the source instance containerX is frozen right after the copy command. Is this normal/expected behavior?
Previously I had an incus host (6.0.2) converted from old LXD host, and copy containers from there to cluster A above as part of migration to new hardware, and I don’t recall a frozen instance with all service unavailable. Sadly the old VM of LXD host is no more.
as a note, I enable rbd features layering,exclusive-lock,object-map,fast-diff on pools used by incus, but I’ve tried the original setup of only layering feature, and the frozen instance is still happening when copying.
It depends on the storage backend in use, but yes, for ceph-rbd, this is one of the backends where we need to freeze the filesystem to have some consistency when transferring the main filesystem itself. The snapshots don’t require that though and those will transfer without the lock.
(lvm and ceph are the two backends that require that to avoid block device inconsistency)
I can issue command incus resume containerX on the source, and it seems that the copying went on and finished without errors, and on the destination, I tried to start the containers, checked the services, etc, without apparent problems.
Will resuming like that be problematic in the result containers?
It’s basically gambling at that point, there is no guarantee of consistency if the filesystem isn’t frozen, so if you’re lucky, it’s just a few missing recent writes, if you’re not lucky, the filesystem is halfway through writing its journal and won’t be mountable without going through a filesystem check first.