Re: [Xen-devel] different QEMU

[Igor Kozhukhov <ikozhukhov@xxxxxxxxx>]

Hi Ian,

On Jan 16, 2014, at 1:56 PM, Ian Campbell wrote:

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

Thanks for your details about QEMU.
i have additional patches/changes for using vdiskadm.
it is tools for using different images as storage for VMs.
i'll take a look a port to xen-4.3 instead of xen-4.2.

at this moment i have fixed/updated changes on illumos(kernel side) and need to 
work on xen side with sources - take a look and try to apply patches from 
xen-3.4.x.

i'll try to send to upstream my changes to Xen sources with changes.
also i have updated libfsimage with ZFS from illumos and will be ready for up 
merge to xen-unstable.

-Igor

> 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