[PATCH] Hang a default VSSD off of the VSMC to mirror the AC RASD behavior
# HG changeset patch # User Dan Smith <danms@us.ibm.com> # Date 1208378296 25200 # Node ID 00dc567c364daeeebc40888742516dc1dcd2b106 # Parent f7e2c322ac0ab1d109192a362d508ca4a2a87310 Hang a default VSSD off of the VSMC to mirror the AC RASD behavior Signed-off-by: Dan Smith <danms@us.ibm.com> diff -r f7e2c322ac0a -r 00dc567c364d src/Virt_SettingsDefineCapabilities.c --- a/src/Virt_SettingsDefineCapabilities.c Wed Apr 16 11:08:13 2008 -0700 +++ b/src/Virt_SettingsDefineCapabilities.c Wed Apr 16 13:38:16 2008 -0700 @@ -55,6 +55,176 @@ const static CMPIBroker *_BROKER; #define SDC_DISK_INC 250 #define DEFAULT_MAC_PREFIX "00:16:3e" + +static bool system_has_vt(virConnectPtr conn) +{ + char *caps = NULL; + bool vt = false; + + caps = virConnectGetCapabilities(conn); + if (caps != NULL) + vt = (strstr(caps, "hvm") != NULL); + + free(caps); + + return vt; +} + +static CMPIInstance *_xen_base_vssd(virConnectPtr conn, + const char *ns, + const char *name) +{ + CMPIInstance *inst; + + inst = get_typed_instance(_BROKER, + pfx_from_conn(conn), + "VirtualSystemSettingData", + ns); + if (inst == NULL) + return NULL; + + CMSetProperty(inst, "VirtualSystemIdentifier", + (CMPIValue *)name, CMPI_chars); + + return inst; +} + +static CMPIStatus _xen_vsmc_to_vssd(virConnectPtr conn, + const char *ns, + struct inst_list *list) +{ + CMPIStatus s = {CMPI_RC_OK, NULL}; + CMPIInstance *inst; + int isfv = 0; + + inst = _xen_base_vssd(conn, ns, "Xen_Paravirt_Guest"); + if (inst == NULL) + goto error; + + CMSetProperty(inst, "Bootloader", + (CMPIValue *)"/usr/bin/pygrub", CMPI_chars); + + CMSetProperty(inst, "isFullVirt", + (CMPIValue *)&isfv, CMPI_boolean); + + inst_list_add(list, inst); + + if (system_has_vt(conn)) { + isfv = 1; + + inst = _xen_base_vssd(conn, ns, "Xen_Fullvirt_Guest"); + if (inst == NULL) + goto error; + + CMSetProperty(inst, "BootDevice", + (CMPIValue *)"hda", CMPI_chars); + + CMSetProperty(inst, "isFullVirt", + (CMPIValue *)&isfv, CMPI_boolean); + + inst_list_add(list, inst); + } + + return s; + + error: + cu_statusf(_BROKER, &s, + CMPI_RC_ERR_FAILED, + "Unable to create %s_VSSD instance", + pfx_from_conn(conn)); + + return s; +} + +static CMPIStatus _kvm_vsmc_to_vssd(virConnectPtr conn, + const char *ns, + struct inst_list *list) +{ + CMPIStatus s = {CMPI_RC_OK, NULL}; + CMPIInstance *inst; + + inst = get_typed_instance(_BROKER, + pfx_from_conn(conn), + "VirtualSystemSettingData", + ns); + if (inst == NULL) { + cu_statusf(_BROKER, &s, + CMPI_RC_ERR_FAILED, + "Unable to create %s_VSSD instance", + pfx_from_conn(conn)); + goto out; + } + + CMSetProperty(inst, "VirtualSystemIdentifier", + (CMPIValue *)"KVM_guest", CMPI_chars); + + CMSetProperty(inst, "BootDevice", + (CMPIValue *)"hda", CMPI_chars); + + inst_list_add(list, inst); + out: + return s; +} + +static CMPIStatus _lxc_vsmc_to_vssd(virConnectPtr conn, + const char *ns, + struct inst_list *list) +{ + CMPIStatus s = {CMPI_RC_OK, NULL}; + CMPIInstance *inst; + + inst = get_typed_instance(_BROKER, + pfx_from_conn(conn), + "VirtualSystemSettingData", + ns); + if (inst == NULL) { + cu_statusf(_BROKER, &s, + CMPI_RC_ERR_FAILED, + "Unable to create %s_VSSD instance", + pfx_from_conn(conn)); + goto out; + } + + CMSetProperty(inst, "InitPath", + (CMPIValue *)"/sbin/init", CMPI_chars); + + inst_list_add(list, inst); + out: + return s; +} + +static CMPIStatus vsmc_to_vssd(const CMPIObjectPath *ref, + struct std_assoc_info *info, + struct inst_list *list) +{ + CMPIStatus s; + virConnectPtr conn = NULL; + const char *cn; + const char *ns; + + cn = CLASSNAME(ref); + ns = NAMESPACE(ref); + + conn = connect_by_classname(_BROKER, cn, &s); + if (conn == NULL) + goto out; + + if (STARTS_WITH(cn, "Xen")) + s = _xen_vsmc_to_vssd(conn, ns, list); + else if (STARTS_WITH(cn, "KVM")) + s = _kvm_vsmc_to_vssd(conn, ns, list); + else if (STARTS_WITH(cn, "LXC")) + s = _lxc_vsmc_to_vssd(conn, ns, list); + else + cu_statusf(_BROKER, &s, + CMPI_RC_ERR_FAILED, + "Invalid reference"); + + out: + virConnectClose(conn); + + return s; +} static bool rasd_prop_copy_value(struct sdc_rasd_prop src, struct sdc_rasd_prop *dest) @@ -1008,11 +1178,39 @@ static struct std_assoc _vsmsd_to_migrat .make_ref = make_ref }; +static char *vsmc[] = { + "Xen_VirtualSystemManagementCapabilities", + "KVM_VirtualSystemManagementCapabilities", + "LXC_VirtualSystemManagementCapabilities", + NULL +}; + +static char *vssd[] = { + "Xen_VirtualSystemSettingData", + "KVM_VirtualSystemSettingData", + "LXC_VirtualSystemSettingData", + NULL +}; + +static struct std_assoc _vsmc_to_vssd = { + .source_class = (char**)&vsmc, + .source_prop = "GroupComponent", + + .target_class = (char**)&vssd, + .target_prop = "PartComponent", + + .assoc_class = (char**)&assoc_classname, + + .handler = vsmc_to_vssd, + .make_ref = make_ref +}; + static struct std_assoc *assoc_handlers[] = { &_alloc_cap_to_rasd, &_rasd_to_alloc_cap, &_migrate_cap_to_vsmsd, &_vsmsd_to_migrate_cap, + &_vsmc_to_vssd, NULL };
Dan Smith wrote:
# HG changeset patch # User Dan Smith <danms@us.ibm.com> # Date 1208378296 25200 # Node ID 00dc567c364daeeebc40888742516dc1dcd2b106 # Parent f7e2c322ac0ab1d109192a362d508ca4a2a87310 Hang a default VSSD off of the VSMC to mirror the AC RASD behavior
Signed-off-by: Dan Smith <danms@us.ibm.com>
You don't set the InstanceID. I'm having trouble thinking of a scenario where you need the InstanceID in the case. However, since it's a key value, it doesn't feel right omitting it. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
KR> You don't set the InstanceID. I'm having trouble thinking of a KR> scenario where you need the InstanceID in the case. However, KR> since it's a key value, it doesn't feel right omitting it. Yeah, you know, I did that on purpose. However, after some pondering and a little consultation, I think you're right. I'd propose that we set InstanceID to something like "TEMPORARY". This will be both (a) invalid for use in any other VSSD capacity, and (b) will indicate to a human looking at it that it's a transient placeholder. Perhaps we should go a step further and add some randomness to the end to make it unique, per the rules. The template RASDs should probably be updated with the same behavior. Thoughts? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
KR> You don't set the InstanceID. I'm having trouble thinking of a KR> scenario where you need the InstanceID in the case. However, KR> since it's a key value, it doesn't feel right omitting it.
Yeah, you know, I did that on purpose. However, after some pondering and a little consultation, I think you're right. I'd propose that we set InstanceID to something like "TEMPORARY". This will be both (a) invalid for use in any other VSSD capacity, and (b) will indicate to a human looking at it that it's a transient placeholder. Perhaps we should go a step further and add some randomness to the end to make it unique, per the rules. The template RASDs should probably be updated with the same behavior.
Thoughts?
Adding randomness to the name is a good one. Someone could create a guest with the name TEMPORARY, but if you through some randomness in for good measure, it's unlikely that the InstanceID will collide with the name of a guest. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
KR> Adding randomness to the name is a good one. Someone could create KR> a guest with the name TEMPORARY, but if you through some KR> randomness in for good measure, it's unlikely that the InstanceID KR> will collide with the name of a guest. In that case, their InstanceID would be "Xen:TEMPORARY" or similar, so I don't think that's a problem anyway. However, if a client depends on the VSSD's InstanceID being unique for hashing or something else, then two template VSSDs with the same InstanceID could cause a problem. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com
Dan Smith wrote:
KR> Adding randomness to the name is a good one. Someone could create KR> a guest with the name TEMPORARY, but if you through some KR> randomness in for good measure, it's unlikely that the InstanceID KR> will collide with the name of a guest.
In that case, their InstanceID would be "Xen:TEMPORARY" or similar, so
Oops - yes, I forgot we prefix the guest name with the virt type.
I don't think that's a problem anyway. However, if a client depends on the VSSD's InstanceID being unique for hashing or something else, then two template VSSDs with the same InstanceID could cause a problem.
True. I can't think of an example where this would be needed, but it's best to avoid a collision if possible. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
participants (2)
-
Dan Smith -
Kaitlin Rupert