* libvirt: A potential problem in the package and looking for guidance
@ 2022-05-18 11:43 Allan Adair
2022-05-23 15:28 ` Ludovic Courtès
0 siblings, 1 reply; 6+ messages in thread
From: Allan Adair @ 2022-05-18 11:43 UTC (permalink / raw)
To: guix-devel
Hi Guix!
I am using a libvirt-service-type in my system configuration and it seems
to be working. I can launch VMs using virt-manager, for example. However I
have run into a potential problem, and I think it has to do with the
libvirt package.
Additionally, I would like to present a plea to others on this list that
perhaps someone could share their system configurations for libvirt-
service-type if they use it in a similar way that I am attempting.
My end goal is that I would like to be able to launch several VM guests,
for them to be able to see each other through a local network, and I would
like to be able to SSH from my my host to VM guests.
The configuration for my service-type might be relevant here, so I will
share it here. I don't think that "mdns-adv?" and "log-level" are
particularly relevant to my problem, just keeping it exactly as it is
defined on my system. My user is part of the "libvirt" group.
(service libvirt-service-type
(libvirt-configuration
(unix-sock-group "libvirt")
(mdns-adv? #t)
(log-level 1)))
I am trying to do everything through qemu://session in user space, not
qemu://system. However it's not that big of a deal to use either. I just
haven't gotten either to work!
The first thing that I am trying to do is to SSH into a single running
guest from my host, and I have so far been unsuccessful.
So, the potential problem that I want to mention is that after having
poked around a bit and created the default network under a qemu://system
connection, a bridge device called "virbr0" is created.
And then for my guest VM which runs under a qemu://session connection, it
has a virtual network interface defined in XML. It was generated by the
virt-manager GUI:
<interface type="bridge">
<mac address="52:54:00:84:a5:5a"/>
<source bridge="virbr0"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00"
function="0x0"/>
</interface>
When I try to restart the VM with this modification, I get the following
error:
Error starting domain: '/usr/libexec/qemu-bridge-helper' is not a suitable
bridge helper: No such file or directory
Traceback (most recent call last):
File "/gnu/store/s15ahi35w0i274lima3dk41a7vr3kdbn-virt-manager-
3.2.0/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/gnu/store/s15ahi35w0i274lima3dk41a7vr3kdbn-virt-manager-
3.2.0/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
callback(*args, **kwargs)
File "/gnu/store/s15ahi35w0i274lima3dk41a7vr3kdbn-virt-manager-
3.2.0/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in
newfn
ret = fn(self, *args, **kwargs)
File "/gnu/store/s15ahi35w0i274lima3dk41a7vr3kdbn-virt-manager-
3.2.0/share/virt-manager/virtManager/object/domain.py", line 1329, in
startup
self._backend.create()
File "/gnu/store/g2x37cxh2ag5h66f0p9zaz9pkz2vcvgg-python-libvirt-
7.9.0/lib/python3.9/site-packages/libvirt.py", line 1353, in create
raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: '/usr/libexec/qemu-bridge-helper' is not a suitable
bridge helper: No such file or directory
Because the package is searching specifically for "/usr/libexec/qemu-
bridge-helper", I think this is a bug in the package definition. "/usr"
should probably be a prefix from the store, right?
Any comments or suggestions?
Thanks in advance for a response,
Allan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libvirt: A potential problem in the package and looking for guidance
2022-05-18 11:43 libvirt: A potential problem in the package and looking for guidance Allan Adair
@ 2022-05-23 15:28 ` Ludovic Courtès
2022-05-23 16:06 ` Maxime Devos
2022-05-23 19:44 ` Allan Adair
0 siblings, 2 replies; 6+ messages in thread
From: Ludovic Courtès @ 2022-05-23 15:28 UTC (permalink / raw)
To: Allan Adair; +Cc: guix-devel
Hi,
Allan Adair <allan@adair.no> skribis:
> File "/gnu/store/g2x37cxh2ag5h66f0p9zaz9pkz2vcvgg-python-libvirt-
> 7.9.0/lib/python3.9/site-packages/libvirt.py", line 1353, in create
> raise libvirtError('virDomainCreate() failed')
> libvirt.libvirtError: '/usr/libexec/qemu-bridge-helper' is not a suitable
> bridge helper: No such file or directory
>
>
> Because the package is searching specifically for "/usr/libexec/qemu-
> bridge-helper", I think this is a bug in the package definition. "/usr"
> should probably be a prefix from the store, right?
>
> Any comments or suggestions?
Presumably that “/usr/libexec/qemu-bridge-helper” reference is
hard-coded in the source. The solution in situations like this is to
replace it (using ‘substitute*’) by the absolute file name of the
corresponding program in /gnu/store.
(substitute* "some/file.py"
(("/usr/libexec/qemu-bridge-helper")
(search-input-file inputs "/bin/qemu-bridge-helper")))
HTH!
Ludo’.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libvirt: A potential problem in the package and looking for guidance
2022-05-23 15:28 ` Ludovic Courtès
@ 2022-05-23 16:06 ` Maxime Devos
2022-05-23 19:44 ` Allan Adair
1 sibling, 0 replies; 6+ messages in thread
From: Maxime Devos @ 2022-05-23 16:06 UTC (permalink / raw)
To: Ludovic Courtès, Allan Adair; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]
Ludovic Courtès schreef op ma 23-05-2022 om 17:28 [+0200]:
> Hi,
>
> Allan Adair <allan@adair.no> skribis:
>
> > File "/gnu/store/g2x37cxh2ag5h66f0p9zaz9pkz2vcvgg-python-libvirt-
> > 7.9.0/lib/python3.9/site-packages/libvirt.py", line 1353, in create
> > raise libvirtError('virDomainCreate() failed')
> > libvirt.libvirtError: '/usr/libexec/qemu-bridge-helper' is not a suitable
> > bridge helper: No such file or directory
> >
> >
> > Because the package is searching specifically for "/usr/libexec/qemu-
> > bridge-helper", I think this is a bug in the package definition. "/usr"
> > should probably be a prefix from the store, right?
> >
> > Any comments or suggestions?
>
> Presumably that “/usr/libexec/qemu-bridge-helper” reference is
> hard-coded in the source. The solution in situations like this is to
> replace it (using ‘substitute*’) by the absolute file name of the
> corresponding program in /gnu/store.
>
> (substitute* "some/file.py"
> (("/usr/libexec/qemu-bridge-helper")
> (search-input-file inputs "/bin/qemu-bridge-helper")))
Additionally, you can do
"grep -RF /usr/libexec /gnu/store/g2x37cxh2ag5h66f0p9zaz9pkz2vcvgg-python-libvirt-7.9.0"
in a shell to find the name of the source file to substitutify.
Greetings,
Maxime.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libvirt: A potential problem in the package and looking for guidance
2022-05-23 15:28 ` Ludovic Courtès
2022-05-23 16:06 ` Maxime Devos
@ 2022-05-23 19:44 ` Allan Adair
2022-05-23 20:35 ` Maxime Devos
1 sibling, 1 reply; 6+ messages in thread
From: Allan Adair @ 2022-05-23 19:44 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Thanks! Looks like I was on a good track. The only reference that I could
find to /usr/libexec/qemu-bridge-helper was in the meson.build file of the
libvirt package. I wrote a package variant that looks like this, to test:
(define-public libvirt-with-qemu-bridge-helper
(package
(inherit libvirt)
(name "libvirt-with-qemu-bridge-helper")
(arguments
(substitute-keyword-arguments (package-arguments libvirt)
((#:phases phases)
#~(modify-phases #$phases
;; libvirt needs to be able to find qemu's bridge helper
;; this is hacky, perhaps a patch on meson.build would be
better.
(add-after 'unpack 'find-qemu-bridge-helper
(lambda* (#:key inputs #:allow-other-keys)
(let* ((qemu (assoc-ref inputs "qemu")))
(substitute* "meson.build"
(("/usr/libexec/qemu-bridge-helper")
(format #f "~a/libexec/qemu-bridge-helper"
qemu))))))))))
(inputs
(modify-inputs (package-inputs libvirt)
(append qemu)))))
However the effort was fruitless, and my efforts on this are currently on
pause. If I am able to fix it I plan to submit a patch.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: libvirt: A potential problem in the package and looking for guidance
@ 2022-05-20 15:50 Rene Saavedra
0 siblings, 0 replies; 6+ messages in thread
From: Rene Saavedra @ 2022-05-20 15:50 UTC (permalink / raw)
To: guix-devel@gnu.org
Hi Allan,
Just an idea,
You can try to fix the package and try again.
--
Rene
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-05-23 20:35 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-18 11:43 libvirt: A potential problem in the package and looking for guidance Allan Adair
2022-05-23 15:28 ` Ludovic Courtès
2022-05-23 16:06 ` Maxime Devos
2022-05-23 19:44 ` Allan Adair
2022-05-23 20:35 ` Maxime Devos
-- strict thread matches above, loose matches on Subject: below --
2022-05-20 15:50 Rene Saavedra
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).