Hi Peter,
I am still on the progress of testing and automating my libvirt setup (kvm, libvirt,
cockpit). I may provide another list during the next week with a couple of findings.
From my perspective this whole change went somewhat sideways and opening/addressing issues
is something that may be done/is doable in the current release.
But, this is only me speaking from a user perspective and there may be others, that are
having a better understanding of how this should be addressed properly.
---
### Contact
dschier(a)while-true-do.io
while-true-do.io
### Code
code.while-true-do.io
github.com/daniel-wtd/
github.com/while-true-do/
### Social
dschier @libera.chat
### Disclaimer
If not stated otherwise all of my work is licensed under a Creative Commons Attribution
4.0 International License (
creativecommons.org/licenses/by/4.0/).
On 9. Nov 2021, at 19:49, Peter Boy <pboy(a)uni-bremen.de>
wrote:
I'm still in the process to update documentation and recommendations of installing
libvirt virtualization on Fedora 35 Server.
As discussed some times ago libvirt switsched from monolithic libvirtd to modular
archticture resulting in various daemons and sockets.
(a)
Installing on a fresh F35 Server installation I get various disconcerting warnings /
error messages
(1)
> Installing : qemu-common-2:6.1.0-9.fc35.x86_64
253/361
> Running Scriptlet: qemu-common-2:6.1.0-9.fc35.x86_64
253/361
> useradd warning: qemu's uid 107 outside of the SYS_UID_MIN 201 and SYS_UID_MAX
999 range.
That's definitely a warning, user qemu is created with UID 107. It's messy, but
it works.
(2)
> Running Scriptlet: libvirt-daemon-7.6.0-3.fc35.x86_64
298/361
> Failed to preset unit: Unit file virtlogd-ro.socket does not exist.
> Failed to preset unit: Unit file virtlockdd.socket does not exist.
> Created symlink /etc/systemd/system/sockets.target.wants/virtproxyd.socket →
/usr/lib/systemd/system/virtproxyd.socket.
Wondering about that. According to libvirt documentation those are needed. But so far I
didn't get any problems.
(3)
> Installing : libvirt-daemon-driver-storage-core-7.6.0-3.fc35.x86_64
299/361
> Installing : libvirt-daemon-driver-network-7.6.0-3.fc35.x86_64
300/361
>
> Running Scriptlet: libvirt-daemon-driver-libxl-7.6.0-3.fc35.x86_64
361/361
> Running Scriptlet: libvirt-daemon-driver-vbox-7.6.0-3.fc35.x86_64
361/361
> Running Scriptlet: libvirt-daemon-driver-storage-7.6.0-3.fc35.x86_64
361/361
> Running Scriptlet: virt-win-reg-1.47.2-2.fc35.noarch
361/361
> Failed to connect to bus: invalid argument
> Failed to connect to bus: invalid argument
Seems to be a general issue with dnf / packaging. The severity/significance is unclear to
me.
Has anyone else had these issues?
All of this probably doesn't cause any serious problems, but it is at least very
unattractive. Do we want to get this fixed now or postpone it to Fedora 36?
(b)
The current default installation doesn't activate the internal network virbr0 to
enable internal protected communication between VMs und host. Instead you have to
separately start/configure 1 or may be more 'additional daemons' for the service
of 'secondary drivers'. Has anyone already worked with it and gathered experience?
At first glance, you only need virtnetworkd and get a similar configuration as before.
On the other hand, it might be advantageous to take the opportunity and switch /
recommend (in the documentation) to dispense with the libvirt internal network
configuration and configure a virtual bridge right away using NetworkManager and its
dnsmasq plugin. Then we would achieve a consistent network management without libvirt
interfering, bypassing NetworkManager. I also hope for a better integration of the name
resolution by systemd-resolved, which due to the idiosyncrasy of libvirt only works via an
auxiliary construction with hooks (but also not smoothly).
What is your opinion about that?
The current still incomplete version of the updated documentation is available at
https://docs.stg.fedoraproject.org/en-US/fedora-server/virtualization-ins...
Any hints / comments appreciated.
Best
Peter
_______________________________________________
server mailing list -- server(a)lists.fedoraproject.org
To unsubscribe send an email to server-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure