Bug 1145658 - Storage domain removal does not check if the storage domain contains any memory dumps.
Summary: Storage domain removal does not check if the storage domain contains any memo...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.4.1-1
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ovirt-4.4.5
: 4.4.5
Assignee: Bella Khizgiyaev
QA Contact: Evelina Shames
URL:
Whiteboard:
: 1208527 (view as bug list)
Depends On: 1150245
Blocks: 1547336 1520566
TreeView+ depends on / blocked
 
Reported: 2014-09-23 12:53 UTC by Roman Hodain
Modified: 2021-04-14 11:41 UTC (History)
25 users (show)

Fixed In Version: ovirt-engine-4.4.5.6
Doc Type: Bug Fix
Doc Text:
This release allows the proper removal of a storage domain containing memory dumps, either by moving the memory dumps to another storage domain or deleting the memory dumps from the snapshot.
Clone Of:
Environment:
Last Closed: 2021-04-14 11:39:53 UTC
oVirt Team: Storage
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1203663 0 None None None Never
Red Hat Product Errata RHSA-2021:1169 0 None None None 2021-04-14 11:41:00 UTC
oVirt gerrit 112629 0 master MERGED webadmin: add a warning on removing a Storage Domain with memory volumes 2021-02-17 14:57:13 UTC

Description Roman Hodain 2014-09-23 12:53:01 UTC
Description of problem:
	When the removal of a storage domain is triggered, it does not check if the
	storage domain contains memory images of VM snapshots.

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

How reproducible:
	100%

Steps to Reproduce:
	1. Create two storage domains
	2. Create a new VM
	3. Create snapshot including the memory image
	4. Remove the storage domain which does not contain the VM disks.
	5. Remove the snapshot

Actual results:
	The storage domain is removed and the snapshot removal fails

Expected results:
	It is not possible to remove the storage domain.

Comment 2 Allon Mureinik 2014-10-07 18:46:05 UTC
We need a proper way to model these objects before we can have any meaningful logic depend on them.
Flagged as blocked by bug 1150239 which can facilitate this, and postponed to 3.6.0.

Comment 3 Allon Mureinik 2014-10-07 18:55:37 UTC
Actually, we cannot block the domain's removal if the admin has no way to manage these volumes.
We need to resolve bug 1150242 and bug 1150245 first.

Comment 4 Michal Skrivanek 2015-01-29 08:35:58 UTC
we can also change the memory volume allocation logic to be predictable and go with e.g. the first disk (or any disk) of the VM. That should be enough to address most of the cases

