Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1542423

Summary:	Distinguish between replication errors
Product:	[oVirt] vdsm	Reporter:	Benny Zlotnik <bzlotnik>
Component:	Core	Assignee:	Benny Zlotnik <bzlotnik>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Kevin Alon Goldblatt <kgoldbla>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.20.15	CC:	amureini, bugs, bzlotnik, ebenahar, lveyde, tnisan
Target Milestone:	ovirt-4.2.2	Flags:	rule-engine: ovirt-4.2+
Target Release:	4.20.18
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	vdsm v4.20.18	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-04-05 09:39:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1517540

Description Benny Zlotnik 2018-02-06 10:46:59 UTC

Description of problem:
Currently, in diskReplicateFinish when a replication is not progress or when the VM has an attribute of a replication in progress (diskReplicate attribute) the same "Drive replication error" will be returned to the engine.

This makes it impossible to perform a cleanup in case of a failed live storage migration attempt.

To resolve this it is required to have a separate error returned to the engine in case the replication is not in progress to allow a cleanup.

Otherwise, the user will have to perform the target cleanup manually in order to make another attempt at a live storage migration.

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


How reproducible:
100%

Steps to Reproduce:
1. Start LSM
2. Once we reach the disk replication starts we abort the blockjob manually,
can be done with virsh blockjob <dom> <path> --abort

Actual results:
The engine will attempt to finish the replication if it succeeds, it will clean up the target SD, if it will not, a clean up will not be attempted. The latter happens in described scenario 

Expected results:
Engine should attempt a clean up if the replication was not in progress.

Additional info:

Comment 4 Kevin Alon Goldblatt 2018-04-03 12:01:49 UTC

Verified with the following code:
----------------------------------------
ovirt-engine-4.2.2.6-0.1.el7.noarch
vdsm-4.20.23-1.el7ev.x86_64


Verified with the following scenario:
-------------------------------------------
Steps to Reproduce:
1. Start LSM
2. Once we reach the disk replication starts we abort the blockjob manually,
can be done with virsh blockjob <dom> <path> --abort >>>>>
Engine cleans up the replication that was not in progress.
3. Moved the disk again after the previous failed move >>>>> works fine



Moving to VERIFIED

Comment 6 Sandro Bonazzola 2018-04-05 09:39:34 UTC

This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.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.