bug#36634: Virtual Machine Manager (virt-manager)

bug#36634: Virtual Machine Manager (virt-manager)

[Raghav Gururajan]

Hello Guix!

Unable to create any VMs by installing from any ISO file.

The virt-manager gives out the following error:

Unable to complete install: 'Unable to read from
'/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
directory'

Traceback (most recent call last):
  File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
2.1.0/share/virt-manager/virtManager/asyncjob.py", line 75, in
cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
2.1.0/share/virt-manager/virtManager/create.py", line 2122, in
_do_async_install
    guest.installer_instance.start_install(guest, meter=meter)
  File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
2.1.0/share/virt-manager/virtinst/installer.py", line 415, in
start_install
    doboot, transient)
  File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
2.1.0/share/virt-manager/virtinst/installer.py", line 358, in
_create_guest
    domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/gnu/store/kcdnna2613in9xfm9gxjqvkisdns911v-python-libvirt-
5.5.0/lib/python3.7/site-packages/libvirt.py", line 3840, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)
libvirt.libvirtError: Unable to read from
'/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
directory

Regards,
RG.

bug#36634: Virtual Machine Manager (virt-manager)

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]

On Sat, Jul 13, 2019 at 01:06:55AM -0400, Raghav Gururajan wrote:
> Hello Guix!
> 
> Unable to create any VMs by installing from any ISO file.
> 
> The virt-manager gives out the following error:
> 
> Unable to complete install: 'Unable to read from
> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
> directory'
> 
> Traceback (most recent call last):
>   File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
> 2.1.0/share/virt-manager/virtManager/asyncjob.py", line 75, in
> cb_wrapper
>     callback(asyncjob, *args, **kwargs)
>   File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
> 2.1.0/share/virt-manager/virtManager/create.py", line 2122, in
> _do_async_install
>     guest.installer_instance.start_install(guest, meter=meter)
>   File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
> 2.1.0/share/virt-manager/virtinst/installer.py", line 415, in
> start_install
>     doboot, transient)
>   File "/gnu/store/r2l62bg0ayh22pkgs0jm9ig8q8n7daql-virt-manager-
> 2.1.0/share/virt-manager/virtinst/installer.py", line 358, in
> _create_guest
>     domain = self.conn.createXML(install_xml or final_xml, 0)
>   File "/gnu/store/kcdnna2613in9xfm9gxjqvkisdns911v-python-libvirt-
> 5.5.0/lib/python3.7/site-packages/libvirt.py", line 3840, in createXML
>     if ret is None:raise libvirtError('virDomainCreateXML() failed',
> conn=self)
> libvirt.libvirtError: Unable to read from
> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
> directory
> 
> Regards,
> RG.
> 
Checking my machine:
$ ls /sys/fs/cgroup/unified/
cgroup.controllers  cgroup.max.depth  cgroup.max.descendants  cgroup.procs  cgroup.stat  cgroup.subtree_control  cgroup.threads

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#36634: Virtual Machine Manager (virt-manager)

[Raghav Gururajan]

> Checking my machine:
> $ ls /sys/fs/cgroup/unified/
> cgroup.controllers  cgroup.max.depth  cgroup.max.descendants  cgroup.
> procs  cgroup.stat  cgroup.subtree_control  cgroup.threads

I get the same output for `ls /sys/fs/cgroup/unified/`. But as shown in
the error, the virt-manager is searching the directory
"/sys/fs/cgroup/unified/machine" (not "/sys/fs/cgroup/unified/"), which
does not exist. o.O

Regards,
RG.

bug#36634: Virtual Machine Manager (virt-manager)

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 639 bytes --]


Raghav Gururajan <rvgn@disroot.org> writes:

> libvirt.libvirtError: Unable to read from
> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
> directory

So, I've experienced this too. Even though this is a cgroup thing, I'm
pretty sure this isn't an issue with Linux.

I've tried reverting the changes in [1], and that seems to solve the
issue. Unfortunately, I don't have any insight in to what's different
between the problematic 5.5.0 release, and the working 5.4.0 release.

1: 458fe419232844d2021608d20dcd8f6e095eb2b4
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=458fe419232844d2021608d20dcd8f6e095eb2b4

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

bug#36634: Virtual Machine Manager (virt-manager)

