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

[Liraz Siri]

Anthony Liguori wrote:

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

For my purposes, the libvirt stuff just gets in the way, but last time I
tried the libvirt based front-end tools were a mess. I didn't try the
latest upstream versions though, just the packages in my distribution's
repository (8.04).

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

For a 32bit host and a 32bit guest Qemu/KVM performs better than
VirtualBox, at least in my testing. It wasn't a dramatic difference though.

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

Supporting that configuration is mostly useful in aiding gradual
transitions from 32bit to 64bit. Due to dependency chains most users are
still running 32bit hosts right now. I'm not sure it has any long-term
usefulness.

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

That's really too bad. I guess at some level their xVM platform is in
competition with qemu/KVM/libvirt so maybe their interests don't align
with the greater good here.

Cheers,
Liraz