127

I setup an Ubuntu guest on a CentOS KVM host with initially 6GB of disk space. How do I go about increasing the Ubuntu guest's disk space from the command line?

EDIT #1: I'm using a disk image file (qemu).

1

18 Answers 18

153
  1. stop the VM
  2. run qemu-img resize vmdisk.img +10G to increase image size by 10Gb
  3. start the VM, resize the partitions and LVM structure within it normally
12
  • 2
    Worked for re-sizing my *.qcow2 img on RHEL6.6. Thanks! Mar 12, 2015 at 17:54
  • 31
    start the VM, resize the partitions and LVM structure within it normally How to do it? Please explain it.
    – Waki
    Jul 2, 2015 at 19:17
  • 11
    To resize partions and LVM, follow all steps as explained in this excellent article: sandilands.info/sgordon/…
    – skonsoft
    Jul 3, 2016 at 18:55
  • 9
    why don't you just use 1. fix the problem? the vague part is 3.... are you kidding me?
    – d9ngle
    May 4, 2020 at 15:47
  • 2
    @d9ngle Well, see, here's the thing. dyasny's answer isn't vague. It explains exactly how to grow a VM image's allocated space. Step 3 involves resizing the filesystem, which is the same whether or not you're using a VM, but is different for every OS, distro, and release. So if you don't know how to resize disk volumes in your (guest) OS, then you have two questions. One of them has now been answered.
    – FeRD
    Jan 6, 2022 at 20:34
40

Online Method (using qemu, libvirt, and virtio-block)

For better or worse, the commands below will run even if the target virtual disk is mounted. This can be useful in environments where the disk cannot be unmounted (such as a root partition), the VM must stay on, and the system owner is willing to assume the risk of data corruption. To remove that risk, you would need to log into the VM and unmount the target disk first, something that isn't always possible.

Perform the following from the KVM hypervisor.

  1. Increase the size of the disk image file itself (specify the amount to increase):

    qemu-img resize <my_vm>.img +10G
    
  2. Get the name of the virtio device, via the libvirt shell (drive-virtio-disk0 in this example):

    virsh qemu-monitor-command <my_vm> info block --hmp
      drive-virtio-disk0: removable=0 io-status=ok file=/var/lib/libvirt/images/<my_vm>.img ro=0 drv=raw encrypted=0
      drive-ide0-1-0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
    
  3. Signal the virtio driver to detect the new size (specify the total new capacity):

    virsh qemu-monitor-command <my_vm> block_resize drive-virtio-disk0 20G --hmp
    

Then log into the VM. Running dmesg should report that the virtio disk detected a capacity change. At this point, go ahead and resize your partitions and LVM structure as needed.

4
  • 6
    The man page for qemu-img (mine is dated 2016-05-08) says: "Warning: Never use qemu-img to modify images in use by a running virtual machine or any other process; this may destroy the image. Also, be aware that querying an image that is being modified by another process may encounter inconsistent state." So I am not sure whether (the first step) is safe when the virtual machine is still running.
    – user44400
    May 30, 2017 at 7:51
  • Does not work on centos7+kvm
    – e-info128
    Dec 27, 2017 at 13:27
  • 1
    This worked perfectly for me. Using ceph and virtio block devices. we store application data / MySQL db on a separate partition. Stop the applications accessing this partition. Unmount it. Resize it. fsck. then mount it again with the new size. No shutdown needed.
    – nelaaro
    Apr 30, 2018 at 14:44
  • Same as this answer, but using libvirt instead of monitor console: serverfault.com/a/952868/30946 Feb 9, 2019 at 17:18
22

These serverfault questions are similar but more specific, KVM online disk resize? & Centos Xen resizing DomU partition and volume group. The 1st asks the question of how to increase a KVM guest while it's online, while the 2nd is XEN specific using LVM. I'm asking how to accomplish this while the KVM is offline.

NOTE: This link was useful for METHOD #1, and shows how to accomplish increasing a KVM's disk space (ext3 based), HOWTO: Resize a KVM Virtual Machine Image.

One thing to be aware of with KVM guests is that the partitions they're using inside can effect which method you can use to increase their disk space.

METHOD #1: Partitions are ext2/ext3/ext4 based

The nuts of this method are as follows:

# 1. stop the VM
# 2. move the current image
mv mykvm.img mykvm.img.bak

# 3. create a new image
qemu-img create -f raw addon.raw 30G

# 4. concatenate the 2 images
cat mykvm.img.bak addon.raw >> mykvm.img

Now with the larger mykvm.img file in hand, boot gparted and extend the existing partition into the newly added disk space. This last step basically extends the OS partition so that it can make use of the extra space.

METHOD #2: Partitions are LVM based

Here are the steps that I roughly followed to resize a KVM guest that used LVM internally.

  1. Shutdown the VM
  2. add more space to the guest's "image file" (something like: cat old.img 10G_addon.raw >> new.img
  3. start the VM (using the newly created new.img)
  4. run fdisk inside VM and delete & re-create LVM partition

    % fdisk /dev/vda
    ...
    Device Boot      Start         End      Blocks   Id  System
    /dev/vda1   *           1          13      104391   83  Linux
    /dev/vda2              14        3263    26105625   8e  Linux LVM
    
    Command (m for help): d
    Partition number (1-4): 2
    
    Command (m for help): p
    
    Disk /dev/vda: 48.3 GB, 48318382080 bytes
    255 heads, 63 sectors/track, 5874 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    
    Device Boot      Start         End      Blocks   Id  System
    /dev/vda1   *           1          13      104391   83  Linux
    
    Command (m for help): n 
    Command action
      e   extended
      p   primary partition (1-4)
    p
    Partition number (1-4): 2
    First cylinder (14-5874, default 14): 14
    Last cylinder or +size or +sizeM or +sizeK (14-5874, default 5874): 
    Using default value 5874
    
    Command (m for help): p
    
    Disk /dev/vda: 48.3 GB, 48318382080 bytes
    255 heads, 63 sectors/track, 5874 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    
    Device Boot      Start         End      Blocks   Id  System
    /dev/vda1   *           1          13      104391   83  Linux
    /dev/vda2              14        5874    47078482+  83  Linux
    
    Command (m for help): t
    Partition number (1-4): 2
    Hex code (type L to list codes): 8e
    Changed system type of partition 2 to 8e (Linux LVM)
    
    Command (m for help): p
    
    Disk /dev/vda: 48.3 GB, 48318382080 bytes
    255 heads, 63 sectors/track, 5874 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    
    Device Boot      Start         End      Blocks   Id  System
    /dev/vda1   *           1          13      104391   83  Linux
    /dev/vda2              14        5874    47078482+  8e  Linux LVM
    
    Command (m for help): w
    The partition table has been altered!
    
    Calling ioctl() to re-read partition table.
    
    WARNING: Re-reading the partition table failed with error 16: Device or 
    resource busy.
    The kernel still uses the old table.
    The new table will be used at the next reboot.
    Syncing disks.
    %
    
  5. Reboot the VM

  6. Resize the LVM physical volume

    % pvdisplay 
      --- Physical volume ---
      PV Name               /dev/vda2
      VG Name               VolGroup00
      PV Size               24.90 GB / not usable 21.59 MB
      Allocatable           yes (but full)
      PE Size (KByte)       32768
      Total PE              796
      Free PE               0
      ...
    
    % pvresize /dev/vda2
    
    % pvdisplay
      --- Physical volume ---
      PV Name               /dev/vda2
      VG Name               VolGroup00
      PV Size               44.90 GB / not usable 22.89 MB
      Allocatable           yes 
      PE Size (KByte)       32768
      Total PE              1436
      Free PE               640
      ...
    
  7. Resize the LVM Logical Volume

      % lvresize /dev/VolGroup00/LogVol00 -l +640
      Extending logical volume LogVol00 to 43.88 GB
      Logical volume LogVol00 successfully resized
    
  8. Grow the File system

      % resize2fs /dev/VolGroup00/LogVol00 
      resize2fs 1.39 (29-May-2006)
      Filesystem at /dev/VolGroup00/LogVol00 is mounted on /; on-line resizing required
      Performing an on-line resize of /dev/VolGroup00/LogVol00 to 11501568 (4k) blocks.
      The filesystem on /dev/VolGroup00/LogVol00 is now 11501568 blocks long.
    

The above is my example, but I followed the steps on this website

5
  • method #1 in this post doesn't seem to work that well - virtual machine manager in red hat does not report the new size afterwards. The method suggested by @dyasny seems to work better at-least in this respect. May 30, 2014 at 8:36
  • @IwanAucamp - interesting, I use virt-manager and have used method #1 & #2 extensively before I migrated our KVM servers to a newer version of KVM (CentOS 5 -> CentOS 6). I now use the qemu-img resize method as well.
    – slm
    May 30, 2014 at 11:53
  • For method #2, you might find lvextend handier as step 7: lvextend /dev/Volgroup/lvname /dev/vda2 (all on one line, where /dev/vda2 would be your physical volume). Without any other options, it will use the maximum size in that volume group.
    – Mike S
    May 5, 2015 at 18:42
  • Method #2, step 4 won't work if there are logical volumes in a partition table. After recreation of extended type of a partition, first available sector will no longer match what one had prior to the changes. E.g. if first sector of your logical partition was 1001472, after the changes it will be 1003518 (assuming 10G disk before and 50G after resizing). Anybody knows how to recreate, if at all possible, logical volumes at the same first sector?
    – ILIV
    Nov 17, 2016 at 17:18
  • 1
    This is due to fdisk by default applying alignment constraints (1MB step) to partitions. To work around, accept default value of 1003518, enter expert mode (x) then choose b and set first sector to 1001472. See unix.stackexchange.com/a/320447 for details.
    – ILIV
    Nov 17, 2016 at 18:06
19

Resize and Expand Internal Partitions in One Step

I had an Ubuntu host with a qcow2 guest file image and wanted to resize the disk and expand the appropriate partitions all in one step. It requires you to set up the libvirt guest filesystem utilities, but those are useful to have around anyway.

Inspiration from here: http://libguestfs.org/virt-resize.1.html

The key command here is: virt-resize

  • this is a libvirt utility
  • it can expand a guest disk AND expand the partitions inside in one step
  • it copies the disk, it doesn't expand it in-place
    • this is good because you have the untouched original as a backup

Preparation:

* Install libvirt file system utilities package 
    * sudo apt-get install libguestfs-tools

* Test to see if it works (it won't) -- you need to see "===== TEST FINISHED OK =====" at the bottom:
    * sudo libguestfs-test-tool

* If you don't see "===== TEST FINISHED OK =====" at the bottom then repair it:
    * sudo update-guestfs-appliance

* Run the test again and verify it works
    * sudo libguestfs-test-tool

Now do the following:

1) shutdown the guest:

2) Check out the current sizing and view the partition name you want to expand using libvirt utility:

sudo virt-filesystems --long --parts --blkdevs -h -a name-of-guest-disk-file

3) Create the new (40G) output disk:

qcow: sudo qemu-img create -f qcow2 -o preallocation=metadata outdisk 40G
img:  sudo truncate -s 40G outdisk

4) Copy the old to the new while expand the appropriate partition (assuming your disk partition from step 2 was /dev/sda1):

sudo virt-resize --expand /dev/sda1 indisk outdisk

5) Rename the indisk file as a backup, rename the outdisk as indisk (or modify the guest XML)

6) Reboot the guest and test the new disk file carefully before deleting the original file

7) Profit!

4
  • This almost does the job in my case. Sadly, almost. When the guest (a CentOS 7 server) is rebooted, it finds the expanded disk unbootable.
    – Urhixidur
    Oct 14, 2016 at 19:08
  • 2
    It worked great for me. Omitting -o preallocation=metadata creates a sparse file. With that option it pre-allocates the entire size. Dec 14, 2016 at 1:28
  • Excellent, this answer nailed it for me. Thanks so much! The "official" documentation for libguestfs (libguestfs.org/virt-resize.1.html), unfortunately is not well written and ends up being quite confusing.
    – mbello
    Aug 16, 2017 at 14:27
  • 2
    Worked well for me, remember that you don't actually need to use -o preallocation=metadata and if you don't you should also skip the truncate step. virt-resize will grow the file as appropriate anyway.
    – amoe
    Nov 13, 2017 at 16:29
12

It is possible to do online resize, without stopping the VM. libvirtd supports this natively:

Find the block device name. Should be something like "vda"

$ virsh domblklist <libvirtd_vm_name>

