Bug 1600788

Summary:	Engine allows deleting HE volumes.
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Germano Veit Michel <gveitmic>
Component:	ovirt-engine	Assignee:	Tal Nisan <tnisan>
Status:	CLOSED ERRATA	QA Contact:	Nikolai Sednev <nsednev>
Severity:	urgent	Docs Contact:
Priority:	low
Version:	4.2.4	CC:	ebenahar, gveitmic, lsurette, mkalinin, Rhev-m-bugs, sborella, srevivo, stirabos, tnisan
Target Milestone:	ovirt-4.3.3	Keywords:	Triaged
Target Release:	4.3.0
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	ovirt-engine-4.3.3.1	Doc Type:	If docs needed, set a value
Doc Text:	This release provides a check to evaluate self-hosted engine volumes prior to deleting the self-hosted engine volumes.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-08 12:37:51 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:	1520566, 1547768

Description Germano Veit Michel 2018-07-13 03:51:03 UTC

Description of problem:

As described in BZ1543218, in RHV 4.1 the engine allowed:

1. Import HE Disks from the HE SD
2. Delete/Move them = HE setup is broken

Now that BZ is closed with errata. I can see the disks are now named and they show up in a fresh installation automatically. That's good.

But this means step 1 is not necessary anymore in RHV 4.2, one can go straight to step 2 and "manage" these disks, breaking the setup is even easier than before.

Version-Release number of selected component (if applicable):
ovirt-engine-4.2.4.5-1.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. Fresh Install
2. Delete HE volumes

Actual results:
HE is broken

Expected results:
Do not allow the user to manage these images.

Additional info:
2018-07-13 13:40:48,394+10 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-740) [b02d43d9-1641-431a-96e5-892de8c10217] EVENT_ID: USER_FINISHED_REMOVE_DISK(2,014), Disk he_sanlock was successfully removed from domain hosted_storage (User admin@internal-authz).

2018-07-13 13:41:15,440+10 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-750) [4d7a475d-e03e-45e2-8609-67433c833f54] EVENT_ID: USER_FINISHED_REMOVE_DISK(2,014), Disk HostedEngineConfigurationImage was successfully removed from domain hosted_storage (User admin@internal-authz).

2018-07-13 13:47:37,684+10 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-855) [841e241c-3890-4c56-97be-3569049325e6] EVENT_ID: USER_FINISHED_REMOVE_DISK(2,014), Disk he_metadata was successfully removed from domain hosted_storage (User admin@internal-authz).

Comment 2 Yaniv Lavi 2018-07-16 08:01:18 UTC

It is very unlikely that the user would delete these disks due. Let's try to add some validation for the next release.

Comment 5 Yaniv Lavi 2018-08-01 13:20:30 UTC

Has BZ #1543218 solved this?

Comment 6 Germano Veit Michel 2018-08-01 22:33:41 UTC

(In reply to Yaniv Lavi from comment #5)
> Has BZ #1543218 solved this?

No. As explained in comment #0, BZ1543218 was closed with errata but IHMO it does not fix the problem. The fix was partial at best, I dont understand why that BZ was closed.

Comment 9 Sandro Bonazzola 2019-01-28 09:39:46 UTC

This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Comment 11 Tal Nisan 2019-01-28 16:32:29 UTC

Simone, is there any way we can block this? I'm not a big fan of doing it according to the disk alias

Comment 12 Simone Tiraboschi 2019-01-28 16:48:20 UTC

(In reply to Tal Nisan from comment #11)
> Simone, is there any way we can block this? I'm not a big fan of doing it
> according to the disk alias

For the same reason on the engine VM itself we are using a special value (6) in the origin field at DB level.
I don't know if there is any field on tables that we can abuse in the same way to flag the disks as specials without side effects.

Comment 13 Tal Nisan 2019-02-26 13:22:24 UTC

We shall solve this by using a new content type of hosted engine disk and as precaution we'll also check the disk alias to comply with older versions.

Comment 14 RHV bug bot 2019-03-29 11:14:44 UTC

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

[Project 'vdsm'/Component 'ovirt-engine' mismatch]

For more info please contact: rhv-devops

Comment 16 Nikolai Sednev 2019-04-02 15:15:55 UTC

I tried to delete HE-VM's disks, one by one and got:
"Operation Canceled
Error while executing action: Cannot remove Virtual Disk. The disk is a part of Hosted Engine."

Works for me on these components:
ovirt-hosted-engine-setup-2.3.7-1.el7ev.noarch
ovirt-hosted-engine-ha-2.3.1-1.el7ev.noarch
rhvm-appliance-4.3-20190328.1.el7.x86_64
Linux 3.10.0-957.10.1.el7.x86_64 #1 SMP Thu Feb 7 07:12:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 7.6 (Maipo)

Tested on RHEL hosts.

Moving to verified.

Comment 18 errata-xmlrpc 2019-05-08 12:37:51 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1085