- Devel - libvirt List Archives

[libvirt] [PATCH] util: use string libvirt to prefix error message instead of libvir
by Guannan Ren 04 Mar '13

04 Mar '13

BZ:https://bugzilla.redhat.com/show_bug.cgi?id=912021 Without error handler set, virDefaultErrorFunc will be called, the error message is prefixed with "libvir:". It become a little better by using prefix "libvirt:" when working with upper application. For example: 1, stop libvirtd daemon 2, run virt-top. libvir: XML-RPC error : Failed to connect \ socket to '/var/run/libvirt/libvirt-sock-ro': \ No such file or directory libvirt: VIR_ERR_SYSTEM_ERROR: VIR_FROM_RPC: \ Failed to connect socket to '/var/run/libvirt/libvirt-sock-ro': \ No such file or directory --- src/util/virerror.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/util/virerror.c b/src/util/virerror.c index 301a1ac..40c3b25 100644 --- a/src/util/virerror.c +++ b/src/util/virerror.c @@ -525,13 +525,13 @@ virDefaultErrorFunc(virErrorPtr err) len = strlen(err->message); if ((err->domain == VIR_FROM_XML) && (err->code == VIR_ERR_XML_DETAIL) && (err->int1 != 0)) - fprintf(stderr, "libvir: %s %s %s%s: line %d: %s", + fprintf(stderr, "libvirt: %s %s %s%s: line %d: %s", dom, lvl, domain, network, err->int1, err->message); else if ((len == 0) || (err->message[len - 1] != '\n')) - fprintf(stderr, "libvir: %s %s %s%s: %s\n", + fprintf(stderr, "libvirt: %s %s %s%s: %s\n", dom, lvl, domain, network, err->message); else - fprintf(stderr, "libvir: %s %s %s%s: %s", + fprintf(stderr, "libvirt: %s %s %s%s: %s", dom, lvl, domain, network, err->message); } -- 1.7.11.2

3 3

[libvirt] libvirt does not logout of iscsi targets, causing system hang on shutdown
by Fritz Elfert 04 Mar '13

04 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, There's a quite old bug entry here: https://bugzilla.redhat.com/show_bug.cgi?id=700010 I just stumbled over that very issue on F18. Doing a little bit debugging of the shutdown sequence, it turns out that - at least on my F18 installation - libvirtd is shutdown *after* iscsid, which makes it impossible for libvirt to perform the logout of the iscsi session properly. My local fix (diff) is attached. It simply adds another startup dependancy on iscsid.service which in turn delays iscsid shutdown until after libvirtd has stopped. Having that applied, the system shuts down properly again. I was asked to post that here for discussion... So please consider this trivial change for the next update. Cheers -Fritz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEvwhoACgkQboM4mAMyprB9agCgpIkGbSBKpfB4e0q6aqSMVGam rMoAnAtBpp3nFbleWLxJTbCt9EKO9Yx3 =2hHf -----END PGP SIGNATURE-----

2 3

[libvirt] [PATCH] qemu: Remove managed save flag from VM when starting with --force-boot
by Peter Krempa 04 Mar '13

04 Mar '13

At the start of the guest after the image is unlinked the state wasn't touched up to match the state on disk. --- src/qemu/qemu_driver.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index d40b5d5..7048ce9 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -5421,20 +5421,21 @@ qemuDomainObjStart(virConnectPtr conn, goto cleanup; if (virFileExists(managed_save)) { if (force_boot) { if (unlink(managed_save) < 0) { virReportSystemError(errno, _("cannot remove managed save file %s"), managed_save); goto cleanup; } + vm->hasManagedSave = false; } else { ret = qemuDomainObjRestore(conn, driver, vm, managed_save, start_paused, bypass_cache); if (ret == 0) { if (unlink(managed_save) < 0) VIR_WARN("Failed to remove the managed state %s", managed_save); else vm->hasManagedSave = false; } -- 1.8.1.1

2 3

[libvirt] libvirt-1.0.2 qith lxc and /proc/meminfo
by Thierry Parmentelat 04 Mar '13

04 Mar '13

