hi, this message would probably be better suited on the qemu-discuss list not the devel.
comments inline. On 13.04.2016 09:43, Gilar Dwitresna wrote: > hi, > I have done make implementation of qemu-kvm instalation for live > migration on ubuntu with sharing storage (NFS) configuration. > the qemu-kvm has been succeed for live migration with default algorithm > (guest without service), but if the guest run the service (streaming > server), the dirty pages rate are increase from 900 to 7000 pages, and > live migration can't succeed. > > i have played run live migration with extended downtime 30 second, live > migration can be succees, consequenly the downtime come to increase. > My system use fast ethernet 100mbps for network bandwidth, 2 PC with ram That's really not fast but more like the lower limit, a guest which dirties page quickly can saturate the max 100Megabits/s / 8 = 12.5 megabyte/s line really quick. 1 Gb/s (=125 megabyte/s) would be an better option. > 8 GB for host, 1 PC RAM 4GB HDD 500 GB for NFS shared storage. Guest VM > configure with 2GB RAM HDD 100 GB, migrate from host A to host B. > > From some reference, if the write rate to the memory pages in use by the > VM (here after referred to as the dirty page rate) is high compared with > the cost of transferring the pages between the two hosts involved in the > process, (as dictated, among others, by the network bandwidth,) then > live migration may not be possible. > With qemu 2.5 you have better autoconverge of live migration, see: http://wiki.qemu.org/Features/AutoconvergeLiveMigration Also post copy ram (introduced as experimental in qemu 2.5) would be an option, see http://wiki.qemu.org/Features/PostCopyLiveMigration cheers, Thomas > In the case with the high dirty pages, i run the live migration while > the guest run the streaming server with network bandwidth 100 mbps, then > the server can be migrated. > > can i modify qemu-kvm live migration algorithm? and what should i do to > modify this algorithm that can be migrate while the VM Guest run the > servive (streaming server) without extended downtime? > > Thanks. > Regards, Papandayan >
