[Kimchi-devel] [PATCH V3 0/3] bug fix: get user and group when VM is running

Aline Manera alinefm at linux.vnet.ibm.com
Wed Apr 23 16:25:45 UTC 2014


On 04/23/2014 12:21 AM, Royce Lv wrote:
> On 2014?04?23? 00:59, Aline Manera wrote:
>> On 04/22/2014 12:59 AM, shaohef at linux.vnet.ibm.com wrote:
>>> From: ShaoHe Feng<shaohef at linux.vnet.ibm.com>
>>>
>>> V2 -> V3:
>>> move the virDomain.metadata and virDomain.setMetadata to model/utils.py
>>> add testcase
>>>
>>> V1 -> V2:
>>> libvirt also support virDomain.metadata and virDomain.setMetadata two api.
>>> use virDomain.metadata to get the user and group.
>>> use virDomain.setMetadata to set the user and group.
>>>
>>> ShaoHe Feng (3):
>>>    Add two function to set and get domain xml metadata
>>>    bug fix: get user and group when vm is living.
>>>    update test case to set/get user and group when VM is running
>>>
>>>   src/kimchi/i18n.py        |  1 +
>>>   src/kimchi/model/utils.py | 41 ++++++++++++++++++++++++++++++
>>>   src/kimchi/model/vms.py   | 65 +++++++++++++++++++++++------------------------
>>>   tests/test_model.py       | 13 ++++++++++
>>>   4 files changed, 87 insertions(+), 33 deletions(-)
>>>
>> As I commented in previous version, virDomain.metadata and 
>> virDomain.setMetadata does not work
>> well in all libvirt versions
>>
>> ----------------------------------------
>>
>> During the first development, I noticed the virDomain.metadata and 
>> virDomain.setMetadata does not work
>> well in all libvirt versions.
>>
>> While using those functions, some libvirt versions will report:
>>
>> libvir: QEMU Driver error : argument unsupported: QEMU driver does 
>> not support<metadata> element
>>
>> But if you manually get and set metadata element, libvirt works fine.
>>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> I went through libvirt log I find:
>
> commit 21d13ddc5d2e1ba24fec401fd7aec0f33f0fecf0
> Author: Peter Krempa <pkrempa at redhat.com>
> Date:   Wed Feb 1 14:03:52 2012 +0100
>
>     qemu: Add support for virDomainGetMetadata and virDomainSetMetadata
>
> And in this patch:
>
> +    if (flags & VIR_DOMAIN_AFFECT_CONFIG) {
> +        switch ((virDomainMetadataType) type) {
> +        case VIR_DOMAIN_METADATA_DESCRIPTION:
> +            VIR_FREE(persistentDef->description);
> +            if (metadata &&
> +                !(persistentDef->description = strdup(metadata)))
> +                goto no_memory;
> +            break;
> +        case VIR_DOMAIN_METADATA_TITLE:
> +            VIR_FREE(persistentDef->title);
> +            if (metadata &&
> +                !(persistentDef->title = strdup(metadata)))
> +                goto no_memory;
> +            break;
> +        case VIR_DOMAIN_METADATA_ELEMENT:
> +            qemuReportError(VIR_ERR_ARGUMENT_UNSUPPORTED, "%s",
> +                            _("QEMU driver does not support"
> +                              "<metadata> element"));
> +            goto cleanup;
>
> So in first version METADATA_ELEMENT is not supported for set and get, 
> and late after release 1.1.2 released(my ubuntu 13.10 is 
> 1.1.1-0ubuntu8.5), metadata_element is handled:
>
> commit ac38bff077642daa17f9a82480062ebef4c11a7b
> Author: Peter Krempa <pkrempa at redhat.com>
> Date:   Fri Sep 6 17:34:43 2013 +0200
>
>     conf: Add support for requesting of XML metadata via the API
>
> So instead of using VIR_DOMAIN_METADATA_ELEMENT, I guess we can use 
> metadata_description, so that we can set this in live time, or we can 
> do as Aline did as a workaround until release 1.1.2 is on all of our 
> supported version?
>
> What do your say?
>

Good investigation, Royce!

VIR_DOMAIN_METADATA_DESCRIPTION handles the <description> tag and 
VIR_DOMAIN_METADATA_TITLE handles the <title> tag

So I don't think we can use it for our proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140423/e2a9ee37/attachment.html>


More information about the Kimchi-devel mailing list