INSTALL.sh

[gueniewie]

Hello This is the ERROR from INSTALL.sh

Problem: package qemu-device-display-vhost-user-gpu-1024:7.2.0-6.btrh9.x86_64 requires libvirglrenderer.so.1()(64bit), but none of the providers can be installed

• widersprüchliche Anforderungen

[gueniewie]

Hello Ladar, I can tell you a success of INSTALL.sh on an Oracle Linux 9.1, no installation errors :-). Is a Virtualbox installation. I can call and configure virt-manager, now I can try it on my "server", I will use oracle linux as it worked here the first time ;-). why this doesn't work with AlmaLinux is a mystery to me. I can't create a BUILD.sh yet, are there problems with qemu build?

Thanks for your help and time for this RH problem. It's just better and more understandable for me than "cockpit"

THANK YOU Günther

[gueniewie]

Bad News when I like to Install a new KVM I have this Error bei openig a window in virt-managerError launching create dialog: list index out of range

Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/createvm.py", line 176, in show_instance cls._instance = vmmCreateVM() File "/usr/share/virt-manager/virtManager/createvm.py", line 248, in init self._init_state() File "/usr/share/virt-manager/virtManager/createvm.py", line 380, in _init_state self._os_list = vmmOSList() File "/usr/share/virt-manager/virtManager/oslist.py", line 44, in init self._init_state() File "/usr/share/virt-manager/virtManager/oslist.py", line 60, in _init_state all_os = virtinst.OSDB.list_os(sortkey="label") File "/usr/share/virt-manager/virtinst/osdict.py", line 157, in list_os oslist = [_OsVariant(osent) for osent in File "/usr/share/virt-manager/virtinst/osdict.py", line 157, in oslist = [_OsVariant(osent) for osent in File "/usr/share/virt-manager/virtinst/osdict.py", line 245, in init self.name = self._short_ids[0] IndexError: list index out of range

[gueniewie]

Bad News when I like to Install a new KVM I have this Error bey opening a window in virt-managerError launching create dialog: list index out of range

Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/createvm.py", line 176, in show_instance cls._instance = vmmCreateVM() File "/usr/share/virt-manager/virtManager/createvm.py", line 248, in init self._init_state() File "/usr/share/virt-manager/virtManager/createvm.py", line 380, in _init_state self._os_list = vmmOSList() File "/usr/share/virt-manager/virtManager/oslist.py", line 44, in init self._init_state() File "/usr/share/virt-manager/virtManager/oslist.py", line 60, in _init_state all_os = virtinst.OSDB.list_os(sortkey="label") File "/usr/share/virt-manager/virtinst/osdict.py", line 157, in list_os oslist = [_OsVariant(osent) for osent in File "/usr/share/virt-manager/virtinst/osdict.py", line 157, in oslist = [_OsVariant(osent) for osent in File "/usr/share/virt-manager/virtinst/osdict.py", line 245, in init self.name = self._short_ids[0] IndexError: list index out of range

[ladar]

A lot was mentioned. The new install script should be installing an updated virt-manager and virglrender package. To confirm:

#  rpm -q virglrenderer virglrenderer-devel virglrenderer-test-server  virt-manager virt-manager-common 
virglrenderer-0.10.4-2.20230104git88b9fe3b.btrh9.x86_64
virglrenderer-devel-0.10.4-2.20230104git88b9fe3b.btrh9.x86_64
virglrenderer-test-server-0.10.4-2.20230104git88b9fe3b.btrh9.x86_64
virt-manager-4.1.0-2.btrh9.noarch
virt-manager-common-4.1.0-2.btrh9.noarch

Make sure the versions strings match, but also make sure they all have the btrh9 string in the package name, instead of el9.

Assuming you have everyting you need installed, the next question is whether virt-manager has issues, even if you have NO virtual machines configured. If you can't remove the VMs to test, then perhaps updating your configuration so it doesn't auto-connect to the daemon might be a good test. If the error comes from the existing VM configs, then I probably know what the problem is.

