[Xen-devel] PATCH RFC: possible implementation of a low-bandwidth private 'channel'

[David Scott <dave.scott@xxxxxxxxxx>]

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).
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).

Signed-off-by: David Scott <dave.scott@xxxxxxxxxx>


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