Page History

...

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. This API creates new volume by extracting the specified volume from specified vm snapshot. As soon as user instance deployment is complete, if data volumes are required for deployed instance, then admin/user would attach the volumes in the order required.
8. Modify prepareTemplate API implementation to support seeding template from VM snapshot. This would improve the deployment speed of 1st user instance, as the seeded template just need to be fast cloned while deploying.

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

...