Re: [Xen-devel] [PATCH] libxl: prefer qdisk over blktap when choosing disk backend

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On 28/08/13 15:41, Wei Liu wrote:
> On Wed, Aug 28, 2013 at 02:35:56PM +0100, Wei Liu wrote:
>> On Wed, Aug 28, 2013 at 03:16:23PM +0200, Fabio Fantoni wrote:
>>> Il 28/08/2013 15:04, Ian Jackson ha scritto:
>>>> Fabio Fantoni writes ("Re: [Xen-devel] [PATCH] libxl: prefer qdisk over 
>>>> blktap when choosing disk backend"):
>>>>> I think is good prefer qdisk also for significant performance increase
>>>>> in comparison with blktap2.
>>>> Thanks, that's useful information.  That, and what George said, have
>>>> convinced me this is the right change.
>>>>
>>>> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>>>
>>> What about qemu traditional with this patch?
>>> I haven't tested qdisk with qemu traditional but unfortunately
>>> qemu-trad. is still widely used and therefore you have to be sure
>>> that does not cause problems.
>>
>> Ah, now I get your question.
>>
>>> I asked about because devices parts seem the same with both qemu but
>>> I not sure about it.
>>
>> We've already switched to qemu-upstream in 4.3. And this patch is not
>> backport material so old system would just work fine IMHO.
>>
>> The only risk of breakage is: users have device_model_version set to
>> qemu-trad and run blktap kernel with Xen pre-4.3, then upgrade to Xen
>> post-4.3 (with this patch). I've tested that, and qemu-trad runs fine
>> for me -- at least it boots and dd works well.
>>
> 
> I didn't have a VHD image (format commonly supported by blktap and qemu)
> at hand so the test was not complete. But qemu-trad and qemu-xen are
> both maintained so even if it breaks we are able to fix them -- which is
> main point of this patch, to let users have better supported backend.

I might be completely wrong, but wasn't there a problem when using
blktap VHD images with Qemu (ie VHD images created with blktap weren't
copatible with VHD Qemu implementation)?


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