7 Replies Latest reply on Jun 29, 2020 5:58 AM by sjesse

    What would cause disk type not to change when performing a storage VMotion?

    pasalott Novice

      Currently running vSphere 6.7.  I have a few VMs that have disks in which I am unable to convert from thick to thin.  I've attempted storage vmotions for these disks, with Thin Provisioning selected, and attempted with the VMs powered on and off, but the disk type will not change.  Any ideas on what could be causing this?

        • 1. Re: What would cause disk type not to change when performing a storage VMotion?
          continuum Guru
          vExpertCommunity Warriors

          Easiest reason:

          a thick provisioned vmdk that is 50% filled with data CAN be converted to a thin provisioned \VMDK

          a thick provisioned vmdk that is 100% filled with data CAN NOT be converted to a thin provisioned \VMDK

          • 2. Re: What would cause disk type not to change when performing a storage VMotion?
            pasalott Novice

            @continuum Hmm, not sure if it's a disk space issue.  There are two VMs I'm having issues with.  One is a linux applicance with a very small disk of around 1 MB.  I can understand why this one will not covert so it's not really important. Can leave as is.

             

            The other VM is Windows 2012.  The disk in question is 175GB with 65GB of available disk space.  Would that be enough to cause the disk not to convert to thin provisioned?

            • 3. Re: What would cause disk type not to change when performing a storage VMotion?
              continuum Guru
              vExpertCommunity Warriors

              How do you know that your 175 gb has only written 65gb ?

              And a 1MB vmdk sounds very suspicious - please add details.

               

              By the way - to figure out the provisioning type of a given vmdk there is only one reliable way:

              Query the flat.vmdk with the command vmkfstools -p 0 name-flat.vmdk > result.txt

              If results.txt has even a single line containing VMFS -Z it is lazy zeroed.

              If results.txt has even a single line not containg VMFS it is thin provisioned.

              For this test ignore the first line of results.txt - thats the info part.

              Every line that follows specifies the allocation of a fragment of the flat.vmdk.

              • 4. Re: What would cause disk type not to change when performing a storage VMotion?
                pasalott Novice

                Windows shows 65 GB available for that disk

                 

                The linux vm is a Cisco Umbrella virtual appliance.  There are two. Each have a small disk of about 1 MB.  Only one of the two VMs has this disk as thick instead of thin provisioned.  These VMs were deployed before I began working here a few months ago.

                • 5. Re: What would cause disk type not to change when performing a storage VMotion?
                  continuum Guru
                  vExpertCommunity Warriors

                  > Windows shows 65 GB available for that disk

                   

                  That is nice to know but irrelevant to the question.

                  A flat.vmdk is used to 100% if each single 1 MB block of has been used once.

                  If the guestOS cleans up the trashbin later this does not change the state of those one MB blocks.

                  When ever you write at least one byte to a one MB block of a vmdk this block changes its state from thin or lazy zeroed to eager zeroed.

                  To change an eager zeroed  one MB block back to a thin provisioned block you must use a function that reclaims the space - such as vmkfstools -i cuurent.vmdk thin.vmdk -d thin.

                   

                  If you really want to understand this - provide an example where you use the vmkfstools -p 0 name-flat.vmdk > result.txt function

                  • 6. Re: What would cause disk type not to change when performing a storage VMotion?
                    pasalott Novice

                    I had been away for a few days...

                     

                    In regards to the "vmkfstools -p 0 name-flat.vmdk > result.txt" function, I've checked and I do not see any *.flat.vmdk files for any of the VMs in question.

                    • 7. Re: What would cause disk type not to change when performing a storage VMotion?
                      sjesse Master
                      User ModeratorsvExpert

                      There is a kb for this, and unless its a specific setup, you need to do it manually.

                       

                      VMware Knowledge Base

                       

                      To reclaim the unused space of a virtual disk in ESXi/ESX 4.1 or later:

                       

                       

                       

                      Note: Where vmkfstools supports the -K option (--punchzero), you can reclaim the zeroed blocks of thin-provisioned virtual disks without the need to clone to another VMFS datastore with a different block size.

                       

                      1. Ensure that the disk has no Snapshots.
                      2. In a Windows virtual machine, run the SDelete command (or a tool with similar functionality) to zero out all unused space. The syntax for the SDelete command is SDelete -z driveletter. If you use SDelete, ensure that you use version 1.6 or later.

                        Note: Zeroing all unused blocks inflates the disk to its full size as if it was an eagerzeroed disk. Ensure that there is sufficient space on the datastore to allow the disk to grow to its full size. For more information, see Determining if a VMDK is zeroedthick or eagerzeroedthick (1011170).
                         
                      3. Shut down the virtual machine or temporarily remove the virtual disk from the virtual machine to ensure that it is not in use.
                      4. Erase all unused blocks by running the command:

                        vmkfstools -K /path/to/disk-name.vmdk