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