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
