[libvirt] [PATCH 6/7] Re-write virsh console to use streams

[Matthias Bolte]

2010/8/23 Daniel P. Berrange <berrange at redhat.com>:
> On Tue, Aug 17, 2010 at 06:02:45PM +0100, Daniel P. Berrange wrote:
>> This re-writes the 'virsh console' command so that it uses
>> the new streams API. This lets it run remotely and/or as a
>> non-root user. This requires that virsh be linked against
>> the simple event loop from libvirtd in daemon/event.c
>> As an added bonus, it can now connect to any console device,
>> not just the first one.
>>
>> * tools/Makefile.am: Link to event.c
>> * tools/console.c, tools/console.h: Rewrite to use the
>>   virDomainOpenConsole() APIs with streams
>> * tools/virsh.c: Support choosing the console name
>>   via --devname $NAME
>
> I've realized one problem with this patch. It breaks virsh console
> for Xen & LXC, since I've not added virDomainOpenConsole to those
> drivers yet.
>
> Supporting them is easy, but it would be a big cut+paste of the
> QEMU driver code, so I think I need to re-work this to pull out
> the QEMU stream code into a reusable module for other (local)
> drivers to share. ESX would of course need separate code, since
> that's a remote driver only.
>

ESX 4.0 and before can redirect a virtual serial device to file in the
datastore or to a physical serial device only. One could poll for this
file in the datastore via HTTPS, but that's quite ugly and I'm not
sure that it would work in a reasonable way. Also this would only
cover the read part, I'm not sure how to do writing that way.

ESX also allows to connect two guests via a virtual null modem cable,
but that would require a management guest per ESX server that runs a
proxy for the virtual serial devices of other guests.

Neither of this ideas sounds reasonable or even doable, so probably no
virDomainOpenConsole for ESX <= 4.0.

Since version 4.1 ESX can export a virtual serial device via Telnet,
Telnet+SSL, TCP and TCP+SSL. This will probably allow the ESX driver
to support virDomainOpenConsole for ESX >= 4.1.

I already tested this manually using an SSL enabled Telnet client for
the Telnet+SSL transport and gnutls-cli for the TCP+SSL transport and
it works.

Matthias