- Devel - libvirt List Archives

[libvirt] [PATCH 0/6] tests: misc collection of improvments
by Cole Robinson 12 Jan '16

12 Jan '16

Small collection of test suite improvements that were getting mixed in with other patches I'm working on. Patch #1 is a REGENERATE tweak for qemu argvs (this is already on list) Patch #2 fixes running schema tests from top git dir Patch #3-4 simplify the domain xml2xml tests Patch #5 adds a new driver agnostic genericxml2xml test (to be used later) Patch #6 adds QEMUCaps plumbing to qemuxml2xml (to be used later) Cole Robinson (6): tests: Add newlines with VIR_TEST_REGENERATE_OUTPUT tests: Fix running schematests directly from topdir tests: Share domain XML2XML compare helper tests: qemuxml2xml: drop early file loading tests: add genericxml2xmltest tests: qemuxml2xml: Wire up QEMUCaps usage tests/Makefile.am | 9 ++ tests/bhyvexml2xmltest.c | 30 +------ tests/capabilityschematest | 2 +- tests/domaincapsschematest | 2 +- tests/domainschematest | 4 +- tests/domainsnapshotschematest | 2 +- tests/genericxml2xmlindata/generic-disk-virtio.xml | 45 ++++++++++ .../genericxml2xmloutdata/generic-disk-virtio.xml | 45 ++++++++++ tests/genericxml2xmltest.c | 83 +++++++++++++++++++ tests/interfaceschematest | 2 +- tests/lxcxml2xmltest.c | 50 +---------- tests/networkschematest | 2 +- tests/nodedevschematest | 2 +- tests/nwfilterschematest | 2 +- tests/qemuxml2xmltest.c | 96 ++++++---------------- tests/secretschematest | 2 +- tests/storagepoolschematest | 2 +- tests/storagevolschematest | 2 +- tests/test-lib.sh | 9 +- tests/testutils.c | 47 ++++++++++- tests/testutils.h | 6 ++ 21 files changed, 281 insertions(+), 163 deletions(-) create mode 100644 tests/genericxml2xmlindata/generic-disk-virtio.xml create mode 100644 tests/genericxml2xmloutdata/generic-disk-virtio.xml create mode 100644 tests/genericxml2xmltest.c -- 2.5.0

3 16

[libvirt] [PATCH] Add missing virxdrdefs.h include to log_protocol
by Roman Bogorodskiy 12 Jan '16

12 Jan '16

Commit 2b6f6ad introduced the virxdrdefs.h header with common definitions to be included in the protocol files, but logging/log_protocol.x was missed, so add it there as well. Hopefully this fixes build on OS X. --- src/logging/log_protocol.x | 1 + 1 file changed, 1 insertion(+) diff --git a/src/logging/log_protocol.x b/src/logging/log_protocol.x index a07334f..b0ac31b 100644 --- a/src/logging/log_protocol.x +++ b/src/logging/log_protocol.x @@ -2,6 +2,7 @@ */ %#include "internal.h" +%#include "virxdrdefs.h" typedef opaque virLogManagerProtocolUUID[VIR_UUID_BUFLEN]; -- 2.4.6

3 3

[libvirt] [PATCH 0/3] fix qemu:///session startup errors (bz 1271183)
by Cole Robinson 12 Jan '16

12 Jan '16

libguestfs and gnome-boxes users have been reporting intermittent qemu:///session launch errors for a while: https://bugzilla.redhat.com/show_bug.cgi?id=1271183 This series fixes it, see individual patches for details Cole Robinson (3): rpc: socket: Minor cleanups rpc: socket: Explicitly error if we exceed retry count rpc: socket: Don't repeatedly attempt to launch daemon src/rpc/virnetsocket.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) -- 2.5.0

2 6

[libvirt] [PATCH V2 0/3] Xen: Support vif outging bandwidth QoS
by Jim Fehlig 12 Jan '16

12 Jan '16

