Reference

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Volume+snapshot+enhancements+for+VMware

Feature Specification

Current volume snapshot operation flow is described as below

• CreateSnapshot API command is issued from end-user/third-party API call
• Snapshot Manager starts and orchestrates the operation execution flow
• Snapshot management commands (ManageSnapshotCommand/BackupSnapshotCommand) are sent to VmwareResource resource instance
• VmwareGuru filters snapshot commands, it help locate an available secondary storage VM instance and performs command redirection to offload snapshot operation task to a chosen secondary storage VM. Snapshot workload load-rebalancing is taken at this step.
• VmwareStorageManagerImpl (this is running inside a secondary storage VM) finally carries on the operation with vCenter/ESX host
  • It first take a VM snapshot on the VM that the volume is attached to
  • After VM snapshot has been taken, it will analyze the composition of the VM snapshot, retrieve the disk chain information of the subject volume and creates a worker VM based on the disk chain.
  • By using vCenter API, it exports the disk content (full-copy) into the mounted NFS share in the secondary storage VM. Disk content includes .OVF and .VMDK files
  • It finally package disk content (.OVF file and .VMDK file) into OVA file format
• Complete the snapshot operation

In the above work flow, exporting volume content into mounted NFS share and packaging it into OVA are very time consuming operations, there are two ways to speed up the process

• Perform delta backup, reduce the amount of data that needs to be copied into secondary storage
• Remove OVA packaging step. Since packaging process contains reading and writing from the NFS mount, it doubles the amount of data that need to be moved around. By eliminating the step, it should improve current snapshot performance with relative small effort.
  Supporting deltal backup involves a big effort to work with VMware internal storage formats, this functional specification mainly discusses the improvement approach of removing OVA packaging step.

Design Description

API

There is no API change for this enhancement feature

Schema Change

This is no schema change for this enhancement feature

Internal storage format change

Internal storage format for snapshot, template and volume on Secondary storage will no longer be OVA. In stead of packing .OVF and .VMDK into .OVA file, CloudStack only stores OVA meta information into a property file. The property file will be named with postfix .ova.meta. Content of the property file includes meta information of .VMX and .VMDK files, stored there to help generate OVA for exporting or importing into vCenter. Following gives some example content of the property file

version=1 (meta file version)

ovf=xxx.ovf

numDisks=1

disk1.name=xxxx.vmdk

disk1.size=xxxxx

Affected Commands

Template Commands

CreateTemplateCmd

RegisterTemplateCmd

CopyTemplateCmd

DeleteTemplateCmd

ExtractTemplateCmd

Snapshot Commands

CreateSnapshotCmd

After the snapshot is create, in the snapshot directory on SEcondary Storage host, we will see the ovf and the vmdk files.
in dir: ~/Secondary/snapshots/2/13/
For example:
1 root root 68608 Apr 5 16:36 aa44054a-d099-4b9d-8fbf-211217381da0-disk0.vmdk
1 root root 3835 Apr 5 16:36 aa44054a-d099-4b9d-8fbf-211217381da0.ovf

In the previous scheme, we will see one ova file after the create snapshot command completes:
in dir ~Secondary/snapshots/2/7/,
ls:
1 root root 81920 Mar 27 15:18 db92a8e4-079f-4055-84f5-08d33f6f9fef.ova

DeleteSnapshotCmd

It will delete the snapshots related ovf, vmdk files for the new scheme. In the old scheme, it delets the ova file.

Volume Commands

CreateVolumeCmd

ExtractVolumeCmd

Of all these commands, it does not have any change to the semantics of the command, but to changes caused by changing of the underlying storage format.

Backwards compatibility

In a upgraded system, volume/snapshot/template on secondary storage are stored in OVA format, after customer system has been upgraded, in order to avoid unneccessary data conversion (which could be very slow and time consuming), we will support co-existence of both format. Therefore existing system could continue operating but all newly created templates/snapshot/volume will start to use the new storage format.

CloudStack can distinguish two different formats by checking the existence of .ova.meta file.

Test

 Suggest following but not limited use cases

• Snapshot test cases on a fresh system
• Volume test cases on a fresh system
• Template test cases on a fresh system
• Snapshot test cases on a upgraded system
• Volume test cases on a upgraded system
• Template test cases on a upgraded system