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.
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