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 1377702 - virt-resize --LV-expand failing (silently when combined with --expand)
Summary: virt-resize --LV-expand failing (silently when combined with --expand)
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libguestfs
Version: 6.8
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-20 12:11 UTC by Leonard den Ottolander
Modified: 2016-09-20 19:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-20 12:27:37 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Leonard den Ottolander 2016-09-20 12:11:59 UTC 
Trying to resize a CentOS-7 virtual disk from 8GB to 20GB on CentOS-6 using libguestfs-tools-c-1.20.11-17.el6.x86_64.

Original C7 vm disk image:

# qemu-img info /dev/VG1/c7android
image: /dev/VG1/c7android
file format: raw
virtual size: 8.0G (8589934592 bytes)
disk size: 0

[root@c7android ~]# pvs
  PV         VG     Fmt  Attr PSize PFree
  /dev/vda2  centos lvm2 a--  7.51g    0 
[root@c7android ~]# vgs
  VG     #PV #LV #SN Attr   VSize VFree
  centos   1   2   0 wz--n- 7.51g    0 
[root@c7android ~]# lvs
  LV   VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root centos -wi-ao----   6.71g                                                    
  swap centos -wi-ao---- 820.00m                                                    


Trying to resize the VM disk:

# lvrename VG1/c7android VG1/c7android-OLD
  Renamed "c7android" to "c7android-OLD" in volume group "VG1"
# lvcreate -L 20G -n c7android VG1
  Logical volume "c7android" created.
# virt-resize /dev/VG1/c7android-OLD /dev/VG1/c7android --expand /dev/vda2 --LV-expand /dev/centos/root
Examining /dev/VG1/c7android-OLD ...
**********

Summary of changes:

/dev/sda1: This partition will be left alone.

/dev/sda2: This partition will be resized from 7.5G to 19.5G.  The LVM 
    PV on /dev/sda2 will be expanded using the 'pvresize' method.

/dev/centos/root: This logical volume will be expanded to maximum 
    size.

**********
Setting up initial partition table on /dev/VG1/c7android ...
Copying /dev/sda1 ...
 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
Copying /dev/sda2 ...
 100% ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧ 00:00
Expanding /dev/sda2 using the 'pvresize' method ...

Resize operation completed with no errors.  Before deleting the old 
disk, carefully check that the resized disk boots and works correctly.


The command reports no errors, but the output seems to show the resizing of /dev/centos/root has been skipped.
Indeed it has:

[root@c7android ~]# pvs; vgs; lvs
  PV         VG     Fmt  Attr PSize  PFree 
  /dev/vda2  centos lvm2 a--  19.51g 12.00g
  VG     #PV #LV #SN Attr   VSize  VFree 
  centos   1   2   0 wz--n- 19.51g 12.00g
  LV   VG     Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  root centos -wi-ao----   6.71g                                                    
  swap centos -wi-ao---- 820.00m                                                    


Now we work from the new image and retry the LV expand step:

# lvrename VG1/c7android VG1/c7android-OLD2  Renamed "c7android" to "c7android-OLD2" in volume group "VG1"
[root@quad VG1]# lvcreate -L 20G -n c7android VG1  Logical volume "c7android" created.
[root@quad VG1]# virt-resize /dev/VG1/c7android-OLD2 /dev/VG1/c7android --LV-expand /dev/centos/root
Examining /dev/VG1/c7android-OLD2 ...
virt-resize: error: There is a deficit of 32768 bytes (32.0K).  You 
need to make the target disk larger by at least this amount or adjust 
your resizing requests.

virt-resize: If reporting bugs, run virt-resize with debugging enabled 
(-v) and include the complete output.


