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

Re: [Libguestfs] One possible plan for remote support

On Mon, Nov 12, 2012 at 05:02:08PM -0500, John Eckersberg wrote:
> "Richard W.M. Jones" <rjones 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).

I'm pretty sure a pty is never going to work.  We need an 8-bit clean
channel, and conversely don't need any features of a pty.


Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

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