Page History

...

Branch

master

Document History

Glossary

• Snapshot - VM snapshot
  
• Original VM - The user instance whose snapshot is being used to deploy a new user instance

Feature

...

specification

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
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.

...

• CloudStack Users and Admins.

Use case

1. Allow user to quickly deploy user instance directly from snapshot

Design description

1. Existing workflow for user instance deployment, deployment planning and resource allocation will be leveraged while deploying instance from snapshot.
2. Instance creation (resource creation in Apache CloudStack DB)
   1. Additional validations will be made if a VM is being deployed from a snapshot.
      1. Apache CloudStack will check if the compute offering specified by the user is valid. For e.g. Apache CloudStack will validate if the number of CPUs mentioned in the compute offering matches the number of virtual CPUs present in the original VM.
      2. These validations will be done by comparing various configurations of the original VM with the properties in the user specified compute offering.
      3. GetVmSnapshotConfigs - A new agent command will be introduced to retrieve configuration details of the original VM at the time the snapshot was taken from the hypervisor.
   2. Below volume operations continue to be blocked on VMs that have VM snapshots associated with them -
      

      1. Attach volume

      2. Detach volume

      3. Resize volume

   3. Choosing service/compute offering is mandatory while deploying user instance from snapshot.
3. Instance start (resource creation on hypervisor)
4. 1. Instance will be created on the hypervisor by cloning the original VM and the clone will be based off the snapshot point.
   2. There are two ways in which this can be achieved
      Option 1
      1. When the first instance is being deployed from a snapshot, the snapshot will be full cloned into the primary storage that contains the snapshot. Then the instance will be created by link cloning from this copy. Every instance that is deployed after the first deployment will simply be link cloned from the full clone copy.
      2. This workflow is similar to the existing work flow of instance deployment from a template. In case of instance deployment from template, the base template is created and stored in primary storage. And every instance would be deployed by full or fast clone (based on global configuration setting 'vmware.create.full.clone') of the template copy in primary storage.
      3. This will ensure that VM deployments are quick and that the snapshot chain doesn't grow too long causing any inconsistencies or low performance.
      Option 2
      1. Every time a VM is deployed from a VM snapshot a linked clones will created directly from the VM snapshot. 
      2. Though this will ensure quick VM deployments, it is error prone as the disk chain could grow too long and potentially lead to corruption of several VMs upon failures. 
   3. Specifications for the cloning operation
      1. CloudStack will specify the exact host and datastore(s) to the clone the VM into. This will be based on the host and storage(s) chosen by the deployment planner.
      2. CloudStack will specify the NICs to be added and removed. This is based on the network(s) chosen by the user to deploy the VM in. This is needed because by default when a VM is cloned, all the NICS on the original VM are created on the new VM.
5. After user instance is deployed from snapshot, there would not be any relation between instance and the snapshot used to create the instance
6. If primary storage runs out of space, the instance deployment would be failed.
7. Modify createVolume API implementation to support VM snapshot as source in addition to the 2 currently supported sources disk offering and volume snapshot. Volume would be created on same primary storage as that of the volume specified in VM snapshot.
8. Modify prepareTemplate API implementation to support seeding template from VM snapshot.

Limitations

• VM can only be deployed on the host that can access the primary storage pool that contains the VM snapshot (VM snapshot will reside with the original VM). If there is not enough capacity i.e. if no host that can access this storage pool has sufficient resources (memory, CPU etc.) then Apache CloudStack will fail the deployment.
• Existing Apache CloudStack limitation will continue, below volume operations will continue to be blocked on VMs that have VM snapshots associated with them. Please refer the design section for more details.

  • Attach volume

  • Detach volume

  • Resize volume

API Changes

1. Existing API deployVirtualMachine will be updated
   1. Adding 1 new optional parameter – vmsnapshotid
      1. vmsnapshotid - UUID of the VM snapshot that the VM has to be deployed from.
      2. This parameter would be mutually exclusive with the existing parameter ‘templateid’
      3. Usage - &vmsnapshotid=<vmsnapshot-uuid>
   2. Modifying the existing parameter templateid from required to optional
      
      
2. prepareTemplate– Existing API will be updated
1. Adding 1 new optional parameter – vmsnapshotid
   1. vmsnapshotid - UUID of the VM snapshot from which the template would be created from.
   2. This parameter would be mutually exclusive with the existing parameter ‘templateid’
   3. Usage - &vmsnapshotid=<vmsnapshot-uuid>
2. Modifying the existing parameter templateid from required to optional
   
   
3. createVolume -  Existing API will be updated
1. Adding 2 new optional parameters – vmsnapshotid, volumeId.
1. vmsnapshotid
1. UUID of the VM snapshot from which the volume should be extracted and created from.
2. This parameter would be used along with volumeId parameter.
3. This parameter would be mutually exclusive with diskofferingid, snapshotid
4. Usage - &vmsnapshotid=<vmsnapshot-uuid>
2. volumeId
1. UUID of the volume from which (content of) new volume would be created so that content of volume would be identical to that of the volume from snapshot specified by vmsnapshotid.
2. This parameter would be used along with vmsnapshotid parameter
3. Usage - &volumeId=<volume-uuid>
2. Size of new volume would be same as that of the volume specified by <volumeid>

DB Changes

vmsnapshot_spool_ref (id, pool_id, vm_snapshot_id, created, install_path, state) -  This table will contain the mapping between a VM snapshot and the primary storage it is on.

...