- Devel - libvirt List Archives

[PATCH 0/2] security: Handle non top parents better
by Michal Privoznik 28 Feb '20

28 Feb '20

See 2/2 for explanation. Michal Prívozník (2): security: Introduce VIR_SECURITY_DOMAIN_IMAGE_TOP_PARENT flag qemu: Tell secdrivers which images are top parent src/qemu/qemu_backup.c | 4 ++-- src/qemu/qemu_blockjob.c | 6 ++++-- src/qemu/qemu_checkpoint.c | 6 ++++-- src/qemu/qemu_domain.c | 15 +++++++++++++-- src/qemu/qemu_domain.h | 3 ++- src/qemu/qemu_driver.c | 15 ++++++++++----- src/qemu/qemu_process.c | 2 +- src/qemu/qemu_security.c | 6 +++++- src/qemu/qemu_security.h | 3 ++- src/security/security_dac.c | 16 +++++++++++----- src/security/security_manager.h | 1 + src/security/security_selinux.c | 18 ++++++++++++------ 12 files changed, 67 insertions(+), 28 deletions(-) -- 2.24.1

2 4

[PATCH v4 0/5] lxc: Add VCPU features for LXC
by Julio Faracco 27 Feb '20

27 Feb '20

This series cover a lots of functionalities to LXC VCPUs. It enables sharing some timer devices between host and LXC guest using `timer` settings. It still has other improvements related to VCPU and LXC such as virtual cpuinfo content based on VCPU settings and some better resource limits. Each patch has the description of the problem and what it is trying to fix. v1-v2: Add Daniel's comments and some cleanups. v2-v3: Remove dependency from patch 4 and 5. v3-v4: Missing cpuinfo file from Fuse Getattr handler. Julio Faracco (5): lxc: Add Real Time Clock device into allowed devices lxc: Add HPET device into allowed devices lxc: Replacing default strings definitions by g_autofree statement lxc: Implement virtual /proc/cpuinfo via LXC fuse lxc: Count max VCPUs based on cpuset.cpus in native config docs/formatdomain.html.in | 4 +- src/lxc/lxc_cgroup.c | 91 ++++++++- src/lxc/lxc_container.c | 62 ++++-- src/lxc/lxc_container.h | 2 + src/lxc/lxc_controller.c | 187 ++++++++++++------ src/lxc/lxc_fuse.c | 114 +++++++++-- src/lxc/lxc_native.c | 24 ++- .../lxcconf2xml-cpusettune.xml | 2 +- 8 files changed, 374 insertions(+), 112 deletions(-) -- 2.20.1

2 11

[libvirt PATCHv5 00/15] add virtiofs support (virtio-fs epopee)
by Ján Tomko 27 Feb '20

27 Feb '20

