From: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: RFC: tracking valid backing chain issue
Date: Thu, 22 Oct 2020 18:54:31 +0300 [thread overview]
Message-ID: <3cfee0dd-f08a-d943-a8bf-bc85a827e6e4@virtuozzo.com> (raw)
In-Reply-To: <20201021105612.GB8958@merkur.fritz.box>
On 21.10.2020 13:56, Kevin Wolf wrote:
> Am 20.10.2020 um 12:29 hat Nikolay Shirokovskiy geschrieben:
>>
>>
>> On 20.10.2020 13:23, Nikolay Shirokovskiy wrote:
>>>
>>>
>>> On 20.10.2020 11:50, Kevin Wolf wrote:
>>>> Am 20.10.2020 um 10:21 hat Nikolay Shirokovskiy geschrieben:
>>>>> Hi, all.
>>>>>
>>>>> I recently found a corner case when it is impossible AFAIK to find out valid
>>>>> backing chain after block commit operation. Imagine committing top image. After
>>>>> commit ready state pivot is sent and then mgmt crashed. So far so good. Upon
>>>>> next start mgmt can either check block job status for non-autodissmised job or
>>>>> inspect backing chain to infer was pivot was successful or not in case of older
>>>>> qemu.
>>>>>
>>>>> But imagine after mgmt crash qemu process was destroyed too. In this case there
>>>>> is no option to know now what is valid backing chain. Yeah libvirt starts qemu
>>>>> process with -no-shutdown flags so process is not destroyed in case of shutdown
>>>>> but still process can crash.
>>>>
>>>> I don't think this is a problem.
>>>>
>>>> Between completion of the job and finalising it, both the base node and
>>>> the top node are equivalent. You can access either and you'll always get
>>>> the same data.
>>>>
>>>> So if libvirt didn't save that the job was already completed, it will
>>>> use the old image file, and it's fine. And if libvirt already sent the
>>>> job-finalize command, it will first have saved that the job was
>>>> completed and therefore use the new image, and it's fine, too.
>>>
>>> So finalizing can't fail? Otherwise libvirt can save that job is completed and
>>> graph is changed while is was really wasn't
>>
>> Hmm, it is even not the matter of qemu. Libvirt can save that job is completed
>> and then crash before sending command to finalize to qemu. So after qemu crash
>> and libvirt start libvirt would think that valid backing chain is without
>> top image which is not true.
>
> Why not? During this time the top and base image are equally valid to be
> used as the active image.
>
> If QEMU hadn't switched from top to base yet when it crashed, it's still
> no problem if libvirt does the switch when restarting QEMU.
>
Now it clear. Thanx for explanation.
Nikolay
prev parent reply other threads:[~2020-10-22 15:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-20 8:21 RFC: tracking valid backing chain issue Nikolay Shirokovskiy
2020-10-20 8:50 ` Kevin Wolf
2020-10-20 10:23 ` Nikolay Shirokovskiy
2020-10-20 10:29 ` Nikolay Shirokovskiy
2020-10-21 10:56 ` Kevin Wolf
2020-10-22 15:54 ` Nikolay Shirokovskiy [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=3cfee0dd-f08a-d943-a8bf-bc85a827e6e4@virtuozzo.com \
--to=nshirokovskiy@virtuozzo.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--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 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).