Versions Compared

Old Version 9

changes.mady.by.user Sateesh Chodapuneedi

Saved on

compared with

New Version Current

changes.mady.by.user Nitin Kumar Maharana

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Jira
serverASF JIRA
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId5aa69414-a9e9-3523-82ec-879b028fb15b
keyCLOUDSTACK-8676

 

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

...

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

...

  • 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

Error handling

  • Ensure resource usage (storage capacity) in primary storage is calculated correctly.

Error handling

  • In case VM deployment 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.

Audit Events

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

...

  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. prepareTemplate– Existing API will be updated

  4. seedTemplateFromVmSnapshot– New API introduced
    1. Parameters –
      1. zoneid - UUID of zone
        1. Required
      Adding 1 new optional parameter – vmsnapshotid
      2. vmsnapshotid - UUID of the VM snapshot from which the template would be created from.
        1. This parameter would be mutually exclusive with the existing parameter ‘templateid’
        2. Usage - &vmsnapshotid=<vmsnapshot-uuid>
        Modifying the existing parameter templateid from required to optional
    2. createVolume -  Existing API will be updated
          1. Required
        2. storageid - UUID of primary storage pool where the template need to be seeded onto.
          1. Required
        3. Usage - &vmsnapshotid=<vmsnapshot-uuid>&zoneid=<zone-uuid>&storageid=<primary-storage-uuid>

    3. createVolumeFromVmSnapshot -  New API will be introduced. In class that implements this API inherits CreateVolumeCmd class due to the functional overlap. Hence all required parameters of createVolume API would required for this API too. Following are the parameters specific to this API and doesn't belong to createVolume API.
      1. Parameters – vmsnapshotid, volumeId.
      2. 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. Required parameter
          5. 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 Required parameter
          3. Usage - &volumeId=<volume-uuid>
      3. Size of new volume would be same as that of the volume specified by <volumeid>

    DB Changes

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

    ...

     

    ...

    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

    ...

    No Format
    +----------------+---------------------+------+-----+---------+----------------+
| Field          | Type                | Null | Key | Default | Extra          |
+----------------+---------------------+------+-----+---------+----------------+
| id             | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| uuid           | varchar(40)         | YES  |     | NULL    |                |
| pool_id        | bigint(20) unsigned | NO   | MUL | NULL    |                |
| vm_snapshot_id | bigint(20) unsigned | NO   | MUL | NULL    |                |
| created        | datetime            | NO   |     | NULL    |                |
| job_id         | varchar(255)        | YES  |     | NULL    |                |
| state          | varchar(255)        | YES  |     | NULL    |                |
| status         | varchar(255)        | YES  |     | NULL    |                |
| install_path   | varchar(255)        | YES  |     | NULL    |                |
| template_size  | bigint(20) unsigned | NO   |     | NULL    |                |
| marked_for_gc  | tinyint(1) unsigned | NO   |     | 0       |                |
+----------------+---------------------+------+-----+---------+----------------+

    Hypervisors supported

    VMware ESXi 5.0 and above.

    ...

    • 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