On Mon, Nov 7, 2022 at 10:15 PM Christoph Anton Mitterer < calestyo@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