Bug 2090682 - [VEEAM] VM can't be backed up again if user power offs it during hybrid backup
Summary: [VEEAM] VM can't be backed up again if user power offs it during hybrid backup
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Backup-Restore.VMs
Version: 4.5.0.8
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.5.1
: ---
Assignee: Benny Zlotnik
QA Contact: Evelina Shames
bugs@ovirt.org
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-26 10:53 UTC by Yury.Panchenko
Modified: 2022-06-23 05:54 UTC (History)
7 users (show)

Fixed In Version: ovirt-engine-4.5.1.1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-06-23 05:54:58 UTC
oVirt Team: Storage
Embargoed:
pm-rhel: ovirt-4.5?


Attachments (Terms of Use)
engine logs (430.98 KB, application/x-7z-compressed)
2022-05-26 10:53 UTC, Yury.Panchenko
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github oVirt ovirt-engine pull 424 0 None open core: unset snapshot id from backup 2022-06-09 07:02:48 UTC
Red Hat Issue Tracker RHV-46126 0 None None None 2022-05-26 11:14:13 UTC

Description Yury.Panchenko 2022-05-26 10:53:59 UTC
Created attachment 1883770 [details]
engine logs

Description of problem:
I'm testing the new hybrid backup in the ovirt 4.5
There is one vm which is powered on
1. User starts full backup
2022-05-20 15:06:27,793Z Running command: HybridBackupCommand
2022-05-20 15:06:30,086Z Running command: CreateLiveSnapshotForVmCommand
2. At the same time user power offs the vm
2022-05-20 15:07:02,639Z Running command: ShutdownVmCommand
3.The backup is failed
2022-05-20 15:07:05,274Z Command CreateLiveSnapshotForVm id: '44e0fba3-9a27-456b-86c6-a5ca24d944eb': execution was completed, the command status is 'FAILED'
4. then
Validation of action 'RemoveSnapshot' failed for user admin@internal-authz. Reasons: VAR__TYPE__SNAPSHOT,VAR__ACTION__REMOVE,ACTION_TYPE_FAILED_VM_SNAPSHOT_TYPE_NOT_REGULAR

and
2022-05-20 15:07:09,525Z ERROR EVENT_ID: VM_BACKUP_FAILED(10,792)

5.If user trys to start next backup it will be failed
2022-05-20 15:10:18,709Z ERROR [org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand] (default task-24) [4fde0c6e-ae21-4fbb-b379-792b98f354b7] Command 'org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand' failed: CallableStatementCallback; SQL [{call updatesnapshotid(?, ?)}]; ERROR: update or delete on table "snapshots" violates foreign key constraint "fk_backups_snapshots" on table "vm_backups"
  Detail: Key (snapshot_id)=(c466b4d3-1d9c-41c4-977b-6360e46192a0) is still referenced from table "vm_backups".
  Where: SQL statement "UPDATE snapshots
    SET snapshot_id = v_new_snapshot_id
    WHERE snapshot_id = v_snapshot_id"




Version-Release number of selected component (if applicable):
ovirt 4.5.0.8


Actual results:
Backup is failed

Expected results:
Backup mustn't react to changes in the vm power state

The ovirt db mustn't have SQL errors

