Description of problem: LVs device nodes (/dev/vg-name/lv-name) are being left stale after deactivating a storage domain. Currently, the LVs are deactivate only on the SPM upon removing the domain (it's being done on 'blockSD -> format'). To deactivate the LVs, 'blockSD -> invalidate' can be used. Version-Release number of selected component (if applicable): 3.5 (probably earlier versions as well) How reproducible: 100% Steps to Reproduce: Move a block storage domain to maintenance. Actual results: - Relevant LVs device nodes [*] aren't being cleared. - dmsetup mappings aren't cleared and can't be flushed. Expected results: The LVs device nodes should be cleared. Additional info: See symptoms of the issue in bug 1063871, bug 1154425 and bug 998112. [*] # ls -l /dev/7b367dbb-1d95-405b-8a81-140c78bf90a2/ total 0 lrwxrwxrwx. 1 root root 8 Nov 13 15:41 ids -> ../dm-53 lrwxrwxrwx. 1 root root 8 Nov 13 15:40 inbox -> ../dm-56 lrwxrwxrwx. 1 root root 8 Nov 13 15:40 leases -> ../dm-54 lrwxrwxrwx. 1 root root 8 Nov 13 15:40 master -> ../dm-60 lrwxrwxrwx. 1 root root 8 Nov 13 15:40 metadata -> ../dm-50 lrwxrwxrwx. 1 root root 8 Nov 13 15:40 outbox -> ../dm-55
Note that LVs deactivation should be done in all connected hosts. However, deactivate domain is currently an SPM command. Hence, the fix should probably be pended on SPM removal.
(In reply to Daniel Erez from comment #1) > Note that LVs deactivation should be done in all connected hosts. However, > deactivate domain is currently an SPM command. Hence, the fix should > probably be pended on SPM removal. Assigning to Adam to consider this one too - not sure this is really 3.6 scope though.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high
Adam - is it going in as part of SPM removal, or before that? (BTW, this bug is missing the user consequence - what happens when they are not deactivated).
(In reply to Yaniv Kaul from comment #5) > Adam - is it going in as part of SPM removal, or before that? > (BTW, this bug is missing the user consequence - what happens when they are > not deactivated). This is really independent of SPM removal. The existing deactivate storage domain flow should be updated to remove the devices from the host(s).
(In reply to Adam Litke from comment #6) > (In reply to Yaniv Kaul from comment #5) > > Adam - is it going in as part of SPM removal, or before that? > > (BTW, this bug is missing the user consequence - what happens when they are > > not deactivated). > > This is really independent of SPM removal. The existing deactivate storage > domain flow should be updated to remove the devices from the host(s). This not possible, as lvs are activated when creating a storage domain object, so lvs will be activated again when storage domain object is accessed. The solution requires rewrite of the this part in vdsm.
(In reply to Nir Soffer from comment #7) > (In reply to Adam Litke from comment #6) > > (In reply to Yaniv Kaul from comment #5) > > > Adam - is it going in as part of SPM removal, or before that? > > > (BTW, this bug is missing the user consequence - what happens when they are > > > not deactivated). > > > > This is really independent of SPM removal. The existing deactivate storage > > domain flow should be updated to remove the devices from the host(s). > > This not possible, as lvs are activated when creating a storage domain > object, so lvs will be activated again when storage domain object is > accessed. > > The solution requires rewrite of the this part in vdsm. Pushing out based on this conclusion - out of scope for 4.0.
Similar to bug 1331978, which give more details no how harmful is this issue.
(In reply to Nir Soffer from comment #10) > Similar to bug 1331978, which give more details no how harmful is this issue. Seems this is more of the bug than an RFe. Setting to 4.0 so QE can verify once bug 1331978 is fixed.
(In reply to Allon Mureinik from comment #11) > (In reply to Nir Soffer from comment #10) > > Similar to bug 1331978, which give more details no how harmful is this issue. > Seems this is more of the bug than an RFe. Setting to 4.0 so QE can verify > once bug 1331978 is fixed. devel-ack+ then, please.
oVirt 4.0 beta has been released, moving to RC milestone.
*** Bug 1157673 has been marked as a duplicate of this bug. ***
Any news on this? I don't think it's a 4.0 candidate?
(In reply to Yaniv Kaul from comment #15) > Any news on this? I don't think it's a 4.0 candidate? The issue here is essentially the same fix as bug 1331978, which seems feasable for 4.0.
4.0.6 has been the last oVirt 4.0 release, please re-target this bug.
This does not depend on bug 1331978. The issue is no proper storage domain life cycle in vdsm. The connection to bug 1331978 is I posted some patches to fix this issue to that bug. These patches needs more work, but they are too risky for stable version, so this bug cannot be fixed in 4.0.
Pushing out. Let's fix this properly in 4.2, and if the resulting patch is safe enough, we can always backport it to 4.1.z.
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.
We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it. If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.
This was fixed in master today by: https://gerrit.ovirt.org/c/105816/ Moving to modified.
This bug is targeted to 4.4.3 and in modified state. can we re-target to 4.4.0 and move to QA?
Moved to 4.4.0 since bug is fixed in current code.
Verified on: ovirt-engine-4.4.0-0.33.master.el8ev.noarch vdsm-4.40.13-1.el8ev.x86_64 Testing first flow with ISCSI: BEFORE SD DEACTIVATION: [root@storage-ge5-vdsm1 ~]# lsblk | grep 360002ac0000000000000003200021f6b -C5 sdc 8:32 0 150G 0 disk └─360002ac0000000000000003200021f6b 253:3 0 150G 0 mpath ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-ids 253:14 0 128M 0 lvm ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-leases 253:16 0 2G 0 lvm ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-metadata 253:22 0 128M 0 lvm ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-inbox 253:23 0 128M 0 lvm ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-outbox ################################################### AFTER SD DEATIVATION: [root@storage-ge5-vdsm1 ~]# lsblk | grep 360002ac0000000000000003200021f6b -C5 253:11 0 1G 0 lvm sdc 8:32 0 150G 0 disk └─360002ac0000000000000003200021f6b 253:3 0 150G 0 mpath sdd 8:48 0 150G 0 disk └─360002ac0000000000000003300021f6b WE CAN SEE THAT THE MAPPING FOR LV'S FOR sdc DEVICE ARE GONE Reactivating the SD brings back the mapping. ********************************************************** Testing second flow with ISCSI: BEFORE HOST DEACTIVATION: [root@storage-ge5-vdsm2 ~]# lsblk | grep 360002ac0000000000000003200021f6b -C5 sdc 8:32 0 150G 0 disk └─360002ac0000000000000003200021f6b 253:2 0 150G 0 mpath ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-ids 253:20 0 128M 0 lvm ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-leases 253:21 0 2G 0 lvm ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-metadata 253:22 0 128M 0 lvm ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-inbox 253:23 0 128M 0 lvm ├─e8eb95fc--1445--4624--9c8d--50a384cfba80-outbox 253:24 0 128M 0 lvm AFTER HOST DEACTIVATION: [root@storage-ge5-vdsm2 ~]# lsblk | grep 360002ac0000000000000003200021f6b -C5 [root@storage-ge5-vdsm2 ~]# Reactivating the HOST brings back the mapping.
*** Bug 1544370 has been marked as a duplicate of this bug. ***
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 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.