I haven't reproduced it yet, but looking at the 4.2 code, it does seem possible since it looks like in 4.2 support for passing the snapshot id via REST[1] was added while in 4.1 a new UUID was always generated. So my guess is it is probably a combination of v3 not supporting passing the image UUID and 4.2 expecting it that led to this unfortunate outcome

I have managed to reproduce it using this request:

POST http://localhost:8080/ovirt-engine/api/v3/vms/502c2717-45dc-4580-abed-40c7c4e613d1/snapshots


<snapshot>
    <description>snap</description>
    <vm id="66e3a14a-ded0-4166-b3cc-16fb5f271c71"/>
    <disks>
    	<disk id="b6287fc3-38a2-45ff-938c-04d0a470f7be">
			<image_id>0bf85090-2785-442c-971f-5e6ab09845f3</image_id>
    	</disk>
    </disks>
</snapshot>

The key here being is that image_id is passed, looking at their script in the case:
                    vm.snapshots.add(
                        params.Snapshot(
                            description=config.get_snapshot_description(),
                            vm=vm,
                            disks=discoSnap,
                            persist_memorystate=config.get_persist_memorystate(),
                        )
                    )

While I am not familiar with APIv3, it probably means discoSnap contains the entire disk definition along with the image id which is the reason why it was used by the engine 

While in V4 we would do something like this:
types.Snapshot(
        description=SNAPSHOT_DESC_1,
        persist_memorystate=False,
        disk_attachments=[
            types.DiskAttachment(
                disk=types.Disk(
                    id=disk.id
                )
            )
        ]
    )

Which sends only the disk's id, perhaps something similar can be done in V3


Regardless, we need to handle this in the engine as well to avoid such failures


[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1405805

(In reply to Benny Zlotnik from comment #4)
> I haven't reproduced it yet, but looking at the 4.2 code, it does seem
Sorry for not proofreading, obviously I've managed to reproduce it by the time the comment was posted :)

Ahhh, one needs to send the VM configuration to trigger it!

Could you please consider 4.2.z this? When the roll-back kicks in, it removes the "new image", which is the same as the "old image" from the DB. Several entries in several tables are removed, its not trivial to put everything back.
Thanks Benny

Just to publicly document here as well, the following tables need to be repopulated with the lines removed by the roll-back mechanism of the failed snapshot:

base_disks
images
snapshots
image_storage_domain_map
disk_vm_element
vm_ovf_generations (OVF corrected, adding the disk back)

WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.2.z': '?'}', ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.2.z': '?'}', ]

For more info please contact: rhv-devops

Hi Benny,
Can you provide the steps to reproduce this bug?
Please move this bug to ON_QA.

Thank you

(In reply to Yosi Ben Shimon from comment #9)
> Hi Benny,
> Can you provide the steps to reproduce this bug?
> Please move this bug to ON_QA.
> 
> Thank you

You can:
1. Create a VM with a disk
2. Create a snapshot
3. Send a request (change the UUIDs to match yours)
POST http://localhost:8080/ovirt-engine/api/v3/vms/502c2717-45dc-4580-abed-40c7c4e613d1/snapshots


<snapshot>
    <description>snap</description>
    <vm id="66e3a14a-ded0-4166-b3cc-16fb5f271c71"/>
    <disks>
    	<disk id="b6287fc3-38a2-45ff-938c-04d0a470f7be">
			<image_id>0bf85090-2785-442c-971f-5e6ab09845f3</image_id>
    	</disk>
    </disks>
</snapshot>

vm id=<your VM id>
disk id=<your disk id>
image_id=<the image id of the created snapshot>

Tested using:
ovirt-engine-4.2.5.2-0.1.el7ev.noarch

I used the steps that Benny provided in comment #10 and the actual result is:

- The response on the REST API was:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<fault>
    <reason>Operation Failed</reason>
    <detail>[Cannot create Snapshot. Image IDs 	a964b123-57b0-4086-aef5-b6a1a052ae24 are already used by a snapshot.]</detail>
</fault>


- On the engine log:

2018-07-25 16:29:43,544+03 INFO  [org.ovirt.engine.core.bll.AddDeprecatedApiEventCommand] (default task-12) [219bc3e3] Running command: AddDeprecatedApiEventCommand internal: false.
2018-07-25 16:29:43,660+03 INFO  [org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand] (default task-12) [77653f00-517a-4367-8f2e-629bf3d9216d] Lock Acquired to object 'EngineLock:{exclusiveLocks='[e7e70c77-4aee-4907-86a2-d0e3e27156bd=VM]', sharedLocks=''}'
2018-07-25 16:29:43,692+03 WARN  [org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand] (default task-12) [77653f00-517a-4367-8f2e-629bf3d9216d] Validation of action 'CreateSnapshotForVm' failed for user admin@internal-authz. Reasons: VAR__ACTION__CREATE,VAR__TYPE__SNAPSHOT,ACTION_TYPE_FAILED_VM_SNAPSHOT_IMAGE_ALREADY_EXISTS,$ImageIds 	a964b123-57b0-4086-aef5-b6a1a052ae24,$ImageIds_COUNTER 1
2018-07-25 16:29:43,693+03 INFO  [org.ovirt.engine.core.bll.snapshots.CreateSnapshotForVmCommand] (default task-12) [77653f00-517a-4367-8f2e-629bf3d9216d] Lock freed to object 'EngineLock:{exclusiveLocks='[e7e70c77-4aee-4907-86a2-d0e3e27156bd=VM]', sharedLocks=''}'
2018-07-25 16:29:43,715+03 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-12) [] Operation Failed: [Cannot create Snapshot. Image IDs 	a964b123-57b0-4086-aef5-b6a1a052ae24 are already used by a snapshot.]
2018-07-25 16:29:43,730+03 INFO  


Moving to VERIFIED

Benny / Yosi,

This bug is on verified and 4.2.5 is out.
Why is this bug still open?
Who can confirm the correct status of it?

Thank you!

Anton, this bug as well, what shall we do with it? It was not moved to ON_QA and I'm assuming not in the Errata as well

https://access.redhat.com/errata/RHBA-2018:2471

sync2jira

sync2jira