Re: Questions about using qemuProcess API within a libvirt test

Much appreciated to you both for the well-written explanations. I'll keep my libvirt tests to mock input/output responses and find an alternative test suite for using libvirt with a real QEMU instance. Thank you for your time! -- Respectfully, - Collin Walling

Re: [PATCH] apparmor: allow to call vhost-user-gpu

On 2/14/20 1:14 PM, Christian Ehrhardt wrote: On Fri, Feb 14, 2020 at 6:00 PM Jim Fehlig > wrote: On 2/13/20 4:32 AM, Christian Ehrhardt wrote: > Configuring vhost-user-gpu like: >      >        >        >      > Triggers an

Re: [PATCH] apparmor: allow to call vhost-user-gpu

On Fri, Feb 14, 2020 at 6:00 PM Jim Fehlig wrote: > On 2/13/20 4:32 AM, Christian Ehrhardt wrote: > > Configuring vhost-user-gpu like: > > > > > > > > > > Triggers an apparmor denial like: > > apparmor="DENIED" operation="exec" profile="libvirtd" > >

Re: [libvirt PATCH 05/11] src: introduce an abstraction for running event loops

On Fri, Feb 14, 2020 at 12:52:03PM +, Daniel P. Berrangé wrote: > We want a way to easily run a private GMainContext in a > thread, with correct synchronization between startup > and shutdown of the thread. > > Signed-off-by: Daniel P. Berrangé > --- > po/POTFILES.in| 1 + >

Re: [libvirt PATCH] docs: add news item about GNULIB removal

On Fri, 2020-02-14 at 16:37 +, Daniel P. Berrangé wrote: > On Fri, Feb 07, 2020 at 06:18:59PM +0100, Andrea Bolognani wrote: > > On Fri, 2020-02-07 at 16:21 +, Daniel P. Berrangé wrote: > > > + Other Linux distros of a similar vintage using GLibC are > > > expected > > > +

Re: [PATCH] apparmor: allow to call vhost-user-gpu

On 2/13/20 4:32 AM, Christian Ehrhardt wrote: Configuring vhost-user-gpu like: Triggers an apparmor denial like: apparmor="DENIED" operation="exec" profile="libvirtd" name="/usr/lib/qemu/vhost-user-gpu" pid=888257 comm="libvirtd" requested_mask="x"

Re: [libvirt PATCH] docs: add news item about GNULIB removal

On Fri, Feb 07, 2020 at 06:18:59PM +0100, Andrea Bolognani wrote: > On Fri, 2020-02-07 at 16:21 +, Daniel P. Berrangé wrote: > > While we have CI testing coverage for many platforms, we don't test any > > non-GLibC based Linux and there are other non-Linux platforms we don't > > It's "glibc",

[libvirt PATCH v2] docs: add news item about gnulib removal

While we have CI testing coverage for many platforms, we don't test any non-glibc based Linux and there are other non-Linux platforms we don't officially target, both of which might hit regressions. Signed-off-by: Daniel P. Berrangé --- docs/news.xml | 19 +++ 1 file changed, 19

[libvirt PATCH v2 1/6] qemu: test if bandwidth has 'floor' factored out to separate function

This compound condition will be useful in several places so it makes sense to give it a name for better readability. Signed-off-by: Pavel Mores --- src/conf/netdev_bandwidth_conf.h | 7 +++ src/network/bridge_driver.c | 8 2 files changed, 11 insertions(+), 4 deletions(-)

[libvirt PATCH v2 4/6] qemu: check if 'floor' is supported for given interface and network

Even if an interface of type 'network', setting 'floor' is only supported if the network's forward type is nat, route, open or none. Signed-off-by: Pavel Mores --- src/network/bridge_driver.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/src/network/bridge_driver.c

[libvirt PATCH v2 6/6] docs: QoS parameter 'floor' is supported for 'open' networks too

Relevant code seems to treat forward modes 'route', 'nat', 'open' and 'none' the same but documentation hasn't reflected that so far. Signed-off-by: Pavel Mores --- docs/formatnetwork.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/formatnetwork.html.in

[libvirt PATCH v2 5/6] qemu: call networkPlugBandwidth() for all types of network

To fix the actual bug, it was necessary to make networkPlugBandwidth() be called also for 'bridge'-type networks implemented using macvtap's 'bridge' mode (previously it was only called for those implemented on top of an existing bridge). However, it seems beneficial to call it for other network

[libvirt PATCH v2 2/6] qemu: add function to test if network supports setting 'floor'

This function will be useful in upcoming commits when code to check whether a network can support 'floor' in the first place is introduced. Signed-off-by: Pavel Mores --- src/conf/netdev_bandwidth_conf.h | 20 1 file changed, 20 insertions(+) diff --git

[libvirt PATCH v2 3/6] qemu: fail on attempt to set 'floor' if interface type is not 'network'

QoS 'floor' setting is documented to be only supported for interfaces of type 'network'. Fail with an error message on attempt to set 'floor' on an interface of any other type. Signed-off-by: Pavel Mores --- src/qemu/qemu_driver.c | 18 +++--- 1 file changed, 15 insertions(+), 3

