Re: [libvirt] adding a new libvirt xml element for File Descriptor backed memory for use with vhost-user
On Tue, May 10, 2016 at 09:01:20PM +0000, Mooney, Sean K wrote:
Today the only native way to request Libvirt to create a vm
who's memory is backed by a memdev which can be
Accessed via a file descriptor is to request hugepage backed memory. This requires the
operator to
Manage and configure hugepage on each of their compute hosts and take special care to
ensure that vms are
Not placed on host were vhost-user interface are used if they do not request hugepages.
Today it is possible to use Libvirt to spawn a vm without hugepage memory and a file
descriptor backed memdev
Via the use of the qemu:commandline element.
<qemu:commandline>
<qemu:arg value='-object'/>
<qemu:arg
value='memory-backend-file,id=mem,size=1024M,mem-path=/var/lib/libvirt/qemu,share=on'/>
<qemu:arg value='-numa'/>
<qemu:arg value='node,memdev=mem'/>
<qemu:arg value='-mem-prealloc'/>
</qemu:commandline>
I created a proof of concept patch to nova to demonstrate that this works however to
support this usecase in
Nova a new xml element is required.
https://review.openstack.org/#/c/309565/1
I would like to propose the introduction of a new subelemnt to the memorybacking element
to request file discrptro backed memory
<memoryBacking>
<filedescriptor size_mb="1024" path="/var/lib/libvirt/qemu"
prealloc="true" shared="on" />
</memoryBacking>
Specifying a size is not required - we already know how big memory must
be for the guest.
We already have a memAccess='shared' attribute against the <numa>
element that is used to determine if the underlying memory should
be setup as shared. We could define a further element that lets
us control memory access mode for guests without NUMA topology
specified.
<memoryBacking>
<access mode="shared"/>
</memoryBacking>
For huge pages it seems we unconditionally pass --mem-prealloc. I'm thinking
we could perhaps make that configurable via an element
<memoryBacking>
<allocation mode="immediate|ondemand"/>
</memoryBacking>
to control use of -mem-prealloc or not.
So all that remains is a way to request file based backing of RAM. As with
huge pages, I think we should hide the actual path from the user. We should
just use /dev/shm as the backing for non-hugepage RAM. For this we could
define something like
<memoryBacking>
<source type="file|anonymous"/>
</memoryBacking>
Putting that all together, to get what you want we'd have
<memoryBacking>
<source type="file"/>
<access mode="shared"/>
<allocation mode="immediate"/>
</memoryBacking>
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 :|