On Thu, May 21, 2009 at 10:39:03PM +0200, Matthias Bolte wrote: > 2009/5/21 Chris Lalancette <[email protected]>: > > Well, this is because of a peculiarity with Xen PV domains. In Xen PV > > guests, > > you specify a "maxmem" and a "memory" parameter in the configuration file. > > The > > "maxmem" parameter is presented to the guest as the end of the e820 map, > > hence > > the end of real memory as far as the guest is concerned (you can see that > > in the > > output of dmesg from the guest). When the balloon driver in the guest > > loads, it > > will "allocate" (maxmem - memory), so that free inside the guest looks like > > it > > only has 1GB. Later on, you can balloon back up, which means that the > > balloon > > driver "releases" memory back to the domain (but never above the maxmem > > parameter, since that's what's in the e820 map for the guest). > > > > I would say for ESX driver, you probably want to follow the Qemu model; > > it's the > > model that KVM and even Xen FV guests follow, so seems to be more common. > > > > I hope that helps somewhat. > > Yes, it does. So my first assumption was correct. SetMaxMemory defines > the total amount of memory that could be available for the guest and > SetMemory defines the actual amount of memory that is available for > the guest to use.
Yup, with SetMemory being a best-effort kind of contract, while MaxMemory is a hardcoded value for the life of a running domain, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ [email protected] | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
