Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1)

[Daniel P. Berrange]

On Wed, Jul 01, 2009 at 02:11:23PM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Wed, Jul 01, 2009 at 01:47:12PM -0500, Anthony Liguori wrote:
> >  
> >>Daniel P. Berrange wrote:
> >>    
> >>>On Wed, Jul 01, 2009 at 01:36:23PM -0500, Anthony Liguori wrote:
> >>> 
> >>>      
> >>>>Daniel P. Berrange wrote:
> >>>>   
> >>>>        
> >>>>>The following two patches make it possible to tunnel character devices
> >>>>>over VNC, using a new VNC extension. This is motivated by the existing
> >>>>>QEMU support for tunnelling audio streams over VNC, and the code 
> >>>>>follows
> >>>>>a very similar design.  The key requirement here is that it should not
> >>>>>be neccessary to specifically configure each character device to make
> >>>>>it available via VNC. The admin should be able to configure the char
> >>>>>devices with all current available backends (file, pty, null, tcp, udp,
> >>>>>unix, etc), and regardless of this config be able to snoop on data from
> >>>>>any active VNC client on demand.
> >>>>>
> >>>>>     
> >>>>>          
> >>>>Shouldn't it just be the character devices put on vc's?
> >>>>   
> >>>>        
> >>>The 'vc' concept is a stateful one, requiring the user to switch betweeen
> >>>channels statically and is opaque to VNC clients - all they see is a
> >>>framebuffer with no idea that QEMU has this magic sequence to change
> >>>what the framebuffer displays, nor what vc's are available.
> >>>      
> >>I understand what you're suggesting, but I think the right way to handle 
> >>this use-case is to allow character devices to be redirected after 
> >>initial open making them truly dynamic.
> >>    
> >
> >The 'vc' reference was puzzelling to me there, but I think you're
> >basically suggesting the same thing as Gerd is ? To fully de-couple
> >the device specification vs backend configuration
> >  
> 
> Well, I'm saying, a character device should be exposed via VNC IIF it's 
> connected to a 'vc' backend device.  In order to satisfy your use-case, 
> I'd also suggest decoupling the monitor front-end's from back-ends so 
> that you can reconnect a character device to a 'vc' if you want to.

Ah, now I see what you mean :-) FYI, the two main deployment scenarios 
I am thinking of are

 - Serial port connected to a /dev/pts in host (eg, so host admin can
   locally run minicom / virsh console to interact with guest,
   eg QEMU is launched with -serial pty

 - Serial port connected to a file to log all data that is transmitted
   eg QEMU is launched with -serial file:/var/log/qemu/foo.log

Dynamically, rebinding backend to the 'vc' in order to access it from
a VNC client would certainly be doable in the first scenario, as there
is no benefit in keeping it accessible via the pty, while its used over 
VNC.

I'm not sure if dynamically re-binding is sufficiently flexible for the
second case, since you'd get an interruption in data logging to the file.
Similarly if using the 'udp' char driver to log to a netconsole server.
Perhaps we could just live with that restriction for the short term
though, and worry about full concurrent usage at a later date.

> The easiest way (albeit a little ugly) to do this would be to create a 
> pluggable character device that proxied to another character device.  
> Change qemu_chr_open() to return qemu_chr_open_proxy(chr, label).
> 
> You can then enumerate proxies by label and retarget the proxy to a 
> different device.

That sounds doable to me - I'll have a go at changing it to work that
way.


Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|