Re: [libvirt] [PATCH 0/8] logically memory hotplug via guest agent

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

recently added DIMM hot add/remove feature on the host side, if at all ? Are the changes made synchronously or asynchronously - ie does the API block while the guest OS releases the memory from the blocks that re released, or is it totally in the backgrond like the balloon driver.. On a design POV, we're reusing the existing virDomainSetMemory API but adding a restriction that it has to be in multiples of the block size, which the mgmt app has no way of knowing upfront. It feels like this is information we need to be able to expose to the app in some manner.