[libvirt PATCH v2 0/6] qemu: add stricter checks of permissibility of the QoS parameter 'floor'

v2 is mostly just integrating requests from Michal's review. The initial two commits introduce new utility functions to be used in the following two commits. The final two commits have no substantial changes since v1. The only exception are long lines caused by error messages which stay

Re: [PATCH v3 12/15] tests: qemublock: Add cases for creating image overlays on top of disks with

On Fri, Feb 14, 2020 at 01:50:22PM +0100, Peter Krempa wrote: On Thu, Feb 13, 2020 at 15:54:53 +0100, Ján Tomko wrote: On Wed, Feb 12, 2020 at 07:03:23PM +0100, Peter Krempa wrote: > Add a set of test data to see whether the backing store strings are > formatted reasonably. Note that we don't

Re: [libvirt PATCH 07/11] qemu: start/stop an event thread for QMP probing

On Fri, Feb 14, 2020 at 02:03:59PM +0100, Ján Tomko wrote: > On Fri, Feb 14, 2020 at 12:52:05PM +, Daniel P. Berrangé wrote: > > In common with regular QEMU guests, the QMP probing > > will need an event loop for handling monitor I/O > > operations. > > > > Signed-off-by: Daniel P. Berrangé

Re: [libvirt PATCH 08/11] tests: start/stop an event thread for QEMU monitor/agent tests

On Fri, Feb 14, 2020 at 02:04:48PM +0100, Ján Tomko wrote: > On Fri, Feb 14, 2020 at 12:52:06PM +, Daniel P. Berrangé wrote: > > Tests which are using the QEMU monitor / agent need to have an > > event thread running a private GMainContext. > > > > There is already a thread running the main

Re: [PATCH] qemu_domain: Modify access to a NVMe disk iff needed

On Fri, Feb 14, 2020 at 02:25:15PM +0100, Michal Privoznik wrote: If a domain has a NVMe disk it already has the access configured. Trying to configure it again on a commit or some other operation is wrong and condemned to failure. Signed-off-by: Michal Privoznik --- src/qemu/qemu_domain.c |

[PATCH] qemu_domain: Modify access to a NVMe disk iff needed

If a domain has a NVMe disk it already has the access configured. Trying to configure it again on a commit or some other operation is wrong and condemned to failure. Signed-off-by: Michal Privoznik --- src/qemu/qemu_domain.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff

Re: [libvirt PATCH 08/11] tests: start/stop an event thread for QEMU monitor/agent tests

On Fri, Feb 14, 2020 at 12:52:06PM +, Daniel P. Berrangé wrote: Tests which are using the QEMU monitor / agent need to have an event thread running a private GMainContext. There is already a thread running the main libvirt event loop but this can't be eliminated yet as it is used for more

Re: [libvirt PATCH 07/11] qemu: start/stop an event thread for QMP probing

On Fri, Feb 14, 2020 at 12:52:05PM +, Daniel P. Berrangé wrote: In common with regular QEMU guests, the QMP probing will need an event loop for handling monitor I/O operations. Signed-off-by: Daniel P. Berrangé --- src/qemu/qemu_process.c | 16 src/qemu/qemu_process.h | 2

[libvirt PATCH 11/11] qemu: convert agent to use the per-VM event loop

This converts the QEMU agent APIs to use the per-VM event loop, which involves switching from virEvent APIs to GMainContext / GSource APIs. A GSocket is used as a convenient way to create a GSource for a socket, but is not yet used for actual I/O. Signed-off-by: Daniel P. Berrangé ---

[libvirt PATCH 10/11] qemu: fix variable naming in agent code

We are dealing with the QEMU agent, not the monitor. Signed-off-by: Daniel P. Berrangé --- src/qemu/qemu_agent.c | 498 +- 1 file changed, 249 insertions(+), 249 deletions(-) diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index

[libvirt PATCH 08/11] tests: start/stop an event thread for QEMU monitor/agent tests

Tests which are using the QEMU monitor / agent need to have an event thread running a private GMainContext. There is already a thread running the main libvirt event loop but this can't be eliminated yet as it is used for more than just the monitor client I/O. Signed-off-by: Daniel P. Berrangé

[libvirt PATCH 01/11] qemu: drop support for agent connections on PTYs

Libvirt has never configured the QEMU agent to support running on a PTY implicitly. In theory an end user may have written such an XML config, but this is reasonably unlikely since when a bare is provided, libvirt will auto-expand it to a UNIX socket backend. With this change a user who has use

[libvirt PATCH 09/11] qemu: convert monitor to use the per-VM event loop

This converts the QEMU monitor APIs to use the per-VM event loop, which involves switching from virEvent APIs to GMainContext / GSource APIs. A GSocket is used as a convenient way to create a GSource for a socket, but is not yet used for actual I/O. Signed-off-by: Daniel P. Berrangé ---

[libvirt PATCH 03/11] src: set the OS level thread name

Setting the thread name makes it easier to debug libvirtd when many threads are running. Signed-off-by: Daniel P. Berrangé --- src/libvirt_private.syms | 1 + src/util/virthread.c | 44 +++- src/util/virthread.h | 4 +++- 3 files changed, 43

[libvirt PATCH 04/11] src: improve thread naming with human targetted names

Historically threads are given a name based on the C function, and this name is just used inside libvirt. With OS level thread naming this name is now visible to debuggers, but also has to fit in 15 characters on Linux, so function names are too long in some cases. Signed-off-by: Daniel P.

[libvirt PATCH 05/11] src: introduce an abstraction for running event loops

We want a way to easily run a private GMainContext in a thread, with correct synchronization between startup and shutdown of the thread. Signed-off-by: Daniel P. Berrangé --- po/POTFILES.in| 1 + src/libvirt_private.syms | 5 ++ src/util/Makefile.inc.am | 2 +

[libvirt PATCH 07/11] qemu: start/stop an event thread for QMP probing

In common with regular QEMU guests, the QMP probing will need an event loop for handling monitor I/O operations. Signed-off-by: Daniel P. Berrangé --- src/qemu/qemu_process.c | 16 src/qemu/qemu_process.h | 2 ++ 2 files changed, 18 insertions(+) diff --git

[libvirt PATCH 06/11] qemu: start/stop an event loop thread for domains

The event loop thread will be responsible for handling any per-domain I/O operations, most notably the QEMU monitor and agent sockets. We start this event loop when launching QEMU, but stopping the event loop is a little more complicated. The obvious idea is to stop it in qemuProcessStop(), but

[libvirt PATCH 02/11] qemu: drop ability to open monitor from FD

The qemuMonitorOpenFD method has not been used since it was first introduced. Signed-off-by: Daniel P. Berrangé --- src/qemu/qemu_monitor.c | 10 -- src/qemu/qemu_monitor.h | 5 - 2 files changed, 15 deletions(-) diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index

[libvirt PATCH 00/11] qemu: introduce a per-VM event loop thread

This series changes the way we manage the QEMU monitor and QEMU agent, such that all I/O is processed by a dedicated event loop thread. Many times in the past years people are reported issues where long running monitor event callbacks block the main libvirtd event loop for an unacceptably long

Re: [PATCH v3 12/15] tests: qemublock: Add cases for creating image overlays on top of disks with

On Thu, Feb 13, 2020 at 15:54:53 +0100, Ján Tomko wrote: > On Wed, Feb 12, 2020 at 07:03:23PM +0100, Peter Krempa wrote: > > Add a set of test data to see whether the backing store strings are > > formatted reasonably. Note that we don't support direct creation of such > > images so those tests

Re: [PATCH v3 06/15] qemuDomainValidateStorageSource: Reject unsupported slices

On Thu, Feb 13, 2020 at 14:51:20 +0100, Ján Tomko wrote: > On Wed, Feb 12, 2020 at 07:03:17PM +0100, Peter Krempa wrote: > > We will currently support slice only for the 'raw' format slice reject > > format slice. > Reject any other option. Actually I completely forgot to fix this commit message

Re: [libvirt] [PATCH 0/8] Second take on slirp-helper & dbus-vmstate

Hi On Tue, Jan 14, 2020 at 2:47 PM wrote: > > From: Marc-André Lureau > > Hi, > > The series "[libvirt] [PATCH v2 00/23] Use a slirp helper process" has > been merged and partially reverted. Meanwhile, qemu dbus-vmstate > design has been changed and merged upstream. > > This new series fixes

Re: [libvirt PATCH v2 3/8] conf: Introduce VIR_DOMAIN_TIMER_NAME_ARMVTIMER

On Fri, 2020-02-14 at 11:19 +0100, Andrew Jones wrote: > On Thu, Feb 13, 2020 at 05:30:21PM +0100, Andrea Bolognani wrote: > > On Thu, 2020-02-13 at 14:26 +0100, Ján Tomko wrote: > > > Okay, so this name is a libvirt invention. > > > > I believe "ARM virtual timer" is the official name for the

Re: [libvirt PATCH v2 3/8] conf: Introduce VIR_DOMAIN_TIMER_NAME_ARMVTIMER

On Thu, Feb 13, 2020 at 05:30:21PM +0100, Andrea Bolognani wrote: > On Thu, 2020-02-13 at 14:26 +0100, Ján Tomko wrote: > > On Fri, Feb 07, 2020 at 03:27:03PM +0100, Andrea Bolognani wrote: > > > +++ b/src/conf/domain_conf.c > > > @@ -1063,6 +1063,7 @@ VIR_ENUM_IMPL(virDomainTimerName, > > >

Re: [libvirt PATCH v2 4/8] qemu: Validate configuration for the armvtimer timer

On Thu, Feb 13, 2020 at 05:45:14PM +0100, Andrea Bolognani wrote: On Thu, 2020-02-13 at 14:28 +0100, Ján Tomko wrote: On Fri, Feb 07, 2020 at 03:27:04PM +0100, Andrea Bolognani wrote: > +++ b/src/qemu/qemu_domain.c > @@ -5430,6 +5430,39 @@ qemuDomainDefValidateClockTimers(const virDomainDef