[Raghav Gururajan]

> So, I've experienced this too. Even though this is a cgroup thing,
> I'm
> pretty sure this isn't an issue with Linux.

I see.

> I've tried reverting the changes in [1], and that seems to solve the
> issue. Unfortunately, I don't have any insight in to what's different
> between the problematic 5.5.0 release, and the working 5.4.0 release.

So, by reverting changes, do you mean you patched and made a new
commit?

Thank you!

Regards,
RG.

bug#36634: Virtual Machine Manager (virt-manager)

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Christopher Baines <mail@cbaines.net> writes:

> Raghav Gururajan <rvgn@disroot.org> writes:
>
>> libvirt.libvirtError: Unable to read from
>> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
>> directory
>
> So, I've experienced this too. Even though this is a cgroup thing, I'm
> pretty sure this isn't an issue with Linux.
>
> I've tried reverting the changes in [1], and that seems to solve the
> issue. Unfortunately, I don't have any insight in to what's different
> between the problematic 5.5.0 release, and the working 5.4.0 release.
>
> 1: 458fe419232844d2021608d20dcd8f6e095eb2b4
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=458fe419232844d2021608d20dcd8f6e095eb2b4

This bug is consistently reproducible.  I've found an upstream bug
report that is very similar to what we're seeing here, so I've left a
comment telling the libvirt maintainers that Guix is also seeing a
similar issue:

https://bugzilla.redhat.com/show_bug.cgi?id=1751120

In the meantime, should we revert to version 5.4.0 in Guix?  I'm not
sure if there are any security vulnerabilities between 5.4.0 and the
most recent release, but this bug is currently preventing me from
creating any VMs at all in Guix using virt-manager, which is pretty bad.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#36634: Virtual Machine Manager (virt-manager)

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

Chrisen,

Chris Marusich 写道：
> In the meantime, should we revert to version 5.4.0 in Guix?  I'm 
> not
> sure if there are any security vulnerabilities between 5.4.0 and 
> the
> most recent release, but this bug is currently preventing me 
> from
> creating any VMs at all in Guix using virt-manager, which is 
> pretty bad.

Yes! (which is why I originally updated this package):

  v5.5.0 (2019-07-02)
    Security
        api: Prevent access to several APIs over read-only 
        connections
            Certain APIs give root-equivalent access to the host, 
            and as
            such should be limited to privileged 
            users. CVE-2019-10161,
            CVE-2019-10166, CVE-2019-10167, CVE-2019-10168.

  ­ https://libvirt.org/news.html

It might be easy to backport.  I didn't try, and I no longer use 
libvirt myself.

What's weird (maybe; I haven't kept up with the thread) is that I 
used libvirt 5.5.0 (and yes, it was 5.5.0) for a while without 
problems.  I don't remember whether I created any *new* VMs, 
though.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#36634: Virtual Machine Manager (virt-manager)

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

Chris Marusich <cmmarusich@gmail.com> writes:

> This bug is consistently reproducible.  I've found an upstream bug
> report that is very similar to what we're seeing here, so I've left a
> comment telling the libvirt maintainers that Guix is also seeing a
> similar issue:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1751120

Upstream has made a patch, which supposedly fixes the issue on Fedora
systems.  However, I applied it to a local checkout of Guix and tested
it, but it didn't fix the issue for me.  Perhaps that upstream bug and
this bug are slightly different?  Anyway, I've updated the upstream bug
report with information that hopefully will be useful to them.  We'll
see how it goes.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#36634: Virtual Machine Manager (virt-manager)

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

Chris Marusich <cmmarusich@gmail.com> writes:

> I've updated the upstream bug report with information that hopefully
> will be useful to them.  We'll see how it goes.

The original upstream bug report has been closed, but it seems likely it
was for a different issue, since it didn't fix the issue in Guix.  At
upstream's recommendation, I've opened a new bug report specifically for
this problem here:

https://bugzilla.redhat.com/show_bug.cgi?id=1760233

I've given them detailed instructions, and a pre-made Guix VM that
demonstrates the bug, which will hopefully help them investigate.  Stay
tuned!

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#36634: ATTENTION REQUIRED

[Raghav Gururajan]

Hello Guix!

