- CIM - libvirt List Archives

[PATCH 0 of 6] Add migration support
by Dan Smith 05 Dec '07

05 Dec '07

This patch set adds preliminary migration support based on the current Virtual System Migration Profile. It's not quite done yet, but it does actually migrate VMs (tested with Xen). Still needing to be done are: - MigrationSettingData (perhaps to include ssh/TLS flag?) - Something for IsMigratable methods - Job support - Indication support

4 15

[PATCH] [RFC] make_ref() of associations
by Heidi Eckhart 05 Dec '07

05 Dec '07

# HG changeset patch # User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com> # Date 1196686834 -3600 # Node ID bea3e027d42ff41fc452935427981739bab76573 # Parent a1582d092f517919470b9ce7ff034b89e4b2bade [RFC] make_ref() of associations While thinking about the implementation of make_ref() and about my proposal to base the asscociation's instance creation on a connect_by_classname, I came to the conclusion that opening a connection to libvirt for not using it, is overkill for this method. Once make_ref() gets called by the std_association logic, the provider can rely on that the prefix of the given reference was checked for the right hypervisor prefix. So I suggest to update all make_ref() functions to use get_typed_instance(). ... and refix some of my fixes :0. Besides that I suggest to rename some of the variables in make_ref() to make the relations clearer. Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com> diff -r a1582d092f51 -r bea3e027d42f src/Virt_ElementAllocatedFromPool.c --- a/src/Virt_ElementAllocatedFromPool.c Mon Dec 03 13:49:01 2007 +0100 +++ b/src/Virt_ElementAllocatedFromPool.c Mon Dec 03 14:00:34 2007 +0100 @@ -241,27 +241,27 @@ static CMPIStatus pool_to_vdev(const CMP return s; } -static CMPIInstance *make_ref(const CMPIObjectPath *ref, - const CMPIInstance *inst, +static CMPIInstance *make_ref(const CMPIObjectPath *source_op, + const CMPIInstance *target_inst, struct std_assoc_info *info, struct std_assoc *assoc) { - CMPIInstance *refinst = NULL; - - refinst = get_typed_instance(_BROKER, - CLASSNAME(ref), - "ElementAllocatedFromPool", - NAMESPACE(ref)); - - if (refinst != NULL) { - CMPIObjectPath *instop; - - instop = CMGetObjectPath(inst, NULL); - - set_reference(assoc, refinst, ref, instop); - } - - return refinst; + CMPIInstance *assoc_inst = NULL; + + assoc_inst = get_typed_instance(_BROKER, + CLASSNAME(source_op), + "ElementAllocatedFromPool", + NAMESPACE(source_op)); + + if (assoc_inst != NULL) { + CMPIObjectPath *target_op; + + target_op = CMGetObjectPath(target_inst, NULL); + + set_reference(assoc, assoc_inst, source_op, target_op); + } + + return assoc_inst; } char* antecedent[] = {

3 4

[PATCH] [RFC] variable renaming in make_ref() of associations
by Heidi Eckhart 05 Dec '07

05 Dec '07

# HG changeset patch # User Heidi Eckhart <heidieck(a)linux.vnet.ibm.com> # Date 1196855770 -3600 # Node ID b49cfc1c6e9c3e4669bceea2f518f6c4f8bf3f82 # Parent 012fc8655c2b443511ba536ef2b425ac86f69f7b [RFC] variable renaming in make_ref() of associations Suggestion to rename some of the variables in make_ref() to make the relations clearer. Signed-off-by: Heidi Eckhart <heidieck(a)linux.vnet.ibm.com> diff -r 012fc8655c2b -r b49cfc1c6e9c src/Virt_ElementAllocatedFromPool.c --- a/src/Virt_ElementAllocatedFromPool.c Wed Dec 05 12:49:18 2007 +0100 +++ b/src/Virt_ElementAllocatedFromPool.c Wed Dec 05 12:56:10 2007 +0100 @@ -247,27 +247,27 @@ static CMPIStatus pool_to_vdev(const CMP return s; } -static CMPIInstance *make_ref(const CMPIObjectPath *ref, - const CMPIInstance *inst, +static CMPIInstance *make_ref(const CMPIObjectPath *source_ref, + const CMPIInstance *target_inst, struct std_assoc_info *info, struct std_assoc *assoc) { - CMPIInstance *refinst = NULL; - - refinst = get_typed_instance(_BROKER, - CLASSNAME(ref), - "ElementAllocatedFromPool", - NAMESPACE(ref)); - - if (refinst != NULL) { - CMPIObjectPath *instop; - - instop = CMGetObjectPath(inst, NULL); - - set_reference(assoc, refinst, ref, instop); - } - - return refinst; + CMPIInstance *ref_inst = NULL; + + ref_inst = get_typed_instance(_BROKER, + CLASSNAME(source_ref), + "ElementAllocatedFromPool", + NAMESPACE(source_ref)); + + if (ref_inst != NULL) { + CMPIObjectPath *target_ref; + + target_ref = CMGetObjectPath(target_inst, NULL); + + set_reference(assoc, ref_inst, source_ref, target_ref); + } + + return ref_inst; } char* antecedent[] = {

