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
