- Devel - libvirt List Archives

[libvirt] [PATCH] qemu: virConnectGetVersion returns bogus value
by Viktor Mihajlovski 28 Feb '13

28 Feb '13

The unitialized local variable qemuVersion can cause an random value to be returned for the hypervisor version, observable with virsh version. Introduced by commit b46f7f4a0b96c2d2d01d64d960bd7bc90dc16b0c Signed-off-by: Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com> --- src/qemu/qemu_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 0f6a431..825babd 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1382,7 +1382,7 @@ cleanup: static int qemuGetVersion(virConnectPtr conn, unsigned long *version) { virQEMUDriverPtr driver = conn->privateData; int ret = -1; - unsigned int qemuVersion; + unsigned int qemuVersion = 0; virCapsPtr caps = NULL; if (!(caps = virQEMUDriverGetCapabilities(driver, false))) -- 1.7.9.5

2 1

[libvirt] [PATCH 1/1] Remove contiguous CPU indexes assumption
by Li Zhang 28 Feb '13

28 Feb '13

From: Li Zhang <zhlcindy(a)linux.vnet.ibm.com> When getting CPUs' information, it assumes that CPU indexes are not contiguous. But for ppc64 platform, CPU indexes are not contiguous because SMT is needed to be disabled, so CPU information is not right on ppc64 and vpuinfo, vcpupin can't work corretly. This patch is to remove the assumption to be compatible with ppc64. Test: 4 vcpus are assigned to one VM and execute vcpuinfo command. Without patch: There is only one vcpu informaion can be listed. With patch: All vcpus' information can be listed correctly. Signed-off-by: Li Zhang <zhlcindy(a)linux.vnet.ibm.com> --- src/qemu/qemu_monitor_json.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index 9991a0a..e130f8c 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -1230,13 +1230,6 @@ qemuMonitorJSONExtractCPUInfo(virJSONValuePtr reply, goto cleanup; } - if (cpu != i) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("unexpected cpu index %d expecting %d"), - i, cpu); - goto cleanup; - } - threads[i] = thread; } -- 1.7.10.1

2 4

[libvirt] [PATCH 0/4] Add cpuset support for LXC
by Gao feng 28 Feb '13

28 Feb '13

This patchset intend to add cpuset support for LXC. in order to don't create too many redundant codes, this patchset also rename some functions. Gao feng (4): rename qemuGetNumadAdvice to virDomainGetNumadAdvice LXC: allow uses advisory nodeset from querying numad remove the redundant codes LXC: add cpuset support for lxc src/conf/domain_conf.c | 144 ++++++++++++++++++++++++++++++++++++++++++ src/conf/domain_conf.h | 4 ++ src/libvirt_private.syms | 3 +- src/lxc/lxc_cgroup.c | 58 ++++++++++++++++- src/lxc/lxc_cgroup.h | 2 +- src/lxc/lxc_controller.c | 117 +++++++++-------------------------- src/qemu/qemu_process.c | 158 ++--------------------------------------------- 7 files changed, 242 insertions(+), 244 deletions(-) -- 1.7.11.7

2 9

[libvirt] [PATCH] maint: fix typo in network docs
by Eric Blake 28 Feb '13

28 Feb '13

* docs/formatnetwork.html.in: Spell variation correctly. --- Pushing under the trivial rule. docs/formatnetwork.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index 41a83fa..4dd0415 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -780,7 +780,7 @@ </network></pre> <p> - Below is another IPv6 varition. Instead of a dhcp range being + Below is another IPv6 variation. Instead of a dhcp range being specified, this example has a couple of IPv6 host definitions. Note that most of the dhcp host definitions use an "id" (client id or DUID) since this has proven to be a more reliable way -- 1.8.1.2

1 0

[libvirt] Compile libvirt V1.0.1 error
by harryxiyou 28 Feb '13

28 Feb '13

Hi all, When i compiled libvirt like following 1. git clone git://libvirt.org/libvirt.git；cd libvirt 2. git reset --hard v1.0.1 3. wget http://cloudxy.googlecode.com/svn/branches/hlfs/person/harry/hlfs/patches/h… 4. wget http://cloudxy.googlecode.com/svn/branches/hlfs/person/harry/hlfs/patches/h… 5. git apply hlfs_driver_for_libvirt_network_disk.patch 6. git apply hlfs_driver_for_libvirt_add_classpath.patch 7. ./autogen.sh 8. ./configure 9. make i got following errors. [...] cc1: error: AVA_HOME/include: No such file or directory [-Werror] cc1: error: AVA_HOME/include/linux: No such file or directory [-Werror] cc1: all warnings being treated as errors make[3]: *** [libvirt_driver_storage_impl_la-storage_driver.lo] Error 1 make[3]: Leaving directory `/home/jiawei/workshop1/libvirt/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/jiawei/workshop1/libvirt/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jiawei/workshop1/libvirt' make: *** [all] Error 2 It seems that the errors have no relationship with HLFS(the patches i patched) but AVA_HOME. Could anyone give me some suggestions? Thanks in advance ;-) -- Thanks Harry Wei

2 4

Re: [libvirt] [Dnsmasq-discuss] Chaining instances?
by Laine Stump 28 Feb '13

28 Feb '13

This discussion should really be taking place on libvir-list - I'm Cc'ing it there. On 02/24/2013 04:11 PM, TJ wrote: > On 24/02/13 19:19, Laine Stump wrote: >> On 02/24/2013 05:09 AM, TJ wrote: >>> I wondered if maybe configuring the libvirtd dnsmasq instances to be dhcp proxies for the LAN dnsmasq, and use multiple dhcp-range's with tags might do it? >>> >>> My brain is a bit fried right now having had to fix several bugs in vmbuilder and libvirt, plus add new functionality to libvirtd to allow its dnsmasq instance to read a conf-file and use a separate log-facility, >> What you're talking about doing sounds *very* useful to have supported >> directly in libvirt, but you may want to contact libvirt's upstream >> developers (at libvir-list(a)redhat.com, or on irc.oftc.net in #virt) >> prior to expending a lot of effort on libvirt code - in general a >> problem may already be solved in a different manner, or somebody else >> may already be working on it. Failing that, there may have already been >> considerable debate on a particular subject, and a path to a solution >> generally agreed on, but with nobody yet working on the code. > It turns out that what I need(ed) to do was completely *disable* libvirt's use of dnsmasq > and instead use Simon's related "dhcp-helper" program which acts as a full dhcp-relay using, f.e: > > /usr/sbin/dhcp-helper -u libvirt-dnsmasq -i virbr1 -b eth0 > > This forwards all requests to the primary dnsmasq DHCP server on the LAN which matches against the > appropriate dhcp-range: > > # physical network leases > dhcp-range=set:phys,10.254.251.50,10.254.251.199,255.255.255.0,1440m > # subnet for VMs on server1 > dhcp-range=set:vmlan1,10.254.1.100,10.254.1.199,255.255.255.0,1440m > # default route (gateway) > dhcp-option=tag:phys,option:router,10.254.251.1 > dhcp-option=tag:vmlan1,option:router,10.254.1.1 > # DNS server > dhcp-option=6,10.254.251.1 > > > To that end this evening I added two additional options to libvirt: > > <dnsmasq enabled='true'/> > <dhcphelper enabled='false'/> libvirt's XML should remain implementation-agnostic. We don't want to have an option to disable the specific implementation of dns+dhcp called "dnsmasq"; rather we want to be able to enable/disable a network's dhcp server and/or dns server. (The reason for this is that we want to leave the door open for someone to implement a different backend using a different dhcp server and/or dns server and be able to use the same configuration.) We have actually previously discussed disabling dns and/or dhcp (see http://www.redhat.com/archives/libvir-list/2012-November/msg00861.html) It is already possible to completely disable dhcp - simply don't include a <dhcp> element in the network definition. As for dns, from the very beginning dns has been *always* enabled on all networks, so even though there is a <dns> element, simply having not having one is not a valid way to say "no dns server" (as it would cause backward compatibility problems with existing installations). Instead, the conclusion of the above-mentioned thread was that the proper way to handle this would be to add an "enable" element to the existing <dns> element, which would default to "yes". To disable libvirt-supplied dns services for a subnet, you would just put: <dns enable='no'/> in the network definition. In the case that dns had enable='no' AND there was no <dhcp> element, dnsmasq simply wouldn't be started at all. That hasn't been implemented yet, but shouldn't be too complex to do. As for dhcp-helper, aside from the fact that again you've created an option that is specific to a particular implementation of what is needed, that command isn't universally available anyway (it's not in any package for Fedora/RHEL, for example), and I'm not sure that it's really necessary to have it started up by libvirt anyway - can it detect newly created/upped interfaces as dnsmasq can? If so, it could be started up by regular host system config even before libvirt was started. > > These are the default values when the options are *not* defined. They allow the admin to disable dnsmasq entirely: > > <dnsmasq enabled='false'/> > > and to enable dhcp-helper: > > <dhcphelper enabled='true'/> > > Using two new functions: > > int networkBuildDhcphelperArgv(...) > int networkBuildDhcpHelperCommandLine(...) > > the existing function: > > int networkStartDhcpDaemon(...) > > is able to launch either or both of dnsmasq and dhcp-helper with the correct options. > > dhcp-helper's "-i" option is filled from network->def->bridge and its "-b" option is taken from > the first forward device declared in a <forward dev='?'/> or <interface dev='?'/>. If no forward > device is declared it throws a VIR_ERR_INVALID_INTERFACE error with appropriate explanatory text. > > >

2 4

[libvirt] q35 machine type and libvirt.
by Laine Stump 28 Feb '13

28 Feb '13

Now that qemu is getting the q35 machine type, libvirt needs to support it. As far as I understand, from libvirt's point of view, q35 is just another x86_64 system, but with a different set of implicit devices, and possibly some extra rules limiting which devices can be plugged into which bus/slot on the guest. That means that in order to support it, we will need to recognize when a q35-based machine type is being created, and auto-add all the implicit devices to libvirt's config model for that domain, then pay attention to the extra rules when assigning addresses for all the user-added devices. We already add implicit controllers/devices for pc-based machine types; as a matter of fact, currently, libvirt improperly assumes (for the purposes of adding implicit devices) that *every* virtual machine is based on the "pc" machine type (or rather it just doesn't pay attention), so it always adds all the implicit devices for a pc machine type for every domain. This of course is already incorrect for many (probably all?) non-x86 machine types, even before we add q35 into the mix. To fix this, it might be reasonable (and arguably, it's necessary to fix the problem in a backward-compatible manner) to just setup a table of machinetype ==> implicit device lists, look up the machine type in this table, and add the devices needed for that machine type. This goes against libvirt's longstanding view of machinetype as being an opaque value that it merely passes through to qemu, but it's manageable for the existing machine types (even including q35), since it's a finite set. But it starts to be a pain to maintain when you think about future additions - yet another case where new functionality in qemu will require an update to libvirt before it can be fully used via libvirt. In the long term, it would be very useful / more easily maintainable to have a qemu status command available via QMP which would return the list of implicit devices (and their PCI addresses) for any requested machine type. It would be necessary that this command be callable multiple times within a single execution of qemu, giving it a different machinetype each time. This way libvirt could first query the list of available machinetypes in this particular qemu binary, then request the list of implicit devices for each machine type (libvirt runs each available qemu binary *once* the first time it's requested, and caches all such capabilities information so that it doesn't need to re-run qemu again and again). My limited understanding of qemu's code is that qemu itself doesn't have a table of this information as data, but instead has lines of code that are executed to create it, thus making it impractical to provide the list of devices for a machinetype without actually instantiating a machine of that type. What's the feasibility of adding such a capability (and in the process likely making the list of implicit devices in qemu itself table/data driven rather than constructed with lines of code). More questions: 1) It seems that the exact list of devices for the basic q35 machine type hasn't been settled on yet, is that correct? 2) Are there other issues aside from implicit controller devices I need to consider for q35? For example, are there any devices that (as I recall is the case for some devices on "pc") may or may not be present, but if they are present they are always at a particular PCI address (meaning that address must be reserved)? I've also just learned that certain types of PCIe devices must be plugged into certain locations on the guest bus? ("root complex" devices - is there a good source of background info to learn the meaning of terms like that, and the rules of engagement? libvirt will need to know/follow these rules.) 3) What new types of devices/controllers must be supported for a properly functioning q35 machine?

6 8

[libvirt] [PATCH RESEND] Add support for <option> tag in network config
by Pieter Hollants 27 Feb '13

27 Feb '13

This patch adds support for a new <option>-Tag in the <dhcp> block of network configs, based on a subset of the fifth proposal by Laine Stump in the mailing list discussion at https://www.redhat.com/archives/libvir-list/2012-November/msg01054.html. Any such defined option will result in a dhcp-option=<number>,"<value>" statement in the generated dnsmasq configuration file. Currently, DHCP options can be specified by number only and there is no whitelisting or blacklisting of option numbers, which should probably be added. Signed-off-by: Pieter Hollants <pieter(a)hollants.com> --- AUTHORS.in | 1 + docs/schemas/network.rng | 6 +++ docs/schemas/networkcommon.rng | 6 +++ src/conf/network_conf.c | 54 +++++++++++++++++++++ src/conf/network_conf.h | 10 ++++ src/network/bridge_driver.c | 10 ++++ tests/networkxml2xmlin/netboot-network.xml | 1 + tests/networkxml2xmlin/netboot-proxy-network.xml | 1 + tests/networkxml2xmlout/netboot-network.xml | 1 + tests/networkxml2xmlout/netboot-proxy-network.xml | 1 + 10 Dateien geändert, 91 Zeilen hinzugefügt(+) diff --git a/AUTHORS.in b/AUTHORS.in index 39fe68d..074185e 100644 --- a/AUTHORS.in +++ b/AUTHORS.in @@ -74,6 +74,7 @@ Michel Ponceau <michel.ponceau(a)bull.net> Nobuhiro Itou <fj0873gn(a)aa.jp.fujitsu.com> Pete Vetere <pvetere(a)redhat.com> Philippe Berthault <philippe.berthault(a)Bull.net> +Pieter Hollants <pieter(a)hollants.com> Saori Fukuta <fukuta.saori(a)jp.fujitsu.com> Shigeki Sakamoto <fj0588di(a)aa.jp.fujitsu.com> Shuveb Hussain <shuveb(a)binarykarma.com> diff --git a/docs/schemas/network.rng b/docs/schemas/network.rng index 09d7c73..a2ce1c9 100644 --- a/docs/schemas/network.rng +++ b/docs/schemas/network.rng @@ -293,6 +293,12 @@ </optional> </element> </optional> + <zeroOrMore> + <element name="option"> + <attribute name="number"><ref name="unsignedByte"/></attribute> + <attribute name="value"><text/></attribute> + </element> + </zeroOrMore> </element> </optional> </element> diff --git a/docs/schemas/networkcommon.rng b/docs/schemas/networkcommon.rng index 51ff759..3510928 100644 --- a/docs/schemas/networkcommon.rng +++ b/docs/schemas/networkcommon.rng @@ -173,6 +173,12 @@ </data> </define> + <define name='unsignedByte'> + <data type='integer'> + <param name="minInclusive">0</param> + <param name="maxInclusive">255</param> + </data> + </define> <define name='unsignedShort'> <data type='integer'> <param name="minInclusive">0</param> diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c index 3604ff7..9d84c7e 100644 --- a/src/conf/network_conf.c +++ b/src/conf/network_conf.c @@ -777,6 +777,45 @@ cleanup: } static int +virNetworkDHCPOptionDefParseXML(const char *networkName, + xmlNodePtr node, + virNetworkDHCPOptionDefPtr option) +{ + char *number = NULL; + int ret = -1; + + if (!(number = virXMLPropString(node, "number"))) { + virReportError(VIR_ERR_XML_ERROR, + _("Option definition in IPv4 network '%s' " + "must have number attribute"), + networkName); + goto cleanup; + } + if (number && + virStrToLong_ui(number, NULL, 10, &option->number) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Cannot parse <option> 'number' attribute")); + goto cleanup; + } + /* TODO: either whitelist numbers or blacklist numbers already occupied + * by other XML statements (eg. submask) */ + if (!(option->value = virXMLPropString(node, "value"))) { + virReportError(VIR_ERR_XML_ERROR, + _("Option definition in IPv4 network '%s' " + "must have value attribute"), + networkName); + goto cleanup; + } + + ret = 0; + +cleanup: + VIR_FREE(number); + return ret; +} + + +static int virNetworkDHCPDefParseXML(const char *networkName, xmlNodePtr node, virNetworkIpDefPtr def) @@ -837,6 +876,17 @@ virNetworkDHCPDefParseXML(const char *networkName, def->bootfile = file; def->bootserver = inaddr; VIR_FREE(server); + } else if (cur->type == XML_ELEMENT_NODE && + xmlStrEqual(cur->name, BAD_CAST "option")) { + if (VIR_REALLOC_N(def->options, def->noptions + 1) < 0) { + virReportOOMError(); + return -1; + } + if (virNetworkDHCPOptionDefParseXML(networkName, cur, + &def->options[def->noptions])) { + return -1; + } + def->noptions++; } cur = cur->next; @@ -2045,6 +2095,10 @@ virNetworkIpDefFormat(virBufferPtr buf, virBufferAddLit(buf, "/>\n"); } + for (ii = 0 ; ii < def->noptions ; ii++) { + virBufferAsprintf(buf, "<option number='%u' value='%s' />\n", + def->options[ii].number, def->options[ii].value); + } virBufferAdjustIndent(buf, -2); virBufferAddLit(buf, "</dhcp>\n"); diff --git a/src/conf/network_conf.h b/src/conf/network_conf.h index 4c634ed..14f852a 100644 --- a/src/conf/network_conf.h +++ b/src/conf/network_conf.h @@ -77,6 +77,13 @@ struct _virNetworkDHCPHostDef { virSocketAddr ip; }; +typedef struct _virNetworkDHCPOptionDef virNetworkDHCPOptionDef; +typedef virNetworkDHCPOptionDef *virNetworkDHCPOptionDefPtr; +struct _virNetworkDHCPOptionDef { + unsigned int number; + char *value; +}; + typedef struct _virNetworkDNSTxtDef virNetworkDNSTxtDef; typedef virNetworkDNSTxtDef *virNetworkDNSTxtDefPtr; struct _virNetworkDNSTxtDef { @@ -139,6 +146,9 @@ struct _virNetworkIpDef { char *tftproot; char *bootfile; virSocketAddr bootserver; + + size_t noptions; /* Zero or more additional dhcp options */ + virNetworkDHCPOptionDefPtr options; }; typedef struct _virNetworkForwardIfDef virNetworkForwardIfDef; diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index c834f83..c7c0a9e 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -926,6 +926,15 @@ networkDnsmasqConfContents(virNetworkObjPtr network, virBufferAsprintf(&configbuf, "dhcp-boot=%s\n", ipdef->bootfile); } } + + /* Any additional DHCP options? */ + if (ipdef->noptions > 0) { + for (r = 0 ; r < ipdef->noptions ; r++) { + virBufferAsprintf(&configbuf, "dhcp-option=%u,\"%s\"\n", + ipdef->options[r].number, + ipdef->options[r].value); + } + } } ipdef = (ipdef == ipv6def) ? NULL : ipv6def; } @@ -959,6 +968,7 @@ networkDnsmasqConfContents(virNetworkObjPtr network, virBufferAsprintf(&configbuf, "addn-hosts=%s\n", dctx->addnhostsfile->path); + /* Are we doing RA instead of radvd? */ if (DNSMASQ_RA_SUPPORT(caps)) { if (ipv6def) diff --git a/tests/networkxml2xmlin/netboot-network.xml b/tests/networkxml2xmlin/netboot-network.xml index ed75663..4de8976 100644 --- a/tests/networkxml2xmlin/netboot-network.xml +++ b/tests/networkxml2xmlin/netboot-network.xml @@ -9,6 +9,7 @@ <dhcp> <range start="192.168.122.2" end="192.168.122.254" /> <bootp file="pxeboot.img" /> + <option number="252" value="\n" /> </dhcp> </ip> </network> diff --git a/tests/networkxml2xmlin/netboot-proxy-network.xml b/tests/networkxml2xmlin/netboot-proxy-network.xml index ecb6738..4c5c480 100644 --- a/tests/networkxml2xmlin/netboot-proxy-network.xml +++ b/tests/networkxml2xmlin/netboot-proxy-network.xml @@ -8,6 +8,7 @@ <dhcp> <range start="192.168.122.2" end="192.168.122.254" /> <bootp file="pxeboot.img" server="10.20.30.40" /> + <option number="252" value="\n" /> </dhcp> </ip> </network> diff --git a/tests/networkxml2xmlout/netboot-network.xml b/tests/networkxml2xmlout/netboot-network.xml index b8a4d99..c3ea95a 100644 --- a/tests/networkxml2xmlout/netboot-network.xml +++ b/tests/networkxml2xmlout/netboot-network.xml @@ -9,6 +9,7 @@ <dhcp> <range start='192.168.122.2' end='192.168.122.254' /> <bootp file='pxeboot.img' /> + <option number='252' value='\n' /> </dhcp> </ip> </network> diff --git a/tests/networkxml2xmlout/netboot-proxy-network.xml b/tests/networkxml2xmlout/netboot-proxy-network.xml index e11c50b..f5f2c0d 100644 --- a/tests/networkxml2xmlout/netboot-proxy-network.xml +++ b/tests/networkxml2xmlout/netboot-proxy-network.xml @@ -8,6 +8,7 @@ <dhcp> <range start='192.168.122.2' end='192.168.122.254' /> <bootp file='pxeboot.img' server='10.20.30.40' /> + <option number='252' value='\n' /> </dhcp> </ip> </network> -- 1.7.10.4

