Re: [Qemu-devel] [PATCH 0/6] RFC: add "spiceport" chardev

[Marc-André Lureau]

Hi

On Fri, Nov 30, 2012 at 2:58 PM, Gerd Hoffmann <address@hidden> wrote:

Also nice to have:

   org.qemu.console.serial.0

... and spice client redirecting that to a vte.  You might have to add
some termios control messages to spiceport, so one can turn on/off echo,
send breaks, xon/xoff flow control, etc to make it work really nicely.

I haven't played with a console yet, but this is indeed an important use case.

> Or to allow arbitrary communication outside of qemu:
>
> ... -chardev spiceport,name=org.ovirt.controller,id=...,chardev=ovcsocket
>     -chardev socket,server,host=0.0.0.0,port=4242,id=ovcsocket,nowait

Hmm, so that will make qemu just hook those chardevs back-to-back and
forward data without looking at it?  I'm not sure we want that ...

 

What is the use case?  Any reason why the spice client can not (or
should not) speak to ovirt directly?

Ah, in fact, it's the main reason why I worked on this. Currently, the Spice client has to communicate with ovirt via the browser, which is a pain to deal with: it's a completely different route, it needs a running browser, a compatible extension (xpi vs activex vs the rest not supported), leading to duplicated work, license problems, regular breakage between browser versions, hard to test, difficult to upgrade... Instead, we are investigating the use of a configuration file provided by ovirt portal for setting up the client, and the dynamic interaction could take place either via the propose Spice port, or directly via ovirt.

Some of the dynamic ovirt functionality are interesting for direct clients, like the "spice controller menu" (a customizable client UI menu, virt-viewer and Boxes could benefit it). It may not be the best solution to route the "ovirt/spice controller" through qemu host, but at least I wanted to try that option. It could be that in the end, it is prefered that the client just talk directly to ovirt, whatever fits best.

--
Marc-André Lureau