[Libguestfs] One possible plan for remote support

[Daniel P. Berrange]

On Mon, Nov 12, 2012 at 05:02:08PM -0500, John Eckersberg wrote:
> "Richard W.M. Jones" <rjones at redhat.com> writes:
> > Problem (b) is really a shortcoming of libvirt.  If you define a
> > virtio-serial socket in libvirt
> > [http://libvirt.org/formatdomain.html#elementCharChannel] then it's a
> > bit stupid that these only work locally.  It should be possible (Dan
> > assures me "easy") to make these be forwarded over the libvirt secure
> > connection.
> 
> Focusing just on this bit for now.
> 
> Dan, do you have any thoughts on how to go about this?  I've been
> digging through the libvirt code trying to understand the pieces.  I see
> there's an existing virDomainOpenConsole API that knows (for the qemu
> driver) how to properly forward a console/serial/parallel device to a
> remote client, limited to ptys.  It looks like we could pretty easily
> make this work with channels + pty.  Also I see that presently
> libguestfs is using a unix socket and not pty.  I'm guessing this is for
> performace reasons, but I'm not familiar enough with the underlying
> performance of each to know for sure.  In any case, we'd also need to
> either (1) make guestfs use a pty source instead of a unix socket
> (easy), or (2) make virDomainOpenConsole work with unix sockets (not as
> easy).

IME, ptys are a total PITA to work with, and would go for unix sockets
every time. I don't think it would be very hard to make virDomainOpenConsole
work with UNIX sockets actually.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|