how to remove image with still used volumes

Christoph Anton Mitterer calestyo at scientia.org
Tue Nov 8 03:15:43 UTC 2022


Hey Erik.

On Mon, 2022-11-07 at 22:01 -0500, Erik McCormick wrote:
> Instance disks are changes over time from a baseline. What this means
> is, you can't delete the origin without destroying all of its
> descendants.

But isn't that quite inefficient? If one never re-installs the images
but only upgrades them over many years, any shared extents will be long
gone and one just keeps the old copy of the original image around for
no good.

[The whole concept of images doesn't really fit my workflow, TBH. I
simply have a number of existing systems I'd like to move into
openstack... they already are installed and I'd just like to copy the
raw image (of them) into a storage volume for instance - without any
(OpenStack) images, especially as I'd have then one such (OpenStack)
image for each server I want to move.]


I even tried to circumvent this, attach a empty volume, copy the OS
from the original volume to that and trying to remove the latter.
But openstack won't let me for obscure reasons.



Next I tried to simply use the copied-volume (which is then not based
on an image) and create a new instance with that.
While that works, the new instance then no longer boots via UEFI.


Which is also a weird thing, I don't understand in OpenStack:
Whether a VM boots from BIOS or UEFI, should be completely independent
of any storage (volumes or images), however:

Only(!) when I set --property hw_firmware_type=uefi while I create a
image (and a volume/instance from that) the instance actually boots
UEFI.
When I set the same on either the server or the volume (when the image
wasn't created so - or, as above, when no image was used at all)... it
simply seems to ignore this and always uses SeaBIOS.

I think I've experienced the same when I set the the hw_disk_bus to
something else (like sata).


Thanks,
Chris.



More information about the openstack-discuss mailing list