Shrinking Space, Creating Volumes & Disk Management Problems

Hello, 

 Re:1.   Sounds like you did not shrink the filesystem before you shrank it on the EQL side.  The partition table info tells the OS what the size of the partition is.  I hope you created a snapshot before you shrank the volume?   Otherwise you have just chopped off the back end of the volume, damaging the filesystem.  If you didn't create a snapshot, then you will likely have to restore it from backup. 

Re:1.  I'm guessing this is a SQL cluster?  By default only one server can log into a volume.  This prevents double mounting the volume on two NON clustered servers corrupting the volumes.  On each volume in the cluster, you have to enable "Multihost access".   There's a check box for that in the volume properties. 

At the CLI, you can enter:

GrpName>volume select VOLUMENAME multihost-access enable 

 Regards,

Don 

Hello Steve, 

  There's really nothing on the array side that can be done to restore that volume.  Any data in the blocks released are gone.  I would create a snapshot first.  Then using OS side tools shrink the filesystem to match the new volume size.  Then run chkdsk on the volume.  *MAYBE* you'll get lucky and there's not valuable data in those lost blocks.  Just increasing the size of the volume on the EQL side won't work.  A volume is made up of 15MB pages. Thee's a map of what pages are associated with that volume.  When you shrunk the volume, those pages were removed from the volume map and returned to free space to be re-used. If you put the volume back to its original size there's no where to be sure you get all the same pages back. 

 Regards, 

Don 

Don- Thank you.  You are correct on both counts.  I've fixed the second item.  Can you give me some ideas on how to fix the first item?

Steve

Hi Don -

  I have successfully resized the partition on one of my three hosts.  I restored my VMs from a snapshot and 4 out of 5 are successfully running.  However, the other two hosts still show the old disk at the expanded size.  Do I have to resize it separately on each host?

Steve

Hello Steve, 

 Are you talking about cluster volumes that are shared or unique volumes on each host?  If in a cluster you might need to log out the volume and log back in.  

 Regards,

Don 

Hello, 

Then try logging out.  Do NOT resize them again.   it's likely related to the MSCS service. 

Don

This is weird.  I resized the volume on host #1 from 6 TB to 3 TB and renamed it.  Hosts #2 and #3 show the old size (6 TB) and the old name.  I rebooted all three hosts.  I start the ASM on one of the hosts and was preparing to take screenshots to show you the difference.  All of the sudden, host #1 has reverted back to the old size and name!  How can this be? 

Here is a screenshot from Failover Cluster Manager.  As you can see, the top line shows the volume TSEV-Data as 2.93 TB.  But the bottom panel shows the same volume as 5.88 TB free out of 6.0 TB.

Hello, 

 Possibly the Microsoft Cluster Service Service.  Something in the configuration would be my guess.  Nothing on the storage side would cause this 

Don 

Hello, 

Earlier you said you restored from a snapshot.  Did you ROLL BACK a snapshot or mount it and restore the VMs?  If you rolled back the snapshot it would also put the size back to 6TB.  Check the EQL to see if the volume is back to 6TB.  If not then it's something up with Windows CSV side of things. 

 Don 

Don - I'm still struggling with this.  The array side is 3 TB, which is good.  The CSV side shows 6 TB.  If I shrink the CSV side, I lose the VMs and I have to restore from the array side, which then resets the CSV back to 6 TB instead of 3 TB.  It's an endless loop.

I also seem unable to back up the VMs to another location because of VSS problems.  It would seem that all of these things are interrelated?  I would really appreciate your thoughts on how to proceed.

Hello, 

 If you are restoring the snapshot over the 3TB volume then that's what's expected to happen.  Since the volume size was 6TB when snapshot was taken.  No getting around that if you do an inplace restore of a snapshot.

 I'm not expert on CSV volumes/clusters.  If you can find out how to mount the snapshot to the cluster then you can copy the VMs over to the 3TB volume w/o resetting the size.  With VMware you have to resignature the snapshot so the cluster knows it's a snapshot.  There has to be a similar process for MS.

VSS is very different from this issue.  They are not likely related. VSS is a conduit for MS to send commands to and get results back.  No actual data goes across that connection.  What's the exact error message?  

Regards,

Don