NOTE (05-OCT-2016): This post is outdated — the current code (in snapshot() and _live_snapshot() methods in libvirt/driver.py) for cold (where the guest is paused) snapshot & live snapshot has changed quite a bit. In short, they now use libvirt APIs managedSave(), for cold snapshot; and blockRebase(), for live snapshot.
I was trying to understand what kind of image nova image-create creates. It’s not entirely obvious from its help output, which says — Creates a new image by taking a snapshot of a running server. But what kind of snapshot? let’s figure.
nova image-create operations
The command is invoked as below
$ nova image-create fed18 "snap1-of-fed18" --poll
Drilling into nova’s source code — nova/virt/libvirt/driver.py — this is what image-create does:
- If the guest — based on which snapshot is to be taken — is running, nova calls libvirt’s
virsh managedsave, which saves and stops a running guest, to be restarted later from the saved state. - Next, it creates a qcow2 internal disk snapshot of the guest (now offline).
- Then, extracts the internal named snapshot from the qcow2 file & exports it to a RAW format and temporarily places in
$instances_path/snapshots. - Deletes the internal named snapshot from the qcow2 file.
- Finally, uploads that image into OpenStack glance service — which can be confirmed by running
glance image-list.
Update: Steps 2 and 4 above are now effectively removed with this upstream change.
A simple test
To get a bit more clarity, let’s try Nova’s actions on a single qocw2 disk — with a running Fedora 18 OS — using libvirt’s shell virsh and QEMU’s qemu-img:
# Save the state and stop a running guest $ virsh managedsave fed18 # Create a qemu internal snapshot $ qemu-img snapshot -c snap1 fed18.qcow2 # Get information about the disk $ qemu-img info fed18.qcow2 # Extract the internal snapshot, # convert it to raw and export it a file $ qemu-img convert -f qcow2 -O raw -s \ snap1 fed18.qcow2 snap1-fed18.img # Get information about the new image # extracted from the snapshot $ qemu-img info snap1-fed18.img # List out file sizes of the original # and the snapshot $ ls -lash fed18.qcow2 snap1-fed18.qcow2 # Delete the internal snapshot # from the original disk $ qemu-img snapshot -d snap1 fed18.qcow2 # Again, get information of the original disk $ qemu-img info fed18.qcow2 # Start the guest again $ virsh start fed18
Thanks to Nikola Dipanov for helping me on where to look.
Update: A few things I missed to mention (thanks again for comments from Nikola) — I was using libvirt, kvm as underlying hypervisor technologies, with OpenStack Folsom release.
Nice post!
Pingback: OpenStack Community Weekly Newsletter (Mar 8-22) » The OpenStack Blog
What the Folsom docs says: “In OpenStack, an instance snapshot is an image. The only difference between an image that you upload directly to glance and an image you create by snapshot is that an image created by snapshot has additional properties in the glance database.”
There’s no meaningful difference between the two, and it’s only the OpenStack dashboard that makes a distinction between between images and snaphots. Some guy submitted this issue as a UI bug [1] a while back, and it has been fixed [2] in the upcoming (havana) release of OpenStack.
[1] https://bugs.launchpad.net/horizon/+bug/1140760
[2] https://review.openstack.org/#/c/30064/
Just to note – Snapshots code in OpenStack has changed considerably since Folsom release.