In this article, we will talk about resizing the disks of a KVM virtual machine, and consider the virtual disk formats used. We will show how to properly increase the disk of a virtual machine in a KVM hypervisor on Linux without losing data, and we will also discuss options for reducing disk sizes.
Increasing the disk of a KVM virtual machine.
Expanding the virtual disk from the KVM side.
In order to work with the disk, the virtual machine must be turned off, otherwise we will not be able to do anything. Consider an example with an increase in a disk whose size was initially 20 GB.
To view the disk parameters of a KVM virtual machine, use the command:
qemu-img info /path_to_disk
The output of the command will be something like this:
We see that we have two fields that indicate the size, these are virtual_size and disk_size:
- virtual_size - virtual disk size specified when creating or expanding the disk (in this example, the maximum disk size is 20 GB);
- disk_size - the size of the disk file at the current moment, i.e. how much space the disk image currently takes up on the physical server (only applies to the qcow format). In our example, the virtual disk takes up only 1.6 GB of storage.
And immediately about the formats. When creating virtual machines on KVM, I recommend using the qcow2 disk format, not raw. A little later I will explain why.
The next step is to expand the disk of the virtual machine by 5Gb (for the correct expansion of the disk, the virtual machine must not have snapshots!).
# qemu-img resize /path to disk +5G
Gimage resized.
If we immediately check the output of information about the disk image, we will see that it has expanded:
# qemu-img info /path to disk
image: /path_to_diskWe have done part of the work, but work is also required on the part of the virtual machine in the guest OS. Next, we'll show you how to increase disk size in CentOS 7 and Windows Server 2012 guests.
file format: qcow2
virtual size: 25G (26843545600 bytes)
disk size: 1.6G
cluster_size: 65536
Format specific information:
compat: 0.10
refcount bits: 16
If you plan to add an additional virtual disk for a VM on a KVM hypervisor, qemu-img and virsh are used.
Extending a Partition in a Linux CentOS Virtual Machine.
After expanding the disk from the server side, you need to start the virtual machine and connect to it via ssh. All work will be carried out using the fdisk hard disk partition management utility.
After connecting to the server, we check the availability of our additionally connected place:
df –h
fdisk -l
The screenshot shows that the /dev/vda2 partition has a size of 20Gb, and we have more available disk space.
Let's fix this moment and expand the /dev/vda2 partition to the maximum size:
# fdisk /dev/vda
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command(m for help): d
Partition number (1,2, default 2):
Partition 2 is deleted
Command (m for help): n
Partition type:
p primary (1 primary, 0 extended, 3 free)
e extended
Select(default p): p
Partition number (2-4, default 2):
First sector (1050624-52428799, default 1050624):
Using default value 1050624
Last sector, +sectors or +size{K,M,G} (1050624-52428799, default 52428799):
Using default value 52428799
Partition 2 of type Linux and of size 24.5 GiB is set
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 or after you run partprobe(8) or kpartx(8)
Synchronizing disks.
# xfs_growfs /dev/vda2
meta-data=/dev/vda2 isize=512 agcount=4, agsize=1277888 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0 spinodes=0
data = bsize=4096 blocks=5111552, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime=none extsz=4096 blocks=0, rtextents=0
data blocks changed from 5111552 to 6422272
# df -h
Filesystem Size Used Avail Use% Mounted onAs a result, we got an extended partition /dev/vda2. Now, in order, what exactly we did:
devtmpfs 485M 0 485M 0% /dev
tmpfs 496M 0 496M 0% /dev/shm
tmpfs 496M 6.6M 489M 2% /run
tmpfs 496M 0 496M 0% /sys/fs/cgroup
/dev/vda2 25G 1.3G 24G 6% /
/dev/vda1 488M 100M 353M 23% /boot
tmpfs 100M 0 100M 0% /run/user/0
- fdisk /dev/vda - run the fdisk utility by connecting to the /dev/vda partition
- / d - delete the section, by default it is section 2 which is what we need, so in the next paragraph we just press Enter
- / n - create a new partition, in the next paragraph just press Enter or enter p , then Enter since the partition created by default will be 2.
- When specifying the first and last sector, just press Enter, if we want to expand the partition to the maximum, if you want to specify a specific size, in the last sector, specify the disk size as indicated in the menu +size{K,M,G} The size cannot be less than before!
- /w - apply our settings.
xfs_growfs /dev/vda2Some sources indicate the command to perform this procedure:
resize2fs /dev/vda2But with the xfs file system it doesn't work! Work on expanding the disk on a virtual machine running CentOS 7 is completed.
Increasing Disk in Windows Server Guest.
- Open Server Manager -> Tools -> Computer Management;
- In the window that opens, select Disk Management from the menu , after which you should see all your disks and unallocated space that we added from the KVM hypervisor side;
- Select the desired disk and click Extended Volume;
- By default, all available space will be offered to increase the disk size;
- Click next to complete the extension. After this procedure, your partition in the system will have to expand;
I would like to add that before expanding the disk for a virtual machine, I advise you to back up the disk itself. Stop the virtual machine and copy the disk image to the backup directory or to any directory that has free space. If something goes wrong during the work, you can always return the virtual disk image from the backup.
How to reduce virtual disk size in KVM?
In my work, earlier I quite often encountered this issue, but unfortunately, it is impossible to painlessly reduce the disk on a virtual machine in KVM! The only acceptable size for reducing the disk size of a KVM virtual machine on physical storage is to compress it through conversion.
There are many articles on the internet claiming that you can reduce the size of the disk in a virtual machine, but it doesn't work.
I will give a few examples that I came across and that I have personally tested.
Shrinking a KVM Disk with qemu.
A number of resources describe the actions performed using the qemu utility. They suggest reducing the size of the virtual machine disk using the command:
qemu-img resize /path_to_disk -5G - reduce the disk to 5GOr this option with a specific size:
qemu-img resize /path_to_disk 25G - specify the disk size in 25GWhat happens after executing this command? We start the server and of course the system does not boot:
I tried first to reduce the partition from under the system using the fdisk utility, but in this case, the system also stops booting, even if you skip the step of reducing the disk from the physical server, and this is logical. The partition that we reduce is the system one and, accordingly, the OS stops loading, since when the disk is reduced, the information is apparently destroyed.
Reducing a virtual disk with image replacement.
An option that is no longer so common in the instructions is to reduce the disk, replacing it with the old one. That is, you create a new virtual machine with the disk size you need. After that, replace the old disk image with a new image, and judging by the description of articles in various sources, it works. I also did a check and it broke the file system, as in the first option. I will give an example command:
virt-resize /old_disk_image / new_disk_image
Options were also given, with converting a disk from raw format to qcow2 format, BUT I initially create machines in this format and I will explain why.
KVM disk formats and disk compression in qcow2 format.
At the very beginning of the article, I mentioned these two formats.
raw - translated as "raw". Format advantage, maximum productivity, format versatility. There are a lot of cons, the main ones are:
- The disk occupies all the disk space on the physical server that has been allocated to it;
- Snapshots cannot be created.
Qcow2 is the native format of the QEMU hypervisor, as well as QEMU-KVM. This is the most convenient virtual disk format of all supported in KVM. The disk image grows as data accumulates on the virtual machine, snapshots are supported.
Why is the qcow2 format good? In principle, you do not need to reduce the size of the virtual disk, since the disk occupies on the server exactly as much as the space is occupied there. If your data on the server is constantly overwritten and it happens that the disk is “swollen”, it can be easily compressed. Let's consider this option. I will fill in some disk space with zeros and then delete the file:
dd if=/dev/zero of=/mytempfile
rm -rf /mytempfile
When checked from the server, the disk image first weighed 2.4G and then expanded to 5.9G:
# du -sh /image_path
2.4G*****
# du -sh /image_path
5.9G*****That is, after deleting information on a virtual machine, the disk did not shrink back. To get the disk file up to date, I use the following method.
Back up the disk file, stop the virtual machine and then perform the following steps:
qemu-img convert -O qcow2 /old_image / new_image
Then you can check the sizes of the two disks:
# du -sh /new_disk
1.6G /****
# du -sh /old_disk
5.8G /****As you can see, the size of the compressed disk is 1.6G. Let's rename the new disk image to the one we need and start the virtual machine:
# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 485M 0 485M 0% /dev
tmpfs 496M 0 496M 0% /dev/shm
tmpfs 496M 6.6M 489M 2% /run
tmpfs 496M 0 496M 0% /sys/fs/cgroup
/dev/vda2 25G 1.3G 24G 6% /
/dev/vda1 488M 100M 353M 23% /boot
tmpfs 100M 0 100M 0% /run/user/0
Control check from the server:
# du -sh /disk_image
1.6G /****
Working method. For all the time of its use, the file system on the virtual machine has never died. But I strongly recommend that before such work, create a copy of the disk if you do not want to lose data.
That's all I wanted to tell in this article.