7:25 a.m.
On Tue, Feb 04, 2014 at 01:34:38PM +0100, Christophe Fergeau wrote:
Hey,
Not a full review yet as I have only been looking at the doc so far.
On Mon, Feb 03, 2014 at 05:41:00PM +0100, Martin Kletzander wrote:
> Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com>
> ---
>
> Notes:
> This applies on top of "qemu: minor cleanups":
>
> https://www.redhat.com/archives/libvir-list/2014-January/msg01584.html
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index fd02864..20ee61e 100644
> --- a/docs/formatdomain.html.in
> +++ b/docs/formatdomain.html.in
> @@ -4252,6 +4252,10 @@ qemu-kvm -net nic,model=? /dev/null
> <source path='/dev/pts/3'/>
> <target port='0'/>
> </serial>
> + <serial type='spiceport'>
> + <source channel='org.qemu.console.serial.0'/>
> + <target port='0'/>
> + </serial>
> <console type='pty'>
> <source path='/dev/pts/4'/>
> <target port='0'/>
> @@ -4711,6 +4715,24 @@ qemu-kvm -net nic,model=? /dev/null
> <pre>
> ...
> <devices>
> + <serial type="spiceport">
> + <source channel="org.qemu.console.serial.0"/>
> + <target port="1"/>
> + </serial>
> + </devices>
> + ...</pre>
> +
> + <h6><a name="elementsCharSpiceport">Spice
channel</a></h6>
> +
> + <p>
> + The character device is accessible through spice connection
> + under a channel name specified in the <code>channel</code>
> + attribute. <span class="since">Since 1.2.2</span>
> + </p>
> +
> +<pre>
> + ...
> + <devices>
> <serial type="unix">
> <source mode="bind" path="/tmp/foo"/>
> <target port="1"/>
This bit is wrong as the doc ends up as
* UNIX domain socket client/server
description
spiceport sample XML
* Spice channel
description
unix domain socket sample XML
Yes, my fault, I copy-pasted the previous target type and then changed
the wrong one.
Regarding the way it's exposed, you have chosen to go with
<devices>
<serial type="spiceport">
<source channel="org.qemu.console.serial.0"/>
<target port="1"/>
</serial>
</devices>
This exposes the 'org.qemu.console.serial.0' spiceport as a serial port in
the guest. This spiceport can then be used by client applications to
interact with the guest.
This is very similar to what is done for the spice agent channel (a virtio serial
port is made available in the guest and is used for client<->guest
communication). Wouldn't it be more consistent to use
<channel type="spiceport">
<target type="virtio" name="org.qemu.console.serial.0"/>
</channel>
here?
When I gave some thoughts about how to expose spiceport in libvirt, I got
confused as in addition to this guest<->spice client channel, spiceport is
much more generic and can also be used to create some host<->spice client
channels (eg forward a local host socket/... over to the client through
spice).
If we use <channel>, maybe this can be added later with
<channel type="spiceport">
<target type="host" name="org.qemu.console.serial.0"/>
<source ... />
</channel> ? (thinking out loud, and something which can be added when
there is need for it)
Christophe
The thing is that when you use spicevmc, the channel going through the
guest (target -- frontend in the guest) is identified using the virtio
channel name because it is virtio-serial-port. That's what you see in
the XML. For the source (backend on host) there are only three
spicevmc channel names to use: vdagent, smartcard and usbredir. We
don't offer to choose that names since there is only one possible
usage for each of those.
OTOH with spiceport, you can choose the channel name yourself, have
them as many as you want and since it provides _backend_ connection
(source for the chardev), it is identified by this name in the
_client_.
From the technical POV, you can interconnect spiceport as a source
with any other target that qemu supports. But that doesn't change the
fact that spiceport is only used as a backend and is not seen in the
guest.
In the example I went with using isa-serial as a target, because that
was the usage mentioned in the mail thanks to which I started working
on it [1], but I to meet your needs you can go with:
<channel type="spiceport">
<source channel="org.qemu.console.serial.0"/>
<target type="virtio" name="whatever-name.you.want"/>
</channel>
which works with this patch too as it merely adds the backend to the
mix. In this case it won't be serial port, but virtio-port (channel);
that means you'll see '/dev/virtio-ports/whatever-name.you.want' in
the guest instead of '/dev/ttyS0'.
Martin
P.S.: Due to spicevmc channel being implemented the way it is, it
took me non-trivial amount of time to figure out how to expose this
and I went through more "designs" before I figured this is just a
backend, nothing else :)
[1] http://lists.freedesktop.org/archives/spice-devel/2014-January/015919.html