Hello Proxmox Support,
we observed a possible issue in the PVE Datacenter Manager remote-migration path when the destination is an RBD storage backed by a replicated metadata pool and an erasure-coded data pool.
Five VMs were migrated from another PVE cluster through PDM. Although the migrations completed successfully and the VM configurations referenced the correct storage ID, every destination RBD image was created without the configured data_pool and without the data-pool feature. Their data was therefore stored directly in the replica-3 metadata pool.
The affected disks accounted for approximately 126 GiB of allocated data and 378 GiB of raw replicated usage. Moving them through a normal replicated PVE storage and back to the EC-backed storage recreated them correctly; the metadata pool then dropped to approximately 2.1 MiB stored.
The attached report contains versions, reproduction details and sanitized evidence. Could you confirm whether this issue is already tracked and investigate whether the PDM/qmtunnel path propagates the destination RBD storage’s data-pool property?
Kind regards,
we observed a possible issue in the PVE Datacenter Manager remote-migration path when the destination is an RBD storage backed by a replicated metadata pool and an erasure-coded data pool.
Five VMs were migrated from another PVE cluster through PDM. Although the migrations completed successfully and the VM configurations referenced the correct storage ID, every destination RBD image was created without the configured data_pool and without the data-pool feature. Their data was therefore stored directly in the replica-3 metadata pool.
The affected disks accounted for approximately 126 GiB of allocated data and 378 GiB of raw replicated usage. Moving them through a normal replicated PVE storage and back to the EC-backed storage recreated them correctly; the metadata pool then dropped to approximately 2.1 MiB stored.
The attached report contains versions, reproduction details and sanitized evidence. Could you confirm whether this issue is already tracked and investigate whether the PDM/qmtunnel path propagates the destination RBD storage’s data-pool property?
Kind regards,
I discovered only the issue seeing that the space of the metadata EC pool was raised a lot without an apparent reason and started to investigate on the reasons.