December 2015 - Devel - libvirt List Archives

[libvirt] oVirt considers using macTableManager='libvirt'
by Ido Barkan 02 Feb '16

02 Feb '16

Hi guys, We, at oVirt, are considring using the automatic bridge management feature of libvirt for our hosts (macTableManager='libvirt'). I could find any discussion in the mailing list archives about the motivation for this feature. (was there?). If there wasn't I would like to start a new one, about the possible trade offs it would have in oVirt. Specifically I have a few questions: 1) The obvious performance motivation is clear: considering N hosts with M vms each connected to the same LAN, the first packet to any unknown yet host will flood all the vms in all N bridges. -- was there any other motivation that I do not understand (apart from slightly better security? 2) oVirt uses TC for port mirroring, in case this is requested by users, to mirror traffic from a chosen bridge to a chosen NIC in the host. I could not understand if macTableManager will interfere with it, or not. 3) Are there any drawbacks to enabling this feature? 4) We aim for rhel7.2. Will the feature be supported (or partially supported) for kernels older then 3.17? And if so, in what way? 5) oVirt currently builds its own bridges and tell libvirt about them. Does that have any affect on the functionality of that feature? 6) are there any plans to support OVS for this feature in the future? -- Thanks, Ido Barkan

4 7

[libvirt] [PATCH 0/8] Add perf and Intel CMT feature support
by Qiaowei Ren 29 Jan '16

29 Jan '16

The series mainly adds Intel CMT feature support into libvirt. CMT is new introduced PQos (Platform Qos) feature to monitor the usage of cache by applications running on the platform. Currently CMT patches has been merged into Linux kernel mainline. The CMT implementation in Linux kernel is based on perf mechanism and there is no support for perf in libvirt, and so this series firstly add perf support into libvirt, including two public API and a set of util interfaces. And based on these APIs and interfaces, thie series implements CMT perf event support. TODO: 1. add support for new APIs into libvirt-python library. Changes since v1: * change perf APIs implementation to match new style of the API. * add new xml element * reenable all perf events previously enabled when libvirtd daemon restart. * redesign perf util functions. Changes since v2: * add an example XML file to the test suite. * add virPerfReadEvent(). * change 'perf' xml element to new style. * change 'perf' command to new stype. Qiaowei Ren (8): perf: add new public APIs for perf event perf: implement the remote protocol for perf event perf: implement a set of util functions for perf event qemu_driver: add support to perf event perf: add new xml element perf: reenable perf events when libvirtd restart virsh: implement new command to support perf virsh: extend domstats command daemon/remote.c | 47 ++++ docs/schemas/domaincommon.rng | 27 +++ include/libvirt/libvirt-domain.h | 19 ++ include/libvirt/virterror.h | 1 + src/Makefile.am | 1 + src/conf/domain_conf.c | 111 ++++++++++ src/conf/domain_conf.h | 10 + src/driver-hypervisor.h | 12 + src/libvirt-domain.c | 93 ++++++++ src/libvirt_private.syms | 12 + src/libvirt_public.syms | 6 + src/qemu/qemu_domain.h | 3 + src/qemu/qemu_driver.c | 195 +++++++++++++++++ src/qemu/qemu_process.c | 10 + src/remote/remote_driver.c | 39 ++++ src/remote/remote_protocol.x | 30 ++- src/remote_protocol-structs | 18 ++ src/util/virerror.c | 1 + src/util/virperf.c | 303 ++++++++++++++++++++++++++ src/util/virperf.h | 63 ++++++ tests/domainschemadata/domain-perf-simple.xml | 20 ++ tools/virsh-domain-monitor.c | 7 + tools/virsh-domain.c | 128 +++++++++++ tools/virsh.pod | 27 ++- 24 files changed, 1180 insertions(+), 3 deletions(-) create mode 100644 src/util/virperf.c create mode 100644 src/util/virperf.h create mode 100644 tests/domainschemadata/domain-perf-simple.xml -- 1.9.1

3 18

[libvirt] rbd: Add support for wiping and cloning images to storage driver
by Wido den Hollander 22 Jan '16

22 Jan '16

These two patches add support for buildVolFrom and wipeVol to the RBD storage driver. Wiping is done by discarding all blocks on the RBD image. Building a volume from a original is done leveraging the cloning mechanism RBD already supports.

3 14

[libvirt] An AB deadlock and libvirtd crash problem the other day with virsh console
by weifuqiang 22 Jan '16

22 Jan '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. Best Regards David

2 1

[libvirt] [PATCH v3 0/6] admin: Introduce server listing API
by Erik Skultety 21 Jan '16

21 Jan '16

