[Libvir] [PATCH] check the maximum of virtual CPU

[Masayuki Sunou]

Hi, Dan

> >  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.

 ・ virDomainGetMaxVcpus
   Judge state (active/inactive) of the domain, and return information
   corresponding to each state. 

 ・ virConnectGetMaxVcpus
   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>

Thanks

----------------------------------------------------------------------
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
> limit.
> 
> 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
> issue:
> 
>   -  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 ???
> 
> Dan.
> -- 
> |=- 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...
Name: libvirt-check-max-vcpu.patch
Type: application/octet-stream
Size: 17330 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070306/d43b1d0a/attachment-0001.obj>