[libvirt] [PATCH] docs: correct setmem text plus expand setmaxmem text
This completes the man page updates required for BZ # 622534: https://bugzilla.redhat.com/show_bug.cgi?id=622534 --- tools/virsh.pod | 15 +++++++++++---- 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/tools/virsh.pod b/tools/virsh.pod index 1f15fef..c0cda79 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -580,13 +580,20 @@ paravirtualized or running the PV balloon driver. 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. +update the XML <currentMemory> element. =item B<setmaxmem> I<domain-id> B<kilobytes> -Change the maximum memory allocation limit in the guest domain. This should -not change the current memory use. The memory limit is specified in -kilobytes. +Change the maximum memory allocation limit for an active guest domain. + +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. =item B<memtune> I<domain-id> optional I<--hard-limit> B<kilobytes> optional I<--soft-limit> B<kilobytes> optional I<--swap-hard-limit> -- 1.7.3.5
On 01/18/2011 05:28 PM, Justin Clift wrote:
This completes the man page updates required for BZ # 622534:
https://bugzilla.redhat.com/show_bug.cgi?id=622534 =item B<setmaxmem> I<domain-id> B<kilobytes>
-Change the maximum memory allocation limit in the guest domain. This should -not change the current memory use. The memory limit is specified in -kilobytes. +Change the maximum memory allocation limit for an active guest domain.
I'm a bit confused here. Doesn't maximum memory allocation only take effect at domain boot? So it seems like something you can't change at runtime, and if a change is made to an active domain, it only affects the configured version and the next boot of the domain rather than having an immediate effect. But I haven't played closely with setmaxmem, so I could be wrong.
+ +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. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Wed, Jan 19, 2011 at 07:54:52AM -0700, Eric Blake wrote:
On 01/18/2011 05:28 PM, Justin Clift wrote:
This completes the man page updates required for BZ # 622534:
https://bugzilla.redhat.com/show_bug.cgi?id=622534 =item B<setmaxmem> I<domain-id> B<kilobytes>
-Change the maximum memory allocation limit in the guest domain. This should -not change the current memory use. The memory limit is specified in -kilobytes. +Change the maximum memory allocation limit for an active guest domain.
I'm a bit confused here. Doesn't maximum memory allocation only take effect at domain boot? So it seems like something you can't change at runtime, and if a change is made to an active domain, it only affects the configured version and the next boot of the domain rather than having an immediate effect. But I haven't played closely with setmaxmem, so I could be wrong.
In theory we could change maxmem at runtime, if the guest truely supported memory hotplug, instead of simply ballooning. No hypervisor or guest in existance really does that yet. So 'max mem' should be considered a boot time only tunable at this time. Daniel
On 20/01/2011, at 2:05 AM, Daniel P. Berrange wrote:
On Wed, Jan 19, 2011 at 07:54:52AM -0700, Eric Blake wrote:
On 01/18/2011 05:28 PM, Justin Clift wrote:
This completes the man page updates required for BZ # 622534:
https://bugzilla.redhat.com/show_bug.cgi?id=622534 =item B<setmaxmem> I<domain-id> B<kilobytes>
-Change the maximum memory allocation limit in the guest domain. This should -not change the current memory use. The memory limit is specified in -kilobytes. +Change the maximum memory allocation limit for an active guest domain.
I'm a bit confused here. Doesn't maximum memory allocation only take effect at domain boot? So it seems like something you can't change at runtime, and if a change is made to an active domain, it only affects the configured version and the next boot of the domain rather than having an immediate effect. But I haven't played closely with setmaxmem, so I could be wrong.
In theory we could change maxmem at runtime, if the guest truely supported memory hotplug, instead of simply ballooning. No hypervisor or guest in existance really does that yet. So 'max mem' should be considered a boot time only tunable at this time.
The virsh "setmaxmem" command we have at the moment seems to be for changing the max value of an active domain, and doesn't yet appear to have any capability for changing the persistent XML config. Trying it out on a F14 guest, running on RHEL 6.0, confirms this isn't a supported operation on running guests with the RHEL 6.0 Qemu/KVM hypervisor: # setmaxmem Fedora_14_x64 786432 error: Unable to change MaxMemorySize error: this function is not supported by the connection driver: virDomainSetMaxMemory Went looking at the commit that added this command to virsh: commit 9425a3e617aff567b2eaa1713cda4790aab62b8b Author: Daniel P. Berrange <berrange@redhat.com> Date: Wed Aug 16 17:30:33 2006 +0000 Added setvcpus, setmem, setmaxme commands to virsh Wasn't anything super informative in there, but the commit immediately before it looks like it might have relevance: commit 5c2831b30b3cb0a8f422006a87f0423c74d26707 Author: Daniel P. Berrange <berrange@redhat.com> Date: Wed Aug 16 16:36:39 2006 +0000 Hook up more test driver methods. Allow HV config to be loaded from extenral XML definition Is there any chance that the "setmaxmem" command as presently implemented, is really only suitable for use by a test driver of some sort? Regards and best wishes, Justin Clift
2011/1/19 Eric Blake <eblake@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. Matthias
On Wed, Jan 19, 2011 at 08:40:33PM +0100, Matthias Bolte wrote:
2011/1/19 Eric Blake <eblake@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
On 01/19/2011 12:40 PM, Matthias Bolte wrote:
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.
See also this bug report, where the request was made to round up to the next integral block size rather than truncate or error out (regardless of granularity of block size): https://bugzilla.redhat.com/show_bug.cgi?id=670529 since storage management and volume creation is closely related to memory sizes in that both suffer from block-sized granularity. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
2011/1/19 Justin Clift <jclift@redhat.com>:
This completes the man page updates required for BZ # 622534:
-Change the maximum memory allocation limit in the guest domain. This should -not change the current memory use. The memory limit is specified in -kilobytes. +Change the maximum memory allocation limit for an active guest domain. + +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).
Actually vSphere/ESX truncates in this case. It rejects in other cases (virsh define). As Dan suggested, I might change this to round up. Matthias
On 20/01/2011, at 11:30 PM, Matthias Bolte wrote:
2011/1/19 Justin Clift <jclift@redhat.com>:
This completes the man page updates required for BZ # 622534:
-Change the maximum memory allocation limit in the guest domain. This should -not change the current memory use. The memory limit is specified in -kilobytes. +Change the maximum memory allocation limit for an active guest domain. + +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).
Actually vSphere/ESX truncates in this case. It rejects in other cases (virsh define).
As Dan suggested, I might change this to round up.
No worries. Looks like the man page is about to get more complicated. Heh. With the "round up" approach, no real issues with that. It *would* be printing some kind of warning message though wouldn't it, alerting the user that what they asked for isn't what they got?
On 20/01/2011, at 11:30 PM, Matthias Bolte wrote:
2011/1/19 Justin Clift <jclift@redhat.com>:
This completes the man page updates required for BZ # 622534:
-Change the maximum memory allocation limit in the guest domain. This should -not change the current memory use. The memory limit is specified in -kilobytes. +Change the maximum memory allocation limit for an active guest domain. + +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).
Actually vSphere/ESX truncates in this case. It rejects in other cases (virsh define).
As Dan suggested, I might change this to round up.
With vSphere/ESX, does the virsh "setmaxmem" command work on running guest domains, or only inactive ones, or ? I'd *really* like to update the man page docs around this in the next few days, and I'm still not sure what this command is actually doing in the real world. Heh. ;(
2011/1/26 Justin Clift <jclift@redhat.com>:
On 20/01/2011, at 11:30 PM, Matthias Bolte wrote:
2011/1/19 Justin Clift <jclift@redhat.com>:
This completes the man page updates required for BZ # 622534:
-Change the maximum memory allocation limit in the guest domain. This should -not change the current memory use. The memory limit is specified in -kilobytes. +Change the maximum memory allocation limit for an active guest domain. + +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).
Actually vSphere/ESX truncates in this case. It rejects in other cases (virsh define).
As Dan suggested, I might change this to round up.
With vSphere/ESX, does the virsh "setmaxmem" command work on running guest domains, or only inactive ones, or ?
I'd *really* like to update the man page docs around this in the next few days, and I'm still not sure what this command is actually doing in the real world. Heh. ;(
setmaxmem works on inactive guest only. Thanks for making me test this again, because I found a bug in the ESX driver, actually in the vSphere API. The API call allows to set max memory to values that aren't a multiple of 4 megabyte. But such a virtual machine fails to start as ESX reports a general config fault for it. The vSphere Client only allows to change this value in 4 mb steps. I'll have to fix that. Matthias
participants (4)
-
Daniel P. Berrange -
Eric Blake -
Justin Clift -
Matthias Bolte