2010/8/23 Daniel P. Berrange <berrange@xxxxxxxxxx>: > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list