Re: [Xen-devel] Anyone using blktap2?

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Fri, May 17, 2019 at 02:36:41AM -0400, Rich Persaud wrote:
> > On May 13, 2019, at 11:34, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> > 
> > Hello
> > 
> > Seeing that you were the last people who changed blktap2 in a meaningful
> > way: do you use it at all?
> 
> As discussed F2F in a Xen Summit 2017 design session: OpenXT and
> Citrix XenServer use blktap. VHD encryption support was recently
> upstreamed from OpenXT to the Citrix-maintained repo [1] for blktap3
> [2], now used by OpenXT.  Prior versions of OpenXT use blktap2.
> 
> Citrix changed the license of XAPI blktap from GPL to BSD, to enable
> non-OSS features in the paid version of XenServer. The XAPI blktap
> repo is actively maintained, with dozens of commits in 2018 and 2019,
> the most recent being this week.
> 
> If the XAPI [3] blktap repos are part of Xen Project, should LibXL
> support a Xen Project feature that is actively maintained and shipping
> in production systems? Does the blktap3 repo [1] need to be separated
> from XAPI?  Perhaps a topic for discussion at the upcoming Xen Summit.
> 

Yes please propose a topic.

To answer one of your questions:

There is a supported way to use blktap after removing the in-tree code
-- use phy backend and make use of the block-tap script, which I have
deliberately left intact in tree.

See the comment at the beginning of hotplug/Linux/block-tap.

With this mechanism we don't need to carry a copy of blktapX in tree.

> > I'm thinking about dropping it (again).
> 
> What would be the proposed mechanism for Xen VM block storage backed
> by thin-provisioned VHD files with per-VM encryption keys? This
> capability was sufficiently valuable to be upstreamed by Citrix, from
> OpenXT to Xen Project XAPI in 2018.  
> 
> With the imminent arrival of Windows Hyper-V and WSL2 Linux 4.19 on
> developer desktops, VHD support (i.e. Microsoft storage
> interoperability) in Xen may be a feature to improve rather than
> remove.

We're merely talking about dropping the (dead) in-tree copy of blktap2
and the inflexible code in libxl. Nothing stops you from using the
aforementioned mechanism to continue using whatever out of tree blktap
you have.

Development of blktapX should be discussed with respective developers. I
don't think we will want to carry a copy in xen.git.

Wei.


> 
> Rich
> 
> [1] https://github.com/xapi-project/blktap
> 
> [2] https://wiki.xenproject.org/wiki/Blktap3
> 
> [3] https://xenproject.org/developers/teams/xen-api/
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel