Request: new option for lxc copy


I am using “lxc copy” in a cron script. It has an option “–quiet” to hide progress information, which is useful for a script. Yet, it lacks a “–stats” option (which exists in rsync, which is used behind the scene if I’m not wrong). To get that option would help to monitor the lxc copy for my sysops work.

Is that possible to add it?

thank you and Happy New Year to All in advance !

Hmm, so it’s slightly less easy than it sounds as the client tool itself doesn’t see the data being transmitted and so can’t easily count all bytes being transferred in each direction or the average rate.

The messages you see during a transfer are effectively sent verbatim by the source or target server and is treated as an obscure string of character by the client tool.

What we could do is print the last message we received from the server which in many cases would be the 100% transfer alongside either the average speed (if the server knew the total size) or the total size in byte which got transferred. But I don’t know if that’d be valuable.

Hi Stephen. Let me rephrase my idea: with no option, you get the stdout of the server. Why not having a “–stats” option, which would be passed to rsync, so that rsync’s stdout returns the global statistics of the transfer instead of its details?

On a different level, are the exit values of “lxc copy” documented? What are they?

And, last but not least, happy new year!

Happy new year!

lxc copy just returns 0 on success, 1 on failure.

LXD supports quite a bit more than just rsync and the normal progress information we show doesn’t come from rsync at all. In fact LXD always runs rsync in silent mode.

Implementing such a --stats isn’t impossible but it’s also not trivial:

  • Needs the CLI arg added (trivial)
  • Needs an API update to add that to the 4 or so endpoints used to initiate migrations
  • Needs per-backend support for it (rsync, zfs, btrfs, ceph)
  • Needs to figure out what to do with the stats, just show them as a websocket progress event like the progress or as something new, if the latter, needs extending our standard API response for websocket operations as we don’t have anything that can hold that today
  • We’d be getting stats from both the source and destination, possibly different depending on version of the tools at play, so what do we show the user