Re: [libvirt PATCH 2/2] tests: don't set G_DEBUG=fatal-warnings on macOS

2022-04-29 Thread Andrea Bolognani
On Thu, Apr 28, 2022 at 05:55:41PM +0100, Daniel P. Berrangé wrote: > On Thu, Apr 28, 2022 at 08:33:46AM -0700, Andrea Bolognani wrote: > > In other words, the current implementation of g_poll() on macOS > > doesn't follow the contract defined by GLib itself. It seems to me > > that this is a (fair

libvirt-8.3.0 release candidate 2

2022-04-29 Thread Jiri Denemark
I have just tagged v8.3.0-rc2 in the repository and pushed signed tarballs and source RPMs to https://libvirt.org/sources/ Please give the release candidate some testing and in case you find a serious issue which should have a fix in the upcoming release, feel free to reply to this thread to make

Re: [libvirt RFCv4 01/20] iohelper: introduce new struct to carry copy operation parameters

2022-04-29 Thread Claudio Fontana
On 4/28/22 3:01 PM, Daniel P. Berrangé wrote: > On Wed, Apr 27, 2022 at 11:13:20PM +0200, Claudio Fontana wrote: >> this is in preparation for a minor refactoring of the copy >> function itself out of runIO(). >> >> Signed-off-by: Claudio Fontana >> --- >> src/util/iohelper.c | 95 +++

Re: [libvirt RFCv4 06/20] libvirt: introduce virDomainSaveParametersFlags public API

2022-04-29 Thread Claudio Fontana
On 4/28/22 11:12 AM, Daniel P. Berrangé wrote: > On Wed, Apr 27, 2022 at 11:13:25PM +0200, Claudio Fontana wrote: >> add new API in order to be able to extend parameters to the domain >> save operation. We will use it to fit the existing arguments of >> VirDomainSaveFlags, and then add parallel sav

Re: [libvirt RFCv4 03/20] iohelper: move runIO function to a separate module

2022-04-29 Thread Claudio Fontana
On 4/28/22 2:55 PM, Daniel P. Berrangé wrote: > On Wed, Apr 27, 2022 at 11:13:22PM +0200, Claudio Fontana wrote: >> where it can be reused by other helpers. >> No changes other than the move. >> >> Signed-off-by: Claudio Fontana >> --- >> po/POTFILES.in | 1 + >> src/util/iohelper.c | 17

Re: [libvirt RFCv4 03/20] iohelper: move runIO function to a separate module

2022-04-29 Thread Claudio Fontana
On 4/29/22 12:08 PM, Claudio Fontana wrote: > On 4/28/22 2:55 PM, Daniel P. Berrangé wrote: >> On Wed, Apr 27, 2022 at 11:13:22PM +0200, Claudio Fontana wrote: >>> where it can be reused by other helpers. >>> No changes other than the move. >>> >>> Signed-off-by: Claudio Fontana >>> --- >>> po/PO

Re: [PATCH 05/18] tests/qtest: Specify audiodev= and -audiodev

2022-04-29 Thread Martin Kletzander
On Mon, Apr 25, 2022 at 02:42:53PM +0100, Daniel P. Berrangé wrote: On Mon, Apr 25, 2022 at 10:21:48AM +0200, Martin Kletzander wrote: This will enable removing deprecated default audiodev support. I did not figure out how to make the audiodev represented as an interface node, so this is a work

Re: [PATCH 07/18] Introduce machine's default-audiodev property

2022-04-29 Thread Martin Kletzander
On Mon, Apr 25, 2022 at 03:06:14PM +0100, Daniel P. Berrangé wrote: On Mon, Apr 25, 2022 at 10:21:50AM +0200, Martin Kletzander wrote: Many machine types have default audio devices with no way to set the underlying audiodev. Instead of adding an option for each and every one of them this new pr

Re: [PATCH 00/18] RFC: Remove deprecated audio features

2022-04-29 Thread Martin Kletzander
On Mon, Apr 25, 2022 at 06:05:56PM +0100, Mark Cave-Ayland wrote: On 25/04/2022 09:21, Martin Kletzander wrote: I wanted to deal with https://bugzilla.redhat.com/2043498 and I got a suggesstion that removing deprecated features could actually make it easier to propagate the error. In the end (

Re: [PATCH v2 2/5] hw/nvme: do not auto-generate eui64

2022-04-29 Thread Christoph Hellwig
On Fri, Apr 29, 2022 at 10:33:33AM +0200, Klaus Jensen wrote: > From: Klaus Jensen > > We cannot provide auto-generated unique or persistent namespace > identifiers (EUI64, NGUID, UUID) easily. Since 6.1, namespaces have been > assigned a generated EUI64 of the form "52:54:00:". > This is will be

[libvirt PATCH] conf: ensure only one vgpu has ramfb enabled

2022-04-29 Thread Jonathon Jongsma
Validate the domain configuration to ensure that if there are more than one vgpu assigned to a domain, only one of them has 'ramfb' enabled. This was never a supported configuration. QEMU failed confusingly when attempting to start a domain with this configuration. This change attempts to provide