[et-mgmt-tools] [PATCH] Add the option to guard maximums of thenumber of virtual CPU by the number of physical CPU

[Masayuki Sunou]

Hi Hugh

> Unless you can think of a compelling reason not to allow a user to do 
> the above, I think we should not take this patch and leave the vcpu 
> setting unbounded. However if you would like to send a patch that warns 
> the user without imposing a hard limit, I think that would be reasonable.
> 
I accepted your suggestion, and I made a patch again.

This patch adds the option to warn when the number of virtual CPU is
more than the number of physical CPU. 

Signed-off-by: Masayuki Sunou <fj1826dm at aa.jp.fujitsu.com>

Thanks

===============================================================================
diff -r 73d38353c139 virt-install
--- a/virt-install	Fri Mar 16 14:32:06 2007 -0400
+++ b/virt-install	Mon Mar 19 14:44:04 2007 +0900
@@ -89,12 +89,23 @@ def get_uuid(uuid, guest):
         except ValueError, e:
             print "ERROR: ", e
 
-def get_vcpus(vcpus, guest):
-    if vcpus: 
-        try:
+def get_vcpus(vcpus, check_cpu, guest, conn):
+    while 1:
+        if check_cpu is None:
+            break
+        hostinfo = conn.getInfo()
+        cpu_num = hostinfo[4] * hostinfo[5] * hostinfo[6] * hostinfo[7]
+        if vcpus <= cpu_num:
+            break
+        res = prompt_for_input("Virtual CPU (%d) is more than physical CPU (%d). Would you like to attach virtual CPU more than physical CPU? (yes or no)" %(vcpus, cpu_num))
+        try:
+            if yes_or_no(res):
+                break
+            vcpus = int(prompt_for_input("How many VCPUs should be attached?"))
+        except ValueError, e:
+            print "ERROR: ", e
+    if vcpus:
             guest.vcpus = vcpus
-        except ValueError, e:
-            print "ERROR: ", e
 
 def get_keymap(keymap, guest):
     if keymap:
@@ -267,6 +278,8 @@ def parse_args():
                       help="UUID for the guest; if none is given a random UUID will be generated")
     parser.add_option("", "--vcpus", type="int", dest="vcpus",
                       help="Number of vcpus to configure for your guest")
+    parser.add_option("", "--check-cpu", action="store_true", dest="check_cpu",
+                      help="Check the maximum of physical CPU.")
 
     # disk options
     parser.add_option("-f", "--file", type="string",
@@ -473,7 +486,7 @@ def main():
     get_name(options.name, guest)
     get_memory(options.memory, guest)
     get_uuid(options.uuid, guest)
-    get_vcpus(options.vcpus, guest)
+    get_vcpus(options.vcpus, options.check_cpu, guest, conn)
     get_keymap(options.keymap, guest)
 
     # set up disks
===============================================================================


In message <45FADC15.7090207 at redhat.com>
   "Re: [et-mgmt-tools] [PATCH] Add the option to guard maximums of thenumber of virtual CPU by the number of physical CPU"
   "Hugh Brock <hbrock at redhat.com>" wrote:

> Masayuki Sunou wrote:
> > Hi
> > 
> > In virt-install, the maximum of the number of virtual CPU are not guarded
> > by the number of physical CPU. 
> > As a result , the domain slows down when the user set many virtual CPUs
> > by mistake. 
> > 
> > Therefore, I contribute the patch that adds the option to guard maximums
> > of the number of virtual CPU by the number of physical CPU. 
> > 
> > 
> > Signed-off-by: Masayuki Sunou <fj1826dm at aa.jp.fujitsu.com>
> > 
> > Thanks,
> > Masayuki Sunou
> 
> Actually, we had included this limit early on, but we decided to merely 
> warn the user that excess vcpus can be bad. The thought was that a user 
> might define a domain somewhere, test it, then migrate it to a machine 
> with more CPUs, in which case we would need to allow them to define more 
> virtual CPUs than are physically present.
> 
> Unless you can think of a compelling reason not to allow a user to do 
> the above, I think we should not take this patch and leave the vcpu 
> setting unbounded. However if you would like to send a patch that warns 
> the user without imposing a hard limit, I think that would be reasonable.
> 
> Take care,
> --Hugh
> 
> -- 
> Red Hat Virtualization Group http://redhat.com/virtualization
> Hugh Brock           | virt-manager http://virt-manager.org
> hbrock at redhat.com    | virtualization library http://libvirt.org
> 
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>