- Devel - libvirt List Archives

[libvirt] VG backed storage pool start behavior.
by Luke Varnadore 01 Mar '13

01 Mar '13

Libvirt 1.0.2-3 I am unable to use vg storage pools that are shared with the host. I was able to do this without issue an update before this one. Wondering if anyone else is seeing this behavior. I am on an Arch Linux system but I can't see why that would matter yet. Here is the error I get when trying to start a pool defined from the shared VG that my host, and guests share: Error starting pool 'vg_nimbus': internal error Child process (/sbin/vgchange -aln vg_nimbus) unexpected exit status 5: Can't deactivate volume group "vg_nimbus" with 7 open logical volume(s) Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/storagepool.py", line 64, in start self.pool.create(0) File "/usr/lib/python2.7/site-packages/libvirt.py", line 2360, in create if ret == -1: raise libvirtError ('virStoragePoolCreate() failed', pool=self) libvirtError: internal error Child process (/sbin/vgchange -aln vg_nimbus) unexpected exit status 5: Can't deactivate volume group "vg_nimbus" with 7 open logical volume(s) I can still carry on using lvs manually (without storage pools) to run my guests and host lvs. -- Luke W Varnadore

4 5

[libvirt] [PATCH] Hook log the exit status of the hook not 256
by Guido Günther 01 Mar '13

01 Mar '13

Adjust the docs accordingly. See http://bugs.debian.org/701570. --- docs/hooks.html.in | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/hooks.html.in b/docs/hooks.html.in index 5f9963d..b75fbeb 100644 --- a/docs/hooks.html.in +++ b/docs/hooks.html.in @@ -239,13 +239,14 @@ If a hook script returns with an exit code of 0, the libvirt daemon regards this as successful and performs no logging of it. However, if a hook script returns with a non zero exit code, the libvirt - daemon regards this as a failure, logs it with return code 256, and + daemon regards this as a failure, logs it's return code, and additionally logs anything on stderr the hook script returns. For example, a hook script might use this code to indicate failure, and send a text string to stderr: <pre>echo "Could not find required XYZZY" >&2 exit 1</pre> The resulting entry in the libvirt log will appear as: - <pre>20:02:40.297: error : virHookCall:416 : Hook script execution failed: Hook script /etc/libvirt/hooks/qemu qemu failed with error code 256:Could not find required XYZZY</pre> + <pre>20:02:40.297: error : virHookCall:285 : Hook script execution failed: internal error Child process (LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin + HOME=/root USER=root LOGNAME=root /etc/libvirt/hooks/qemu qemu prepare begin -) unexpected exit status 1: Could not find required XYZZY</pre> </body> </html> -- 1.7.10.4

2 2

[libvirt] [PATCH] qemu: enable direct migration over IPv6
by Ján Tomko 01 Mar '13

01 Mar '13

Use virURIParse in qemuMigrationPrepareDirect to allow parsing IPv6 addresses, which would cause an 'incorrect :port' error message before. To be able to migrate over IPv6, QEMU needs to listen on [::] instead of 0.0.0.0. This patch adds a call to getaddrinfo and sets the listen address based on the result. This will break migration if a hostname that can only be resolved on the source machine is passed in the migration URI, or if it does not resolve to the same address family on both sides. Bug: https://bugzilla.redhat.com/show_bug.cgi?id=846013 --- src/qemu/qemu_migration.c | 65 +++++++++++++++++++++++++++++++++++++---------- 1 file changed, 52 insertions(+), 13 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 36e55d2..c813c4a 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -22,7 +22,10 @@ #include <config.h> +#include <netdb.h> +#include <sys/socket.h> #include <sys/time.h> +#include <sys/types.h> #ifdef WITH_GNUTLS # include <gnutls/gnutls.h> # include <gnutls/x509.h> @@ -1835,8 +1838,11 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver, int this_port; char *hostname = NULL; char migrateFrom [64]; - const char *p; + char *uri_str; int ret = -1; + bool ipv6 = false; + struct addrinfo *info; + virURIPtr uri; VIR_DEBUG("driver=%p, dconn=%p, cookiein=%s, cookieinlen=%d, " "cookieout=%p, cookieoutlen=%p, uri_in=%s, uri_out=%p, " @@ -1892,9 +1898,33 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver, goto cleanup; } - /* Get the port number. */ - p = strrchr(uri_in, ':'); - if (p == strchr(uri_in, ':')) { + /* Convert uri_in to well-formed URI with // after tcp: */ + if (!(STRPREFIX(uri_in, "tcp://"))) { + if (virAsprintf(&uri_str, "tcp://%s", + uri_in + strlen("tcp:")) < 0) { + virReportOOMError(); + goto cleanup; + } + } + + uri = virURIParse(uri_str ? uri_str : uri_in); + VIR_FREE(uri_str); + + if (uri == NULL) { + virReportError(VIR_ERR_INVALID_ARG, _("unable to parse URI: %s"), + uri_in); + goto cleanup; + } + + if (uri->server == NULL) { + virReportError(VIR_ERR_INVALID_ARG, _("missing host in migration" + " URI: %s"), uri_in); + goto cleanup; + } else { + hostname = uri->server; + } + + if (uri->port == 0) { /* Generate a port */ this_port = QEMUD_MIGRATION_FIRST_PORT + port++; if (port == QEMUD_MIGRATION_NUM_PORTS) @@ -1907,21 +1937,30 @@ qemuMigrationPrepareDirect(virQEMUDriverPtr driver, } } else { - p++; /* definitely has a ':' in it, see above */ - this_port = virParseNumber(&p); - if (this_port == -1 || p-uri_in != strlen(uri_in)) { - virReportError(VIR_ERR_INVALID_ARG, - "%s", _("URI ended with incorrect ':port'")); - goto cleanup; - } + this_port = uri->port; } } + if (getaddrinfo(hostname, NULL, NULL, &info)) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("unable to get address info for %s"), hostname); + goto cleanup; + } else { + ipv6 = info->ai_family == AF_INET6; + } + if (*uri_out) VIR_DEBUG("Generated uri_out=%s", *uri_out); - /* QEMU will be started with -incoming tcp:0.0.0.0:port */ - snprintf(migrateFrom, sizeof(migrateFrom), "tcp:0.0.0.0:%d", this_port); + /* QEMU will be started with -incoming tcp:0.0.0.0:port + * or -incoming tcp:[::]:port for IPv6 */ + if (ipv6) { + snprintf(migrateFrom, sizeof(migrateFrom), + "tcp:[::]:%d", this_port); + } else { + snprintf(migrateFrom, sizeof(migrateFrom), + "tcp:0.0.0.0:%d", this_port); + } ret = qemuMigrationPrepareAny(driver, dconn, cookiein, cookieinlen, cookieout, cookieoutlen, dname, dom_xml, -- 1.7.12.4

3 4

[libvirt] [PATCH v2] virnetdevmacvlan.c: Introduce mutex for macvlan creation
by Michal Privoznik 01 Mar '13

01 Mar '13

Currently, after we removed the qemu driver lock, it may happen that two or more threads will start up a machine with macvlan and race over virNetDevMacVLanCreateWithVPortProfile(). However, there's a racy section in which we are generating a sequence of possible device names and detecting if they exits. If we found one which doesn't we try to create a device with that name. However, the other thread is doing just the same. Assume it will succeed and we must therefore fail. If this happens more than 5 times (which in massive parallel startup surely will) we return -1 without any error reported. This patch is a simple hack to both of these problems. It introduces a mutex, so only one thread will enter the section, and if it runs out of possibilities, error is reported. Moreover, the number of retries is raised to 20. --- diff to v1: -don't increase @retries -move error reporting to virNetDevMacVLanCreateMutexOnceInit src/util/virnetdevmacvlan.c | 37 ++++++++++++++++++++++++++++++++----- 1 file changed, 32 insertions(+), 5 deletions(-) diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c index a74db1e..ddea11f 100644 --- a/src/util/virnetdevmacvlan.c +++ b/src/util/virnetdevmacvlan.c @@ -31,6 +31,7 @@ #include "virmacaddr.h" #include "virutil.h" #include "virerror.h" +#include "virthread.h" #define VIR_FROM_THIS VIR_FROM_NET @@ -71,6 +72,19 @@ VIR_ENUM_IMPL(virNetDevMacVLanMode, VIR_NETDEV_MACVLAN_MODE_LAST, # define MACVLAN_NAME_PREFIX "macvlan" # define MACVLAN_NAME_PATTERN "macvlan%d" +virMutex virNetDevMacVLanCreateMutex; + +static int virNetDevMacVLanCreateMutexOnceInit(void) +{ + if (virMutexInit(&virNetDevMacVLanCreateMutex) < 0) { + virReportSystemError(errno, "%s", _("unable to init mutex")); + return -1; + } + return 0; +} + +VIR_ONCE_GLOBAL_INIT(virNetDevMacVLanCreateMutex); + /** * virNetDevMacVLanCreate: * @@ -829,7 +843,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char *tgifname, char ifname[IFNAMSIZ]; int retries, do_retry = 0; uint32_t macvtapMode; - const char *cr_ifname; + const char *cr_ifname = NULL; int ret; int vf = -1; @@ -871,22 +885,35 @@ int virNetDevMacVLanCreateWithVPortProfile(const char *tgifname, } else { create_name: retries = 5; + if (virNetDevMacVLanCreateMutexInitialize() < 0) + return -1; + virMutexLock(&virNetDevMacVLanCreateMutex); for (c = 0; c < 8192; c++) { snprintf(ifname, sizeof(ifname), pattern, c); - if ((ret = virNetDevExists(ifname)) < 0) + if ((ret = virNetDevExists(ifname)) < 0) { + virMutexUnlock(&virNetDevMacVLanCreateMutex); return -1; + } if (!ret) { rc = virNetDevMacVLanCreate(ifname, type, macaddress, linkdev, macvtapMode, &do_retry); - if (rc == 0) + if (rc == 0) { + cr_ifname = ifname; break; + } if (do_retry && --retries) continue; - return -1; + break; } } - cr_ifname = ifname; + + virMutexUnlock(&virNetDevMacVLanCreateMutex); + if (!cr_ifname) { + virReportError(VIR_ERR_OPERATION_FAILED, "%s", + _("Unable to create macvlan device")); + return -1; + } } if (virNetDevVPortProfileAssociate(cr_ifname, -- 1.8.1.4

2 2

[libvirt] [PATCH] virnetdevmacvlan.c: Introduce mutex for macvlan creation
by Michal Privoznik 01 Mar '13

01 Mar '13

Currently, after we removed the qemu driver lock, it may happen that two or more threads will start up a machine with macvlan and race over virNetDevMacVLanCreateWithVPortProfile(). However, there's a racy section in which we are generating a sequence of possible device names and detecting if they exits. If we found one which doesn't we try to create a device with that name. However, the other thread is doing just the same. Assume it will succeed and we must therefore fail. If this happens more than 5 times (which in massive parallel startup surely will) we return -1 without any error reported. This patch is a simple hack to both of these problems. It introduces a mutex, so only one thread will enter the section, and if it runs out of possibilities, error is reported. Moreover, the number of retries is raised to 20. --- This is just a quick hack which aim is to be as small as possible in order to be well understood and hence included in the release. After the release, this should be totally dropped in flavour of virNetDevNameAllocator. src/util/virnetdevmacvlan.c | 38 ++++++++++++++++++++++++++++++++------ 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c index a74db1e..bf5e7e0 100644 --- a/src/util/virnetdevmacvlan.c +++ b/src/util/virnetdevmacvlan.c @@ -31,6 +31,7 @@ #include "virmacaddr.h" #include "virutil.h" #include "virerror.h" +#include "virthread.h" #define VIR_FROM_THIS VIR_FROM_NET @@ -71,6 +72,15 @@ VIR_ENUM_IMPL(virNetDevMacVLanMode, VIR_NETDEV_MACVLAN_MODE_LAST, # define MACVLAN_NAME_PREFIX "macvlan" # define MACVLAN_NAME_PATTERN "macvlan%d" +virMutex virNetDevMacVLanCreateMutex; + +static int virNetDevMacVLanCreateMutexOnceInit(void) +{ + return virMutexInit(&virNetDevMacVLanCreateMutex); +} + +VIR_ONCE_GLOBAL_INIT(virNetDevMacVLanCreateMutex); + /** * virNetDevMacVLanCreate: * @@ -829,7 +839,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char *tgifname, char ifname[IFNAMSIZ]; int retries, do_retry = 0; uint32_t macvtapMode; - const char *cr_ifname; + const char *cr_ifname = NULL; int ret; int vf = -1; @@ -870,23 +880,39 @@ int virNetDevMacVLanCreateWithVPortProfile(const char *tgifname, return -1; } else { create_name: - retries = 5; + if (virNetDevMacVLanCreateMutexInitialize() < 0) { + virReportSystemError(errno, "%s", _("unable to init mutext")); + return -1; + } + + retries = 20; + virMutexLock(&virNetDevMacVLanCreateMutex); for (c = 0; c < 8192; c++) { snprintf(ifname, sizeof(ifname), pattern, c); - if ((ret = virNetDevExists(ifname)) < 0) + if ((ret = virNetDevExists(ifname)) < 0) { + virMutexUnlock(&virNetDevMacVLanCreateMutex); return -1; + } if (!ret) { rc = virNetDevMacVLanCreate(ifname, type, macaddress, linkdev, macvtapMode, &do_retry); - if (rc == 0) + if (rc == 0) { + cr_ifname = ifname; break; + } if (do_retry && --retries) continue; - return -1; + break; } } - cr_ifname = ifname; + + virMutexUnlock(&virNetDevMacVLanCreateMutex); + if (!cr_ifname) { + virReportError(VIR_ERR_OPERATION_FAILED, "%s", + _("Unable to create macvlan device")); + return -1; + } } if (virNetDevVPortProfileAssociate(cr_ifname, -- 1.8.1.4

4 3

[libvirt] [PATCH RFC 0/3] Keep original file label
by Michal Privoznik 01 Mar '13

01 Mar '13

Just sending out early to make sure this time I am going in acceptable direction before digging into selinux. Hopefully, apparmor won't be any deal as I don't see anything that should be restored on domain shut off process. Michal Privoznik (3): security_dac: Remember owner prior chown() and restore on relabel security_manager: Introduce {Save,Load}Status security_dac: Implement {save,load}Status src/lxc/lxc_controller.c | 2 +- src/lxc/lxc_driver.c | 1 + src/qemu/qemu_driver.c | 3 + src/security/security_dac.c | 465 ++++++++++++++++++++++++++++++++++----- src/security/security_driver.h | 12 + src/security/security_manager.c | 161 +++++++++++++- src/security/security_manager.h | 2 + tests/seclabeltest.c | 2 +- tests/securityselinuxlabeltest.c | 3 +- tests/securityselinuxtest.c | 3 +- 10 files changed, 590 insertions(+), 64 deletions(-) -- 1.8.1.4

3 12

[libvirt] [PATCH 0/4]typo fix and codes improvement in generator.py
by Guannan Ren 01 Mar '13

01 Mar '13

This four patches try to fix various typoes, fd leaks and optimize codes in generator.py script. This is the first round. Guannan Ren(4) [PATCH 1/4] python: global variable and debugging improvement for [PATCH 2/4] python: fix typoes and repeated global vars references [PATCH 3/4] python: optimize SAX xml parsing event handler [PATCH 4/4] python: fix fd leak in generator.py python/generator.py | 158 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------------- 1 file changed, 70 insertions(+), 88 deletions(-)

2 9

[libvirt] [PATCH] qemu: Make sure qemuProcessStart is run within a job
by Jiri Denemark 01 Mar '13

01 Mar '13

qemuProcessStart expects to be run with a job already set and every caller except for qemuMigrationPrepareAny use it correctly. This bug can be observed in libvirtd logs during incoming migration as warning : qemuDomainObjEnterMonitorInternal:979 : This thread seems to be the async job owner; entering monitor without asking for a nested job is dangerous --- src/qemu/qemu_domain.c | 35 ++++++++++++++++++++++++----------- src/qemu/qemu_domain.h | 4 ++++ src/qemu/qemu_migration.c | 11 +++++++---- 3 files changed, 35 insertions(+), 15 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index eca85fc..0e56596 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -881,6 +881,29 @@ int qemuDomainObjBeginAsyncJob(virQEMUDriverPtr driver, asyncJob); } +int +qemuDomainObjBeginNestedJob(virQEMUDriverPtr driver, + virDomainObjPtr obj, + enum qemuDomainAsyncJob asyncJob) +{ + qemuDomainObjPrivatePtr priv = obj->privateData; + + if (asyncJob != priv->job.asyncJob) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("unexpected async job %d"), asyncJob); + return -1; + } + + if (priv->job.asyncOwner != virThreadSelfID()) { + VIR_WARN("This thread doesn't seem to be the async job owner: %d", + priv->job.asyncOwner); + } + + return qemuDomainObjBeginJobInternal(driver, obj, + QEMU_JOB_ASYNC_NESTED, + QEMU_ASYNC_JOB_NONE); +} + /* * obj must be locked before calling @@ -955,17 +978,7 @@ qemuDomainObjEnterMonitorInternal(virQEMUDriverPtr driver, qemuDomainObjPrivatePtr priv = obj->privateData; if (asyncJob != QEMU_ASYNC_JOB_NONE) { - if (asyncJob != priv->job.asyncJob) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("unexpected async job %d"), asyncJob); - return -1; - } - if (priv->job.asyncOwner != virThreadSelfID()) - VIR_WARN("This thread doesn't seem to be the async job owner: %d", - priv->job.asyncOwner); - if (qemuDomainObjBeginJobInternal(driver, obj, - QEMU_JOB_ASYNC_NESTED, - QEMU_ASYNC_JOB_NONE) < 0) + if (qemuDomainObjBeginNestedJob(driver, obj, asyncJob) < 0) return -1; if (!virDomainObjIsActive(obj)) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 30e6b97..e114f89 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -192,6 +192,10 @@ int qemuDomainObjBeginAsyncJob(virQEMUDriverPtr driver, virDomainObjPtr obj, enum qemuDomainAsyncJob asyncJob) ATTRIBUTE_RETURN_CHECK; +int qemuDomainObjBeginNestedJob(virQEMUDriverPtr driver, + virDomainObjPtr obj, + enum qemuDomainAsyncJob asyncJob) + ATTRIBUTE_RETURN_CHECK; bool qemuDomainObjEndJob(virQEMUDriverPtr driver, virDomainObjPtr obj) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index a58a79d..4c6d7e1 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2118,6 +2118,10 @@ qemuMigrationPrepareAny(virQEMUDriverPtr driver, goto endjob; } + if (qemuDomainObjBeginNestedJob(driver, vm, + QEMU_ASYNC_JOB_MIGRATION_IN) < 0) + goto endjob; + /* Start the QEMU daemon, with the same command-line arguments plus * -incoming $migrateFrom */ @@ -2126,9 +2130,8 @@ qemuMigrationPrepareAny(virQEMUDriverPtr driver, VIR_QEMU_PROCESS_START_PAUSED | VIR_QEMU_PROCESS_START_AUTODESTROY) < 0) { virDomainAuditStart(vm, "migrated", false); - /* Note that we don't set an error here because qemuProcessStart - * should have already done that. - */ + if (qemuDomainObjEndJob(driver, vm) < 0) + vm = NULL; goto endjob; } @@ -2235,7 +2238,7 @@ stop: qemuProcessStop(driver, vm, VIR_DOMAIN_SHUTOFF_FAILED, 0); endjob: - if (!qemuMigrationJobFinish(driver, vm)) { + if (vm && !qemuMigrationJobFinish(driver, vm)) { vm = NULL; } goto cleanup; -- 1.8.1.4

2 2

[libvirt] [RFC] DHCP Relay agent functionality
by TJ 01 Mar '13

01 Mar '13

Recently I needed to implement functionality to operate a DHCP relay instead of dnsmasq's DHCP server on the virtual networks managed by libvirt. The primary benefit of operating a relay is that the central DHCP and DNS servers for the physical network can manage IP address allocation and hostname resolution for the entire network and, potentially, expose VMs via hostname and IP address on the public network too, as well as being able to monitor VM instance creation for resource planning. I originally implemented this functionality on libvirt 0.9.8 included with Ubuntu 12.04 as a hack to simply disable dnsmasq entirely and use dhcp-helper[1] (the DHCP relay written by Simon Kelley, author of dnsmaq) although I've constructed it so that another relay-agent could be used. After proving it works well I've reworked the code on the current libvirt master branch. If it's thought to be of use to the project please let me know. [1] http://www.thekelleys.org.uk/dhcp-helper/ The following changes since commit 34f1a618a5c4507f27f3f467b723c9119c1db3c7: conf: Avoid leaking of RNG device definition (2013-02-25 22:31:11 +0100) are available in the git repository at: git://github.com/iam-TJ/libvirt.git dhcp_relay_network for you to fetch changes up to dfc0609403106712b205e60b53b29dc850cad68d: docs: Describe the <dhcp> 'enable' and 'relay' attributes (2013-02-27 20:35:06 +0000) ---------------------------------------------------------------- TJ (10): conf: DHCP - add state for DHCP Relay and On/Off switch conf: Network - add ability to read/write XML DHCP state conf: Network - add pointers to enabled virNetworkIpDef DHCP settings conf: Network - keep track of active DHCP stanza in virNetworkDef network: Bridge - use IPv4 and IPv6 active DHCP stanza pointers network: Bridge - Add support for a DHCP Relay Agent network: Bridge - don't offer dnsmasq DHCP services when DHCP relay is enabled configure: Add DHCPRELAY to the set of external program definitions Add copyright attribution for DHCP relay functionality docs: Describe the <dhcp> 'enable' and 'relay' attributes configure.ac | 4 +++ docs/formatnetwork.html.in | 22 +++++++++++++- src/conf/network_conf.c | 36 +++++++++++++++++++--- src/conf/network_conf.h | 7 +++++ src/network/bridge_driver.c | 215 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------- 5 files changed, 229 insertions(+), 55 deletions(-)

5 44

[libvirt] [trivial PATCH 1/1] Fix a message typo
by Serge Hallyn 28 Feb '13

28 Feb '13

As pointed out in https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1034661 The sentence "The function of PCI device addresses must less than 8" does not quite make sense. Update that to read "The function of PCI device addresses must be less than 8" Signed-off-by: Serge Hallyn <serge.hallyn(a)ubuntu.com> --- src/qemu/qemu_command.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index f8f3ade..201fac1 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1743,7 +1743,7 @@ qemuBuildDeviceAddressStr(virBufferPtr buf, if (info->addr.pci.function > 7) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("The function of PCI device addresses must " - "less than 8")); + "be less than 8")); return -1; } } else { -- 1.8.1.2

2 1