Since v2: - static names of daemons are passed to virNetServerNew directly, instead of creating an array of names like the previous version did - dropped client-side server identification through ID, only name is used - adjusted naming of some methods (prefixes again...) - converted the server listing example to virt-admin command (finally) Erik Skultety (6): rpc: Introduce new element 'name' to virnetserver structure virnetdaemon: Add post exec restart support for multiple servers admin: Move admin_server.{h,c} to admin.{h,c} admin: Introduce virAdmServer structure admin: Introduce adminDaemonConnectListServers API virt-admin: Introduce cmdSrvList daemon/Makefile.am | 6 +- daemon/admin.c | 181 +++++++++++++++++++++ daemon/admin.h | 36 ++++ daemon/admin_server.c | 121 +++++--------- daemon/admin_server.h | 23 ++- daemon/libvirtd.c | 4 +- include/libvirt/libvirt-admin.h | 11 ++ po/POTFILES.in | 2 +- src/admin/admin_protocol.x | 26 ++- src/admin_protocol-structs | 15 ++ src/datatypes.c | 36 ++++ src/datatypes.h | 34 ++++ src/libvirt-admin.c | 148 +++++++++++++++++ src/libvirt_admin_private.syms | 5 + src/libvirt_admin_public.syms | 3 + src/locking/lock_daemon.c | 3 +- src/logging/log_daemon.c | 3 +- src/lxc/lxc_controller.c | 2 +- src/rpc/virnetdaemon.c | 15 ++ src/rpc/virnetdaemon.h | 3 + src/rpc/virnetserver.c | 32 +++- src/rpc/virnetserver.h | 5 + .../input-data-admin-server-names.json | 128 +++++++++++++++ .../virnetdaemondata/output-data-admin-nomdns.json | 2 + .../output-data-admin-server-names.json | 128 +++++++++++++++ .../virnetdaemondata/output-data-anon-clients.json | 1 + .../output-data-initial-nomdns.json | 1 + tests/virnetdaemondata/output-data-initial.json | 1 + tests/virnetdaemontest.c | 40 ++--- tools/virt-admin.c | 62 +++++++ 30 files changed, 946 insertions(+), 131 deletions(-) create mode 100644 daemon/admin.c create mode 100644 daemon/admin.h create mode 100644 tests/virnetdaemondata/input-data-admin-server-names.json create mode 100644 tests/virnetdaemondata/output-data-admin-server-names.json -- 2.4.3

2 12

[libvirt] [PATCH V2 0/9] support multi-thread compress migration.
by ShaoHe Feng 18 Jan '16

18 Jan '16

These series patches support multi-thread compress during live migration. Eli Qiao (4): Add test cases for qemuMonitorJSONGetMigrationParameter remote: Add support for set and get multil thread migration parameters qemu_driver: Add support to set/get migration parameters. virsh: Add set and get multi-thread migration parameters commands ShaoHe Feng (5): qemu_migration: Add support for mutil-thread compressed migration enable qemu: Add monitor API for get/set migration parameters set multi-thread compress params for Migrate3 during live migration virsh: add multi-thread migration option for live migrate command Implement the public APIs for multi-thread compress parameters. .gnulib | 2 +- daemon/remote.c | 62 +++++++++++ include/libvirt/libvirt-domain.h | 31 ++++++ src/driver-hypervisor.h | 14 +++ src/libvirt-domain.c | 110 +++++++++++++++++++ src/libvirt_public.syms | 5 + src/qemu/qemu_domain.h | 3 + src/qemu/qemu_driver.c | 186 ++++++++++++++++++++++++++++++++ src/qemu/qemu_migration.c | 105 ++++++++++++++++++ src/qemu/qemu_migration.h | 32 ++++-- src/qemu/qemu_monitor.c | 40 ++++++- src/qemu/qemu_monitor.h | 11 ++ src/qemu/qemu_monitor_json.c | 93 ++++++++++++++++ src/qemu/qemu_monitor_json.h | 9 ++ src/qemu/qemu_monitor_text.c | 95 +++++++++++++++++ src/qemu/qemu_monitor_text.h | 10 ++ src/remote/remote_driver.c | 54 ++++++++++ src/remote/remote_protocol.x | 30 +++++- src/remote_protocol-structs | 26 +++++ tests/qemumonitorjsontest.c | 53 ++++++++++ tools/virsh-domain.c | 223 ++++++++++++++++++++++++++++++++++++++- tools/virsh.pod | 37 +++++-- 22 files changed, 1212 insertions(+), 19 deletions(-) -- 2.1.4

4 19

[libvirt] Trying to debug "Received unexpected event 3" from libvirt
by Yaniv Kaul 16 Jan '16

16 Jan '16

Hi, I'm trying to debug this issue, which may be affecting my inability to perform live snapshot. 1. I'm not sure what 'Waking up a tragedian" in the debug log means - what exactly is a tragedian? 2. In any case, it'd be great if the WARN would mention mon->await_event - is it the event libvirt is actually waiting for? (Both from qemu/qemu_agent.c) 3. I reckon event 3 is QEMU_AGENT_EVENT_RESET ? (from qemu/qemu_agent.h) 4. I'm also getting 'End of file while reading data: Input/output error' messages, not sure what they mean yet. (using 1.2.18.2-1 on FC23, trying to live-snapshot VMs (with Centos 6 & 7 in them, all with qemu guest agent, AFAIK). TIA, Y.

