[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.