On 09/16/2016 05:43 PM, Joao Martins wrote:
> Hey,
> Channels have been on xen toolstack since Xen 4.5 and this small series
> adds support for it, including xenconfig conversion and appropriate tests.

Cool! Thanks.

> After this series it's possible to do this:
> (assuming correct configuration of qemu agent in the guest)
>  $ cat domain.xml | grep -a1 channel | head -n 5 | tail -n 4
>  <channel type='unix'>
>    <source mode='bind' path='/tmp/channel'/>
>    <target type='xen' name='org.qemu.guest_agent.0'/>
>  </channel>
>  $ virsh create domain.xml
>  $ echo '{"execute":"guest-network-get-interfaces"}' | socat
>  stdio,ignoreeof  unix-connect:/tmp/channel
>  {"execute":"guest-network-get-interfaces"}
>  {"return": [{"name": "lo", "ip-addresses": [{"ip-address-type": "ipv4",
>  "ip-address": "", "prefix": 8}, {"ip-address-type": "ipv6",
>  "ip-address": "::1", "prefix": 128}], "hardware-address":
>  "00:00:00:00:00:00"}, {"name": "eth0", "ip-addresses":
>  [{"ip-address-type": "ipv4", "ip-address": "", "prefix": 24},
>  {"ip-address-type": "ipv6", "ip-address": "fe80::216:3eff:fe40:88eb",
>  "prefix": 64}], "hardware-address": "00:16:3e:40:88:eb"}, {"name":
>  "sit0"}]}
> There is just one thing unclear: is source "path" meant to be auto-generated
> if it's not specified in the channel config?

I think so. According to docs/formatdomain.html

Moreover, since 1.0.6 it is possible to have source path auto generated for
virtio unix channels. This is very useful in case of a qemu guest agent, where
users don't usually care about the source path since it's libvirt who talks to
the guest agent. In case users want to utilize this feature, they should leave
<source> element out.

>  Additionally what does "state"
> signify for virtio case: is it that the guest agent is connected, or that the
> virtio serial is connected? Looking at the qemu driver on
> processSerialChangedEvent it sounds to me like it's about the serial state.

AFAICT you are right, but perhaps Michal is kind enough to confirm. I think he
is familiar with this code.

> I also have one other series that lets us share the qemu agent across both 
> qemu
> and libxl drivers, with qemu-agent-command implemented. But it's still in an
> early stage.
> Any comments or feedback is appreciated :)

Thanks again. I'll start reviewing the individual patches.


libvir-list mailing list

Reply via email to