For some reason, RHEL renames their qemu binary from the standard/default from the defaultqemu-system-x86_64andqemu-system-i386toqemukvm. It's probably a holdover from when KVM support was first added. The issue is that some guests might be configured to use the qemu-kvm binary in their libvirt XML config. You can either update the XML to point at the correct binary, or use the ln commands in the install script to trick things into working.

There is a simllar problem with the machine target names. RHEL uses non-standard name for the machine config. That gets stored in the XML, and once the packages have been replaced, those machine types won't exist anymore. That will cause virt-manager to abort because it thinks the XML is invalid.

To see the available machine targerts on an updated system, run:

# qemu-system-x86_64 -machine help
Supported machines are:
microvm              microvm (i386)
pc                   Standard PC (i440FX + PIIX, 1996) (alias of pc-i440fx-7.2)
pc-i440fx-7.2        Standard PC (i440FX + PIIX, 1996) (default)
pc-i440fx-7.1        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-7.0        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-6.2        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-6.1        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-6.0        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-5.2        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-5.1        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-5.0        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-4.2        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-4.1        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-4.0        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-3.1        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-3.0        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.9        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.8        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.7        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.6        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.5        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.4        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.3        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.2        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.12       Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.11       Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.10       Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.1        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-2.0        Standard PC (i440FX + PIIX, 1996)
pc-i440fx-1.7        Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-1.6        Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-1.5        Standard PC (i440FX + PIIX, 1996) (deprecated)
pc-i440fx-1.4        Standard PC (i440FX + PIIX, 1996) (deprecated)
q35                  Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-7.2)
pc-q35-7.2           Standard PC (Q35 + ICH9, 2009)
pc-q35-7.1           Standard PC (Q35 + ICH9, 2009)
pc-q35-7.0           Standard PC (Q35 + ICH9, 2009)
pc-q35-6.2           Standard PC (Q35 + ICH9, 2009)
pc-q35-6.1           Standard PC (Q35 + ICH9, 2009)
pc-q35-6.0           Standard PC (Q35 + ICH9, 2009)
pc-q35-5.2           Standard PC (Q35 + ICH9, 2009)
pc-q35-5.1           Standard PC (Q35 + ICH9, 2009)
pc-q35-5.0           Standard PC (Q35 + ICH9, 2009)
pc-q35-4.2           Standard PC (Q35 + ICH9, 2009)
pc-q35-4.1           Standard PC (Q35 + ICH9, 2009)
pc-q35-4.0.1         Standard PC (Q35 + ICH9, 2009)
pc-q35-4.0           Standard PC (Q35 + ICH9, 2009)
pc-q35-3.1           Standard PC (Q35 + ICH9, 2009)
pc-q35-3.0           Standard PC (Q35 + ICH9, 2009)
pc-q35-2.9           Standard PC (Q35 + ICH9, 2009)
pc-q35-2.8           Standard PC (Q35 + ICH9, 2009)
pc-q35-2.7           Standard PC (Q35 + ICH9, 2009)
pc-q35-2.6           Standard PC (Q35 + ICH9, 2009)
pc-q35-2.5           Standard PC (Q35 + ICH9, 2009)
pc-q35-2.4           Standard PC (Q35 + ICH9, 2009)
pc-q35-2.12          Standard PC (Q35 + ICH9, 2009)
pc-q35-2.11          Standard PC (Q35 + ICH9, 2009)
pc-q35-2.10          Standard PC (Q35 + ICH9, 2009)
isapc                ISA-only PC
none                 empty machine
x-remote             Experimental remote machine

In contrast, this is the list from a RHEL 8 system:

