hi, Any input on this Regards Adivya Singh On Tue, Nov 8, 2022 at 8:50 AM 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.
[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.