Bug 1415422 - Creating an image (nova image-create) from a boot from volume instance generate 0 bytes images
Summary: Creating an image (nova image-create) from a boot from volume instance genera...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Eoghan Glynn
QA Contact: Joe H. Rahme
URL:
Whiteboard:
: 2170857 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-21 20:58 UTC by Andreas Karis
Modified: 2024-03-25 14:58 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-27 17:00:23 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-25776 0 None None None 2023-06-13 17:04:22 UTC
Red Hat Knowledge Base (Solution) 2885001 0 None None None 2023-06-13 17:04:59 UTC
Red Hat Knowledge Base (Solution) 3831741 0 None None None 2023-06-13 16:59:48 UTC

Description Andreas Karis 2017-01-21 20:58:53 UTC
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.

Comment 1 Andreas Karis 2017-01-23 17:04:36 UTC
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.

Comment 2 Stephen Finucane 2017-01-27 16:46:43 UTC
(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.

Comment 3 Andreas Karis 2017-01-30 15:27:17 UTC
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

Comment 4 awaugama 2017-08-30 17:55:34 UTC
WONTFIX/NOTABUG therefore QE Won't automate

Comment 5 masha.atakova 2017-09-21 10:50:20 UTC
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!

Comment 6 Radomir Dopieralski 2023-06-14 07:35:07 UTC
*** Bug 2170857 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.