how to remove image with still used volumes

Erik McCormick emccormick at cirrusseven.com
Tue Nov 8 17:09:01 UTC 2022


On Mon, Nov 7, 2022 at 10:15 PM Christoph Anton Mitterer <
calestyo at scientia.org> wrote:

> 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.
>

I suppose you could consider it inefficient over a very long term in that
you have a source image taking up storage that has very little resemblance
to the instances that were spawned from it. However, what you're running in
to here is the "pets vs. cattle" argument. Openstack is a *cloud* platform,
not a virtualization platform. It is built for cattle. Long-lived instances
are not what it's targeted to. That being said, it deals with them just
fine. You simply have to accept you're going to end up with these relics.
If you're able to nuke and recreate instances frequently and not upgrade
them over years, you end up using far less storage and have instances that
can quickly migrate around if you're using local storage.


>
> [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.]
>

You can import an existing disk (after some conversion depending on your
source hypervisor) into a Ceph-backed Cinder volume and boot from it just
fine. You have to make sure to tick the box that tells it it's bootable,
but otherwise should be fine.

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).
>
> Those properties you're setting on images are simply being passed to nova
when it boots the instance. You should be able to specify them on a
command-line boot from a volume.

For your conversion purposes, you could check out virt-v2v. I used that to
convert a bunch of old vmware instances to KVM and import them into
Openstack. It was slow but worked pretty well.


>
> Thanks,
> Chris.
>

-Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221108/0e1ef029/attachment.htm>


More information about the openstack-discuss mailing list