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).
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.