[Qemu-devel] Merging improvements from VirtualBox OSE into qemu?

[Liraz Siri <liraz@turnkeylinux.org>]

Hi,

I'm new to the list so let me introduce myself. I am one of the
developers for TurnKey Linux, a new opensource project that develops a
family of lightweight installable live CDs optimized for various
server-type tasks including LAMP, Ruby on Rails, Django, Joomla, Drupal,
MediaWiki, and others: http://www.turnkeylinux.org/

This type of pre-integrated, ready-to-use system is typically called a
software appliance: http://en.wikipedia.org/wiki/Software_appliance

We use qemu heavily in our development/testing. We find it's better
suited as a scriptable primitive than other opensource alternative such
as VirtualBox. Thankfully the KVM fork has gotten rid of the performance
disadvantage qemu used to suffer from.

Anyhow, I've recently explored the latest release of VirtualBox (which I
understand is based on qemu).

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 works without root privileges somehow, probably by taking
   advantage of new infrastructure in the VirtualBox device driver.

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

These are dramatic improvements in usability and I'm curious whether it
is likely that these changes will find there way to qemu? I know that
both projects are under the same opensource license and share quite a
bit of code 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