/cc #32020

and more directly, cc @aszlig @vcunat

@grahamc: Using VNC looks like a bit of a workaround to me, because first of all the machine states will get further away from real machines, it also doesn't capture bootup and/or anything else that doesn't involve an X server and the video stream also will come with an overhead because it travels through the guest's user space.

Maybe it's a better idea to create a patch for qemu itself, like for example this one?

Regardless of that, using SPICE instead of VNC IMHO is a better option (if you don't want to patch qemu) because it doesn't have the overhead mentioned above, it's supported by QEMU using the QXL video device and also doesn't involve additional options in the virtualisation module as we can simply use a UNIX socket instead of assigning a TCP port.

it also doesn't capture bootup and/or anything else that doesn't involve an X server

This does capture boot up, and is implemented in and by qemu as a way of viewing the video output of the guest from the host. It isn't passing the VNC connection to the guest. For this reason, I think it isn't so much of a workaround and doesn't change the guest configuration in any appreciable way.

I would have liked to use a unix socket, but couldn't find a VNC recorder which supported it.

QXL would be fine, but I'm not sure it actually provides any benefits (other than unix socket support) over this patch. Am I mistaken?

Here is an example video: gsc.io/machine-0.flv

If it isn't enabled by default (it isn't AFAIK), the only overhead is this couple of additional packages into (test-time) closure. I'd think we can take this approach and leave improvements (QXL?) to later.

I'm actually not sure about recording the keymap tests by default. I assumed Aszlig already had understood the problem there well enough.

Closing in favor of that one ^