Hello there I'm using libvirt-1.0.2 to spawn off linux containers We currently have 2 very similar setups that run on fedora 16 and f18 respectively And I'm seeing one weird difference concerning /proc/meminfo While everything is fine on the fedora16 world, on the fedora18 side here is what the container sees bash-4.2# ls /proc ls: cannot access /proc/meminfo: Permission denied 1 257 bus devices fb irq kpagecount mdstat net schedstat swaps tty 10 377 cgroups diskstats filesystems kallsyms kpageflags meminfo pagetypeinfo scsi sys uptime 15 522 cmdline dma fs kcore latency_stats misc partitions self sysrq-trigger version 16 542 consoles dri interrupts key-users loadavg modules pidsu slabinfo sysvipc vmallocinfo 18 acpi cpuinfo driver iomem keys locks mounts procprotect softirqs timer_list vmstat 19 buddyinfo crypto execdomains ioports kmsg lxcsu mtrr sched_debug stat timer_stats zoneinfo bash-4.2# ls -l /proc | grep meminfo ls: cannot access /proc/meminfo: Permission denied -????????? ? ? ? ? ? meminfo bash-4.2# cat /proc/meminfo cat: /proc/meminfo: Permission denied ===== we rebuild libvirt-1.0.2 more or less as is modulo a few features that are turned off, our specfile can be found here http://git.onelab.eu/?p=libvirt.git;a=blob;f=libvirt.spec the most obvious difference between both builds lies in using fuse: --- # fuse is used to provide virtualized /proc for LXC %if 0%{?fedora} >= 17 || 0%{?rhel} >= 7 %define with_fuse 0%{!?_without_fuse:1} %endif --- I was wondering what exactly should be the requirements on the root context for running this properly In particular the fuse rpm was not pulled as part of the libvirt dependencies, which might be an omission ? Can I expect my problem to go away if I make sure fuse gets installed ? Otherwise where should I try to look to solve this issue ? many thanks in advance -- Thierry

2 1

[libvirt] [PATCH] Fix error report from nl_recvmsg
by Daniel P. Berrange 04 Mar '13

04 Mar '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The nl_recvmsg does not always set errno. Instead it returns its own custom set of error codes. Thus we were reporting the wrong data. --- src/util/virnetlink.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/util/virnetlink.c b/src/util/virnetlink.c index 0b36fdc..8b47ede 100644 --- a/src/util/virnetlink.c +++ b/src/util/virnetlink.c @@ -335,8 +335,9 @@ virNetlinkEventCallback(int watch, if (length == 0) return; if (length < 0) { - virReportSystemError(errno, - "%s", _("nl_recv returned with error")); + virReportError(VIR_ERR_INTERNAL_ERROR, + _("nl_recv returned with error: %s"), + nl_geterror(length)); return; } -- 1.7.11.7

5 13

Re: [libvirt] [Qemu-devel] [Qemu PATCH v2] add a boot option to do strict boot
by Eric Blake 04 Mar '13

04 Mar '13

On 01/09/2013 01:39 AM, Amos Kong wrote: > Current seabios will try to boot from selected devices first, > if they are all failed, seabios will also try to boot from > un-selected devices. > > We need to make it configurable. I already posted a seabios > patch to add a new device type to halt booting. Qemu can add > "HALT" at the end of bootindex string, then seabios will halt > booting after trying to boot from selected devices. > > This option only effects when boot priority is changed by > bootindex options, the old style(-boot order=..) will still > try to boot from un-selected devices. > > v2: add HALT entry in get_boot_devices_list() > define boot_strict to bool > > Signed-off-by: Amos Kong <akong(a)redhat.com> > --- Libvirt will need to expose an attribute that lets the user control whether to use this new option; how do we probe via QMP whether the new -boot strict=on command-line option is available? > +++ b/qemu-options.hx > @@ -376,14 +376,14 @@ ETEXI > > DEF("boot", HAS_ARG, QEMU_OPTION_boot, > "-boot [order=drives][,once=drives][,menu=on|off]\n" > - " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time]\n" > + " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time][,strict=on|off]\n" > " 'drives': floppy (a), hard disk (c), CD-ROM (d), network (n)\n" > " 'sp_name': the file's name that would be passed to bios as logo picture, if menu=on\n" > " 'sp_time': the period that splash picture last if menu=on, unit is ms\n" > " 'rb_timeout': the timeout before guest reboot when boot failed, unit is ms\n", So if I understand correctly, -boot order=... is incompatible with -boot strict=on; even though you have listed both options under a single -boot entry in the -help. We've already declared that -help output is no longer guaranteed stable, so this doesn't really impact libvirt, but would it make any more sense to list this as two orthogonal entries, to make it clear that they don't mix? -boot order=drivers[,once=drives]... -boot strict=on|off[,menu=on|off]... But this is all bikeshedding, so it's not worth a v3 if you disagree. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

9 16

[libvirt] Entering freeze for libvirt-1.0.3
by Daniel Veillard 04 Mar '13

04 Mar '13

I have just tagged git and pushed the tarball. The rpms for F17 are following too at the usual place: ftp://libvirt.org/libvirt/ I gave a try to the set of rpms and this seems to work fine for relatively simple tests, but of course more testing and checking on other architectures is needed ! If everything goes fine, I will make an rc2 in a couple of days and then we can decide if a final release on Friday is fine or if we need to postpone to next week, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

11 25

[libvirt] TEST
by Han Cheng 04 Mar '13

04 Mar '13

Sorry, just a test.

1 0

[libvirt] TEST
by Han Cheng 04 Mar '13

04 Mar '13

Sorry, just a test.

1 0

[libvirt] libvirt accidentally destroys guests after being restarted
by Igor Lukyanov 02 Mar '13

02 Mar '13

Hello. We notice a very upsetting behavior of how libvirtd deals with running domains after being restarted. Namely, in 10-20s after start libvirtd may accidentally kill a random number of running (qemu) domains with SIGTERM. Here is what we get in libvirt log: 2013-02-27 12:35:10.415+0000: 45777: info : libvirt version: 1.0.2 2013-02-27 12:35:10.415+0000: 45777: error : virNWFilterSnoopLeaseFileRefresh:1903 : open("/var/run/libvirt/network/nwfilter.ltmp"): No such file or directory 2013-02-27 12:35:21.772+0000: 45766: error : qemuMonitorIO:602 : internal error End of file from monitor 2013-02-27 12:35:21.772+0000: 45766: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet34" not in key map 2013-02-27 12:35:21.905+0000: 45766: error : virNetDevGetIndex:653 : Unable to get index for interface vnet34: No such device 2013-02-27 12:35:22.029+0000: 45766: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet35" not in key map 2013-02-27 12:35:22.032+0000: 45766: error : virNetDevGetIndex:653 : Unable to get index for interface vnet35: No such device 2013-02-27 12:35:22.430+0000: 45766: error : qemuMonitorIO:602 : internal error End of file from monitor 2013-02-27 12:35:22.430+0000: 45766: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet4" not in key map 2013-02-27 12:35:22.433+0000: 45766: error : virNetDevGetIndex:653 : Unable to get index for interface vnet4: No such device 2013-02-27 12:35:22.554+0000: 45766: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet5" not in key map 2013-02-27 12:35:22.557+0000: 45766: error : virNetDevGetIndex:653 : Unable to get index for interface vnet5: No such device 2013-02-27 12:35:22.794+0000: 45766: error : qemuMonitorIO:602 : internal error End of file from monitor 2013-02-27 12:35:22.794+0000: 45766: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet10" not in key map 2013-02-27 12:35:22.797+0000: 45766: error : virNetDevGetIndex:653 : Unable to get index for interface vnet10: No such device 2013-02-27 12:35:22.944+0000: 45766: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet11" not in key map 2013-02-27 12:35:22.947+0000: 45766: error : virNetDevGetIndex:653 : Unable to get index for interface vnet11: No such device 2013-02-27 12:35:23.194+0000: 45766: error : qemuMonitorIO:602 : internal error End of file from monitor 2013-02-27 12:35:23.194+0000: 45766: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet14" not in key map 2013-02-27 12:35:23.197+0000: 45766: error : virNetDevGetIndex:653 : Unable to get index for interface vnet14: No such device 2013-02-27 12:35:23.361+0000: 45766: error : virNWFilterDHCPSnoopEnd:2131 : internal error ifname "vnet15" not in key map 2013-02-27 12:35:23.364+0000: 45766: error : virNetDevGetIndex:653 : Unable to get index for interface vnet15: No such device And this is what we get by grepping 45766 in separate logs of vms: drafter@10-5-0-11:/var/log/libvirt/qemu$ sudo grep -A 1 45766 * vm010-001-206-002.log:qemu: terminating on signal 15 from pid 45766 vm010-001-206-002.log-2013-02-27 12:35:22.430+0000: shutting down -- vm010-001-207-002.log:qemu: terminating on signal 15 from pid 45766 vm010-001-207-002.log-2013-02-27 12:35:22.794+0000: shutting down -- vm010-001-228-006.log:qemu: terminating on signal 15 from pid 45766 vm010-001-228-006.log-2013-02-27 12:35:23.194+0000: shutting down -- vm010-002-011-002.log:qemu: terminating on signal 15 from pid 45766 vm010-002-011-002.log-2013-02-27 12:35:21.772+0000: shutting down Specifically here libvirt killed 4 vms just after start. Before that occasion we just shut libvirtd off and started again (stop/start). Will be very grateful for any ideas on this matter. -- wbr, Igor Lukyanov

2 2

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

02 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 01 Mar '13

01 Mar '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

[libvirt] [PATCH] Revert hack for autodestroy in qemuProcessStop
by Daniel P. Berrange 01 Mar '13

01 Mar '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> This reverts the hack done in commit 568a6cda277f04ab9baaeb97490e548b7b608aa6 Author: Jiri Denemark <jdenemar(a)redhat.com> Date: Fri Feb 15 15:11:47 2013 +0100 qemu: Avoid deadlock in autodestroy since we now have a fix which avoids the deadlock scenario entirely --- src/qemu/qemu_conf.h | 4 ---- src/qemu/qemu_domain.h | 1 - src/qemu/qemu_process.c | 8 +------- 3 files changed, 1 insertion(+), 12 deletions(-) diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h index d547d97..6bb3dee 100644 --- a/src/qemu/qemu_conf.h +++ b/src/qemu/qemu_conf.h @@ -254,10 +254,6 @@ struct qemuDomainDiskInfo { int io_status; }; -/* - * To avoid a certain deadlock this callback must never call any - * virQEMUCloseCallbacks* API. - */ typedef virDomainObjPtr (*virQEMUCloseCallback)(virQEMUDriverPtr driver, virDomainObjPtr vm, virConnectPtr conn); diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 30e6b97..dacbb54 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -138,7 +138,6 @@ struct _qemuDomainObjPrivate { bool gotShutdown; bool beingDestroyed; - bool autoDestroyed; char *pidfile; int nvcpupids; diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 1b9eede..9f1507a 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4232,8 +4232,7 @@ void qemuProcessStop(virQEMUDriverPtr driver, qemuDomainCleanupRun(driver, vm); /* Stop autodestroy in case guest is restarted */ - if (!priv->autoDestroyed) - qemuProcessAutoDestroyRemove(driver, vm); + qemuProcessAutoDestroyRemove(driver, vm); /* now that we know it's stopped call the hook if present */ if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) { @@ -4614,13 +4613,8 @@ qemuProcessAutoDestroy(virQEMUDriverPtr driver, VIR_DEBUG("Killing domain"); - /* We need to prevent qemuProcessStop from removing this function from - * closeCallbacks since that would cause a deadlock. - */ - priv->autoDestroyed = true; qemuProcessStop(driver, dom, VIR_DOMAIN_SHUTOFF_DESTROYED, VIR_QEMU_PROCESS_STOP_MIGRATED); - priv->autoDestroyed = false; virDomainAuditStop(dom, "destroyed"); event = virDomainEventNewFromObj(dom, -- 1.7.11.7

2 1

[libvirt] [PATCH] Fix deadlock in QEMU close callback APIs
by Daniel P. Berrange 01 Mar '13

01 Mar '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> There is a lock ordering problem in the QEMU close callback APIs. When starting a guest we have a lock on the VM. We then set a autodestroy callback, which acquires a lock on the close callbacks. When running auto-destroy, we obtain a lock on the close callbacks, then run each callbacks - which obtains a lock on the VM. This causes deadlock if anyone tries to start a VM, while autodestroy is taking place. The fix is to do autodestroy in 2 phases. First obtain all the callbacks and remove them from the list under the close callback lock. Then invoke each callback from outside the close callback lock. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/qemu/qemu_conf.c | 106 ++++++++++++++++++++++++++++++++++++++++++-------- src/util/virnetlink.c | 5 ++- 2 files changed, 92 insertions(+), 19 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 1cd4b7c..f3b09cf 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -797,20 +797,37 @@ virQEMUCloseCallbacksGet(virQEMUCloseCallbacksPtr closeCallbacks, return cb; } + +typedef struct _virQEMUCloseCallbacksListEntry virQEMUCloseCallbacksListEntry; +typedef virQEMUCloseCallbacksListEntry *virQEMUCloseCallbacksListEntryPtr; +struct _virQEMUCloseCallbacksListEntry { + unsigned char uuid[VIR_UUID_BUFLEN]; + virQEMUCloseCallback callback; +}; + + +typedef struct _virQEMUCloseCallbacksList virQEMUCloseCallbacksList; +typedef virQEMUCloseCallbacksList *virQEMUCloseCallbacksListPtr; +struct _virQEMUCloseCallbacksList { + size_t nentries; + virQEMUCloseCallbacksListEntryPtr entries; +}; + + struct virQEMUCloseCallbacksData { - virHashTablePtr list; - virQEMUDriverPtr driver; virConnectPtr conn; + virQEMUCloseCallbacksListPtr list; + bool oom; }; + static void -virQEMUCloseCallbacksRunOne(void *payload, +virQEMUCloseCallbacksGetOne(void *payload, const void *key, void *opaque) { struct virQEMUCloseCallbacksData *data = opaque; qemuDriverCloseDefPtr closeDef = payload; - virDomainObjPtr dom; const char *uuidstr = key; unsigned char uuid[VIR_UUID_BUFLEN]; @@ -823,35 +840,90 @@ virQEMUCloseCallbacksRunOne(void *payload, if (data->conn != closeDef->conn || !closeDef->cb) return; - if (!(dom = virDomainObjListFindByUUID(data->driver->domains, uuid))) { - VIR_DEBUG("No domain object with UUID %s", uuidstr); + if (VIR_EXPAND_N(data->list->entries, + data->list->nentries, 1) < 0) { + data->oom = true; return; } - dom = closeDef->cb(data->driver, dom, data->conn); - if (dom) - virObjectUnlock(dom); + memcpy(data->list->entries[data->list->nentries - 1].uuid, + uuid, VIR_UUID_BUFLEN); + data->list->entries[data->list->nentries - 1].callback = closeDef->cb; +} + + +static virQEMUCloseCallbacksListPtr +virQEMUCloseCallbacksGetForConn(virQEMUCloseCallbacksPtr closeCallbacks, + virConnectPtr conn) +{ + virQEMUCloseCallbacksListPtr list = NULL; + struct virQEMUCloseCallbacksData data; + + if (VIR_ALLOC(list) < 0) { + virReportOOMError(); + return NULL; + } + + data.conn = conn; + data.list = list; + data.oom = false; + + virHashForEach(closeCallbacks->list, virQEMUCloseCallbacksGetOne, &data); - virHashRemoveEntry(data->list, uuid); + if (data.oom) { + VIR_FREE(list->entries); + VIR_FREE(list); + virReportOOMError(); + return NULL; + } + + return list; } + void virQEMUCloseCallbacksRun(virQEMUCloseCallbacksPtr closeCallbacks, virConnectPtr conn, virQEMUDriverPtr driver) { - struct virQEMUCloseCallbacksData data = { - .driver = driver, - .conn = conn - }; + virQEMUCloseCallbacksListPtr list; + size_t i; VIR_DEBUG("conn=%p", conn); - virObjectLock(closeCallbacks); - data.list = closeCallbacks->list; - virHashForEach(data.list, virQEMUCloseCallbacksRunOne, &data); + /* We must not hold the lock while running the callbacks, + * so first we obtain the list of callbacks, then remove + * them all from the hash. At that point we can release + * the lock and run the callbacks safely. */ + virObjectLock(closeCallbacks); + list = virQEMUCloseCallbacksGetForConn(closeCallbacks, conn); + if (!list) + return; + + for (i = 0 ; i < list->nentries ; i++) { + virHashRemoveEntry(closeCallbacks->list, + list->entries[i].uuid); + } virObjectUnlock(closeCallbacks); + + for (i = 0 ; i < list->nentries ; i++) { + virDomainObjPtr vm; + + if (!(vm = virDomainObjListFindByUUID(driver->domains, + list->entries[i].uuid))) { + char uuidstr[VIR_UUID_STRING_BUFLEN]; + virUUIDFormat(list->entries[i].uuid, uuidstr); + VIR_DEBUG("No domain object with UUID %s", uuidstr); + continue; + } + + vm = list->entries[i].callback(driver, vm, conn); + if (vm) + virObjectUnlock(vm); + } + VIR_FREE(list->entries); + VIR_FREE(list); } struct _qemuSharedDiskEntry { diff --git a/src/util/virnetlink.c b/src/util/virnetlink.c index 0b36fdc..8b47ede 100644 --- a/src/util/virnetlink.c +++ b/src/util/virnetlink.c @@ -335,8 +335,9 @@ virNetlinkEventCallback(int watch, if (length == 0) return; if (length < 0) { - virReportSystemError(errno, - "%s", _("nl_recv returned with error")); + virReportError(VIR_ERR_INTERNAL_ERROR, + _("nl_recv returned with error: %s"), + nl_geterror(length)); return; } -- 1.7.11.7

2 5

[libvirt] [PATCH] Fix crash in QEMU auto-destroy with transient guests
by Daniel P. Berrange 01 Mar '13

01 Mar '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> When the auto-destroy callback runs it is supposed to return NULL if the virDomainObjPtr is no longer valid. It was not doing this for transient guests, so we tried to virObjectUnlock a mutex which had been freed. This often led to a crash. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/qemu/qemu_process.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index db95d6e..1b9eede 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4629,8 +4629,10 @@ qemuProcessAutoDestroy(virQEMUDriverPtr driver, if (!qemuDomainObjEndJob(driver, dom)) dom = NULL; - if (dom && !dom->persistent) + if (dom && !dom->persistent) { qemuDomainRemoveInactive(driver, dom); + dom = NULL; + } if (event) qemuDomainEventQueue(driver, event); -- 1.7.11.7

3 2

[libvirt] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option
by Eduardo Habkost 01 Mar '13

01 Mar '13

This allows ":" to be used a separator between each CPU range, so the command-line may look like: -numa node,cpus=A-B:C-D Note that the following format, currently used by libvirt: -numa nodes,cpus=A-B,C-D will _not_ work, as "," is the option separator for the command-line option parser, and it would require changing the -numa option parsing code to handle "cpus" as a special case. Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com> --- Changes v2: - Use ":" as separator - Document the new format --- qemu-options.hx | 10 ++++++++-- vl.c | 14 +++++++++++++- 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/qemu-options.hx b/qemu-options.hx index 4bc9c85..b135044 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -95,12 +95,18 @@ specifies the maximum number of hotpluggable CPUs. ETEXI DEF("numa", HAS_ARG, QEMU_OPTION_numa, - "-numa node[,mem=size][,cpus=cpu[-cpu]][,nodeid=node]\n", QEMU_ARCH_ALL) + "-numa node[,mem=size][,cpus=cpu[-cpu][:...]][,nodeid=node]\n", QEMU_ARCH_ALL) STEXI @item -numa @var{opts} @findex -numa Simulate a multi node NUMA system. If mem and cpus are omitted, resources -are split equally. +are split equally. Multiple CPU ranges in the "cpus" option may be separated +by colons. e.g.: + +@example +-numa node,mem=1024,cpus=0-1:4-5:8-9 +-numa node,mem=1024,cpus=2-3:6-7:10-11 +@end example ETEXI DEF("add-fd", HAS_ARG, QEMU_OPTION_add_fd, diff --git a/vl.c b/vl.c index 955d2ff..fe632db 100644 --- a/vl.c +++ b/vl.c @@ -1244,7 +1244,7 @@ char *get_boot_devices_list(size_t *size) return list; } -static void numa_node_parse_cpus(int nodenr, const char *cpus) +static void numa_node_parse_cpu_range(int nodenr, const char *cpus) { char *endptr; unsigned long long value, endvalue; @@ -1288,6 +1288,18 @@ error: exit(1); } +static void numa_node_parse_cpus(int nodenr, const char *option) +{ + char **parts; + int i; + + parts = g_strsplit(option, ":", 0); + for (i = 0; parts[i]; i++) { + numa_node_parse_cpu_range(nodenr, parts[i]); + } + g_strfreev(parts); +} + static void numa_add(const char *optarg) { char option[128]; -- 1.8.1

6 30

[libvirt] virnettlscontexttest test fails on Fedora Rawhide x86_64
by Richard W.M. Jones 28 Feb '13

28 Feb '13

Still investigating, but the log is attached. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

2 2