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 [email protected] +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
