Bug Reference

CLOUDSTACK-10066

Branch

masterMaster, patches will be submitted through to the review board.

Introduction

Purpose

...

Currently CloudStack supports VM snapshots for VMware. This feature will add the support for VM Snapshots in Hyper-V.

...

createVMSnapshot:

Common workflow

1. check Check authority, concurrency, existence...
2. allocate Allocate VM snapshot entry in DB.
3. transit vm and vmsnapshot Transit the VM and VM snapshot state to snapshotting/creating.
4. prepare Prepare TO object and CreateVMSnapshotCommand.
5. send command Send the command to the agent.
6. update Update DB, like current/parent fields or volume table, depending on CreateVMSnapshotAnswer and TO object.
7. transit vm and vmsnapshot stateTransit VM and VM snapshot state.

revertToVMSnapshot:

Common workflow

1. check Check authority, concurrency, existence.
2. call Call advanceStart or advanceStop first if revert will change vmVM's state; for example, when reverting a stopped VM to a DiskAndMemory snapshot, we will start this VM first and then revert it.
3. transit vm/ vmsnapshot Transit the VM and VM snapshot state to reverting.
4. prepare Prepare TO objects and send command.
5. update Update DB with information from Answer object.
6. Transit VM and VM snapshot state.transite vm/vmsnapshot state

deleteVMSnapshot:

Unlike VM expunging, VM snapshot deletion is designed as a sync operation, there is no daemon thread scanning and expunging them.

the implemention The implementation is fairly straightforward:

1. transit vmsnapshot Transit VM snapshot to expunging state.
2. prepare Prepare TO object and send command,.
3. update Update snapshots tree tree.
4. mark Mark as removed.

VMSnapshotSync:

1. Add vm VM snapshot sync to fullSync and fullHostSync.
2. It will check if there are is any vm VM snapshot in transient states.
3. Transient The transient state found during host connection usually means mgmt server restart/outrage, or hypervisor cluster down. Because mgmt server has no idea if those tasks succeed or not, it will re-send the command in question

...

Create one VM snapshot with snapshotMemory (on, off) when VM is (running, stopped)

Revert to the previous snapshot when VM is (running, stopped)

Create multiple VM snapshot with snapshotMemory snapshot memory (on, off, mixed) when VM is (running, stopped), the snapshots should form a tree hierarchy, such as:

...

Attach/detach a volume to a VM when this VM has VM snapshots.

Upgrade VM serviceOffering service offering when VM has snapshots with snapshotMemory snapshot memory (on, off)

take Volume Snapshot when associated VM has VM snapshots

...

1. Export VM when we are stopping the VM.
   
   Pros
   
   1.  In In this case we  , we have to perform the costly export operation only when it is needed(when we cannot avoid).
   2. VM snapshots will be fast as then it needs to keep only differential data.
      
      
   Cons
   1. The stop operation will get affected, which we can make asynchronous and export VM only when the VM snapshots has have been taken on that VM.
   2. What will be done if VM is started before the export operation has been completed?
   3. What will happen if primary goes down in middle of an export operation or export operation has not yet started?
      1. whenever host or primary comes up first export the VM then delete it, if it has snapshots
      2. What state of that VM will be returned in hostVMstatereport for vmsync?
         
         
2. Export VM at every snapshot
   
   Pros
   1. The probability of stop operation being affected will be low. Will only be affected when stop operation occurs in the process of exporting VM.
   
   Cons
   1. VM snapshots will be slow

...