RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2233901 - lvm_import_vdo fails to import - 'vdoprepareforlvm: Failed to open'
Summary: lvm_import_vdo fails to import - 'vdoprepareforlvm: Failed to open'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: lvm2
Version: 8.9
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: rc
: ---
Assignee: Zdenek Kabelac
QA Contact: cluster-qe
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-08-23 16:36 UTC by Corey Marthaler
Modified: 2023-11-14 18:16 UTC (History)
10 users (show)

Fixed In Version: lvm2-2.03.14-13.el8_9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-11-14 15:52:08 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CLUSTERQE-6884 0 None None None 2023-09-13 15:11:00 UTC
Red Hat Issue Tracker RHELPLAN-166251 0 None None None 2023-08-23 16:38:57 UTC
Red Hat Product Errata RHBA-2023:7191 0 None None None 2023-11-14 15:52:18 UTC

Description Corey Marthaler 2023-08-23 16:36:26 UTC 
Description of problem:

[root@virt-047 ~]# vdo create --force --name lvm_import_vdo_sanity2 --vdoLogicalSize 50G --device /dev/sdb
Creating VDO lvm_import_vdo_sanity2
      The VDO volume can address 72 GB in 36 data slabs, each 2 GB.
      It can grow to address at most 16 TB of physical storage in 8192 slabs.
      If a larger maximum size might be needed, use bigger slabs.
Starting VDO lvm_import_vdo_sanity2
Starting compression on VDO lvm_import_vdo_sanity2
VDO instance 0 volume is ready at /dev/mapper/lvm_import_vdo_sanity2

[root@virt-047 ~]# lvm_import_vdo --yes --name vdovg2/lvm_import_vdo_sanity2 /dev/sdb
Stopping VDO lvm_import_vdo_sanity2
vdo: ERROR - Device lvm_import_vdo_sanity2 could not be converted; vdoprepareforlvm: Failed to open '/dev/disk/by-id/scsi-1LIO-ORGcluster151790-d:7eb9b61c-ed69-4ff5-9de4-256964f8e0fa' exclusively : Device or resource busy
vdo: ERROR - vdoprepareforlvm: Failed to open '/dev/disk/by-id/scsi-1LIO-ORGcluster151790-d:7eb9b61c-ed69-4ff5-9de4-256964f8e0fa' exclusively : Device or resource busy


Version-Release number of selected component (if applicable):
kernel-4.18.0-511.el8    BUILT: Fri Aug 18 17:12:35 CEST 2023
lvm2-2.03.14-11.el8    BUILT: Thu Jul 27 18:17:12 CEST 2023
lvm2-libs-2.03.14-11.el8    BUILT: Thu Jul 27 18:17:12 CEST 2023
lvm2-dbusd-2.03.14-11.el8    BUILT: Thu Jul 27 18:17:45 CEST 2023
lvm2-lockd-2.03.14-11.el8    BUILT: Thu Jul 27 18:17:12 CEST 2023

vdo-6.2.9.7-14.el8    BUILT: Wed May 24 21:36:13 CEST 2023
kmod-kvdo-6.2.8.7-92.el8    BUILT: Thu Aug  3 21:45:01 CEST 2023


How reproducible:
Everytime
Comment 1 Corey Marthaler 2023-08-23 16:40:10 UTC 
[root@virt-047 ~]# dmsetup ls
VDO_lvm_import_vdo_50862250_snap        (253:2)

[root@virt-047 ~]# dmsetup table
VDO_lvm_import_vdo_50862250_snap: 0 157286400 snapshot 8:16 7:0 P 32
Comment 2 Corey Marthaler 2023-08-23 22:49:19 UTC 
Aug 24 00:48:36 grant-01 vdo[5625]: ERROR - Device lvm_import_vdo_sanity could not be converted; vdoprepareforlvm: Failed to open '/dev/disk/by-id/ata-HFS480G32FEH-BA10A_ESB1N6680I1501N6B' exclusively : Device or resource busy
Aug 24 00:48:36 grant-01 vdo[5625]: ERROR - vdoprepareforlvm: Failed to open '/dev/disk/by-id/ata-HFS480G32FEH-BA10A_ESB1N6680I1501N6B' exclusively : Device or resource busy
Comment 3 Zdenek Kabelac 2023-09-04 14:53:25 UTC 
Ok - so there were couple issue that were problematic.

There are now upstreamed to patches:

https://gitlab.com/lvmteam/lvm2/-/commit/b81835b5ca2c3ccb31e8c4ce88e62e0a6a7e16fe

This patch internally switches to the name used within the vdoconf.yml.
As a test workaround user should be able to pass that path i.e.:
#  lvm_import_vdo  '/dev/disk/by-id/ata-HFS480G32FEH-BA10A_ESB1N6680I1501N6B'   instead of using '/dev/sdb'


2nd. patch: 

https://gitlab.com/lvmteam/lvm2/-/commit/c693aa8dacf61fac3f08ec65bec204c4b4d29d3d

Cleans some error paths and makes overall tracing of this script more useful.
Comment 10 Corey Marthaler 2023-09-08 01:44:26 UTC 
This scratch build doesn't work.

[root@virt-242 ~]# lvm_import_vdo --yes --name vdovg/lvm_import_vdo_sanity_new /dev/sda
Stopping VDO lvm_import_vdo_sanity_new
vdo: WARNING - VDO service lvm_import_vdo_sanity_new already stopped
sed: -e expression #1, char 85: unknown option to `s'
[root@virt-242 ~]# echo $?
1
Comment 11 Corey Marthaler 2023-09-08 14:35:45 UTC 
+ DEVICE=/dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1
+ case "$DM_UUID" in
+ convert_non_lv_ 524288000
+ local vdo_logicalSize=524288000
+ local vdo_logicalSizeRounded
+ local extent_size
+ local output
+ local pvfree
+ '[' 1 = 1 ']'
+ dry snapshot_create_ /dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1
+ '[' 0 -ne 0 ']'
+ verbose Executing snapshot_create_ /dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1
+ test -z ''
+ snapshot_create_ /dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1
+ VDO_DM_SNAPSHOT_NAME=VDO_lvm_import_vdo_100662161_snap
+ local file=/tmp/VDO_lvm_import_vdo_100662161/VDO_lvm_import_vdo_100662161_snap
+ truncate -s 20M /tmp/VDO_lvm_import_vdo_100662161/VDO_lvm_import_vdo_100662161_snap
++ losetup -f --show /tmp/VDO_lvm_import_vdo_100662161/VDO_lvm_import_vdo_100662161_snap
+ VDO_SNAPSHOT_LOOP=/dev/loop2
++ snapshot_target_line_ /dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1 /dev/loop2
+++ blockdev --getsize /dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1
++ echo '0 157286320 snapshot /dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1 /dev/loop2 P 32'
+ dmsetup create VDO_lvm_import_vdo_100662161_snap -u -VDO_lvm_import_vdo_100662161_snap-priv --table '0 157286320 snapshot /dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1 /dev/loop2 P 32'
+ VDO_DM_SNAPSHOT_DEVICE=/dev/mapper/VDO_lvm_import_vdo_100662161_snap
+ verbose 'Snapshot of VDO device /dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1 created: /dev/mapper/VDO_lvm_import_vdo_100662161_snap.'
+ test -z ''
+ sed s:/dev/disk/by-id/scsi-1LIO-ORGcluster152688-d:0618652b-2df0-4693-9c9f-995b89c3e57e-part1:/dev/mapper/VDO_lvm_import_vdo_100662161_snap: /tmp/VDO_lvm_import_vdo_100662161/vdoconf.yml
sed: -e expression #1, char 91: unknown option to `s'
Comment 13 Corey Marthaler 2023-09-08 17:08:11 UTC 
It appears to work now, however there is still an ioctl failure being displayed with the latest:
 device-mapper: remove ioctl on VDO_lvm_import_vdo_90306623_snap  failed: Device or resource busy Command failed.




[root@virt-242 ~]# vdo create --force --name lvm_import_vdo_sanity --vdoLogicalSize 500G --device /dev/sda1
Creating VDO lvm_import_vdo_sanity
      The VDO volume can address 72 GB in 36 data slabs, each 2 GB.
      It can grow to address at most 16 TB of physical storage in 8192 slabs.
      If a larger maximum size might be needed, use bigger slabs.
Starting VDO lvm_import_vdo_sanity
Starting compression on VDO lvm_import_vdo_sanity
VDO instance 4 volume is ready at /dev/mapper/lvm_import_vdo_sanity
[root@virt-242 ~]# lvm_import_vdo --yes /dev/sda1
Stopping VDO lvm_import_vdo_sanity
Converting VDO lvm_import_vdo_sanity
      Checking device
      Non converted VDO. Converting to LVM
      Opening /dev/mapper/VDO_lvm_import_vdo_90306623_snap exclusively
      Loading the VDO superblock and volume geometry
      Checking the VDO state
      New geometry block offset calculated at 2056192
      Converting the UDS index
      Converting the VDO
      Conversion completed for '/dev/mapper/VDO_lvm_import_vdo_90306623_snap': VDO is now aligned on 2097152 bytes, starting at offset 2056192
  Physical volume "/dev/mapper/VDO_lvm_import_vdo_90306623_snap" successfully created.
  Volume group "vdovg" successfully created
  WARNING: Logical volume vdovg/vdolvol_vpool not zeroed.
  Logical volume "vdolvol_vpool" created.
  WARNING: Converting logical volume vdovg/vdolvol_vpool to VDO pool volume WITHOUT formating.
  WARNING: Using invalid VDO pool data MAY DESTROY YOUR DATA!
  Logical volume "vdolvol" created.
  Converted vdovg/vdolvol_vpool to VDO pool volume and created virtual vdovg/vdolvol VDO volume.
  0 logical volume(s) in volume group "vdovg" now active
  Volume group "vdovg" successfully changed
device-mapper: remove ioctl on VDO_lvm_import_vdo_90306623_snap  failed: Device or resource busy
Command failed.
  Volume group "vdovg" successfully changed
[root@virt-242 ~]# echo $?
0
[root@virt-242 ~]# lvs -a -o +devices
  LV                    VG            Attr       LSize   Pool          Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices               
  root                  rhel_virt-242 -wi-ao----  <6.20g                                                              /dev/vda2(205)        
  swap                  rhel_virt-242 -wi-ao---- 820.00m                                                              /dev/vda2(0)          
  vdolvol               vdovg         vwi-a-v--- 500.00g vdolvol_vpool        0.00                                    vdolvol_vpool(0)      
  vdolvol_vpool         vdovg         dwi------- <75.00g                      4.06                                    vdolvol_vpool_vdata(0)
  [vdolvol_vpool_vdata] vdovg         Dwi-ao---- <75.00g                                                              /dev/sda1(0)
Comment 16 Corey Marthaler 2023-09-13 16:54:06 UTC 
The latest build does NOT have the fixes described in comment #15.

kernel-4.18.0-513.1.1.el8_9    BUILT: Wed Sep  6 16:32:22 CEST 2023
lvm2-2.03.14-13.el8_9    BUILT: Wed Sep 13 15:23:07 CEST 2023
lvm2-libs-2.03.14-13.el8_9    BUILT: Wed Sep 13 15:23:07 CEST 2023

lvm_import_vdo --yes /dev/disk/by-id/scsi-1LIO-ORGcluster153229-d:b882991f-b574-4e27-ab8a-d11b4c55bc5f
Stopping VDO lvm_import_vdo_sanity
Converting VDO lvm_import_vdo_sanity
      Checking device
      Non converted VDO. Converting to LVM
      Opening /dev/mapper/VDO_lvm_import_vdo_223932607_snap exclusively
      Loading the VDO superblock and volume geometry
      Checking the VDO state
      New geometry block offset calculated at 2097152
      Converting the UDS index
      Converting the VDO
      Conversion completed for '/dev/mapper/VDO_lvm_import_vdo_223932607_snap': VDO is now aligned on 2097152 bytes, starting at offset 2097152
  Physical volume "/dev/mapper/VDO_lvm_import_vdo_223932607_snap" successfully created.
  Volume group "vdovg" successfully created
  Logical volume "vdolvol_vpool" created.
  WARNING: Logical volume vdovg/vdolvol_vpool not zeroed.
  WARNING: Converting logical volume vdovg/vdolvol_vpool to VDO pool volume WITHOUT formating.
  WARNING: Using invalid VDO pool data MAY DESTROY YOUR DATA!
  Logical volume "vdolvol" created.
  Converted vdovg/vdolvol_vpool to VDO pool volume and created virtual vdovg/vdolvol VDO volume.
lvextend: unrecognized option '--fs'
  Error during parsing of command line.
lvm_import_vdo should have worked using a large vdo logical size
Comment 17 Corey Marthaler 2023-09-13 17:03:07 UTC 
Additional issues that have come from the testing of this issue:

https://issues.redhat.com/browse/RHEL-3530
https://issues.redhat.com/browse/RHEL-3529
Comment 21 Corey Marthaler 2023-09-14 15:51:10 UTC 
The lvm_import_vdo regression tests have passed on this latest attached script.
Comment 23 Corey Marthaler 2023-09-19 14:48:23 UTC 
Marking this Verified:Tested in the latest build.

kernel-4.18.0-513.1.1.el8_9    BUILT: Wed Sep  6 16:32:22 CEST 2023
lvm2-2.03.14-13.el8_9    BUILT: Mon Sep 18 11:27:08 CEST 2023
lvm2-libs-2.03.14-13.el8_9    BUILT: Mon Sep 18 11:27:08 CEST 2023
Comment 28 errata-xmlrpc 2023-11-14 15:52:08 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 (lvm2 bug fix and enhancement update), 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/RHBA-2023:7191
Note You need to log in before you can comment on or make changes to this bug.