On Mon, Nov 12, 2012 at 05:02:08PM -0500, John Eckersberg wrote:
"Richard W.M. Jones" <rjones(a)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.
Rich.
--
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#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora