August 2016 - Devel - libvirt List Archives

[libvirt] [PATCH 0/6] Use more PCIe, less legacy PCI slots
by Laine Stump 11 Aug '16

11 Aug '16

These patches use three methods to get more of the PCI devices onto PCIe slots on Q35 and aarch64/virt machinetypes: 1) When virtio devices can present themselves as PCIe if they're plugged into a PCIe controller, do that. (This capability is detected by looking for presence of the "disable-modern" option on the virtio-net device. If you have a better idea for how to detect it, please let me know.) 2) Any devices that aren't hotpluggable anyway will no longer request a hotplug-capable slot. This, along with a change to auto-assign legacy PCI devices to pcie-root (as long as they don't require hotplug) means the devices will now be assigned to pcie-root. 3) Also using the fact that devices that won't be hotplugged can be assigned to pcie-root, the devices that *do* support hotplug have a new optional subelement "<hotplug require='no'/>" (it defaults to "yes" for historical reasons). If hotplug require is set to 'no', even a PCI device can be auto-assigned to pcie-root. I haven't yet removed the dmi-to-pci-bridge that is added by default, and we still will only auto-add pci-bridge (so if you're adding a virtio device without <hostplug require='no'/> then you will also need to add a <controller type='pci' model='pcie-root-port'/> to plug it into). These 6 patches together resolve: https://bugzilla.redhat.com/show_bug.cgi?id=1330024 They need to be applied on top of the series I sent on Friday: https://www.redhat.com/archives/libvir-list/2016-August/msg00380.html Laine Stump (6): conf: restrict what type of buses will accept a pci-bridge conf: permit auto-assignment of *non-hotpluggable* PCI devices to pcie-root qemu: add capabilities bit for virtio-net "disable-modern" option conf: new <hotplug require='yes|no'/> element for hotpluggable devices qemu: don't require a hotpluggable slot for devices that can't be hotplugged qemu: auto-assign virtio devices to PCIe slots when appropriate docs/formatdomain.html.in | 37 +++++++ docs/schemas/domaincommon.rng | 17 +++ src/conf/device_conf.h | 15 +++ src/conf/domain_addr.c | 44 ++++++-- src/conf/domain_addr.h | 4 +- src/conf/domain_conf.c | 28 +++++ src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain_address.c | 94 ++++++++++++++-- tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 22 ++-- .../qemuxml2argv-bios-nvram-secure.args | 2 +- .../qemuxml2argv-machine-smm-opt.args | 2 +- .../qemuxml2argv-q35-hotpluggable.args | 50 +++++++++ .../qemuxml2argv-q35-hotpluggable.xml | 62 +++++++++++ .../qemuxml2argv-q35-pm-disable-fallback.args | 3 +- .../qemuxml2argv-q35-pm-disable.args | 3 +- .../qemuxml2argv-q35-usb2-multi.args | 10 +- .../qemuxml2argv-q35-usb2-reorder.args | 10 +- .../qemuxml2argv-q35-virtio-pcie.args | 54 +++++++++ .../qemuxml2argv-q35-virtio-pcie.xml | 69 ++++++++++++ tests/qemuxml2argvtest.c | 18 +++ .../qemuxml2xmlout-autoindex.xml | 18 +-- .../qemuxml2xmlout-q35-hotpluggable.xml | 103 +++++++++++++++++ .../qemuxml2xmlout-q35-usb2-multi.xml | 8 +- .../qemuxml2xmlout-q35-usb2-reorder.xml | 8 +- .../qemuxml2xmlout-q35-virtio-pcie.xml | 123 +++++++++++++++++++++ tests/qemuxml2xmltest.c | 15 +++ 34 files changed, 765 insertions(+), 64 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-hotpluggable.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-hotpluggable.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pcie.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pcie.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-hotpluggable.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virtio-pcie.xml -- 2.7.4

3 19

[libvirt] [PATCH] lxc: don't try to resolve a NULL path for filesystems
by Daniel P. Berrange 11 Aug '16

11 Aug '16

<filesystem type='ram' accessmode='passthrough'> <source usage='524288' units='KiB'/> <target dir='/dev/shm'/> </filesystem> would lead to lxcContainerResolveSymlinks calling access(NULL) because it failed to check if fs->src->path was non-NULL. This is a regression caused by commit da665fbd4858890fbb3bbf5da2a7b6ca37bb3220 Author: Olga Krishtal <okrishtal(a)virtuozzo.com> Date: Thu Jul 14 16:52:38 2016 +0300 filesystem: adds possibility to use storage pool as fs source Signed-off-by: Olga Krishtal <okrishtal(a)virtuozzo.com> Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/lxc/lxc_container.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 124b441..e1eb434 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -616,7 +616,7 @@ static int lxcContainerResolveSymlinks(virDomainFSDefPtr fs, bool gentle) { char *newroot; - if (!fs->src || fs->symlinksResolved) + if (!fs->src || !fs->src->path || fs->symlinksResolved) return 0; if (access(fs->src->path, F_OK)) { -- 2.7.4

2 1

[libvirt] [PATCH 0/7] qemu: Trivially add support for newer ivshmem
by Martin Kletzander 11 Aug '16

11 Aug '16

It's "trivially" because it's just about using different parameters. It is a series because I wanted to make some code paths saner and some output nicer, but I tried keeping every patch self-contained and as small as possible while keeping the readability. Also I wanted to make the series to be looked upon by more people by just using the word "trivial". Sorry for that =) Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1347049 Martin Kletzander (7): qemu: Add capabilities for ivshmem-{plain,doorbell} qemu: Save various defaults for shmem qemu: Make qemuBuildShmemDevStr static qemu: Rename qemuBuildShmemDevStr to qemuBuildShmemDevLegacyStr qemu: Move common checks outside qemuBuildShmemDevLegacyStr qemu: Reorder shmem params nicely qemu: Support newer ivshmem and prefer that over the legacy one src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 144 +++++++++++++++------ src/qemu/qemu_command.h | 4 - src/qemu/qemu_domain.c | 18 +++ .../caps_2.6.0-gicv2.aarch64.xml | 2 + .../caps_2.6.0-gicv3.aarch64.xml | 2 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 2 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 2 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 2 + .../qemuxml2argv-shmem-plain-doorbell.args | 42 ++++++ .../qemuxml2argv-shmem-plain-doorbell.xml} | 14 +- tests/qemuxml2argvdata/qemuxml2argv-shmem.args | 16 +-- tests/qemuxml2argvtest.c | 3 + tests/qemuxml2xmloutdata/qemuxml2xmlout-shmem.xml | 1 + 15 files changed, 193 insertions(+), 65 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.args copy tests/{qemuxml2xmloutdata/qemuxml2xmlout-shmem.xml => qemuxml2argvdata/qemuxml2argv-shmem-plain-doorbell.xml} (66%) -- 2.9.2

2 10

[libvirt] an AB deadlock or libvirtd crash problem in virsh console and virsh destroy
by weifuqiang 11 Aug '16

11 Aug '16

