On the “old” server we have rsync 3.1.1, and on the “new” there is LXD snap 4.4. I don’t know how to check if rsync is part of the snap. But I think it has version 3.1.2 because that is what I see in the error message on the “old” server. The Ubuntu package rsync is 3.1.3
BTW In LXD 2.0 there is no export, so I can’t use that as a workaround.
The only option I can think of is to upgrade LXD to 3.0.3. However, there are some important containers for which we want to avoid downtime. And of course, it would be trouble if the upgrade somehow fails.
Can you initiate the copy from the target server so you have a more modern CLI and use lxc copy old:CONTAINER new: --mode relay?
That should leave us just with one error to deal with
It’s indeed quite likely to be a rsync feature mismatch, though the target should be assuming the least amount of feature in that case so maybe there are some other flags that have since changed and are confusing rsync.
You may want to run forkstat | grep rsync on both source and target, so we can easily compare the final set of arguments on both sides.
If we’re just missing a few arguments on the source, one workaround is to put in place a /usr/local/bin/rsync wrapper which executes the real rsync with the few extra arguments needed.
Hmm, right, so there’s something wrong on the target as it’s mistakenly assuming all features are supported…
@tomp is that something you could take a look at? Ideally we’d want rsync copies to work between 2.0.11 and higher, 3.0.3 and higher, 4.0.0 and higher and whatever is latest. I’m not sure it’s possible, will depend on exactly what 3.0.3 does as a behavior and if we have to chose between 2.0 and 3.0, we’ll obviously pick 3.0 as the one that should work.
@keesbghs so in your case, you can create a file at /usr/local/bin/rsync containing:
Then make that path executable and attempt another copy. This should cause LXD to use the wrapper script which will inject the missing args on the source.
Hopefully we can tweak the code in latest LXD to better handle importing from 2.0 without such hacks. I just fear that our current detection behavior is there to accommodate 3.0 and that as 2.0 doesn’t have interactive feature negotiation, it may not be possible to fix this for everyone…
I’m happy. I’m going to move the containers, one by one, to our cluster (LXD 4.4), and after that we will wipe the old system and newly install Ubuntu 20.04, and then add it to the cluster.