Ask Your Question

Icehouse: How to boot a snapshot from a running instance

asked 2014-07-16 10:54:39 -0600

Michael Steffens gravatar image

updated 2014-07-23 10:29:20 -0600

Update 3: Again the question needs to be rephrased a little. It turns out that my "unbootable" snapshots in QCOW2 format do boot easily, just not inside nova. In fact, if I run

sudo virt-install --connect qemu:///system --name *SomeName* --ram=1024 --disk path=*snapshotname.qcow2*,format=qcow2 --import --virt-type kvm --graphics vnc

the VNC window pops up with the OS booting like a charm, using the very same image file snapshotname.qcow2, that nova refuses to recognize as a bootable disk. On the other hand, omitting the format=qcow2 spec for the image file reproduces the boot failure, which is line with virt-install's documentation. Quoting the man page:


Image format to be used if creating managed storage. For file volumes, this can be 'raw', 'qcow2', 'vmdk', etc. See format types in for possible values. This is often mapped to the driver_type value as well.

With libvirt 0.8.3 and later, this option should be specified if reusing an existing disk image, since libvirt does not autodetect storage format as it is a potential security issue. For example, if reusing an existing qcow2 image, you will want to specify format=qcow2, otherwise the hypervisor may not be able to read your disk image.

My libvirt version is 1.2.2. What is the difference in nova boot an image to virt-install doing it? Does anyone else also see this issue?

Update 2: The issue seems to be unrelated to image down- or uploading, except for the partial workaround described below. But I can also reproduce this issue by attempting to launch snapshot directly after creation from the running instance. Rephrasing the question title accordingly. Any ideas?

I'm trying to create a qcow2 disk image file from a snapshot, that can be used to create a bootable image in OpenStack again:

  1. Created an image from stock trusty-server-cloudimg-amd64-disk1.img.

  2. The file command identifies the format as "QEMU QCOW Image (v2), 2361393152 bytes"

  3. Booted instance (succcessful)

  4. Logged in and performed additional installation/configuration (successful: instance still running, reboots succesfully)

  5. Shut down instance

  6. Create snapshot

  7. Download snapshot using glance image-download *snapname* --file *snapname.qcow2* --progress

The resulting file is now identified as "QEMU QCOW Image (unknown version)" without any size information. Consequently, after reimporting the file using

glance image-create --name *newname* --file *snapname.qcow2* --disk-format qcow2 --container-format bare --is-public True --progress

the new image's instance doesn't boot. On startup the instance complains "Boot failed: not a bootable disk".

I can, however, mount and browse the image file with guestmount command. It also has the expected size and is populated with the expected contents. It just seems to have lost its boot flag!

Is the procedure described supposed to work? What is the exact difference between the original and my downloaded file? And finally, how do do I get an image file that can boot?

Additional observation:

  • it doesn't make a difference whether the instance if running or shut down when the snaphot ...

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2014-07-31 04:43:43 -0600

Michael Steffens gravatar image

updated 2014-07-31 04:45:17 -0600

It's a race condition triggered when nova converts base images after download from glance: See bug #1350766

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2014-07-16 10:54:39 -0600

Seen: 564 times

Last updated: Jul 31 '14