Description of problem: Following a recent discussion on Fedora server@ [1], I am trying to reduce cockpit-machine's dependencies to avoid pulling in a gazillion desktop packages on a server [2]. c-machines uses "virsh domcapabilities" to detect which graphics devices to add to a newly created VM. In particular, it is looking for "spice" and "vnc". Version-Release number of selected component (if applicable): libvirt-client-7.6.0-5.fc35.x86_64 Aside from that, I only have a small set of libvirt/qemu packages installed: qemu-img-6.1.0-14.fc35.x86_64 libvirt-libs-7.6.0-5.fc35.x86_64 libvirt-daemon-7.6.0-5.fc35.x86_64 libvirt-daemon-driver-network-7.6.0-5.fc35.x86_64 libvirt-client-7.6.0-5.fc35.x86_64 libvirt-daemon-config-network-7.6.0-5.fc35.x86_64 libvirt-daemon-driver-interface-7.6.0-5.fc35.x86_64 libvirt-daemon-driver-qemu-7.6.0-5.fc35.x86_64 libvirt-daemon-driver-storage-core-7.6.0-5.fc35.x86_64 libvirt-glib-4.0.0-3.fc35.x86_64 libvirt-dbus-1.4.0-4.fc35.x86_64 python3-libvirt-7.6.0-1.fc35.x86_64 ipxe-roms-qemu-20200823-7.git4bd064de.fc35.noarch qemu-common-6.1.0-14.fc35.x86_64 qemu-system-x86-core-6.1.0-14.fc35.x86_64 qemu-kvm-core-6.1.0-14.fc35.x86_64 How reproducible: Always Steps to Reproduce: 1. Make sure that qemu-device-display-qxl package is *not* installed. 2. virsh domcapabilities|grep -A7 '<graphics supported' Actual results: <graphics supported='yes'> <enum name='type'> <value>sdl</value> <value>vnc</value> <value>spice</value> <value>egl-headless</value> </enum> </graphics> The "spice" capability is wrong -- if you try to actually create a VM with it, it fails: curl -L -o /tmp/cirros.qcow2 https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-i386-disk.img echo '#cloud-config' > /tmp/userdata virt-install --name c --os-variant cirros0.4.0 --memory 128 --wait -1 --noautoconsole --disk 'size=0.1,format=qcow2,backing_store=/tmp/cirros.qcow2' --graphics 'spice,listen=127.0.0.1' --cloud-init 'user-data=/tmp/userdata' Fails with Starting install... Allocating 'c.qcow2' | 102 MB 00:00:00 Removing disk 'c.qcow2' | 0 B 00:00:00 ERROR unsupported configuration: domain configuration does not support video model 'qxl' Domain installation does not appear to have been successful. Expected results: domcapabilities should only include "spice" if the QXL driver is actually installed. This isn't that easy to figure out from a client (this is why we use domcapabilities in the first place) Additional info: [1] https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/SZKLLRC6ZRBFRYF5KFTWH7Z6MZ2GRX7V/ [2] https://github.com/cockpit-project/cockpit-machines/pull/622
> This isn't that easy to figure out from a client I looked at this on Debian stable: dpkg -l | grep qemu ii ipxe-qemu 1.0.0+git-20190125.36a4c85-5.1 all PXE boot firmware - ROM images for qemu ii libvirt-daemon-driver-qemu 7.0.0-3 amd64 Virtualization daemon QEMU connection driver ii qemu-block-extra 1:5.2+dfsg-11+deb11u1 amd64 extra block backend modules for qemu-system and qemu-utils ii qemu-system-common 1:5.2+dfsg-11+deb11u1 amd64 QEMU full system emulation binaries (common files) ii qemu-system-data 1:5.2+dfsg-11+deb11u1 all QEMU full system emulation (data files) ii qemu-system-gui:amd64 1:5.2+dfsg-11+deb11u1 amd64 QEMU full system emulation binaries (user interface and audio support) ii qemu-system-x86 1:5.2+dfsg-11+deb11u1 amd64 QEMU full system emulation binaries (x86) ii qemu-utils 1:5.2+dfsg-11+deb11u1 amd64 QEMU utilities There is no '*qxl*' in /usr other than /usr/share/seabios/vgabios-qxl.bin, and yet `virsh domcapabilities` claims spice support, and virt-install with adding graphics spice actually does work. So merely testing for the qxl driver's existence is not enough, apparently this can also be built into the binary? Is there some better way to detect spice suport than `virsh domcapability`?
(In reply to Martin Pitt from comment #0) > > Expected results: domcapabilities should only include "spice" if the QXL > driver is actually installed. This isn't that easy to figure out from a > client (this is why we use domcapabilities in the first place) That's an incorrect correlation. SPICE is usable with any video driver device. Historically QXL could have some benefits for SPICE by providing 2-d acceleration but that is considered largely useless these days, and so we don't even recommend using QXL in most cases - virtio-vga or std vga are generally better choices https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
I see -- thanks Daniel. Should this then rather be a virt-install bug then? Or libvirt itself?
Yeah this is virt-install, sounds like we incorrectly assume qxl is available if spice is available.
We should probably re-consider whether we still want to default to use of QXL at all in virt-install/virt-manager, given its limited benefits. We picked it previously because we though it was going to be the universal best default for all OS going forward, but these days stdvga & virtio-vga are the universal best defaults, unless someone has explicitly installed QXL drivers in a windows guest, and even then its limited in benefit.
That makes sense going forward. Is there some particular "qxl available" test that c-machines could do for existing virt-install/libvirt/qemu versions? Thanks!
The best that I found is 'qemu-system-x86_64 -vga help' and checking if `qxl` is in it. That will only work for x86_64 machines obviously, but I think it's fine to not offer spice/QXL on non-x86?
virt-manager upstream and 4.0.0 does the right thing here, and the backports in the april virt-manager-3.2.0-5.fc35 seem to cover this too, so we can close this.