Comment 5 Allon Mureinik 2015-01-29 08:47:41 UTC
(In reply to Michal Skrivanek from comment #4)
> we can also change the memory volume allocation logic to be predictable and
> go with e.g. the first disk (or any disk) of the VM. That should be enough
> to address most of the cases
See bug 1186230 - it covers this idea.

Comment 6 Roman Hodain 2015-01-30 07:19:53 UTC
Or we can display a drop down many and ask the customer to choose.

Comment 7 Allon Mureinik 2015-04-04 15:15:18 UTC
*** Bug 1208527 has been marked as a duplicate of this bug. ***

Comment 8 Allon Mureinik 2015-07-07 11:19:22 UTC
This depends (indirectly) on bug 1150239, which won't be available before 4.0.0.

Comment 9 Tal Nisan 2016-12-21 13:00:27 UTC
This bug depends on 2 RFEs that did not make it to 4.1, retargeting to 4.2

Comment 10 Allon Mureinik 2017-06-13 13:01:57 UTC
Tal, won't the work you're doing on disk content types in 4.2 handle this?

Comment 11 Tal Nisan 2017-06-14 08:13:24 UTC
It will handle the check so the domain will alert before removing or completely block it, not sure if in the scope of 4.2 we will also handle the moving of the memory dumps but I think it's safe to say that we will

Comment 12 Yaniv Kaul 2017-10-29 14:55:57 UTC
(In reply to Tal Nisan from comment #11)
> It will handle the check so the domain will alert before removing or
> completely block it, not sure if in the scope of 4.2 we will also handle the
> moving of the memory dumps but I think it's safe to say that we will

It seems to depend on 2 RFEs that are not targeted to 4.2. Will this one doable for 4.2?

Comment 13 Tal Nisan 2017-10-30 09:41:46 UTC
Most likely that it will be in 4.2

Comment 15 Yaniv Lavi 2018-03-05 09:20:08 UTC
Is the RFE on 4.2 to enable moving a memory volume enough to resolve this bug?

Comment 16 Marina Kalinin 2018-03-19 18:31:59 UTC
(In reply to Yaniv Lavi from comment #15)
> Is the RFE on 4.2 to enable moving a memory volume enough to resolve this
> bug?

Just to clarify - we are talking about this bz#1542118 here.

Comment 17 Marina Kalinin 2018-03-19 18:38:23 UTC
(In reply to Marina from comment #16)
> (In reply to Yaniv Lavi from comment #15)
> > Is the RFE on 4.2 to enable moving a memory volume enough to resolve this
> > bug?
> 
> Just to clarify - we are talking about this bz#1542118 here.

Yaniv,
I think this is a great question for Allon, actually.
If that RFE will help storage team implementing the need to perform storage removal in a clean way - then yes, otherwise - no.

Comment 18 Allon Mureinik 2018-03-20 15:57:34 UTC
(In reply to Marina from comment #17)
> (In reply to Marina from comment #16)
> > (In reply to Yaniv Lavi from comment #15)
> > > Is the RFE on 4.2 to enable moving a memory volume enough to resolve this
> > > bug?
> > 
> > Just to clarify - we are talking about this bz#1542118 here.
> 
> Yaniv,
> I think this is a great question for Allon, actually.
> If that RFE will help storage team implementing the need to perform storage
> removal in a clean way - then yes, otherwise - no.

We depend on two capabilities here:
1. Bug 1150245 - [RFE] Add facility to move a memory volume (already on QA). This is strictly the bare minimum to allow this RFE, but having the second one would make flows much easier:
2. The ability to remove a memory volume (bug 1150242 is a specific aspect of this - the general capability already exists.

Tal, I think once moving a memory volume is merged, this BZ can also be moved to MODIFIED.

Comment 19 Tal Nisan 2018-03-20 19:05:21 UTC
Yes, and most likely will be handled in 4.2.4 as well

Comment 22 Tal Nisan 2018-07-05 13:13:19 UTC
(In reply to Allon Mureinik from comment #18)
> (In reply to Marina from comment #17)
> > (In reply to Marina from comment #16)
> > > (In reply to Yaniv Lavi from comment #15)
> > > > Is the RFE on 4.2 to enable moving a memory volume enough to resolve this
> > > > bug?
> > > 
> > > Just to clarify - we are talking about this bz#1542118 here.
> > 
> > Yaniv,
> > I think this is a great question for Allon, actually.
> > If that RFE will help storage team implementing the need to perform storage
> > removal in a clean way - then yes, otherwise - no.
> 
> We depend on two capabilities here:
> 1. Bug 1150245 - [RFE] Add facility to move a memory volume (already on QA).
> This is strictly the bare minimum to allow this RFE, but having the second
> one would make flows much easier:
> 2. The ability to remove a memory volume (bug 1150242 is a specific aspect
> of this - the general capability already exists.
> 
> Tal, I think once moving a memory volume is merged, this BZ can also be
> moved to MODIFIED.

As stated, this depends on the ability to move memory volumes from one storage domain to another which was fixed and the ability to remove a memory volume from a snapshot (available from the main disks tab)

Comment 23 Dusan Fodor 2018-07-12 14:22:26 UTC
Please clone properly.

Comment 24 Elad 2018-07-12 14:59:20 UTC
Storage domain removal is allowed for a domain that has memory images of a VM snapshot, even when the VM is running.

Tal, according to the expected results from the bug description, it failed QA.

Comment 25 Elad 2018-07-12 14:59:44 UTC
Used:
rhvm-4.2.5.1_SNAPSHOT-74.gce67578.0.scratch.master.el7ev.noarch

Comment 26 Tal Nisan 2018-07-15 12:01:08 UTC
(In reply to Elad from comment #24)
> Storage domain removal is allowed for a domain that has memory images of a
> VM snapshot, even when the VM is running.
> 
> Tal, according to the expected results from the bug description, it failed
> QA.

We've introduced the work around for that, I can add a block of removing the storage domain but does it make sense to you?

Comment 27 Elad 2018-07-15 12:22:11 UTC
Frankly, not sure.
I think there are few options here:
1. To align the behavior to be the same as it is for regular disk image - restrict storage domain deactivation in case the domain holds a memory disk of a running VM. In this case, not sure if it makes sense as memory images are not RW while the VM is running.
2. To allow domain deactivation but not removal in case it has memory images. This will add more complexity to domain deatcivation/removal (which is already pretty complexed)
3. Add a warning upon domain deactivation. 

As the current behavior is to allow domain removal while it has memory images, do we have a fall back for snapshot preview in case the memory image doesn't exist?

Comment 28 Tal Nisan 2018-07-15 12:49:34 UTC
(In reply to Elad from comment #27)
> Frankly, not sure.
> I think there are few options here:
> 1. To align the behavior to be the same as it is for regular disk image -
> restrict storage domain deactivation in case the domain holds a memory disk
> of a running VM. In this case, not sure if it makes sense as memory images
> are not RW while the VM is running.
Exactly, doesn't really matter for a running VM
> 2. To allow domain deactivation but not removal in case it has memory
> images. This will add more complexity to domain deatcivation/removal (which
> is already pretty complexed)
> 3. Add a warning upon domain deactivation. 
> 
> As the current behavior is to allow domain removal while it has memory
> images, do we have a fall back for snapshot preview in case the memory image
> doesn't exist?
No, so in that case we should probably restrict if memory images exist, so it will have to wait for 4.2.6 then

Comment 29 Sandro Bonazzola 2019-01-28 09:40:43 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 32 Marina Kalinin 2019-12-17 21:47:26 UTC
Tal, can you please review this bug?

Comment 34 Marina Kalinin 2020-03-23 15:31:03 UTC
Discussing this with Tal's team, here is the summary:
- Moving those volumes cannot be part of storage storage domain removal process. Needs to be done manually by the admin, as a separate task.
- We can give a warning to the user, that there memory volumes on this storage domain, for VMs on other domains, and removing this domain without transferring the volumes, will cause snapshot removal on those VMs to fail.
- Should we allow the user to proceed with the removal of storage domain despite the warning or not?
- This check cannot be done via REST API, only in UI. 


Decision:
- The warning should be very clear and informative to the user.
In addition to disks UUID, include VM names, is possible, to make the decision for the user easier.
Log this warning to audit.log / engine.log

- In order to proceed with the removal of a storage domain despite the warning - require double check from the user to confirm. For instance, add a checkbox to check "Force remove the Storage Domain with external memory dumps".

- Rest API - add a warning to the Admin Guide, Storage Domain removal section about this as a known issue on Rest API. (New bug is needed, if we agree on this).

Tal, Avihai, Roman, Peter - if any reservations, please add here, otherwise, let's go with this decision.

Comment 35 Gordon Watson 2020-03-23 21:01:09 UTC
In a quick test here, I physically removed the memory volumes associated with a snapshot, then performed a live merge of that snapshot. Errors were reported about the missing volumes, but the snapshot deletion operation was successful. I repeated this with Cold Merge, with the same result.

Comment 36 Lukas Svaty 2020-03-24 12:57:31 UTC
Regressions needs to be fixed till next milestone 4.4.0, retargeting.

Comment 38 Peter Lauterbach 2020-03-31 16:17:19 UTC
Since there is a workaround, this should not block RHV 4.4 GA.

Comment 40 Bella Khizgiyaev 2021-02-21 10:39:23 UTC
After working on the tests for the new query a problematic flow was discovered so a new patch with a fix was posted to solve this issue.

Comment 41 Bella Khizgiyaev 2021-02-24 11:20:18 UTC
All fixes were merged.

Steps to verify that the new changes are working (works from UI only):
1. create VM and power on the machine.
2. create a snapshot with memory for the VM.
3. move one of the snapshot volumes (metadata or memory) to a different storage domain.
4. try to detach the SD to which you move the snapshot disk (once from the DC page and once from the SD page), a warning message should be raised with the disk id.

Maybe better to check multi disks for SD and see that all are printed right, 
also, try to detach more than one SD, and check that all disks are displayed for all of the SD.

Comment 45 Evelina Shames 2021-03-10 07:07:35 UTC
(In reply to Bella Khizgiyaev from comment #41)
> All fixes were merged.
> 
> Steps to verify that the new changes are working (works from UI only):
> 1. create VM and power on the machine.
> 2. create a snapshot with memory for the VM.
> 3. move one of the snapshot volumes (metadata or memory) to a different
> storage domain.
> 4. try to detach the SD to which you move the snapshot disk (once from the
> DC page and once from the SD page), a warning message should be raised with
> the disk id.
> 
> Maybe better to check multi disks for SD and see that all are printed right, 
> also, try to detach more than one SD, and check that all disks are displayed
> for all of the SD.

Verified with the above steps on ovirt-engine-4.4.5.7-0.1.

Moving to 'Verified'.

Comment 50 errata-xmlrpc 2021-04-14 11:39:53 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 (Moderate: RHV Manager (ovirt-engine) 4.4.z [ovirt-4.4.5] security, bug fix, enhancement), 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/RHSA-2021:1169


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