VM Pool To Pool Migration over VPN
-
@acebmxer could you try a VM copy with compression enabled ? and benchmark it
-
-
That is much faster throughput wise. Time wise will seems about the same or longer.
-
-
@acebmxer did it ever finish? Did it work or was the vm shutdown'd?
-
@nikade
Doing the copy vm with compression moved at double the speed shown in above screenshots. And finish in half the time. Since it was a copy job it left a copy of the vm on both locations. However starting the copied vm from its original location showed no issues. I then deleted the vm no longer needed in other location.So question why did vm migration take so long vs vm copy. both instances the vm was powered off.
-
@acebmxer i noticed the différence but can't quite explain it...
need some Vates storage guru to enlighten us
-
Hi!
@team-storage will correct me but on top of my head:
- Live migration needs to continue to write locally while the VM runs while copying the blocks on destination. This takes some ressources and time, limiting the transfer speed
- Migration in general is limited by the Dom0 expert speed via tapdisk, which is a bottleneck. In real life, this allowed us to have migrations without disrupting day-to-day operations (not taking all IOPS), which is good for stability but not on purpose
- Copy with compression is faster because all blocks are compressed so you are sending more data for the same time (therefore, faster) at the cost of more CPU cycles. Which in general is worth it, as you've seen.
-
@acebmxer said in VM Pool To Pool Migration over VPN:
Maybe VPN overhead.
Have You checked the VPN capacity spec of Your firewalls?
-
@olivierlambert thank for that. Just to be clear the vm was not runing but shut down if that makes a difference.
@ph7 Both firewalls are Unifi Enterprise fortress gateways. - https://techspecs.ui.com/unifi/cloud-gateways/efg?subcategory=all-cloud-gateways
Both sites are setup with Site Magic VPN. So should be full 1.1gbps if accurate.
