incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Animesh Chaturvedi (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-529) VM deployment re-design on VMware
Date Mon, 25 Feb 2013 14:52:14 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Animesh Chaturvedi updated CLOUDSTACK-529:
------------------------------------------

    Assignee: Venkata Siva Vijayendra Bhamidipati
    
> VM deployment re-design on VMware
> ---------------------------------
>
>                 Key: CLOUDSTACK-529
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-529
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: VMware
>    Affects Versions: 4.0.0
>         Environment: CentOS + vSphere 4.1/5.1
>            Reporter: Tamas Monos
>            Assignee: Venkata Siva Vijayendra Bhamidipati
>            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

Mime
View raw message