RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1222795 - VIR_MIGRATE_PARAMs are not exposed
Summary: VIR_MIGRATE_PARAMs are not exposed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt-python
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jiri Denemark
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1229199
Blocks: 974510
TreeView+ depends on / blocked
 
Reported: 2015-05-19 07:50 UTC by Yeela Kaplan
Modified: 2016-02-02 22:40 UTC (History)
8 users (show)

Fixed In Version: libvirt-python-1.2.17-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1229199 (view as bug list)
Environment:
Last Closed: 2015-11-19 05:34:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
libvirt-api.xml for libvirt 1.2.17 (754.84 KB, application/xml)
2015-07-10 21:06 UTC, Jasper Lievisse Adriaanse
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2203 0 normal SHIPPED_LIVE libvirt-python bug fix and enhancement update 2015-11-19 08:17:48 UTC

Description Yeela Kaplan 2015-05-19 07:50:31 UTC
Description of problem:
Using migrateToURI3 requires giving to libvirt a dictionary of parameters,
where keys are libvirt's VIR_MIGRATE_PARAMs: 
which should be exposed by virDomain, but are not defined there.  

Version-Release number of selected component (if applicable):
libvirt-python-1.2.8-7.el7_1.1


Actual results:
Cannot use migrateToURI3 using the python bindings for libvirt

Comment 2 Michal Skrivanek 2015-05-28 08:28:17 UTC
Jiri, one more thing, feel free to open a separate bug or suggest a better solution.

oVirt supports a configuration of both VNC and SPICE displays (actually plan to prefer it) and in this case we should preserve the protocol on migration. But since the client can choose any of the protocols we are not really aware which is in use. It would be great if the protocol part of the uri is optional as well.
Any way how to do that?

Comment 3 Jiri Denemark 2015-06-05 07:47:02 UTC
I don't think it would make any difference anyway :-) While some parts of our code are general and seem to support both VNC and SPICE relocation, we really only support SPICE. Not to mention that we don't try to detect which graphics type is actually used. If no graphics URI is used, we just take the first SPICE graphics and relocate it. If graphics URI is used and it's SPICE, we relocate it. And that's it. If you need something more, please, file a BZ for it :-)

Comment 4 Jiri Denemark 2015-06-11 11:54:55 UTC
Fixed upstream by v1.2.16-3-gd3e2aff:

commit d3e2aff6a701480bf19bdfe748c1c6def2db0a50
Author: Jiri Denemark <jdenemar>
Date:   Fri Jun 5 10:17:53 2015 +0200

    Provide symbolic names for typed parameters
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1222795
    
    Signed-off-by: Jiri Denemark <jdenemar>

Comment 6 Jasper Lievisse Adriaanse 2015-07-10 19:19:16 UTC
This actually broke for me with libvirt and libvirt-python 1.2.17:

===>  Building for libvirt-python-1.2.17
running build
/usr/bin/pkg-config --print-errors --atleast-version=0.9.11 libvirt
/usr/local/bin/python2.7 generator.py libvirt /usr/local/share/libvirt/api/libvirt-api.xml
Traceback (most recent call last):
  File "generator.py", line 2126, in <module>
    if buildStubs(sys.argv[1], sys.argv[2]) < 0:
  File "generator.py", line 887, in buildStubs
    parser.feed(data)
  File "/usr/local/lib/python2.7/site-packages/_xmlplus/sax/expatreader.py", line 216, in feed
    self._parser.Parse(data, isFinal)
  File "/usr/local/lib/python2.7/site-packages/_xmlplus/sax/expatreader.py", line 312, in start_element
    self._cont_handler.startElement(name, AttributesImpl(attrs))
  File "generator.py", line 139, in start
    if "string" in attrs:
  File "/usr/local/lib/python2.7/site-packages/_xmlplus/sax/xmlreader.py", line 316, in __getitem__
    return self._attrs[name]
KeyError: 0

Reverting commit d3e2aff6a701480bf19bdfe748c1c6def2db0a50 and only this commit fixes it for me with python 2.7.10.

Comment 7 Jiri Denemark 2015-07-10 19:33:11 UTC
Hmm, what version of libvirt do you have installed in /usr/local? And could you attach /usr/local/share/libvirt/api/libvirt-api.xml to this bugzilla? Thanks.

