@stgraber I have been testing “incus mv” commands to move a container from one incus server to another. This is accomplished by stopping the container and then executing a move:
incus mv Container1 server2:Container1
It appears that the container and all of its snapshots and exports are moved to the target server. So, potentially this can be a long operation.
Thankfully an “incus mv” is an operation that can be cancelled unlike an “incus export” which cannot. However, examining an “incus export” command it is possible to watch the progress and tell how far the export has progressed.
With an “incus mv” there is no status in examining the operation other than “operation underway”.
My tests have involved instances all on Fast SSDs and yet the “incus mv” is even slower than an “incus export” followed by an “incus import”. My “incus mv” is via the “push mode” and yet I have no real understanding of the performance metrics.
Is there a “best practice” in regards to moving instances between incus servers?
Both the source and target were Incus 6.2 and both storage pools were zfs 2.2 running under Ubuntu 24.04 hosts. The source was a standalone Incus server and the target was an Incus cluster. The transfer didn’t complete after 90 minutes, so I aborted it. I ended up doing an export which took 5 minutes and I imported it on the cluster which was another 5 minutes. I am still not sure what happened.
This is odd, it may have been a connectivity issue between the target cluster and the source server?
I’d recommend trying with --mode=relay to avoid connectivity issue by having the CLI tool relay all communications.