Reinforcement with Native Server Snapshot

Registered by Vincent Hou on 2014-02-26

Background:
Nova has implemented many drivers for different hypervisors, each of which may have its native feature to create the snapshot and revert/restore the snapshot. For example, Xen, VMware vSphere hypervisor, etc. Currently, creating a snapshot in Nova means to create a image with a full clone of the VM and upload it to Glance.

Objective:
This blueprint to about to bring this native feature for snapshot to Nova, providing both of the API and the driver implementation. The snapshot is created and reverted in the hypervisor environment only without connecting to Glance.

Benefits:
• Making snapshot creation and restore fast and convenient. Taking a native snapshot and launching a VM from the native snapshot will be much faster than creating an image and launching from this image in Nova.
• Making live snapshot possible, because some of the hypervisors have taken live snapshot into account in their native snapshot facility by snapshotting the memory and processor state. This blueprint is not 100% equal to live snapshot(https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms), but live snapshot can be one use case.
• Users with an existing environment for a certain hypervisor, can smoothly transfer to OpenStack environment, since this native feature has been triggered on in OpenStack.

Implementation:
The implementation consists of two parts, one is the extension for Nova API and the other is the feature implementation for each driver.

The Nova API can be implemented via the extension, the following API may be added:
• CreateSnapshot: create a snapshot from the VM. The snapshot can be live snapshot or other hypervisor native way to create a snapshot.
• RestoreFromSnapshot: restore/revert the VM from a snapshot.
• DeleteSnapshot: delete a snapshot.
• ListSnapshot: list all the snapshots or list all the snapshots if a VM id is given.
• SpawnFromSnapshot: spawn a new VM from an existing snapshot, which is the live snapshot or the snapshot of other snapshot created in a hypervisor native way.

Feature implementation for the driver:
Each hypervisor driver will take care of its implementation for the native snapshot support.

The features in this blueprint can be optional for any drivers. If a driver does not have a "native way" to do live snapshot or other kind of snapshots, it is fine to leave the API not implemented; if a driver can provide the "native feature" to do snapshot, it is an opportunity to reinforce Nova with this snapshot support.

Welcome to put your comments here: https://etherpad.openstack.org/p/live-snapshot

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Vincent Hou
Direction:
Needs approval
Assignee:
Vincent Hou
Definition:
Drafting
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

--- Qin Zhao ---
To my understanding, QEMU snapshot should be similar to VMware snapshot. It can also generate in-place snapshot in qcow2 file, and let the VM revert to a certain snapshot. However, the existing 'snapshot' defined by Nova seems to be a individual image to spawn new VMs.

My point is to define a new 'in-place snapshot' terminology for Nova, which is associate with the running VM, and will only be used to revert this VM to a certain state.

So personally I do not like 'driver-specific' behavior. I think usually users will hope Nova have unified model and behavior to manage all VMs. If we need any specific behavior, we can define parameters to request that, and driver can return 'Unsupported' if it can not do that.
--- Qin Zhao ---

--- Shawn Hartsock ---
My short answer is: perhaps we should instead introduce an idea in Nova of a "backup" of an instance?

This is an interesting question in general, how do we acknowledge underlying system's differences in capabilities yet at the same time preserve abstractions. We could preserve the existing snapshot abstractions in Nova and simply implement the snapshot behavior differently in the vmware drivers.

== from documentation ==
Our VMware API allows VMware and third-party products to perform operations with virtual machines and their snapshots. This is a list of common operations that can be performed on virtual machines and snapshots using our API:

CreateSnapshot: Creates a new snapshot of a virtual machine. As a side effect, this updates the current snapshot.
RemoveSnapshot: Removes a snapshot and deletes any associated storage.
RemoveAllSnapshots: Remove all snapshots associated with a virtual machine. If a virtual machine does not have any snapshots, then this operation simply returns successfully.
RevertToSnapshot: Changes the execution state of a virtual machine to the state of this snapshot. This is equivalent to the Go To option under the Snapshot Manager while using vSphere/VI client GUI.
Consolidate: Merges the hierarchy of redo logs. This is available in vSphere 5.0 and above.
== from documentation ==

The vSphere concept of a snapshot is simply *not* the same concept in Nova. The idea in Nova is that I might spawn any number of new VM from a snapshot taken at a point in time. The vSphere concept of a snapshot is simply different... it's essentially a backup.

For reference:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180
http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.wssdk.apiref.doc/vim.VirtualMachine.html#createSnapshot
http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.wssdk.apiref.doc/vim.vm.Snapshot.html#revert

EDIT:
A thought just came to me. Here's one possible way you could preserve both the vSphere concept of a snapshot and Nova's concept of a snapshot.

Create a snapshot:
* create a vSphere snapshot of a VM, name it with a Nova friendly name

Revert to a snapshot:
* simply use a vSphere revert to the old snapshot... no magic required

Spawn from a snapshot:
* lookup the appropriate snapshot by UUID and name
* use ExportSnapshot to obtain the URLs for the snapshot vmdk
* copy the snapshot's VMDK to create the new VM

--- Shawn Hartsock ---

--- Qin Zhao ---
I feel the major difference between this blueprint and existing snapshot/backup is that this blueprint is requesting NOT to create an image and NOT to create a new instance either.

If we hope to implement it, I think at least we need to define a new resource model in Nova to represent this new type of 'snapshot'. If we do that this way, it will be hard to limit its scope within VMware driver. It should become a cross-hypervisor design.

If we think that creating an image and creating a new instance will be always fine, I think we may not need to do anything for this blueprint. Once Glance can remotely manage VCenter as its image repository, the user will be able to snapshot VMs and create new VMs easily.
--- Qin Zhao ---

