Il 15/12/2012 12:20, Peter Lieven ha scritto: > Am 15.12.2012 10:02, schrieb Paolo Bonzini: >> >>> is the check for spending > 50ms in the loop still necessary in qemu >>> 1.3.0? >> >> Yes, it helps finding the available bandwidth and tuning the downtime of >> migration. > > Aha, okay. But then it should also be added to block migration, shoudn't it?
The main problem with block migration is that it uses the same strategy for RAM and storage migration, but the two are very different. In RAM migration, you are basically fighting an uphill battle. You cannot do RAM migration without some amount of downtime, because CPUs are always going to be faster than the migration process and latency is zero. But in storage migration you have the same constraints as the guest. Disk is slow for the guest too (and as slow as network, or slower). The guest needs to flush to disk, while the migration process does not need to do that. And migration can proceed asynchronously, just like the guest, with multiple in-flight operations at the same time. drive-mirror can do all this much better than migration, and without slowing down RAM migration (which occurs on a separate socket). See the drive-mirror patches that I posted recently for 1.4. With those patches, I can sync the destination to the source every 100 ms during a kernel compilation, and every 1-2 seconds during hibernation (the absolute worst case) using iSCSI for both the source and the target and a middle-range SAS disk. This is a far cry from what RAM migration can achieve on any reasonable workload, and it's the reason why I'm pushing for a separate mechanism than the migrate command. libvirt has had patches posted to support this too. Paolo > I tested it in qemu-kvm 1.2.0 and it help to increase responsiveness if the > I/O latency on the storage is high.