- Devel - libvirt List Archives

[libvirt] [PATCH] test: Implement virConnectListAllInterfaces
by Cole Robinson 18 Jul '18

18 Jul '18

This adds some generic virinterfaceobj code, roughly matching what is used by other stateful drivers like network, storage, etc. Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- src/conf/virinterfaceobj.c | 105 +++++++++++++++++++++++++++++++++++++ src/conf/virinterfaceobj.h | 7 +++ src/libvirt_private.syms | 1 + src/test/test_driver.c | 15 ++++++ 4 files changed, 128 insertions(+) diff --git a/src/conf/virinterfaceobj.c b/src/conf/virinterfaceobj.c index a1d7346eb2..87ce188117 100644 --- a/src/conf/virinterfaceobj.c +++ b/src/conf/virinterfaceobj.c @@ -241,6 +241,111 @@ virInterfaceObjListFindByName(virInterfaceObjListPtr interfaces, return obj; } +#define MATCH(FLAG) (flags & (FLAG)) +static bool +virInterfaceMatch(virInterfaceObjPtr obj, + unsigned int flags) +{ + /* filter by active state */ + if (MATCH(VIR_CONNECT_LIST_INTERFACES_FILTERS_ACTIVE) && + !((MATCH(VIR_CONNECT_LIST_INTERFACES_ACTIVE) && + virInterfaceObjIsActive(obj)) || + (MATCH(VIR_CONNECT_LIST_INTERFACES_INACTIVE) && + !virInterfaceObjIsActive(obj)))) + return false; + + return true; +} +#undef MATCH + + +struct virInterfaceObjListData { + virConnectPtr conn; + virInterfacePtr *ifaces; + virInterfaceObjListFilter filter; + unsigned int flags; + int nifaces; + bool error; +}; + +static int +virInterfaceObjListPopulate(void *payload, + const void *name ATTRIBUTE_UNUSED, + void *opaque) +{ + struct virInterfaceObjListData *data = opaque; + virInterfaceObjPtr obj = payload; + virInterfacePtr iface = NULL; + + if (data->error) + return 0; + + virObjectLock(obj); + + if (data->filter && + !data->filter(data->conn, obj->def)) + goto cleanup; + + if (!virInterfaceMatch(obj, data->flags)) + goto cleanup; + + if (!data->ifaces) { + data->nifaces++; + goto cleanup; + } + + if (!(iface = virGetInterface(data->conn, obj->def->name, obj->def->mac))) { + data->error = true; + goto cleanup; + } + + data->ifaces[data->nifaces++] = iface; + + cleanup: + virObjectUnlock(obj); + return 0; +} + + +int +virInterfaceObjListExport(virConnectPtr conn, + virInterfaceObjListPtr ifaceobjs, + virInterfacePtr **ifaces, + virInterfaceObjListFilter filter, + unsigned int flags) +{ + int ret = -1; + struct virInterfaceObjListData data = { + .conn = conn, .ifaces = NULL, .filter = filter, .flags = flags, + .nifaces = 0, .error = false }; + + virObjectRWLockRead(ifaceobjs); + if (ifaces && VIR_ALLOC_N(data.ifaces, + virHashSize(ifaceobjs->objsName) + 1) < 0) + goto cleanup; + + virHashForEach(ifaceobjs->objsName, virInterfaceObjListPopulate, &data); + + if (data.error) + goto cleanup; + + if (data.ifaces) { + /* trim the array to the final size */ + ignore_value(VIR_REALLOC_N(data.ifaces, data.nifaces + 1)); + *ifaces = data.ifaces; + data.ifaces = NULL; + } + + ret = data.nifaces; + cleanup: + virObjectRWUnlock(ifaceobjs); + while (data.ifaces && data.nifaces) + virObjectUnref(data.ifaces[--data.nifaces]); + + VIR_FREE(data.ifaces); + return ret; +} + void virInterfaceObjListDispose(void *obj) diff --git a/src/conf/virinterfaceobj.h b/src/conf/virinterfaceobj.h index 799d38038f..33d2dda05d 100644 --- a/src/conf/virinterfaceobj.h +++ b/src/conf/virinterfaceobj.h @@ -82,4 +82,11 @@ virInterfaceObjListGetNames(virInterfaceObjListPtr interfaces, char **const names, int maxnames); +int +virInterfaceObjListExport(virConnectPtr conn, + virInterfaceObjListPtr ifaceobjs, + virInterfacePtr **ifaces, + virInterfaceObjListFilter filter, + unsigned int flags); + #endif /* __VIRINTERFACEOBJ_H__ */ diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index e688981c3e..ec5ed0cc81 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -961,6 +961,7 @@ virInterfaceObjGetDef; virInterfaceObjIsActive; virInterfaceObjListAssignDef; virInterfaceObjListClone; +virInterfaceObjListExport; virInterfaceObjListFindByMACString; virInterfaceObjListFindByName; virInterfaceObjListGetNames; diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 5494d51017..951d9c4151 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -3828,6 +3828,20 @@ testConnectListDefinedInterfaces(virConnectPtr conn, } +static int +testConnectListAllInterfaces(virConnectPtr conn, + virInterfacePtr **ifaces, + unsigned int flags) +{ + testDriverPtr privconn = conn->privateData; + + virCheckFlags(VIR_CONNECT_LIST_INTERFACES_FILTERS_ACTIVE, -1); + + return virInterfaceObjListExport(conn, privconn->ifaces, ifaces, + NULL, flags); +} + + static virInterfacePtr testInterfaceLookupByName(virConnectPtr conn, const char *name) @@ -6944,6 +6958,7 @@ static virInterfaceDriver testInterfaceDriver = { .connectListInterfaces = testConnectListInterfaces, /* 0.7.0 */ .connectNumOfDefinedInterfaces = testConnectNumOfDefinedInterfaces, /* 0.7.0 */ .connectListDefinedInterfaces = testConnectListDefinedInterfaces, /* 0.7.0 */ + .connectListAllInterfaces = testConnectListAllInterfaces, /* 4.6.0 */ .interfaceLookupByName = testInterfaceLookupByName, /* 0.7.0 */ .interfaceLookupByMACString = testInterfaceLookupByMACString, /* 0.7.0 */ .interfaceGetXMLDesc = testInterfaceGetXMLDesc, /* 0.7.0 */ -- 2.17.1

2 1

[libvirt] [PATCHv2] examples: Add clean-traffic-gateway into nwfilters
by Ales Musil 18 Jul '18

18 Jul '18

The filter purpose is to simulate isolated private VLAN. The behavior can be achieved by limiting network traffic to traffic between VM and gateway. Because there is no concept of the PVLAN in the linux bridge. The filter also contains parts from clean-traffic to prevent VM from spoofing its IP and MAC address. To use this filter the user just needs to set the GATEWAY_MAC variable to gateway MAC address. Signed-off-by: Ales Musil <amusil(a)redhat.com> --- examples/xml/nwfilter/clean-traffic-gateway.xml | 34 +++++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 examples/xml/nwfilter/clean-traffic-gateway.xml diff --git a/examples/xml/nwfilter/clean-traffic-gateway.xml b/examples/xml/nwfilter/clean-traffic-gateway.xml new file mode 100644 index 0000000..b8c2040 --- /dev/null +++ b/examples/xml/nwfilter/clean-traffic-gateway.xml @@ -0,0 +1,34 @@ +<filter name='clean-traffic-gateway'> +  + <filterref filter='no-mac-spoofing'/> + +  + <filterref filter='no-ip-spoofing'/> + +  + <filterref filter='no-arp-spoofing'/> + +  + <rule action='accept' direction='inout' priority='-500'> + <mac protocolid='arp'/> + </rule> + +  + <rule action='accept' direction='in'> + <mac match='yes' srcmacaddr='$GATEWAY_MAC'/> + </rule> + +  + <rule action='accept' direction='out'> + <mac match='yes' dstmacaddr='$GATEWAY_MAC'/> + </rule> + +  + <filterref filter='no-other-l2-traffic'/> + +  + <filterref filter='qemu-announce-self'/> +</filter> -- 1.8.3.1

