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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list