1 1

[PATCH] VSMC returns extra instances - add connect_by_classname
by Kaitlin Rupert 05 Dec '07

05 Dec '07

# HG changeset patch # User Kaitlin Rupert <karupert(a)us.ibm.com> # Date 1196809769 28800 # Node ID f83fe9e0ad3648502dcc52eabdb8ebc2c6baf046 # Parent e9e11611dc975a72237a9653b0a4a07ab9b4b4e1 VSMC returns extra instances - add connect_by_classname. VSMC is returning an instance for both KVM and Xen, when only a Xen instance should be returned. Test query: wbemcli ein http://localhost/root/virt:CIM_VirtualSystemManagementCapabilities Signed-off-by: Kaitlin Rupert <karupert(a)us.ibm.com> diff -r e9e11611dc97 -r f83fe9e0ad36 src/Virt_VirtualSystemManagementCapabilities.c --- a/src/Virt_VirtualSystemManagementCapabilities.c Tue Dec 04 09:10:36 2007 -0800 +++ b/src/Virt_VirtualSystemManagementCapabilities.c Tue Dec 04 15:09:29 2007 -0800 @@ -128,6 +128,11 @@ static CMPIStatus return_vsm_cap(const C { CMPIStatus s = {CMPI_RC_OK, NULL}; CMPIInstance *inst = NULL; + virConnectPtr conn = NULL; + + conn = connect_by_classname(_BROKER, CLASSNAME(ref), &s); + if (conn == NULL) + goto out; s = get_vsm_cap(_BROKER, ref, &inst); if (s.rc != CMPI_RC_OK) @@ -138,6 +143,8 @@ static CMPIStatus return_vsm_cap(const C else CMReturnInstance(results, inst); out: + virConnectClose(conn); + return s; }

2 2

[PATCH] Fix typos for disk & network classes in SDC SD & EAFP
by lizg＠cn.ibm.com 05 Dec '07

05 Dec '07

# HG changeset patch # User Zhengang Li <lizg(a)cn.ibm.com> # Date 1196763876 -28800 # Node ID 7dbad83883a3f5eaeedac4e415a97fb459ec50e5 # Parent 7fd4f296b8cc328a7492a24c731d8722bc485452 Fix typos for disk & network classes in SDC SD & EAFP *_LogicalDisk & *_NetworkPort classes are typo-ed as *_Disk & *_Network in several assoc classes' handler param. This leads to some assoc failure. Signed-off-by: Zhengang Li <lizg(a)cn.ibm.com> diff -r 7fd4f296b8cc -r 7dbad83883a3 src/Virt_ElementAllocatedFromPool.c --- a/src/Virt_ElementAllocatedFromPool.c Mon Dec 03 13:35:16 2007 +0100 +++ b/src/Virt_ElementAllocatedFromPool.c Tue Dec 04 18:24:36 2007 +0800 @@ -279,12 +279,12 @@ char* dependent[] = { char* dependent[] = { "Xen_Processor", "Xen_Memory", - "Xen_Network", - "Xen_Disk", + "Xen_NetworkPort", + "Xen_LogicalDisk", "KVM_Processor", "KVM_Memory", - "KVM_Network", - "KVM_Disk", + "KVM_NetworkPort", + "KVM_LogicalDisk", NULL }; diff -r 7fd4f296b8cc -r 7dbad83883a3 src/Virt_SettingsDefineState.c --- a/src/Virt_SettingsDefineState.c Mon Dec 03 13:35:16 2007 +0100 +++ b/src/Virt_SettingsDefineState.c Tue Dec 04 18:24:36 2007 +0800 @@ -304,12 +304,12 @@ char* logical_device[] = { char* logical_device[] = { "Xen_Processor", "Xen_Memory", - "Xen_Network", - "Xen_Disk", + "Xen_NetworkPort", + "Xen_LogicalDisk", "KVM_Processor", "KVM_Memory", - "KVM_Network", - "KVM_Disk", + "KVM_NetworkPort", + "KVM_LogicalDisk", NULL }; diff -r 7fd4f296b8cc -r 7dbad83883a3 src/Virt_SystemDevice.c --- a/src/Virt_SystemDevice.c Mon Dec 03 13:35:16 2007 +0100 +++ b/src/Virt_SystemDevice.c Tue Dec 04 18:24:36 2007 +0800 @@ -241,12 +241,12 @@ char* part_component[] = { char* part_component[] = { "Xen_Processor", "Xen_Memory", - "Xen_Network", - "Xen_Disk", + "Xen_NetworkPort", + "Xen_LogicalDisk", "KVM_Processor", "KVM_Memory", - "KVM_Network", - "KVM_Disk", + "KVM_NetworkPort", + "KVM_LogicalDisk", NULL };

5 4

[PATCH 0 of 2] #2 Remove devid-style InstanceID support from ELEC and EC.
by Kaitlin Rupert 04 Dec '07

04 Dec '07

Removed devid-style InstanceID support from ELEC - this class now uses just the name of domain. This caused a needed update in EC - cap_to_cs() no longer needs to parse devid-style InstanceIDs. Updates: None This is acutally just a resend. Heidi suggested to add connect_by_classname() to return_vsm_cap() in VSMC. However, since this patchset doesn't address changes in VSMC, I'll be sending the VSMC change as a seperate patch.

1 2

[PATCH] SD doesn't return instances in all cases
by Kaitlin Rupert 04 Dec '07

04 Dec '07

# HG changeset patch # User Kaitlin Rupert <karupert(a)us.ibm.com> # Date 1196460977 28800 # Node ID 1776beb36f5cffcfad4e581a8841f77f20bc3927 # Parent d5af3e219c22e8b32de64c69a29aea970ab6a9a4 SD doesn't return instances in all cases. Virt_SystemDevice doesn't return instances when CIM_ManagedElement is passed as a result class argument. This only applies to the VM to device case (see failint query below). The problem is that we use the result class to determine which device type to return. If no result class is specified, we return all associated devices. However, if CIM_ManagedElement is specified, we are unable to match the device type, and we return nothing. I think all of this can be removed because filter_results() in libcmpiutil should remove the need for this kind of checking. Failing query: wbemcli ain -ac Xen_SystemDevice -arc CIM_ManagedElement 'http://root:elm3b41@localhost/root/virt:Xen_ComputerSystem.CreationClassNam…"Xen_ComputerSystem",Name="Domain-0"' Signed-off-by: Kaitlin Rupert <karupert(a)us.ibm.com> diff -r d5af3e219c22 -r 1776beb36f5c src/Virt_SystemDevice.c --- a/src/Virt_SystemDevice.c Fri Nov 30 11:33:21 2007 -0800 +++ b/src/Virt_SystemDevice.c Fri Nov 30 14:16:17 2007 -0800 @@ -171,22 +171,10 @@ static CMPIStatus sys_to_dev(const CMPIO goto out; } - if (info->result_class) { - int type; - - type = device_type_from_classname(info->result_class); - - ret = get_dom_devices(host, - list, - type, - CLASSNAME(ref), - NAMESPACE(ref)); - } else { - ret = get_all_devices(host, - list, - CLASSNAME(ref), - NAMESPACE(ref)); - } + ret = get_all_devices(host, + list, + CLASSNAME(ref), + NAMESPACE(ref)); if (ret >= 0) { CMSetStatus(&s, CMPI_RC_OK);

3 3

[PATCH] Add patching guidelines to site
by Jay Gagnon 04 Dec '07

04 Dec '07

