Open Stack

hi,

Any input on this

Regards
Adivya Singh

On Tue, Nov 8, 2022 at 8:50 AM 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.
>
> [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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221108/0a78218d/attachment.htm>