From: "Denis V. Lunev" <den@openvz.org>
To: John Snow <jsnow@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org,
quintela@redhat.com, stefanha@redhat.com, famz@redhat.com,
mreitz@redhat.com, kwolf@redhat.com,
Eric Blake <eblake@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic
Date: Wed, 1 Aug 2018 23:47:31 +0300 [thread overview]
Message-ID: <30c90ae6-b747-7da8-9f9c-93511fd95a7b@openvz.org> (raw)
In-Reply-To: <e200102e-f5ae-3dae-42b1-b9f98d92fc46@redhat.com>
On 08/01/2018 09:56 PM, John Snow wrote:
>
> On 08/01/2018 02:42 PM, Denis V. Lunev wrote:
>> On 08/01/2018 08:40 PM, Dr. David Alan Gilbert wrote:
>>> * John Snow (jsnow@redhat.com) wrote:
>>>> On 08/01/2018 06:20 AM, Dr. David Alan Gilbert wrote:
>>>>> * John Snow (jsnow@redhat.com) wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>> I'd rather do something like this:
>>>>>> - Always flush bitmaps to disk on inactivate.
>>>>> Does that increase the time taken by the inactivate measurably?
>>>>> If it's small relative to everything else that's fine; it's just I
>>>>> always worry a little since I think this happens after we've stopped the
>>>>> CPU on the source, so is part of the 'downtime'.
>>>>>
>>>>> Dave
>>>>> --
>>>>> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>>>>>
>>>> I'm worried that if we don't, we're leaving behind unusable, partially
>>>> complete files behind us. That's a bad design and we shouldn't push for
>>>> it just because it's theoretically faster.
>>> Oh I don't care about theoretical speed; but if it's actually unusably
>>> slow in practice then it needs fixing.
>>>
>>> Dave
>> This is not "theoretical" speed. This is real practical speed and
>> instability.
> It's theoretical until I see performance testing numbers; do you have
> any? How much faster does the pivot happen by avoiding making the qcow2
> consistent on close?
>
> I don't argue that it's faster to just simply not write data, but what's
> not obvious is how much time it actually saves in practice and if that's
> worth doing unintuitive and undocumented things like "the source file
> loses bitmaps after a migration because it was faster."
Also, frankly speaking, I do not understand the goal of this purism.
There 2 main cases - shared and non-shared storage. On shared
storage:
- normally migration is finished successfully. Source is shut down,
target is started. The data in the file on shared storage would be
__IMMEDIATELY__ marked as stale on target, i.e. you will save CBT
on source (with IO over networked fs), load CBT on target (with IO
over networked FS), mark CBT as stale (IO again). CBT data written
is marked as lost
- failed migration. OK, we have CBT data written on source, CBT
data read on source, CBT data marked stale. Thus any CBT on
disk while VM is running is pure overhead.
The same situation is when we use non-shared migration. In this
case the situation is even worse. You save CBT and put it to trash
upon migration complete.
Please also note, that CBT saving almost does not protect us
from powerlosses as the power should be lost at the very
specific moment to allow data to survive and most likely
we will have to drop CBT completely.
Den
Normally migration is executed as follows:
- source is gently shutdowned, all da
next prev parent reply other threads:[~2018-08-01 20:47 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-26 13:50 [Qemu-devel] [PATCH 0/6] fix persistent bitmaps migration logic Vladimir Sementsov-Ogievskiy
2018-06-26 13:50 ` [Qemu-devel] [PATCH 1/6] iotests: 169: drop deprecated 'autoload' parameter Vladimir Sementsov-Ogievskiy
2018-07-09 22:36 ` John Snow
2018-06-26 13:50 ` [Qemu-devel] [PATCH 2/6] block/qcow2: improve error message in qcow2_inactivate Vladimir Sementsov-Ogievskiy
2018-06-28 12:16 ` Eric Blake
2018-07-09 22:38 ` John Snow
2018-06-26 13:50 ` [Qemu-devel] [PATCH 3/6] bloc/qcow2: drop dirty_bitmaps_loaded state variable Vladimir Sementsov-Ogievskiy
2018-07-09 23:25 ` John Snow
2018-07-10 7:43 ` Vladimir Sementsov-Ogievskiy
2018-07-17 19:10 ` John Snow
2018-06-26 13:50 ` [Qemu-devel] [PATCH 4/6] dirty-bitmaps: clean-up bitmaps loading and migration logic Vladimir Sementsov-Ogievskiy
2018-07-21 2:41 ` John Snow
2018-08-01 10:20 ` Dr. David Alan Gilbert
2018-08-01 17:34 ` John Snow
2018-08-01 17:40 ` Dr. David Alan Gilbert
2018-08-01 18:42 ` Denis V. Lunev
2018-08-01 18:55 ` Dr. David Alan Gilbert
2018-08-01 20:25 ` Denis V. Lunev
2018-08-02 9:29 ` Dr. David Alan Gilbert
2018-08-02 9:38 ` Denis V. Lunev
2018-08-02 9:50 ` Dr. David Alan Gilbert
2018-08-02 19:05 ` Denis V. Lunev
2018-08-02 19:10 ` John Snow
[not found] ` <6d8ed319-9b63-5a7b-fcfe-20cd37cf8c7c@virtuozzo.com>
[not found] ` <d2538432-be74-99bc-72d1-94f8abaa2f9b@redhat.com>
[not found] ` <26c0e008-898d-924a-214e-68ab9fedf1ea@virtuozzo.com>
2018-10-15 9:42 ` [Qemu-devel] ping " Vladimir Sementsov-Ogievskiy
2018-10-29 17:52 ` [Qemu-devel] ping2 " Vladimir Sementsov-Ogievskiy
2018-10-29 18:06 ` John Snow
2018-08-03 8:33 ` [Qemu-devel] " Dr. David Alan Gilbert
2018-08-03 8:44 ` Vladimir Sementsov-Ogievskiy
2018-08-03 8:49 ` Dr. David Alan Gilbert
2018-08-03 8:59 ` Denis V. Lunev
2018-08-03 9:10 ` Dr. David Alan Gilbert
2018-08-01 18:56 ` John Snow
2018-08-01 20:31 ` Denis V. Lunev
2018-08-01 20:47 ` Denis V. Lunev [this message]
2018-08-01 22:28 ` John Snow
2018-08-02 10:23 ` Vladimir Sementsov-Ogievskiy
2018-08-01 12:24 ` Vladimir Sementsov-Ogievskiy
2018-06-26 13:50 ` [Qemu-devel] [PATCH 5/6] iotests: improve 169 Vladimir Sementsov-Ogievskiy
2018-06-26 13:50 ` [Qemu-devel] [PATCH 6/6] iotests: 169: add cases for source vm resuming Vladimir Sementsov-Ogievskiy
2018-06-26 18:22 ` [Qemu-devel] [PATCH 0/6] fix persistent bitmaps migration logic John Snow
2018-06-28 12:04 ` Vladimir Sementsov-Ogievskiy
2018-06-26 18:36 ` John Snow
2018-07-12 19:00 ` Vladimir Sementsov-Ogievskiy
2018-07-12 20:25 ` John Snow
2018-07-13 6:46 ` Vladimir Sementsov-Ogievskiy
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=30c90ae6-b747-7da8-9f9c-93511fd95a7b@openvz.org \
--to=den@openvz.org \
--cc=dgilbert@redhat.com \
--cc=eblake@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=stefanha@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.