IMO the easiest way to achieve your goal is to convert V2V the VM again. Running a volume based conversion, you can configure the target partition sizes or - if you prefer - configure the VM to have 2 separate virtual disks.
A V2V is definitely an option. You can resize .vmdks and thin provision at the same time. I'm not quite sure I understand what you mean by "releasing the 700GB to the SAN." I can address, however, your thin provisioning question.
If you already have a thick provisioned VM, you can convert it to thin provisioning by performing a Storage vMotion. Normally, I'm not hesitant to svMotion VMs, but I am careful not to move around the large ones too often. I'm just worried about the svMotion failing, then having to recover. Plus, large VMs can take hours to svMotion. Then again, a V2V of large VMs can take just as long.
Of course, if you want to expand the size of your OS .vmdk, you can do so by editing the hard disk size in the VM's settings. You'll then need to expand the hard disk within the guest OS itself.
Hi and thanks for our answers.
We have a SAN, and what I ment by "releasing" disk space is that I want to resize/shrink the disk from, let's say, 800GB to 100GB. Then I guess 700GB will be available to the SAN again..? As far as I know you can't just resize a thick provision disk on a converted machine?
But the solution could be, as you both say, to do a V2V conversion.
The server is far from critical so if it crashes there are no worries. It's more testing in case I need to do it on a more critical server.
For the VM itself, a V2V is probably your best bet.
Your SAN won't necessarily "see" this free space. Remember, SANs aren't typically VM and filesystem aware (it's just a big disk), so it doesn't necessarily know that space has been freed up inside a VM or guest filesystem. This issue isn't a big deal if you don't thin provision your SAN volumes, but if you do, the SAN won't be able to see the free space. If you don't TP your SAN volumes, it doesn't matter.