Happy New Year! This small series adds support for specifying vif outgoing rate limits in Xen. The first patch adds support for converting rate limits between sexpr config and domXML. The second patch does the same for xl/xm config. The third patch adds outgoing rate limiting to the libxl driver. V1 here https://www.redhat.com/archives/libvir-list/2015-December/msg00899.html In V2 I've extended support to include the sexpr config format Jim Fehlig (3): xenconfig: support vif bandwidth in sexpr parser and formatter xenconfig: support vif bandwidth in xm and xl parser and formatter libxl: support vif outgoing bandwidth QoS src/libvirt_xenconfig.syms | 1 + src/libxl/libxl_conf.c | 39 +++++++++++++ src/xenconfig/xen_common.c | 30 ++++++++++ src/xenconfig/xen_sxpr.c | 74 +++++++++++++++++++++++++ src/xenconfig/xen_sxpr.h | 2 + tests/sexpr2xmldata/sexpr2xml-vif-rate.sexpr | 11 ++++ tests/sexpr2xmldata/sexpr2xml-vif-rate.xml | 51 +++++++++++++++++ tests/sexpr2xmltest.c | 2 + tests/xlconfigdata/test-vif-rate.cfg | 26 +++++++++ tests/xlconfigdata/test-vif-rate.xml | 57 +++++++++++++++++++ tests/xlconfigtest.c | 1 + tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr | 10 ++++ tests/xml2sexprdata/xml2sexpr-fv-net-rate.xml | 34 ++++++++++++ tests/xml2sexprtest.c | 1 + 14 files changed, 339 insertions(+) create mode 100644 tests/sexpr2xmldata/sexpr2xml-vif-rate.sexpr create mode 100644 tests/sexpr2xmldata/sexpr2xml-vif-rate.xml create mode 100644 tests/xlconfigdata/test-vif-rate.cfg create mode 100644 tests/xlconfigdata/test-vif-rate.xml create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-rate.sexpr create mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-rate.xml -- 2.1.4

3 6

[libvirt] [PATCH v3 00/14] Use macros for more common virsh command options
by John Ferlan 12 Jan '16

12 Jan '16

v2: http://www.redhat.com/archives/libvir-list/2015-December/msg00766.html Changes since v2: Use VIRSH_COMMON_OPT_<optname> for option prefix instead of VIRSH_<optname>_OPT_COMMON Patches have a few thumbs up already, figured I'd post it one last time for perusal and checks of the naming 'algorithm. John Ferlan (14): virsh: Covert VSH_POOL_ macro to VIRSH_COMMON_OPT_ virsh: Move VIRSH_COMMON_OPT_POOL to virsh.h virsh: Create macro for common "domain" option virsh: Create macro for common "persistent" option virsh: Create macro for common "config" option virsh: Create macro for common "live" option virsh: Create macro for common "current" option virsh: Create macro for common "file" option virsh: Create macros for common "pool" options virsh: Create macros for common "vol" options virsh: Have domain-monitor use common "domain" option virsh: have snapshot use common "domain" option virsh: Create macro for common "network" option virsh: Create macro for common "interface" option po/POTFILES.in | 1 + tools/virsh-domain-monitor.c | 77 +--- tools/virsh-domain.c | 911 +++++++++---------------------------------- tools/virsh-interface.c | 37 +- tools/virsh-network.c | 61 +-- tools/virsh-pool.c | 71 ++-- tools/virsh-snapshot.c | 60 +-- tools/virsh-volume.c | 148 ++----- tools/virsh.h | 17 + 9 files changed, 334 insertions(+), 1049 deletions(-) -- 2.5.0

4 45

Re: [libvirt] [PATCH 1/4] cgroup: Fix possible bug as a result of code motion for vcpu cgroup setup
by Henning Schild 12 Jan '16

12 Jan '16

On Mon, 11 Jan 2016 13:50:32 -0500 John Ferlan <jferlan(a)redhat.com> wrote: > Commit id '90b721e43' moved where the virCgroupAddTask was made until > after the check for the vcpupin checks. However, in doing so it missed > an option where if the cpumap didn't exist, then the code would > continue back to the top of the current vcpu loop. The results was > that the virCgroupAddTask wouldn't be called. > > Signed-off-by: John Ferlan <jferlan(a)redhat.com> > --- > src/qemu/qemu_cgroup.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c > index 1c406ce..91b3328 100644 > --- a/src/qemu/qemu_cgroup.c > +++ b/src/qemu/qemu_cgroup.c > @@ -1079,10 +1079,7 @@ qemuSetupCgroupForVcpu(virDomainObjPtr vm) > } > } > > - if (!cpumap) > - continue; > - > - if (qemuSetupCgroupCpusetCpus(cgroup_vcpu, cpumap) < 0) > + if (cpumap && qemuSetupCgroupCpusetCpus(cgroup_vcpu, > cpumap) < 0) goto cleanup; > } > Good catch, should be applied! Henning

1 0

Re: [libvirt] Fwd: DNS for IPv6 addresses?
by hongming 12 Jan '16

12 Jan '16

Hi Yaniv Please refer to the following . [root@localhost images]# virsh net-dumpxml dhcp <network connections='2'> <name>dhcp</name> <uuid>066f0d89-67a6-42c8-bdeb-ed9420aaaf4f</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr4' stp='on' delay='0'/> <mac address='52:54:00:c8:29:9f'/> <ip address='192.168.123.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.123.2' end='192.168.123.254'/> </dhcp> </ip> <ip family='ipv6' address='2001:db8:ca2:2::1' prefix='64'> <dhcp> <range start='2001:db8:ca2:2:1::10' end='2001:db8:ca2:2:1::ff'/> </dhcp> </ip> </network> [root@localhost images]# virsh dumpxml rhel7.1|grep /interface -B7 <interface type='network'> <mac address='52:54:00:82:49:b1'/> <source network='dhcp' bridge='virbr4'/> <target dev='vnet1'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> [root@localhost images]# virsh domifaddr rhel7.1 --source lease Name MAC address Protocol Address ------------------------------------------------------------------------------- vnet1 52:54:00:82:49:b1 ipv4 192.168.123.171/24 - - ipv6 2001:db8:ca2:2:1::1a/64 [root@localhost images]# cat /var/lib/libvirt/dnsmasq/virbr4.status [ { "ip-address": "192.168.123.171", "mac-address": "52:54:00:82:49:b1", "expiry-time": 1452594968 }, { "iaid": "8538545", "ip-address": "2001:db8:ca2:2:1::1a", "mac-address": "52:54:00:82:49:b1", "client-id": "00:04:ee:53:b7:a8:c7:46:ab:95:d0:86:88:ee:6e:51:a0:2a", "server-duid": "", "expiry-time": 1452594971 } ] Login guest to check ipv6 address . It is the same as the result returned by "domifaddr" Thanks Hongming On 01/11/2016 03:24 PM, Min Zhan wrote: > @shyu, > > Could you help have a look and reply this question? > > Regards, > Min Zhan > > ----- Forwarded Message ----- >> From: "Yaniv Kaul" <ykaul(a)redhat.com> >> To: libvirt-list(a)redhat.com >> Sent: Friday, January 8, 2016 5:40:09 PM >> Subject: [libvirt] DNS for IPv6 addresses? >> >> Is there a way to define DNS for IPv6 addresses? >> Something like: >> <dns forwardPlainNames =" yes " > >> <host ip =" 192.168.200.4 " > >> <hostname> lago_basic_suite_3_6_storage-iscsi </hostname> >> </host> >> </dns> >> >> >> >> Only for IPv6? >> I reckon I can't just use an IPv6 address in the 'IP' attribute? >> >> TIA, >> Y. >> >> -- >> libvir-list mailing list >> libvir-list(a)redhat.com >> https://www.redhat.com/mailman/listinfo/libvir-list

1 0

[libvirt] Software Offloading Performance Issue on increasing VM's (TSO enabled ) pushing traffic
by Piyush R Srivastava1 12 Jan '16

12 Jan '16