--- Vincent Hou ---
I guess we can start from the easy use cases. At first, we can implement CreateSnapshot, RemoveSnapshot, RevertToSnapshot and ListSnapshotsForServer for vSphere.

In Nova, there can be two approaches. One is to bring in a new resource model for this "snapshot", and the other is to consider all the actions as the extension of the current server(instance). From the API's perspective, the blueprint live-snapshot(https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms) used to propose a new API to snapshot the memory and processor state. It could be a similar approach to implement the API via the nova API extension.
--- Vincent Hou ---

--- Qin Zhao ---
I create a pad to discuss the design
https://etherpad.openstack.org/p/live-snapshot
--- Qin Zhao

--- boh.ricky ---
I think it's more neat if we abstract a new resource model such as "server snapshot".
It's similar to the relationship between "volume" and "volume snapshot".
--- boh.ricky ------ Qin Zhao ---
To my understanding, QEMU snapshot should be similar to VMware snapshot. It can also generate in-place snapshot in qcow2 file, and let the VM revert to a certain snapshot. However, the existing 'snapshot' defined by Nova seems to be a individual image to spawn new VMs.

My point is to define a new 'in-place snapshot' terminology for Nova, which is associate with the running VM, and will only be used to revert this VM to a certain state.

So personally I do not like 'driver-specific' behavior. I think usually users will hope Nova have unified model and behavior to manage all VMs. If we need any specific behavior, we can define parameters to request that, and driver can return 'Unsupported' if it can not do that.
--- Qin Zhao ---

--- Shawn Hartsock ---
My short answer is: perhaps we should instead introduce an idea in Nova of a "backup" of an instance?

This is an interesting question in general, how do we acknowledge underlying system's differences in capabilities yet at the same time preserve abstractions. We could preserve the existing snapshot abstractions in Nova and simply implement the snapshot behavior differently in the vmware drivers.

== from documentation ==
Our VMware API allows VMware and third-party products to perform operations with virtual machines and their snapshots. This is a list of common operations that can be performed on virtual machines and snapshots using our API:

CreateSnapshot: Creates a new snapshot of a virtual machine. As a side effect, this updates the current snapshot.
RemoveSnapshot: Removes a snapshot and deletes any associated storage.
RemoveAllSnapshots: Remove all snapshots associated with a virtual machine. If a virtual machine does not have any snapshots, then this operation simply returns successfully.
RevertToSnapshot: Changes the execution state of a virtual machine to the state of this snapshot. This is equivalent to the Go To option under the Snapshot Manager while using vSphere/VI client GUI.
Consolidate: Merges the hierarchy of redo logs. This is available in vSphere 5.0 and above.
== from documentation ==

The vSphere concept of a snapshot is simply *not* the same concept in Nova. The idea in Nova is that I might spawn any number of new VM from a snapshot taken at a point in time. The vSphere concept of a snapshot is simply different... it's essentially a backup.

For reference:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180
http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.wssdk.apiref.doc/vim.VirtualMachine.html#createSnapshot
http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.wssdk.apiref.doc/vim.vm.Snapshot.html#revert

EDIT:
A thought just came to me. Here's one possible way you could preserve both the vSphere concept of a snapshot and Nova's concept of a snapshot.

Create a snapshot:
* create a vSphere snapshot of a VM, name it with a Nova friendly name

Revert to a snapshot:
* simply use a vSphere revert to the old snapshot... no magic required

Spawn from a snapshot:
* lookup the appropriate snapshot by UUID and name
* use ExportSnapshot to obtain the URLs for the snapshot vmdk
* copy the snapshot's VMDK to create the new VM

--- Shawn Hartsock ---

--- Qin Zhao ---
I feel the major difference between this blueprint and existing snapshot/backup is that this blueprint is requesting NOT to create an image and NOT to create a new instance either.

If we hope to implement it, I think at least we need to define a new resource model in Nova to represent this new type of 'snapshot'. If we do that this way, it will be hard to limit its scope within VMware driver. It should become a cross-hypervisor design.

If we think that creating an image and creating a new instance will be always fine, I think we may not need to do anything for this blueprint. Once Glance can remotely manage VCenter as its image repository, the user will be able to snapshot VMs and create new VMs easily.
--- Qin Zhao ---

--- Vincent Hou ---
I guess we can start from the easy use cases. At first, we can implement CreateSnapshot, RemoveSnapshot, RevertToSnapshot and ListSnapshotsForServer for vSphere.

In Nova, there can be two approaches. One is to bring in a new resource model for this "snapshot", and the other is to consider all the actions as the extension of the current server(instance). From the API's perspective, the blueprint live-snapshot(https://blueprints.launchpad.net/nova/+spec/live-snapshot-vms) used to propose a new API to snapshot the memory and processor state. It could be a similar approach to implement the API via the nova API extension.
--- Vincent Hou ---

--- Qin Zhao ---
I create a pad to discuss the design
https://etherpad.openstack.org/p/live-snapshot
--- Qin Zhao

--- boh.ricky ---
I think it's more neat if we abstract a new resource model such as "server snapshot".
It's similar to the relationship between "volume" and "volume snapshot".
--- boh.ricky ---

If you are still working on this, please re-submit via nova-specs. If not, please mark as obsolete, and add a quick comment to describe why. --johnthetubaguy (20th April 2014)

Gerrit topic: https://review.openstack.org/#q,topic:bp/driver-specific-snapshot,n,z

Addressed by: https://review.openstack.org/84676
    Add live snapshot chance for drivers applicable to do live snapshot

Addressed by: https://review.openstack.org/85243
    Do not review this patch

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.