# /usr/libexec/qemu-kvm -machine help
Supported machines are:
pc                   RHEL 7.6.0 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-rhel7.6.0)
pc-i440fx-rhel7.6.0  RHEL 7.6.0 PC (i440FX + PIIX, 1996) (default)
pc-i440fx-rhel7.5.0  RHEL 7.5.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.4.0  RHEL 7.4.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.3.0  RHEL 7.3.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.2.0  RHEL 7.2.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.1.0  RHEL 7.1.0 PC (i440FX + PIIX, 1996)
pc-i440fx-rhel7.0.0  RHEL 7.0.0 PC (i440FX + PIIX, 1996)
q35                  RHEL-8.6.0 PC (Q35 + ICH9, 2009) (alias of pc-q35-rhel8.6.0)
pc-q35-rhel8.6.0     RHEL-8.6.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel8.5.0     RHEL-8.5.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel8.4.0     RHEL-8.4.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel8.3.0     RHEL-8.3.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel8.2.0     RHEL-8.2.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel8.1.0     RHEL-8.1.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel8.0.0     RHEL-8.0.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.6.0     RHEL-7.6.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.5.0     RHEL-7.5.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.4.0     RHEL-7.4.0 PC (Q35 + ICH9, 2009)
pc-q35-rhel7.3.0     RHEL-7.3.0 PC (Q35 + ICH9, 2009)
none                 empty machine

Note the names are similar. It's just that the normal ones have a suffix based on the QEMU release. While the RHEL targets use the string rhel and the OS release version.

Again, updating the XML will resolve this.

At some point I;d like to find a workaround that will create the standard targets, and the RHEL targets, so this issue goes away. But for now, when you compile QEMU using the RHEL rules, it generates the RHEL naming scheme, and if you use the Fedora rules (which I use because they add Spice support), it creates the default targets.

If the above doesn't fix things up, then I'll need more info.

[gueniewie]

Hello Ladar, the RPM installation packages are identical,

I reinstalled everything in a new virtualBox VM almaLinux 9.1 (minimal install), after the installation I have your qemu parameters, only AFTER the START of virt-manger, when you click on NEW machine, the error messages come up and there is no configuration window open?

This is the same on all distris, whether centos alma or rocky.

did you forget to update the git repository (?) because you write about a new INSTALL.sh, virt-manger... I still have the one from 2 weeks ago

I also have the new parameters on my server, after the broken virt-manager I experimented with cockpit, after a long time back and forth I was able to import 2 machines, I would prefer to have the virt-manager because it has better setting options available.

what is going wrong with me is a mystery to me?

[gueniewie]

I heard that virt-manaer should still work with centos stream 9. I'll test it when I find an iso? ;-)

[gueniewie]

could it be that the virt-manager is missing some dependencies, see older posts because the error messages are "almost" the same?

[ladar]

could it be that the virt-manager is missing some dependencies, see older posts because the error messages are "almost" the same?

@gueniewie I think you're right. The good news is I'm working on a rebuild, and it should include an updated INSTALL.sh script which I'm hoping will do a better a job updating systems which may already have upstream packages installed. I suspect the current version isn't replacing some of the official packages like it needs to.

I'm also rebuilting a handful of additional dependencies. The most significant is the suite of libvirt packages. I'm hoping these new packages will resolve a couple of annoying GPU acceleration/stability issues I am running into. The downside is that it will require replacing the upstream libvirt server/daemon packages, which I was hoping to avoid.

As for the timeframe, my middle-aged laptoip takes a 2-3 hours to go through the entire build process, when starting with an empty.clean virtual machine. And I keep having to repeat that process as I make fixes/improvements. so I can't promise a time frame as to the upload. Hopefully in the next day or so.

Given how much has changed, I might upload the packaegs to a branch for testing first.

[ladar]

@gueniewie two more footnotes. A big chunk of my effort this build has been getting theqt-virt-manager package built with SPICE support. It's required a bit of effort, as there were a handful of dependencies required that also aren't available on RHEL. We;ll see if it's an upgrade.

