You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Introduction

Currently in Apache CloudStack, a user can only deploy a VM from templates or ISOs but not directly from VM snapshots. To deploy a VM off another VM at a given point in time, today a CloudStack user needs to take a snapshot of the original VM’s volume at that point in time, create a template from the snapshot backup of the volume and then deploy a VM from the template. This work flow is tedious and time consuming as it involves multiple data transfers over network,

  1. From primary storage to secondary storage to export snapshot as template over to secondary storage.
  2. From secondary storage to primary storage to download the template to seed the template for further instance deployment over that primary storage.

This document describes a feature that will be introduced to ease the above process by providing users with the ability to deploy VMs directly from VM snapshots residing on the primary storage.

Purpose

This is the functional specification for feature ‘Deploy VM from VM Snapshot’.

References

JIRA Ticket

Unable to render Jira issues macro, execution error.

Branch

Targeted for ACS master

Currently feature is under development at github branch - https://github.com/sateesh-chodapuneedi/cloudstack/tree/deploy-from-snapshot

 

Document History

Author

Description

Date

Deploy instance from VM snapshotInitial draft of feature specification, design24 July 2015

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. Only root volume would be created while deploying instance from snapshot, and data volumes would be ignored, if any are present for user instance associated with the specified snapshot.
    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.
  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 behaviour 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.

Test guidelines

  • User instance deployed from a snapshot should have root disk identical (content-wise) to that in original VM
  • If the primary storage pool already has template seeded from snapshot using 'prepareTemplate' API, then time to deploy instance from that snapshot would be consistent. That means 1st deployment of user instance would be same as that of 2nd, 3rd,... nth deployment.
  • Ability to choose guest networks while deploying user instance for snapshot
  • Ability to choose compute offering while deploying user instance for snapshot
  • Ensure resource usage (storage capacity) in primary storage is calculated correctly.

Error handling

  • In case VM deployment from VM snapshot fails at any stage during the deployment,
    • The VM should be moved to ‘ERROR’ state
    • UI and management server logs should clearly indicate the reason for the failure
    • Cleanup process of the VM and all its resources should be identical to the cleanup of any VM in ‘ERROR’ state.
  • In case of volume creation from snapshot
    • New volume should be moved to 'ERROR' state in case of failure to create volume, and subsequently should be cleaned up by StorageScavenger thread as part of storage gc.
    • UI and management server logs should clearly indicate the reason for the failure, whether insufficient space to create volume on primary storage OR some other vCenter API error OR runtime faults etc.
  • In case the APIs meant for creating volume from vm snapshot & seeding the template from vm snapshot, called in hypervisors other than VMware, CCP throws exception with message saying that the operation is not supported in hypervisors other than VMware. 

Audit Events

  • Events will be generated in the management server logs for any resource (for e.g. VM, volume, NIC) being created during the course of the deployment.
  • vCenter tasks involved during a VM deployment – Clone virtual machine, Reconfigure virtual machine, Power On virtual machine etc.

Target users

  • 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)
    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. createVolume API changes
    1. 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.
    2. As soon as deployment is complete, user instance would have only ROOT volume with it, and if data volumes are required for deployed instance, then admin/user would attach the volumes in the order required. While attaching data volumes, admin/user may want to attach the volumes in order similar to that in original VM, if admin/user is concerned about the disk/device ordering in the new user instance.
    3. Update the create volume code such that to create volume CCP creates full clone of the volume/vmdk specified by volume id, from snapshot image. Current volume creation code just creates empty volume.
  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

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’, which represents a template or iso
      3. Usage - &vmsnapshotid=<vmsnapshot-uuid>
    2. Modifying the existing parameter templateid from required to optional

  2. seedTemplateFromVmSnapshot– New API introduced
    1. Parameters –
      1. zoneid - UUID of zone
        1. Required
      2. vmsnapshotid - UUID of the VM snapshot from which the template would be created from.
        1. Required
      3. storageid - UUID of primary storage pool where the template need to be seeded onto.
        1. Required
      4. Usage - &vmsnapshotid=<vmsnapshot-uuid>&zoneid=<zone-uuid>&storageid=<primary-storage-uuid>

  3. createVolumeFromVmSnapshot -  New API will be introduced
    1. Parameters – vmsnapshotid, volumeId.
      1. vmsnapshotid
        1. UUID of the VM snapshot from which the volume should be extracted and created from.
        2. Required parameter
        3. 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. Required 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.

Field

Type

NULL

Key

Default

id

bigint(20) unsigned

NO

PRI

NULL

vm_snapshot_id

bigint(20) unsigned

NO

 

NULL

pool_id

bigint(20) unsigned

NO

 

NULL

createddatetimeYES NULL
install_pathvarchar(255)YES NULL
statevarchar(255)YES NULL

Hypervisors supported

VMware ESXi 5.0 and above.

UI Flow

  • Add a new option ‘Deploy VM from VM snapshot’ to the existing operations supported on VM snapshots.
    • Include it under, Instances --> Details --> View Snapshots --> VM Snapshot
    • When a user selects this option, the existing VM deployment workflow should be provided to the user. The same VM deployment widget without the first screen where a user needs to provides the zone and template.

Upgrade

  • Deployment of VM from VM snapshots will be available with a fresh deployment as well as an upgraded deployment.
  • In an upgraded deployment, VM deployment will be supported for VM snapshots created both before and after upgrade.

Open Items/Questions

  1. NA
  • No labels