> Anyway, is the information provided in the link accurate?
NO - this is dangerous bullshit !!!!
The instructions for the conversion from cli is incomplete - showing that the author did not completely understands what he is talking about.
The instructions ....
After the convertation is completed, delete the original Thick disk file w10rtm-test.vmdk:
And rename the resulting Thin disk:
mv w10rtm-test-thin.vmdk w10rtm-test.vmdk
Just renaming the descriptor.vmdk would have the result that w10rtm-test.vmdk still points to w10rtm-test-thin-flat.vmdk
If you are not aware of this ugly things will happen.
To rename a vmdk you should use the vmkfstools command or to do it manually you need to:
2.rename associated flat.vmdk
3.edit descriptor.vmdk so that it points to the renamed flat.vmdk.
When you dont do #3 the vmdk will be invalid and unusable.
> This time I converted from Tick to Thin on my VMWare workstation machine and I have yet to upload that to the ESXi server to see if it actually worked.
Bad idea - you can not convert to ESXi - thin format using Workstation.
Be careful - looks like you prefer to read obscure VMware related blogs rather than consulting the forum or the VMware documentation.
This is a very dangerous habbit - stop doing this.
Forget the command line section in the link you've posted!
In order to do this from the command line, stay with vmkfstools commands, which will not only take care of the conversion, but also of the metadata.
To convert a virtual disk to thin, run:
vmkfstools -i sourcename.vmdk -d thin targetname.vmdk
Caution: In case the VM has active snapshots, either delete them prior to the conversioin, or specify the current snapshot's .vmdk name (as the source), as it shows up in the VM's configuration (.vmx) file.
Once converted, you may delete the original virtual disk from the VM's settings (backup the .vmdk files before deleting the disk, if you want).
Then rename the target to the source virtual disk's original name. This step is optional, but makes it easier to associate the virtual disk with the VM by their names.
vmkfstools -E targetname.vmdk sourcename.vmdk
Please note the upper case "-E".
Now you may add the virtual disk to the VM's configuration again.
This time I converted from Tick to Thin on my VMWare workstation machine ...
This won't work. Thin Provisioning is a VMFS file system feature.
As for the Thick to Thin on VMWare, I used this...
vmware-vdiskmanager -r “Source Disk.vmdk” -t 0 “Target Disk.vmdk”
So I ran through that process on a VM I am uploading now. Will it be operational if not Thin provisioned? I was able to run the VM from Workstation after the process and after putting the what I thought was the thin provisioned disk file in place.
I know, another blog or other site. I just realized today, after days of struggle that I should check for and use the VMWare forums.
So, maybe I should start from the top again.
I have three VMs I want to get operational on our ESXi server. I can delete what I have and upload again if needed. The way I was doing that was to connect to the ESXi server from VMWare Workstation and simply drag and drop the VMs I wanted to upload. It took a while, but they were operational.
It would be nice if I could Thin provision them once there and also maybe shrink the disks. For example, one might be Thick provisioned at 200 GB and, if "easy", I would like to cut that down to 150 GB max. The shrinking is not crucial at this point and really neither is the provisioning, but I would like to get that finished.
And I've learned my lesson. With the quick responses, its much better to use the forums!!
>> Converting VMware Workstation Thick Disks (VMDKs) to Thin
The amount of misguiding tutorials that is available in the internet is really frightening !!!
For the record:
ESXi and Workstation use completely different approaches to create space-efficient VMDKs.
ESXi uses a special feature of the VMFS filesystem. This feature links unused areas of the VMDK-file to /dev/zero.
It waits until a certain area is requested for write from the guestOS. Only then it actually writes that area to disk and removes the reference to /dev/zero.
The information wether a block of the VMDK references a fragment on disk or links to /dev/zero is not visible when you analyse the vmdk-file.
Workstation on the other hand does not rely on the filesystem.
Instead it uses an area at the beginning of the VMDK to keep an inventar of all the blocks that the guestOS has written to.
If you analyse a Workstation VMDK of the "growable" type you will see that the VMDK itself contains the additional information for the inventory of used blocks.
The effect of this two different ways is that this "space-efficient" VMDK formats are NOT compatible.
Because of this incompatibilty it is very misguiding to use the terms THICK and THIN for Workstation.
The more correct term for the WS "space-efficient" format is "SPARSE"
Workstation has one format that is "almost" compatible with ESXi and that is the VMDK-type "monolithicFlat"
This type is equivalent to the ESXi VMDK-type "VMFS" - it only uses a different descriptor-file.
Anyway - dont use Workstation for any VMDK-operations on ESXi.
When you say...
"Anyway - dont use Workstation for any VMDK-operations on ESXi."
..., do you mean that it is not a good idea to copy VMs created by Workstation onto the ESXi server and use them, or are you referring to conversion type actions? The VMs I have uploaded to the ESXi server via drag and drop after connecting to the server in Workstation seem to be working OK (though they may not be streamlined or efficient).
I really think my IT department should be handling this, but I guess they don't have a problem with me struggling with this.
Don't copy the files directly, workstation has a built in function to move vms to esxi, or you export it to ovf and import it. Just don't take a workstation vmdk and attach it to a esxi vmdk and expect it to do things.