Can can someone verify: cockpit-machines able to show VMs on qemu:///system after upgrade to F41?

Ask Fedora
, , ,
1

Hi,
After upgrading my major installation to F41, I experience an issue. But before checking out with the maintainer(s), I would like to get a verification if that is a wider phenomenon others experience too.

It would be cool if the subsequent issue can be verified by someone who …

  • upgraded from F40 to F41 (not a new installation or upgrade from F39 to F41!)
  • had already installed cockpit and cockpit-machines locally on their F40
  • knows that on their F40, virtual machines were properly shown in the list of the “Virtual machines” category of cockpit when accessing cockpit in the web browser
  • have a qemu:///system configuration
  • have not customized SELinux, and you do not use any confined user accounts (if you don’t know what that is, it means you do not use it)

If you belong the the defined group, can you just login to your cockpit, go to the category “Virtual machines” and then check out if the list of virtual machines is shown?

The issue in my case is, that the machines are no longer shown: it just shows “No VM is running or defined on this host”. However, I can see in virt-manager that all machines are still there. Also, I can create new machines with cockpit, but once reloading the page, it again shows “No VM is running or defined on this host” while the new machine appear in virt-manager.

I am not seeking troubleshooting here, just verification. This would help to determine which component is the origin of the issue, and likely would help to decrease the amount of work for the maintainers. There are two possibilities, and I currently have not the resources to verify which of the two it is. A short verification could give strong indication and allow to solve this phenomenon quicker :classic_smiley:

Thanks :wink:

Supplement: along with the information if it works or not, it would be (in both cases) interesting to know if you experience a “pool-libvirt-db” denial at any time you are in cockpit (plus the ~10 seconds after).

2

This sounds kind of similar to the issue I got, though the error message looks to be different. Perhaps these bug reports might be relevant:

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

For me, I got it working by doing the steps outlined in the bugzilla report’s first comment:

Do
allow this access for now by executing:

# ausearch -c 'pool-libvirt-db' --raw | audit2allow -M my-poollibvirtdb
# semodule -X 300 -i my-poollibvirtdb.pp
1 Like
3

Thanks. I just worked myself through some step-by-step confinement testing as the behavior of the phenomenon is a little odd, but the ticket seems indeed related: I just updated it.

1 Like