Re: adding a new libvirt xml element for File Descriptor backed memory for use with vhost-user

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]