[Xen-devel] "storage domain": is the idea still alive?

[Eric Shelton <eshelton@xxxxxxxxx>]

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

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