I got around this by increasing the migrate-setmaxdowntime value on the host while the domain was migrating away:
# virsh migrate-setmaxdowntime <domain name> 750
This allows the domain to be paused for 750ms while the remaining memory is sync'ed to the new host. Smaller values can be tried first, and changed on the run...
This behavior can also be simulated by using the "stress" utility on the guest:
# stress --cpu 1 --vm 8 --vm-bytes 128M --vm-hang 1 --timeout 900s
If it takes too long, increase the maxdowntime parameter (or increase your network bandwidth). It can also be worthy to check if the migration process is really taking advantage of all the available bandwidth with a utility like "iftop". If needed, increase to the available bandwidth:
# virsh migrate-setspeed <domain name> 1000
After all, sometimes it's more acceptable to have a small hickup than failing all the way and having to do an offline migration. As long as your application can live with it...
If it takes too long, increase the maxdowntime parameter (or increase your network bandwidth). It can also be worthy to check if the migration process is really taking advantage of all the available bandwidth with a utility like "iftop". If needed, increase to the available bandwidth:
# virsh migrate-setspeed <domain name> 1000
After all, sometimes it's more acceptable to have a small hickup than failing all the way and having to do an offline migration. As long as your application can live with it...
No comments:
Post a Comment