From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LFVZv-0002Qf-FK for qemu-devel@nongnu.org; Wed, 24 Dec 2008 10:23:19 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LFVZu-0002Ph-Es for qemu-devel@nongnu.org; Wed, 24 Dec 2008 10:23:19 -0500 Received: from [199.232.76.173] (port=35066 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LFVZu-0002PW-9d for qemu-devel@nongnu.org; Wed, 24 Dec 2008 10:23:18 -0500 Received: from yw-out-1718.google.com ([74.125.46.158]:44349) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LFVZt-0005to-Vu for qemu-devel@nongnu.org; Wed, 24 Dec 2008 10:23:18 -0500 Received: by yw-out-1718.google.com with SMTP id 6so1273579ywa.82 for ; Wed, 24 Dec 2008 07:23:16 -0800 (PST) Message-ID: <495253E1.3090209@codemonkey.ws> Date: Wed, 24 Dec 2008 09:23:13 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Merging improvements from VirtualBox OSE into qemu? References: <49522F8D.4000203@turnkeylinux.org> In-Reply-To: <49522F8D.4000203@turnkeylinux.org> Content-Type: text/plain; charset=UTF-8; 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 Cc: turnkey-discuss@lists.turnkeylinux.org Liraz Siri wrote: > Hi, > > Two major changes in version 2.1 caught my attention: > > 1) complex setup is no longer required for "bridged" networking: > > This is a big win for us as the former networking setup complexity > indirectly made TurnKey appliances much more difficult for regular > users to set up. > > VirtualBox came to its senses and realized the tap configuration mess > was way too complex for most users and cumbersome even for advanced > users. Also, I don't think it worked with wireless NICs. > > In the latest release, "host interface networking" just works. The > user simply selects which NIC to connect the guest to (e.g., eth0) > and they're done. > > Behinds the scenes VirtualBox is putting your NIC into promisc mode to > sniff packets to guests and injecting packets directly to the NIC. > Essentially it creates a virtual NIC in software. > This is not how it works. They have their own special tap kernel module. > This works without root privileges somehow, probably by taking > advantage of new infrastructure in the VirtualBox device driver. > Because they load a new kernel module and the set the perms of it's device to be open to any user. This would never be allowed in upstream Linux though. Putting arbitrary packets on the physical network is considered a superuser operation. Since you have to be root to bind() to a port < 1024, raw traffic obviously allows you to do this. FWIW, if you use virt-manager, then setting up networking is a breeze. The reason you think networking is hard in QEMU is that you are interacting with it at the wrong level. > 2) improved support for running 64bit guests on 32bit hosts > > On my Intel Core 2.4 rig I booted the Debian Lenny live CD in 48 > seconds. > > By contrast, I booted the same CD under qemu-system-x86_64 in > 257 seconds, or 5 times slower... > Well you're comparing virtualization to emulation. A better comparison would be a 32-bit vs 32-bit VM using -enable-kvm. I'm sure QEMU will hold it's own or even do better. Historically, VirtualBox has not performed competitively against other VMMs. KVM doesn't support running 64-bit guests on 32-bit hosts. If someone was sufficiently motivated, they could write patches to KVM and they could possibly be accepted. VirtualBox is of no help here. I think the value of running 64-bit guests on a 32-bit host is marginal, at best. I don't see a lot of eagerness among developers to support this configuration. > These are dramatic improvements in usability and I'm curious whether it > is likely that these changes will find there way to qemu? Only if Sun decides to start contributing those changes back to QEMU. You'll have to talk to the VirtualBox developers to see what their plans are with that. > I know that > both projects are under the same opensource license and share quite a > bit of code Sharing implies a two-way exchange. In reality, VirtualBox has taken a bunch of QEMU code and AFAIK has not shared any of their changes back with the QEMU community. They are completely entitled to do this of course based on the licensing of QEMU. Some of their most interesting changes (like SATA emulation, rewritten USB emulation) remain available only in their closed source version. I find that extremely unfortunate because that would be some of the easiest and most useful code to try to merge from their project. Regards, Anthony Liguori > but I don't really know too much about the internals of both > projects so I'm not sure how difficult this would be to accomplish > technically... > > Cheers, > Liraz > > >