[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