[libvirt] [PATCH 0/5] Add API to tunnel channels

[Daniel P. Berrange]

On Fri, Dec 14, 2012 at 12:05:31PM +0100, Michal Privoznik wrote:
> On 13.12.2012 17:24, John Eckersberg wrote:
> > This series enables the qemu driver to tunnel a virtio channel.  This
> > is useful for a remote session to communicate with a guest channel via
> > the streaming API.
> > 
> > This was originally fleshed out a while back in this thread:
> > https://www.redhat.com/archives/libvir-list/2011-September/msg01049.html
> > 
> > This implements only item (3) in that list.
> > 
> > The new API is nearly identical to the existing virDomainOpenConsole
> > API, except it works on channels, and supports UNIX sockets in
> > addition to PTYs for channel source type.
> > 
> > This is my first libvirt patch, please be gentle :)
> > 
> > John Eckersberg (5):
> >   api: Add API to tunnel a guest channel via stream
> >   conf: Rename virconsole.* to virchrdev.*
> >   conf: Rename console-specific identifiers to be more generic
> >   conf: Add unix socket support to virChrdevOpen
> >   qemu: Implement virDomainOpenChannel API
> > 
> >  configure.ac                 |  48 ++---
> >  include/libvirt/libvirt.h.in |  16 ++
> >  po/POTFILES.in               |   2 +-
> >  src/Makefile.am              |   8 +-
> >  src/conf/virchrdev.c         | 442 +++++++++++++++++++++++++++++++++++++++++++
> >  src/conf/virchrdev.h         |  37 ++++
> >  src/conf/virconsole.c        | 414 ----------------------------------------
> >  src/conf/virconsole.h        |  36 ----
> >  src/driver.h                 |   7 +
> >  src/libvirt.c                |  61 ++++++
> >  src/libvirt_private.syms     |   8 +-
> >  src/libvirt_public.syms      |   5 +
> >  src/qemu/qemu_domain.c       |   4 +-
> >  src/qemu/qemu_domain.h       |   4 +-
> >  src/qemu/qemu_driver.c       |  81 +++++++-
> >  src/remote/remote_driver.c   |   1 +
> >  src/remote/remote_protocol.x |   9 +-
> >  src/remote_protocol-structs  |   6 +
> >  18 files changed, 697 insertions(+), 492 deletions(-)
> >  create mode 100644 src/conf/virchrdev.c
> >  create mode 100644 src/conf/virchrdev.h
> >  delete mode 100644 src/conf/virconsole.c
> >  delete mode 100644 src/conf/virconsole.h
> > 
> 
> I am not hesitant to this approach. In fact, I think it can be combined
> with Peter's patch set for tunneling a TCP stream (which you omit in
> your patch set). Thus we will have an API which will be able to tunnel
> unix socket, PTY and TCP. Or do we want to keep these two split?

This API John is proposing mirrors the API used for virDomainOpenConsole.
I don't much like the general TCP tunnelling API because it is at
quite a low level. It is nicer to have the API directly associated
with the domain name + channel name, so we can provide access control
based on the domain / device. It also isolates the client from needing
to know what type of console is configiured.


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 :|