PVE 9.2 OCI data disk always deleted (bug or working as intended?)

[iI0cd@jJEQnVwYZBh$^lE86*l]

Hello all,

I've been testing the OCI image support in PVE 9.2. I am running a 3-node HA cluster testing OCI image support.

Current upgrade path for OCI images is to re-create the container with the new image.

Expected behavior:
* Delete container, leave "Destroy unreferenced disks owned by guest" unchecked
* Recreate container
* Manually update LXC config with mountpoint for existing data disk before starting (this essentially is a small disk containing configuration settings).
* Start container with new version.

Observed behavior:
* Container and ALL mounted disks are removed.
* Retry with test container, removing the mounted disk from the LXC config before repeating steps. Data disk is still removed.

For OCI containers to really work, this config disk is critical for easy version upgrades.

I am not sure if this is working as intended, or this is a bug. I would expect that the config disk is kept (especially after being removed from the LXC config, and not explicitly deleting the referenced disks. Note: When deleting you must check at least one option so I have checked Purge from job configurations).

Has anyone been able to replace a OCI container with a new version without PVE destroying the config disk?

edit: I would note that the current workaround is copy the config disk before removing the container, and manually restore it before starting the new container, however this smells like I'm doing something wrong.

cp /d/pve/images/104/vm-104-disk-1.raw /tmp/
# remove and re-add new OCI container image, do not start
cp /tmp/vm-104-disk-1.raw /d/pve/images/104
# Add mountpoint manually to LXC image
vim /etv/pve/lxc/104.conf
# Start container as normal, config disk is kept and runs as expected.

 

[fschauer]

Observed behavior:
* Container and ALL mounted disks are removed.

In the delete dialog of the Web UI there is a warning saying "Referenced disks will always be destroyed.". So this is expected behavior.

* Retry with test container, removing the mounted disk from the LXC config before repeating steps. Data disk is still removed.

Did the container config still reference the disk? Note that detaching a disk still references it as unused.

I would note that the current workaround is copy the config disk before removing the container, and manually restore it before starting the new container, however this smells like I'm doing something wrong.

To preserve the data without copying files manually you can either manually delete any line referencing the disks from /etc/pve/lxc/<vmid>.conf before destroying the container, and make sure "Destroy unreferenced disks owned by guest" is unchecked. After recreating the container with the same VMID, run pct rescan --vmid <vmid> to reference the disks as unused again.

Another way would be to temporarily reassign the disks to a different container via "Volume Action" -> "Reassign Owner".

Keep in mind that support for OCI images is still a tech preview and more mature support is planned: https://pve.proxmox.com/wiki/Roadmap#Virtualization_&_Guest_Management

 

[iI0cd@jJEQnVwYZBh$^lE86*l]

Thanks!

Did the container config still reference the disk?

In observed behavior (second case) I removed the disk explicitly from the LXC .conf file before deleting the container, with the same results. I ran through both cases twice to confirm behavior before posting - I'll run through it again today and update.

After recreating the container with the same VMID, run pct rescan --vmid <vmid> to reference the disks as unused again.
Another way would be to temporarily reassign the disks to a different container via "Volume Action" -> "Reassign Owner".

I'll try these today; this seems like the answer I was looking for until OCI container support is more fleshed out.

Keep in mind that support for OCI images is still a tech preview and more mature support is planned: https://pve.proxmox.com/wiki/Roadmap#Virtualization_&_Guest_Management

Yup! posted because I didn't find any previous posts about it and consider the config disk use case for OCI images a pretty common one to support out of the box in the final release. Not running production workloads on it, just getting a look at PVE's way vs podman.