I posted the bug on libvirt mail list few days ago (https://www.redhat.
com/archives/libvir-list/2019-July/msg01309.html). It appears the bug
has now been fixed (https://github.com/libvirt/libvirt/commit/759bf903a
6c24a8efa25c7cf4b099d952eda9bd3).

Could anyone please update the libvirt package/service to this latest
build?

Thank you!

Regards,
RG.

bug#36634: ATTENTION REQUIRED

[Tobias Geerinckx-Rice]

Raghav,

On Thu, Jul 25, 2019 at 11:46 AM, Raghav Gururajan 
<raghavgururajan@disroot.org> wrote:
> Hello Guix!
> 
> I posted the bug on libvirt mail list few days ago 
> (https://www.redhat.
> com/archives/libvir-list/2019-July/msg01309.html). It appears the bug
> has now been fixed 
> (https://github.com/libvirt/libvirt/commit/759bf903a
> 6c24a8efa25c7cf4b099d952eda9bd3).
> 
> Could anyone please update the libvirt package/service to this latest
> build?

I will do so swiftly since I updated libvirt to the 'broken' version 
(although I never had any troubles like yours).  Thank you for 
reporting this upstream.



A personal note: I find this new wave of 'ATTENTION REQUIRED' messages 
quite the opposite of motivating and pleasant.  I'm honestly not sure 
what result you expect from them.  I fear it may backfire.

You are very welcome to contribute patches yourself!  I don't mean 
'patches or GTFO', I mean 'please dive in, the water's great'.  The 
reviewers don't bite.  You don't need to be a programmmer; I'm not.

You've been part of our discussions for a while, you obviously care 
about Guix and Free software, and particularly about certain Gnome and 
'desktop-demographic' packages that are clearly under-maintained or 
even missing because we're missing people like you.  Learning to create 
and maintain them yourself is hardly more work than trying to herd 
volunteers like this -- and a hell of a lot more fun.

Kind regards,

T G-R

bug#36634: ATTENTION REQUIRED

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

Tobias Geerinckx-Rice 写道：
>> Could anyone please update the libvirt package/service to this 
>> latest
>> build?
>
> I will do so swiftly since I updated libvirt to the 'broken' 
> version
> (although I never had any troubles like yours).  Thank you for
> reporting this upstream.

I have applied ‘your’ patch in 
41097b2dee9367974c6dd16ac1ba2ee945457237.

I'm closing this bug for now.  However, could you update and 
confirm that this actually solves the problem?

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#36634:

[Raghav Gururajan]

[-- Attachment #1: Type: text/plain, Size: 453 bytes --]


> I have applied ‘your’ patch in 
> 41097b2dee9367974c6dd16ac1ba2ee945457237.
> 
> I'm closing this bug for now.  However, could you update and 
> confirm that this actually solves the problem?

Oh Shoot! I just saw your previous reply and replied to it. Sorry for
the delay. Anyway that patch fixes something, so good.

You do not have to close the bug. I will update this mail list once I
receive the correct patch. :)

Regards,
RG.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#36634:

[Raghav Gururajan]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]


> I will do so swiftly since I updated libvirt to the 'broken' version 
> (although I never had any troubles like yours).  Thank you for 
> reporting this upstream.

About that, it appears I misunderstood the patch. That recent build was
not to fix the bug I reported. Anyway, I have been told by one of the
libvirt maintainers (pavel) that they are working on a fix for the bug
I reported.

So once I come to know about the new patch, I will update you and this
mail list. :)

> A personal note: I find this new wave of 'ATTENTION REQUIRED'
> messages 
> quite the opposite of motivating and pleasant.  I'm honestly not
> sure 
> what result you expect from them.  I fear it may backfire.

Yeah, sorry about that. It was not intentional. I thought that sending
replies directly to `#bug@debbugs.gnu.org` will not use the subject
line, so just went with something top of my head. I will defer to do
this, moving forward. :)

Regards,
RG.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

bug#36634: Virtual Machine Manager (virt-manager)

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

As version 5.7.0 has been released, I tried updating to that. There
seems to be some issue with the configuration for the socket file, but
even avoiding that, it doesn't seem to resolve the issue with the
cgroups.

For now, I've switched more permanently back to 5.4.0.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]

bug#36634: Virtual Machine Manager (virt-manager)

