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@xxxxxxxxxxxxxxxxx> Thanks ---------------------------------------------------------------------- In message <20070306035647.GA31470@xxxxxxxxxx> "Re: [PATCH] check the maximum of virtual CPU" ""Daniel P. Berrange" <berrange@xxxxxxxxxx>" 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 -=| >
Attachment:
libvirt-check-max-vcpu.patch
Description: Binary data