best way to reach QEMU VM desktop on headless GuixSD server

best way to reach QEMU VM desktop on headless GuixSD server

[George myglc2 Clemmer]

It appears that there are 3 ways to reach a QEMU VM desktop on headless
GuixSD servers: X11, spice, and maybe VNC. Is that right?

Can anyone comment on which has the best performance.

My situation: MacOS <-- 1000BaseT --> GuixSD/servers

TIA - George

Re: best way to reach QEMU VM desktop on headless GuixSD server

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

George myglc2 Clemmer <myglc2@gmail.com> writes:

> It appears that there are 3 ways to reach a QEMU VM desktop on headless
> GuixSD servers: X11, spice, and maybe VNC. Is that right?
>
> Can anyone comment on which has the best performance.
>
> My situation: MacOS <-- 1000BaseT --> GuixSD/servers
>
> TIA - George

I've tried X11 and VNC.  X11 is easier to use and maintain if you
already have SSH access, but I prefer VNC if it's available.

X11 over a remote (e.g., VPN over the Internet) connection is usually no
fun at all.  However, if you have a local 1G link to the servers, then
the X11 performance might be tolerable, in which case the simplicity of
X11 might beat VNC's performance.

FWIW, QEMU comes with a built-in VNC server feature, which makes it even
easier to use VNC in this use case.  See for example:

https://qemu.weilnetz.de/doc/qemu-doc.html#vnc_005fsecurity

For a VNC client, in Guix we have Vinagre, which works fine for me.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: best way to reach QEMU VM desktop on headless GuixSD server

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

George myglc2 Clemmer <myglc2@gmail.com> writes:

> It appears that there are 3 ways to reach a QEMU VM desktop on headless
> GuixSD servers: X11, spice, and maybe VNC. Is that right?
>
> Can anyone comment on which has the best performance.

Spice was designed to be a better protocol than VNC for accessing
virtual machine consoles.  I haven't done any benchmarks though.

It requires a rather involved QEMU command line[0]:

 [qemu] -spice addr=127.0.0.1,port=3001,disable-ticketing -soundhw hda \
        -device virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent \
        -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \

Then you can use virt-viewer or "spicy" from spice-gtk along with SSH
forwarding to access 127.0.0.1:3001 on the remote machine.  Setting up
encryption or authentication requires a few more arguments if you want
to expose this on a network-facing interface directly.

[0] https://www.spice-space.org/spice-user-manual.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: best way to reach QEMU VM desktop on headless GuixSD server

[myglc2]

Hi Marius,

On 01/27/2018 at 17:03 Marius Bakke writes:

> George myglc2 Clemmer <myglc2@gmail.com> writes:
>
>> It appears that there are 3 ways to reach a QEMU VM desktop on headless
>> GuixSD servers: X11, spice, and maybe VNC. Is that right?
>>
>> Can anyone comment on which has the best performance.
>
> Spice was designed to be a better protocol than VNC for accessing
> virtual machine consoles.  I haven't done any benchmarks though.
>
> It requires a rather involved QEMU command line[0]:
>
>  [qemu] -spice addr=127.0.0.1,port=3001,disable-ticketing -soundhw hda \
>         -device virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent \
>         -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
>
> Then you can use virt-viewer or "spicy" from spice-gtk along with SSH
> forwarding to access 127.0.0.1:3001 on the remote machine.  Setting up
> encryption or authentication requires a few more arguments if you want
> to expose this on a network-facing interface directly.
>
> [0] https://www.spice-space.org/spice-user-manual.html

Many thanks for this ... dropped your lines into my qemu call and it
worked right out of the box \\WOW// ... once I realized the virt-viewer
client is actually called remote-viewer ;-) - George