From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
qemu block <qemu-block@nongnu.org>, Kevin Wolf <kwolf@redhat.com>,
Max Reitz <mreitz@redhat.com>, John Snow <jsnow@redhat.com>,
Fam Zheng <famz@redhat.com>,
"Juan Q >> Juan Jose Quintela Carreira" <quintela@redhat.com>
Subject: Re: [Qemu-devel] Restoring bitmaps after failed/cancelled migration
Date: Mon, 23 Apr 2018 19:41:54 +0100 [thread overview]
Message-ID: <20180423184153.GB13754@work-vm> (raw)
In-Reply-To: <8739e95e-1900-d4e3-7ac8-77e3aa8b927e@virtuozzo.com>
* Vladimir Sementsov-Ogievskiy (vsementsov@virtuozzo.com) wrote:
> Hi all.
>
> We now have the following problem:
>
> If dirty-bitmaps migration capability is enabled, persistance flag is
> dropped for all migrated bitmaps, to prevent their storing to the storage on
> inactivate. It works ok, persistence itself is migrated through the
> migration channel. But on source, bitmaps becomes not persistent, so if we,
> for some reasons, want to continue using source vm, we'll lose bitmaps on
> stop/start.
>
> It's simple to fix it: just make bitmaps persistent again on invalidate
> [1].. But I have some questions.
>
> 1. What are possible cases? I think about the following:
>
> a. migration cancel or fail, then invalidate
> b. migration success, then qmp cont => invalidate
> c. migration success, then stop/start (there was no invalidate, so [1] will
> not work)
>
>
> 2. Is it safe at all, saving bitmaps after inactivate, even without
> persistence?
>
> Inactive disk implies, that it may be changed by somebody other, isn't it?
> Is it possible, that target will change the disk, and then we return control
> to the source? In this case bitmaps will be invalid. So, should not we drop
> all the bitmaps on inactivate?
I don't know the full answers; but I do know it's valid to have the case
(b) - i.e. from QEMU's point of view the migration succeeds, but the
destination was run with -S and for some external failure reason, the
management layer decides to kill the destination and restart the source.
And you're right, that at that point there's no one holding the lock,
so the source can't be sure that no one snuck in and fiddled with the
disk before restarting.
Dave
> --
> Best regards,
> Vladimir
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2018-04-23 18:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-18 14:00 [Qemu-devel] Restoring bitmaps after failed/cancelled migration Vladimir Sementsov-Ogievskiy
2018-04-23 18:41 ` Dr. David Alan Gilbert [this message]
2018-05-11 21:23 ` John Snow
2018-05-14 9:55 ` Vladimir Sementsov-Ogievskiy
2018-05-14 6:41 ` Fam Zheng
2018-05-14 10:09 ` Vladimir Sementsov-Ogievskiy
2018-05-14 10:23 ` Vladimir Sementsov-Ogievskiy
2018-05-15 2:03 ` Fam Zheng
2018-05-16 12:47 ` Kevin Wolf
2018-05-16 15:10 ` Vladimir Sementsov-Ogievskiy
2018-05-16 15:32 ` Kevin Wolf
2018-05-16 15:52 ` Vladimir Sementsov-Ogievskiy
2018-05-17 2:14 ` Fam Zheng
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=20180423184153.GB13754@work-vm \
--to=dgilbert@redhat.com \
--cc=famz@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=vsementsov@virtuozzo.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 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.