2 1

[libvirt] [PATCH 0/3] support VLan for virtual network based on 8021q kernel module
by Shi Lei 18 Jul '18

18 Jul '18

Support VLan for virtual network based on 8021q kernel module other than ovs backend. Insert vlan-device into the datapath of the network traffic: (outside of host) <--> physical_interface <--> vlan-dev(with VLAN-Tag) <--> bridge <--> guests Then VLAN-Tag will be applied to the guest's network traffic. The VLan network acts as real layer-2 switch which provides 'access' port to guest. 1. Create VLan network by setting mode='vlan' on the forward element, for example: ... <network> <name>vlan10</name> <forward mode="vlan" dev="eth0"/> <vlan> <tag id="10"/> </vlan> </network> ... The mode attribute of <forward> should be 'vlan' (this patch added). The dev attribute of <forward> specifies a physical interface which forwards traffice between this VLan-network and outside. The id attribue of the vlan tag indicates VLAN-Tag. Both vlan element and tag element should be unique in this xml. A guest connects to this VLan network by setting its xml like this: <interface type='network'> <source network='vlan10'/> </interface> 2. We can enable dhcp for VLan network according to the current way, for example: ... <network> ... <ip address="192.168.126.2" netmask="255.255.255.0"> <dhcp> <range start="192.168.126.120" end="192.168.126.129"/> </dhcp> </ip> </network> ... 3. This can help to build Cross-Host VLan network for guests. We can simplify the work to implement vlan-net of management app (e.g. OpenStack). 1) Distribute the xml of VLan network to all hosts, then 'virsh net-create ...' on each host locally. 2) Makesure the outside switch's port linked to the physical interface (specified by the dev of <forward>) is 'trunk' mode. 3) For each VLan network, ONLY one host can 'net-create' network with ip and dhcp element to avoid dhcp conflict. Shi Lei (3): add functions: load(verify) 8021q module, create/destroy vlan-dev support new forward mode of vlan for virtual network fix other functions to add VIR_NETWORK_FORWARD_VLAN configure.ac | 5 +- src/conf/domain_conf.c | 1 + src/conf/network_conf.c | 12 ++- src/conf/network_conf.h | 1 + src/conf/virnetworkobj.c | 1 + src/libvirt_private.syms | 4 + src/network/bridge_driver.c | 80 ++++++++++++++++-- src/qemu/qemu_process.c | 1 + src/util/virnetdev.c | 195 ++++++++++++++++++++++++++++++++++++++++++++ src/util/virnetdev.h | 14 ++++ 10 files changed, 301 insertions(+), 13 deletions(-) -- 2.7.4

2 10

[libvirt] [PATCH 0/4] qemu: vnc: switch to tls-creds-x509
by Ján Tomko 18 Jul '18

18 Jul '18

Ján Tomko (4): tests: qemu: Remove disk from graphics-vnc-tls FIXDOWN: copy graphics-vnc-tls args to versioned paths tests: qemu: test more versions for graphics-vnc-tls qemu: vnc: switch to tls-creds-x509 src/qemu/qemu_command.c | 26 +++++++++++++---- tests/qemuxml2argvdata/graphics-vnc-tls.args | 2 -- .../graphics-vnc-tls.x86_64-2.4.0.args | 28 ++++++++++++++++++ .../graphics-vnc-tls.x86_64-latest.args | 33 ++++++++++++++++++++++ tests/qemuxml2argvdata/graphics-vnc-tls.xml | 6 ---- tests/qemuxml2argvtest.c | 2 ++ tests/qemuxml2xmloutdata/graphics-vnc-tls.xml | 6 ---- 7 files changed, 83 insertions(+), 20 deletions(-) create mode 100644 tests/qemuxml2argvdata/graphics-vnc-tls.x86_64-2.4.0.args create mode 100644 tests/qemuxml2argvdata/graphics-vnc-tls.x86_64-latest.args -- 2.16.1

