[Libvir] [PATCH] Implement memory operations for qemu driver

Daniel Veillard veillard at redhat.com
Tue Mar 18 14:31:31 UTC 2008


On Tue, Mar 18, 2008 at 10:04:12AM -0400, Cole Robinson wrote:
> Richard W.M. Jones wrote:
> > 
> >> 2) Should SetMaxMem be able to be called on a running guest? This code
> >>    allows it, since maxmem is basically a metavalue that doesn't directly
> >>    affect a guest.
> >>
> >> 3) Should maxmem be able to be set lower than the currently allocated mem?
> >>    This code does not allow this. If this changed, would also need to take
> >>    into account how we would handle this if we can change the maxmem while
> >>    the guest is running. After rethinking, we probably should be able to
> >>    do this, but I haven't changed the code.
> > 
> > As far as I understand what maxmem means (for Xen), this seems to be
> > correct behaviour.
> > 
> > Rich.
> > 
> 
> I just checked this: xm seems to explicitly reject setting maxmem lower than
> current mem for a guest in any state, but going through virsh you can set
> maxmem to any value on an inactive guest. But it is probably better to just
> stick with the xm convention.

  in practice it should be fine to change max_mem on any domain which has
no running instance, as long as the domain will go though a create to run
again, because that's at create time that some of the data is allocated
based on that maximum size. For example resizing and restoring a domain
which was previously saved to disk won't work in practice, and it's impossible
for libvirt or the hypervisor to know if a domain will be restarted with
Create() or Restore(). I think xm is being a bit too cautious there, though
I can understand their decision.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/




More information about the libvir-list mailing list