On 02/05/2014 07:15 PM, Paolo Bonzini wrote: > Il 05/02/2014 11:46, Andrey Korolyov ha scritto: >> On 02/05/2014 11:27 AM, Paolo Bonzini wrote: >>> Il 04/02/2014 18:06, Andrey Korolyov ha scritto: >>>> Migration time is almost independent of VM RSS(varies by ten percent at >>>> maximum), for situation when VM is active on target host, time is about >>>> 85 seconds to migrate 8G between hosts, and when it is turned off, >>>> migration time *increasing* to 120s. For curious ones, frequency >>>> management is completely inactive on both nodes, neither CStates >>>> mechanism. Interconnection is relatively fast (20+Gbit/s by IPoIB). >>> >>> What version of QEMU? >>> >>> Paolo >> >> Ancie.. ehm, stable - 1.1.2 from wheezy. Should I try 1.6/1.7? > > Yeah, you can checkout the release notes on wiki.qemu.org to find out > which versions had good improvements. You can also try compiling > straight from git, there are more speedups there. > > Paolo > Took and build 1.6.2 and faced a problem - after a couple of bounce iterations of migration (1->2->1->2) VM is not able to migrate anymore back in a probabilistic manner with an error 'internal error unexpected migration status in setup'. Error may disappear over a time, or may not disappear at all and it may took a lot of tries in a row to succeed. There are no obvious hints with default logging level in libvirt/qemu logs and seemingly libvirt is not a cause because "accumulated error state" preserves over service restarts. Also every VM is affected, not ones which are experiencing multiple migration actions. Error happens on 3rd-5th second of the migration procedure, if it may help. What is more interesting, the original counter-intuitive behavior is not disappeared but increased relative span: 25 vs 70 seconds for fully commited 8G VM. I am suspecting some mechanism falling back to the idle and dropping overall performance therefore but can not image one beyond standard freq/cstates which are definitely turned off. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