Hi, Problem- Offloading (in Software) for VM generated packets ( TSO enabled in VM's ) degrades severely with increase in VM's on a host. On increasing VM's ( which are pushing traffic simultaneously ) on a compute node- - % offloaded packets coming out of VM's ( TSO enabled ) on tap port / veth-pair decreases significantly - Size of offloaded packets coming out of VM's (TSO enabled ) on tap porty / veth pair decreases significantly We are using OpenStack setup. Throughput for SNAT Test ( iperf client at VM and server at external network machine ) is SIGNIFICANTLY less that DNAT Test ( server at VM and client at external network machine). For 50 VM's ( 25 VM on each compute node on a 2 Compute Node setup ) SNAT throughput is 30% less than DNAT Throughput. I was hoping to get community feedback on what is controlling the software offloading of VM packets and how can we improve it ? NOTE- This seems to be one of the bottlenecks in SNAT which is affecting throughput at TX side on Compute Node. Improving this would help in improving SNAT test network performance. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Description- We have a testbed OpenStack deployment. We boot 1, 10 and 25 VM's on a single compute node and start iperf traffic. ( VM's are iperf client ). We then simultaneously do tcpdump at the veth-pair connecting the VM to the OVS Bridges. Tcpdump data shows that on increasing the VM's on a host, the % of offloaded packets degrades severely ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Host configuration- 12 cores ( 24 vCPU ), 40 GB RAM [root rhel7-25 ~]# uname -a Linux rhel7-25.in.ibm.com 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux VM MTU is set to 1450 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Analysis- Following is the % of non-offloaded packets observed at the tap ports / veth pair ( connected to VM's TO OVS Bridge ) ------------------------------------ | VMs on 1 Compute Node | % Non-Offloaded packets | |-----------------------------------| | 1 | 11.11% | | 10 | 71.78% | | 25 | 80.44% | |----|--------- | Thus we see significant degradation in offloaded packets when 10 and 25 VM's are sending iperf data simultaneously. ( TSO enabled VM's ) Non-Offloaded packets means Ethernet Frame of size 1464 ( VM MTU is 1450 ). Thus the packets coming out of the VM's (TSO enabled ) are majority non-offloaded as we increase VM's on a host. ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Tcpdump details- Iperf Server IP- 1.1.1.34 For 1 VM, we see majority offloaded packets and also large sized offloaded frames- [piyush rhel7-34 25]$ cat qvoed7aa38d-22.log | grep "> 1.1.1.34.5001" | head -n 30 14:36:26.331073 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 74: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 0 14:36:26.331917 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 66: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 0 14:36:26.331946 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 90: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 24 14:36:26.331977 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 7056: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 6990 14:36:26.332018 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 5658: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 5592 14:36:26.332527 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 7056: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 6990 14:36:26.332560 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 9852: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 9786 14:36:26.333024 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 8454: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 8388 14:36:26.333054 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 7056: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 6990 14:36:26.333076 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 4260: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 4194 14:36:26.333530 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 16842: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 16776 14:36:26.333568 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 4260: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 4194 14:36:26.333886 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 21036: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 20970 14:36:26.333925 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 2862: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 2796 14:36:26.334303 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 21036: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 20970 14:36:26.334349 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 2862: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 2796 14:36:26.334741 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 22434: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 22368 14:36:26.335118 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 25230: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 25164 14:36:26.335566 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 25230: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 25164 14:36:26.336007 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 23832: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 23766 For 20 VM's, we see reduction is size of offloaded packets and also the size of offloaded packets is reduced. Tcpdump for one of the 10 VM's ( similar characterization for all 10 VM's )- [piyush rhel7-34 25]$ cat qvo255d8cdd-90.log | grep "> 1.1.1.34.5001" | head -n 30 15:09:25.024790 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 74: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 0 15:09:25.026834 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 66: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 0 15:09:25.026870 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 90: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 24 15:09:25.027186 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.027213 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 5658: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 5592 15:09:25.032500 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 5658: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 5592 15:09:25.032539 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 1464: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 1398 15:09:25.032567 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.035122 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.035631 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.035661 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.038508 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.038904 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 15:09:25.039300 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 7056: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 6990 For 25 VM's, we see very less offloaded packets and also the size of offloaded packets is reduced. Tcpdump for one of the 25 VM's ( similar characterization for all 25 VM's )- 15:52:31.544316 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.544340 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545034 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545066 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 5658: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 5592 15:52:31.545474 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545501 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 2862: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 2796 15:52:31.545539 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 2862: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 2796 15:52:31.545572 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 7056: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 6990 15:52:31.545736 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545807 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545813 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545934 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545956 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.545974 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 15:52:31.546012 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 1464: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 1398 Thanks and regards, Piyush Raman Mail: pirsriva(a)in.ibm.com

1 0

[libvirt] [PATCH] virsh: Fix alignment in VIRSH_COMMON_OPT_CONFIG definition
by Andrea Bolognani 12 Jan '16

12 Jan '16

--- Pushed as trivial and safe for freeze. tools/virsh.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/virsh.h b/tools/virsh.h index 94d012a..8b5e5ba 100644 --- a/tools/virsh.h +++ b/tools/virsh.h @@ -78,8 +78,8 @@ # define VIRSH_COMMON_OPT_CONFIG(_helpstr) \ {.name = "config", \ - .type = VSH_OT_BOOL, \ - .help = _helpstr \ + .type = VSH_OT_BOOL, \ + .help = _helpstr \ } \ # define VIRSH_COMMON_OPT_LIVE(_helpstr) \ -- 2.5.0

1 0

[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