I also wanted to say, you mentioned Cockpit. I prefer to manage systems remotely using SSH, so I haven't used it much. BUT... there were a couple of packages, spice-html5 specifically, which I am not currently rebuilding. A rebuilt gtk-vnc package is coming with the next update, but there might be VNC+HTML packages, like novnc that Cockpit uses, which would benefit from being rebuilt/updated with GPU/SPICE support.

If we can figure out which ones, and they aren't hard to add, and/or you can do the work of figuring out how to build them, I can add them as well.

[gueniewie]

Hello Ladar, You work too deep for my knowledge of all these packages ;-)

It seems that the versions of "CentOs 9 Stream" are newer and also work with my test installation (VirtualBox)? I can't install KVM in the VirtualBox installation (too little memory), but the virt-manager opens its windows well-behaved :-)

I usually also go to my server (basement) via ssh, since I had a crash I switched to version 9 and am now struggling with the consequences.

Apparently there are no SRPM packages for the "CentOS 9 stream" version, I wanted to see the difference in the spec files.

I hope you can still get everything to work so that I can get my (beloved) virt-manager again ;-).

Thank you for your time and work

[ladar]

@gueniewie try something like:

dnf --enablerepo=* --source download virt-manager

That's the easiest way to get a source RPM, from within a C9S system. It usually works, although sometimes binary RPMs will get pushed to a repo before the source packages, so it isn't always the answer, particularly when the package version matters (like with kernel releases).

There are other ways, but that's the easiest way. You can also use the method from the BUILD.sh script to grab SRPMS from the repos of a different OS, like I do for the Fedora packages.

Of course a web browser also works, provided you know where to look:

virt-manager-3.2.0-12.el9.src.rpm virt-manager-3.2.0-13.el9.src.rpm virt-manager-3.2.0-14.el9.src.rpm virt-manager-4.0.0-1.el9.src.rpm virt-manager-4.1.0-1.el9.src.rpm

Those are the C9S SRPMs.

[ladar]

@gueniewie the updated packages/install script is uploading now to the experimental/expanded-dependency-rebuild branch. Can you give it a try?

I played around with the install logic quite a bit, and had trouble getting it to work on every system I tested. In the end I ran out of diverse system setups to try it on, so please test it, and let me know.

Assuming the install works, you should be aware you're replacing libvirt and other system daemons with these new packages. If you can reboot, after the install to make sure everything gets restarted. The RPMs should restart the required services during the update, but I haven't tested/checked that yet.

[gueniewie]

Hello Ladar, I have now got the zip archive of the experimental package, unfortunately the INSTALL.sh refuses to work at the beginning apparently has a problem with DNF.

How do I actually get the experiment archive with git?

I try to send you the error messages as an attachment, unfortunately they are in German (quick installation)

This is a fresh minimal installation of alma9 in VirtualBox install.txt

[ladar]

I think the problem is that you're missing the EPEL repo. Run this first:

dnf --enablerepo=extras --quiet --assumeyes install epel-release 

That should fix some of the errors. I only include dependent RPMs in the repo that aren't in baseos/appstream or epel. Mostly devel packages from crb, and I think one package from Remi's repo.

[ladar]

How do I actually get the experiment archive with git?

You could clone the entire repo, and then checkout the experimental branch. But the repo has gotten pretty massive. I'd suggest a shallow clone of just the head commit on the experimental branch, which is possible, but I'd have to lookup the clone option syntax to make that happen, as it's been awhile.

[gueniewie]

You are correct it is missing the repositories ;-) The clone syntax is git checkout -b experimental origin/original I found it :-) It is now running the INSTALL.sh ......

[gueniewie]

Hello Ladar, You install a complete desktop with Install.sh. Is this necessary, I have almost 900 packages installed?

After a reboot: The good news is that the Virt-manger starts and also brings up the window for creating a new KVM client?

What actually happens when you run the install script again? because a part is already installed on the server and I don't want to install it again :-(

