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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org