Re-Attach Virtual Disks automatically from StoragePools

I’ve been rebuilding some of my lab and demo machines running WS2012 R2 preview with RTM bits. As they are Cluster-In-A-Box systems, they have shared disk between them and an already configured Storage Pool. Once I did a clean install one node of the CiB with Windows Server 2012 R2 RTM bits – it sees the old storage pool disks and recognizes there is a storage pool available on the disks. I want to preserve the Storage Pool and its data, so it’s really an Import Storage Pool action I am looking to accomplish.

I found these steps from Martin Lucas on the AskPFE blog. (How to import a StoragePool)

  1. Make the physical disks available to the server (I’ve already done that).
  2. Right click the Storage Pool and choose Set Read-Write Access. Choose the server you want to enable Read-Write access.
  3. Attach the Virtual disks back. Each disk has to be selected and re-attached.
  4. Online the Volume (logical disk) to get it operational once again.

This works great, until you restart your system – at which time it recognizes the Storage Pool, but the Virtual Disks are not re-attached automatically. You can do this with a little PowerShell, since the GUI does not have the option to modify the “IsManualAttach” property.

Open your administrative level PowerShell prompt and type in the following.

Get-VirtualDisk | Where-Object {$_.IsManualAttach –eq $True}

IsManualAttach

This lists off your virtual disks where the IsManualAttach property is turned on and the disks will not auto-reattach on restart. You can see I have four of them for this demo box I use.

Now run the line again but include the following:

Get-VirtualDisk | Where-Object {$_.IsManualAttach –eq $True} | Set-VirtualDisk –IsManualAttach $False

There won’t be any output, since you are piping the results into the Set-VirtualDisk command which will modify the IsManualAttach property to false.

Voila!

My Imported StorageSpace will now re-attach my drives correctly, even on restart!

About author View all posts

Rick

2 CommentsLeave a comment

  • Thank you very much. It worked like a charm.
    I was thinking my disks are defect but only this small setting was wrong.

  • Thanks!

    If I may impose on you further, I have this situation:

    A micro ITX home server with 6 sata ports, all filled with one 120GB Intel boot ssd and five 3TB Seagate drives. One of the hard drives needs replacing, it developed bad sectors but it still works.

    So, I have a 13.6TB storage pool and on it I have two thin provisioned, parity virtual disks, one 2TB (758GB allocated, 1.011TB used) and another 8TB (3.46TB allocated, 4.62TB used).

    My problem is this, when I try to remove one of the 3TB drives it tells me to add another before I take this one out. Obviously I can’t do that because all the SATA ports are filled and I don’t want to buy another one, I want to send this one to get replaced under warranty.

    By my math, the storage pool has more than enough free space to take out one drive and redistribute the data to the other drives, but it doesn’t wan to do that for some reason.

    All I can think is Windows counts all 10TB as being full, never mind that the drives are thin provisioned.

    I also can’t decrease the 8TB virtual disk size.

    So, I’m left scratching my head .. 🙁

    Thanks for reading!


Warning: sizeof(): Parameter must be an array or an object that implements Countable in D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\project-nami-blob-cache.php on line 416

Fatal error: Uncaught WindowsAzure\Common\ServiceException: Fail: Code: 400 Value: The account being accessed does not support http. details (if any): <?xml version="1.0" encoding="utf-8"?><Error><Code>AccountRequiresHttps</Code><Message>The account being accessed does not support http. RequestId:aa80c173-401e-005b-794e-33cf33000000 Time:2021-04-17T05:59:11.2256974Z</Message><AccountName>ritgcache</AccountName></Error>. in D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\Http\HttpClient.php:382 Stack trace: #0 D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\Http\HttpClient.php(275): WindowsAzure\Common\Internal\Http\HttpClient::throwIfError(400, 'The account bei...', '\xEF\xBB\xBF<?xml versio...', Array) #1 D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\RestProxy.php(141): WindowsAzure\Common\Internal\Http\HttpClient->send(Array, Object(WindowsAzure\Common\Internal\ in D:\home\site\wwwroot\wp-content\plugins\projectnami-blob-cache\library\WindowsAzure\Common\Internal\Http\HttpClient.php on line 382