Bug 1723275

Summary: The virt-resize command fails to expand swap partition
Product: Red Hat Enterprise Linux 8 Reporter: YongkuiGuo <yoguo>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED NEXTRELEASE QA Contact: YongkuiGuo <yoguo>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.1CC: jsuchane, ptoscano, rjones
Target Milestone: rc   
Target Release: 8.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-30 09:40:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1727270    
Bug Blocks:    
Attachments:
Description Flags
virt-resize output log none

Description YongkuiGuo 2019-06-24 06:54:59 UTC
Created attachment 1583875 [details]
virt-resize output log

Description of problem:
The virt-resize fails to expand swap partition on latest rhel8.1.0 compose(RHEL-8.1.0-20190619.2).


Version-Release number of selected component (if applicable):
libguestfs-1.38.4-12.module+el8.1.0+3306+18be956d.x86_64
lvm2-2.03.05-1.el8.x86_64


How reproducible:
100%


Steps:

1. On latest rhel8.1.0 compose(RHEL-8.1.0-20190619.2)
# virt-filesystems -a rhel8.0.raw -lh --extra
Name                            Type       VFS  Label Size Parent
/dev/sda1                       filesystem xfs  -     1.0G -
/dev/rhel_bootp-73-199-200/root filesystem xfs  -     6.2G -
/dev/rhel_bootp-73-199-200/swap filesystem swap -     820M -

2.
# qemu-img create virt-resize-test.img 10G

3.
# virt-resize -v -x --expand /dev/sda2 --LV-expand /dev/rhel_bootp-73-199-200/swap rhel8.0.raw virt-resize-test.img
...
[  59.1] Expanding /dev/rhel_bootp-73-199-200/swap using the ‘mkswap’ method
libguestfs: trace: lvresize_free "/dev/rhel_bootp-73-199-200/swap" 100
guestfsd: => pvresize (0x62) took 0.12 secs
guestfsd: <= lvresize_free (0xee) request length 80 bytes
commandrvf: stdout=n stderr=y flags=0x0
commandrvf: udevadm --debug settle -E /dev/rhel_bootp-73-199-200/swap
calling: settle
is_device_parameter: stat: /dev/rhel_bootp-73-199-200/swap: No such file or directory
guestfsd: error: lvresize_free_stub: /dev/rhel_bootp-73-199-200/swap: expecting a device name
guestfsd: => lvresize_free (0xee) took 0.05 secs
libguestfs: trace: lvresize_free = -1 (error)
virt-resize: error: libguestfs error: lvresize_free: lvresize_free_stub:
/dev/rhel_bootp-73-199-200/swap: expecting a device name


4.Downgrade the lvm2 packages to the prior version(lvm2-2.03.02-6.el8) and the virt-resize command works fine.


Actual results:
The virt-resize command fails to expand swap partition.

Expected results:
The virt-resize should be able to expand swap partition correctly.

Additional info:

Comment 1 YongkuiGuo 2019-07-04 03:36:50 UTC
hi rjones, could you take a look at this issue? Thanks.

Comment 2 Richard W.M. Jones 2019-07-04 08:51:07 UTC
It does look like it might be a bug in LVM.  Can I get access to the
rhel8.0.raw image from somewhere?

Comment 3 YongkuiGuo 2019-07-05 07:46:04 UTC
Have sent the detailed info about the image by email.

Comment 4 Richard W.M. Jones 2019-07-05 09:28:54 UTC
Kernel version when broken was 4.18.0-107.el8.x86_64

Comment 5 Richard W.M. Jones 2019-07-05 09:48:58 UTC
I can reproduce this using:

kernel 4.18.0-111.el8.x86_64
systemd-239-15.el8.x86_64
device-mapper-1.02.163-1.el8.x86_64
lvm2-2.03.05-1.el8.x86_64
libguestfs-1.38.4-13.module+el8.1.0+3531+2918145b.x86_64

Downgrading to these versions fixes the problem:

device-mapper-1.02.155-6.el8.x86_64
lvm2-2.03.02-6.el8.x86_64

Comment 6 Richard W.M. Jones 2019-07-05 10:05:59 UTC
Here's a simpler reproducer in a couple of lines:

$ guestfish sparse test1.img 100M : run : pvcreate /dev/sda : vgcreate VG /dev/sda : lvcreate boot VG 10 : lvcreate swap VG 10 : lvcreate root VG 10 ; truncate -s 1G test1.img

This creates a ‘test1.img’ disk image.

To reproduce the problem:

$ guestfish --ro -a test1.img run : debug ll /dev/mapper

With LVM2 2.03.05-1.el8 (the broken version) you will see only the control file:

crw-------  1 root root 10, 236 Jul  5 10:02 control

With LVM2 2.03.02-6.el8 (the working version) you will see the expected LVs:

lrwxrwxrwx  1 root root       7 Jul  5 10:03 VG-boot -> ../dm-0
lrwxrwxrwx  1 root root       7 Jul  5 10:03 VG-root -> ../dm-2
lrwxrwxrwx  1 root root       7 Jul  5 10:03 VG-swap -> ../dm-1
crw-------  1 root root 10, 236 Jul  5 10:03 control

Comment 7 Richard W.M. Jones 2019-07-05 10:07:32 UTC
So the problem appears to be a new test added to LVM2.  With the broken LVM2 I see:

  pvscan[192] PV /dev/sda ignore for size 204800 not matching device 2097152.

With non-broken LVM2 I do not see this warning and the pvscan operation completes.
I believe this is a misguided attempt in LVM2 to add some checking.  I will file
a bug against LVM2.

Comment 8 YongkuiGuo 2019-07-08 03:02:47 UTC
Thanks for providing the simpler reproducer and explanation.

Comment 9 YongkuiGuo 2019-08-08 03:39:38 UTC
Verified with the packages:
libguestfs-1.38.4-13.module+el8.1.0+3531+2918145b.x86_64
lvm2-2.03.05-2.el8.x86_64

Steps:

1. On latest rhel8.1.0 compose(RHEL-8.1.0-20190806.2)
$ guestfish sparse test1.img 100M : run : pvcreate /dev/sda : vgcreate VG /dev/sda : lvcreate boot VG 10 : lvcreate swap VG 10 : lvcreate root VG 10 ; truncate -s 1G test1.img

2.
$ guestfish --ro -a test1.img run : debug ll /dev/mapper
...
lrwxrwxrwx  1 root root       7 Aug  8 03:31 VG-boot -> ../dm-0
lrwxrwxrwx  1 root root       7 Aug  8 03:31 VG-root -> ../dm-2
lrwxrwxrwx  1 root root       7 Aug  8 03:31 VG-swap -> ../dm-1
crw-------  1 root root 10, 236 Aug  8 03:31 control

Verified this bug.

Comment 10 Jaroslav Suchanek 2019-08-29 15:48:50 UTC
Should it be in VERIFIED than?

Comment 11 YongkuiGuo 2019-08-30 01:37:44 UTC
(In reply to Jaroslav Suchanek from comment #10)
> Should it be in VERIFIED than?

This issue is related to lvm2 bug #1727270. And the latest lvm2 works fine. So we can close this bug.

Comment 12 Richard W.M. Jones 2019-08-30 09:40:40 UTC
I retested it with lvm2-2.03.05-4.el8.x86_64 and it works over here.
Let's close this.