3 10

[libvirt] [PATCH] spec: remove libcgroup and cgconfig
by Pavel Hrdina 18 Jul '18

18 Jul '18

RHEL-6/CentOS-6 is no longer supported, let's remove dependency on libcgroup and code that enables/starts cgconfig service. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1602407 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- libvirt.spec.in | 19 ------------------- 1 file changed, 19 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 6f0d399064..6f360c5579 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -80,7 +80,6 @@ # A few optional bits off by default, we enable later %define with_fuse 0%{!?_without_fuse:0} -%define with_cgconfig 0%{!?_without_cgconfig:0} %define with_sanlock 0%{!?_without_sanlock:0} %define with_systemd 0%{!?_without_systemd:0} %define with_numad 0%{!?_without_numad:0} @@ -216,11 +215,6 @@ %endif %endif -# Pull in cgroups config system -%if %{with_qemu} || %{with_lxc} - %define with_cgconfig 0%{!?_without_cgconfig:1} -%endif - # Force QEMU to run as non-root %define qemu_user qemu %define qemu_group qemu @@ -496,9 +490,6 @@ Requires: polkit >= 0.112 %else Requires: polkit >= 0.93 %endif -%if %{with_cgconfig} -Requires: libcgroup -%endif %ifarch %{ix86} x86_64 ia64 # For virConnectGetSysinfo Requires: dmidecode @@ -1490,16 +1481,6 @@ if [ $1 -eq 1 ] ; then fi %endif %else - %if %{with_cgconfig} -# Starting with Fedora 16/RHEL-7, systemd automounts all cgroups, -# and cgconfig is no longer a necessary service. - %if 0%{?rhel} && 0%{?rhel} < 7 -if [ "$1" -eq "1" ]; then -/sbin/chkconfig cgconfig on -fi - %endif - %endif - /sbin/chkconfig --add libvirtd /sbin/chkconfig --add virtlogd /sbin/chkconfig --add virtlockd -- 2.17.1

2 1

[libvirt] [PATCH] docs: formatdomain: unify naming for CPUs/vCPUs
by Katerina Koukiou 18 Jul '18

18 Jul '18

