Extend Failed Size Not Supported Disk Win 16
You will most likely have to shut down the VM and then increase the size of the C: drive - not sure you can do that on the fly while the VM is running in Hyper-V. Reboot the VM and then. Extend Volume failed, but partition was extended. I hopped into vSphere and expanded the size of all disks on all the servers, then hopped into Server Manager to. How to Expand and Resize Storage Spaces Direct CSV Volume? Point to remember: When you are resizing the storage space direct CSV volume, you have to specify the new total size, and not the amount you want to increase, so in this example, the existing virtual disk volume is 700 GB, I need to add 324 GB (new) + 700 GB (existing) = 1,024 GB.
Hey guys!I had made a temporary FAT32 partition to use with my PS3 which I don't need anymore. I deleted the volume and tried extending my NTFS partition, which I use for backups and is running out of space. When I try to extend it, I get a message asking me if I want to convert the basic disk into a dynamic disk. I click yes. Then I get an error from the Disk Manager saying 'The operation is not supported by the object.'
Now I'm stuck here and don't know what to do. Any advice would be appreciated!
The hard drive is a Western Digital Elements 2TB USB external drive. I'm running Windows 7 64bit and using Windows Disk Management to manage my partitions.
I've recently taken to converting a couple of mirrored RAID1 arrays into one large storage pool. I have two 2TB disks and two 3TB disks, altogether 10TB, which when mirrored should give me 5TB of usable space.
I started the storage pool with the two 2TB disks and one of the two 3TB disks, using the final 3TB disk as a backup of the old data to move to the new pooled storage. I set up the virtual disk as 'mirrored' on top of the new pool, and had a little under 3TB of usable space.
After moving the backup from the extra 3TB drive to the new pool, I cleaned it, and added it to the pool. However, I'm now unable to extend the mirrored virtual disk to take advantage of the added space.
Unfortunately I cannot post images due to my starter reputation, but my pool shows up with 9.09TB capacity, and 2.64TB of free space. When attempting to extend the virtual disk, the maximum size allowed is 3.22 TB, only just a hair more then before I added the 3TB drive. Physical disks show that almost none of the new disk is being used, while the rest are full.
I've read elsewhere that number of columns can restrict how you can extend virtual disks, but my number of columns is set to 1, which should allow extending to any number of disks.
Here's the powershell output of my virtual disk:
And here is the powershell output for the pool:
Any ideas how I can reclaim my space?
2 Answers
I ran into the same issue. Neograph's comment is irrelevant in this case, he's talking about traditional Windows Server disk mirroring, not Storage Spaces. Thin provisioning is also quite irrelevant in this case. You can use it as a workaround, but I think more cautious planning will be better both budget- and performance-wise, just read on and you'll see.
After quite some time spent on reading and playing around in Server Manager, I think I figured out what's going on. The thing is, SS has this thing called 'columns'. That defines how many disks data is striped across. If your virtual disk was created with 4 columns, data is only spread across 4 disks with Simple layout (i.e. RAID0) or 8 disks with Two-way mirror (i.e. RAID10), not all of them. Now this may be confusing for someone who comes from traditional HW RAID (like me), but that's the way it is.
Note: from now on, I'll refer to the number of columns as column size because it's much more intuitive for me this way.
So anyway, column size also defines how you can extend a virtual disk. Clearly, if your current VD has groups of 4 disks (= column size is 4), you can't add a 'half' group by adding 2 new disks. So the number of disks required for expansion is basically
So if you have a two-way mirror and a column size of 1, you can only add pairs of disks. If your mirror has a column size of 3, you can only add 6, 12, 18 or so disks.
From what I understand, the default column size for a VD is the number of disks divided by copy count, but 8 at maximum, e.g. if you have 10 disks in a two-way mirror, column size will be 5, if you have 16 disks, column size will be 8, but if you have 24 disks, column size will still be 8 - by default. Note: you can check these numbers under VD properties (NumberOfColumns and NumberOfDataCopies properties undes Details).
And here come a lot of headaches:
- the default column size requires you to double the disk count if you want to expand the VD (in most cases)
- you can only select column size if disk usage was set to Manual during pool creation
- the default disk usage is Automatic (of course)
- you cannot change column size once the VD's created
- you cannot change disk usage to Manual once the pool's created
So to have this set up properly, you need to delete:
- the volume
- the virtual disk
- the storage pool
i.e. everything. As a sidenote, stripe size (called Interleave size in SS) is also unavailable if disk usage is set to automatic.
Now you may wonder why would anyone use anything bigger than 1 for column size. The answer is of course performance. The bigger the column size the better the performance you get. Actually, it can be quite dramatic, here's a benchmark with column size 1 and 6:
You need to plan wisely. Only use a high column size if you know for sure that you'll be able to afford to purchase a big number of disks once disk space runs out.
Some good reads on the topic:
I can't downvote by now, but I want to outline, that the basic information given in bviktors post is wrong - he is still thinking in Raid by saying you can't extend with half a diskgroup:
- If you have a Storage Pool with 4 Columns - you can use any number of disks, starting with 4.
- Storage Spaces will always utilize all the Disks you have!
- The Column count just defines on how much Disks data is written at the same time (This is called striping)
- The next Stripe (by default 256 KB in Size, called Interleave) however can (and will) be written to 4 different Disks!
Hence, to extend a Storage Pool of 4 Columns - you don't need to add 4 disks - you only need to make sure, that you have 4 disks with remaining diskspace left in the pool!
So, if 1 is full, but 3 have remaining space, the pool will become operational again after adding One Disk!
(This allows to mix capacity as desired - there's no need to keep the raid-constraint of equal disk-sizes)
As a Best-Practice, you should always add more disks, than #NumberOfDataCopies * #NumberofColumns would be:
Consider a 2 Column 2 Copy Disk - It requires a minimum of 4 disks. If you loose one Disk, you could still access your data - but you cannot write anything anymore, cause you don't have 4 columns left where data could be stored!
Consider you would have added 5 Disks to that pool (which will be used based on Size by the Storage Spaces Subsystem, filled up in the best possible way to make all disks hit 100% at the same time) - loosing one Disk still retains your data - and keeps your Pool working for new writes, because you still have the minimum of 4 Columns left.
Also, this allows you to rebuild the pool immediately if one disk fails, without having to purchase a new disk first!
The data will now be 'moved' to the remaining disks, if enough space is left. After the rebuild:
(You can use the same commands to retire 'functional' disks and move data to other disks - this will allow some sort of redistributing the data, once you add a disk - but at the end you will always have one disk 'empty'. However in your case it would not work, due to the small number of disks. In 10 disk pool for instance, you could free up a 2 TB Disk, by distributing as little as 200 MB to every other disk. Re-Running the operation will now write prefered to the empty disk. Storage Spaces basically always says: 'I have to write: 8 Blocks (NumberOfColumns * NumberOfDataCopies) with a size of 64 KB (Interleave / Number of Columns) each - give me 8 distinct disks out of the 10 disks with the least percentual usage, so I can throw the data there!')
In your example mentioned:
I started the storage pool with the two 2TB disks and one of the two 3TB disks, using the final 3TB disk as a backup of the old data to move to the new pooled storage. I set up the virtual disk as 'mirrored' on top of the new pool, and had a little under 3TB of usable space.
You started with 2+2+3 TB - Storage Spaces now would put about 1/3 more data on the 3TB disk, than on the Other Disks while maintaining the required mirror, so they fill up equaly.
('2 Datacopies, 1 Column: I have to write: 2 Blocks (NumberOfColumns * NumberOfDataCopies) with a size of 256 KB (Interleave / Number of Columns) each - give me 2 distinct disks out of the 3 disks with the least percentual usage, so I can throw the data there!')
Physical disks show that almost none of the new disk is being used, while the rest are full.
Now, your disks are 'almost full' and you added a 'new' disk:
Now, remember you got a mirrored virtual disk there: If you are going to extend that disk, Storage Spaces needs two have at least 1MB on two Disks, to extend the virtual disk by 1MB
Your Pool now will do the following: EVERY Data written goes to disk 4 - and every COPY written goes to either 1,2 or 3, as this will give you the most usable Diskspace.
While Extending a (fixed) this, the following equation would be evaluated:
A thin provisioned can be extended beyond the available physical size - it will just stop accepting data, once 400 MB have been written!
Hence, with the free diskspace of 100+100+200 - Your Virtual Disk can only be increased by 400MB, because then disk 1,2,3 are full - and disk 4 has 2.6 TB Space left. No more storage to keep a dual mirror operational.
Error Extending Volume Not Enough Available Capacity
Now, you just need to add 1 Disk - let's say 8 TB to be able to extend your virtual disk by 2.6 TB again (2.6 on disk 4 and 2.6 on the 'new 8 TB Disk')