Open Stack

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 at 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/