[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH for-4.5 v5] add support for libvirt-like channels
Hi, I've incorporated IanC's feedback from the v4. IanJ: I've tried to incorporate your feedback from the earlier v3 -- let me know what you think. The blurb: 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 = [ "connection=socket,path=/tmp/mysock,name=org.mydomain.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 v4: * doc: highlight that the 'output' key in the console configuration should be considered an internal implementation artifact * return EINVAL if a primary console has invalid configuration * Use LOG(ERROR,... rather than LIBXL__LOG(CTX, LIBXL__LOG_ERROR * Use an abort() when implementation code is missing * move READ_BACKEND to the top of the file (since it's generally useful) * Remove stray tab Changes since v3: * docs: coalesce the docs patch into the libxl patch * docs: in channels.txt give high-level usage information, pitfalls and channgle registry * docs: move the xenstore paths into the existing console.txt, which is referenced from xenstore-paths.markdown * idl: rename 'kind' to 'connection' * xl: add parser functions for comma-separated lists of pairs Changes since v2: * trim down the 'kinds' of channels to PTY and SOCKET -- these seem the most useful and we can add more later * add a channelinfo (queryable by 'channel-list') to check the state of each channel, and for a kind=PTY discover the slave device path * IDL: switched to KeyedUnion for both the channel and channelinfo since each 'kind' will have different parameters (e.g. only SOCKET has PATH) * write all the backend configuration parameters to xenstore -- where we were using qemu -chardev some crucial information was only on the command-line. * add LIBXL_HAVE_DEVICE_CHANNEL * docs: replace 'should' with 'will' e.g. the backend will be connected to a Unix domain socket * squash all the libxl patches together into a coherent whole * explain that there is no registry of channel names and so people should use unique information to create them (e.g. include domain name and interface version) 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |