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

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

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