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
- 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
- Deletes the internal named snapshot from the qcow2 file.
- Finally, uploads that image into OpenStack glance service — which can be confirmed by running
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
# 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.