[Miguel Arruga Vivas]

Hi,

This bug can be easier to fix than we thought. :-D

As a workaround, you only have to execute:

$ sudo mkdir /sys/fs/cgroup/unified/{machine,system,user}

The folders should be created at libvirtd start, probably manually with
some extra cgroup magic that I don't understand yet, but this works
well and new machines can be created.  I'll take a look this week into
the libvirtd service if nobody takes it first, as this is quite trivial.

Best regards,
Miguel

bug#36634: Virtual Machine Manager (virt-manager)

[Miguel Arruga Vivas]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

Hello again,

The two patches attached create the cgroup directory needed and remove
the warning for the ip binary missing.  Still the following errors
are emitted to the log. 

--------------------8<-------------------
error : virConnectGetCPUModelNames:1109 : this function is not supported by the connection driver: virConnectGetCPUModelNames
error : virConnectGetAllDomainStats:11705 : this function is not supported by the connection driver: virConnectGetAllDomainStats
error : virCgroupSetValueRaw:473 : Unable to write to '/sys/fs/cgroup/unified/machine/qemu-1-Guix.libvirt-qemu/tasks': No such file or directory
error : virCgroupRemoveRecursively:2383 : Unable to remove /sys/fs/cgroup/unified/machine/qemu-1-Guix.libvirt-qemu/ (16) 
-------------------->8-------------------

The last two may indicate there may be lurking another bug in the
cgroups configuration, but at least the machines can be created and
started/stopped seamlessly.  What do you think?

Happy hacking!
Miguel