Hi all: I encountered with an AB deadlock and libvirtd crash problem the other day. The process to generate the problems: 1 use the command "virsh create ***.xml" to create a vm 2 after vm is running , use the command "virsh console ***" to connect vm with console 3 after connection, use the command "virsh destroy ****" to destroy vm and delete it Then, an AB lock problem occurs, or libvirtd got crashed. AB LOCK stack: [Switching to thread 1 (Thread 0x7ff96bf3d7a0 (LWP 9772))] #0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0 #0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007ff967b44669 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007ff967b4447e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007ff96b3bd96c in virChrdevFDStreamCloseCb () from /usr/lib64/libvirt.so.0 #4 0x00007ff96b3c9a34 in virFDStreamCloseInt () from /usr/lib64/libvirt.so.0 #5 0x00007ff96b40ac3e in virStreamAbort () from /usr/lib64/libvirt.so.0 #6 0x00007ff96bfa242a in daemonStreamHandleAbort () #7 0x00007ff96bfa2803 in daemonStreamEvent () #8 0x00007ff96b3c9bfc in virFDStreamEvent () from /usr/lib64/libvirt.so.0 #9 0x00007ff96b3083aa in virEventPollRunOnce () from /usr/lib64/libvirt.so.0 #10 0x00007ff96b307042 in virEventRunDefaultImpl () from /usr/lib64/libvirt.so.0 #11 0x00007ff96b4503dd in virNetDaemonRun () from /usr/lib64/libvirt.so.0 #12 0x00007ff96bf72528 in main () [Switching to thread 12 (Thread 0x7ff9640ff700 (LWP 9778))] #0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0 #0 0x00007ff967b49324 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007ff967b44669 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007ff967b4447e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007ff96b3c8f26 in virFDStreamSetInternalCloseCb () from /usr/lib64/libvirt.so.0 #4 0x00007ff96b30f7b9 in virHashForEach () from /usr/lib64/libvirt.so.0 #5 0x00007ff96b3be1a2 in virChrdevFree () from /usr/lib64/libvirt.so.0 #6 0x00007ff96055980f in qemuDomainObjPrivateFree () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so #7 0x00007ff96b367014 in virDomainObjDispose () from /usr/lib64/libvirt.so.0 #8 0x00007ff96b330c33 in virObjectUnref () from /usr/lib64/libvirt.so.0 #9 0x00007ff96b35edb9 in virDomainObjEndAPI () from /usr/lib64/libvirt.so.0 #10 0x00007ff9605c6e89 in qemuDomainUndefineFlags () from /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so #11 0x00007ff96b3e35ac in virDomainUndefine () from /usr/lib64/libvirt.so.0 #12 0x00007ff96bf996db in remoteDispatchDomainUndefineHelper () #13 0x00007ff96b4537ef in virNetServerProgramDispatch () from /usr/lib64/libvirt.so.0 #14 0x00007ff96b45205e in virNetServerProcessMsg () from /usr/lib64/libvirt.so.0 #15 0x00007ff96b4520e8 in virNetServerHandleJob () from /usr/lib64/libvirt.so.0 #16 0x00007ff96b349f94 in virThreadPoolWorker () from /usr/lib64/libvirt.so.0 #17 0x00007ff96b3494a8 in virThreadHelper () from /usr/lib64/libvirt.so.0 #18 0x00007ff967b42806 in start_thread () from /lib64/libpthread.so.0 #19 0x00007ff96789d67d in clone () from /lib64/libc.so.6 #20 0x0000000000000000 in ?? () coredump stack (gdb) f 1 #1 0x00007f1672a7c73f in virMutexLock (m=0x68) at util/virthread.c:89 89 pthread_mutex_lock(&m->lock); (gdb) bt #0 0x00007f1670ace444 in pthread_mutex_lock () from /lib64/libpthread.so.0 #1 0x00007f1672a7c73f in virMutexLock (m=0x68) at util/virthread.c:89 #2 0x00007f1672b2fda2 in virFDStreamSetInternalCloseCb (st=0x7f1673a1a370, cb=0x0, opaque=0x0, fcb=0x0) at fdstream.c:796 #3 0x00007f1672b1f5ad in virChrdevFreeClearCallbacks (payload=0x7f1673a1a370, name=0x7f1673a12520, data=0x0) at conf/virchrdev.c:301 #4 0x00007f1672a36c9b in virHashForEach (table=0x7f1673a0ba20, iter=0x7f1672b1f567 <virChrdevFreeClearCallbacks>, data=0x0) at util/virhash.c:521 #5 0x00007f1672b1f626 in virChrdevFree (devs=0x7f1673a2f820) at conf/virchrdev.c:316 #6 0x00007f1669cca988 in qemuDomainObjPrivateFree (data=0x7f1673a1afa0) at qemu/qemu_domain.c:496 #7 0x00007f1672a9e293 in virDomainObjDispose (obj=0x7f1673a16400) at conf/domain_conf.c:2545 #8 0x00007f1672a5b326 in virObjectUnref (anyobj=0x7f1673a16400) at util/virobject.c:265 #9 0x00007f1672a9e7a5 in virDomainObjEndAPI (vm=0x7f166b07d8d0) at conf/domain_conf.c:2684 #10 0x00007f1669d3ff00 in qemuDomainDestroyFlags (dom=0x7f16600017f0, flags=0) at qemu/qemu_driver.c:2264 #11 0x00007f1669d3ff69 in qemuDomainDestroy (dom=0x7f16600017f0) at qemu/qemu_driver.c:2273 #12 0x00007f1672b39333 in virDomainDestroy (domain=0x7f16600017f0) at libvirt-domain.c:483 #13 0x00007f16737167a5 in remoteDispatchDomainDestroy (server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70, rerr=0x7f166b07db50, args=0x7f1673a2f9b0) at remote_dispatch.h:4002 #14 0x00007f1673716648 in remoteDispatchDomainDestroyHelper (server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70, rerr=0x7f166b07db50, args=0x7f1673a2f9b0, ret= 0x7f1673a10e10) at remote_dispatch.h:3977 #15 0x00007f1672bd8a9b in virNetServerProgramDispatchCall (prog=0x7f167399c610, server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70) at rpc/virnetserverprogram.c:437 #16 0x00007f1672bd85fd in virNetServerProgramDispatch (prog=0x7f167399c610, server=0x7f167398f4f0, client=0x7f1673a172f0, msg=0x7f1673a2fc70) at rpc/virnetserverprogram.c:307 #17 0x00007f1672bd2a08 in virNetServerProcessMsg (srv=0x7f167398f4f0, client=0x7f1673a172f0, prog=0x7f167399c610, msg=0x7f1673a2fc70) at rpc/virnetserver.c:136 #18 0x00007f1672bd2aed in virNetServerHandleJob (jobOpaque=0x7f1673a1d780, opaque=0x7f167398f4f0) at rpc/virnetserver.c:157 #19 0x00007f1672a7d833 in virThreadPoolWorker (opaque=0x7f167399bad0) at util/virthreadpool.c:145 #20 0x00007f1672a7cbec in virThreadHelper (data=0x7f167399c980) at util/virthread.c:206 #21 0x00007f1670acc806 in start_thread () from /lib64/libpthread.so.0 #22 0x00007f167082767d in clone () from /lib64/libc.so.6 #23 0x0000000000000000 in ?? () (gdb) bt #0 0x00007f1670ad3324 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f1670ace669 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007f1670ace47e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00007f1672a7c73f in virMutexLock (m=0x7f1673a2f820) at util/virthread.c:89 #4 0x00007f1672b1f3fe in virChrdevFDStreamCloseCb (st=0x7f1673a1a370, opaque=0x7f1673a149e0) at conf/virchrdev.c:254 #5 0x00007f1672b2e8a8 in virFDStreamCloseInt (st=0x7f1673a1a370, streamAbort=true) at fdstream.c:329 #6 0x00007f1672b2e9d5 in virFDStreamAbort (st=0x7f1673a1a370) at fdstream.c:355 #7 0x00007f1672b7d856 in virStreamAbort (stream=0x7f1673a1a370) at libvirt-stream.c:663 #8 0x00007f16737497e8 in daemonStreamHandleAbort (client=0x7f1673a1b1b0, stream=0x7f1673a1ec50, msg=0x7f1673a0d660) at stream.c:613 #9 0x00007f16737499fa in daemonStreamHandleWrite (client=0x7f1673a1b1b0, stream=0x7f1673a1ec50) at stream.c:662 #10 0x00007f167374866b in daemonStreamEvent (st=0x7f1673a1a370, events=14, opaque=0x7f1673a1b1b0) at stream.c:138 #11 0x00007f1672b2e17a in virFDStreamEvent (watch=18, fd=17, events=14, opaque=0x7f1673a1a370) at fdstream.c:173 #12 0x00007f1672a2c2cb in virEventPollDispatchHandles (nfds=12, fds=0x7f1673a2fda0) at util/vireventpoll.c:509 #13 0x00007f1672a2cb08 in virEventPollRunOnce () at util/vireventpoll.c:658 #14 0x00007f1672a2a9e0 in virEventRunDefaultImpl () at util/virevent.c:308 #15 0x00007f1672bd25d2 in virNetDaemonRun (dmn=0x7f1673990ed0) at rpc/virnetdaemon.c:707 #16 0x00007f167370cad4 in main (argc=3, argv=0x7ffd63276288) at libvirtd.c:1581 The reason of this problem is that fdstream abort event or close event occured at the same time, libvirtd doesn't deal with the synchronousness well enough. the flows about fdStream is bellow 1、qemuDomainDefineXMLFlags -> virDomainObjListAdd -> qemuDomainObjPrivateAlloc -> virChrdevAlloc -> virHashCreate 2、qemuDomainOpenConsole -> virChrdevOpen -> virHashAddEntry(devs->hash, path, st) 3、virDomainObjDispose -> privateDataFreeFunc (qemuDomainObjPrivateFree) - > virChrdevFree(*dev locked*) -> virChrdevFreeClearCallbacks - > virFDStreamSetInternalCloseCb(*fdst locked*) 4、virFDStreamCloseInt (*fdst locked*) -> icbFreeOpaque(virChrdevFDStreamCloseCb (*dev locked*)) -> virHashRemoveEntry The AB lock problem is obviouse: in step 3, it locks chardev before fdst, and in step 4, it's the opsite way. The reason of libvirtd crash is that: in virFDStreamCloseInt function we set fdst to NULL, while in virFDStreamSetInternalCloseCb we use fdst->lock, note that fdst has already been freed. another crash problem occurs because that when virChrdevFree was earlier finished, dev->hash freed and all date of hash is freed, but fdstream event flow use fdStream after hash free. Ahha~~， libvirtd coredump. All of those problem is because clear vm flow and fdStream flow concurs synchronously. then I fix this problem by modify virChrdevFree() void virChrdevFree(virChrdevsPtr devs) { if (!devs || !devs->hash) return; for (;;) { virMutexLock(&devs->lock); if (0 == virHashSize(devs->hash)) { virMutexUnlock(&devs->lock); break; } virMutexUnlock(&devs->lock); usleep(10 * 1000); } virMutexLock(&devs->lock); virHashFree(devs->hash); virMutexUnlock(&devs->lock); virMutexDestroy(&devs->lock); VIR_FREE(devs); } If the chardev is removed by fdStream close or fdStream abort when vm destroy or shutdown, the modification works well. But I'm not sure is that all chardev would be removed when we clear vm, if not, it would always sleep here. Another solution is as follows: virMutexLock(vm); virChrdevFree(); virMutexUnlock(vm); virMutexLock(vm); virFDStreamCloseInt(); virMutexUnlock(vm); I lock vm before calling these 2 functions, which makes them run sequently. Do you have other better idea to solve this problem. thanks in advance. Thanks in advance. Wei Fuqiang

2 1

[libvirt] [PATCH v2] libxl: support serial list
by Bob Liu 10 Aug '16

10 Aug '16

Add support for multi serial devices, after this patch virsh can be used to connect different serial devices of running domains. E.g. vish # console <xxx> --devname serial<xxx> Note: This depends on a xen/libxl bug fix to have libxl_console_get_tty(...) correctly returning the tty path (as opposed to always returning the first one). [0] https://lists.xen.org/archives/html/xen-devel/2016-08/msg00438.html Signed-off-by: Bob Liu <bob.liu(a)oracle.com> --- v2: Add #ifdef LIBXL_HAVE_BUILDINFO_SERIAL_LIST --- src/libxl/libxl_conf.c | 24 +++++++++++++++++++++--- src/libxl/libxl_domain.c | 23 +++++++++++++++++++++++ src/libxl/libxl_driver.c | 17 +++++++++-------- 3 files changed, 53 insertions(+), 11 deletions(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 146e08a..26c704d 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -431,14 +431,32 @@ libxlMakeDomBuildInfo(virDomainDefPtr def, } if (def->nserials) { - if (def->nserials > 1) { + if (def->nserials == 1) { + if (libxlMakeChrdevStr(def->serials[0], &b_info->u.hvm.serial) < + 0) + return -1; + } else { +#ifdef LIBXL_HAVE_BUILDINFO_SERIAL_LIST + if (VIR_ALLOC_N(b_info->u.hvm.serial_list, def->nserials + 1) < + 0) + return -1; + + for (i = 0; i < def->nserials; i++) { + if (libxlMakeChrdevStr(def->serials[i], + &b_info->u.hvm.serial_list[i]) < 0) + { + libxl_string_list_dispose(&b_info->u.hvm.serial_list); + return -1; + } + } + b_info->u.hvm.serial_list[i] = NULL; +#else virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("Only one serial device is supported by libxl")); return -1; +#endif } - if (libxlMakeChrdevStr(def->serials[0], &b_info->u.hvm.serial) < 0) - return -1; } if (def->nparallels) { diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index 0e26b91..5d8c9c1 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -989,6 +989,29 @@ libxlConsoleCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback) VIR_FREE(console); } } + for (i = 0; i < vm->def->nserials; i++) { + virDomainChrDefPtr chr = vm->def->serials[i]; + char *console = NULL; + int ret; + + ignore_value(virAsprintf(&chr->info.alias, "serial%zd", i)); + if (chr->source.type == VIR_DOMAIN_CHR_TYPE_PTY) { + if (chr->source.data.file.path) + continue; + ret = libxl_console_get_tty(ctx, ev->domid, + chr->target.port, + LIBXL_CONSOLE_TYPE_SERIAL, + &console); + if (!ret) { + VIR_FREE(chr->source.data.file.path); + if (console && console[0] != '\0') { + ignore_value(VIR_STRDUP(chr->source.data.file.path, + console)); + } + } + VIR_FREE(console); + } + } virObjectUnlock(vm); libxl_event_free(ctx, ev); } diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c index f153f69..a34eb02 100644 --- a/src/libxl/libxl_driver.c +++ b/src/libxl/libxl_driver.c @@ -4450,13 +4450,6 @@ libxlDomainOpenConsole(virDomainPtr dom, virCheckFlags(VIR_DOMAIN_CONSOLE_FORCE, -1); - if (dev_name) { - /* XXX support device aliases in future */ - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("Named device aliases are not supported")); - goto cleanup; - } - if (!(vm = libxlDomObjFromDomain(dom))) goto cleanup; @@ -4472,8 +4465,16 @@ libxlDomainOpenConsole(virDomainPtr dom, } priv = vm->privateData; + if (dev_name) { + size_t i; - if (vm->def->nconsoles) { + for (i = 0; !chr && i < vm->def->nserials; i++) { + if (STREQ(dev_name, vm->def->serials[i]->info.alias)) { + chr = vm->def->serials[i]; + break; + } + } + } else if (vm->def->nconsoles) { chr = vm->def->consoles[0]; if (chr->targetType == VIR_DOMAIN_CHR_CONSOLE_TARGET_TYPE_SERIAL) chr = vm->def->serials[0]; -- 2.6.5

2 1

[libvirt] [PATCH 0/2] libxl USB vendor/product support
by Cédric Bosdonnat 10 Aug '16

10 Aug '16

Hi all, Libxl API only allows providing bus/dev for USB hostdevs. If libvirt libxl driver users provide vendor/product they get an error, instead search for the corresponding bus/dev pair and feed them to libxl. Cédric Bosdonnat (2): Add virHostdevFindUSBDevice to private symbols libxl: allow vendor/product addressing for USB hostdevs src/libvirt_private.syms | 1 + src/libxl/libxl_conf.c | 25 +++++++++++++++++-------- src/util/virhostdev.c | 2 +- src/util/virhostdev.h | 6 ++++++ 4 files changed, 25 insertions(+), 9 deletions(-) -- 2.6.6

2 4

[libvirt] [PATCH jenkins-ci 00/19] Use jenkins-job-builder for CI
by Daniel P. Berrange 10 Aug '16

10 Aug '16

We are using the CentOS Jenkins server for running CI tasks. Currently those tasks are maintained by people manually updating the Jenkins web UI. This is a horrible interface that requires 100's of mouse clicks to achieve even the simplest things. It is also incredibly hard to compare the config of different jobs to make sure they are working in a consistent manner. Fortunately there are tools which can help - OpenStack created the jenkins-job-builder tool which uses the Jenkins REST API to create/update jobs from a simple YAML file definition. This series thus creates a set of YAML files which will (almost) replicate our current manually create config. I've used jenkins-job-builder in offline test mode to generate Jenkins XML files and then compared them to what we currently have and they are mostly the same. So there should not be too many suprises lurking, but I do still expect some accidental breakage in places. As such I have not actually uploaded the new auto-generated job configs to ci.centos.org at this time. The intention is that these configs will all live in the libvirt GIT server in a new 'libvirt-jenkins-ci' repository Daniel P. Berrange (19): jobs: add global default variables jobs: add a template for generic build process jobs: add a template for GNU autotools jobs: add a template for Python distutils jobs: add a template for Perl ExtUtils::MakeMaker jobs: add a template for Perl Module::Build projects: add the libvirt package projects: add the libvirt-python package projects: add the libvirt-perl package projects: add the libvirt-tck package projects: add the libvirt-glib package projects: add the libvirt-sandbox package projects: add the osinfo-db-tools package projects: add the osinfo-db package projects: add the libvirt-cim package projects: add the virt-viewer package projects: add the virt-manager package projects: add the libosinfo package Add README explaining how to use it README | 34 ++++++++ jobs/autotools.yaml | 198 ++++++++++++++++++++++++++++++++++++++++++ jobs/defaults.yaml | 11 +++ jobs/generic.yaml | 124 ++++++++++++++++++++++++++ jobs/perl-makemaker.yaml | 105 ++++++++++++++++++++++ jobs/perl-modulebuild.yaml | 104 ++++++++++++++++++++++ jobs/python-distutils.yaml | 99 +++++++++++++++++++++ projects/libosinfo.yaml | 20 +++++ projects/libvirt-cim.yaml | 24 +++++ projects/libvirt-glib.yaml | 20 +++++ projects/libvirt-perl.yaml | 18 ++++ projects/libvirt-python.yaml | 18 ++++ projects/libvirt-sandbox.yaml | 19 ++++ projects/libvirt-tck.yaml | 16 ++++ projects/libvirt.yaml | 44 ++++++++++ projects/osinfo-db-tools.yaml | 19 ++++ projects/osinfo-db.yaml | 24 +++++ projects/virt-manager.yaml | 19 ++++ projects/virt-viewer.yaml | 19 ++++ 19 files changed, 935 insertions(+) create mode 100644 README create mode 100644 jobs/autotools.yaml create mode 100644 jobs/defaults.yaml create mode 100644 jobs/generic.yaml create mode 100644 jobs/perl-makemaker.yaml create mode 100644 jobs/perl-modulebuild.yaml create mode 100644 jobs/python-distutils.yaml create mode 100644 projects/libosinfo.yaml create mode 100644 projects/libvirt-cim.yaml create mode 100644 projects/libvirt-glib.yaml create mode 100644 projects/libvirt-perl.yaml create mode 100644 projects/libvirt-python.yaml create mode 100644 projects/libvirt-sandbox.yaml create mode 100644 projects/libvirt-tck.yaml create mode 100644 projects/libvirt.yaml create mode 100644 projects/osinfo-db-tools.yaml create mode 100644 projects/osinfo-db.yaml create mode 100644 projects/virt-manager.yaml create mode 100644 projects/virt-viewer.yaml -- 2.7.4

