[one-users] why doesn't opennebula judge the host capacity except for actions related to scheduler?

[Ruben S. Montero]

Hi

Forgot to mention that these changes are in master, and that's probably the
reason you missed them in the fist place

Ruben


On Fri, Mar 15, 2013 at 9:55 AM, Ruben S. Montero
<rsmontero at opennebula.org>wrote:

> Hi
>
> Here:
>
> Deploy
>
> https://github.com/OpenNebula/one/blob/master/src/rm/RequestManagerVirtualMachine.cc#L486
>
> Migrate (Live or not)
>
> https://github.com/OpenNebula/one/blob/master/src/rm/RequestManagerVirtualMachine.cc#L603
>
> Check function test the capacity, here:
>
> https://github.com/OpenNebula/one/blob/master/src/rm/RequestManagerVirtualMachine.cc#L224
>
> Cheers
>
> Ruben
>
>
> On Fri, Mar 15, 2013 at 3:09 AM, cmcc.dylan <dx10years at 126.com> wrote:
>
>> Thanks Ruben!
>>     I read the source code related to cold migration, but i don't find
>> judgement places about CPU. That is to say, the test_capacity function
>> isn't called in the cold migration. Is it right? If you please, can you
>> poit out how opennebula does?
>>
>>    Thank you very much!
>>
>>
>>
>>
>> At 2013-03-14 17:13:17,"Ruben S. Montero" <rsmontero at opennebula.org>
>> wrote:
>>
>> Hi
>>
>> About the first problem (-2). This should be fixed in OpenNebula 3.8.3,
>> are you using that version? If so can you send the output of onehost sh ow
>> -x <host_id> before and after the migration.
>>
>> About the second problem (capacity checks). We have included the
>> '--enforce' option to enforce that the host capacity is not exceeded for
>> onevm migrate and livemigrate. (The new onevm resize command also accepts
>> that options so you can enforce that the host capacity is not overcommitted
>> when re-sizing the VM capacity).
>>
>> Cheers
>>
>> Ruben
>>
>>
>> On Thu, Mar 14, 2013 at 6:07 AM, cmcc.dylan <dx10years at 126.com> wrote:
>>
>>> Hi everyone!
>>>    I doubt about this problem for a long time and i also prove it using
>>> some test case.
>>>    Firstly, let's describe the problem as follows:
>>>    I manage two host machines using opennebula and they both have 4
>>> cores in total. I deploy vm1 which has 2 cores in host1 and deploy vm2
>>> which has 4 cores in host2. After that, I migrate vm1 to host2, to my
>>> surprise it success and the free cpu of host2 becomes -2.
>>>
>>>    so i read the source code related to virtual machine's migration, and
>>> i find this is no judgement of host resources' capacity in the whole
>>> migration process. Source codes as follows:
>>>                        vm->get_requirements(cpu,mem,disk);
>>>                        hpool->add_capacity(vm->get_hid(),cpu,mem,disk);
>>>    And i also seek what actions does opennebula to test host resources'
>>> capacity and find only two places and they also related to scheduler.For
>>> example:
>>>    (1)void Scheduler::match()
>>>    (2)int VirtualMachineXML::get_host()
>>> Only the two place call the funstion - test_capacity(cpu,mem,dsk) to
>>> judge the host resources.
>>>
>>>    i'm sorry if i don't describe the problem clearly. Hope someone to
>>> help and communication with me.
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>>>
>>
>>
>> --
>> Ruben S. Montero, PhD
>> Project co-Lead and Chief Architect
>> OpenNebula - The Open Source Solution for Data Center Virtualization
>> www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
>>
>>
>>
>>
>
>
> --
> Ruben S. Montero, PhD
> Project co-Lead and Chief Architect
> OpenNebula - The Open Source Solution for Data Center Virtualization
> www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
>



-- 
Ruben S. Montero, PhD
Project co-Lead and Chief Architect
OpenNebula - The Open Source Solution for Data Center Virtualization
www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130315/773f9931/attachment-0002.htm>