[CentOS-virt] The future of blktap in Xen4CentOS

Mon May 11 13:53:04 UTC 2015
George Dunlap <dunlapg at umich.edu>

On Fri, May 8, 2015 at 11:10 PM, Johnny Hughes <johnny at centos.org> wrote:
> On 05/06/2015 09:27 AM, George Dunlap wrote:
>> On Tue, May 5, 2015 at 2:07 PM, Johnny Hughes <johnny at centos.org> wrote:
>>> WRT a new kernel .. the 3.18.x kernel has been selected to be maintained
>>> as an LTS until Jan 2017.  I think we should start work on rebuilding
>>> this kernel and using it in the x4c projects.
>>> https://lwn.net/Articles/636289/
>>> Thoughts?
>>> I will grab this kernel and try to roll in all the patches, etc. and see
>>> if I can make it work.
>> I did a little bit of work on building the 3.18 kernel a couple of
>> weeks ago, but it looks like the blktap2.5 kernel code we were using
>> before has totally bitrotted.
>> I see three ways forward:
>> 1. Try to do a "deep port" of the functionality, continuing to
>> maintain it going forward.
> I did this with the kernel I released .. the blktap module is loaded
> upon boot.. I did have to change some of the code based on this Debain bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748953
> I have no idea how well this works .. we could use some testing of that
> kernel here:
> http://people.centos.org/hughesjr/xen-kernel/

Right -- done by none other than Citrix's own Bob Ball... who updated
it in his own github branch but then forgot to send a pull request to
to the main XenServer repo, which is why I didn't see it. :-)

>> 2. Start using the blktap3 code, which requires no kernel driver.
>> 3. Drop blktap support, and ask people to use qdisk for vhd.
>> Re #1, I'm not really excited about the idea of trying to keep porting
>> those patches forward (and finding and fixing bugs in the forward-port
>> each time).
> This has not been a huge problem in the past .. it mostly works OK.  At
> least no one has complained.  The only time I had to change it was when
> we moved from 3.6 to 3.10 and then from 3.10 to 3.18.  But that does not
> mean it works without issue, just that no one complained about it.

Right... well I guess there are other users of the same code (which is
why Bob submitted the fix last year), so we can hope that it's at
least getting a little testing.  If we give it a month of beta testing
before releasing it, I think that's the best people can expect from a
community-run project.

>> In parallel to the Xen for C7 work I've been doing, I've been working
>> on getting upstream Xen to build against XenServer's blktap code, with
>> then aim of moving to blktap3.  If we want to go with #2, then a major
>> kernel update will have to wait until that work is done.
> I have no real preference .. just that we need a kernel update in 3
> months as in Sept 2015, 3.10 support stops at kernel.org.
> We can use the 3.18 LTS tree with my mods now, if it works for everyone
> .. although the best way longterm seems to be to use blktap3 in the
> future since that is what is in XenServer.

Yes, using the forward-ported kernel blktap driver is probably the
best thing to do until we have a replacement.