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

[Anthony Liguori]

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