Open Stack

On Tue, 2022-11-08 at 12:09 -0500, Erik McCormick wrote:
> 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.

Well it ultimately costs me a ~ factor 2 of storage per instance.


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

It's clear that my use case is a bit non-standard. :-)


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

In my case that periodic re-creating is rather not easily possible, as
the VMs are rather complex in their setup.

It's clear that otherwise, it makes sense to have the CoW to share
blocks,... but still:

Shouldn't it be possible to simply break up the connection? Like
telling the backend, when someone wants to "detach" the volume from the
image it's based (and CoW-copied) upon, that it should make a full copy
of the still shared blocks?

Also, what its the reason, that one cannot remove the volume, an
instance was originally created with, from it?


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

That's what I tried to describe before:
1st: I imported it as image
2nd: Made an instance from it
- so far things work fine -
3rd: attached a empty (non image based) volume of the same size)
     that one also had --bootable
4th: copied everything over and made it bootable

At this point however, removing the original volume (based on the
image) seems to be forbidden (some error that the root volume cannot be
removed.

So I tried to trick the system and used the 2nd (non-image based
volume) for instance creation (i.e. server create --volume, not --
image).
While that did work, it then falls back to booting from (SeaBIOS) and
not UEFI as the previous instance, based on the image, still did.

And I seem to cannot get that working to UEFI-boot.


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

Well I'm afraid, that doesn't work. Not sure, maybe it's a bug (the
OpenStack instance in question is probably a somewhat older version).

When I upload my image, and use --property hw_firmware_type=uefi, the
image get's
properties       | direct_url='rbd://fd2b36a3-4f06-5212-a74b-1f9ea2b3ee83/images/c45be8c7-8ff7-4553-a145-c83ba75fb951/snap', hw_firmware_type='uefi', locations='[{'url': 'rbd://fd2b36a3-4f06-5212-a74b-1f9ea2b3ee83/images/c45be8c7-8ff7-4553-a145-c83ba75fb951/snap', 'metadata': {}}]', owner_specified.openstack.md5='', owner_specified.openstack.object='images/mytestimage', owner_specified.openstack.sha256=''

The volume created from that has:
properties                   | attached_mode='rw'
volume_image_metadata        | {'container_format': 'bare', 'min_ram': '0', 'owner_specified.openstack.sha256': '', 'disk_format': 'raw', 'image_name': 'mytestimage', 'hw_firmware_type': 'uefi', 'image_id': 'c45be8c7-8ff7-4553-a145-c83ba75fb951', 'owner_specified.openstack.object': 'images/mytestimage', 'owner_specified.openstack.md5': '', 'min_disk': '0', 'checksum': '9ad12344a29cbbf7dbddc1ff4c48ea69', 'size': '21474836480'}

So there, the setting seems to be not in properties but
volume_image_metadata.


The instance created from that volume has:
an empty properties field.


My 2nd (image independent volume) has:
properties                   | hw_firmware_type='uefi'
and no volume_image_metadata field.


When I create an instance from that (2nd image), via e.g.:
$ openstack server create --flavor pn72te.small --network=internet --volume mytestimage-indep-from-image --property 'hw_firmware_type=uefi' test

Then it gets:
properties                  | hw_firmware_type='uefi'


So seems whether it boots BIOS or UEFI is not determined from the
instance's properties field (which IMO would be the natural place)...
but not from the volume (or image)... but there it also doesn't seem to
work.



Is there any documentation on where/what exactly causes the instance to
boot UEFI?


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

I'll have a look, but I guess it won't help me with the no-UEFI-boot
issue.


Thanks,
Chris.