CPU is an acronym and should be written in uppercase when part of plain text and not refering to an element. Signed-off-by: Katerina Koukiou <kkoukiou(a)redhat.com> --- As asked in the review here https://www.redhat.com/archives/libvir-list/2018-July/msg01093.html docs/formatdomain.html.in | 84 +++++++++++++++++++-------------------- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index b00971a945..d08ede9ab5 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -631,45 +631,45 @@ </dd> <dt><code>vcpus</code></dt> <dd> - The vcpus element allows to control state of individual vcpus. + The vcpus element allows to control state of individual vCPUs. The <code>id</code> attribute specifies the vCPU id as used by libvirt - in other places such as vcpu pinning, scheduler information and NUMA - assignment. Note that the vcpu ID as seen in the guest may differ from - libvirt ID in certain cases. Valid IDs are from 0 to the maximum vcpu + in other places such as vCPU pinning, scheduler information and NUMA + assignment. Note that the vCPU ID as seen in the guest may differ from + libvirt ID in certain cases. Valid IDs are from 0 to the maximum vCPU count as set by the <code>vcpu</code> element minus 1. The <code>enabled</code> attribute allows to control the state of the - vcpu. Valid values are <code>yes</code> and <code>no</code>. + vCPU. Valid values are <code>yes</code> and <code>no</code>. - <code>hotpluggable</code> controls whether given vcpu can be hotplugged - and hotunplugged in cases when the cpu is enabled at boot. Note that - all disabled vcpus must be hotpluggable. Valid values are + <code>hotpluggable</code> controls whether given vCPU can be hotplugged + and hotunplugged in cases when the CPU is enabled at boot. Note that + all disabled vCPUs must be hotpluggable. Valid values are <code>yes</code> and <code>no</code>. - <code>order</code> allows to specify the order to add the online vcpus. - For hypervisors/platforms that require to insert multiple vcpus at once - the order may be duplicated across all vcpus that need to be - enabled at once. Specifying order is not necessary, vcpus are then + <code>order</code> allows to specify the order to add the online vCPUs. + For hypervisors/platforms that require to insert multiple vCPUs at once + the order may be duplicated across all vCPUs that need to be + enabled at once. Specifying order is not necessary, vCPUs are then added in an arbitrary order. If order info is used, it must be used for - all online vcpus. Hypervisors may clear or update ordering information + all online vCPUs. Hypervisors may clear or update ordering information during certain operations to assure valid configuration. - Note that hypervisors may create hotpluggable vcpus differently from - boot vcpus thus special initialization may be necessary. + Note that hypervisors may create hotpluggable vCPUs differently from + boot vCPUs thus special initialization may be necessary. - Hypervisors may require that vcpus enabled on boot which are not + Hypervisors may require that vCPUs enabled on boot which are not hotpluggable are clustered at the beginning starting with ID 0. It may - be also required that vcpu 0 is always present and non-hotpluggable. + be also required that vCPU 0 is always present and non-hotpluggable. - Note that providing state for individual cpus may be necessary to enable + Note that providing state for individual CPUs may be necessary to enable support of addressable vCPU hotplug and this feature may not be supported by all hypervisors. - For QEMU the following conditions are required. Vcpu 0 needs to be - enabled and non-hotpluggable. On PPC64 along with it vcpus that are in - the same core need to be enabled as well. All non-hotpluggable cpus - present at boot need to be grouped after vcpu 0. + For QEMU the following conditions are required. vCPU 0 needs to be + enabled and non-hotpluggable. On PPC64 along with it vCPUs that are in + the same core need to be enabled as well. All non-hotpluggable CPUs + present at boot need to be grouped after vCPU 0. Since 2.2.0 (QEMU only) </dd> </dl> @@ -774,11 +774,11 @@ <dt><code>vcpupin</code></dt> <dd> The optional <code>vcpupin</code> element specifies which of host's - physical CPUs the domain VCPU will be pinned to. If this is omitted, + physical CPUs the domain vCPU will be pinned to. If this is omitted, and attribute <code>cpuset</code> of element <code>vcpu</code> is not specified, the vCPU is pinned to all the physical CPUs by default. It contains two required attributes, the attribute <code>vcpu</code> - specifies vcpu id, and the attribute <code>cpuset</code> is same as + specifies vCPU id, and the attribute <code>cpuset</code> is same as attribute <code>cpuset</code> of element <code>vcpu</code>. (NB: Only qemu driver support) Since 0.9.0 @@ -786,7 +786,7 @@ <dt><code>emulatorpin</code></dt> <dd> The optional <code>emulatorpin</code> element specifies which of host - physical CPUs the "emulator", a subset of a domain not including vcpu + physical CPUs the "emulator", a subset of a domain not including vCPU or iothreads will be pinned to. If this is omitted, and attribute <code>cpuset</code> of element <code>vcpu</code> is not specified, "emulator" is pinned to all the physical CPUs by default. It contains @@ -820,7 +820,7 @@ <dt><code>period</code></dt> <dd> The optional <code>period</code> element specifies the enforcement - interval(unit: microseconds). Within <code>period</code>, each vcpu of + interval(unit: microseconds). Within <code>period</code>, each vCPU of the domain will not be allowed to consume more than <code>quota</code> worth of runtime. The value should be in range [1000, 1000000]. A period with value 0 means no value. @@ -835,7 +835,7 @@ vCPU threads, which means that it is not bandwidth controlled. The value should be in range [1000, 18446744073709551] or less than 0. A quota with value 0 means no value. You can use this feature to ensure that all - vcpus run at the same speed. + vCPUs run at the same speed. Only QEMU driver support since 0.9.4, LXC since 0.9.10 </dd> @@ -864,7 +864,7 @@ <dd> The optional <code>emulator_period</code> element specifies the enforcement interval(unit: microseconds). Within <code>emulator_period</code>, emulator - threads(those excluding vcpus) of the domain will not be allowed to consume + threads(those excluding vCPUs) of the domain will not be allowed to consume more than <code>emulator_quota</code> worth of runtime. The value should be in range [1000, 1000000]. A period with value 0 means no value. Only QEMU driver support since 0.10.0 @@ -873,9 +873,9 @@ <dd> The optional <code>emulator_quota</code> element specifies the maximum allowed bandwidth(unit: microseconds) for domain's emulator threads(those - excluding vcpus). A domain with <code>emulator_quota</code> as any negative + excluding vCPUs). A domain with <code>emulator_quota</code> as any negative value indicates that the domain has infinite bandwidth for emulator threads - (those excluding vcpus), which means that it is not bandwidth controlled. + (those excluding vCPUs), which means that it is not bandwidth controlled. The value should be in range [1000, 18446744073709551] or less than 0. A quota with value 0 means no value. Only QEMU driver support since 0.10.0 @@ -2131,13 +2131,13 @@ QEMU, the user-configurable extended TSEG feature was unavailable up to and including <code>pc-q35-2.9</code>. Starting with <code>pc-q35-2.10</code> the feature is available, with default size - 16 MiB. That should suffice for up to roughly 272 VCPUs, 5 GiB guest + 16 MiB. That should suffice for up to roughly 272 vCPUs, 5 GiB guest RAM in total, no hotplug memory range, and 32 GiB of 64-bit PCI MMIO - aperture. Or for 48 VCPUs, with 1TB of guest RAM, no hotplug DIMM + aperture. Or for 48 vCPUs, with 1TB of guest RAM, no hotplug DIMM range, and 32GB of 64-bit PCI MMIO aperture. The values may also vary based on the loader the VM is using. - Additional size might be needed for significantly higher VCPU counts + Additional size might be needed for significantly higher vCPU counts or increased address space (that can be memory, maxMemory, 64-bit PCI MMIO aperture size; roughly 8 MiB of TSEG per 1 TiB of address space) which can also be rounded up. @@ -2147,7 +2147,7 @@ documentation of the guest OS or loader (if there is any), or test this by trial-and-error changing the value until the VM boots successfully. Yet another guiding value for users might be the fact - that 48 MiB should be enough for pretty large guests (240 VCPUs and + that 48 MiB should be enough for pretty large guests (240 vCPUs and 4TB guest RAM), but it is on purpose not set as default as 48 MiB of unavailable RAM might be too much for small guests (e.g. with 512 MiB of RAM). @@ -2425,7 +2425,7 @@ </tr> <tr> <td><code>cpu_cycles</code></td> - <td>the count of cpu cycles (total/elapsed)</td> + <td>the count of CPU cycles (total/elapsed)</td> <td><code>perf.cpu_cycles</code></td> </tr> <tr> @@ -2460,25 +2460,25 @@ </tr> <tr> <td><code>stalled_cycles_frontend</code></td> - <td>the count of stalled cpu cycles in the frontend of the instruction + <td>the count of stalled CPU cycles in the frontend of the instruction processor pipeline by applications running on the platform</td> <td><code>perf.stalled_cycles_frontend</code></td> </tr> <tr> <td><code>stalled_cycles_backend</code></td> - <td>the count of stalled cpu cycles in the backend of the instruction + <td>the count of stalled CPU cycles in the backend of the instruction processor pipeline by applications running on the platform</td> <td><code>perf.stalled_cycles_backend</code></td> </tr> <tr> <td><code>ref_cpu_cycles</code></td> - <td>the count of total cpu cycles not affected by CPU frequency scaling + <td>the count of total CPU cycles not affected by CPU frequency scaling by applications running on the platform</td> <td><code>perf.ref_cpu_cycles</code></td> </tr> <tr> <td><code>cpu_clock</code></td> - <td>the count of cpu clock time, as measured by a monotonic + <td>the count of CPU clock time, as measured by a monotonic high-resolution per-CPU timer, by applications running on the platform</td> <td><code>perf.cpu_clock</code></td> @@ -2505,7 +2505,7 @@ </tr> <tr> <td><code>cpu_migrations</code></td> - <td>the count of cpu migrations, that is, where the process + <td>the count of CPU migrations, that is, where the process moved from one logical processor to another, by applications running on the platform</td> <td><code>perf.cpu_migrations</code></td> @@ -5621,8 +5621,8 @@ qemu-kvm -net nic,model=? /dev/null The resulting difference, according to the qemu developer who added the option is: "bh makes tx more asynchronous and reduces latency, but potentially causes more processor bandwidth - contention since the cpu doing the tx isn't necessarily the - cpu where the guest generated the packets." + contention since the CPU doing the tx isn't necessarily the + CPU where the guest generated the packets." In general you should leave this option alone, unless you are very certain you know what you are doing. -- 2.17.1

2 1

[libvirt] [dbus PATCH] tests: Explicitly spawn a session libvirt-dbus instance
by Andrea Bolognani 18 Jul '18

18 Jul '18

Tests are performed using the session D-Bus instance, so we should launch libvirt-dbus in session mode as well. This was working fine when running the tests as a regular user, because in that case libvirt-dbus would default to session mode, but fail when running them as root because libvirt-dbus would run in system mode and consequently not show up on the session bus. Of course building and runnning the test suite as root is a pretty bad idea in general, but a lot of distributions run at least part of their package build steps with pretend root privileges (eg. fakeroot), so we have to make sure it works in that scenario too. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- tests/libvirttest.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/libvirttest.py b/tests/libvirttest.py index 3741abd..4653055 100644 --- a/tests/libvirttest.py +++ b/tests/libvirttest.py @@ -33,7 +33,7 @@ class BaseTestClass(): """Start libvirt-dbus for each test function """ os.environ['LIBVIRT_DEBUG'] = '3' - self.libvirt_dbus = subprocess.Popen([exe]) + self.libvirt_dbus = subprocess.Popen([exe, '--session']) self.bus = dbus.SessionBus() for i in range(10): -- 2.17.1

2 1

[libvirt] [jenkins-ci PATCH v2 00/12] lcitool: Rewrite in Python (and add Dockefile generator)
by Andrea Bolognani 18 Jul '18

18 Jul '18

Read the initial cover letter for background and motivations. Changes from [v1]: * add Dockerfile generator; * rename the 'list' action to 'hosts' to better fit along with the additional 'projects' action; * always list items in alphabetical order; * move some generic functions to an Util class. [v1] https://www.redhat.com/archives/libvir-list/2018-July/msg00717.html Andrea Bolognani (12): lcitool: Drop shell implementation lcitool: Stub out Python implementation lcitool: Add tool configuration handling lcitool: Add inventory handling lcitool: Implement the 'hosts' action lcitool: Implement the 'install' action lcitool: Implement the 'update' action guests: Update documentation guests: Add Docker-related information to the inventory lcitool: Add projects information handling lcitool: Implement the 'projects' action lcitool: Implement the 'dockerfile' action guests/README.markdown | 8 +- guests/host_vars/libvirt-centos-7/docker.yml | 2 + guests/host_vars/libvirt-debian-8/docker.yml | 2 + guests/host_vars/libvirt-debian-9/docker.yml | 2 + .../host_vars/libvirt-debian-sid/docker.yml | 2 + guests/host_vars/libvirt-fedora-27/docker.yml | 2 + guests/host_vars/libvirt-fedora-28/docker.yml | 2 + .../libvirt-fedora-rawhide/docker.yml | 2 + guests/host_vars/libvirt-ubuntu-16/docker.yml | 2 + guests/host_vars/libvirt-ubuntu-18/docker.yml | 2 + guests/lcitool | 722 ++++++++++++------ 11 files changed, 521 insertions(+), 227 deletions(-) create mode 100644 guests/host_vars/libvirt-centos-7/docker.yml create mode 100644 guests/host_vars/libvirt-debian-8/docker.yml create mode 100644 guests/host_vars/libvirt-debian-9/docker.yml create mode 100644 guests/host_vars/libvirt-debian-sid/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-27/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-28/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-rawhide/docker.yml create mode 100644 guests/host_vars/libvirt-ubuntu-16/docker.yml create mode 100644 guests/host_vars/libvirt-ubuntu-18/docker.yml -- 2.17.1

3 30

[libvirt] [PATCH 0/2] Some additions/fixes in formatdomain docs
by Katerina Koukiou 18 Jul '18

18 Jul '18

Katerina Koukiou (2): docs: formatdomain: add info about global_period and global_quota for cputune docs: formatdomain: clarify period cputune subelement docs/formatdomain.html.in | 31 ++++++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) -- 2.17.1

4 7

[libvirt] [jenkins-ci PATCH v3 00/12] lcitool: Rewrite in Python (and add Dockefile generator)
by Andrea Bolognani 18 Jul '18

18 Jul '18

pylint is reasonably happy with the script now: $ pylint lcitool No config file found, using default configuration ************* Module lcitool C: 1, 0: Missing module docstring (missing-docstring) C: 37, 0: Missing class docstring (missing-docstring) C: 47, 4: Missing method docstring (missing-docstring) W:108,15: Catching too general exception Exception (broad-except) R:427, 4: Too many branches (14/12) (too-many-branches) R:289, 0: Too few public methods (1/2) (too-few-public-methods) ------------------------------------------------------------------- Your code has been rated at 9.21/10 (previous run: 9.21/10, +0.00) The remaining issues are not considered blockers and will be addressed, if at all, later down the line. Changes from [v2]: * address review comments; * improve pycodestyle and pylint compliance; * replace FSF address with an URL. Changes from [v1]: * add Dockerfile generator; * rename the 'list' action to 'hosts' to better fit along with the additional 'projects' action; * always list items in alphabetical order; * move some generic functions to an Util class. [v2] https://www.redhat.com/archives/libvir-list/2018-July/msg00795.html [v1] https://www.redhat.com/archives/libvir-list/2018-July/msg00717.html Andrea Bolognani (12): lcitool: Drop shell implementation lcitool: Stub out Python implementation lcitool: Add tool configuration handling lcitool: Add inventory handling lcitool: Implement the 'hosts' action lcitool: Implement the 'install' action lcitool: Implement the 'update' action guests: Update documentation guests: Add Docker-related information to the inventory lcitool: Add projects information handling lcitool: Implement the 'projects' action lcitool: Implement the 'dockerfile' action guests/README.markdown | 8 +- guests/host_vars/libvirt-centos-7/docker.yml | 2 + guests/host_vars/libvirt-debian-8/docker.yml | 2 + guests/host_vars/libvirt-debian-9/docker.yml | 2 + .../host_vars/libvirt-debian-sid/docker.yml | 2 + guests/host_vars/libvirt-fedora-27/docker.yml | 2 + guests/host_vars/libvirt-fedora-28/docker.yml | 2 + .../libvirt-fedora-rawhide/docker.yml | 2 + guests/host_vars/libvirt-ubuntu-16/docker.yml | 2 + guests/host_vars/libvirt-ubuntu-18/docker.yml | 2 + guests/lcitool | 730 ++++++++++++------ 11 files changed, 529 insertions(+), 227 deletions(-) create mode 100644 guests/host_vars/libvirt-centos-7/docker.yml create mode 100644 guests/host_vars/libvirt-debian-8/docker.yml create mode 100644 guests/host_vars/libvirt-debian-9/docker.yml create mode 100644 guests/host_vars/libvirt-debian-sid/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-27/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-28/docker.yml create mode 100644 guests/host_vars/libvirt-fedora-rawhide/docker.yml create mode 100644 guests/host_vars/libvirt-ubuntu-16/docker.yml create mode 100644 guests/host_vars/libvirt-ubuntu-18/docker.yml -- 2.17.1

2 13