[Xen-API] Storage driver domains and XAPI

[Mike Neilsen <mike.neilsen@xxxxxxxxxxxxxxxxx>]

Does anyone recall if/how XAPI support for storage driver domains was
removed or altered between XenServer 6.x (xapi-0.2) and XenServer 7.x
(xapi-1.9.57+)

Perhaps there is a new preferred mechanism to establish a storage
driver domain? If so, could someone shed any light on what
configuration is required to bypass Dom0's SMAPI plugins?

Background... In XenServer 6.x, once could:
1. Create and provision a storage driver VM to communicate with XAPI
   storage requests over XMLRPC on the host internal management
   network
2. Create an SR in Dom0; set the required "type" parameter to "ext".
3. Create a PBD in Dom0 linked to the SR created in step 2.
4. Set step 3's PBD's "other-config:storage_driver_domain" to the VM
   created in step 1.
5. Finally, plug in the PBD.

In XenServer 7.x however, step 5 (plug in a PBD) XAPI attempts to use
assets in Dom0--an SM plugin or message-switch queue named after step
2's SR type ("ext", for example)--instead of a remote endpoint such as
the storage driver VM. In 7.x, if step 2's SR type is "ext", XAPI uses
Dom0's /opt/xensource/sm/EXTSR.py, while in 6.x, Dom0's plugins are
bypassed in favor of using the storage driver VM.

The following commit (Dave Scott) seems vaguely relevant:
  "All SMAPI access is now routed through the xcp-idl client code"
  
https://github.com/xapi-project/xen-api/commit/b0dba67e71a20534bc4e84d249f3264c21d1893d

"Driver_kind.classify" was capable of returning the IP of a storage
driver VM.  Looking through 7.x's XAPI and IDL code, I was not able to
find equivalent functionality.

So, driver domain feature: gone, or overtaken by an alternative
mechanism?

Thanks
  mike.neilsen@xxxxxxxxxxxxxxxxx

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