Tamas Monos created CLOUDSTACK-529:
--------------------------------------
Summary: VM deployment re-design on VMware
Key: CLOUDSTACK-529
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-529
Project: CloudStack
Issue Type: Improvement
Components: VMware
Affects Versions: 4.0.0
Environment: CentOS + vSphere 4.1/5.1
Reporter: Tamas Monos
Priority: Critical
Hi,
The current mechanism to deploy VMs from templates has its weaknesses:
- The linked-on-clone way always requires the original template files/vmdisk to
exist on the primary/seconary storage as it is missing (updated template
replaced the old one) all VMs were built from an old template will fail to
start forever.
- Expensive primary storage is used to storage linked-in-clone disks, and
cannot be cleaned up efficiently.
- Clean-up scripts for storage clean-up is potentially dangerous and capable to
self-destruction in case of reference errors (happened on my sandbox platform).
The optimal way would be in my eyes:
- Deploy the OVF template directly from the mounted secondary nfs storage.
- No snapshots, no dependency, all VMs must be independent so if there is any
problem its impact is small/local.
- CloudStack should not be worried about "storage efficiency", that is up for
the storage backend.
Many could say linked-in-clones are good because reduces the primary storage
usage.
It might help in some scenarios, but introduces unnecessary complexity,
maintenance overhead and could actually lead to performance degradation (dozens
of VMs accessing the same template disks, race for locking) and inefficient in
terms of template storage. I need to storage all previous and current templates
on which VMs are relying on.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
