From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ELnuw-0007cF-L4 for qemu-devel@nongnu.org; Sat, 01 Oct 2005 16:25:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ELnun-0007ZH-9Z for qemu-devel@nongnu.org; Sat, 01 Oct 2005 16:25:01 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ELnum-0007Z7-VP for qemu-devel@nongnu.org; Sat, 01 Oct 2005 16:25:00 -0400 Received: from [144.85.15.72] (helo=mail.eclis.ch) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ELntt-0000vK-Sz for qemu-devel@nongnu.org; Sat, 01 Oct 2005 16:24:06 -0400 Message-ID: <433EF063.3080101@eclis.ch> Date: Sat, 01 Oct 2005 22:24:03 +0200 From: Jean-Christian de Rivaz MIME-Version: 1.0 Subject: Re: [Qemu-devel] tun/tap networking References: <20050930221321.C7BED31C14@ravel.n2.net> <20050930230149.GA20433@jbrown.mylinuxbox.org> <433E44F9.8040501@eclis.ch> <20051001131215.GB28444@jbrown.mylinuxbox.org> In-Reply-To: <20051001131215.GB28444@jbrown.mylinuxbox.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org >>You point the real question: why it has been impossible to get accepted >>any patch that fixed this. I has proposed one myself and I get no >>comment at all. I see similar effort from others and obviousely there >>failed almost the same way. No getting any valuable comment about why a >>idea proposed by many peopoles is not applyed make this subject very hard. >> > > > The change I was talking about is a one line patch... > > It's annoying that Fabrice has said nothing about it. But it doesn't actually > mess anything up, it's just confusing for advanced users. > > I presume that the device qemu makes is called tun0 because Fabrice wants to > make clear that he doesnt use (and wont support) the ethertap device. Not a > very good reason. > > (Or maybe he wants to keep it tun0 because if he changed the name he'd have > to change the option -tun-fd to -tap-fd and that'd break some scripts.) > > >>I hope that we can resolve this subject, because in my point of view, >>using a existing "tun" is far more simpler than create one the way quemu >>do; > > > I never mentioned that. At all. Agree. Sorry, I extented the subjet beyon the initial subjet of this thread. > And qemu already supports that, via the -tun-fd option. Can you please give me an exemple how to use the -tun-fd option to open an existing tun (i.e: tun-alice) ? This option only work for already opened tap/tun interface as I understand. > >>and this open a lot of new uses in terme of the network managment of >>the quemu instance. The very first one for me is to allow only root to >>setup a DHCP server and to assign "tuns" interfaces to the users that >>needs it, so there don't even have to think about the network setup, >>ther just boot into quemu an OS with a DHCP client. >> > > > That is a little tricky to do - but qemu can do it. The problem is exactly because this is tricky! Simply telling quemu to use a existing tun and boot a OS with a DHCP client is the simplest operation you can imagine to allow testing network experiment. Network setup is the job of root. Users just use the setup and that must be dead simple. Regards, -- Jean-Christian de Rivaz