Yes, absolutely. That is what thin provisioning is all about!
If you are using thin provisioning, you need to have a contingency plan in place to purchase and add more storage when your overall utilization passes a pre-determined threshold (e.g. 80%), and you need to have a monitoring system in place to ensure that you don't miss the moment. You also need to be sure that you are protected against situations wherein a single VM could begin to consume disk space explosively (e.g. Exchange or MSSQL transaction logs). For example, if you've decided that your threshold for buying more storage is 200GB of free space in your thin provisioned storage pool, it would be beyond foolish to thin provision >=200GB of extra space on any virtual server drive, even if you currently have terabytes of free space available.
If the above is too much for your organization (e.g., perhaps you cannot be entirely confident that an acquisition of additional storage would be approved when it is needed), then thin provisioning may not be an appropriate choice.
If you have already thin provisioned more space than you actually have, the first step to "undo" thin provisioning would be to reduce the sizes of the allocated partitions within the virtual disks such that, collectively, their sizes no longer exceed your physical storage limits. Then you would be able to convert to fixed-size virtual disks.
Note that converting to a fixed-size virtual disk is both time-consuming and potentially unnecessary: even if the virtual disks themselves are still technically thin provisioned in VMware, the VMs will never use unpartitioned space. For example, if you thin provisioned a 100GB virtual disk for a virtual machine that is only using 20GB of a 100GB partition, you could shrink the allocated partition within the virtual disk to 30GB. Under no circumstances would the VM use more than 30GB: the VM will still think it has a larger disk, but the unallocated space will never be used.
My setup is somewhat similar and works well. Virt-manager makes it really easy (even over ssh X forwarding it works well). Some random thoughts:
I would use LVM + virtio (perhaps except for the very large volumes; there appears to be a "1TB problem" with virtio) in this scenario. You can put the IO-intensive vm's volume on the fastest part of the sata raid.
Swap: unless you know exactly why you probably don't need 12GB at all.
On the small systems I would recommend splitting off the data volume from the system volume. You'll probably be using ~4 out of 8GB for system files leaving only 4GB for those "oops" moments. Systems behave a lot better when their root volume isn't full.
What kind of raid are you using? DM-softraid or some battery-backed hardware controller?
Putting the system files on a SSD will give you nice bootup times but not much after that. Putting data files (esp seek intensive stuff) on the SSD will give you intense joy for a very long time.
Afaik there is still some gain to be had if you do not fill up your SSD's all the way, leaving 20% unused (never written to) is easy with LVM, just make a volume for it.
As with any hardware rebuild I urge to use ECC memory.
Best Answer
Thin provisioned disks cannot be shrunk; once you've allocated all the blocks, that's it.
Also, unless you do a Quick Format, Windows will actually fill the entire thin provisioned disk.
There may also be a performance penalty, but that I'm not 100% certain of and is something that should be tested out; I know that was the case with some host-based hypervisors.