Xen devel - Apr 2013 - "storage domain": is the idea still alive?

Dear List,

I am interested in the notion of a "storage domain," involving passing
a storage controller through to a domU, and having it serve block
devices to other domains.  However, I cannot find a way to implement
this with xl.  Browsing the code, the "xl block-attach" command
appears to be for dom0-backed block devices only, as in
xl_cmdimpl.c:main_blockattach(), a variable be_domid is initialized to
0, never changed, and then used to populate disk.backend_domid.  Also,
the code for parsing an xl.cfg-style config file appears to lack any
way to specify a backend domain ID.

If I have overlooked something in xl, I would appreciate a pointer in
the right direction.

In contrast, xm/main.py:parse_block_configuration() processes an
optional last parameter specifying the backend domain ID.  Maybe I am
missing something in xl?  About a year ago it was indicated xl had
"feature parity" with xm on this specific feature.

If it turns out that xm provides this feature but xl does not, can I
safely mix and match use of the two?  Is libvirt considered a better
tool for going about this?

Finally, is this feature functional at this time?  Was a conclusion
reached that they should not be used?  Currently,
http://wiki.xen.org/wiki/Driver_Domain only gives an example of a
network device domain, without any discussion of a block device
domain.  However, not so long ago, the only thing it discussed was a
block device domain arrangement.  This change occurred less than 3
months ago. Also, Qubes, which long ago proposed the use of a storage
domain, has not implemented one.  These things might suggest that
storage domains are unavailable or discouraged.

Thank you for your help,
Eric

On Fri, Apr 5, 2013 at 9:21 AM, Eric Shelton <eshelton@pobox.com>
wrote:
> Dear List,
>
> I am interested in the notion of a "storage domain," involving
passing
> a storage controller through to a domU, and having it serve block
> devices to other domains.  However, I cannot find a way to implement
> this with xl.  Browsing the code, the "xl block-attach" command
> appears to be for dom0-backed block devices only, as in
> xl_cmdimpl.c:main_blockattach(), a variable be_domid is initialized to
> 0, never changed, and then used to populate disk.backend_domid.  Also,
> the code for parsing an xl.cfg-style config file appears to lack any
> way to specify a backend domain ID.
>
> If I have overlooked something in xl, I would appreciate a pointer in
> the right direction.
>
> In contrast, xm/main.py:parse_block_configuration() processes an
> optional last parameter specifying the backend domain ID.  Maybe I am
> missing something in xl?  About a year ago it was indicated xl had
> "feature parity" with xm on this specific feature.
>
> If it turns out that xm provides this feature but xl does not, can I
> safely mix and match use of the two?  Is libvirt considered a better
> tool for going about this?
>
> Finally, is this feature functional at this time?  Was a conclusion
> reached that they should not be used?  Currently,
> http://wiki.xen.org/wiki/Driver_Domain only gives an example of a
> network device domain, without any discussion of a block device
> domain.  However, not so long ago, the only thing it discussed was a
> block device domain arrangement.  This change occurred less than 3
> months ago. Also, Qubes, which long ago proposed the use of a storage
> domain, has not implemented one.  These things might suggest that
> storage domains are unavailable or discouraged.
>
> Thank you for your help,
> Eric
>
Hi Eric,
I just sent out a similar thread asking for the same feature:
http://lists.xen.org/archives/html/xen-devel/2013-04/msg00216.html

In my thread, Daniel has provided a patch. However, I''m not sure if
there are other requirement to get it work.

Thanks,
Timothy