Re: [Xen-devel] different QEMU

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-01-16 at 06:33 +0400, Igor Kozhukhov wrote:
> could you please let me know - why we have different QEMU for xen builds ?
> i see :
> qemu-xen-dir-remote - git://xenbits.xen.org/qemu-upstream-4.2-testing.git
> qemu-xen-traditional-dir-remote - 
> git://xenbits.xen.org/qemu-xen-4.2-testing.git
> 
> can we use ONE ?
> or we need different binaries ?

qemu-xen-traditional is the old Xen fork of Qemu. It was the only qemu
for a long time, and was the default until 4.3 (I think).

Obviously the fork was a bad thing so from 4.2 we have also had the
"qemu-xen" version of qemu which is the upstream qemu with Xen support.
This was "tech preview" in 4.2 and become the default (in most cases) in
4.3. (the exception is stubdomains which currently only work for
traditional). It is also intended that distros can just use their
existing qemu packaging instead of packaging a special Xen version of
qemu (they like this from a security support PoV etc).

The reason why the traditional fork lives on despite the default having
been changed is that VMs which were installed on that platform may not
take kindly to being switched to the newer one (in particular Windows
VMs might require reactivation). So the upstream project intends to keep
this code base alive, in a heavily frozen/maintenance state for the
foreseeable future.

New VM deployments from 4.3 onwards should use the qemu-xen fork where
possible.

Your use of 4.2 makes it hard for me to make a recommendation to you,
since qemu-xen in 4.2 was tech preview and was missing some features,
but it is the future, while 4.2 still used the old frozen qemu as its
default.

My recommendation would be to be more concerned about pulling forward to
a newer Xen (like 4.3 or even 4.4-rc) and on getting your Xen patches
upstream before worrying about Qemu too much, and then having done that
to focus mainly on upstream qemu-xen.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel