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

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
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/, 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"

"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


Xen-api mailing list

Reply via email to