On Thu, May 21, 2009 at 10:39:03PM +0200, Matthias Bolte wrote: > 2009/5/21 Chris Lalancette <clalance@xxxxxxxxxx>: > > 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/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list