After investigating the logs I believe that there were few issues that
might have caused this unstable behavior.
1) Looks like the DB still contained some leftovers from the already fixed
bug which was causing duplicate entries. Even after the date of engine
upgrade I still saw some "Duplicate key" errors. I suggest cleaning the DB
(if that is possible).
2) Also saw a few other known (and already reported) issues that also might
have caused the problem. The issues are going to be fixed in the coming
4.4.9 version, resulting in more stability.
I asked our QE team to inform me if they encounter this 'disks stuck in
FINALIZING' issue, so I'll be able to try and investigate it locally.
But again, this issue might be caused by either some DB leftovers or issues
that we are already WIP fixing them.
If you opened a bug, please send the link to it here.
Thank you in advance.
On Wed, 11 Aug 2021 at 15:24, Pavel Bar <pbar(a)redhat.com> wrote:
Just a short status update FYI.
The issue is not forgotten, I'm looking at it.
Found in logs a few known issues that are gonna be fixed in the next
version, but still not sure that the issue you described will be fixed by
WIP, will continue updating.
On Sun, 1 Aug 2021 at 10:38, Eyal Shenitzky <eshenitz(a)redhat.com> wrote:
> +Pavel Bar <pbar(a)redhat.com> +Benny Zlotnik <bzlotnik(a)redhat.com>
> On Sun, 1 Aug 2021 at 08:53, luwen.zhang <luwen.zhang(a)vinchin.com> wrote:
>> Sorry I was trying to open a new thread for this issue, but it seems I
>> failed to submit. Here let me explain how the issue is reproduced.
>> It’s a regular backup by using CBT+imageip API, after a series of
>> successful backup, at one of the backup session beginning, when we try to
>> obtain the VM config and the snapshot list (obtain snapshot list can
>> determine the VM virtual disk format is RAW or QCOW2) by using `GET
>> vms/<vm-id>/snapshots`, but get the following error.
>> <?xml version="1.0" encoding="UTF-8"
>> <detail>duplicate key acf1edaa-e950-4c4f-94df-1bd6b3da49c1
>> (attempted merging values
>> and org.ovirt.engine.core.common.businessentities.storage.diskimage@d973046c
>> <reason>Operation Failed</reason>
>> After this, on oVirt engine web console, the VM show 2 disks (actually
>> it only has 1) , and the disk status always showing “Finalizing”, it’s been
>> more than 30 hours now, and during this, cannot modify VM disk or take
>> Before upgrading oVirt engine to 126.96.36.199-1.el8 this problem happened
>> frequently, after upgrading, the frequency is reduced.
>> Here I’m adding the engine logs and vdsm logs.
>> Engine logs:
>> VDSM logs:
>> Thanks & regards!
>> On 07/29/2021 19:20，Nir Soffer<nsoffer(a)redhat.com>
>> On Thu, Jul 29, 2021 at 10:08 AM luwen.zhang <luwen.zhang(a)vinchin.com>
>> The problem occurred yesterday, but we waited for more than 20 hours,
>> still 2 disks and in Finalizing state.
>> If the image transfer is "finalizing" it means the image transfer is
>> trying to finalize, but the operation could not complete.
>> In this phase the disk remains locked, and it should not be possible
>> to start a new image transfer
>> (e.g perform another backup).
>> Engine and vdsm logs should explain why the image transfer is stuck in
>> the finalizing phase.
>> Can you add detailed instructions on how to reproduce this issue?
>> Devel mailing list -- devel(a)ovirt.org
>> To unsubscribe send an email to devel-leave(a)ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct:
>> List Archives:
> Eyal Shenitzky