You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm having the same problem and found some additional information that may be useful for debugging.
Guest OS has spice-vdagent & spice-vdagentd running, but when resizing the UTM window the spice-vdagentd log shows the following:
● spice-vdagentd.service - Agent daemon for Spice guests
Loaded: loaded (/usr/lib/systemd/system/spice-vdagentd.service; indirect; vendor preset: disabled)
Active: active (running) since Sun 2022-05-29 13:30:57 CEST; 3s ago
TriggeredBy: ● spice-vdagentd.socket
Process: 868 ExecStart=/usr/bin/spice-vdagentd $SPICE_VDAGENTD_EXTRA_ARGS (code=exited, status=0/SUCCESS)
Main PID: 869 (spice-vdagentd)
Tasks: 2 (limit: 11808)
Memory: 1.1M
CPU: 9ms
CGroup: /system.slice/spice-vdagentd.service
└─869 /usr/bin/spice-vdagentd
May 29 13:30:57 derp systemd[1]: Starting Agent daemon for Spice guests...
May 29 13:30:57 derp systemd[1]: Started Agent daemon for Spice guests.
May 29 13:30:57 derp spice-vdagentd[869]: opening vdagent virtio channel
May 29 13:30:57 derp spice-vdagentd[869]: Set max clipboard: 104857600
May 29 13:30:57 derp spice-vdagentd[869]: invalid message size for VDAgentMonitorsConfig
May 29 13:30:57 derp spice-vdagentd[869]: Set max clipboard: 104857600
May 29 13:30:57 derp spice-vdagentd[869]: invalid message size for VDAgentMonitorsConfig
I quickly checked the spice-vdagentd source code, and this message is logged in spice-vdagentd.c on line 212 when the service receives a monitor configuration message with an unexpected message body size:
static void do_client_monitors(VirtioPort *vport, int port_nr,
VDAgentMessage *message_header, VDAgentMonitorsConfig *new_monitors)
{
VDAgentReply reply;
uint32_t size;
/* Store monitor config to send to agents when they connect */
size = sizeof(VDAgentMonitorsConfig) +
new_monitors->num_of_monitors * sizeof(VDAgentMonConfig);
if (message_header->size != size) {
syslog(LOG_ERR, "invalid message size for VDAgentMonitorsConfig");
return;
}
It seems as if the side that sends the monitor config message (UTM/QEMU) and the side that receives it (the spice-vdagentd inside the VM) are using a different protocol, possibly some mismatch in the SPICE version used to build UTM and the one in the VM? The spice-vdagent in Arch is version 0.22.1 released three months ago.
I did try to find some clues in the UTM source code but it seems this code that sends this message is somewhere in a QEMU or SPICE dependency, and building all that myself seems complicated.
UTM Version 3.2.4 (58)
Host OS: macOS Monterey 12.4
Guest OS: Arch Linux aarch64 with i3 desktop environment
Apple MacBook 14" M1 Pro
That's interesting, thanks. Can you downgrade spice-vdagent and see if that makes a difference? We're using an older version of spice on the host side and I wonder if anything changed in how that structure is sized.
osy
changed the title
I'm having the same problem and found some additional information that may be useful for debugging.
SPICE vdagent version mismatch causes resolution change issues
Feb 26, 2024
Guest OS has spice-vdagent & spice-vdagentd running, but when resizing the UTM window the spice-vdagentd log shows the following:
I quickly checked the spice-vdagentd source code, and this message is logged in spice-vdagentd.c on line 212 when the service receives a monitor configuration message with an unexpected message body size:
It seems as if the side that sends the monitor config message (UTM/QEMU) and the side that receives it (the spice-vdagentd inside the VM) are using a different protocol, possibly some mismatch in the SPICE version used to build UTM and the one in the VM? The spice-vdagent in Arch is version 0.22.1 released three months ago.
I did try to find some clues in the UTM source code but it seems this code that sends this message is somewhere in a QEMU or SPICE dependency, and building all that myself seems complicated.
UTM Version 3.2.4 (58)
Host OS: macOS Monterey 12.4
Guest OS: Arch Linux aarch64 with i3 desktop environment
Apple MacBook 14" M1 Pro
Originally posted by @w0utert in #4064 (comment)
The text was updated successfully, but these errors were encountered: