Description of problem: further to bug 2080766, when creating a snapshot during backup finalization it causes the auto-generated snapshot not to be removed with no clear message. The message we see in the UI is that there was some possible failure during the snapshot removal: "Possible failure while removing a snapshot that was generated automatically during backup of VM 'golden_env_mixed_virtio_2_0'. The snapshot may be removed manually" and that the backup failed: "Backup c64ddaec-0d1f-45e0-9269-91e805db84d2 for VM golden_env_mixed_virtio_2_0 failed" Version-Release number of selected component (if applicable): engine-4.5.1-0.62.el8ev How reproducible: always. Steps to Reproduce: 1. Create a VM from rhel8.6 template and run it 2. Run backup_vm.py SDK example 3. When it starts finalizing the backup, create a live snapshot Actual results: The backup operation succeeds but the backup command fails: SDK script finishes successfully, engine throws an error that backup failed. Expected results: We should see a clear message on the UI that the backup operation succeeded and the problem is only with removing the auto-generated snapshot. Additional info:
Evelina, you have got the following message: "Possible failure while removing a snapshot that was generated automatically during backup of VM 'golden_env_mixed_virtio_2_0'. The snapshot may be removed manually" didn't it appear in the UI?
I would let go of "possible" - we did detect an error in removing snapshot, so it's not "possible" - it happened. Perhaps also change the "may" to "can", as to me "may" implies that the system might do that automatically which is not the case. Or "You may remove...."
(In reply to Michal Skrivanek from comment #2) > I would let go of "possible" - we did detect an error in removing snapshot, > so it's not "possible" - it happened. > Perhaps also change the "may" to "can", as to me "may" implies that the > system might do that automatically which is not the case. Or "You may > remove...." The reason for phrasing it that way was that we cannot say for sure what happened to the volumes (unless we check them) - we know that we didn't get an indication of a successful removal but it may be that the operation succeeded and we didn't get the task in succeed status so we wanted to be more careful with the message but the likelihood of such a case is pretty low, we can change it if you think it's important the more important part of this issue (now reflected in the title) is that the backup command appears to fail. we thought of two ways to handle that: 1. to wait for an on going operation to finish before initiating remove-snapshot 2. to generate an audit log that indicates the backup has succeeded (or no audit log at all) in case we just failed to remove the auto generated snapshot for the backup
(In reply to Arik from comment #3) > 2. to generate an audit log that indicates the backup has succeeded (or no > audit log at all) in case we just failed to remove the auto generated > snapshot for the backup The option above was chosen, the fix is included in 4.5.2 already
This bug has low overall severity and passed an automated regression suite, and is not going to be further verified by QE. If you believe special care is required, feel free to re-open to ON_QA status.
This bugzilla is included in oVirt 4.5.2 release, published on August 10th 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.2 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.