File 774-maxvcpu.patch of Package libvirt-cim

Overview Repositories Revisions Requests Users Attributes Meta

File 774-maxvcpu.patch of Package libvirt-cim (Revision 56819c74b1cf1f0fdcd8422a7b52bc9e)

Currently displaying revision 56819c74b1cf1f0fdcd8422a7b52bc9e , Show latest

# HG changeset patch
# User Dan Smith <danms@us.ibm.com>
# Date 1228245240 28800
# Node ID 03af2846604b1fdc8d1d7fa3aef737f727b0414b
# Parent  c9a0e8c2f4e85f9bbdbe1857ac5689e8a8efc909
Catch unimplemented sentinel of GetMaxVcpus and be less stupid

Currently, we stuff the result of GetMaxVcpus into a u64 directly.  Since
that function can return -1 for unimplemented (as it does for LXC), we end
up with a ridiculously large number of vcpus as the maximum.

Assuming nothing can run with less than 1 cpu, I think it's a safe default
for this case.

Signed-off-by: Dan Smith <danms@us.ibm.com>

Index: libvirt-cim-0.5.2/src/Virt_SettingsDefineCapabilities.c
===================================================================
--- libvirt-cim-0.5.2.orig/src/Virt_SettingsDefineCapabilities.c
+++ libvirt-cim-0.5.2/src/Virt_SettingsDefineCapabilities.c
@@ -330,6 +330,7 @@ static bool get_max_procs(const CMPIObje
 {
         bool ret = false;
         virConnectPtr conn;
+        int max;
 
         conn = connect_by_classname(_BROKER, CLASSNAME(ref), s);
         if (conn == NULL) {
@@ -339,8 +340,14 @@ static bool get_max_procs(const CMPIObje
                 goto out;
         }
 
-        *num_procs = virConnectGetMaxVcpus(conn, NULL);
-        CU_DEBUG("libvirt says %d max vcpus", *num_procs);
+        max = virConnectGetMaxVcpus(conn, NULL);
+        if (max == -1) {
+                CU_DEBUG("GetMaxVcpus not supported, assuming 1");
+                *num_procs = 1;
+        } else {
+                *num_procs = max;
+                CU_DEBUG("libvirt says %d max vcpus", *num_procs);
+        }
         ret = true;
 
  out:

Places

File 774-maxvcpu.patch of Package libvirt-cim (Revision 56819c74b1cf1f0fdcd8422a7b52bc9e)

Places