Does anyone know if there is an optional method of accounting for data store usage in vCD? Currently, the system includes all of the VMDK (virtual drives) and the VM's overhead files of swap, VMX, snapshots, etc. As a service provider customers pay for storage that they can actually use, such as a Windows C:\ drive that is 60GB. Currently we must over allocated the storage selected by a customer that covers all of their storage requirements plus about 2 GB per VM and amount of total vRAM. I can't just give my provisioning team a general percent basis since vRAM comes into the equation so heavy. It would be much preferred if the storage utilization only included root VDMK files (the allocated virtual drives), customers need not know anything about snapshots and all of the other storage overhead.
Today it just is not a clean process with customer communication and packaging, they think we are giving them free storage so they use it and run out again and again. I also do not want to document and disclose that all deployed VMs have storage overhead that the customer must take into account. That looks and sounds like fine print and gothchas that customers hate. It should be simple, customer needs 1000GB of allocated storage, then they should be able to add as many VM virtual disks that they desire up to the full 1000GB allocation.
We have this same issue. To address we had to go PayGo model - and then handle by reporting not quota.
Depending on your model it can get complicated - do you want to charge 100GB for a VM that is thin provisioned at 5GB? Maybe, maybe not - but VCloud says yes.
We have thought about that as well, but not tried it! Happy to hear that someone else thought it was a useful method. Thin Provisioning is very dangerous with customer environments as you never know when they will all suddenly start using data. By default we rarely Thin Provision as we would need to reserve an X % of allocated just as a basic safety measure. The risk isn't worth it as we were burned once in a customer production environment.