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.
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.
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.
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
(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.
Or we can display a drop down many and ask the customer to choose.
*** Bug 1208527 has been marked as a duplicate of this bug. ***
This depends (indirectly) on bug 1150239, which won't be available before 4.0.0.
This bug depends on 2 RFEs that did not make it to 4.1, retargeting to 4.2
Tal, won't the work you're doing on disk content types in 4.2 handle this?
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
(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?
Most likely that it will be in 4.2
Is the RFE on 4.2 to enable moving a memory volume enough to resolve this bug?
(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.
(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.
(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.
Yes, and most likely will be handled in 4.2.4 as well
(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)
Please clone properly.
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.
Used: rhvm-4.2.5.1_SNAPSHOT-74.gce67578.0.scratch.master.el7ev.noarch
(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?
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?
(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
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.
Tal, can you please review this bug?
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.
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.
Regressions needs to be fixed till next milestone 4.4.0, retargeting.
Since there is a workaround, this should not block RHV 4.4 GA.
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.
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.
(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'.
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