All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Qemu-kvm live migration modify
Date: Wed, 13 Apr 2016 11:12:49 +0200	[thread overview]
Message-ID: <570E0D91.2020808@proxmox.com> (raw)
In-Reply-To: <CANNuj8wzn3+oqL2MFLmL5rjCoLs2kpnr=hVRzShf0FN8YCyq8A@mail.gmail.com>

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
> 

      reply	other threads:[~2016-04-13  9:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13  7:43 [Qemu-devel] Qemu-kvm live migration modify Gilar Dwitresna
2016-04-13  9:12 ` Thomas Lamprecht [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=570E0D91.2020808@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.