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

Bug 1117406

Summary: Old block storage domain's VG's & LV's don't get cleared if the old the storage domain's Luns are being used as direct Luns
Product: [Retired] oVirt Reporter: Ori Gofen <ogofen>
Component: vdsmAssignee: Allon Mureinik <amureini>
Status: CLOSED NOTABUG QA Contact: Ori Gofen <ogofen>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.5CC: acanan, acathrow, amureini, bazulay, bugs, gklein, iheim, mgoldboi, ogofen, yeylon
Target Milestone: ---Keywords: Triaged
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-04 14:54:22 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:
Attachments:
Description Flags
image none

Description Ori Gofen 2014-07-08 15:28:21 UTC
Description of problem:

The operation of attaching "dirty Luns" (Luns containing previous domain) as direct Luns to a vm doesn't clear Lun's virtual group or logical volumes (that belong to the old domain),the result is redundant virtual groups and logical volumes.

[root@camel-vdsc ~]# vgs
  VG                                   #PV #LV #SN Attr   VSize   VFree 
  872ee2b5-8865-452b-93f1-8361d15c68f6   1   6   0 wz--n-  29.62g 25.75g
  a00f1dab-abc4-4573-bef7-3ab3c27221ea   2   6   0 wz--n-  59.25g 55.38g
  a2cf8c0e-448b-4965-8fab-ecebb7510eaf   1   6   0 wz--n-  29.62g 25.75g
  e364f587-7471-40f4-a497-915c13c6a223   2   6   0 wz--n-  59.25g 55.38g
  vg0                                    1   2   0 wz--n- 232.69g     0 

 LV       VG                                   Attr       LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  ids      872ee2b5-8865-452b-93f1-8361d15c68f6 -wi------- 128.00m                                             
  inbox    872ee2b5-8865-452b-93f1-8361d15c68f6 -wi------- 128.00m                                             
  leases   872ee2b5-8865-452b-93f1-8361d15c68f6 -wi-------   2.00g                                             
  master   872ee2b5-8865-452b-93f1-8361d15c68f6 -wi-------   1.00g                                             
  metadata 872ee2b5-8865-452b-93f1-8361d15c68f6 -wi------- 512.00m                                             
  outbox   872ee2b5-8865-452b-93f1-8361d15c68f6 -wi------- 128.00m                                             
  ids      a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi------- 128.00m                                             
  inbox    a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi------- 128.00m                                             
  leases   a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi-------   2.00g                                             
  master   a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi-------   1.00g                                             
  metadata a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi------- 512.00m                                             
  outbox   a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi------- 128.00m                                             
  ids      a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi----- 128.00m                                             
  inbox    a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi------ 128.00m                                             
  leases   a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi------   2.00g                                             
  master   a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi------   1.00g                                             
  metadata a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi------ 512.00m                                             
  outbox   a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi------ 128.00m                                             
  ids      e364f587-7471-40f4-a497-915c13c6a223 -wi----- 128.00m                                             
  inbox    e364f587-7471-40f4-a497-915c13c6a223 -wi------ 128.00m                                             
  leases   e364f587-7471-40f4-a497-915c13c6a223 -wi------   2.00g                                             
  master   e364f587-7471-40f4-a497-915c13c6a223 -wi------   1.00g                                             
  metadata e364f587-7471-40f4-a497-915c13c6a223 -wi------ 512.00m                                             
  outbox   e364f587-7471-40f4-a497-915c13c6a223 -wi------ 128.00m                                             
  lv_root  vg0                                  -wi----- 224.88g                                             
  lv_swap  vg0                                  -wi--   7.81g  

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

How reproducible:
100%

Steps to Reproduce:
Setup:Have dirty Luns,have a dc with nfs master.

1.login host to iscsi iqn (don't create iscsi domain)
2.verify the existence of old VG's and LV's (execute vgs,lvs)
3.execute pvs command (view which Luns contain old storage domain)
4.attach those Luns as direct Luns to a vm

Actual results:
a Host reports on redundant VG's and LV's which are now used as disks on a virtual guest

Expected results:
vdsm should not display VG's | LV's  which won't have no use
Additional info:

Comment 1 Allon Mureinik 2014-07-08 19:10:02 UTC
(In reply to Ori from comment #0)
> Actual results:
> a Host reports on redundant VG's and LV's which are now used as disks on a
> virtual guest
> 
> Expected results:
> vdsm should not display VG's | LV's  which won't have no use
> Additional info:

I'm not sure I understand the issue. Where is this reported? By manually running vgs?

Comment 2 Ori Gofen 2014-07-09 09:48:52 UTC
Created attachment 916690 [details]
image

For example here is a Setup that all it's Luns are used as disks(direct Luns) or storage domains (see image).

the psql reports on four domains,two of them are iscsi domains

engine=# SELECT id,storage,storage_name FROM storage_domains;
                  id                  |                storage                 |      storage_name      
--------------------------------------+----------------------------------------+------------------------
072fbaa1-08f3-4a40-9f34-a5ca22dd1d74| ceab03af-7220-4d42-8f5c-9b557f5d29af|ovirt-image-repository
da5103db-671e-4fa8-a420-db3d30d38efa| 38e1802d-b157-435e-ade6-2f217c8a124f|nfs
e364f587-7471-40f4-a497-915c13c6a223| juVJ1V-To3d-mXha-WEUD-a4Ik-uier-TBmo9y|ISCSI
e180bb5f-9361-4f68-9690-9a2f0098a02c| 5K597a-jwqp-3XNB-v9SQ-VkiZF7ua-O4UB5g| ISCSI_1
(4 rows)

the db doesn't report about images found on both domains

engine=# SELECT image_guid,disk_alias FROM images_storage_domain_view WHERE storage_name ='ISCSI';
              image_guid              | disk_alias 
--------------------------------------+------------
 2d1e9ac8-777b-4ea3-a4dd-70703d8cb091 | OVF_STORE
 aea5c788-2b9b-4570-90eb-2fee5b0fbc98 | OVF_STORE
(2 rows)

engine=# SELECT image_guid,disk_alias FROM images_storage_domain_view WHERE storage_name ='ISCSI_1';
 image_guid | disk_alias 
------------+------------
(0 rows)

thus a reasonable user doesn't expect an output of so many unrecognised LV's

root@camel-vdsc ~]# lvs
  LV                                   VG                                   Attr       LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  ids                                  872ee2b5-8865-452b-93f1-8361d15c68f6 -wi------- 128.00m                                             
  inbox                                872ee2b5-8865-452b-93f1-8361d15c68f6 -wi------- 128.00m                                             
  leases                               872ee2b5-8865-452b-93f1-8361d15c68f6 -wi-------   2.00g                                             
  master                               872ee2b5-8865-452b-93f1-8361d15c68f6 -wi-------   1.00g                                             
  metadata                             872ee2b5-8865-452b-93f1-8361d15c68f6 -wi------- 512.00m                                             
  outbox                               872ee2b5-8865-452b-93f1-8361d15c68f6 -wi------- 128.00m                                             
  ids                                  a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi------- 128.00m                                             
  inbox                                a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi------- 128.00m                                             
  leases                               a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi-------   2.00g                                             
  master                               a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi-------   1.00g                                             
  metadata                             a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi------- 512.00m                                             
  outbox                               a00f1dab-abc4-4573-bef7-3ab3c27221ea -wi------- 128.00m                                             
  edc4139e-1d2a-4672-9774-e6f1cb4acaf7 a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi------- 128.00m                                             
  f359a1b8-f8d6-4f60-a3db-1fd3ed58874a a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi------- 128.00m                                             
  ids                                  a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi-a----- 128.00m                                             
  inbox                                a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi-a----- 128.00m                                             
  leases                               a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi-a-----   2.00g                                             
  master                               a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi-a-----   1.00g                                             
  metadata                             a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi-a----- 512.00m                                             
  outbox                               a2cf8c0e-448b-4965-8fab-ecebb7510eaf -wi-a----- 128.00m                                             
  ids                                  e180bb5f-9361-4f68-9690-9a2f0098a02c -wi-ao---- 128.00m                                             
  inbox                                e180bb5f-9361-4f68-9690-9a2f0098a02c -wi-a----- 128.00m                                             
  leases                               e180bb5f-9361-4f68-9690-9a2f0098a02c -wi-a-----   2.00g                                             
  master                               e180bb5f-9361-4f68-9690-9a2f0098a02c -wi-a-----   1.00g                                             
  metadata                             e180bb5f-9361-4f68-9690-9a2f0098a02c -wi-a----- 512.00m                                             
  outbox                               e180bb5f-9361-4f68-9690-9a2f0098a02c -wi-a----- 128.00m                                             
  2d1e9ac8-777b-4ea3-a4dd-70703d8cb091 e364f587-7471-40f4-a497-915c13c6a223 -wi------- 128.00m                                             
  aea5c788-2b9b-4570-90eb-2fee5b0fbc98 e364f587-7471-40f4-a497-915c13c6a223 -wi------- 128.00m                                             
  ids                                  e364f587-7471-40f4-a497-915c13c6a223 -wi-ao---- 128.00m                                             
  inbox                                e364f587-7471-40f4-a497-915c13c6a223 -wi-a----- 128.00m                                             
  leases                               e364f587-7471-40f4-a497-915c13c6a223 -wi-a-----   2.00g                                             
  master                               e364f587-7471-40f4-a497-915c13c6a223 -wi-a-----   1.00g                                             
  metadata                             e364f587-7471-40f4-a497-915c13c6a223 -wi-a----- 512.00m                                             
  outbox                               e364f587-7471-40f4-a497-915c13c6a223 -wi-a----- 128.00m                                             
  lv_root                              vg0                                  -wi-ao---- 224.88g                                             
  lv_swap                              vg0                                  -wi-ao----   7.81g         

and 5 block domain VG's while his setup contains only two iscsi domains and all other Luns are being used as direct disks to vm's

[root@camel-vdsc ~]# vgs
  VG                                   #PV #LV #SN Attr   VSize   VFree  
  872ee2b5-8865-452b-93f1-8361d15c68f6   1   6   0 wz--n-  29.62g  25.75g
  a00f1dab-abc4-4573-bef7-3ab3c27221ea   2   6   0 wz--n-  59.25g  55.38g
  a2cf8c0e-448b-4965-8fab-ecebb7510eaf   1   8   0 wz--n-  29.62g  25.50g
  e180bb5f-9361-4f68-9690-9a2f0098a02c   4   6   0 wz--n- 118.50g 114.62g
  e364f587-7471-40f4-a497-915c13c6a223   2   8   0 wz--n-  59.25g  55.12g
  vg0                                    1   2   0 wz--n- 232.69g      0 

in this example 872ee2b5-8865-452b-93f1-8361d15c68f6,a00f1dab-abc4-4573-bef7-3ab3c27221ea,a2cf8c0e-448b-4965-8fab-ecebb7510eaf VG's are redundant 
thus very confusing to the user

Comment 3 Allon Mureinik 2014-07-10 08:40:38 UTC
Sorry, I still don't understand the issue.

You are mounting some LUNs as Direct LUNs, and those LUNs have leftover VG data on them.
We aren't allowed to clear data on Direct LUNs (i.e., VDSM isn't the owner of the data).

Comment 4 Ori Gofen 2014-08-03 13:17:13 UTC
Ok,got it