- Devel - libvirt List Archives

[libvirt] TSO of VM packets degardes significantly on increasing VM's on a Host
by Piyush R Srivastava1 18 Dec '15

18 Dec '15

Hi, Problem- Offloading for VM packets (TSO enabled in VM's ) degrades severely with increase in VM's on a host What is controlling the offloading of VM packets and how can we improve it ? ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 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- ------------------------------------------------------------------------------------ | VMs | % 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 ) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Tcpdump details- Iperf Server IP- 1.1.1.34 For 1 VM, we see majority offloaded packets- [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 14:36:26.336050 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.336453 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 26628: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 26562 14:36:26.336898 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.336941 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.337235 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 14:36:26.337603 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.337644 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.337987 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 18240: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 18174 14:36:26.338040 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 12648: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 12582 14:36:26.338356 fa:16:3e:98:41:8b > fa:16:3e:ef:5f:16, IPv4, length 14046: 10.20.7.3.50395 > 1.1.1.34.5001: tcp 13980 For 20 VM's, we see reduction is size of offloaded packets. Tcpdump for one of the 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 15:09:25.040740 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 4260: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 4194 15:09:25.040774 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 2862: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 2796 15:09:25.040995 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.041235 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.042599 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.043209 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.043592 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.044312 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.044551 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.045232 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.045251 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.049951 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.049977 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.049996 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.050020 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 2862: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 2796 15:09:25.050039 fa:16:3e:b9:f8:ec > fa:16:3e:c1:de:cc, IPv4, length 4260: 10.20.18.3.36798 > 1.1.1.34.5001: tcp 4194 For 25 VM's, we hardly see very less offloaded packets. Tcpdump for one of the 25 VM's- 15:52:31.543613 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.543637 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.543957 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.544090 fa:16:3e:3c:7d:78 > fa:16:3e:aa:af:d5, IPv4, length 4260: 10.20.10.3.45892 > 1.1.1.34.5001: tcp 4194 15:52:31.544272 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.544296 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.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 0/2] 'deflate-on-oom' attribute for mememory balloon
by Dmitry Andreev 18 Dec '15

18 Dec '15

This patch-set adds support for the new feature that has been added to the QEMU virtio memory balloon a month ago. This feature lets a guest OS deflate balloon on OOM. With 'deflate-on-oom' enabled virtio balloon will release it's memory if possible right before an OOM termination of processes. QEMU commit with the complete feature description: http://git.qemu.org/?p=qemu.git;a=commit;h=e3816255bf4b6377bb405331e2ee0dc1… Dmitry Andreev (2): conf: introduce 'deflate-on-oom' attribute for memballoon device qemu: add support of optional 'deflate-on-oom' attribute docs/formatdomain.html.in | 10 +++++++++ docs/schemas/domaincommon.rng | 5 +++++ src/conf/domain_conf.c | 23 ++++++++++++++++++++ src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 4 ++++ .../qemuxml2argv-balloon-device-deflate-off.args | 23 ++++++++++++++++++++ .../qemuxml2argv-balloon-device-deflate-off.xml | 25 ++++++++++++++++++++++ .../qemuxml2argv-balloon-device-deflate.args | 23 ++++++++++++++++++++ .../qemuxml2argv-balloon-device-deflate.xml | 25 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 4 ++++ 10 files changed, 143 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-device-deflate-off.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-device-deflate-off.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-device-deflate.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-device-deflate.xml -- 1.8.3.1

2 6

[libvirt] [libvirt-perl][PATCH] Add VIR_STORAGE_POOL_CREATE_* constants
by Michal Privoznik 18 Dec '15

18 Dec '15

Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Changes | 4 +++- Virt.xs | 5 +++++ lib/Sys/Virt/StoragePool.pm | 28 ++++++++++++++++++++++++++++ 3 files changed, 36 insertions(+), 1 deletion(-) diff --git a/Changes b/Changes index 0b3e659..05643b5 100644 --- a/Changes +++ b/Changes @@ -2,7 +2,9 @@ Revision history for perl module Sys::Virt 1.3.1 2015-12-00 - - XXX + - Add VIR_STORAGE_POOL_CREATE_NORMAL, VIR_STORAGE_POOL_CREATE_WITH_BUILD, + VIR_STORAGE_POOL_CREATE_WITH_BUILD_OVERWRITE and + VIR_STORAGE_POOL_CREATE_WITH_BUILD_NO_OVERWRITE constants 1.3.0 2015-12-10 diff --git a/Virt.xs b/Virt.xs index db04fc2..4e28887 100644 --- a/Virt.xs +++ b/Virt.xs @@ -8026,6 +8026,11 @@ BOOT: REGISTER_CONSTANT(VIR_STORAGE_POOL_BUILD_NO_OVERWRITE, BUILD_NO_OVERWRITE); REGISTER_CONSTANT(VIR_STORAGE_POOL_BUILD_OVERWRITE, BUILD_OVERWRITE); + REGISTER_CONSTANT(VIR_STORAGE_POOL_CREATE_NORMAL, CREATE_NORMAL); + REGISTER_CONSTANT(VIR_STORAGE_POOL_CREATE_WITH_BUILD, CREATE_WITH_BUILD); + REGISTER_CONSTANT(VIR_STORAGE_POOL_CREATE_WITH_BUILD_OVERWRITE, CREATE_WITH_BUILD_OVERWRITE); + REGISTER_CONSTANT(VIR_STORAGE_POOL_CREATE_WITH_BUILD_NO_OVERWRITE, CREATE_WITH_BUILD_NO_OVERWRITE); + REGISTER_CONSTANT(VIR_STORAGE_POOL_DELETE_NORMAL, DELETE_NORMAL); REGISTER_CONSTANT(VIR_STORAGE_POOL_DELETE_ZEROED, DELETE_ZEROED); diff --git a/lib/Sys/Virt/StoragePool.pm b/lib/Sys/Virt/StoragePool.pm index 7572d62..5fd6acc 100644 --- a/lib/Sys/Virt/StoragePool.pm +++ b/lib/Sys/Virt/StoragePool.pm @@ -355,6 +355,34 @@ Overwrite existing storage pool data =back +=head2 CREATE MODES + +When creating a storage pool it can be built at the same time. +The following values are therefore close to their BUILD +counterparts. + +=over 4 + +=item Sys::Virt::StoragePool::CREATE_NORMAL + +Just create the storage pool without building it. + +=item Sys::Virt::StoragePool::CREATE_WITH_BUILD + +When creating new storage pool also perform pool build without any flags. + +=item Sys::Virt::StoragePool::CREATE_WITH_BUILD_OVERWRITE + +Create the pool and perform pool build using the BUILD_OVERWRITE +flag. This is mutually exclusive to CREATE_WITH_BUILD_NO_OVERWRITE. + +=item Sys::Virt::StoragePool::CREATE_WITH_BUILD_NO_OVERWRITE + +Create the pool and perform pool build using the BUILD_NO_OVERWRITE +flag. This is mutually exclusive to CREATE_WITH_BUILD_OVERWRITE. + +=back + =head2 XML DOCUMENTS The following constants are useful when requesting -- 2.4.10

3 2

[libvirt] [PATCH] lxc_cgroup: Add check for NULL cgroup before AddTask call
by John Ferlan 18 Dec '15

18 Dec '15

Commit id '71ce4759' altered the cgroup processing with respect to the call to virCgroupAddTask being moved out from lower layers into the calling layers especially for qemu processing of emulator and vcpu threads. The movement affected lxc insomuch as it is possible for a code path to return a NULL cgroup *and* a 0 return status via virCgroupNewPartition failure when virCgroupNewIgnoreError succeeded when virCgroupNewMachineManual returns. Coverity pointed out that would cause virCgroupAddTask to core. This patch will check for a NULL cgroup as well as the negative return and just return the NULL cgroup to the caller (as it would have previously) Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/lxc/lxc_cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c index 609e9ea..ef332e3 100644 --- a/src/lxc/lxc_cgroup.c +++ b/src/lxc/lxc_cgroup.c @@ -501,7 +501,7 @@ virCgroupPtr virLXCCgroupCreate(virDomainDefPtr def, nnicindexes, nicindexes, def->resource->partition, -1, - &cgroup) < 0) + &cgroup) < 0 || !cgroup) goto cleanup; if (virCgroupAddTask(cgroup, initpid) < 0) { -- 2.5.0

2 1

[libvirt] [PATCH 0/8] Use macros for more common virsh command options
by John Ferlan 18 Dec '15

18 Dec '15

As a follow on to a recent series which created macros for various virsh-*.c command options, see: http://www.redhat.com/archives/libvir-list/2015-December/msg00672.html (although best to view by index since there are varying opinions on the matter)... Modify virsh-domain.c and virsh-volume.c to "follow" the concept of macro-ifying some commonly used options. In order to choose, I used: $ grep "{.name =" tools/virsh-*.c | \ grep -v "help" | grep -v "desc" | grep -v NULL | \ sort -i | uniq -c | sort -n To generate a list by module. That generated a list where I randomly picked 9 as the nexus, leaving the following: 9 tools/virsh-domain.c: {.name = "persistent", 10 tools/virsh-snapshot.c: {.name = "domain", 12 tools/virsh-network.c: {.name = "network", 12 tools/virsh-pool.c: {.name = "pool", 13 tools/virsh-volume.c: {.name = "vol", 14 tools/virsh-domain.c: {.name = "file", 14 tools/virsh-domain-monitor.c: {.name = "domain", 14 tools/virsh-volume.c: {.name = "pool", 26 tools/virsh-domain.c: {.name = "current", 28 tools/virsh-domain.c: {.name = "config", 28 tools/virsh-domain.c: {.name = "live", 81 tools/virsh-domain.c: {.name = "domain", Because virsh-domain-monitor.c, virsh-network.c, and virsh-snapshot.c only had one element with larger counts - I just left them as is and focused on the virsh-domain.c and virsh-volume.c. The perhaps more controversial choice will be the "file" option in virsh-domain.c which had numerous different helpstr values. I chose to macro-ify them using the entire helpstr including the N_("xxx") rather than just "xxx" since the N_ is the I18N marker. John Ferlan (8): 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 tools/virsh-domain.c | 918 +++++++++++---------------------------------------- tools/virsh-volume.c | 155 +++------ 2 files changed, 247 insertions(+), 826 deletions(-) -- 2.5.0

3 11

[libvirt] [PATCH 0/3] Add delete-snapshots option to virsh commands
by John Ferlan 18 Dec '15

18 Dec '15

Commit id '3c7590e0' added the ability to delete snapshots for rbd backends, but did not provide the virsh commands in order to handle that option. The first two patches fix a couple of minor nits - not using virCheckFlags in virStorageBackendRBDDeleteVol even though the flags are used. Also, the virStorageVolDeleteFlags did not document the possible flags. Added the reference for the API. The third patch is the meat where the --delete-snapshots flag to virsh commands 'undefine' and 'vol-delete' was added and handled. cc'd author of '3c7590e0' - hopefully this series could be applied and tested in a "real" environment. John Ferlan (3): storage: Add virCheckFlags to virStorageBackendRBDDeleteVol libvirt: Add virStorageVolDeleteFlags to virStorageVolDelete virsh: Add --delete-snapshots flag for undefine and vol-delete src/libvirt-storage.c | 2 +- src/storage/storage_backend_rbd.c | 3 +++ tools/virsh-domain.c | 14 +++++++++++++- tools/virsh-volume.c | 12 +++++++++++- tools/virsh.pod | 14 +++++++++++++- 5 files changed, 41 insertions(+), 4 deletions(-) -- 2.5.0

3 6

[libvirt] [PATCH] cpu_map.xml: Expose svm flag for nested kvm on AMD CPU model
by Lin Ma 18 Dec '15

18 Dec '15

QEMU commit 75d373e disables svm by default since PC machine 2.2. So with PC machine version > 2.1, When a user wants to expose the svm flag to a guest, says: ...... <feature policy='require' name='svm'/> ...... The svm flag wont be passed to qemu command line, This patch fixes it. Signed-off-by: Lin Ma <lma(a)suse.com> --- src/cpu/cpu_map.xml | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 0b6d424..8f96843 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -686,7 +686,6 @@ <feature name='sep'/> <feature name='sse'/> <feature name='sse2'/> - <feature name='svm'/> <feature name='syscall'/> <feature name='tsc'/> </model> @@ -1195,7 +1194,6 @@ <feature name='sep'/> <feature name='sse'/> <feature name='sse2'/> - <feature name='svm'/> <feature name='syscall'/> <feature name='tsc'/> </model> @@ -1257,7 +1255,6 @@ <feature name='sep'/> <feature name='sse'/> <feature name='sse2'/> - <feature name='svm'/> <feature name='syscall'/> <feature name='tsc'/> </model> @@ -1295,7 +1292,6 @@ <feature name='sse'/> <feature name='sse2'/> <feature name='sse4a'/> - <feature name='svm'/> <feature name='syscall'/> <feature name='tsc'/> </model> @@ -1341,7 +1337,6 @@ <feature name='sse4.2'/> <feature name='sse4a'/> <feature name='ssse3'/> - <feature name='svm'/> <feature name='syscall'/> <feature name='tsc'/> <feature name='xop'/> @@ -1391,7 +1386,6 @@ <feature name='sse4.2'/> <feature name='sse4a'/> <feature name='ssse3'/> - <feature name='svm'/> <feature name='syscall'/> <feature name='tbm'/> <feature name='tsc'/> -- 2.1.4

1 1

[libvirt] [PATCH 00/16] Xen: remove xend config version
by Jim Fehlig 18 Dec '15

18 Dec '15

Hi All, Ian Campbell recently attempted [1] to fix and issue around MAX_VIRT_VPUS on ARM that required adding a new XEND_CONFIG_VERSION. After some discussion [2] we decided to drop support for all of the old xend config versions and go with the version supported in Xen 4.0, since the xl syntax was originally based on (and intended to be compatible with) xm circa that point in time. This series removes all traces of xend config version from the codebase, essentially removing support for Xen 3.x. Hopefully I succeeding in making the rather large series reviewable. The series is also available on the remove-xend-config-version branch of my libvirt github clone [2]. [1] https://www.redhat.com/archives/libvir-list/2015-November/msg01153.html [2] https://www.redhat.com/archives/libvir-list/2015-December/msg00148.html [3] https://github.com/jfehlig/libvirt/tree/remove-xend-config-version Jim Fehlig (16): Xen: tests: remove old xm config tests Xen: tests: remove net-ioemu xm config test Xen: tests: remove old sexpr2xml tests Xen: tests: remove old xml2sexpr tests Xen: tests: use latest XEND_CONFIG_VERSION in xm/xl tests Xen: xenconfig: remove XEND_CONFIG_VERSION in common code Xen: xenconfig: remove use of XEND_CONFIG_VERSION in xen_xm Xen: xenconfig: remove xendConfigVersion from public functions Xen: tests: use latest XEND_CONFIG_VERSION in sexpr2xml tests Xen: xenconfig: remove disks from '(image)' sexpr Xen: tests: use latest XEND_CONFIG_VERSION in xml2sexpr tests Xen: xenconfig: remove use of XEND_CONFIG_VERSION in xen_sxpr Xen: xen_driver: remove use of XEND_CONFIG_VERSION Xen: xend: remove use of XEND_CONFIG_VERSION Xen: xenconfig: remove xendConfigVersion from public sexpr functions Xen: remove xendConfigVersion from driver private struct src/libxl/libxl_driver.c | 9 +- src/xen/xen_driver.c | 296 ++++----------- src/xen/xen_driver.h | 2 - src/xen/xend_internal.c | 224 ++--------- src/xen/xm_internal.c | 9 +- src/xenconfig/xen_common.c | 211 ++++------- src/xenconfig/xen_common.h | 7 +- src/xenconfig/xen_sxpr.c | 411 ++++++--------------- src/xenconfig/xen_sxpr.h | 21 +- src/xenconfig/xen_xl.c | 9 +- src/xenconfig/xen_xl.h | 7 +- src/xenconfig/xen_xm.c | 57 +-- src/xenconfig/xen_xm.h | 5 +- src/xenconfig/xenxs_private.h | 8 - tests/sexpr2xmldata/sexpr2xml-fv-autoport.xml | 2 +- .../sexpr2xmldata/sexpr2xml-fv-empty-kernel.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-empty-kernel.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-force-hpet.xml | 4 +- .../sexpr2xmldata/sexpr2xml-fv-force-nohpet.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-force-nohpet.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-kernel.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv-localtime.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-localtime.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr | 9 - tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml | 48 --- .../sexpr2xmldata/sexpr2xml-fv-net-netfront.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-net-netfront.xml | 4 +- .../sexpr2xmldata/sexpr2xml-fv-parallel-tcp.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-parallel-tcp.xml | 4 +- .../sexpr2xml-fv-serial-dev-2-ports.sexpr | 5 +- .../sexpr2xml-fv-serial-dev-2-ports.xml | 4 +- .../sexpr2xml-fv-serial-dev-2nd-port.sexpr | 4 +- .../sexpr2xml-fv-serial-dev-2nd-port.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-file.sexpr | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-file.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-null.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-null.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.sexpr | 7 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pipe.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-pty.xml | 4 +- .../sexpr2xmldata/sexpr2xml-fv-serial-stdio.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-stdio.xml | 4 +- .../sexpr2xml-fv-serial-tcp-telnet.sexpr | 3 +- .../sexpr2xml-fv-serial-tcp-telnet.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-tcp.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-udp.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-serial-unix.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-sound-all.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-sound-all.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-sound.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-sound.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-usbmouse.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-usbmouse.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-usbtablet.sexpr | 3 +- tests/sexpr2xmldata/sexpr2xml-fv-usbtablet.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-utc.sexpr | 2 + tests/sexpr2xmldata/sexpr2xml-fv-utc.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-fv-v2.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-fv.sexpr | 4 +- tests/sexpr2xmldata/sexpr2xml-fv.xml | 4 +- tests/sexpr2xmldata/sexpr2xml-no-source-cdrom.xml | 2 +- tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.sexpr | 9 - tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.xml | 34 -- tests/sexpr2xmltest.c | 130 ++++--- .../test-fullvirt-direct-kernel-boot.cfg | 3 +- .../test-fullvirt-direct-kernel-boot.xml | 2 +- tests/xlconfigdata/test-fullvirt-multiusb.cfg | 3 +- tests/xlconfigdata/test-fullvirt-multiusb.xml | 2 +- tests/xlconfigdata/test-new-disk.cfg | 3 +- tests/xlconfigdata/test-new-disk.xml | 2 +- tests/xlconfigdata/test-spice-features.cfg | 3 +- tests/xlconfigdata/test-spice-features.xml | 2 +- tests/xlconfigdata/test-spice.cfg | 3 +- tests/xlconfigdata/test-spice.xml | 2 +- tests/xlconfigtest.c | 29 +- tests/xmconfigdata/test-escape-paths.cfg | 5 +- tests/xmconfigdata/test-escape-paths.xml | 2 +- .../xmconfigdata/test-fullvirt-default-feature.cfg | 5 +- .../xmconfigdata/test-fullvirt-default-feature.xml | 2 +- tests/xmconfigdata/test-fullvirt-force-hpet.cfg | 5 +- tests/xmconfigdata/test-fullvirt-force-hpet.xml | 2 +- tests/xmconfigdata/test-fullvirt-force-nohpet.cfg | 5 +- tests/xmconfigdata/test-fullvirt-force-nohpet.xml | 2 +- tests/xmconfigdata/test-fullvirt-localtime.cfg | 5 +- tests/xmconfigdata/test-fullvirt-localtime.xml | 2 +- tests/xmconfigdata/test-fullvirt-net-ioemu.cfg | 25 -- tests/xmconfigdata/test-fullvirt-net-ioemu.xml | 49 --- tests/xmconfigdata/test-fullvirt-net-netfront.cfg | 3 + tests/xmconfigdata/test-fullvirt-net-netfront.xml | 2 +- tests/xmconfigdata/test-fullvirt-new-cdrom.cfg | 5 +- tests/xmconfigdata/test-fullvirt-new-cdrom.xml | 2 +- tests/xmconfigdata/test-fullvirt-old-cdrom.cfg | 26 -- tests/xmconfigdata/test-fullvirt-old-cdrom.xml | 49 --- tests/xmconfigdata/test-fullvirt-parallel-tcp.cfg | 5 +- tests/xmconfigdata/test-fullvirt-parallel-tcp.xml | 2 +- .../test-fullvirt-serial-dev-2-ports.cfg | 5 +- .../test-fullvirt-serial-dev-2-ports.xml | 2 +- .../test-fullvirt-serial-dev-2nd-port.cfg | 5 +- .../test-fullvirt-serial-dev-2nd-port.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-file.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-file.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-null.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-null.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-pipe.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-pipe.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-pty.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-pty.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-stdio.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-stdio.xml | 2 +- .../test-fullvirt-serial-tcp-telnet.cfg | 5 +- .../test-fullvirt-serial-tcp-telnet.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-tcp.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-tcp.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-udp.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-udp.xml | 2 +- tests/xmconfigdata/test-fullvirt-serial-unix.cfg | 5 +- tests/xmconfigdata/test-fullvirt-serial-unix.xml | 2 +- tests/xmconfigdata/test-fullvirt-sound.cfg | 5 +- tests/xmconfigdata/test-fullvirt-sound.xml | 2 +- tests/xmconfigdata/test-fullvirt-usbmouse.cfg | 5 +- tests/xmconfigdata/test-fullvirt-usbmouse.xml | 2 +- tests/xmconfigdata/test-fullvirt-usbtablet.cfg | 5 +- tests/xmconfigdata/test-fullvirt-usbtablet.xml | 2 +- tests/xmconfigdata/test-fullvirt-utc.cfg | 5 +- tests/xmconfigdata/test-fullvirt-utc.xml | 2 +- tests/xmconfigdata/test-no-source-cdrom.cfg | 5 +- tests/xmconfigdata/test-no-source-cdrom.xml | 2 +- .../test-paravirt-old-pvfb-vncdisplay.cfg | 18 - .../test-paravirt-old-pvfb-vncdisplay.xml | 36 -- tests/xmconfigdata/test-paravirt-old-pvfb.cfg | 17 - tests/xmconfigdata/test-paravirt-old-pvfb.xml | 36 -- tests/xmconfigdata/test-pci-devs.cfg | 5 +- tests/xmconfigdata/test-pci-devs.xml | 2 +- tests/xmconfigtest.c | 94 +++-- tests/xml2sexprdata/xml2sexpr-boot-grub.sexpr | 4 +- tests/xml2sexprdata/xml2sexpr-bridge-ipaddr.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-curmem.sexpr | 2 +- .../xml2sexpr-disk-block-shareable.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-disk-block.sexpr | 2 +- .../xml2sexprdata/xml2sexpr-disk-drv-blkback.sexpr | 2 +- .../xml2sexpr-disk-drv-blktap-qcow.sexpr | 2 +- .../xml2sexpr-disk-drv-blktap-raw.sexpr | 2 +- .../xml2sexprdata/xml2sexpr-disk-drv-blktap.sexpr | 2 +- .../xml2sexpr-disk-drv-blktap2-raw.sexpr | 2 +- .../xml2sexprdata/xml2sexpr-disk-drv-blktap2.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-disk-drv-loop.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-disk-file.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-escape.sexpr | 6 +- tests/xml2sexprdata/xml2sexpr-fv-force-hpet.sexpr | 10 +- .../xml2sexprdata/xml2sexpr-fv-force-nohpet.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-kernel.sexpr | 5 +- tests/xml2sexprdata/xml2sexpr-fv-localtime.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr | 9 - tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml | 31 -- .../xml2sexprdata/xml2sexpr-fv-net-netfront.sexpr | 5 +- .../xml2sexprdata/xml2sexpr-fv-parallel-tcp.sexpr | 10 +- .../xml2sexpr-fv-serial-dev-2-ports.sexpr | 13 +- .../xml2sexpr-fv-serial-dev-2nd-port.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-serial-file.sexpr | 13 +- tests/xml2sexprdata/xml2sexpr-fv-serial-null.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-serial-pipe.sexpr | 13 +- tests/xml2sexprdata/xml2sexpr-fv-serial-pty.sexpr | 10 +- .../xml2sexprdata/xml2sexpr-fv-serial-stdio.sexpr | 10 +- .../xml2sexpr-fv-serial-tcp-telnet.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-serial-tcp.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-serial-udp.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-serial-unix.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-sound.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-usbmouse.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-utc.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-fv-v2.sexpr | 4 +- tests/xml2sexprdata/xml2sexpr-fv-vncunused.sexpr | 4 +- tests/xml2sexprdata/xml2sexpr-fv.sexpr | 10 +- tests/xml2sexprdata/xml2sexpr-net-bridged.sexpr | 3 +- tests/xml2sexprdata/xml2sexpr-net-e1000.sexpr | 3 +- tests/xml2sexprdata/xml2sexpr-net-routed.sexpr | 3 +- .../xml2sexprdata/xml2sexpr-no-source-cdrom.sexpr | 6 +- tests/xml2sexprdata/xml2sexpr-pci-devs.sexpr | 2 +- .../xml2sexpr-pv-bootloader-cmdline.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-pv-bootloader.sexpr | 2 +- tests/xml2sexprdata/xml2sexpr-pv-localtime.sexpr | 6 +- tests/xml2sexprdata/xml2sexpr-pv-vcpus.sexpr | 3 +- .../xml2sexprdata/xml2sexpr-pv-vfb-new-auto.sexpr | 3 +- tests/xml2sexprdata/xml2sexpr-pv-vfb-new.sexpr | 3 +- tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.sexpr | 10 - tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.xml | 23 -- tests/xml2sexprdata/xml2sexpr-pv.sexpr | 3 +- tests/xml2sexprtest.c | 120 +++--- 193 files changed, 919 insertions(+), 1833 deletions(-) delete mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.sexpr delete mode 100644 tests/sexpr2xmldata/sexpr2xml-fv-net-ioemu.xml delete mode 100644 tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.sexpr delete mode 100644 tests/sexpr2xmldata/sexpr2xml-pv-vfb-orig.xml delete mode 100644 tests/xmconfigdata/test-fullvirt-net-ioemu.cfg delete mode 100644 tests/xmconfigdata/test-fullvirt-net-ioemu.xml delete mode 100755 tests/xmconfigdata/test-fullvirt-old-cdrom.cfg delete mode 100644 tests/xmconfigdata/test-fullvirt-old-cdrom.xml delete mode 100644 tests/xmconfigdata/test-paravirt-old-pvfb-vncdisplay.cfg delete mode 100644 tests/xmconfigdata/test-paravirt-old-pvfb-vncdisplay.xml delete mode 100755 tests/xmconfigdata/test-paravirt-old-pvfb.cfg delete mode 100644 tests/xmconfigdata/test-paravirt-old-pvfb.xml delete mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.sexpr delete mode 100644 tests/xml2sexprdata/xml2sexpr-fv-net-ioemu.xml delete mode 100644 tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.sexpr delete mode 100644 tests/xml2sexprdata/xml2sexpr-pv-vfb-orig.xml -- 2.1.4

3 21

[libvirt] [PATH lxc_support_ethernet] fix bug:lxc don't support network type of ethernet
by mark zhong 17 Dec '15

17 Dec '15

for exmple,the xml is: <domain type = 'lxc'> ... <devices> <interface type ="ethernet"> <mac address="02:36:1d:18:2a:e4"/> <ip address='192.168.112.105' family='ipv4' prefix='24'/> <target dev="tap361d182e-14"/> </interface> <devices> </domian> when i start lxc with that xml file,system will report error and start lxc failed Now i create the veth pair and set mac address in lxc if the network type is ethernet Signed-off-by: mark zhong <zhongguocheng1(a)163.com> --- src/lxc/lxc_process.c | 36 ++++++++++++++++++++++++++++++++++++ src/lxc/lxc_process.h | 3 +++ 2 files changed, 39 insertions(+) diff --git a/src/lxc/lxc_process.c b/src/lxc/lxc_process.c index 57e3880..913fe36 100644 --- a/src/lxc/lxc_process.c +++ b/src/lxc/lxc_process.c @@ -359,6 +359,39 @@ char *virLXCProcessSetupInterfaceDirect(virConnectPtr conn, return ret; } +char *virLXCProcessSetupInterfaceEthernet(virDomainDefPtr vm, + virDomainNetDefPtr net) +{ + char *ret = NULL; + char *parentVeth; + char *containerVeth = NULL; + + VIR_DEBUG("calling vethCreate()"); + parentVeth = net->ifname; + if (virNetDevVethCreate(&parentVeth, &containerVeth) < 0) + goto cleanup; + VIR_DEBUG("parentVeth: %s, containerVeth: %s", parentVeth, containerVeth); + + if (net->ifname == NULL) + net->ifname = parentVeth; + + if (virNetDevSetMAC(containerVeth, &net->mac) < 0) + goto cleanup; + + if (virNetDevSetOnline(parentVeth, true) < 0) + goto cleanup; + + if (net->filter && + virDomainConfNWFilterInstantiate(vm->uuid, net) < 0) + goto cleanup; + + ret = containerVeth; + + cleanup: + return ret; +} + + static const char *nsInfoLocal[VIR_LXC_DOMAIN_NAMESPACE_LAST] = { [VIR_LXC_DOMAIN_NAMESPACE_SHARENET] = "net", [VIR_LXC_DOMAIN_NAMESPACE_SHAREIPC] = "ipc", @@ -559,6 +592,9 @@ static int virLXCProcessSetupInterfaces(virConnectPtr conn, break; case VIR_DOMAIN_NET_TYPE_ETHERNET: + if (!(veth = virLXCProcessSetupInterfaceEthernet(def, + net))) + goto cleanup; break; case VIR_DOMAIN_NET_TYPE_USER: diff --git a/src/lxc/lxc_process.h b/src/lxc/lxc_process.h index b6c8083..3b4ade3 100644 --- a/src/lxc/lxc_process.h +++ b/src/lxc/lxc_process.h @@ -53,5 +53,8 @@ char *virLXCProcessSetupInterfaceBridged(virDomainDefPtr vm, char *virLXCProcessSetupInterfaceDirect(virConnectPtr conn, virDomainDefPtr def, virDomainNetDefPtr net); +char *virLXCProcessSetupInterfaceEthernet(virDomainDefPtr vm, + virDomainNetDefPtr net); + #endif /* __LXC_PROCESS_H__ */ -- 2.5.1.windows.1

2 1

[libvirt] [PATCH 0/3] qemu_hotplug: dead code removal
by Ján Tomko 17 Dec '15

17 Dec '15

Originally posted as a part of https://www.redhat.com/archives/libvir-list/2015-August/msg00521.html Ján Tomko (3): qemu_hotplug: remove qemuDomainAttachDeviceControllerLive Remove dead code from qemuDomainAttachControllerDevice mark virDomainVirtioSerialAddrSetAddController as static. src/conf/domain_addr.c | 23 +---------------------- src/conf/domain_addr.h | 8 -------- src/libvirt_private.syms | 2 -- src/qemu/qemu_driver.c | 23 +---------------------- src/qemu/qemu_hotplug.c | 25 +++++++------------------ 5 files changed, 9 insertions(+), 72 deletions(-) -- 2.4.6

2 7

[libvirt] [PATCH v2] Allow building lxc without virt-login-shell
by Cédric Bosdonnat 17 Dec '15

17 Dec '15

Add a configure option to disable virt-login-shell build even if lxc is enabled. --- Diff to V1: * moved the configure.ac code into m4/virt-login-shell.m4 * allow building virt-login-shell without lxc * Introduce WITH_SETUID_RPC_CLIENT to have it built if either lxc or virt-login-shell is built. configure.ac | 9 +++++++++ m4/virt-login-shell.m4 | 27 +++++++++++++++++++++++++++ src/Makefile.am | 4 ++-- tools/Makefile.am | 12 ++++++------ 4 files changed, 44 insertions(+), 8 deletions(-) create mode 100644 m4/virt-login-shell.m4 diff --git a/configure.ac b/configure.ac index f481c50..6fef728 100644 --- a/configure.ac +++ b/configure.ac @@ -1075,6 +1075,14 @@ fi AM_CONDITIONAL([WITH_LXC], [test "$with_lxc" = "yes"]) dnl +dnl Check for virt-login-shell +dnl + +LIBVIRT_CHECK_LOGIN_SHELL + +AM_CONDITIONAL([WITH_SETUID_RPC_CLIENT], [test "$with_lxc$with_login_shell" != "nono"]) + +dnl dnl Checks for the Parallels driver dnl @@ -2974,6 +2982,7 @@ AC_MSG_NOTICE([ Init script: $with_init_script]) AC_MSG_NOTICE([Char device locks: $with_chrdev_lock_files]) AC_MSG_NOTICE([ Default Editor: $DEFAULT_EDITOR]) AC_MSG_NOTICE([ Loader/NVRAM: $with_loader_nvram]) +AC_MSG_NOTICE([ virt-login-shell: $with_login_shell]) AC_MSG_NOTICE([]) AC_MSG_NOTICE([Developer Tools]) AC_MSG_NOTICE([]) diff --git a/m4/virt-login-shell.m4 b/m4/virt-login-shell.m4 new file mode 100644 index 0000000..0701054 --- /dev/null +++ b/m4/virt-login-shell.m4 @@ -0,0 +1,27 @@ +dnl Copyright (c) 2015 SUSE LINUX Products GmbH, Nuernberg, Germany. +dnl +dnl This library is free software; you can redistribute it and/or +dnl modify it under the terms of the GNU Lesser General Public +dnl License as published by the Free Software Foundation; either +dnl version 2.1 of the License, or (at your option) any later version. +dnl +dnl This library is distributed in the hope that it will be useful, +dnl but WITHOUT ANY WARRANTY; without even the implied warranty of +dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +dnl Lesser General Public License for more details. +dnl +dnl You should have received a copy of the GNU Lesser General Public +dnl License along with this library. If not, see +dnl <http://www.gnu.org/licenses/>. + +AC_DEFUN([LIBVIRT_CHECK_LOGIN_SHELL], [ + AC_ARG_WITH([login_shell], + [AS_HELP_STRING([--with-login-shell], + [build virt-login-shell @<:@default=yes@:>@])]) + m4_divert_text([DEFAULTS], [with_login_shell=yes]) + + if test "$with_login_shell" ; then + AC_DEFINE_UNQUOTED([WITH_LOGIN_SHELL], 1, [whether virt-login-shell is built]) + fi + AM_CONDITIONAL([WITH_LOGIN_SHELL], [test "$with_login_shell" = "yes"]) +]) diff --git a/src/Makefile.am b/src/Makefile.am index 99b4993..2f40910 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -2225,7 +2225,7 @@ libvirt_lxc_la_LIBADD = libvirt.la $(CYGWIN_EXTRA_LIBADD) # have a RPC client for local UNIX socket access only. We use # the ../config-post.h header to disable all external deps that # we don't want -if WITH_LXC +if WITH_SETUID_RPC_CLIENT noinst_LTLIBRARIES += libvirt-setuid-rpc-client.la libvirt_setuid_rpc_client_la_SOURCES = \ @@ -2302,7 +2302,7 @@ libvirt_setuid_rpc_client_la_CFLAGS = \ $(SECDRIVER_CFLAGS) \ $(XDR_CFLAGS) \ $(NULL) -endif WITH_LXC +endif WITH_SETUID_RPC_CLIENT lockdriverdir = $(libdir)/libvirt/lock-driver lockdriver_LTLIBRARIES = diff --git a/tools/Makefile.am b/tools/Makefile.am index d5638d9..d005035 100644 --- a/tools/Makefile.am +++ b/tools/Makefile.am @@ -71,12 +71,12 @@ sbin_SCRIPTS = virt-sanlock-cleanup DISTCLEANFILES += virt-sanlock-cleanup endif WITH_SANLOCK -if WITH_LXC +if WITH_LOGIN_SHELL conf_DATA += virt-login-shell.conf bin_PROGRAMS += virt-login-shell -else ! WITH_LXC +else ! WITH_LOGIN_SHELL EXTRA_DIST += virt-login-shell.conf -endif ! WITH_LXC +endif ! WITH_LOGIN_SHELL dist_man1_MANS = \ @@ -84,11 +84,11 @@ dist_man1_MANS = \ virt-pki-validate.1 \ virt-xml-validate.1 \ virsh.1 -if WITH_LXC +if WITH_LOGIN_SHELL dist_man1_MANS += virt-login-shell.1 -else ! WITH_LXC +else ! WITH_LOGIN_SHELL EXTRA_DIST += virt-login-shell.1 -endif ! WITH_LXC +endif ! WITH_LOGIN_SHELL if WITH_SANLOCK dist_man8_MANS = virt-sanlock-cleanup.8 endif WITH_SANLOCK -- 2.1.4

2 1

[libvirt] [PATCH] schema: interleave domain name and uuid with other elements
by Ján Tomko 17 Dec '15

17 Dec '15

Allow <name> and <uuid> anywhere under <domain>, not just at the top: error:XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng Expecting an element name, got nothing Invalid sequence in interleave Element domain failed to validate content Introduced with the first RelaxNG schema in commit c642103. https://bugzilla.redhat.com/show_bug.cgi?id=1292131 --- docs/schemas/domaincommon.rng | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 4804c69..01d99f0 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -30,8 +30,8 @@ <define name="domain"> <element name="domain"> <ref name="hvs"/> - <ref name="ids"/> <interleave> + <ref name="ids"/> <optional> <ref name="title"/> </optional> -- 2.4.6

3 3

[libvirt] [PATCH] qemu: Fix event generated for qemuDomainRevertToSnapshot (pause->run)
by John Ferlan 17 Dec '15

17 Dec '15

A closer review of the code shows that for the transition from paused to running which was supposed to emit the VIR_DOMAIN_EVENT_RESUMED - no event would be generated. Rather the event is generated when going from running to running. Following the 'was_running' boolean shows it is set when the domain obj is active and the domain obj state is VIR_DOMAIN_RUNNING. So rather than using was_running to generate the RESUMED event, use !was_running Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- I hope I've read the bread crumbs in the code correctly regarding state transitions! Saw this while reviewing something else: http://www.redhat.com/archives/libvir-list/2015-December/msg00330.html src/qemu/qemu_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 783a7cd..deeffc1 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -15549,7 +15549,7 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, event = virDomainEventLifecycleNewFromObj(vm, VIR_DOMAIN_EVENT_STARTED, detail); - } else if (was_running) { + } else if (!was_running) { /* Transition 8 */ detail = VIR_DOMAIN_EVENT_RESUMED; event = virDomainEventLifecycleNewFromObj(vm, -- 2.5.0

2 2

[libvirt] [PATCH] storage: Fix startup issue for logical pool
by John Ferlan 17 Dec '15

17 Dec '15

Commit id '71b803ac' assumed that the storage pool source device path was required for a 'logical' pool. This resulted in a failure to start a pool without any device path defined. So, adjust the virStorageBackendLogicalMatchPoolSource logic to return success if at least the pool name matches the vgs output when no pool source device path is/are provided. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/storage/storage_backend_logical.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_backend_logical.c index c52782f..f59684a 100644 --- a/src/storage/storage_backend_logical.c +++ b/src/storage/storage_backend_logical.c @@ -541,6 +541,15 @@ virStorageBackendLogicalMatchPoolSource(virStoragePoolObjPtr pool) goto cleanup; } + /* If the pool has defined source device(s), then let's make sure + * they match as well; otherwise, matching can only occur on the + * pool's name. + */ + if (!pool->def->source.ndevice) { + ret = true; + goto cleanup; + } + /* Let's make sure the pool's device(s) match what the pvs output has * for volume group devices. */ -- 2.5.0

2 1

[libvirt] [PATCH v2] storage: Attempt to refresh volume after successful wipe volume
by John Ferlan 17 Dec '15

17 Dec '15

https://bugzilla.redhat.com/show_bug.cgi?id=1270709 When a volume wipe is successful, perform a volume refresh afterwards to update any volume data that may be used in future volume commands, such as volume resize. For a raw file volume, a wipe could truncate the file and a followup volume resize the capacity may fail because the volume target allocation isn't updated to reflect the wipe activity. Since the documentation doesn't mention this side effect of the zero algorithm for a raw file volume, update the various documentation to describe the results. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- v1: http://www.redhat.com/archives/libvir-list/2015-December/msg00085.html Changes since v1: * Use the preferred call format from review * Cause error if refreshVol fails * Add wording to docs regarding zero wipe algorithm and truncating the raw file. src/libvirt-storage.c | 9 +++++++-- src/storage/storage_driver.c | 9 ++++++++- tools/virsh.pod | 5 +++++ 3 files changed, 20 insertions(+), 3 deletions(-) diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 66dd9f0..62bb999 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -1725,7 +1725,9 @@ virStorageVolDelete(virStorageVolPtr vol, * @vol: pointer to storage volume * @flags: extra flags; not used yet, so callers should always pass 0 * - * Ensure data previously on a volume is not accessible to future reads + * Ensure data previously on a volume is not accessible to future reads. + * Use of this function is equivalent to calling virStorageVolWipePattern + * with the VIR_STORAGE_VOL_WIPE_ALG_ZERO for the algorithm. * * Returns 0 on success, or -1 on error */ @@ -1766,7 +1768,10 @@ virStorageVolWipe(virStorageVolPtr vol, * @flags: future flags, use 0 for now * * Similar to virStorageVolWipe, but one can choose - * between different wiping algorithms. + * between different wiping algorithms. When choosing the + * zero algorithm (VIR_STORAGE_VOL_WIPE_ALG_ZERO), it is + * possible the target storage backend will truncate the + * file rather than writing a stream of zeroes. * * Returns 0 on success, or -1 on error. */ diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index bbf21f6..2531a88 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -2436,7 +2436,14 @@ storageVolWipePattern(virStorageVolPtr obj, goto cleanup; } - ret = backend->wipeVol(obj->conn, pool, vol, algorithm, flags); + if (backend->wipeVol(obj->conn, pool, vol, algorithm, flags) < 0) + goto cleanup; + + if (backend->refreshVol && + backend->refreshVol(obj->conn, pool, vol) < 0) + goto cleanup; + + ret = 0; cleanup: virStoragePoolObjUnlock(pool); diff --git a/tools/virsh.pod b/tools/virsh.pod index 21ae4a3..7f6dc8d 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -3509,6 +3509,11 @@ B<Supported algorithms> B<Note>: The availability of algorithms may be limited by the version of the C<scrub> binary installed on the host. +B<Note>: Use of the zero algorithm for some storage backends may result +in the truncation of the target file instead of writing all zeroes to the +file. The Storage Driver will refresh the volume allocation and capacity +after successful volume wipe completion. + =item B<vol-dumpxml> [I<--pool> I<pool-or-uuid>] I<vol-name-or-key-or-path> Output the volume information as an XML dump to stdout. -- 2.5.0

4 6

[libvirt] [PATCH 0/5] virStorageBackendWipeLocal cleanups
by Ján Tomko 17 Dec '15

17 Dec '15

The first patch fixes the return values of virStorageWipe on non-sparse local files in the case of a partial wipe or a fdatasync error. The rest reduces the number of parameters of virStorageBackendWipe{Extent,}Local. Ján Tomko (5): storage: fix return values of virStorageBackendWipeExtentLocal storage: move buffer allocation inside virStorageBackendWipeExtentLocal storage: drop 'Extent' from virStorageBackendWipeExtentLocal virStorageBackendWipeLocal: use unsigned long long instead of off_t virStorageBackendWipeLocal: remove bytes_wiped argument src/storage/storage_backend.c | 53 +++++++++++++++++-------------------------- 1 file changed, 21 insertions(+), 32 deletions(-) -- 2.4.6

2 8

[libvirt] [PATCH v2 0/7] Memory locking limit improvements
by Andrea Bolognani 17 Dec '15

17 Dec '15

During my testing, I've realized that even with the series applied there's still one case in which we're unable to restore the previous memory locking limit after removing the last PCI hostdev from the guest. If an x86 guest contains a PCI hostdev in its XML definition, then the memory locking limit will be set correctly, but virCommandGetMaxMemLock() will be used instead of virProcessGetMaxMemLock(), and the limit will be set right before calling exec() to spawn the qemu binary. In this context, we have no access to the virDomainObj or even virDomainDef instances, so I see no way of storing the original limit for later retrieval. The series is still an improvement as it covers all other cases. Still, I thought this was worth mentioning. Changes since v1[1]: * reorder commits according to John's suggestions * don't fail if we can't retrieve the current memory locking limit * small changes here and there as pointed out during review Cheers. [1] https://www.redhat.com/archives/libvir-list/2015-November/msg01021.html Andrea Bolognani (7): process: Allow virProcessPrLimit() to get current limit process: Add virProcessGetMaxMemLock() qemu: Add qemuDomainAdjustMaxMemLock() qemu: Use qemuDomainAdjustMaxMemLock() qemu: Reduce memlock limit after detaching PCI hostdev qemu: Allow qemuDomainAdjustMaxMemLock() to restore previous value qemu: Replace Mlock with MemLock in function names configure.ac | 2 +- src/conf/domain_conf.h | 3 +++ src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 4 ++-- src/qemu/qemu_domain.c | 53 ++++++++++++++++++++++++++++++++++++++--- src/qemu/qemu_domain.h | 5 ++-- src/qemu/qemu_hotplug.c | 45 ++++++++++++++--------------------- src/util/virprocess.c | 61 +++++++++++++++++++++++++++++++++++++++++++----- src/util/virprocess.h | 2 ++ 9 files changed, 135 insertions(+), 41 deletions(-) -- 2.5.0

2 9

[libvirt] [PATCH] build: disable vbox on cygwin
by Eric Blake 16 Dec '15

16 Dec '15

Cygwin cannot build the vbox driver yet: CC vbox/libvirt_driver_vbox_impl_la-vbox_glue.lo In file included from vbox/vbox_glue.c:27:0: vblox/vbox_XPCOMCGlue.c:63:3: error: #error "Port me" # error "Port me" ^ In file included from vbox/vbox_XPCOMCGlue.c:45:0, from vbox/vbox_glue.c:27: vbox/vbox_XPCOMCGlue.c: In function 'tryLoadOne': vbox/vbox_XPCOMCGlue.c:98:46: error: 'DYNLIB_NAME' undeclared (first use in this function) if (virAsprintf(&name, "%s/%s", dir, DYNLIB_NAME) < 0) ^ ./util/virstring.h:245:31: note: in definition of macro 'virAsprintf' strp, __VA_ARGS__) ^ Rather than trying to figure out how to get dynamic loading of vbox to work under cygwin (since I don't even have a working vbox setup to test whether it works), I'm going to be lazy and just default to not even trying vbox on cygwin. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Not technically a build-breaker, since I can './configure --without-vbox' to work around it, so I'll wait for a review. configure.ac | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index 75e95b7..2c34333 100644 --- a/configure.ac +++ b/configure.ac @@ -175,12 +175,13 @@ dnl are also linux specific. The "network" and storage_fs drivers are known dnl to not work on MacOS X presently, so we also make a note if compiling dnl for that -with_linux=no with_osx=no with_freebsd=no +with_linux=no with_osx=no with_freebsd=no with_win=no with_cygwin=no case $host in *-*-linux*) with_linux=yes ;; *-*-darwin*) with_osx=yes ;; *-*-freebsd*) with_freebsd=yes ;; *-*-mingw* | *-*-msvc* ) with_win=yes ;; + *-*-cygwin*) with_cygwin=yes ;; esac if test $with_linux = no; then @@ -192,9 +193,12 @@ if test $with_linux = no; then fi if test $with_freebsd = yes; then - want_ifconfig=yes + want_ifconfig=yes + with_firewalld=no +fi - with_firewalld=no +if test $with_cygwin = yes; then + with_vbox=no fi AM_CONDITIONAL([WITH_LINUX], [test "$with_linux" = "yes"]) -- 2.4.3

2 2

[libvirt] LSN-2015-0004: CVE-2015-5313: ACL bypass using ../ to access beyond storage pool
by Eric Blake 16 Dec '15

16 Dec '15

Libvirt Security Notice: LSN-2015-0004 ====================================== Summary: ACL bypass using ../ to access beyond storage pool Reported on: 20151030 Published on: 20151211 Fixed on: 20151211 Reported by: Ossi Herrala <vulncoord(a)ficora.fi> Joonas Kuorilehto <vulncoord(a)ficora.fi> Patched by: Eric Blake <eblake(a)redhat.com> See also: CVE-2015-5313, FICORA bug #876194 Description ----------- Various virStorageVol* API operate on user-supplied volume names by concatenating the volume name to the pool location. Note that the virStoragePoolListVolumes API, when used on a storage pool backed by a directory in a file system, will only list volumes immediately in that directory (there is no traversal into subdirectories). However, other APIs such as virStorageVolCreateXML were not checking if a potential volume name represented one of the volumes that could be returned by virStoragePoolListVolumes; because they were not rejecting the use of '/' in a volume name. Impact ------ Because no checking was done on volume names, a user could supply a potential volume name of something like '../../../etc/passwd' to attempt to access a file not belonging to the storage pool. When fine-grained Access Control Lists (ACL) are in effect, a user with storage_vol:create ACL permission but lacking domain:write permssion could thus abuse virStorageVolCreateXML and similar APIs to gain access to files not normally permitted to that user. Fortunately, it appears that the only APIs that could leak information or corrupt files require read-write connection to libvirtd; and when ACLs are not in use (the default without any further configuration), a user with read-write access can already be considered to have full access to the machine, and without an escalation of privilege there is no security problem. Workaround ---------- If fine-grained ACLs must be used, administrators must consider all of the storage_vol:* permissions as equivalent to domain:write when running an impacted version of libvirt. The easiest way to prevent untrusted users from gaining unauthorized access to volumes outside of permitted pools is by disabling the use of fine-graned ACLs, and ensuring that such users do not have read-write access to libvirtd. Affected product ---------------- Name: libvirt Repository: git://libvirt.org/git/libvirt.git http://libvirt.org/git/?p=libvirt.git Branch: master Broken in: v1.1.0 Broken in: v1.1.1 Broken in: v1.1.2 Broken in: v1.1.3 Broken in: v1.1.4 Broken in: v1.2.0 Broken in: v1.2.1 Broken in: v1.2.2 Broken in: v1.2.3 Broken in: v1.2.4 Broken in: v1.2.5 Broken in: v1.2.6 Broken in: v1.2.7 Broken in: v1.2.8 Broken in: v1.2.9 Broken in: v1.2.10 Broken in: v1.2.11 Broken in: v1.2.12 Broken in: v1.2.13 Broken in: v1.2.14 Broken in: v1.2.15 Broken in: v1.2.16 Broken in: v1.2.17 Broken in: v1.2.18 Broken in: v1.2.19 Broken in: v1.2.20 Broken in: v1.2.20 Broken in: v1.3.0 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 034e47c338b13a95cf02106a3af912c1c5f818d7 Branch: v1.1.0-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 14828a59eadc7221326198a8d7af817a6b8b8c13 Branch: v1.1.1-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 692ce509efa0a07f2811d0fe3b7202b020c874e0 Branch: v1.1.2-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: e8643ef68c99e9f5068f6ff64ea0acab94cac7f6 Branch: v1.1.3-maint Broken in: v1.1.3.1 Broken in: v1.1.3.2 Broken in: v1.1.3.3 Broken in: v1.1.3.4 Broken in: v1.1.3.5 Broken in: v1.1.3.6 Broken in: v1.1.3.7 Broken in: v1.1.3.8 Broken in: v1.1.3.9 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: dcce665904b8ebc9ac3e5109db179a567b33e1a2 Branch: v1.1.4-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: dc2db111a9ba074589c54b90c89f33c01b1e4941 Branch: v1.2.0-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: d414ecb8e1714704e6515ab01ef9386d89b8051e Branch: v1.2.1-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 02d365dae595a3453fe0e438bc274ccf3c18e20d Branch: v1.2.2-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 6542e643024ca4272f14e9052b3786378f6eec62 Branch: v1.2.3-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 91898c606496b14e0891af31dfca7eb77ba9fee3 Branch: v1.2.4-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: c9450f4f855736ef3024dfbab403a849110d8bb5 Branch: v1.2.5-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 890fc0f1ffcc479b08b9fd01de31b62e3d9e7427 Branch: v1.2.6-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 6ae433938377e1b7e657c34cca39e52426347cb4 Branch: v1.2.7-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 4ed8074672f9b847a10464d9c6be77d428c1eb1c Branch: v1.2.8-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 54be99a717873524798d39f8baf49e45054192c8 Branch: v1.2.9-maint Broken in: v1.2.9.1 Broken in: v1.2.9.2 Broken in: v1.2.9.3 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: b0f88836e5eb5b7156bda99c005cf4aa0456ed0d Branch: v1.2.10-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 53ae31bf4df364a2110f636d5482b21af4e4a0cc Branch: v1.2.11-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 0060c4ee9e70a9f6f297373cb4fd2ace6c187be0 Branch: v1.2.12-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: b5ddfbc0fe13a7910c2303056ddd5df749bcf8b0 Branch: v1.2.13-maint Broken in: v1.2.13.1 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: b553ec764f7ecdf8962efbf849a0e8524bae610c Branch: v1.2.14-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 6410a22743fadc3b554b2f0866c9ab8008ff4908 Branch: v1.2.15-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 01cbfeb7d81498db3c644404980c9c1aa9cac048 Branch: v1.2.16-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 3e6b40e5aa3edf47443f017a42ec7b87855ed847 Branch: v1.2.17-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 08acad56ce2e5bcfcca8600a4e4074d3aaeb44dd Branch: v1.2.18-maint Broken in: v1.2.18.1 Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: d035796675ca42795953828d11f902f691fa6b29 Branch: v1.2.19-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 69548d200409d2b0dd6356fccfd59570fb58e23a Branch: v1.2.20-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: edeef640db625d23700011dc94adff6e29b85cd3 Branch: v1.2.21-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 29b4ce46798519b93a6a17a5e3734ea4f68ea69d Branch: v1.3.0-maint Broken by: c930410bebae0a45889b992a7932c663b06cbbcd Fixed by: 1d8bcbb7c68d3f35689daf727bc74fcf80a3a6b1 -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org

1 0

[libvirt] [PATCH 0/5] Fix issues with activating pool with invalid source
by John Ferlan 16 Dec '15

16 Dec '15

These patches resolve issues with 'FS', 'NFS', and 'LOGICAL' pools where if the pool source device didn't match the reality what was running on the host there were inconsistent results. For the file pools, a pool would be declared 'active' after restart even though a start would fail because the check code only cared that the device the pool was using was mounted. Patches 3 alters the check to not only make sure the device is mounted, but that the source for the device matches the source used to start the pool. For the logical pool, a pool could be both started and declared 'active' on restart as long as the "pool->def->source.name" was a valid volume group on the host even though the pool's source device(s) didn't match the same volume group. Usually the pool build process takes care of ensuring not only that the source device exists, but matching the device(s) to the volume group name create (via vgcreate). The reality is pool startup never checked that the volume group name being used by the pool matched the reality of the volume group on the host. Patch 5 will now ensure not only startup matches the name and device list, but that restart setting 'active' would do the same. John Ferlan (5): storage: Create helper to generate FS pool source value storage: Refactor virStorageBackendFileSystemGetPoolSource storage: Check FS pool source during virStorageBackendFileSystemIsMounted storage: Create helper for virStorageBackendLogicalFindPoolSources storage: Add helper to compare logical pool def against pvs output src/storage/storage_backend_fs.c | 73 ++++++++++++----- src/storage/storage_backend_logical.c | 148 +++++++++++++++++++++++++++++----- 2 files changed, 182 insertions(+), 39 deletions(-) -- 2.5.0

3 15

[libvirt] [PATCH 0/6] Add build options to pool create[-as] and start
by John Ferlan 16 Dec '15

16 Dec '15

https://bugzilla.redhat.com/show_bug.cgi?id=830056 Add the capability to build the pool during pool creation or startup NOTE: If patches 2-4 regarding usage of #define for repeated command options are acceptible, I can start doing the same for other virsh commands. I just found it easier and I think better than the need to continually cut-n-paste for each command option entry. If it's preferred to keep cut-n-paste'ing, then I can modify patch 5 & 6 to follow that model. NOTE: Based loosely on patches posted quite a while ago by Osier Yang before he left Red Hat, see: (Cover) https://www.redhat.com/archives/libvir-list/2012-July/msg00494.html and (libvirt API, storage driver changes) https://www.redhat.com/archives/libvir-list/2012-July/msg01328.html and (virsh changes) https://www.redhat.com/archives/libvir-list/2012-July/msg00497.html John Ferlan (6): storage: Add flags to allow building pool during create processing virsh: Create macro for "pool" option virsh: Create macro for "file" option virsh: Create macro for "overwrite" and no-overwrite" options virsh: Create a macro for pool-define-as and pool-create-as options virsh: Add build flags to pool-create[-as] and pool-start include/libvirt/libvirt-storage.h | 16 +- src/libvirt-storage.c | 4 +- src/storage/storage_driver.c | 42 ++++- tools/virsh-pool.c | 360 ++++++++++++++++++++++---------------- tools/virsh.pod | 25 ++- 5 files changed, 288 insertions(+), 159 deletions(-) -- 2.5.0

3 23

[libvirt] [PATCHv2 0/2] notify about reverting to snapshot
by Dmitry Andreev 16 Dec '15

16 Dec '15

Reverting to snapshot may change domain configuration but there will be no events about that. Lack of the event become a problem for virt-manager https://bugzilla.redhat.com/show_bug.cgi?id=1081148 This patch-set introduces new event and emits it in qemuDomainRevertToSnapshot. v2: [2/2] Reworked. John noted that in some error cases I send 'defined' event without changes in configuration. Dmitry Andreev (2): Introduce new VIR_DOMAIN_EVENT_DEFINED_FROM_SNAPSHOT event qemu: emit 'defined' event after reverted to snapshot examples/object-events/event-test.c | 2 ++ include/libvirt/libvirt-domain.h | 1 + src/qemu/qemu_driver.c | 13 +++++++++++-- tools/virsh-domain.c | 3 ++- 4 files changed, 16 insertions(+), 3 deletions(-) -- 1.8.3.1

3 7

[libvirt] [PATCH] qemu: Search all nodes for shared memory access
by Martin Kletzander 16 Dec '15

16 Dec '15

In commit 686eb7a24f7d, the break was not considered part of the condition, hence breaking after first node when searching. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- Pushed as 'trivial' and also John ACKed it earlier. src/qemu/qemu_process.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index ba8dfebd1357..f2740687f655 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4781,9 +4781,10 @@ qemuProcessLaunch(virConnectPtr conn, if (!shmem && vm->def->mem.nhugepages) { for (i = 0; i < virDomainNumaGetNodeCount(vm->def->numa); i++) { if (virDomainNumaGetNodeMemoryAccessMode(vm->def->numa, i) == - VIR_NUMA_MEM_ACCESS_SHARED) + VIR_NUMA_MEM_ACCESS_SHARED) { shmem = true; - break; + break; + } } } -- 2.6.4

1 0

[libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.
by Ian Campbell 16 Dec '15

16 Dec '15

Upstream Xen is in the process of splitting the (stable API) xtl_* interfaces out from the (unstable API) libxenctrl library and into a new (stable API) libxentoollog. In order to be compatible with Xen both before and after this transition check for xtl_createlogger_stdiostream in a libxentoollog library and use it if present. If it is not present assume it is in libxenctrl. Compile tested on Xen 4.6 and a development tree with the split in place. Signed-off-by: Ian Campbell <ian.campbell(a)citrix.com> --- I'm waiting on applying the upstream change until downstreams are prepared for this. The latest upstream patch is http://lists.xen.org/archives/html/xen-devel/2015-12/msg00454.html which had to be reverted because I had somehow not properly checked if libvirt used this interface http://lists.xen.org/archives/html/xen-devel/2015-12/msg01153.html It might be nice to get this into 1.3.0 so that supports Xen 4.7 out of the box? Not sure what the libvirt stable backport policy is but it might also be good to eventually consider it for that? --- configure.ac | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 98cf210..b641cc7 100644 --- a/configure.ac +++ b/configure.ac @@ -883,7 +883,6 @@ if test "$with_libxl" != "no" ; then PKG_CHECK_MODULES([LIBXL], [xenlight], [ LIBXL_FIRMWARE_DIR=`$PKG_CONFIG --variable xenfirmwaredir xenlight` LIBXL_EXECBIN_DIR=`$PKG_CONFIG --variable libexec_bin xenlight` - LIBXL_LIBS="$LIBXL_LIBS -lxenctrl" with_libxl=yes ], [LIBXL_FOUND=no]) if test "$LIBXL_FOUND" = "no"; then @@ -896,7 +895,7 @@ if test "$with_libxl" != "no" ; then LIBS="$LIBS $LIBXL_LIBS" AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [ with_libxl=yes - LIBXL_LIBS="$LIBXL_LIBS -lxenlight -lxenctrl" + LIBXL_LIBS="$LIBXL_LIBS -lxenlight" ],[ if test "$with_libxl" = "yes"; then fail=1 @@ -924,6 +923,14 @@ if test "$with_libxl" = "yes"; then if test "x$LIBXL_EXECBIN_DIR" != "x"; then AC_DEFINE_UNQUOTED([LIBXL_EXECBIN_DIR], ["$LIBXL_EXECBIN_DIR"], [directory containing Xen libexec binaries]) fi + dnl Check if the xtl_* infrastructure is in libxentoollog + dnl (since Xen 4.7) if not then assume it is in libxenctrl + dnl (as it was for 4.6 and earler) + AC_CHECK_LIB([xentoollog], [xtl_createlogger_stdiostream], [ + LIBXL_LIBS="$LIBXL_LIBS -lxentoollog" + ],[ + LIBXL_LIBS="$LIBXL_LIBS -lxenctrl" + ]) fi AM_CONDITIONAL([WITH_LIBXL], [test "$with_libxl" = "yes"]) -- 2.1.4

3 4

[libvirt] [PATCH 0/5] UEFI loader NVRAM image in Qcow2 format
by Dmitry Andreev 16 Dec '15

16 Dec '15

Libvirt allows to specify a path to an image file that will be used as a var storage for UEFI firmware. <nvram>/var/lib/libvirt/nvram/guest_VARS.fd</nvram> By default this image is created as a copy of a master image. The master image and it's copy are stored in 'raw' format. Qemu isn't able to create snapshot for an image in 'raw' format. That makes snapshotting impossible for any UEFI configuration. If the image with UEFI nvram is converted to Qcow2 format (and qemu command is modified appropriately), snapshotting works fine. In the patch-set I introduce 'format' attribute for nvram tag that specifies nvram image file format. The patch-set doesn't contains docs and test in v1. Dmitry Andreev (5): storage: split virStorageBackendCreateExecCommand in two functions storage: refactor: split out image creating tool search function storage: add new function virStorageBackendConvertImage conf: add 'format' attribute to domain/os/nvram element qemu: add support for os.nvram 'format' attribute docs/schemas/domaincommon.rng | 8 ++ src/conf/domain_conf.c | 18 +++++ src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 8 +- src/qemu/qemu_process.c | 17 ++++ src/storage/storage_backend.c | 181 ++++++++++++++++++++++++++---------------- src/storage/storage_backend.h | 5 ++ 7 files changed, 167 insertions(+), 71 deletions(-) -- 1.8.3.1

3 9