How to increase disk size in virtual machine without reboot?

Question

Virtualization

The task is this. There is a host machine on Debian. It has QEMU-KVM virtualization configured. There is also a virtual machine on Debian. An LVM block device is used as a disk for the virtual machine. I needed to increase the disk size for the virtual machine. Naturally, I do everything from the host
lvresize -L+8G <lv_name> <vg_name>
. Everything is fine. The device has grown.
I also use LVM inside the virtual machine. If you stop the virtual machine (namely shutdown -h 0, not reboot), then then there are no problems with increasing the partitions in the virtual machine.
Actually the question is how to increase the size of partitions inside the virtual machine without stopping it? If this is of course possible.

Answer 1

Same way. We re-query disk devices, increase the volume on which the lvm is located and then expand the lvm and the file system

Answer 2

echo 1 > /sys/bus/scsi/devices/2\:0\:0\:0/rescan
Where 2:0:0:0 is the scsi id of the device. After that, the bucket should report that the disk size has changed:
May 22 01:49:58 ххх kernel: sda: detected capacity change from 107374182400 to 128849018880
And after that, when the bucket realized that the disk is of a different size, partprobe goes. True, if there is a system on this disk (/boot, /usr ...), partprobe will glue the bots together and only reboot.

Answer 3

I'll write it myself too. Googling more closely, I found out that such tricks will not work with the root file system, CityCat4 already wrote about this . But I came across this old article. Resize a live root FS - a HOWTO. She is almost 10 years old, but I think she has not lost her relevance. There used

pivot_root - change the root file system

pivot_root moves the root system of the current process to the put_old directory and sets the new_root directory to the new root file system of the current process.

It turns out quite an interesting way. We can't force the kernel to re-cache the partition table until we remount it, but we can copy the entire OS first! into RAM, then remount the root and do whatever it takes.
Unfortunately, I have not yet reproduced this on my virtual machine (I have only one gig of memory on the problem machine), but I will definitely try and unsubscribe.
Thanks to everyone who responded.