# HG changeset patch # User Jay Gagnon <grendel(a)linux.vnet.ibm.com> # Date 1196783327 18000 # Node ID 1a3e2e6e3ec15d8f600eb21477e18b6a48ccb2df # Parent d182b5a3324feb2d8403d995f8208f8e0057aa6d Add patching guidelines to site. Signed-off-by: Jay Gagnon <grendel(a)linux.vnet.ibm.com> diff -r d182b5a3324f -r 1a3e2e6e3ec1 doc/Makefile.am --- a/doc/Makefile.am Mon Dec 03 11:22:46 2007 -0500 +++ b/doc/Makefile.am Tue Dec 04 10:48:47 2007 -0500 @@ -5,6 +5,7 @@ WEB_PAGES = index.html \ downloads.html \ intro.html \ news.html \ + patches.html \ platforms.html \ schema.html diff -r d182b5a3324f -r 1a3e2e6e3ec1 doc/libvirt-cim.html --- a/doc/libvirt-cim.html Mon Dec 03 11:22:46 2007 -0500 +++ b/doc/libvirt-cim.html Tue Dec 04 10:48:47 2007 -0500 @@ -57,6 +57,183 @@ <a href="http://libvirt.org/hg/libvirt-cim/archive/tip.tar.gz">tarball</a> or <a href="http://libvirt.org/hg/libvirt-cim/archive/tip.zip">zip</a> file snapshot of the repository. +</p> + +<h2><a name="Patches">Patches</a></h2> + +<p>To submit patches to libvirt-cim, you must follow the DCO process, outlined +below:</p> + +<h3>Developer's Certificate of Origin 1.1</h3> +<p>By making a contribution to this project, I certify that:</p> +<ol> +<li> + <p> + The contribution was created in whole or in part by me and I + have the right to submit it under the open source license indicated in + the file; or + </p> +</li> +<li> + <p> + The contribution is based upon previous work that, to the best of my + knowledge, is covered under an appropriate open source license and I have the + right under that license to submit that work with modifications, whether + created in whole or in part by me, under the same open source license + (unless I am permitted to submit under a different license), as indicated in + the file; or + </p> +</li> +<li> + <p> + The contribution was provided directly to me by some other person who + certified (1), (2) or (3) and I have not modified it. + </p> +</li> +<li> + <p> + I understand and agree that this project and the contribution are public and + that a record of the contribution (including all personal information I + submit with it, including my sign-off) is maintained indefinitely and may be + redistributed consistent with this project or the open source license(s) + involved. + </p> +</li> +</ol> + +<p>then you just add a line saying</p> + +<p style="text-align:center"> + Signed-off-by: Random J Developer <random(a)developer.example.org> +</p> + +<p>using your real name (sorry, no pseudonyms or anonymous contributions.)</p> + +<h3>Guidelines for Submitting Patches.</h3> +<p> + Patches should be submitted using Mercurial's patchbomb extension, and we + recommend using the queues extension as well. On top of that, we have some + guidelines you should follow when submitting patches. This makes reviewing + patches easier, which in turns improves the chances of your patch being + accepted in a timely fashion. +</p> +<p> + For help on how to use the patchbomb extension, see + <a href="http://hgbook.red-bean.com/hgbookch14.html">Section 14.4</a> of <i> + Distributed revision control with Mercurial</i>. +</p> +<p> + For help on the queues extension, see + <a href="http://hgbook.red-bean.com/hgbookch12.html">Chapter 12</a>. +</p> + +<h4>Single Patches:</h4> +<ol> +<li> + <p> + When you add a patch to the queue you have an idea of where you're going with + it, and the commit message should reflect that. Be specific. Avoid just + saying something like, "Various fixes to AllocationCapabilities." Add a list + of what was actually fixed, like, "Add EnumInstanceNames support," and, + "Eliminate duplicate instances." +</p> +</li> +<li> + <p> + The first line of your commit message will be the subject of the patch email + when you send it out, so write it like a subject. Keep it short and to the + point, then start a new line and feel free to be as verbose as you need to + be. The entire commit message will be included in the patch. + </p> +</li> +<li> + <p> + Stay on task with a patch. If you notice other problems while you are + working on a patch, and they are not most definitely specific to your patch, + they should be another patch. The same goes for nitpicking. While it might + be only a line or two here and there that is off track, this is actually one + of the easiest ways to make a patch difficult to review. All the trivial + changes hide what is really going on. Make the unrelated changes a new + patch or don't make them at all. + </p> +</li> +<li> + <p> + If your patch addresses a strange issue or a rare edge case that the + reviewers are unlikely to be familiar with, make sure the commit message + include some example testcase with results, so the reviewers can verify + your patch more quickly. + </p> +</li> +<li> + <p> + Before you email, export. If you have a patch called "alloc_fixes", which + would be emailed with "hg email alloc_fixes", you should first run "hg export + alloc_fixes". This lets you review your patch. Does it have any typos in + the comments? Did you accidentally include an irrelevant change? Is your + commit message still accurate and useful? This is the single biggest step in + ensuring you have a good patch. + </p> +</li> +<li> + <p> + If your patch needs to be reworked and resent, prepend a "version number" to + the first line of the commit message. For example, "Add EnumInstance to + RASD," becomes "#2 Add EnumInstance to RASD." This helps mail readers thread + discussions correctly and helps maintainers know they are applying the right + version of your patch. At the end of the commit message, explain what is + different from one version to the next. Nobody likes having to diff a diff. + </p> +</li> +<li> + <p> + If your patch depends on a patch that exists on the mailing list but not in + the tree, it is okay to send your patch to the list as long as your commit + message mentions the dependency. It is also a good idea to import the + patch into your tree before you make your patch. For example, a new patch + called "cu_statusf API change" is on the list, and your patch needs the new + API. Save the email (no need to trim headers) as api_change.eml, then do + "hg qimport api_change.eml" and "hg qpush" so that the patch is applied to + your tree. Now write your patch on top of it. You should still indicate + the dependency in your commit message. +</li> +</ol> + +<h4>Patchsets:</h4> +<ol> +<li> + <p> + When you send a group of patches, Mercurial's email extension will create a + "header" email. Make the subject and body of that email meaningful, so we + know how the patches relate. It's easy to say, "Each patch has a commit + message, it's obvious how they work together," but the rest of the list + usually won't agree with that. If the commit messages for each patch are + good, you shouldn't need more than a sentence or two to tie them all + together, but you do need it. + </p> +</li> +<li> + <p> + If any of your patches are rejected and you rework them, resend the entire + set. This prevents things like, "So use patch 1 of 4 from the set I sent + yesterday, 2 and 3 of 4 from the patch I sent an hour later, and patch 4 + of 4 from today." + </p> +</li> +<li> + <p> + If you resend a patchset, apply part (6) of the Single Patches guidelines to + your "Patch [0 of 3]" header email, for all the same reasons. + </p> +</li> +</ol> + +<p>Questions/Comments on the Guidelines should be directed to:</p> +<p> + Jay Gagnon + <a href="mailto:grendel@linux.vnet.ibm.com">grendel(a)linux.vnet.ibm.com</a> + <br> + Patch Compliance Officer </p> <h2><a name="Schema">Schema</a></h2> diff -r d182b5a3324f -r 1a3e2e6e3ec1 doc/site.xsl --- a/doc/site.xsl Mon Dec 03 11:22:46 2007 -0500 +++ b/doc/site.xsl Tue Dec 04 10:48:47 2007 -0500 @@ -50,6 +50,9 @@ </xsl:when> <xsl:when test="$name = '#Schema'"> <xsl:text>schema.html</xsl:text> + </xsl:when> + <xsl:when test="$name = '#Patches'"> + <xsl:text>patches.html</xsl:text> </xsl:when> <xsl:when test="$name = ''"> <xsl:text>unknown.html</xsl:text>

2 3

[PATCH 0 of 9] Reorganized association provider registration
by Heidi Eckhart 04 Dec '07

04 Dec '07

The association provider was registered for each subclass with a different name. That caused duplicated instances as the same provider gets called twice, but has no chance to figure out for which registration. This patch set tries to fix it. Please review. Thanks. Based on: - #2 Fix (again) VSMCaps and ElementCap - Remove devid-style InstanceID support from ELEC and EC

3 17

Null of InstanceID in ein ResourcePoolConfigurationCapabilities
by daisy 03 Dec '07

03 Dec '07

Hi, I try to test VirtualSystemManagementCapabilities and get results as follows: "wbemcli ein http://root:password@localhost:5988/root/virt:Xen_ResourcePoolConfiguration…" localhost:5988/root/virt:Xen_ResourcePoolConfigurationCapabilities.InstanceID="" As a property of ResourcePoolConfigurationCapabilities, is InstanceID need to set in provider? Best, Regards Daisy Guo Lian Yun E-mail: yunguol(a)cn.ibm.com IBM China Development Lab, Shanghai, China TEL: (86)-21-61008057

2 1