I'll drop this here since I now spend quite some time to find it's all hardcoded in the xe binary.
Forcing to use stunnel + gzip has made the Xen live migration slower than it even was in 2006, on 2006's hardware.
Documentation would be cool, too. i.e. XE_STUNNEL env var could be a workaround, just it's not documented anywhere, so one would be stupid using it.
If able to configure a dedicated interface and port, ssl disabled, compression disabled, infiniband users could use SDP for the migration, meaning 20x+ performance increase over GigE
If you can only do one thing, go for gzip -1
If you can only do two things, go for gzip -1 and documentation.
Thanks for the input.
FWIW there used to be an encryption option for migration, added in commit 5c9edd2 but then removed again in 7fcc90f (while storage motion was going in). Although encryption defaulting to on sounds like a safe default, I agree it should be possible to turn it off. I'm looking into a similar mechanism for cross-host VDI.copy.
It would be really nice if storagexenmotion would work offline too. I find myself a lot of times in the situations when I moved a vm live from an older server to a newer one and then I can't move it back because of CPU flags. I understand that live it would not be possible but maybe it can be done offline?
I posted here because seemed to be in the same spectra "Livemigration improvements"
Would be nice, also if this ticket, that affects EVERY USER of livemigration, would see some consideration.