Mismatch of profile, storage, containers

I have a bit of an unwanted scenario at hand here that came about after replacing a storage pool with a new larger one (living on a dedicated partition).

one profile, 2 storage pools, 3 containers

where the default profile is connect to a default storage pool and 3 containers, but all 3 containers use another storage pool1 (which is not formally used by the default profile though).

the default pool is obsolete (it went out of space and therefore got replaced by the bigger pool1). To clean this up I guess I need to shift things around a bit. I am wondering what the right sequence (least risk of downtime or even loss) of doing this would be best.

Is it sufficient to add pool1 to the default profile?

this paste illustrates the situation at hand

Yeah, if no instances use the storage from the default profile, you’ll be allowed to edit the default profile to have it point to the new pool. This will then let you delete the old pool.

You can then go one step further and edit your instances to remove their root disk entry which will then make them inherit from the default profile again.

so practically I’d have to replace

devices:
...
...
  root:
    path: /
    pool: default
    type: disk

with

devices:
...
...
  root:
    path: /
    pool: pool1
    type: disk

… (if no container, or image is still using def default pool,) right?

an alternative may be to create a second profile connected with the new pool1 and have the assign the continainers to that new profile then.