Comment 1 Arik 2022-06-07 12:03:24 UTC
(In reply to Yury.Panchenko from comment #0)
> I'm testing the new hybrid backup in the ovirt 4.5
> There is one vm which is powered on
> 1. User starts full backup
> 2022-05-20 15:06:27,793Z Running command: HybridBackupCommand
> 2022-05-20 15:06:30,086Z Running command: CreateLiveSnapshotForVmCommand
> 2. At the same time user power offs the vm
> 2022-05-20 15:07:02,639Z Running command: ShutdownVmCommand
> 3.The backup is failed
> 2022-05-20 15:07:05,274Z Command CreateLiveSnapshotForVm id:
> '44e0fba3-9a27-456b-86c6-a5ca24d944eb': execution was completed, the command
> status is 'FAILED'
> 4. then
> Validation of action 'RemoveSnapshot' failed for user admin@internal-authz.
> Reasons:
> VAR__TYPE__SNAPSHOT,VAR__ACTION__REMOVE,
> ACTION_TYPE_FAILED_VM_SNAPSHOT_TYPE_NOT_REGULAR
> 
> and
> 2022-05-20 15:07:09,525Z ERROR EVENT_ID: VM_BACKUP_FAILED(10,792)

This sounds like bz 2080766 - the fix is being tested as part of 4.5.1
 
> 5.If user trys to start next backup it will be failed
> 2022-05-20 15:10:18,709Z ERROR
> [org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand] (default
> task-24) [4fde0c6e-ae21-4fbb-b379-792b98f354b7] Command
> 'org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand' failed:
> CallableStatementCallback; SQL [{call updatesnapshotid(?, ?)}]; ERROR:
> update or delete on table "snapshots" violates foreign key constraint
> "fk_backups_snapshots" on table "vm_backups"
>   Detail: Key (snapshot_id)=(c466b4d3-1d9c-41c4-977b-6360e46192a0) is still
> referenced from table "vm_backups".
>   Where: SQL statement "UPDATE snapshots
>     SET snapshot_id = v_new_snapshot_id
>     WHERE snapshot_id = v_snapshot_id"

Benny, can you please take a look at this part? maybe we should also detach the snapshot from the backup in this case?

Comment 2 Benny Zlotnik 2022-06-09 07:02:48 UTC
(In reply to Arik from comment #1)
> (In reply to Yury.Panchenko from comment #0)
> > I'm testing the new hybrid backup in the ovirt 4.5
> > There is one vm which is powered on
> > 1. User starts full backup
> > 2022-05-20 15:06:27,793Z Running command: HybridBackupCommand
> > 2022-05-20 15:06:30,086Z Running command: CreateLiveSnapshotForVmCommand
> > 2. At the same time user power offs the vm
> > 2022-05-20 15:07:02,639Z Running command: ShutdownVmCommand
> > 3.The backup is failed
> > 2022-05-20 15:07:05,274Z Command CreateLiveSnapshotForVm id:
> > '44e0fba3-9a27-456b-86c6-a5ca24d944eb': execution was completed, the command
> > status is 'FAILED'
> > 4. then
> > Validation of action 'RemoveSnapshot' failed for user admin@internal-authz.
> > Reasons:
> > VAR__TYPE__SNAPSHOT,VAR__ACTION__REMOVE,
> > ACTION_TYPE_FAILED_VM_SNAPSHOT_TYPE_NOT_REGULAR
> > 
> > and
> > 2022-05-20 15:07:09,525Z ERROR EVENT_ID: VM_BACKUP_FAILED(10,792)
> 
> This sounds like bz 2080766 - the fix is being tested as part of 4.5.1
>  
> > 5.If user trys to start next backup it will be failed
> > 2022-05-20 15:10:18,709Z ERROR
> > [org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand] (default
> > task-24) [4fde0c6e-ae21-4fbb-b379-792b98f354b7] Command
> > 'org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand' failed:
> > CallableStatementCallback; SQL [{call updatesnapshotid(?, ?)}]; ERROR:
> > update or delete on table "snapshots" violates foreign key constraint
> > "fk_backups_snapshots" on table "vm_backups"
> >   Detail: Key (snapshot_id)=(c466b4d3-1d9c-41c4-977b-6360e46192a0) is still
> > referenced from table "vm_backups".
> >   Where: SQL statement "UPDATE snapshots
> >     SET snapshot_id = v_new_snapshot_id
> >     WHERE snapshot_id = v_snapshot_id"
> 
> Benny, can you please take a look at this part? maybe we should also detach
> the snapshot from the backup in this case?

yes, it looks like the reference prevented the creation

Comment 3 Evelina Shames 2022-06-14 10:06:18 UTC
I'm not able to reproduce this on engine-4.5.0.7-0.9.el8ev, can you pls add a more detailed reproduction flow?

The flow I tested:
1. Have a running VM
2. Start a full backup
3. When the auto-generated snapshot is being created -> power off the VM.

--> VM was powered off successfully and backup succeeded.

Comment 4 Evelina Shames 2022-06-14 12:54:07 UTC
(In reply to Evelina Shames from comment #3)
> I'm not able to reproduce this on engine-4.5.0.7-0.9.el8ev, can you pls add
> a more detailed reproduction flow?
> 
> The flow I tested:
> 1. Have a running VM
> 2. Start a full backup
> 3. When the auto-generated snapshot is being created -> power off the VM.
> 
> --> VM was powered off successfully and backup succeeded.

I managed to reproduce this with shutdown VM (instead of power-off VM).

Same flow was tested also on ovirt-engine-4.5.1-0.62.el8ev.noarch and passed successfully.

Moving to 'Verified'.

Comment 5 Sandro Bonazzola 2022-06-23 05:54:58 UTC
This bugzilla is included in oVirt 4.5.1 release, published on June 22nd 2022.
Since the problem described in this bug report should be resolved in oVirt 4.5.1 release, it has been closed with a resolution of CURRENT RELEASE.
If the solution does not work for you, please open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.