Ok, with debug info (--debug, not -v!)
# virt-resize --debug /dev/VG1/c7android-OLD2 /dev/VG1/c7android --LV-expand /dev/centos/root
command line: virt-resize --debug /dev/VG1/c7android-OLD2 /dev/VG1/c7android --LV-expand /dev/centos/root
Examining /dev/VG1/c7android-OLD2 ...
libguestfs: trace: add_drive "/dev/VG1/c7android-OLD2" "readonly:true"
libguestfs: trace: add_drive = 0
libguestfs: trace: add_drive "/dev/VG1/c7android" "readonly:false"
libguestfs: trace: add_drive = 0
libguestfs: trace: launch
libguestfs: trace: get_tmpdir
libguestfs: trace: get_tmpdir = "/tmp"
libguestfs: trace: get_cachedir
libguestfs: trace: get_cachedir = "/var/tmp"
libguestfs: trace: launch = 0
libguestfs: trace: lvm_set_filter "/dev/sda"
libguestfs: trace: lvm_set_filter = 0
libguestfs: trace: available "ntfsprogs ntfs3g"
libguestfs: trace: available = -1 (error)
libguestfs: trace: available "btrfs"
libguestfs: trace: available = 0
libguestfs: trace: blockdev_getss "/dev/sdb"
libguestfs: trace: blockdev_getss = 512
libguestfs: trace: blockdev_getsize64 "/dev/sda"
libguestfs: trace: blockdev_getsize64 = 21474836480
libguestfs: trace: blockdev_getsize64 "/dev/sdb"
libguestfs: trace: blockdev_getsize64 = 21474836480
libguestfs: trace: part_get_parttype "/dev/sda"
libguestfs: trace: part_get_parttype = "msdos"
/dev/VG1/c7android-OLD2 size 21474836480 bytes
/dev/VG1/c7android size 21474836480 bytes
partition table type: msdos
libguestfs: trace: pvs_full
libguestfs: trace: pvs_full = <struct guestfs_lvm_pv_list *>
libguestfs: trace: part_list "/dev/sda"
libguestfs: trace: part_list = <struct guestfs_partition_list *>
libguestfs: trace: part_get_bootable "/dev/sda" 1
libguestfs: trace: part_get_bootable = 1
libguestfs: trace: part_get_mbr_id "/dev/sda" 1
libguestfs: trace: part_get_mbr_id = 131
libguestfs: trace: vfs_type "/dev/sda1"
libguestfs: trace: vfs_type = "xfs"
libguestfs: trace: mount_ro "/dev/sda1" "/"
libguestfs: trace: mount_ro = 0
libguestfs: trace: statvfs "/"
libguestfs: trace: statvfs = <struct guestfs_statvfs *>
libguestfs: trace: part_get_bootable "/dev/sda" 2
libguestfs: trace: part_get_bootable = 0
libguestfs: trace: part_get_mbr_id "/dev/sda" 2
libguestfs: trace: part_get_mbr_id = 142
libguestfs: trace: vfs_type "/dev/sda2"
libguestfs: trace: vfs_type = "LVM2_member"
libguestfs: trace: canonical_device_name "/dev/sda2"
libguestfs: trace: canonical_device_name = "/dev/sda2"
libguestfs: trace: lvs
libguestfs: trace: lvs = ["/dev/centos/root", "/dev/centos/swap"]
libguestfs: trace: vfs_type "/dev/centos/root"
libguestfs: trace: vfs_type = "xfs"
libguestfs: trace: mount_ro "/dev/centos/root" "/"
libguestfs: trace: mount_ro = 0
libguestfs: trace: statvfs "/"
libguestfs: trace: statvfs = <struct guestfs_statvfs *>
libguestfs: trace: vfs_type "/dev/centos/swap"
libguestfs: trace: vfs_type = "swap"
libguestfs: trace: mount_ro "/dev/centos/swap" "/"
libguestfs: trace: mount_ro = -1 (error)
2 partitions found
/dev/sda1:
	partition data: 1 1048576-525336575 (524288000 bytes)
	bootable: true
	partition ID: 0x83
	content: filesystem xfs (520794112 bytes)
/dev/sda2:
	partition data: 2 525336576-21473591295 (20948254720 bytes)
	bootable: false
	partition ID: 0x8e
	content: LVM PV (20946354176 bytes)
2 logical volumes found
/dev/centos/root:
	content: filesystem xfs (7191134208 bytes)
/dev/centos/swap:
	content: unknown data
calculate surplus: outsize=21474836480 required=21472542720 overhead=2326528 surplus=-32768
virt-resize: error: There is a deficit of 32768 bytes (32.0K).  You 
need to make the target disk larger by at least this amount or adjust 
your resizing requests.

virt-resize: If reporting bugs, run virt-resize with debugging enabled 
(-v) and include the complete output.
libguestfs: trace: close
libguestfs: trace: internal_autosync
libguestfs: trace: internal_autosync = 0


Doing the LV expand step after the expand step has been completed shows what seems to be a calculation error resulting in the failure to expand the virtual lv. Why this error is not reported when attempting both steps with a single invocation is unclear to me.
Comment 1 Richard W.M. Jones 2016-09-20 12:27:37 UTC 
Resizing XFS from CentOS 7, using a CentOS 6 host is problematic.

The CentOS 6 kernel does not support the XFS variant / features used
by CentOS 7, and you'll find that even if you can get past this
surplus calculation problem, it's not going to work properly.  The
XFS developers have refused to backport the extra features to
RHEL 6.

You need to use a CentOS 7 host for this task (and in general
you need to use similar/later host to manipulate earlier disk image).

So I'm afraid I'm going to close this one because it's something
we cannot support.
Comment 2 Leonard den Ottolander 2016-09-20 13:17:16 UTC 
1) Resize vm image
2) Resize lv
3) Resize fs

The problem is not so much the fact that the action fails, the problem is the (combined) command does not indicate any failure.

Also, the failure seems to happen at step 2 above, the resizing of the logical volume, even before it reaches step 3, the resizing of the fs. Perhaps the code could be patched to indicate a failure when combining --expand and --LV-expand as in my first example?

Your answer seems to suggest that this forward approach does work when using ext4 in the C7 host. Is that correct?
Comment 3 Richard W.M. Jones 2016-09-20 13:29:09 UTC 
I see, I missed that you were doing this in two steps.  The
problem is that --LV-expand failed (silently) in the first step.
That's not surprising for the reasons outlined in comment 1.

There is probably a bug in the surplus calculation, but this
is a very old version of virt-resize (released 3 years ago)
and lots has changed upstream in how we do these calculations.
But none of this is relevant because you shouldn't need the
two step process, and this simply can't be done on a RHEL 6-based
host.

(In reply to Leonard den Ottolander from comment #2)
> Your answer seems to suggest that this forward approach does work when using
> ext4 in the C7 host. Is that correct?

It might work, provided no new features of ext4 are used.  ext4 seems
a bit more tolerant here.  All of the bugs so far have been reported by
people using XFS.
Comment 4 Leonard den Ottolander 2016-09-20 19:38:22 UTC 
I only used a separate invocation of --LV-expand to make the error visible. When using --expand and --LV-expand in conjunction the output reports no errors even if only executing the expand step. I'll see if I have any luck with ext4.
Note You need to log in before you can comment on or make changes to this bug.