FAQ

Unable to deploy Storage Spaces on Windows Server on Instance.

(:Last updated)

Even if you mount Volume on Instance, it unable to deploy Storage Spaces as default setting

because driver on Instance does not correspond to Storage Spaces.

It has 2 workarounds for it as below;

Please note that both workarounds have cautioned, understand the cautions and conduct any workarounds at your own risk.

 

Workaround1.Changing driver type

You can deploy Storage Spaces if you change driver type on Instance by configuring property to snapshot which was created from Instance of Virtual Server. Detail procedure is the following.

(Step for changing driver type)

  1. Select Windows Server of Official template, and create an Instance
  2. Log in The Instance via console, and setting account
  3. After shut down the Windows Server Instance, create snapshot from the Instance
  4. Configure property in the snapshot via API(It requires API operation) After getting Keystone token, execute the following API for changing driver type in the snapshot from ’hw_disk_bus’ to ’ide’API format for changing ’hw_disk_bus’ from default(virtio) to ’ide’curl -i -X PATCH -H 'Content-Type: application/openstack-images-v2.1-json-patch'  -H 'X-Auth-Token: {token}' https://{endpoint}/v2/images/{image_id} -d '[{"path": "/hw_disk_bus", "value": "ide", "op": "add"}]' Confirm response '200 OK' against the above API callHTTP/1.1 200 OK

    content-length: 1662

    server: Apache

    connection: close

    *snip*

    (Reference)Roll back to default setting

    API format for changing ’hw_disk_bus’ from ’ide’ to default(virtio)

    curl -i -X PATCH -H 'Content-Type: application/openstack-images-v2.1-json-patch'  -H 'X-Auth-Token: {token}' https://{endpoint}/v2/images/{image_id} -d '[{"path": "/hw_disk_bus", "value": "virtio", "op": "replace"}]

  5. Create Instance from the snapshot which was executed procedure 4.
  6. Enable to deploy Storage Spaces on setting display on Windows Server as the following image.faq_vs_storage_space

 

(Cautions)

  • Up to 4 volumes(including root volume) can be attached to each Instance by this work around.
  • Volume can’t be attached/detached with power-on. Please power off Instance when attach/detach Volume.
  • API operation is required when attaching additional Volume. It fails to attach additional Volume by GUI operation for attaching to existing disk pass. (API format for attaching additional Volume)

curl -i 'https://{endpoint}/v2/{project_id}/servers/{server_id}/os-volume_attachments' -X POST -H "Accept: application/json" -H "Content-Type: application/json"  -H "X-Auth-Token: {token}" -d '{"volumeAttachment": {"device": "{device_path}", "volumeId": "{volume_id}"}}

  • This workaround might cause to decrease I/O performance to Volume.

 

Workaround2.Using Block Storage

You can deploy Storage Spaces if you use Block Storage(Provisioned I/O Performance) and mount it instead of Volume of Virtual Server.

(Cautions)

This workaround has been verified by Enterprise Cloud Provider, however, it is not supported by Microsoft Corporation because Block Storage adopts iSCSI connection and Microsoft does not support iSCSI connection for Storage Space.

 

▼Reference:Deploy Storage Spaces - TechNet - Microsoft

https://technet.microsoft.com/en-us/library/jj822938%28v=ws.11%29.aspx

 

▼Reference:Service Description of Block Storage(Provisioned I/O Performance)

https://ecl.ntt.com/en/documents/service-descriptions/rsts/storage/block_storage.html

Is this page helpful?

Yes No
  • ECL2.0
  •  
  • Virtual Server
  •  

Related Pages

We appreciate your cooperation in improving the site

Did this FAQ be helpful? If you have any comments, please let us know.

Thank you

Your feedback has been received.