Comment 8 Jasper Lievisse Adriaanse 2015-07-10 21:05:36 UTC
I have 1.2.17 installed; attached is the requested file.

Comment 9 Jasper Lievisse Adriaanse 2015-07-10 21:06:16 UTC
Created attachment 1050799 [details]
libvirt-api.xml for libvirt 1.2.17

Comment 10 Luyao Huang 2015-09-02 06:03:00 UTC
(In reply to Jasper Lievisse Adriaanse from comment #6)
> This actually broke for me with libvirt and libvirt-python 1.2.17:
> 
> ===>  Building for libvirt-python-1.2.17
> running build
> /usr/bin/pkg-config --print-errors --atleast-version=0.9.11 libvirt
> /usr/local/bin/python2.7 generator.py libvirt
> /usr/local/share/libvirt/api/libvirt-api.xml
> Traceback (most recent call last):
>   File "generator.py", line 2126, in <module>
>     if buildStubs(sys.argv[1], sys.argv[2]) < 0:
>   File "generator.py", line 887, in buildStubs
>     parser.feed(data)
>   File "/usr/local/lib/python2.7/site-packages/_xmlplus/sax/expatreader.py",
> line 216, in feed
>     self._parser.Parse(data, isFinal)
>   File "/usr/local/lib/python2.7/site-packages/_xmlplus/sax/expatreader.py",
> line 312, in start_element
>     self._cont_handler.startElement(name, AttributesImpl(attrs))
>   File "generator.py", line 139, in start
>     if "string" in attrs:
>   File "/usr/local/lib/python2.7/site-packages/_xmlplus/sax/xmlreader.py",
> line 316, in __getitem__
>     return self._attrs[name]
> KeyError: 0
> 
> Reverting commit d3e2aff6a701480bf19bdfe748c1c6def2db0a50 and only this
> commit fixes it for me with python 2.7.10.

I guess you install python-pyxml on your host:

I can reproduce this issue after install python-pyxml:

# /usr/bin/python2.7 generator.py libvirt /usr/share/libvirt/api/libvirt-api.xml
Traceback (most recent call last):
  File "generator.py", line 2126, in <module>
    if buildStubs(sys.argv[1], sys.argv[2]) < 0:
  File "generator.py", line 887, in buildStubs
    parser.feed(data)
  File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/expatreader.py", line 216, in feed
    self._parser.Parse(data, isFinal)
  File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/expatreader.py", line 312, in start_element
    self._cont_handler.startElement(name, AttributesImpl(attrs))
  File "generator.py", line 139, in start
    if "string" in attrs:
  File "/usr/lib64/python2.7/site-packages/_xmlplus/sax/xmlreader.py", line 316, in __getitem__
    return self._attrs[name]
KeyError: 0

This because there is no __contains__ in class AttributesImpl in _xmlplus/sax/expatreader.py, python will call __getitem__ here.

And i have sent a patch to upstream:

https://www.redhat.com/archives/libvir-list/2015-September/msg00024.html

Comment 11 Jasper Lievisse Adriaanse 2015-09-02 06:34:50 UTC
Hi,

That is correct, I do have python-pyxml installed and your proposed patch resolves the issue for me. Thanks!

Comment 12 Luyao Huang 2015-09-02 07:10:06 UTC
(In reply to Jasper Lievisse Adriaanse from comment #11)
> Hi,
> 
> That is correct, I do have python-pyxml installed and your proposed patch
> resolves the issue for me. Thanks!

You are welcome, and thanks for reporting this issue, i don't want leave any issue before verify this bug :-)

Comment 13 Luyao Huang 2015-09-08 09:41:40 UTC
Verify this bug with libvirt-1.2.17-8.el7.x86_64 and libvirt-python-1.2.17-2.el7.x86_64:

1. check the libvirt-domain.h:

# define VIR_MIGRATE_PARAM_URI               "migrate_uri"

# define VIR_MIGRATE_PARAM_DEST_NAME         "destination_name"

# define VIR_MIGRATE_PARAM_DEST_XML          "destination_xml"

# define VIR_MIGRATE_PARAM_BANDWIDTH         "bandwidth"

# define VIR_MIGRATE_PARAM_GRAPHICS_URI      "graphics_uri"

# define VIR_MIGRATE_PARAM_LISTEN_ADDRESS    "listen_address"

# define VIR_MIGRATE_PARAM_MIGRATE_DISKS    "migrate_disks"

2. check it in python:

# ipython
Python 2.7.5 (default, Aug  6 2015, 10:12:10) 
Type "copyright", "credits" or "license" for more information.

IPython 2.3.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import libvirt

...

In [6]: libvirt.VIR_MIGRATE_PARAM_URI
Out[6]: 'migrate_uri'

In [7]: libvirt.VIR_MIGRATE_PARAM_DEST_NAME
Out[7]: 'destination_name'

In [8]: libvirt.VIR_MIGRATE_PARAM_DEST_XML
Out[8]: 'destination_xml'

In [9]: libvirt.VIR_MIGRATE_PARAM_BANDWIDTH
Out[9]: 'bandwidth'

In [10]: libvirt.VIR_MIGRATE_PARAM_GRAPHICS_URI
Out[10]: 'graphics_uri'

In [11]: libvirt.VIR_MIGRATE_PARAM_LISTEN_ADDRESS
Out[11]: 'listen_address'

In [12]: libvirt.VIR_MIGRATE_PARAM_MIGRATE_DISKS
Out[12]: 'migrate_disks'

3. Then use this script to check other parameters:

# cat /tmp/test-macro.py
#!/usr/bin/env python

import libvirt
import lxml
import lxml.etree
import sys
import os

XML = "/usr/share/libvirt/api/libvirt-api.xml"
LIBVIRT_HEAD_PATH = "/usr/include/libvirt/"


def getstringmarcro(filename):
    ret = {}
    filec = open(filename)
    for line in filec:
        if "# define " in line:
            if len(line[9:].split(" ")) >= 2:
                if line[9:].split(" ")[-1].count("\"") == 2:
                    ret[line[9:].split(" ")[0]] = line[9:].split(" ")[-1][1:-2]

    return ret



if not os.access(XML, os.R_OK):
    print("can not open %s" % XML)
    sys.exit(1)

f = open(XML, "r")
tree = lxml.etree.parse(f)

set1 = tree.xpath("/api/files/file")
for i in set1:
    name1 = i.attrib['name']
    filename = ("%s%s.h" % (LIBVIRT_HEAD_PATH, name1))
    dict1 = getstringmarcro(filename)
    count = 0

    for (d, x) in dict1.items():
        tmpset = tree.xpath("/api/symbols/macro[@name='%s']" % d)
        if len(tmpset) == 0:
            print("macro named %s is not covered" % d)
            continue

        try:
            string = tmpset[0].attrib['string']
        except KeyError:
            print("macro named %s is not a string macro" % d)
            continue

        if string != x:
            print("macro %s's string is not equal : %s: %s %s: %s" % (d, XML, string, filename, x))
            continue
        else:
            count = count + 1

        """ check libvirt-python parameters """
        try:
            string_libvirt = getattr(libvirt, d)
        except AttributeError:
            print("macro named %s cannot found in libvirt python" % d)
            continue

        if string_libvirt != x:
            print("macro %s's string is not equal : libvirt-python: %s %s: %s" % (d, string_libvirt, filename, x))


    print("found %d string marcos in %s, and %d string marcos in %s" % (len(dict1), filename, count, XML))

sys.exit(0)

4. run it:

# /usr/bin/python2.7 /tmp/test-macro.py
found 0 string marcos in /usr/include/libvirt/libvirt-domain-snapshot.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 111 string marcos in /usr/include/libvirt/libvirt-domain.h, and 111 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 0 string marcos in /usr/include/libvirt/libvirt-event.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 18 string marcos in /usr/include/libvirt/libvirt-host.h, and 18 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 0 string marcos in /usr/include/libvirt/libvirt-interface.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 0 string marcos in /usr/include/libvirt/libvirt-network.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 0 string marcos in /usr/include/libvirt/libvirt-nodedev.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 0 string marcos in /usr/include/libvirt/libvirt-nwfilter.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 0 string marcos in /usr/include/libvirt/libvirt-secret.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 0 string marcos in /usr/include/libvirt/libvirt-storage.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 0 string marcos in /usr/include/libvirt/libvirt-stream.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml
found 0 string marcos in /usr/include/libvirt/virterror.h, and 0 string marcos in /usr/share/libvirt/api/libvirt-api.xml

Comment 15 errata-xmlrpc 2015-11-19 05:34:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2203.html


Note You need to log in before you can comment on or make changes to this bug.