From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSZY4-00086O-75 for qemu-devel@nongnu.org; Wed, 06 Jan 2010 12:19:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSZXz-00085V-JB for qemu-devel@nongnu.org; Wed, 06 Jan 2010 12:19:55 -0500 Received: from [199.232.76.173] (port=50553 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSZXz-00085N-9v for qemu-devel@nongnu.org; Wed, 06 Jan 2010 12:19:51 -0500 Received: from mail2.shareable.org ([80.68.89.115]:54743) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSZXy-0000gI-SP for qemu-devel@nongnu.org; Wed, 06 Jan 2010 12:19:51 -0500 Date: Wed, 6 Jan 2010 17:19:45 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: Planning for 0.13 Message-ID: <20100106171945.GB11773@shareable.org> References: <4B43DA17.8080001@codemonkey.ws> <20100106104903.GA2248@redhat.com> <4B4483CA.2030101@linux.vnet.ibm.com> <20100106132043.GC2248@redhat.com> <4B449162.9040107@linux.vnet.ibm.com> <20100106135527.GE2248@redhat.com> <4B44A7E6.5030300@linux.vnet.ibm.com> <20100106151658.GB4001@redhat.com> <4B44AB3D.4010209@linux.vnet.ibm.com> <20100106154134.GC4001@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100106154134.GC4001@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Anthony Liguori , qemu-devel@nongnu.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