2 5

[libvirt] [PATCH 0/3] Misc fixes
by Cédric Bosdonnat 15 Jan '16

15 Jan '16

Hi all, Here are a few patches without strong connection together. The first one only allows us not to package virt-login-shell even with lxc driver enabled. The other ones are related to mounts security. I'm wondering if changing the default dropped capabilities in the lxc driver is acceptable... dropping sys_admin makes sense, but it can introduce incompatibilities for users needing it as they will need to explicitely enable it. Cédric Bosdonnat (3): Allow building lxc without virt-login-shell virt-aa-helper: don't deny writes to readonly mounts lxc: drop sys_admin caps by default configure.ac | 14 ++++++++++++++ src/lxc/lxc_container.c | 1 + src/security/virt-aa-helper.c | 5 ++++- tools/Makefile.am | 12 ++++++------ 4 files changed, 25 insertions(+), 7 deletions(-) -- 2.1.4

5 8

[libvirt] [RFC] memory settings interface for containers
by Nikolay Shirokovskiy 14 Jan '16

14 Jan '16

Hi, everyone. I plan to add means to configure vz containers memory setting and have trouble getting it done thru libvirt interface. Looks like current interface fits good for vm memory managment but its not clear how to use it with containers. First let's take aside memory hotplugging which is obviously not suitable for containers. Then memory interface is represented by 2 parameters: total_memory and cur_balloon. For VMs total_memory can't be changed at runtime, cur_ballon can't be greater than total_memory. But for containers memory model is different. We have only one parameter and it can be changed for running domains. So question is how to map this model to existing interface (it is unlikely to have a new interface for this case). I plan to make both parameters to have same meaning and be equal for containers and update virsh, API and xml model documentation accordingly. I'd be happy to hear core developers opinions on this topic.

4 10

[libvirt] Bug in RPC code causes failure to start LXC container using virDomainCreateXMLWithFiles
by Ben Gray 12 Jan '16

12 Jan '16

Hi, Occasionally when trying to start LXC containers with fds I get the following error: virNetMessageDupFD:562 : Unable to duplicate FD -1: Bad file descriptor I tracked it down to the code that handles EAGAIN errors from recvfd. In such cases the virNetMessageDecodeNumFDs function may be called multiple times from virNetServerClientDispatchRead and each time it overwrites the msg->fds array. In the best case (when msg->donefds == 0) this results in a memory leak, in the worse case it will leak any fd's already in msg->fds and cause subsequent failures when dup is called. A very similar problem is mention here: https://www.redhat.com/archives/libvir-list/2012-December/msg01306.html Below is my patch to fix the issue. --- a/src/rpc/virnetserverclient.c 2015-01-23 11:46:24.000000000 +0000 +++ b/src/rpc/virnetserverclient.c 2015-11-26 15:30:51.214462290 +0000 @@ -1107,36 +1107,40 @@ /* Now figure out if we need to read more data to get some * file descriptors */ - if (msg->header.type == VIR_NET_CALL_WITH_FDS && - virNetMessageDecodeNumFDs(msg) < 0) { - virNetMessageQueueServe(&client->rx); - virNetMessageFree(msg); - client->wantClose = true; - return; /* Error */ - } + if (msg->header.type == VIR_NET_CALL_WITH_FDS) { + size_t i; - /* Try getting the file descriptors (may fail if blocking) */ - for (i = msg->donefds; i < msg->nfds; i++) { - int rv; - if ((rv = virNetSocketRecvFD(client->sock, &(msg->fds[i]))) < 0) { + if (msg->nfds == 0 && + virNetMessageDecodeNumFDs(msg) < 0) { virNetMessageQueueServe(&client->rx); virNetMessageFree(msg); client->wantClose = true; - return; + return; /* Error */ } - if (rv == 0) /* Blocking */ - break; - msg->donefds++; - } - /* Need to poll() until FDs arrive */ - if (msg->donefds < msg->nfds) { - /* Because DecodeHeader/NumFDs reset bufferOffset, we - * put it back to what it was, so everything works - * again next time we run this method - */ - client->rx->bufferOffset = client->rx->bufferLength; - return; + /* Try getting the file descriptors (may fail if blocking) */ + for (i = msg->donefds; i < msg->nfds; i++) { + int rv; + if ((rv = virNetSocketRecvFD(client->sock, &(msg->fds[i]))) < 0) { + virNetMessageQueueServe(&client->rx); + virNetMessageFree(msg); + client->wantClose = true; + return; + } + if (rv == 0) /* Blocking */ + break; + msg->donefds++; + } + + /* Need to poll() until FDs arrive */ + if (msg->donefds < msg->nfds) { + /* Because DecodeHeader/NumFDs reset bufferOffset, we + * put it back to what it was, so everything works + * again next time we run this method + */ + client->rx->bufferOffset = client->rx->bufferLength; + return; + } } /* Definitely finished reading, so remove from queue */

2 1