Description of problem: Creating an image (nova image-create) from a boot from volume instance generate 0 bytes images and seems to be a volume snapshot instead of an image in the ceph image pool. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Deploy an overcloud with ceph backend 2. Deploy a boot from volume image 3. Use nova image-create to create a snapshot Actual results: Creates a volume snapshot Expected results: Should create an image as expected Additional info: Note that we have a workaround for this: ~~~ openstack volume create --image bf9680bb-97ab-4f98-a83e-14fbb1e8466d --size 8 bootable_volume openstack server create --flavor m1.small --volume $VOLUME_ID --block-device source=volume,id=$VOLUME_ID,dest=volume,size=8,shutdown=preserve,bootindex=0 --nic net-id=0a8f4649-92a5-4bc5-adc4-d70cf9b32e76 myInstanceFromVolume nova image-create --poll myInstanceFromVolume myInstanceFromVolumeSnapshot cinder snapshot-list cinder create --snapshot-id 36aab00c-3a12-47fc-a319-ae34d52687b8 10 cinder upload-to-image cf3b2b9e-666c-4aea-804c-c396ec05f7a9 myInstanceFromVolumeSnapshotImage glance image-download --file test.raw d5c3cbed-d235-4d34-912c-f1411bf0e119 ~~~ But this is cumbersome. Ideally, no matter if this is ephemeral or volume boot, the image-create should create a downloadable image with a non-zero size.
Copying this info over from 1415338 David Hill 2017-01-23 12:00:43 EST They also have this issue with RHOSP 7.x and RHOSP 10.x. The behavior of a command should be the same regardless of the original boot type of a VM. They're expecting image-create to create an image and this is the main issue.
(In reply to Andreas Karis from comment #0) > ... > But this is cumbersome. Ideally, no matter if this is ephemeral or volume > boot, the image-create should create a downloadable image with a non-zero > size. Images, local disks and volumes are all different things. The lifecycle of a local disk is tied to an instance (i.e. it's ephemeral storage), whereas the lifecycle of a volume is independent of an instance (i.e. it's persistent). The 'nova image-create' command creates an image from the instance. As the instance 'contains' its ephemeral storage it's in the created image. However, neither the instance nor any resulting images 'contain' a remote volume - they just points to it. This is true for attached volumes whether they are bootable or not. Extending the 'nova image-create' command to support instances using bootable volumes would make no more sense than extending it to include the entirety of any remote volumes attached to the instance. Should you wish to snapshot a volume, this should be done inside cinder. This is because the volume is not part of the instance, meaning this operation is not an instance-related operation and not within the purview of nova. It does appear like you're doing something similar already. Alternatively, you could boot an instance from a image and use this command as expected. I'm going to mark this as NOTABUG as I don't feel there is any issue with the command, except a potential lack of clarity in the docs. Should you feel this is not the case, feel free to reopen the issue.
Hi, Thanks for the explanation. I updated https://access.redhat.com/solutions/2885001 with your comment, thus we have documentation for this at least in form of a KCS entry. Regards, Andreas
WONTFIX/NOTABUG therefore QE Won't automate
Hi, Thanks for the explanation, it really shed the light on what's going on with the same situation in my infrastructure. Although, I have another problem: how do I download the resulting snapshot? I don't see such options neither in horizon's tab "Volume snapshots", or anywhere else(I've checked the command-line interface of cinder also). And all openstack documentation suggests to convert the snapshot to glance image and download the image. But since we already know that size of that image will be 0, this method doesn't apply. Could you please clarify the download of a snapshot in this case? Thanks!
*** Bug 2170857 has been marked as a duplicate of this bug. ***