Resize the virtual device:

$ virsh blockresize --domain <libvirtd_vm_name> --path <block_device_name> --size <new_size>

Here is an example were I expand the vda disk from 50GB to 51GB for undercloud VM.

[root@localhost ~]# virsh domblklist undercloud
Target     Source
------------------------------------------------
vda        /home/images/undercloud.qcow2

Now take a look at the .qcow2 image file's details:

[root@localhost ~]# qemu-img info /home/images/undercloud.qcow2
image: /home/images/undercloud.qcow2
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 38G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Now let's resize the vda block device:

[root@localhost ~]# virsh blockresize undercloud vda 51G
Block device 'vda' is resized

And confirm:

[root@localhost ~]# qemu-img info /home/images/undercloud.qcow2
image: /home/images/undercloud.qcow2
file format: qcow2
virtual size: 51G (54760833024 bytes)
disk size: 38G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
[root@localhost ~]#

Then you can use this script inside the VM to show the commands to resize the block devices and fs: https://github.com/mircea-vutcovici/scripts/blob/master/vol_resize.sh. Here is a sample output:

mvutcovi@ubuntu1904:~$ wget -q https://raw.githubusercontent.com/mircea-vutcovici/scripts/master/vol_resize.sh

mvutcovi@ubuntu1904:~$ df /
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/vda1       15414216 7928904   6682600  55% /

mvutcovi@ubuntu1904:~$ sudo bash vol_resize.sh --block-device /dev/vda1
sfdisk -d /dev/vda > dev_vda-partition-table-$(date +%F_%H%M%S).txt   # Backup MS-DOS partition table for /dev/vda block device.
parted -s /dev/vda resizepart 1   # Resize MS-DOS partition /dev/vda1
# Update kernel with new partition table from disk
partx -u /dev/vda
partprobe /dev/vda
blockdev --rereadpt /dev/vda
kpartx -u /dev/vda
resize2fs /dev/vda1    # Resize ext3 or ext4 filesystem
mvutcovi@ubuntu1904:~$ 
4
  • I've tried this (and a million other things), but the thing is that it doesn't even detect that the disk got "physically" bigger. qemu and virsh show that I made the image bigger, but the guest OS doesn't detect the change, and I can't find a way to get it to do that.
    – Tyrel
    Apr 1, 2023 at 5:39
  • 1
    You need to ask the the SCSI subsystem to update the block device size with echo 1 > /sys/block/<sdX>/device/rescan. You should try the vol_resize.sh script I mention in my answer. Apr 1, 2023 at 19:15
  • Which guest OS are you running? In a Linux guest you should see a message like: virtio_blk virtio4: [vda] new size: 85983232 512-byte logical blocks (44.0 GB/41.0 GiB) followed by vda: detected capacity change from 42949672960 to 44023414784 Apr 1, 2023 at 20:04
  • I gave up and just rebooted the thing. But for reference, the guest OS is Ubuntu 22.04. I tried doing the SCSI rescan (and rescan on other devices that had rescan which looked relevant). I did run your script, and tries those commands, none of it worked. All the partx, partprobe, blockdev, etc commands all said the device was in use and didn't do anything.
    – Tyrel
    Apr 2, 2023 at 23:13
6

If you are using LVM within the VM the simplest way to do this woudl be to add a new virtual disk to the VM and expand the volume group and logical volumes onto that.

To check if you are using LVM run sudo pvs; sudo vgs; sudo lvs, you will get something like this out:

PV         VG     Fmt  Attr PSize  PFree
/dev/vda1  vgWWW  lvm2 a-   30.00g    0

VG     #PV #LV #SN Attr   VSize  VFree
vgWWW    1   2   0 wz--n- 30.00g    0

LV   VG    Attr   LSize 
root vgWWW -wi-ao 28.80g
swap vgWWW -wi-ao  1.19g

if the VM's OS is using LVM. In the above example the VM has a 30Gbyte vdisk, configured using LVM with one volume group called vgWWW containing two logical volumes, one for swap and one for everything else.

