On Tue, Jun 09, 2015 at 01:22:49PM +0200, Peter Krempa wrote:
On Tue, Jun 09, 2015 at 11:05:16 +0100, Daniel Berrange wrote:
> On Tue, Jun 09, 2015 at 05:33:24PM +0800, Zhang Bo wrote:
> > Logically memory hotplug via guest agent, by enabling/disabling memory blocks.
> > The corresponding qga commands are: 'guest-get-memory-blocks',
> > 'guest-set-memory-blocks' and 'guest-get-memory-block-info'.
> >
> > detailed flow:
> > 1 get memory block list, each member has 'phy-index',
'online' and 'can-offline' parameters
> > 2 get memory block size, normally 128MB or 256MB for most OSes
> > 3 convert the target memory size to memory block number, and see if
there's enough memory
> > blocks to be set online/offline.
> > 4 update the memory block list info, and let guest agent to set memory
blocks online/offline.
> >
> >
> > Note that because we hotplug memory logically by online/offline MEMORY BLOCKS,
> > and each memory block has a size much bigger than KiB, there's a deviation
> > with the range of (0, block_size). block_size may be 128MB or 256MB or etc.,
> > it differs on different OSes.
>
> So thre's alot of questions about this feature that are unclear to me..
>
> This appears to be entirely operating via guest agent commands. How
> does this then correspond to increased/decreased allocation in the host
> side QEMU ? What are the upper/lower bounds on adding/removing blocks.
> eg what prevents a malicous guest from asking for more memory to be
> added too itself than we wish to allow ? How is this better / worse than
> adjusting memory via the balloon driver ? How does this relate to the
There are two possibilities where this could be advantageous:
1) This could be better than ballooning (given that it would actually
return the memory to the host, which it doesn't) since you probably
will be able to disable memory regions in certain NUMA nodes which is
not possible with the current balloon driver (memory is taken randomly).
2) The guest OS sometimes needs to enable the memory region after ACPI
memory hotplug. The GA would be able to online such memory. For this
option we don't need to go through a different API though since it can
be compounded using a flag.
So, are you saying that we should not be adding this to the
virDomainSetMemory API as done in this series, and we should
instead be able to request automatic enabling/disabling of the
regions when we do the original DIMM hotplug ?
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|