# HG changeset patch
# User Jay Gagnon <grendel(a)linux.vnet.ibm.com>
# Date 1195070622 18000
# Node ID cf3c1b32e71d9a95b3c95ebf3f3622bd39a4a4e3
# Parent 1828b3b30fe476fbae1bf31d99c999ba548911f5
Make net_max callback smarter.
Xen 3.0.x supports up to 4
Xen 3.1.x supports up to 8
KVM supports up to 32
Also move a goto that was placed rather poorly.
Signed-off-by: Jay Gagnon <grendel(a)linux.vnet.ibm.com>
diff -r 1828b3b30fe4 -r cf3c1b32e71d src/Virt_SettingsDefineCapabilities.c
--- a/src/Virt_SettingsDefineCapabilities.c Tue Nov 13 11:39:22 2007 -0800
+++ b/src/Virt_SettingsDefineCapabilities.c Wed Nov 14 15:03:42 2007 -0500
@@ -332,27 +332,80 @@ static struct sdc_rasd_prop *net_min(con
return rasd;
}
-static int net_max_xen(const CMPIObjectPath *ref,
- CMPIStatus *s)
-{
- /* No dynamic lookup for now. */
- return 6;
+static uint16_t net_max_kvm(const CMPIObjectPath *ref,
+ CMPIStatus *s)
+{
+ /* This appears to not require anything dynamic. */
+ return 32;
+}
+static uint16_t net_max_xen(const CMPIObjectPath *ref,
+ CMPIStatus *s)
+{
+ int rc;
+ virConnectPtr conn;
+ unsigned long version;
+ uint16_t num_nics = -1;
+
+ conn = lv_connect(_BROKER, s);
+ if (s->rc != CMPI_RC_OK) {
+ cu_statusf(_BROKER, s,
+ CMPI_RC_ERR_FAILED,
+ "Could not get connection.");
+ goto out;
+ }
+
+ rc = virConnectGetVersion(conn, &version);
+ CU_DEBUG("libvir : version=%ld, rc=%d", version, rc);
+ if (rc != 0) {
+ cu_statusf(_BROKER, s,
+ CMPI_RC_ERR_FAILED,
+ "Could not get xen version.");
+ goto out;
+ }
+
+ if (version >= 3001000)
+ num_nics = 8;
+ else
+ num_nics = 4;
+
+ out:
+ virConnectClose(conn);
+ return num_nics;
}
static struct sdc_rasd_prop *net_max(const CMPIObjectPath *ref,
CMPIStatus *s)
{
bool ret;
+ char *prefix;
uint16_t num_nics;
struct sdc_rasd_prop *rasd = NULL;
- /* TODO: relevant functions for KVM etc. and dispatch code. */
- num_nics = net_max_xen(ref, s);
+ prefix = class_prefix_name(CLASSNAME(ref));
+ if (prefix == NULL) {
+ cu_statusf(_BROKER, s,
+ CMPI_RC_ERR_FAILED,
+ "Could not get prefix from reference.");
+ goto out;
+ }
+
+ if (STREQC(prefix, "Xen")) {
+ num_nics = net_max_xen(ref, s);
+ } else if (STREQC(prefix, "KVM")) {
+ num_nics = net_max_kvm(ref, s);
+ } else {
+ cu_statusf(_BROKER, s,
+ CMPI_RC_ERR_NOT_SUPPORTED,
+ "Unsupported hypervisor: '%s'", prefix);
+ goto out;
+ }
+
+
if (s->rc != CMPI_RC_OK) {
- goto out;
cu_statusf(_BROKER, s,
CMPI_RC_ERR_FAILED,
"Could not get max nic count");
+ goto out;
}
struct sdc_rasd_prop tmp[] = {
@@ -368,6 +421,7 @@ static struct sdc_rasd_prop *net_max(con
"Could not copy RASD.");
}
out:
+ free(prefix);
return rasd;
}
Show replies by date
JG> # HG changeset patch
JG> # User Jay Gagnon <grendel(a)linux.vnet.ibm.com>
JG> # Date 1195070622 18000
JG> # Node ID cf3c1b32e71d9a95b3c95ebf3f3622bd39a4a4e3
JG> # Parent 1828b3b30fe476fbae1bf31d99c999ba548911f5
JG> Make net_max callback smarter.
JG> Xen 3.0.x supports up to 4
JG> Xen 3.1.x supports up to 8
JG> KVM supports up to 32
If there is no way to determine what the current implementation
supports via libvirt, I'm inclined to say that we should advertise the
maximum as something that is likely to be sane for most installations,
since it isn't an enforced limit. Right now, 8 is hardcoded in vl.c.
What about putting the Xen (>3.1.0) and QEMU limits in configure and
#include<config.h> here to get the values? That way, we can set them
there but make them easily overridable in the case that someone is
building the package to run against a modified Xen or QEMU.
I'll commit this and cook up a patch for discussion.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com
Dan Smith wrote:
JG> # HG changeset patch
JG> # User Jay Gagnon <grendel(a)linux.vnet.ibm.com>
JG> # Date 1195070622 18000
JG> # Node ID cf3c1b32e71d9a95b3c95ebf3f3622bd39a4a4e3
JG> # Parent 1828b3b30fe476fbae1bf31d99c999ba548911f5
JG> Make net_max callback smarter.
JG> Xen 3.0.x supports up to 4
JG> Xen 3.1.x supports up to 8
JG> KVM supports up to 32
If there is no way to determine what the current implementation
supports via libvirt, I'm inclined to say that we should advertise the
maximum as something that is likely to be sane for most installations,
since it isn't an enforced limit. Right now, 8 is hardcoded in vl.c.
What about putting the Xen (>3.1.0) and QEMU limits in configure and
#include<config.h> here to get the values? That way, we can set them
there but make them easily overridable in the case that someone is
building the package to run against a modified Xen or QEMU.
I'll commit this and cook up a patch for discussion.
Okay, that's fine.
--
-Jay