3 38

[libvirt] [PATCH] qemu: fix qemu.conf security_driver
by Cole Robinson 10 Aug '16

10 Aug '16

Since a9331394 (first release v2.1.0), specifying a manual security_driver setting in qemu.conf causes the daemon to fail to start, erroring with 'Duplicate security driver X'. The duplicate checking was incorrectly comparing every entry against itself, guaranteeing a false positive. https://bugzilla.redhat.com/show_bug.cgi?id=1365607 --- src/qemu/qemu_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index b51f36f..7b971f1 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -436,7 +436,7 @@ int virQEMUDriverConfigLoadFile(virQEMUDriverConfigPtr cfg, goto cleanup; for (i = 0; cfg->securityDriverNames && cfg->securityDriverNames[i] != NULL; i++) { - for (j = i; cfg->securityDriverNames[j] != NULL; j++) { + for (j = i + 1; cfg->securityDriverNames[j] != NULL; j++) { if (STREQ(cfg->securityDriverNames[i], cfg->securityDriverNames[j])) { virReportError(VIR_ERR_CONF_SYNTAX, -- 2.7.4

2 1

[libvirt] [PATCH 0/3] Couple of virNetDevMacVLanCreateWithVPortProfile fixes
by Michal Privoznik 10 Aug '16

10 Aug '16

Le sigh. How come this slipped uncaught for that long? Michal Privoznik (3): virNetDevMacVLanCreateWithVPortProfile: Don't mask virNetDevMacVLanTapOpen error virNetDevMacVLanCreateWithVPortProfile: Drop @rc virNetDevMacVLanCreateWithVPortProfile: Drop @ret src/util/virnetdevmacvlan.c | 37 ++++++++++++++----------------------- 1 file changed, 14 insertions(+), 23 deletions(-) -- 2.8.4

2 6

[libvirt] [PATCH] virt-admin: Fix the error when an invalid URI has been provided
by Erik Skultety 10 Aug '16

10 Aug '16

After commit 9d479dd1 fiddled with the cmdConnect's output which used to be a bit more verbose prior to the mentioned commit, the program flow would result in a quite confusing error if an invalid URI has been provided: error: Failed to connect to the admin server Connected to the admin server error: <some error> The problem is that the commit mentioned above relied on the fact that connect routine always succeeds which is not true. Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- tools/virt-admin.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virt-admin.c b/tools/virt-admin.c index 2ae05da..513054b 100644 --- a/tools/virt-admin.c +++ b/tools/virt-admin.c @@ -351,7 +351,7 @@ cmdConnect(vshControl *ctl, const vshCmd *cmd) } vshAdmReconnect(ctl); - if (!connected) + if (!connected && priv->conn) vshPrint(ctl, "%s\n", _("Connected to the admin server")); return !!priv->conn; -- 2.5.5

2 2