[libvirt] [PATCH 1/3] add percentage limit parse and define support for RAM filesystems

Daniel P. Berrange berrange at redhat.com
Thu Dec 5 13:17:16 UTC 2013


On Thu, Dec 05, 2013 at 06:12:22AM -0700, Eric Blake wrote:
> On 12/05/2013 04:56 AM, Daniel P. Berrange wrote:
> 
> >>>>>
> >>>>> This patch enables percentage limit for ram filesystem
> >>>>>
> >>>>> <filesystem type='ram'>
> >>>>>     <source usage='10%'/>
> >>>>>     <target dir='/mnt'/>
> >>>>> </filesystem>
> >>>>>
> 
> > 
> > I just don't see this as a compelling feature. I think it is more important
> > to have a single canonical representation of memory allocation. User
> > convenience is something for higher level tools to worry about.
> 
> But do higher level tools already have a way to query libvirt what the
> current host's available ram is, in order to determine percentages
> itself?  We can't really migrate online LXC guests, but for an offline
> guest setup, copying XML from one host with small memory to another host
> with large memory, and still having the guest have a fixed percentage of
> the host resources (more memory assigned to the guest on the larger
> host), seems like a reasonable desire; to achieve that, the management
> tool needs to be able to either request percentages (no change to the
> guest xml being copied) or know the host resource limits (and rewrite
> the xml rather than merely copy it).

We do have APIs for querying host RAM, but if we wanted this, which I
don't think we do, then tmpfs RAM % would want to be relative to guest
RAM allocation not host RAM. It doesn't make sense to have guest XML
whose semantics differ according to the host environment - they should
be self-contained.

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




More information about the libvir-list mailing list