From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH v2] implement libvirt-like 'channels' via PV
 consoles
Date: Mon, 16 Jun 2014 09:34:07 -0400
Message-ID: <20140616133407.GA8696@laptop.dumpdata.com>
References: <1402912195-24732-1-git-send-email-dave.scott@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta4.messagelabs.com ([85.158.143.247])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <konrad.wilk@oracle.com>) id 1WwX3B-0001bB-9P
	for xen-devel@lists.xenproject.org; Mon, 16 Jun 2014 13:34:17 +0000
Content-Disposition: inline
In-Reply-To: <1402912195-24732-1-git-send-email-dave.scott@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: David Scott <dave.scott@citrix.com>
Cc: xen-devel@lists.xenproject.org, stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com, wei.liu2@citrix.com, ian.campbell@citrix.com
List-Id: xen-devel@lists.xenproject.org

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?

Thanks!

> 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@citrix.com>
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel