Reference
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 .VMX and .VMDK files
- It finally package disk content (.VMX 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 for snapshot, template and volume on Secondary storage will no longer be OVA. In stead of packing .VMX 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)
vmx=xxx.vmx
numDisks=1
disk1.name=xxxx.vmdk
disk1.size=xxxxx
Affected Commands
Template Commands
CreateTemplateCmd
RegisterTemplateCmd
CopyTemplateCmd
DeleteTemplateCmd
ExtractTemplateCmd
Snapshot Commands
CreateSnapshotCmd
DeleteSnapshotCmd
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