Package: libspice-server1 Version: 0.14.3-2.1 Severity: normal Dear Maintainer,
* What led up to the situation? I noticed that guest systems (Ubuntu 18.x and 20.x) of a QEMU VM stopped updating their internal display configuration (resizing the display after resizing the host window) with upgrade from Buster to Bullseye (0.14.0 -> 0.14.3-2.1). * What exactly did you do (or not do) that was effective (or ineffective)? Initially, I verified that the QEMU host configuration included correct options to use QXL display and SPICE protocol. AFAIK, it does: -vga qxl \ -device virtio-serial-pci \ -spice unix,addr=qemu-spice.sock,disable-ticketing \ -device virtserialport,chardev=spicechannel0,name=com.redhat.spice.0 \ -chardev spicevmc,id=spicechannel0,name=vdagent I also verified the guest systems still run spice-vdagent. They do. * What was the outcome of this action? I noticed that the guest systems started reporting an error, which I don't remember seeing before: Sep 01 09:50:04 GUEST spice-vdagentd[11881]: invalid message size for VDAgentMonitorsConfig >From the vdagentd code, it seems that it will discard the configuration of the host window for the guests display if the message size isn't exactly what it expects. This results in a scaled image of the guest display, which is not what I expect for the VMs using SPICE protocol. * What outcome did you expect instead? I expected the guest system to re-configure its graphics output to fit the window on the host, as it did before. * Additional information I tried instrumenting the vdagentd code to figure out why it considers the monitor configuration invalid and noticed that the virtio messages are larger than the code expects: ... invalid message size for VDAgentMonitorsConfig (392 != 328, monitors 16, sizeof 8) 392 above is `message_header->size` from src/vdagentd/vdagentd.c, while 328 is the expected message size calculated in the same function. Indeed, making the abort condition to allow for larger messages allows the messages to be interpreted and the decoded monitors configuration seems to be correct. Guest display re-configuration with that works as expected (at least on visual inspection). The problem now is that I'd rather avoid re-compiling spice-vdagent in all guest images (of which there are many). I would like to fix it in the host code instead, since it seemed to work before the upgrade. Regards, Alex -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.13 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libspice-server1 depends on: ii libc6 2.31-13 ii libglib2.0-0 2.66.8-1 ii libgstreamer-plugins-base1.0-0 1.18.4-2 ii libgstreamer1.0-0 1.18.4-2.1 ii libjpeg62-turbo 1:2.0.6-4 ii liblz4-1 1.9.3-2 ii libopus0 1.3.1-0.1 ii liborc-0.4-0 1:0.4.32-1 ii libpixman-1-0 0.40.0-1 ii libsasl2-2 2.1.27+dfsg-2.1 ii libssl1.1 1.1.1k-1+deb11u1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages libspice-server1 recommends: ii gstreamer1.0-libav 1.18.4-3 ii gstreamer1.0-plugins-base 1.18.4-2 ii gstreamer1.0-plugins-good 1.18.4-2 Versions of packages libspice-server1 suggests: ii gstreamer1.0-plugins-ugly 1.18.4-2 -- no debconf information