Hide Forgot
Description of problem: Hit same issue on RHEL 6.1 host with . When setting migration downtime to 0.0000001, migration works fine for me, but setting to 0.0000000001, migration speeds slow down to less than 100Kb/s Version-Release number of selected component (if applicable): kernel 2.6.32-132.el6.x86_64, qemu-kvm qemu-kvm-0.12.1.2-2.158.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1. start a guest by following cli: /usr/libexec/qemu-kvm -M rhel6.1.0 -enable-kvm -m 4096 -smp 4 -name rhel6.1 -uuid `uuidgen` -rtc base=utc,clock=host,driftfix=slew -no-kvm-pit-reinjection -boot c -drive file=/root/RHEL-Server-6.1-64-virtio.raw,if=none,id=drive-virtio0-0-0,media=disk,format=raw,cache=none -device virtio-blk-pci,drive=drive-virtio0-0-0,id=virt0-0-0 -netdev tap,id=hostnet1 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:40:13:15:53 -usb -device usb-tablet,id=input1 -vnc :6 -monitor stdio -balloon none 2. start another guest in listening mode -incoming tcp:0:5880 3. (qemu)migrate_set_downtime 0.0000000001 4. check migration speed Actual results: migrate speed is less than 100Kb/s Expected results: Should affect migration speed. Additional info:
> > Expected results: > Should affect migration speed. > ---> Should not affect migration speed.
Migration downtime affects migration speed because qemu has more work to do between iterations (checking the dirty bitmap, etc.). Besides, a downtime of 10^-10 seconds makes little sense when a clock cycle is three times that.
Relation here is that we we are never getting few enough pages to migrate in 0.0000001 secondos (that should be one page or something ridiculous like that). So we try to get to that single one page and stay forever trying (making final speed really small).