Hi and sorry for the noise, I would like to add something to this thread. Apparently the 'disk_format' property of a glance image that was created as a snapshot of a volume based instance has a different impact than it has on instances created from regular glance images. To summarize (backend for nova, cinder and glance is ceph): 1. Creating an instance from a (regular) glance image with 'disk_format = qcow2' results in a flat nova instance with no parent data (as reported in [1]). 2. Creating a snapshot of a volume based nova instance unexpectedly results in a glance image with 'disk_format = qcow2'. Launching an instance from that snapshot does *not* result in a flat image as I would have expected because of 1. Instead the new instance is a cow-clone of the original volume, which in fact is expected because of ceph backend. So the workflow seems fine, but I find it very confusing (obviously) that the volume based snapshot is declared as a qcow2 image, that doesn't seem right to me. It would be great to hear your opinions on this topic, maybe I don't get the concept. But if my explanation makes sense it would be great to find a solution for this. Best regards, Eugen Zitat von Eugen Block <eblock@nde.ag>:

Hi all,

this still seems to be related to a thread I created last year [1]. There was a part left which I didn't understand and couldn't reproduce, now a colleague seems to have created an instance where I can reproduce the issue.

I also found [2] and [3] referring to this, both were marked as invalid, but this is not resolved IMO. I'll try to explain:

We have a volume backed instance, its base image was in raw format (all non-raw images were updated after I learned about the consequences):

# nova show output | image | Attempt to boot from volume - no image supplied | | os-extended-volumes:volumes_attached | [{"id": "ccca4607-3296-472b-a521-fdc3e76451a2"}] |

The respective volume has the following meta-data:

# cinder show output | volume_image_metadata | {'container_format': 'bare', 'min_ram': '0', 'disk_format': 'raw', 'image_name': '###_SLES12-SP3-JeOS', 'image_id': '9ed2b16e-c939-42e7-9e09-4a732caf2449', 'checksum': 'e3282f363c62194c1e4dea1bacccdda6', 'min_disk': '0', 'size': '1084227584'} |

I also double-checked the (exported) volume with qemu-img info that it's indeed a raw formatted volume. Now when I create a nova snapshot either with Horizon or the CLI it results in a qcow2 image:

control:~ # nova image-create d1d4e694-3920-47e6-8338-060015c4eb71 test-image

control1:~ # openstack image show 7de2fd37-1124-4382-9fb4-66fde8c92676 | grep disk_format | disk_format | qcow2

I changed 'snapshot_image_format' from '<None>' to 'raw' in nova.conf on both control and compute node, although nova states to use the source image's format:

# If set, this decides what format is used when sending the snapshot to the # image service. # If not set, defaults to same type as source image.

Obviously, this doesn't work as expected, so the question is which component is responsible for the qcow2 format? I couldn't find related cinder config options, could [2] be a valid bug report after all?

Thanks for any thoughts on this!

Regards, Eugen

[1] https://www.mail-archive.com/openstack@lists.openstack.org/msg20935.html [2] https://bugs.launchpad.net/nova/+bug/1332558 [3] https://ask.openstack.org/en/question/65451/snapshot-defaults-to-qcow2/