On 09/29/2010 06:02 PM, Eric Blake wrote:
* tools/virsh.c (cmdSetvcpus): Add new flags. Let invalid
commands through to driver, to ease testing of hypervisor argument
validation.
(cmdVcpucount): New command.
(commands): Add new command.
* tools/virsh.pod (setvcpus, vcpucount): Document new behavior.
---
In testing this, I found it useful to add one more command.
Previously, virsh had no way to get at
virConnectGetMaxVcpus/virDomainGetMaxVcpus (it is used it inside
setvcpus, but not exposed to the user). And now that
virDomainGetVcpusFlags is smarter about reading the maximum limit
associated with the XML of a domain, it is harder to tell whether the
maximum associated with a domain is due to the domain's xml or due to
the XML omitting the <vcpus> element and inheriting the hypervisor's
maximum. That is, with more flexibility in vcpu management, it is also
more important to know, for example, that the max vcpus permitted by xen
is 32, and the max vcpus permitted by qemu is dependent on the number of
cores in the host, whether or not a given domain is using that many vcpus.
I debated between two interfaces:
1. Make vcpucount smarter:
vcpucount => virConnectGetMaxVcpus, plus table of all vcpu stats on all
domains
vcpucount domain => table of all vcpu stats on domain
vcpucount {--live|--config} {--curent|--maximum} domain => single stat
vcpucount domain... => table of all vcpu stats on listed domains
2. Add second command, leaving vcpucount unchanged from v1:
maxvcpus [--type=string] => virConnectGetMaxVcpus
then decided to go with option 2 in my v2 posting of the vcpu series,
unless anyone has a reason why overloading a single command makes more
sense than keeping the separate API calls under separate commands.
--
Eric Blake ebl...@redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
