[Libvir] [PATCH] check the maximum of virtual CPU
fj1826dm at aa.jp.fujitsu.com
Tue Mar 6 11:08:57 UTC 2007
> > 1. When initially creating a VM
> > 2. When changing the config of an inactive VM
> > 3. When changing the config of a running VM
Certainly, I had not considered concerning 1 and 2.
So, I corrected the patch based on your proposal.
Judge state (active/inactive) of the domain, and return information
corresponding to each state.
Add it as a method that returns the number of maximum CPUs defined by Xen.
However, I only added virConnectGetMaxVcpus because I did not understand
the use image of it.
Is it added as a command of virsh?
Or, is it used from virsh create and virsh start?
Signed-off-by: Masayuki Sunou <fj1826dm at aa.jp.fujitsu.com>
In message <20070306035647.GA31470 at redhat.com>
"Re: [Libvir] [PATCH] check the maximum of virtual CPU"
""Daniel P. Berrange" <berrange at redhat.com>" wrote:
> On Mon, Mar 05, 2007 at 03:42:35PM +0900, Masayuki Sunou wrote:
> > I removed a needless part from the former patch.
> > Add check the maxmum of virtual CPU.
> I was thinking about how to make use of this new API in virt-manager
> when I came up with a further complication :-) There are three scenarios
> where I'd like to be able to find out the maximum VCPUs possible for
> a guest VM:
> 1. When initially creating a VM
> 2. When changing the config of an inactive VM
> 3. When changing the config of a running VM
> Thus far in this thread, we've focused on addressing the last point,
> but I think its worth trying address all 3 while we're looking at
> this area.
> In the first case, we do not have a virDomainPtr object at all yet,
> all we have is a virConnectPtr and info about the type of domain
> we're planning to create - Xen, QEMU, KVM, KQEMU. When creating a
> VM we need to apply some domain type specific limit.
> In the case of an inactive domain, we have a virDomainPtr object
> and from that the internal drivers can determine the domain type
> or Xen, QEMU, KVM, etc, and again apply some domain type specific
> In the 3rd case of a running VM though, the hypervisor limit is
> typically not neccessarily the one that is relevant. While the
> hypervisor will still has its own limit of VCPUs, the effective
> limit is likely lower - ie fixed at the number of virtual CPUs
> which were allocated when the guest OS booted. So if you boot a
> guest with 4 cpus, you can hotplug remove & add CPUs, but you
> can never go above 4 until the guest is shutdown.
> So anyway, I think we need to add 2 apis to address this whole
> - int virConnectGetMaxVcpus(virConnectPtr conn,
> const char *type);
> Returns the maximum number of virtual CPUs supported for
> a guest VM of a specific type. Thje 'type' parameter here
> corresponds to the 'type' attribute in the <domain>
> element of the XML.
> - int virDomainGetMaxVcpus(virDomainPtr dom);
> Returns the maximum number of virual CPUs supported for
> the guest VM. If the guest is inactive, this is basically
> the same as virConnectGetMaxVcpus. If the guest is running
> this will reflect the maximum number of VCPus the guest
> was booted with.
> In terms of the Xen implementation, the virConnectGetMaxVcpus
> method can simply return MAX_VIRT_VCPUS. Likewie virDomainGetMaxVcpus
> can do the same for inactive guests, but if the guest is running then
> we will need to call out to XenD to extract the max vcpus info.
> Any other thoughts from people on the list ???
> |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
> |=- Perl modules: http://search.cpan.org/~danberr/ -=|
> |=- Projects: http://freshmeat.net/~danielpb/ -=|
> |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 17330 bytes
Desc: not available
More information about the libvir-list