4 6

[libvirt] <seclabel> inside a //disk/source element
by Richard W.M. Jones 27 Feb '13

27 Feb '13

According to the docs, it should be possible to do: <disk device="disk" type="file"> <source file="/path/to/some/file"> <seclabel relabel="no"/> <---- NB </source> <target dev="sda" bus="scsi"/> <driver name="qemu" type="qcow2"/> </disk> However I tried it, and it simply doesn't work. Furthermore I looked at the code in domain_conf.c, and I can't see how it's even supposed to work. It doesn't look to me as if <seclabel> is ever parsed in that context. Can anyone else confirm that this is a bug or point out my error? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v

2 2

[libvirt] [PATCH] Fix autodestroy of QEMU guests
by Daniel P. Berrange 27 Feb '13

27 Feb '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The virQEMUCloseCallbacksRunOne method was passing a uuid string to virDomainObjListFindByUUID, when it actually expected to get a raw uuid buffer. This was not caught by the compiler because the method was using a 'void *uuid' instead of first casting it to the expected type. This regression was accidentally caused by refactoring in commit 568a6cda277f04ab9baaeb97490e548b7b608aa6 Author: Jiri Denemark <jdenemar(a)redhat.com> Date: Fri Feb 15 15:11:47 2013 +0100 qemu: Avoid deadlock in autodestroy Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/qemu/qemu_conf.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 4f0cb18..1cd4b7c 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -805,22 +805,26 @@ struct virQEMUCloseCallbacksData { static void virQEMUCloseCallbacksRunOne(void *payload, - const void *uuid, + const void *key, void *opaque) { struct virQEMUCloseCallbacksData *data = opaque; qemuDriverCloseDefPtr closeDef = payload; virDomainObjPtr dom; + const char *uuidstr = key; + unsigned char uuid[VIR_UUID_BUFLEN]; + + if (virUUIDParse(uuidstr, uuid) < 0) + return; VIR_DEBUG("conn=%p, thisconn=%p, uuid=%s, cb=%p", - closeDef->conn, data->conn, (const char *) uuid, closeDef->cb); + closeDef->conn, data->conn, uuidstr, closeDef->cb); if (data->conn != closeDef->conn || !closeDef->cb) return; if (!(dom = virDomainObjListFindByUUID(data->driver->domains, uuid))) { - VIR_DEBUG("No domain object with UUID %s", - (const char *) uuid); + VIR_DEBUG("No domain object with UUID %s", uuidstr); return; } -- 1.7.11.7

2 1