If LV is in use in the VM:

  1. Shut down the VM
  2. On the host create a new virtual disk file and add it to the VM
  3. Restart the VM and login
  4. Mark the new drive as being a physical volume for LVM with sudo pvcreate /dev/vdb
  5. Extend the volume group to include this new block of disk with sudo vgextend vgWWW /dev/vdb
  6. Extend the logical volume to take up the new space with sudo lvextend --extents +100%FREE /dev/vgWWW/root (or something like sudo lvextend --size +8G /dev/vgWWW/root if you don't want to grow it all the way, this example would add 8Gb to the volume)
  7. Resize the filesystem with resize2fs /dev/vgWWW/root

Note: the above assumes the vg/lv names are the same as my example which is unlikely, change as appropriate, also if the VM already had a virtual drive called vdb the new one will be something else (vdc, and so on)

Note: resize2fs will only work on ext2, ext3 and ext4 filesystem. If you are using something else it will error and do nothing.

Note: as you are resizing a live filesystem resize2fs won't prompt you to run fsck first as it would for an unmounted filesystem, it will just go ahead. You might want to run a read-only filesystem check there are no issues before proceeding.

1
6

The 'follow up' you always wanted

  1. stop the VM
  2. run qemu-img resize vmdisk.img +10G to increase image size by 10Gb
  3. start the VM, resize the partitions and LVM structure within it normally...

All credit goes to Josphat Mutai. Note that sizes, disk numbers and names mentioned below are different from the question and yours will be too.

Ubuntu / Debian

$ sudo apt -y install cloud-guest-utils gdisk

CentOS / RHEL / Fedora

$ sudo yum -y install cloud-utils-growpart gdisk

Check if using LVM (indicator for LVM something like /dev/mapper/xyz):

cat /etc/fstab

TL;DR

For 'non lvm', device vda, rootfs at partition 1:

$ sudo growpart /dev/vda 1
# Uncomment and run one of these (ext or xfs)
#sudo resize2fs /dev/vda1
#sudo xfs_growfs /

For 'lvm', device vda, partition 2, physical volume vda2, logical volume group rhel-root :

$ sudo growpart /dev/vda 2
$ sudo pvresize /dev/vda2
$ sudo lvextend -r -l +100%FREE /dev/mapper/rhel-root

For the longer versions of each, see below!


Non LVM

Find partition number using lsblk (in this example "1" from vda1)


     $ lsblk
     NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
     sr0     11:0    1 1024M  0 rom
vda 253:0 0 10G 0 disk └─vda1 253:1 0 10G 0 part /

Grow partition '1' of 'vda' using growpart

    $ sudo growpart /dev/vda 1
    CHANGED: partition=1 start=2048 old: size=20969472 end=20971520 new: size=62912479,end=62914527
 

To grow the file system, first check whether ext2/3/4 or XFS using df:

    $ df -hT | grep /dev/vda
    /dev/vda1      ext4       30G  1.2G   7G   5% /
 

For ext4 file system, use resize2fs:

    $ sudo resize2fs /dev/vda1
    resize2fs 1.42.9 (28-Dec-2013)
     Filesystem at /dev/vda1 is mounted on /; on-line resizing required
     old_desc_blocks = 2, new_desc_blocks = 4
     The filesystem on /dev/vda1 is now 7864059 blocks long.
 

For XFS, it can be grown while mounted using `xfs_growfs:

    $ sudo xfs_growfs /
 

LVM

Find partition number:

    $ lsblk
     NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
     sr0            11:0    1 1024M  0 rom
vda 252:0 0 40G 0 disk ├─vda1 252:1 0 1G 0 part /boot └─vda2 252:2 0 29G 0 part ├─rhel-root 253:0 0 26.9G 0 lvm / └─rhel-swap 253:1 0 2.1G 0 lvm [SWAP]

Grow partition '2' of 'vda' using growpart:

    $ sudo growpart /dev/vda 2
    CHANGED: partition=2 start=2099200 old: size=18872320 end=20971520 new: size=60815327,end=62914527
 

Resize physical volume with pvresize:

    $ sudo pvresize /dev/vda2
      Physical volume "/dev/vda2" changed
      1 physical volume(s) resized or updated / 0 physical volume(s) not resized
 

Find name of volume group using df (yours is likely different than below) and resize logical volume used by the root file system using the extended volume group with lvextend:

    $ df -hT | grep mapper
     /dev/mapper/rhel-root xfs        27G  1.9G   26G   8% /

$ sudo lvextend -r -l +100%FREE /dev/mapper/rhel-root Size of logical volume rhel/root changed from <26.93 GiB (6893 extents) to <36.93 GiB (9453 extents). Logical volume rhel/root successfully resized.

If you didn’t use -r option in previous step, the file system will still show the old size. To make the file system report the actual size, including extended do the following.

For ext4 file system, use resize2fs:

    $ sudo resize2fs /dev/name-of-volume-group/root
 

For xfs filesystem use xfs_growfs:

    $ sudo xfs_growfs /
     meta-data=/dev/mapper/rhel-root  isize=512    agcount=4, agsize=1764608 blks
              =                       sectsz=512   attr=2, projid32bit=1
              =                       crc=1        finobt=1, sparse=1, rmapbt=0
              =                       reflink=1
     data     =                       bsize=4096   blocks=7058432, imaxpct=25
              =                       sunit=0      swidth=0 blks
     naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
     log      =internal log           bsize=4096   blocks=3446, version=2
              =                       sectsz=512   sunit=0 blks, lazy-count=1
     realtime =none                   extsz=4096   blocks=0, rtextents=0
     data blocks changed from 7058432 to 9679872
 

5

This way you can expand the partition you want:

    # see what partitions you have? 
    virt-filesystems --long -h --all -a olddisk

    truncate -r olddisk newdisk
    truncate -s +5G newdisk

    # Note "/dev/sda2" is a partition inside the "olddisk" file.
    virt-resize --expand /dev/sda2 olddisk newdisk

See more examples here.

3

There is a possibility to increase the size of your VM's disk without rebooting the VM if you're using virtio drive and LVM.

  1. Use virt-manager or virsh to define a new empty disk
  2. The kernel should see a new /dev/vdb
  3. (Optional) Create a primary partition with fdisk to get /dev/vdb1, then use kpartx -a /dev/vdb to reread the partition table

  4. Use vgextend vg_name /dev/vdb1 (or /dev/vdb if you did not create a partition)

  5. Use lvextend -l +100%FREE /dev/vg_name/lv_name
  6. Use resize2fs /dev/vg_name/lv_name to extend your filesystem

You're done.

1
2

Another way to do it

truncate -s +2G vm1.img 

go in the make a disk rescan and after you can do your lvm resize.

1

If you have LVM in your VM then this is crazy easy and fast.

  1. Turn off VM (guest machine).
  2. In your host machine add new storage device.
  3. Turn on guest.
  4. Open System -> Administration -> Logical Volume Management (or type sudo system-config-lvm in terminal)*.

I found the GUI quite intuitive, but follow next steps if you have problems.

  1. Open "Uninitialized Entities" and find your new drive.
  2. After selecting new drive, below the image you should find an initialize button. Press it.
  3. It will ask you about partitioning - you don't need it.
  4. When done add your drive to existing volume group.
  5. Finally you need to grow your logical volume(s) - this is done in Logical View of the group by editing properties of your volume.
  6. Save and your done. No need to restart VM.

Note! At least on CentOS 6 LVM GUI is not installed by default, but you can install it with yum install system-config-lvm.

1
  1. Shutdown the VM
  2. Resize image:

    qemu-img resize vmdisk.img +16G
    

    increases image size by 16 GB.

  3. If your image has GPT (GUID Partition Table) then drive size used in GPT will differ from new size, you need to fix it with gdisk:

    MY_DRIVE=/dev/vda
    gdisk $MY_DRIVE <<EOF
    w
    Y
    Y
    EOF
    

    or with parted:

    parted $MY_DRIVE print Fix
    

    For some reason parted fix is not working when no tty is presented (for example when provisioning with Vagrant) so I use gdisk.

  4. Increase partition size to fill all available space:

    MY_PARTITION_GUID=$(
    gdisk $MY_DRIVE <<EOF | sed -n -e 's/^Partition unique GUID: //p'
    i
    EOF
    )
    
    MY_PARTITION_FIRST_SECTOR=$(
    gdisk $MY_DRIVE <<EOF | sed -n -e 's/^First sector: \([0-9]\+\).*/\1/p'
    i
    EOF
    )
    
    gdisk $MY_DRIVE <<EOF
    d
    n
    
    $MY_PARTITION_FIRST_SECTOR
    
    
    x
    a
    2
    
    c
    $MY_PARTITION_GUID
    w
    Y
    EOF
    

    The x a 2 <Enter> part is optional and needed if you are using legacy BIOS. MY_PARTITION_GUID=... and c $MY_PARTITION_GUID parts are also optional and needed only if you use partition UUID in /etc/fstab or somewhere else.

  5. Reboot or reread partitions with partx -u $MY_DRIVE or partprobe.

  6. Extend partition, example for ext2, ext3 or ext4:

    MY_PARTITION="${MY_DRIVE}1"
    resize2fs $MY_PARTITION
    
1
  • sgdisk -e works for me better instead of gdisk w Y Y Jan 18, 2021 at 7:44
0

You can use solus vm with gparted mounted. Once used with the gparted you can easly boot the system and adjust the space. Make sure you have the correct boot priority set. As a reference please refer the below url that could come handy. https://greencloudvps.com/knowledgebase/11/How-to-Extend-the-Hard-drive-on-KVM-after-upgrading-VPS.html

0

GPT Disk and Non-Linux:

virsh shutdown myVM
qemu-img info mydisk.img
sudo qemu-img resize mydisk.img 50G  
sudo sgdisk -e mydisk.img 

New size of mydisk.img of myVM will be 50G and gpt partition table backup will be re-taken to the last sectors of disk. Otherwise most OS does not recognize disk as resized ... Linux does because gparted automatically fixes it most of the time.

! Gparted gets confused if you clone your disk to bigger disk with dd without cleaning bigger disks backup gpt partition (virtual or bare metal disk doesn't matter)

0
  1. Shutdown the vm

virsh shutdown <vm name>

  1. increase the vm's storage volume size

virsh vol-resize <vol path>

  1. Login to vm

  2. increase the partition size

parted <virtual block device name>

providing the partition no and size, it will increase the size of partition.

  1. increase size of filesystem like in case of xfs filesystem

xfs_grow <partition name> -D <size>

Procedure will be same although command may be different base don utility used for increasing the partition and type of filesystem.

1
  • This is only valid when using XFS. If you use LVM, you need to use: lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv followed by: resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv Mar 31, 2023 at 15:33
0

Changing the size of partition 2:

#1 resize disk size ( I used GUI on UTM )

#2 under guest operating system

sudo parted /dev/vda
 ( has changed, F)ix )
resizepart 2 100%
  ( warning, proceed - yes )
quit

sudo resize2fs /dev/vda2

df -h
0

Below steps works for me, I am not expert on this and don't know much detail technicality behind this command. I am using Ubuntu 22.04

  1. Shutdown guest os and run following on host os
  2. qemu-img resize /dev/mapper/ubuntu--vg-ubuntu--lv +10G
  3. start guest and run following command on it.
  4. sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
  5. sudo resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
  6. sudo vgdisplay
  7. df -h

Ref: https://packetpushers.net/ubuntu-extend-your-default-lvm-space/

0

This function pulls an ubuntu image, resizes it, then resizes the partition, and finally updates the boot table.

image_setup(){
WORKDIR="/root/"
VMSIZE="10G"
cd $WORKDIR
virsh destroy vm
virsh undefine vm
wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg- 
amd64-disk-kvm.img -O $WORKDIR/jammy-server-cloudimg-amd64-disk-kvm.img
rm -f $WORKDIR/ubuntu-22.04.qcow2
mv $WORKDIR/jammy-server-cloudimg-amd64-disk-kvm.img $WORKDIR/ubuntu- 
22.04.qcow2
qemu-img resize $WORKDIR/ubuntu-22.04.qcow2 $VMSIZE
cp $WORKDIR/ubuntu-22.04.qcow2 $WORKDIR/ubuntu-22.04.qcow2.old
sudo virt-resize --expand /dev/sda1 $WORKDIR/ubuntu-22.04.qcow2.old 
$WORKDIR/ubuntu-22.04.qcow2
rm $WORKDIR/ubuntu-22.04.qcow2.old
sudo virt-customize -a $WORKDIR/ubuntu-22.04.qcow2 --run-command 'grub- 
install /dev/sda'
}

image_setup #function call
#run your virsh-install now

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .