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

[Jamie Lokier <jamie@shareable.org>]

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.

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