[libvirt] [PATCH] docs: expand the man page text for virsh setmaxmem
Addresses BZ # 622534: https://bugzilla.redhat.com/show_bug.cgi?id=622534 --- tools/virsh.pod | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/tools/virsh.pod b/tools/virsh.pod index 4e8b295..0d37512 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -584,9 +584,20 @@ 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 inactive guest domain. + +This command works for at least the Xen and vSphere/ESX hypervisors, +but not for QEMU/KVM. + +Some hypervisors require a larger granularity than kilobytes, rounding down +or rejecting requests that are not an even multiple of the desired amount. +vSphere/ESX is one of these, requiring the parameter to be evenly divisible +by 4MB. For example with vSphere/ESX, 262144 (256MB) is valid as it's a +multiple of 4MB; 263168 (257MB) is not valid as it's not a multiple of 4MB; +266240 (260MB) is also valid, as it's a multiple of 4MB. + +Note, to change the maximum memory allocation for a QEMU/KVM guest domain, +use the virsh B<edit> command instead to update its 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
2011/1/27 Justin Clift <jclift@redhat.com>:
Addresses BZ # 622534:
https://bugzilla.redhat.com/show_bug.cgi?id=622534 --- tools/virsh.pod | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod index 4e8b295..0d37512 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -584,9 +584,20 @@ 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 inactive guest domain. + +This command works for at least the Xen and vSphere/ESX hypervisors, +but not for QEMU/KVM. + +Some hypervisors require a larger granularity than kilobytes, rounding down +or rejecting requests that are not an even multiple of the desired amount. +vSphere/ESX is one of these, requiring the parameter to be evenly divisible +by 4MB. For example with vSphere/ESX, 262144 (256MB) is valid as it's a +multiple of 4MB; 263168 (257MB) is not valid as it's not a multiple of 4MB; +266240 (260MB) is also valid, as it's a multiple of 4MB.
Well, currently this is true. But I'm preparing a patch that makes libvirt round memory/storage request up instead of down when dividing it for a larger granularity. That way you'll get at least what you requested. I basically applied the pattern we started to use in commit "storage: Round up capacity for LVM volume creation" to all places where it applies. I also removed the strict checks from the ESX driver. This means that the ESX driver will automatically round 257MB up to 260MB instead of reporting an error. I didn't post the patch yet, as it isn't finished yet. When my patch gets accepted your patch needs some small tweaks :) Matthias
On 01/27/2011 09:10 AM, Matthias Bolte wrote:
2011/1/27 Justin Clift <jclift@redhat.com>:
+Some hypervisors require a larger granularity than kilobytes, rounding down +or rejecting requests that are not an even multiple of the desired amount. +vSphere/ESX is one of these, requiring the parameter to be evenly divisible +by 4MB. For example with vSphere/ESX, 262144 (256MB) is valid as it's a +multiple of 4MB; 263168 (257MB) is not valid as it's not a multiple of 4MB; +266240 (260MB) is also valid, as it's a multiple of 4MB.
Do we need three examples, or would two be sufficient? For example, vSphere/ESX has a 4MB granularity, so 263168 (257MB) would be rejected while 266240 (260MB) is valid.
Well, currently this is true. But I'm preparing a patch that makes libvirt round memory/storage request up instead of down when dividing it for a larger granularity. That way you'll get at least what you requested.
Let's go ahead and push it as-is, since it is accurate for the current state of the tree,
When my patch gets accepted your patch needs some small tweaks :)
then update it as part of the improved semantics. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On 28/01/2011, at 3:19 AM, Eric Blake wrote:
Do we need three examples, or would two be sufficient?
For example, vSphere/ESX has a 4MB granularity, so 263168 (257MB) would be rejected while 266240 (260MB) is valid.
Yeah, that'd work too. I'll just that example then push it.
On 01/27/2011 09:20 AM, Justin Clift wrote:
On 28/01/2011, at 3:19 AM, Eric Blake wrote:
Do we need three examples, or would two be sufficient?
For example, vSphere/ESX has a 4MB granularity, so 263168 (257MB) would be rejected while 266240 (260MB) is valid.
Yeah, that'd work too. I'll just that example then push it.
In case it wasn't clear: ACK with nits addressed, no need to see a v2; let's go ahead and get this pushed with the minor fix incorporated :) -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On 28/01/2011, at 3:29 AM, Eric Blake wrote:
On 01/27/2011 09:20 AM, Justin Clift wrote:
On 28/01/2011, at 3:19 AM, Eric Blake wrote:
Do we need three examples, or would two be sufficient?
For example, vSphere/ESX has a 4MB granularity, so 263168 (257MB) would be rejected while 266240 (260MB) is valid.
Yeah, that'd work too. I'll just that example then push it.
In case it wasn't clear:
ACK with nits addressed, no need to see a v2; let's go ahead and get this pushed with the minor fix incorporated :)
Thanks Eric, pushed. :)
On 28/01/2011, at 3:10 AM, Matthias Bolte wrote: <snip>
I didn't post the patch yet, as it isn't finished yet.
When my patch gets accepted your patch needs some small tweaks :)
Heh, no worries. Can I can this as an ACK (for libvirt 0.8.7 thus far) though? :) Happy to tweak it again subsequently when your patch goes in btw.
participants (3)
-
Eric Blake -
Justin Clift -
Matthias Bolte