Bug 699674

Summary:	decrease migration_downtime cause migrtion speed very slow
Product:	Red Hat Enterprise Linux 5	Reporter:	Mike Cao <bcao>
Component:	kvm	Assignee:	Virtualization Maintenance <virt-maint>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.7	CC:	bcao, juzhang, michen, mkenneth, virt-maint, xfu
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-05-10 11:05:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Mike Cao 2011-04-26 10:39:02 UTC

Description of problem:


Version-Release number of selected component (if applicable):
# uname -r
2.6.18-256.el5
# rpm -q kvm
kvm-83-231.el5


How reproducible:
100%

Steps to Reproduce:
1.start VM in src host
CLI:/usr/libexec/qemu-kvm -rtc-td-hack -usbdevice tablet -no-hpet -drive file=win7-32.qcow2,if=ide,werror=stop,cache=none,format=qcow2,media=disk -cpu qemu64,+sse2 -smp 16,cores=16 -m 4G -net nic,macaddr=00:12:24:5f:a6:99,model=virtio,vlan=0 -net tap,script=/etc/qemu-ifup,vlan=0  -uuid `uuidgen` -vnc :1 -boot c  -balloon none -monitor stdio
2.start lisetnning port
3.set migration downtime to 0.00000001s
(qemu)migrate_set_downtime 0.00000001
4(qemu)migrate -d tcp:0:5888
5.check migration speed  
Actual results:
20kb/s

Expected results:
set migration dowmtime should not influence migration speed. it should keep 30MB/s

Additional info:

Comment 1 FuXiangChun 2011-05-10 10:55:05 UTC

reporduced on
uname -r
2.6.18-260.el5
rpm -qa|grep kvm
kvm-83-232.el5

Comment 2 juzhang 2011-05-10 11:05:26 UTC

Close this bug according to bz699952 comment2,if need further investigation,please re-open this issue.

--snip of comment2---
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.