Page History

...

1. Deployment of user instance from snapshot will be quicker than earlier work flow which includes exporting snapshot to secondary storage as template and importing template from secondary storage to deploy user instance in primary storage.
2. Support deployment of user instance from snapshot of existing user instance over VMware hypervisor
   
   1. Deployed instance must have the root volume identical (content-wise) to the root volume from snapshot.
   2. Deployed instance should be added to guest networks specified by the list of network offerings specified while deploying user instance
   3. Deployed instance must have the configuration as per the service/compute offering specified while deploying user instance
   4. Root volume of deployed instance must use the same primary storage pool as that of the counter-part in original VM.
   5. There is no restriction on the configuration of original VM, the user instance whose snapshot is used to deploy a user instance. For example orginal VM may have zero or more data volumes OR may be part of zero or more guest networks. Also it is possible for a user instance and its snapshot to span across one or more primary storage pools if user instance has more than 1 volume and the volumes spread across primary storage pools.
3. Snapshots of a user instance forms a hierarchy and users should be allowed to deploy user instance from any snapshot in that hierarchy.
4. Provide means to seed template in same primary storage pool from snapshot
5. Provide means to create volume from VM snapshot on same primary storage, from specified volume in original VM of the snapshot
6. While deploying a user instance from snapshot,
   1. Users will not be allowed to specify a zone, as current zone is assumed.
   2. Users will not be allowed to specify a template, as the snapshot image would be used as source instead of template.
   3. Users will be allowed to specify a host, provided the host has access to primary storage pool where the original VM resides.
   4. Users will be allowed to choose compute offering for customized compute configurations and guest networks
   5. CloudStack should ignore memory dump, if any, which is associated with the specified snapshot
   6. CloudStack considers all hosts that can access the primary storage pool where the snapshot resides
7. Post deployment, life cycle and behavior of a VM deployed from a snapshot will be the same as any other VM in the CloudStack cloud.
8. Deployed user instance inherits following properties of original VM
   1. disk_offering_id
   2. vm_template_id
   3. service_offering_id (unless a compute offering was specified by user while deploying this user instance)
9. All volumes of new user instance inherits disk_offering_id of respective volumes of original VM, except for volumes of type ROOT which is attached to original VM which was deployed from template. In case of such volumes disk_offering_id would be the compute offering chosen by user, if any, while deploying the user instance otherwise disk_offering_id of ROOT volume of original VM
10. Root volume of new user instance inherits template_id (if original VM was deployed from a template) or iso_id (if original VM was deployed from ISO) property from original VM. This establishes the point of restore in future.
11. What is not supported?
    1. Deploying multiple instances simultaneously from the snapshot
    2. Supporting storage migration of user instance while deploy VM from snapshot of that user instance is in progress
    3. Deploy instance from snapshot in primary storage other than where the snapshot is present
    4. Deploy instance along with all volumes from the snapshot.
    5. Data volumes will not be considered while creating/seeding template from snapshot
    6. Creating/seeding template from snapshot is not supported for primary storage pools other than primary storage pool of the snapshot.

...