Re: [libvirt] [PATCHv4 4/4] vcpupin: add the new options to "virsh vcpupin" command
On 05/20/2011 03:11 PM, Adam Litke wrote:
On 05/20/2011 04:10 AM, Taku Izumi wrote:
> --- libvirt.orig/tools/virsh.c
> +++ libvirt/tools/virsh.c
> @@ -2757,6 +2757,9 @@ static const vshCmdOptDef opts_vcpupin[]
> {"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or
uuid")},
> {"vcpu", VSH_OT_INT, VSH_OFLAG_REQ, N_("vcpu number")},
> {"cpulist", VSH_OT_DATA, VSH_OFLAG_REQ, N_("host cpu number(s)
(comma separated)")},
> + {"config", VSH_OT_BOOL, 0, N_("affect next boot")},
> + {"live", VSH_OT_BOOL, 0, N_("affect running domain")},
> + {"current", VSH_OT_BOOL, 0, N_("affect current domain")},
I am probably just unenlightened, but I still don't understand the
difference between 'current domain' and 'running domain'.
We could probably clean up the 'virsh help' and virsh.pod man page
wording to be more explicit:
--current affects the current state of the domain (--live if domain is
running, --config otherwise). That is, for a running domain (including
a transient domain), it is a hot-plug action that will not affect the
next boot; and for an inactive domain, it affects all future boots.
According to the API documentation, --current is the same as not
specifying either flag. If that's correct, than both the default (no
flags) and --current have the same behavior (which is hypervisor
dependent). The --current switch doesn't even seem necessary.
I'm not sure if it matters here, but it does matter for some other APIs,
such as 'virsh schedinfo' using virDomainSetSchedulerParameters vs.
virDomainSetSchedulerParametersFlags - lack of all three boolean options
implies using the older API (which implies hypervisor-dependent flags);
using any of the three boolean options implies using the newer API
(where --current has an explicit meaning).
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachments:
- signature.asc (application/pgp-signature — 619 bytes)