8 thoughts on - Troubles Expanding File System.

• Thanks for the long list of items of what you have done. In Fedora Infrastructure, we used this method to resize images in the past https://pagure.io/infra-docs/blob/main/f/docs/sysadmin-guide/sops/guestdisk.rst

  The guest system usually needs to have the `fdisk` , `gdisk` or
  `parted` commands rerun to resize the disk to its new size.

  Not sure that would do anything.

• If you look at the content of /sys/class/block/vde and vde1, you’ll see that vde has a device subdir, and vde1 does not.  You can’t rescan a partition.  Rescan the *drive*

  echo 1 > /sys/class/block/vde/device/rescan

• And, on additional disks, one can put filesystems directly on the disk and so not have to care about useless partition tables (that’s not on the root/boot disk). To add more flexibility, one can also use LVM on the device directly without having to mess with partition tables.

  Simon

• I realized I was still on receiving the daily digest format last night, so I have probably screwed up the threading on this now. If you cc me directly maybe I can maintain the future threading.

  Ok, looking at Parted it looks like the resize (or resizepart) command will be what I will need. But that doesn’t appear to help recognize the expanded disk, so I think I need something before that. That is what I thought the echo 1 > rescan would do for me.

  I will look more into fdisk to understand the capabilities there. I am going to take advantage of the holiday weekend in a few days to take care of this so I am trying to understand all of the options available to me before diving into the task.

  In response to Gordon also, I did rescan the drive as suggested and got the same results; no such file or directory. So then I did a search for the rescan file to see where it was present. Found it in a few locations, but this one looks to be the one that I would want to try.

  /sys/devices/pci0000:00/0000:00:01.1/host1/target1:0:0/1:0:0:0/

  The rescan file was also located in just: /sys/bus/pci but don’t know if that would do the job for the specific device.

  Thanks for everyone’s input. Very helpful. More suggestions are welcome while I am still reading up on options.

  Jeff

  Date: Wed, 1 Sep 2021 13:15:37 -0400
  From: Stephen John Smoogen
  To: CentOS mailing list
  Subject: Re: [CentOS] Troubles expanding file system. Message-ID:
  
  Content-Type: text/plain; charset=”UTF-8″

  Thanks for the long list of items of what you have done. In Fedora Infrastructure, we used this method to resize images in the past https://pagure.io/infra-docs/blob/main/f/docs/sysadmin-guide/sops/guestdisk.rst

  The guest system usually needs to have the `fdisk` , `gdisk` or
  `parted` commands rerun to resize the disk to its new size.

  Not sure that would do anything.

• What are the CentOS versions of your host and guest?
  As far as I know, virtio disks have never supported rescan from inside the guest and so there isn’t the corresponding “rescan” special file. I found this old, but interesting thread:
  https://forum.proxmox.com/threads/extend-rescan-virtio-disk-in-guest-vm.7989/

  Can you confirm your host libvirt version and your guest kernel are ok with what is referred?
  In case you could try with the qemu monitor command.

  See also here for a reference of possible qemu monitor commands:
  https://qemu-project.gitlab.io/qemu/interop/qemu-qmp-ref.html

  And here for consideration regarding RH EL 6 host:
  https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_administration_guide/sub-sect-domain_commands-using_blockresize_to_change_the_size_of_a_domain_path

  Also here you find reference of command to issue, but somehow the syntax changes depending on components’ versions:
  https://www.humblec.com/is-it-possible-to-do-online-resizing-of-guest-block-devices-or-without-shutdown/

  HIH, Gianluca

• Hi Jeff,

  I’m not sure what your current state is but I’d like to point out what I
  usually do to online resize disks on KVM hosts/guests.

  After expanding the disk image/logical volume, let the quest know it has changed. To do so, run like this on the host:

  virsh blockresize db01 /var/lib/libvirt/images/db01.var.img 7516192768B

  or

  virsh blockresize db01 vdb 7516192768B

  Note: I’m using bytes (B) as unit to make very sure it’s correct!

  After doing so, you should see that disk size has changed on the guest, in syslog or with dmesg.

  Now you can modify partition tables or pvresize. After that, resize the fillesystems with resize2fs or xfs_growfs.

  That’s all possible while the guest is online with one exception outlined below.

  There is one thing that I couldn’t find a solution for no matter what I
  tried: When the root/boot disk of the guest is being resized, it’s not possible to modify and reread the new partition table without reboot.

  Regards, Simon

• I’m curious to know if this works for you.  Suppose /dev/sda is the boot disk.  Determine the highest number primary partition in use on the drive.  Let’s say it’s 3.

  # growpart /dev/sda 3

  In addition, you might try

  # printf “F\n” | parted —pretend-input-tty -l

  I have these in an Ansible playbook for creating CentOS 7 and Ubuntu Focal VMs.  They require cloud-int (for growpart) and gdisk.  Note:
  growpart doesn’t work if the highest partition is not a primary partition, i.e., greater than 4.

  Jack

• I think the problem in my case was that EL6 didn’t support this. From growpart man page:

  “this requires kernel support and ‘partx –update'”

  Maybe it works for newer systems but didn’t work when I last had to do it on EL6.

  Simon