How do you actually get this btrh9 in the files I'm trying to build an rspamd package with "opensuse buildservice" and just can't get the "el9" in the RPM (to recognize)

You seem to have reached a milestone ;-). let's wait and see what's next

[gueniewie]

Hello Ladar,

I make a pull from the experimental git my files have the date from 1. March is this the latest ?

[gueniewie]

I found tis Errors in the log,

Ausgeführtes Scriptlet: tracker-miners-3.1.2-1.el9.x86_64 806/895 Failed to preset unit, unit tracker-miner-rss-3.service does not exist.

Installieren : qemu-guest-agent-1024:7.2.0-7.btrh9.x86_64 886/895 Ausgeführtes Scriptlet: qemu-guest-agent-1024:7.2.0-7.btrh9.x86_64 886/895 Created symlink /etc/systemd/system/dev-virtio\x2dports-org.qemu.guest_agent.0.device.wants/qemu-guest-agent.service → /usr/lib/systemd/system/qemu-guest-agent.service. Unit /usr/lib/systemd/system/qemu-guest-agent.service is added as a dependency to a non-existent unit dev-virtio\x2dports-org.qemu.guest_agent.0.device.

[gueniewie]

Hello Ladar,

I mean I have found a problem? after a reboot libvirtd don't start again, when I start manual, it is starting. I have in the Moment not found any in the logs :-( Alma9

[ladar]

I found tis Errors in the log,

Ausgeführtes Scriptlet: tracker-miners-3.1.2-1.el9.x86_64 806/895 Failed to preset unit, unit tracker-miner-rss-3.service does not exist.

Installieren : qemu-guest-agent-1024:7.2.0-7.btrh9.x86_64 886/895 Ausgeführtes Scriptlet: qemu-guest-agent-1024:7.2.0-7.btrh9.x86_64 886/895 Created symlink /etc/systemd/system/dev-virtio\x2dports-org.qemu.guest_agent.0.device.wants/qemu-guest-agent.service → /usr/lib/systemd/system/qemu-guest-agent.service. Unit /usr/lib/systemd/system/qemu-guest-agent.service is added as a dependency to a non-existent unit dev-virtio\x2dports-org.qemu.guest_agent.0.device.

Technically the qemu-guest-agent package isn't needed on hosts. I will add a filter so it doesn't get installed anymore.

[gueniewie]

On my system it is installed to shutdow the guests on a server reboot and also start it again ?

[gueniewie]

A...... no it is the libvirt-guest that I meen

[ladar]

You install a complete desktop with Install.sh. Is this necessary, I have almost 900 packages installed?

No, it is not necessary. The INSTALL.sh script installs everything that isn't a source/debug package. Since some of the packages are GUI apps (virt-manager, etc), they require the desktop packages.

It might be time to sort/organize some of the packages into subfolders. Although updating the installer to handle server vs desktop environments will be more complicated.

The only reason I created the INSTALL.sh script in the first place was to help people (including myself) avoid a ending up with both btrh and el9 packages installed at the same time, since that would probably lead to various bugs.

[ladar]

On my system it is installed to shutdow the guests on a server reboot and also start it again ?

I'm not following. You're saying you reboot, and now your guests won't start?

[gueniewie]

Hello Ladar, I didn't mean to criticize you, the whole thing just surprised me.

For me, the virtmanager "usually" works like this if I give it the package "xorg-x11-xauth.x86_64" and then go from the client to the server with "ssh -X root@server" the GUI works ;-)

| I'm not following. You're saying you reboot, and now your guests won't start?

No, I mean libvirt-guests, the tool looks at running systems and also starts the KVMs after a reboot.

But what seems to be a problem is that libvirtd doesn't start after a reboot. on the alm9 installation, just now, with your experimintal repo's you can start libvirtd by hand but something prevents the automatic start at boot

[gitenstuff]

Is this project being maintained?