Re: [Xen-devel] [PATCH v2] implement libvirt-like 'channels' via PV consoles

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Mon, Jun 16, 2014 at 01:49:36PM +0000, Dave Scott wrote:
> Hi Konrad,
> 
> On 16 Jun 2014, at 14:34, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
> wrote:
> 
> > On Mon, Jun 16, 2014 at 10:49:49AM +0100, David Scott wrote:
> >> Several libvirt applications (e.g. oVirt, CloudStack) make use of 
> >> 'channels':
> >> low-bandwidth private host <-> guest communication links which resemble 
> >> serial
> >> ports. Typical uses include:
> >> 
> >>  * initial VM configuration without using the network: read the config data
> >>    directly from the channel on boot
> >> 
> >>  * controlling a guest agent: signal shutdown reqests, exchange clipboard 
> >> data,
> >>    trigger resolution changes
> >> 
> >> This patch set re-uses the existing PV console protocol implemented by qemu
> >> to provide this service.
> >> 
> >> If you declare a channel in your .xl file as follows:
> >> 
> >>  channel = [ "type=socket,path=/tmp/mysock,name=guest-agent" ]
> >> 
> >> then an extra PV console will be added to your guest. This console has the
> >> extra key in the frontend
> >> 
> >>  name = guest-agent
> >> 
> >> which allows udev scripts in the VM to create a named device in a 
> >> well-known
> >> location (e.g. /dev/xen-channels/guest-agent, similar to the KVM 
> >> /dev/vports).
> > 
> > Are these udev scripts somewhere implemented?
> 
> Iâve been playing with these ones:
> 
> https://github.com/djs55/mirage-console/tree/master/udev
> 
> (ignore the reference to Mirage â you just need the .rules file and the 
> helper script)
> 
> Do you think an example udev script like this should live in the tree?

I think it would be fantastic if it was in the docs/ that is part of
this patchset.
> 
> > 
> > Thanks!
> 
> Cheers,
> Dave
> 
> > 
> >> The qemu process in the backend domain will proxy the data to/from the 
> >> named
> >> Unix domain socket (in this case /tmp/mysock).
> >> 
> >> Note this mechanism is intended for low-bandwidth communication only. If an
> >> application requires a high-bandwith connection then it should use a direct
> >> vchan connection (and not proxy it via a qemu).
> >> 
> >> Changes since v1:
> >> 
> >>  * extend xl.cfg(5)
> >>  * add docs/misc/channel.txt
> >>  * libxl_types.idl: omit unnecessary init_val = 0
> >>  * xl_cmdimpl.c: fixed over-long lines
> >>  * xl_cmdimpl.c: use xrealloc (via ARRAY_EXTEND_INIT)
> >>  * xl_cmdimpl.c: exit() on parse failure rather than ignore configuration
> >>  * libxl_create.c: use libxl__device_console_init instead of memset
> >>  * libxl_create.c: use libxl__strdup(NOGC rather than raw strdup
> >>  * libxl.c: add name=<name> to console frontend
> >>  * libxl.c: resolve the backend_domid from backend_domname
> >>  * libxl_dm.c: channels[i].devid rather than i
> >>  * libxl_dm.c: fix indentation
> >>  * libxl_dm.c: use GCSPRINTF convenience macro
> >> 
> >> Signed-off-by: David Scott <dave.scott@xxxxxxxxxx>
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> Xen-devel mailing list
> >> Xen-devel@xxxxxxxxxxxxx
> >> http://lists.xen.org/xen-devel
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel