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@adventiumlabs.com
_______________________________________________
Xen-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api
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@adventiumlabs.com
_______________________________________________
Xen-api mailing list
Xen-api@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-api