[-- Attachment #2: 0001-services-libvirtd-Create-required-control-groups.patch --]
[-- Type: text/x-patch, Size: 1744 bytes --]

From a5dd055ea0fc20420cca6df2d38302596d397c49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
 <rosen644835@gmail.com>
Date: Sun, 27 Oct 2019 03:56:17 +0100
Subject: [PATCH 1/2] services: libvirtd: Create required control groups.

* gnu/services/virtualization.scm (libvirt-shepherd-service)
[libvirtd-activation]: New shepherd service.
[libvirtd]: Add a requirement of the new service.
---
 gnu/services/virtualization.scm | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm
index bc8ac9b40a..2f26945efd 100644
--- a/gnu/services/virtualization.scm
+++ b/gnu/services/virtualization.scm
@@ -428,8 +428,19 @@ potential infinite waits blocking libvirt."))
   (let* ((config-file (libvirt-conf-file config))
          (libvirt (libvirt-configuration-libvirt config)))
     (list (shepherd-service
+           ;; See https://libvirt.org/cgroups.html#currentLayoutGeneric
+           (documentation "Create the cgroup hierarchy required by libvirt.")
+           (provision '(libvirtd-activation))
+           (requirement '(file-system-/sys/fs/cgroup))
+           (one-shot? #t)
+           (start #~(lambda args
+                      (let ((path "/sys/fs/cgroup/unified/machine"))
+                        (or (access? path F_OK) (mkdir path)))))
+           (stop #~(lambda args #t)))
+          (shepherd-service
            (documentation "Run the libvirt daemon.")
            (provision '(libvirtd))
+           (requirement '(libvirtd-activation))
            (start #~(make-forkexec-constructor
                      (list (string-append #$libvirt "/sbin/libvirtd")
                            "-f" #$config-file)
-- 
2.23.0


[-- Attachment #3: 0002-services-libvirtd-Provide-ip-binary-at-runtime.patch --]
[-- Type: text/x-patch, Size: 1405 bytes --]

From 24f7c06a47562f410ceb982a3b2a0d44980de392 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
 <rosen644835@gmail.com>
Date: Sun, 27 Oct 2019 03:59:23 +0100
Subject: [PATCH 2/2] services: libvirtd: Provide ip binary at runtime.

* gnu/services/virtualization.scm (libvirt-shepherd-service): Add sbin to
the PATH variable, as ip binary is installed there.
---
 gnu/services/virtualization.scm | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gnu/services/virtualization.scm b/gnu/services/virtualization.scm
index 2f26945efd..488cd63041 100644
--- a/gnu/services/virtualization.scm
+++ b/gnu/services/virtualization.scm
@@ -444,9 +444,11 @@ potential infinite waits blocking libvirt."))
            (start #~(make-forkexec-constructor
                      (list (string-append #$libvirt "/sbin/libvirtd")
                            "-f" #$config-file)
+                     ;; For finding qemu and ip binaries.
                      #:environment-variables
-                     ;; For finding qemu binaries.
-                     '("PATH=/run/current-system/profile/bin")))
+                     (list (string-append
+                            "PATH=/run/current-system/profile/bin:"
+                            "/run/current-system/profile/sbin"))))
            (stop #~(make-kill-destructor))))))
 
 (define libvirt-service-type
-- 
2.23.0

bug#36634: Virtual Machine Manager (virt-manager)

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

Hi Miguel,

Miguel Arruga Vivas <rosen644835@gmail.com> writes:

> Hello again,
>
> The two patches attached create the cgroup directory needed and remove
> the warning for the ip binary missing.  Still the following errors
> are emitted to the log. 
>
> --------------------8<-------------------
> error : virConnectGetCPUModelNames:1109 : this function is not supported by the connection driver: virConnectGetCPUModelNames
> error : virConnectGetAllDomainStats:11705 : this function is not supported by the connection driver: virConnectGetAllDomainStats
> error : virCgroupSetValueRaw:473 : Unable to write to '/sys/fs/cgroup/unified/machine/qemu-1-Guix.libvirt-qemu/tasks': No such file or directory
> error : virCgroupRemoveRecursively:2383 : Unable to remove /sys/fs/cgroup/unified/machine/qemu-1-Guix.libvirt-qemu/ (16) 
> -------------------->8-------------------
>
> The last two may indicate there may be lurking another bug in the
> cgroups configuration, but at least the machines can be created and
> started/stopped seamlessly.  What do you think?

With the patch you submitted upstream (not the patches you attached to
your previous email here), I can confirm the issue is fixed for me, and
that I do NOT observe the errors you mentioned above.

I see the patch was incorporated into Guix master in commit
aa1f0896fb15a0bdcc5474839c8afdbb2520d603.  That is good, and I think
this issue can be resolved.  If nobody follows up in a few days' time,
let's close the bug report.

Regarding your other patch in this thread to find the "ip" program at
run-time, could you open a new bug report or patch (via
guix-patches@gnu.org) for that?  It seems unrelated to the issue at
hand.

Thank you for your help,

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#36634: Virtual Machine Manager (virt-manager)

[Miguel Arruga Vivas]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:
> With the patch you submitted upstream (not the patches you attached to
> your previous email here), I can confirm the issue is fixed for me,
> and that I do NOT observe the errors you mentioned above.

Sorry, I did not send the email here.

> I see the patch was incorporated into Guix master in commit
> aa1f0896fb15a0bdcc5474839c8afdbb2520d603.  That is good, and I think
> this issue can be resolved.  If nobody follows up in a few days' time,
> let's close the bug report.

I created 38032 on guix-patches and Ludo’ applied them.

> Regarding your other patch in this thread to find the "ip" program at
> run-time, could you open a new bug report or patch (via
> guix-patches@gnu.org) for that?

It was included in that patchset and it was unrelated, yes.  On
master it's commit 2dfb9ba406.

> It seems unrelated to the issue at hand.

I've been using the patches now on master this week and I have a really
annoying problem: the mouse is drawn on top of the vm screen.  This
one is unrelated too, so I should open a new bug, maybe to
virt-manager...

> Thank you for your help,

Thank you too, as you reported upstream and provided a great test
environment, which will help them to test my solution or find better
ones. :)

Happy hacking!
Miguel

bug#36634: (no subject)

[Brice Waegeneire]

Hello,

> Chris Marusich <cmmarusich@gmail.com> writes:
>> I see the patch was incorporated into Guix master in commit
>> aa1f0896fb15a0bdcc5474839c8afdbb2520d603.  That is good, and I think
>> this issue can be resolved.  If nobody follows up in a few days' time,
>> let's close the bug report.
> 
> I created 38032 on guix-patches and Ludo’ applied them.

Looks like this issue can be closed.
I can't reproduce the bug. Upstream fixed it in libvirt 5.10, so
we'll be able to remove Miguel's patch when we upgrade libvrit.

Brice.