[libvirt] [PATCH] virsh: Fix docs for "virsh setmaxmem"
The docs assumed the command works always for QEMU and other hypervisors. Unfortunately until qemu will add memory hotplug this can't be done. Fix the docs to mention this limitation. --- tools/virsh.pod | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/virsh.pod b/tools/virsh.pod index b5e632e..07e7c24 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -1469,23 +1469,24 @@ paravirtualized or running the PV balloon driver. =item B<setmaxmem> I<domain> B<size> [[I<--config>] [I<--live>] | [I<--current>]] Change the maximum memory allocation limit for a guest domain. If I<--live> is specified, affect a running guest. If I<--config> is specified, affect the next boot of a persistent guest. If I<--current> is specified, affect the current guest state. Both I<--live> and I<--config> flags may be given, but I<--current> is exclusive. If no flag is specified, behavior is different depending on hypervisor. -This command works for at least the Xen, QEMU/KVM and vSphere/ESX hypervisors. +Some hypervisors such as QEMU/KVM don't support live changes (especially +increasing) of the maximum memory limit. I<size> is a scaled integer (see B<NOTES> above); it defaults to kibibytes (blocks of 1024 bytes) unless you provide a suffix (and the older option name I<--kilobytes> is available as a deprecated synonym) . Libvirt rounds up to the nearest kibibyte. Some hypervisors require a larger granularity than KiB, and requests that are not an even multiple will be rounded up. For example, vSphere/ESX rounds the parameter up to mebibytes (1024 kibibytes). =item B<memtune> I<domain> [I<--hard-limit> B<size>] [I<--soft-limit> B<size>] [I<--swap-hard-limit> B<size>] [I<--min-guarantee> B<size>] [[I<--config>] [I<--live>] | [I<--current>]] -- 1.8.1.5
On 03/22/2013 04:08 AM, Peter Krempa wrote:
The docs assumed the command works always for QEMU and other hypervisors. Unfortunately until qemu will add memory hotplug this can't be done. Fix the docs to mention this limitation.
The setmaxmem command controls balloon size, not memory hotplug. If qemu adds memory hotplug, we STILL have to pre-declare a maximum memory size when qemu first boots, and at runtime, you can only change the current memory. And if we do add qemu memory hotplug support (and not just memory ballooning), I'm not sure if it would make sense to reuse the setmaxmem command (probably with a new flag) or add a new command.
--- tools/virsh.pod | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
-This command works for at least the Xen, QEMU/KVM and vSphere/ESX hypervisors. +Some hypervisors such as QEMU/KVM don't support live changes (especially +increasing) of the maximum memory limit.
I don't know of any hypervisor that supports changing the maximum limit on a live domain - the maximum is pinned when the hypervisor starts, and can only be changed for the next boot. At any rate, while this wording might not be the best possible, it is certainly an improvement, so: ACK. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 03/22/13 22:01, Eric Blake wrote:
On 03/22/2013 04:08 AM, Peter Krempa wrote:
The docs assumed the command works always for QEMU and other hypervisors. Unfortunately until qemu will add memory hotplug this can't be done. Fix the docs to mention this limitation.
The setmaxmem command controls balloon size, not memory hotplug. If qemu adds memory hotplug, we STILL have to pre-declare a maximum memory size when qemu first boots, and at runtime, you can only change the current memory. And if we do add qemu memory hotplug support (and not just memory ballooning), I'm not sure if it would make sense to reuse the setmaxmem command (probably with a new flag) or add a new command.
I agree, the commit message was a bit misleading. The question of memory hotplug will have to remain open until qemu will actually support it. I removed the note about hotplug from the commit message.
--- tools/virsh.pod | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
-This command works for at least the Xen, QEMU/KVM and vSphere/ESX hypervisors. +Some hypervisors such as QEMU/KVM don't support live changes (especially +increasing) of the maximum memory limit.
I don't know of any hypervisor that supports changing the maximum limit on a live domain - the maximum is pinned when the hypervisor starts, and can only be changed for the next boot.
At any rate, while this wording might not be the best possible, it is certainly an improvement, so:
Well yes. I thought about it a bit more, the wording isn't ideal but definitely better than it was before, so ...
ACK.
I pushed this patch. Thanks. Peter
participants (2)
-
Eric Blake -
Peter Krempa