Re: [Qemu-devel] Re: Planning for 0.13

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jan 06, 2010 at 05:19:45PM +0000, Jamie Lokier wrote:
> Michael S. Tsirkin wrote:
> > On Wed, Jan 06, 2010 at 09:24:45AM -0600, Anthony Liguori wrote:
> > > A helper is semantics equivalent to passing an fd from a management  
> > > tool.  All of the problems you describe are equally applicable to that  
> > > model.
> > 
> > No, because management calls qemu and parses qemu help output.  Yes it
> > is not ideal but it works today.
> 
> I don't understand.  What do you think would not work with
> helper="..."  where ... is specified on the qemu command line by the
> management script, versus the management script doing the helper
> operations itself first and then calling qemu with fd=?
> 
> If you are thinking that management scripts will tailor the -net
> arguments according to qemu version, you're right for some
> configurations (but not well established simple ones).
> 
> Presumably management can do the same capability when specifying "..."
> - the difference being it would query the helper tool to get _it's_
> features in some cases, e.g. for arguments to a helper which uses SSH
> to provide an encrypted tunnel.

What won't work is that besides fd= management specifies many other
arguments to the -net flag.

> > > The question is, should we take in code in qemu to support any possible  
> > > mechanism of creation of networking or should we just make sure their  
> > > all possible by passing in an appropriate fd.
> > 
> > We already do this. What will not work generally is *returning* fd from
> > helper. And IMO we are better off not pretending it's possible.
> 
> What about it will not work?  Even on Windows, I don't see why -net
> this,that,other,helper="..." cannot be a direct equivalent for -net
> this,that,other,fd=N, for any combination of this,that,other options -
> with the added bonus that the helper would be allowed to provide
> additional options to QEMU if wanted.
> 
> > > Having helpers does not mean that we would have no backends built into  
> > > qemu.  It just means that's it's possible to create backends outside of  
> > > qemu.
> > > 
> > > Of course, we need to evalute whether a new backend should be in qemu or  
> > > outside of qemu but that's something to handle on a case-by-case basis.
> > >
> > > Regards,
> > >
> > > Anthony Liguori
> > 
> > To the point, I think we are better off with packet socket (vepa)
> > backend in qemu than as a helper script.
> 
> That one, yes, but with the helper= option being more or less
> equivalent to fd= with the added ability to tell qemu how it wants
> qemu to talk to the fd, it's a bit easier to have user-supplied
> helpers such as:
> 
>     - Build an encrypted tunnel with SSH
>     - Log all packets
>     - Fake packets with a Perl script for repeatable tests
>     - Send packets through a network simulator
>     - Site-specific bridge + iptables setup
> 
> You don't want code for those sort of things in qemu itself.
> 
> Same, really, could be imagined with -monitor, -serial etc. -
> providing a generic "helper" backend in the same way we support
> connecting to serial ports, telnet sockets etc.
> 
> Btw, as of right now, I have not found a management tool which sets up
> bridges correctly for my sites...  There is always something extra
> needed with iptables, so it has to be done with hand-holding, or with
> the script= and downscript= options - which are annoyingly fragile
> because downscript isn't run if qemu has to be killed.
> 
> A helper which communicates its result back to qemu, and then *keeps
> the unix socket open* would be a nice way to reliably detect when the
> helper should destroy whatever it created - more reliable than downscript=.
> 
> I agree many backends are better implemented in qemu proper, but
> Anthony's idea sounds simple and versatile to me, and I would
> certainly use it for site-specific things.
> 
> -- Jamie

What you describe: helper= instead of fd= will work and I have no issue
with this. And we won't need any protocol between helper and qemu: just
the fd returned.  But of course this means that it can't be used to
create new backends such as vepa, which often need to setup the fd
in complex ways.

-- 
MST