v4: https://www.redhat.com/archives/libvir-list/2020-February/msg00707.html v5: use priv->libDir for the pid file more validation checks cmd line escaping and memory leak fixes Ján Tomko (15): schema: wrap fsDriver in a choice group qemuExtDevicesStart: pass logManager qemu: pass virDomainObjPtr to qemuExtDevicesSetupCgroup qemuxml2xmltest: set driver as privileged qemu: add QEMU_CAPS_DEVICE_VHOST_USER_FS docs: add virtiofs kbase conf: qemu: add virtiofs fsdriver type conf: add virtiofs-related elements and attributes qemu: add virtiofsd_debug to qemu.conf qemu: validate virtiofs filesystems qemu: forbid migration with vhost-user-fs device qemu: add code for handling virtiofsd qemu: put virtiofsd in the emulator cgroup qemu: use the vhost-user schemas to find binary qemu: build vhost-user-fs device command line docs/formatdomain.html.in | 35 +- docs/kbase.html.in | 3 + docs/kbase/virtiofs.rst | 152 ++++++++ docs/schemas/domaincommon.rng | 88 ++++- po/POTFILES.in | 1 + src/conf/domain_conf.c | 105 +++++- src/conf/domain_conf.h | 16 + src/libvirt_private.syms | 1 + src/qemu/Makefile.inc.am | 2 + src/qemu/libvirtd_qemu.aug | 1 + src/qemu/qemu.conf | 7 + src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_cgroup.c | 2 +- src/qemu/qemu_command.c | 48 ++- src/qemu/qemu_conf.c | 2 + src/qemu/qemu_conf.h | 1 + src/qemu/qemu_domain.c | 87 ++++- src/qemu/qemu_domain.h | 2 +- src/qemu/qemu_domain_address.c | 4 + src/qemu/qemu_extdevice.c | 46 ++- src/qemu/qemu_extdevice.h | 3 +- src/qemu/qemu_migration.c | 10 + src/qemu/qemu_process.c | 4 +- src/qemu/qemu_vhost_user.c | 39 ++ src/qemu/qemu_vhost_user.h | 4 + src/qemu/qemu_virtiofs.c | 338 ++++++++++++++++++ src/qemu/qemu_virtiofs.h | 46 +++ src/qemu/test_libvirtd_qemu.aug.in | 1 + .../caps_4.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + ...vhost-user-fs-fd-memory.x86_64-latest.args | 39 ++ .../vhost-user-fs-fd-memory.xml | 43 +++ ...vhost-user-fs-hugepages.x86_64-latest.args | 47 +++ .../vhost-user-fs-hugepages.xml | 75 ++++ tests/qemuxml2argvtest.c | 14 + .../vhost-user-fs-fd-memory.x86_64-latest.xml | 1 + .../vhost-user-fs-hugepages.x86_64-latest.xml | 1 + tests/qemuxml2xmltest.c | 4 + 42 files changed, 1257 insertions(+), 27 deletions(-) create mode 100644 docs/kbase/virtiofs.rst create mode 100644 src/qemu/qemu_virtiofs.c create mode 100644 src/qemu/qemu_virtiofs.h create mode 100644 tests/qemuxml2argvdata/vhost-user-fs-fd-memory.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml create mode 100644 tests/qemuxml2argvdata/vhost-user-fs-hugepages.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-user-fs-hugepages.xml create mode 120000 tests/qemuxml2xmloutdata/vhost-user-fs-fd-memory.x86_64-latest.xml create mode 120000 tests/qemuxml2xmloutdata/vhost-user-fs-hugepages.x86_64-latest.xml -- 2.24.1

5 24

[PATCH 0/2] (for 6.1) docs: kbase/news additions
by Peter Krempa 27 Feb '20

27 Feb '20

Peter Krempa (2): kbase: backing_chains: Add steps how to securely probe image format news: Document recent storage improvements docs/kbase/backing_chains.rst | 15 +++++++++++++++ docs/news.xml | 23 +++++++++++++++++++++++ 2 files changed, 38 insertions(+) -- 2.24.1

2 4

[libvirt PATCH] ci: Drop handling of $PKG_CONFIG_LIBDIR
by Andrea Bolognani 27 Feb '20

27 Feb '20

As of libvirt-jenkins-ci commit e41e341f0d8f, we no longer bake this environment variable into our container images. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- ci/Makefile | 4 ---- 1 file changed, 4 deletions(-) diff --git a/ci/Makefile b/ci/Makefile index 577b130d2f..bc1dac11e3 100644 --- a/ci/Makefile +++ b/ci/Makefile @@ -216,15 +216,11 @@ ci-run-command@%: ci-prepare-tree $(CI_ENGINE) run $(CI_ENGINE_ARGS) $(CI_IMAGE_PREFIX)$*$(CI_IMAGE_TAG) \ /bin/bash -c ' \ $(CI_USER_HOME)/prepare || exit 1; \ - if test "$$PKG_CONFIG_LIBDIR"; then \ - pkgconfig_env="PKG_CONFIG_LIBDIR=$$PKG_CONFIG_LIBDIR"; \ - fi; \ sudo \ --login \ --user="#$(CI_UID)" \ --group="#$(CI_GID)" \ CONFIGURE_OPTS="$$CONFIGURE_OPTS" \ - $$pkgconfig_env \ CI_CONT_SRCDIR="$(CI_CONT_SRCDIR)" \ CI_CONT_BUILDDIR="$(CI_CONT_BUILDDIR)" \ CI_SMP="$(CI_SMP)" \ -- 2.24.1

2 1

[libvirt PATCH 0/2] conf: only allow virtio bus for input passthrough
by Ján Tomko 26 Feb '20

26 Feb '20

https://bugzilla.redhat.com/show_bug.cgi?id=1724928 Ján Tomko (2): conf: only allow virtio bus for input passthrough conf: default to virtio bus for input passthrough src/conf/domain_conf.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) -- 2.24.1

2 3

[libvirt PATCH] daemon: set default memlock limit for systemd service
by Pavel Hrdina 26 Feb '20

26 Feb '20

The default memlock limit is 64k which is not enough to start a single VM. The requirements for one VM are 12k, 8k for eBPF map and 4k for eBPF program, however, it fails to create eBPF map and program with 64k limit. By testing I figured out that the minimal limit is 80k to start a single VM with functional eBPF and if I add 12k I can start another one. This leads into following calculation: 80k as memlock limit worked to start a VM with eBPF which means there is 68k of lock memory that I was not able to figure out what was using it. So to get a number for 4096 VMs: 68 + 12 * 4096 = 49220 If we round it up we will get 49M of memory lock limit to support 4096 VMs with default map size which can hold 64 entries for devices. This should be good enough as a sane default and users can change it if the need to. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1807090 Signed-off-by: Pavel Hrdina <phrdina(a)redhat.com> --- src/remote/libvirtd.service.in | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/src/remote/libvirtd.service.in b/src/remote/libvirtd.service.in index 9c8c54a2ef..8a3ace5bdb 100644 --- a/src/remote/libvirtd.service.in +++ b/src/remote/libvirtd.service.in @@ -40,6 +40,11 @@ LimitNOFILE=8192 # A conservative default of 8 tasks per guest results in a TasksMax of # 32k to support 4096 guests. TasksMax=32768 +# With cgroups v2 there is no devices controller anymore, we have to use +# eBPF to control access to devices. In order to do that we create a eBPF +# hash MAP which locked memory. The default map size for 64 devices together +# with program takes 12k per guest which results in 49M to support 4096 guests. +LimitMEMLOCK=49M [Install] WantedBy=multi-user.target -- 2.24.1

4 5

[libvirt PATCH] docs: fix docs about bandwidth setting with bridge networks
by Daniel P. Berrangé 26 Feb '20

26 Feb '20

We now support setting bandwidth on networks with type bridge. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- docs/formatnetwork.html.in | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index 3d807ecab6..ec055c8360 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -548,10 +548,10 @@ (<span class="since">since 0.9.4</span>). Setting <code>bandwidth</code> for a network is supported only for networks with a <code><forward></code> mode - of <code>route</code>, <code>nat</code>, or no mode at all - (i.e. an "isolated" network). Setting <code>bandwidth</code> - is <b>not</b> supported for forward modes - of <code>bridge</code>, <code>passthrough</code>, <code>private</code>, + of <code>route</code>, <code>nat</code>, <code>bridge</code>, + or no mode at all (i.e. an "isolated" network). Setting + <code>bandwidth</code> is <b>not</b> supported for forward modes + <code>passthrough</code>, <code>private</code>, or <code>hostdev</code>. Attempts to do this will lead to a failure to define the network or to create a transient network. </p> -- 2.24.1

2 1

[PATCH] docs: document port isolated property in domain/network/networkport
by Laine Stump 26 Feb '20

26 Feb '20

Signed-off-by: Laine Stump <laine(a)redhat.com> --- I had thought I'd included documentation with the patch that added parsing/formatting for this, but after crobinso noticed it was missing, I realized that I had only put documentation in an earlier version of the patches (that put the option inside <virtualport>). Oops :-/ docs/formatdomain.html.in | 31 +++++++++++++++++++++++++++++++ docs/formatnetwork.html.in | 25 +++++++++++++++++++++++++ docs/formatnetworkport.html.in | 11 +++++++++++ 3 files changed, 67 insertions(+) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 4fef2a0a97..28770188dd 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -6539,6 +6539,37 @@ qemu-kvm -net nic,model=? /dev/null traffic for that VLAN will be tagged. </p> + <h5><a id="elementPort">Isolating guests's network traffic from each other</a></h5> + +<pre> +... +<devices> + <interface type='network'> + <source network='default'/> + <b><port isolated='yes'/></b> + </interface> +</devices> +...</pre> + + <p> + <span class="since">Since 6.1.0.</span> The <code>port</code> + element property <code>isolated</code>, when set + to <code>yes</code> (default setting is <code>no</code>) is used + to isolate this interface's network traffic from that of other + guest interfaces connected to the same network that also + have <code><port isolated='yes'/></code>. This setting is + only supported for emulated interface devices that use a + standard tap device to connect to the network via a Linux host + bridge. This property can be inherited from a libvirt network, + so if all guests that will be connected to the network should be + isolated, it is better to put the setting in the network + configuration. (NB: this only prevents guests that + have <code>isolated='yes'</code> from communicating with each + other; if there is a guest on the same bridge that doesn't + have <code>isolated='yes'</code>, even the isolated guests will + be able to communicate with it.) + </p> + <h5><a id="elementLink">Modifying virtual link state</a></h5> <pre> ... diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index 3d807ecab6..f1e7ce5e4e 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -729,6 +729,31 @@ or <code><interface></code>. </p> + <h5><a id="elementPort">Isolating ports from one another</a></h5> + +<pre> +<network> + <name>isolated-ports</name> + <forward mode='bridge'/> + <bridge name='br0'/> + <port isolated='yes'/> +</network> +</pre> + + <p> + <span class="since">Since 6.1.0.</span> The <code>port</code> + element property <code>isolated</code>, when set + to <code>yes</code> (default setting is <code>no</code>) is used + to isolate the network traffic of each guest on the network from + all other guests connected to the network; it does not have an + effect on communication between the guests and the host, or + between the guests and destinations beyond this network. This + setting is only supported for networks that use a Linux host + bridge to connect guest interfaces via a standard tap device + (i.e. those with a forward mode of nat, route, open, bridge, or + no forward mode). + </p> + <h5><a id="elementsPortgroup">Portgroups</a></h5> <pre> diff --git a/docs/formatnetworkport.html.in b/docs/formatnetworkport.html.in index 0425e069ce..199a05f929 100644 --- a/docs/formatnetworkport.html.in +++ b/docs/formatnetworkport.html.in @@ -84,6 +84,7 @@ <outbound average='128' peak='256' burst='256'/> </bandwidth> <rxfilters trustGuest='yes'/> + <port isolated='yes'/> <virtualport type='802.1Qbg'> <parameters managerid='11' typeid='1193047' typeidversion='2'/> </virtualport> @@ -110,6 +111,16 @@ only supported for the virtio device model and for macvtap connections on the host. </dd> + <dt><code>port</code></dt> + <dd> <span class="since">Since 6.1.0.</span> + The <code>port</code> element property + <code>isolated</code>, when set to <code>yes</code> (default + setting is <code>no</code>) is used to isolate this port's + network traffic from other ports on the same network that also + have <code><port isolated='yes'/></code>. This setting + is only supported for emulated network devices connected to a + Linux host bridge via a standard tap device. + </dd> <dt><code>virtualport</code></dt> <dd>The <code>virtualport</code> element describes metadata that needs to be provided to the underlying network subsystem. It -- 2.24.1

2 1

[PATCH 0/7] qemu: Use 'flat' version of query-named-block-nodes
by Peter Krempa 26 Feb '20

26 Feb '20

Don't request the recursive output since we don't use it. Peter Krempa (7): tests: qemucapabilities: Update capabilities of qemu-5.0.0 on x86_64 qemu: monitor: Remove leftovers from password callback qemu: capabilities: Add capability for the 'flat' argument of 'query-named-block-nodes' qemu: monitor: Refactor variable cleanup in qemuMonitorJSONQueryNamedBlockNodes qemuCheckpointDiscardBitmaps: Use qemuBlockGetNamedNodeData qemu: monitor: Add 'flat' parameter for qemuMonitorJSONQueryNamedBlockNodes qemu: Don't request nested entries in qemuBlockGetNamedNodeData src/qemu/qemu_block.c | 4 +- src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_checkpoint.c | 4 +- src/qemu/qemu_monitor.c | 9 +- src/qemu/qemu_monitor.h | 12 +- src/qemu/qemu_monitor_json.c | 31 +- src/qemu/qemu_monitor_json.h | 6 +- .../caps_5.0.0.x86_64.replies | 6185 +++++++++-------- .../caps_5.0.0.x86_64.xml | 3 +- 10 files changed, 3388 insertions(+), 2873 deletions(-) -- 2.24.1

2 14