screen scaling and performance

[cirrusflyer]

I've tested installing Windows 10 using Win10_20H2_v2_English_x64.iso and found the dynamic screen scaling doesn't work and installation is fairly slow. I have installed the VirtIO drivers. When installing the same ISO in Gnome Boxes, the installation is much faster and the screen scaling works correctly. That's after installing the SPICE drivers. Both VMs seem to use the same video driver. Any ideas?

Update: looks like the performance issues were due to not using the "edge" version. But still can't get the dynamic screen scaling to work.

[AnErrupTion]

To get the dynamic screen scaling to work, you need to connect via virt-viewer or another SPICE-capable viewer. The default QEMU viewer isn't SPICE compatible and thus most of the SPICE integration (dynamic screen scaling as well as copy & paste) do not work.

[ofi]

Can you or someone else please elaborate on how to do this exactly? When running qemu-virgil (in my case with Pop!_OS 21.01 aka Ubuntu 20.10 on the host) the Viewer (whichever?) is started implicitly after the guest has come up. Neither did I recognize a command line option or parameter of qemu-virgil to select it, nor did i manage to figure out how to start the engine headlessly for connecting to it with the SPICE-capable virt-viewer from VMM afterwards.

For the same reason (i. e. the "wrong" viewer) it seems to be impossible to share the clipboard, even with package spice-vdagent installed in the guest machine.

So, thanks in advance for lending a hand here. [Edit: Added host system]

[AnErrupTion]

The -display option in QEMU needs to be set to spice-app in order to have it start virt-viewer (or spicy depending on what you have installed) without starting the other gtk or sdl display.

[ofi]

Thank you for coming back on this, but this leads to other failures (from my notes, here testing OpenSUSE but gives the same with Pop_OS):

# Setting -display spice-app yields:                                            
qemu-system-x86_64: SPICE GL support is local-only for now and incompatible with -spice port/tls-port

# removing -spice option from qemu call results in:                                            
qemu-system-x86_64: egl: eglGetDisplay failed                                   
qemu-system-x86_64: Failed to initialize EGL render node for SPICE GL           

# starting with sudo (suspecting insufficient rights for qemu:///system) changes this to:
mkdir: cannot create directory '/run/user/0': Permission denied                 
qemu-system-x86_64: -drive media=cdrom,index=0,file=/media/<path-to-iso-image-dir>/opensuse-leap-15.3-NET-x86_64.iso:
Could not open '/media/<path-to-iso-image-dir>/openSUSE-Leap-15.3-NET-x86_64.iso': Permission denied

The last one is weird on its own, because the config references a qcow2 disk image which is detected when not running with sudo.

I have read two (officially closed) issues by the libvirt folks at redhat which have given me no further insights. For not wasting more of your time, I'd appreciate your opinion on leaving the script solution alone for the time being and continue with virt-manager, although I'd prefer the beauty of simplicity using a script with simple configs alongside the corresponding images (which in turn facilitates maintenance processes, e.g. backup, a lot).

[Edit: plus linebreaks in code block for better reading]

[AnErrupTion]

You must only remove the port option from -spice, not the whole thing.

[ofi]

Ok, thanks again. I didn't try to do this because 'qemu-virgil -help' states that at least the port setting has to be present. But trying to omit the port sitll does not do the trick. Citing my notes again:

# removing only the port setting from the -spice option (leaving disable-ticketing, because one argument has
# to be present) again yields:
qemu-system-x86_64: egl: eglGetDisplay failed
qemu-system-x86_64: Failed to initialize EGL render node for SPICE GL

# the whole executed qemu call reads:
/snap/bin/qemu-virgil
    -name opensuse-leap_15-3,process=opensuse-leap_15-3
    -enable-kvm
    -machine q35
    -cpu host,kvm=on
    -smp 4,sockets=1,cores=4,threads=1
    -m 8G
    -device virtio-balloon
    -drive media=cdrom,index=0,file=
    -drive media=cdrom,index=1,file=
    -drive if=none,id=drive0,cache=directsync,aio=native,format=qcow2,file=/home/ofi/QEMU-VMs/OpenSUSE/opensuse_15-3_test.qcow2
    -device virtio-blk-pci,drive=drive0,scsi=off
    -device virtio-vga,virgl=off,xres=2048,yres=1152,
    -display spice-app,gl=off
    -device qemu-xhci,id=usb,p2=8,p3=8
    -device usb-kbd,bus=usb.0
    -device usb-tablet,bus=usb.0
    -device virtio-net,netdev=nic
    -netdev user,hostname=opensuse-leap_15-3,smb=/home/ofi,hostfwd=tcp::22224-:22,hostfwd=tcp::8123-:8123,hostfwd=tcp::8888-:80,id=nic
    -audiodev pa,id=pa,server=unix:/run/user/1000/pulse/native,out.stream-name=quickemu-opensuse-leap_15-3,in.stream-name=quickemu-opensuse-leap_15-3
    -device intel-hda
    -device hda-duplex,audiodev=pa,mixer=off
    -rtc base=localtime,clock=host
    -object rng-random,id=rng0,filename=/dev/urandom
    -device virtio-rng-pci,rng=rng0
    -spice disable-ticketing
    -device virtio-serial-pci
    -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0
    -chardev spicevmc,id=spicechannel0,name=vdagent
    -serial mon:stdio

(BTW: it does not work with "gl=on" either.)

My next step is to start from the beginning, this time trying the EFI boot, but if this fails as well, I will have to stick with VirtualBox (using virt-manager copy & paste works but dynamic resolution triggered by resizing the host window does not). Otherwise I will come back here for reporting.

All that knitty-gritty-patching is grist to the mills of advocates on propietary software - at least as far as QEMU is concerned, but it simply seems not to be ready for daily use in combination with graphical frontends and non-experts on graphics hardware like me (with or w/o libvirt and not questioning the benefits of quickemu for standalone lab testing of distros at fixed resolutions).

Anyway: I really appreciate your support attempts. Thanks a lot!