Re: [libvirt] [PATCH 6/7] Re-write virsh console to use streams
2010/8/23 Daniel P. Berrange <berrange(a)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