[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Wed, Aug 28, 2013 at 05:04:07PM +0200, Roger Pau Monné wrote:
> 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)?

Do you mean that timestamp bug in libvhd [0]? Oh that's not fixed in OSS

Ian, do you think it is necessary to have [1] ported to OSS Xen?

Then there's all the old images needed to be converted. However this is
a necessary step sooner or later if users migrate these images to newer
Xen + newer kernel which don't have blktap anymore.


[0] http://lists.xen.org/archives/html/xen-devel/2013-02/msg01326.html

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.