qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@parallels.com>
Cc: famz@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org,
	den@parallels.com
Subject: Re: [Qemu-devel] [PATCH v2] persistent dirty bitmap: add QDB file spec.
Date: Fri, 21 Nov 2014 16:55:12 +0000	[thread overview]
Message-ID: <20141121165512.GA32635@stefanha-thinkpad.redhat.com> (raw)
In-Reply-To: <546F139C.1050408@parallels.com>

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

On Fri, Nov 21, 2014 at 01:27:40PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> >There is a constraint if we want to get live migration for free: The
> >bitmap contents must be accessible with bdrv_read() and
> >bdrv_get_block_status() to skip zero regions.
> Hm. I'm afraid, it still will not be free. If bitmap is active, it's actual
> version is in memory. To migrate bitmap file like a disk image, we should
> start syncing it with every write to corresponding disk, doubling number of
> io.

It would be possible to drive-mirror the persistent dirty bitmap and
then flush it like all drives when the guest vCPUs are paused for
migration.

After thinking more about it though, this approach places more I/O into
the critical guest downtime phase.  In other words, slow disk I/O could
lead to long guest downtimes while QEMU tries to write out the dirty
bitmap.

> Moreover, we have normal dirty bitmaps, which have no name/file, do we
> migrate them? If, for example, the migration occurs when backup in progress?
> Active bitmaps should be migrated in the same way for
> persistent/named/normal bitmaps. I can't find in qemu source, is there
> bitmap migration?

bs->dirty_bitmaps is not migrated, in fact none of BlockDriverState is
migrated.

QEMU only migrates emulated device state (e.g. the hardware registers
and associated state).  It does not emulate host state that the guest
cannot see like the dirty bitmap.

> Or you are saying about migrating disabled bitmaps? Hm. We should sync
> bitmap file on bitmap_disable. Disabled persistent bitmap is just a static
> file ~30mb, we can easily migrate it without common procedure with cow or
> something like this..

Active dirty bitmaps should migrate too.  I'm thinking now that the
appropriate thing is to add live migration of dirty bitmaps to QEMU
(regardless of whether they are active or not).

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2014-11-21 16:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <545CB9CE.9000302@parallels.com>
     [not found] ` <20141108071919.GB4940@fam-t430.nay.redhat.com>
     [not found]   ` <54607427.8040404@parallels.com>
     [not found]     ` <5462327C.5080704@redhat.com>
     [not found]       ` <5464B80E.6060201@parallels.com>
     [not found]         ` <546A88DD.10006@redhat.com>
2014-11-18 10:54           ` [Qemu-devel] [PATCH v6 00/10] block: Incremental backup series Vladimir Sementsov-Ogievskiy
2014-11-18 13:09             ` Vladimir Sementsov-Ogievskiy
2014-11-18 14:41               ` Vladimir Sementsov-Ogievskiy
2014-11-18 16:08               ` John Snow
2014-11-19  6:25                 ` Denis V. Lunev
2014-11-20 10:34           ` [Qemu-devel] [PATCH v2] persistent dirty bitmap: add QDB file spec Vladimir Sementsov-Ogievskiy
2014-11-20 10:41             ` Vladimir Sementsov-Ogievskiy
2014-11-20 11:36               ` Stefan Hajnoczi
2014-11-21 10:27                 ` Vladimir Sementsov-Ogievskiy
2014-11-21 16:55                   ` Stefan Hajnoczi [this message]
2014-11-24  9:19                     ` Vladimir Sementsov-Ogievskiy
2014-11-25 17:58                     ` Vladimir Sementsov-Ogievskiy
2014-11-28 13:28                     ` Vladimir Sementsov-Ogievskiy
2014-12-01 11:02                       ` Stefan Hajnoczi
2014-11-21 12:56                 ` Vladimir Sementsov-Ogievskiy
2014-11-21  0:24             ` Eric Blake

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=20141121165512.GA32635@stefanha-thinkpad.redhat.com \
    --to=stefanha@redhat.com \
    --cc=den@parallels.com \
    --cc=famz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@parallels.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).