This new feature will help live migration converge when the guest is dirtying pages too fast for the network throughput. The performance team is using a script like this: # cat migrated_cgroup.sh # Enter guest name $1 # # Try for 120 seconds with 10 percent of 1-cpu echo 10000 > /cgroup/cpu/libvirt/qemu/$1/vcpu0/cpu.cfs_quota_us echo 10000 > /cgroup/cpu/libvirt/qemu/$1/vcpu1/cpu.cfs_quota_us sleep 120 # Try for 2 minutes with 1% of the cpu of 1-cpu echo 1000 > /cgroup/cpu/libvirt/qemu/$1/vcpu0/cpu.cfs_quota_us echo 1000 > /cgroup/cpu/libvirt/qemu/$1/vcpu1/cpu.cfs_quota_us sleep 120 # Increase the period to then reduce to .1% of 1-cpu. echo 1000000 > /cgroup/cpu/libvirt/qemu/$1/vcpu0/cpu.cfs_period_us echo 1000000 > /cgroup/cpu/libvirt/qemu/$1/vcpu1/cpu.cfs_period_us echo 1000 > /cgroup/cpu/libvirt/qemu/$1/vcpu0/cpu.cfs_quota_us echo 1000 > /cgroup/cpu/libvirt/qemu/$1/vcpu1/cpu.cfs_quota_us This logic should be refined and put into libvirt so it's automatic for the customer.
Additionally, libvirt should be using the qemu 1.2 feature of XBZRLE migration, if it can determine that both sides of the migration support it (which also means that XBZRLE needs to be backported into RHEL qemu).
XBZRLE support is requested by bug 842857
Libvirt already supports changing CPU scheduling parameters and I thing doing so automagically goes beyond libvirt's competency. It should be higher-level management (vdsm probably) doing that.
*** This bug has been marked as a duplicate of bug 867453 ***