[libvirt] [PATCH] docs: correct setmem text plus expand setmaxmem text

[Daniel P. Berrange]

On Wed, Jan 19, 2011 at 08:40:33PM +0100, Matthias Bolte wrote:
> 2011/1/19 Eric Blake <eblake at redhat.com>:
> > On 01/18/2011 05:28 PM, Justin Clift wrote:
> >> This completes the man page updates required for BZ # 622534:
> 
> >> +
> >> +Some hypervisors require a larger granularity than kilobytes, and requests
> >> +that are not an even multiple will either be rounded down or rejected.  For
> >> +example, vSphere/ESX rejects the parameter unless the kB argument is evenly
> >> +divisible by 1024 (that is, the kB argument happens to represent megabytes).
> >> +
> >> +Note, this command only works on active guest domains.  To change the memory
> >> +allocation for an inactive guest domain, use the virsh B<edit> command to
> >> +update the XML <memory> element.
> >
> > I guess this means some experimentation is in order to validate these
> > claims.
> >
> 
> Actually the ESX driver is a bit inconsistent in that regard. Most
> times the code will just divide by 1024 when libvirt uses kilobytes
> but ESX needs megabytes. It even ignores the case when this results in
> 0 megabytes.
> 
> The VMX handling code is stricter and rejects values that are not even
> dividable by 1024, or by 4096 in case of <memory> or by 64 in case of
> <video vram=...>. So this only affects virsh define and virsh dumpxml,
> the only two places where the ESX driver uses the VMX handling code.
> 
> I wonder in which direction to go in order to unify this: being more
> strict and do "value % 1024 == 0" checks all over the place, or being
> less strict and just divide by 1024.

There was a problem reported against the storage driver thats
similar. When creating LVM volumes we just / 1024 to get KB,
but this truncates, so if an app absolutely needs a particular
min size we likely give them a volume too small. So arguably
when converting to less granular units, we should round up to
the nearest, rather than truncating or rounding down. Throwing
an error is probably a little too harsh

Daniel