[Kimchi-devel] [PATCH 0/5] [Memory HotPlug] Implements backend of memory device hotplug

Rodrigo Trujillo rodrigo.trujillo at linux.vnet.ibm.com
Thu May 28 13:49:35 UTC 2015



On 05/27/2015 02:19 PM, Crístian Deives wrote:
> On 27-05-2015 12:39, Rodrigo Trujillo wrote:
>> Hi Cristian,
>>
>> "why create memdevides ?"
>> this is all about the way libvirt and memory hotplug works. Let me 
>> try to explain:
>> - it is possible to set in guest xml two elements: <memory> and 
>> <currentmemory>.  The first is the max amount of memory allocated to 
>> guest when libvirt starts it, the second is the memory the guest will 
>> "see". You can increase and decrease currentmemory with guest 
>> running, but you are not actually hotadding memory, you are using the 
>> ballooning module of the guest.
>
> Changes to a VM's XML configuration are not applied to a running 
> system, so changing the memory value via XML on a running VM isn't 
> expected to update the VM memory, only after reboot.

Yes, yes, you are correct. Actually I mentioned <memory> and 
<currentMemory> but did not say that we have to use "setMemoryFlags" and 
"setMaxMemory" to update this values in a running system. Change the XML 
is not an option to memory hotplug.

>
>> - on the other side, we can attach (hotplug) a memory device to the 
>> guest (like attach a network device), this is different then using 
>> the ballooning. And values can higher than <memory>. In fact, this is 
>> the only way to increase <memory> on running guests.
>
> It's not. You can use the function "dom.setMemory[Flags]", which seems 
> like a much easier way of implementing this feature.
>

Yes, we can use the setMemory, but you can only increase the running 
guest memory up to the value set in <memory>. And, yes, this is way easier
to implement, but we would have to set <memory> to a high value and 
<currentMemory> to a value that the user wants to start the guest. So user
will have an interval between <currentMemory> and <memory> to increase. 
Today, Kimchi uses <memory> and <currentMemory> as the same.
I think you are mixing the concepts (I did this too), the feature I am 
proposing in hotplug memory, like install new memory module in a 
physical machine.
This way you can increase the guest value for a higher value, than the 
previously set in <memory>. In other words, we don't want to use ballooning.

> And even if you really need to attach a memory device to a VM, 
> wouldn't it be simpler for the user to just set a memory value? Then 
> Kimchi will add/remove devices as needed.

This can be done in the front-end

> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>




More information about the Kimchi-devel mailing list