Shrinking a LUN's size isn't something i'd do. However, increasing a LUN's size is OK. You need first to make sure the containing volume has enough space. If not, you should first increase the volume's size using SnapDrive. Then you can increase the LUN size.
Shrinking a LUN works just fine with SnapDrive. You are limited by how much you can shrink a LUN by the LUN geometry and the available space on the LUN. For example, if I have a 100MB LUN and grow it to 100GB, the LUN geometry will not let you shrink the LUN back down to 100MB again.
"When you shrink a partition, any ordinary files are automatically relocated on the disk to create the new unallocated space."
In description for the syntax of diskpart shrink:
"No data loss occurs. If the partition includes unmovable files (such as the page file or the shadow copy storage area), the volume will shrink to the point where the unmovable files are located."
I have not tested this yet, but from the documentation, it appears that Windows will not let you shrink a LUN if it cannot create space for the shrink.
A consideration though is the impact on the rate of change in flexible volume where the LUN is located. Windows is copying the files to free up the space to shrink the LUN. This will action will probably result in larger snapshots and if the volume is snapmirrored, more data will be in the transfer after a LUN shrink.
I just shrunk a CSV LUN and had horrific results, as noticed previously. I worry about experiencing something similar to extending the same LUN. Is there any "official" documentation from NetApp, not just community hearsay (ala "I done that") that says either is supported or unsupported? That would clear things up.
Whether LUN shrinking / growing is supported or not, purely depends on the host side - NetApp delivers the capability which may, or may not be properly handled by a particular OS / clustering methodology.
MS Technet doesn't give a clear answer to you question, so the safest assumption is it is not supported (i.e. growing a CSV volume).
I would rephrase and say I am barking up the wrong branch - I think we are sitting on the same tree . . .
I agree that ultimately MS needs to support it - but shouldn't the storage vendor who is providing you with the utilities to perform certain actions know if something is allowed or not, and hopefully, prevent you from doing something that will cause negative effects?
Plus, this is something at least that should go into their Best Practices Guide for Hyper-V (which is really helpful BTW).
I was just frustrated because I tried it and didn't think twice that it wasn't supported, seeing that with a regular disk you can. I would've thought this is something they would've tried in the labs (seeing that SnapDrive 6.2 [I think] wa the first version that supported CSV disks anyhow). And even if not, if they could try and just let us know clearly. Something which is relatively easy to determine and find out shouldn't be something that needs to be hidden.
When you say "resize" - does that mean Shrink & Grow? Are there any grow limitation such as with Shrinking? I went from a 250GB LUN to a 175GB LUN and had problems, similar to what was first posted here (https://communities.netapp.com/message/22197#22197).
I am wondering if there is some other factor here in play, such as SnapShots, which are possibly causing the problems. You guys fully tested in your labs shrinking a CSV Cluster disk, for example 50GB or so (ie. not just a few MB or 1-2 GB)?
Sorry to pester, just want this be to VERY clear for us in the future, and everyone else. I would hate to see people have to go through what I went through.
I'd like to take this up with our engineering team to see if the "redirected" mode is a requirement for CSV resizing. Do you have a NetApp support case open on this issue? If not, can you please open a support ticket and collect the OntapWINDC logs?
Once the ticket is open, I can forward the information to our dev team.
I've been speaking with our dev team and its not really clear if the "redirected" mode is a MS requirement. Do you have any documentation from MS support suggesting this requirement?
I've tried looking around online and haven't been able to find any official documents on CSV resizing. I've confirmed with our DEV & QA that CSV resizing has been tested and confirmed (Both Shrink & Grow).
I'm sorry to hear about your support situation. Let me see what I can do here.
Can you collect the OntapWINDC logs and send them to me? You've got a PM.
Maybe you should e-mail Scott M. Johnson and/or the Windows Server/Storage team directly (like I did) and ask them if it is just a "best practice" to put turn on Redirected mode or if it is in fact a requirement.
Also, another though that I had which could have been the cause of my and mes@faber's problem - when you shrink a LUN, let's say 20GB, does that 20GB now get added to the latest snapshot, and if you don't have enough space allocated to SnapShots with no snap-auto-delete turned on, wouldn't that overflow into your lun space causing alignment corruption?
What I noticed when I shrunk my CSV LUN was that the Failover Cluster Manager didn't see my new CSV disk in size, but it still saw it as the old size. Even in Disk Management I couldn't get the updated size (smaller). SnapDrive successfully shrunk the LUN, but Windows was still seeing it as bigger (original size).
I did open a case and could send you and ONTAPWINDC if you want - ask me privately and I can give you the info you need (or more if interested).
For example, if I have a 100MB LUN and grow it to 100GB, the LUN geometry will not let you shrink the LUN back down to 100MB again.
Why? From my experience in CHS the Heads/Sectors part is fixed during LUN creation; when you resize a LUN, NetApp changes only number of Cylinders. LUN with initial size of 100M would have CHS=13/255/63, increasing size to 100GB changes geometry to 13055/255/63. What exactly prevents it goiong back to original 13 cylinders?
Actually I just tested it and had no problem going back to 100MB