[ovirt-users] Resize of virtio disk

[Gianluca Cecchi]

Hello,
I seem to remember that online resize of VirtIO disk is possible.
Now I have an Oracle Linux VM with 2.6.39-400.215.3.el6uek.x86_64 kernel
where I resize a disk (/dev/vdb) from 500Gb to 900Gb.
Apparently the kernel acquired the change because in /var/log/messages I
see:

May 31 14:16:16 dbatest3 kernel: virtio_blk virtio6: new size: 1887436800
512-byte logical blocks (966 GB/900 GiB)

but fdisk seems not to be able to recognize it:

[root at dbatest3 ~]# fdisk -l /dev/vdb

Disk /dev/vdb: 536.9 GB, 536870912000 bytes
16 heads, 63 sectors/track, 1040253 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

[root at dbatest3 ~]#

oVirt is 4.1.1 with hypervisor running the VM being in CentOS 7.3 with
libvirt 2.0.0-10.el7_3.5 and qemu-kvm-ev 2.6.0-28.el7_3.6.1

I was not able to find the rescan option I eventually need to execute (but
I think not necessary because the kernel already detected it).
Is this a bug in fdisk itself?
I have an LVM PV on the whole disk, but of course a pvresize doesn't notice
any change in it.
I verified that in my kernel the ACPI PCI hotplug feature is compiled into
the kernel and not as a module:

[root at dbatest3 ~]# grep "CONFIG_HOTPLUG_PCI_ACPI="
/boot/config-2.6.39-400.215.3.el6uek.x86_64
CONFIG_HOTPLUG_PCI_ACPI=y
[root at dbatest3 ~]#

I tried also this:

echo 1 > /sys/devices/pci0000\:00/0000\:00\:09.0/rescan

because of the tree below:

[root at dbatest3 ~]# ll /sys/devices/pci0000\:00/0000\:00\:09.0/virtio6/
total 0
drwxr-xr-x 3 root root    0 May 31 11:45 block
-r--r--r-- 1 root root 4096 May 31 14:19 device
lrwxrwxrwx 1 root root    0 May 31 14:19 driver ->
../../../../bus/virtio/drivers/virtio_blk
-r--r--r-- 1 root root 4096 May 31 14:19 features
-r--r--r-- 1 root root 4096 May 31 14:19 modalias
drwxr-xr-x 2 root root    0 May 31 14:18 power
-r--r--r-- 1 root root 4096 May 31 14:19 status
lrwxrwxrwx 1 root root    0 May 31 14:16 subsystem -> ../../../../bus/virtio
-rw-r--r-- 1 root root 4096 May 31 14:16 uevent
-r--r--r-- 1 root root 4096 May 31 14:19 vendor
[root at dbatest3 ~]#

[root at dbatest3 ~]# ll /sys/devices/pci0000\:00/0000\:00\:09.0/virtio6/block
total 0
drwxr-xr-x 7 root root 0 May 31 11:45 vdb
[root at dbatest3 ~]#

[root at dbatest3 ~]# ll
/sys/devices/pci0000\:00/0000\:00\:09.0/virtio6/block/vdb/
total 0
-r--r--r-- 1 root root 4096 May 31 14:19 alignment_offset
lrwxrwxrwx 1 root root    0 May 31 14:19 bdi ->
../../../../../virtual/bdi/251:16
-r--r--r-- 1 root root 4096 May 31 14:19 capability
-r--r--r-- 1 root root 4096 May 31 14:15 dev
lrwxrwxrwx 1 root root    0 May 31 14:19 device -> ../../../virtio6
-r--r--r-- 1 root root 4096 May 31 14:19 discard_alignment
-r--r--r-- 1 root root 4096 May 31 14:19 ext_range
drwxr-xr-x 2 root root    0 May 31 14:18 holders
-r--r--r-- 1 root root 4096 May 31 14:19 inflight
drwxr-xr-x 2 root root    0 May 31 14:18 power
drwxr-xr-x 3 root root    0 May 31 14:16 queue
-r--r--r-- 1 root root 4096 May 31 14:19 range
-r--r--r-- 1 root root 4096 May 31 14:16 removable
-r--r--r-- 1 root root 4096 May 31 14:19 ro
-r--r--r-- 1 root root 4096 May 31 14:16 serial
-r--r--r-- 1 root root 4096 May 31 14:19 size
drwxr-xr-x 2 root root    0 May 31 14:18 slaves
-r--r--r-- 1 root root 4096 May 31 14:19 stat
lrwxrwxrwx 1 root root    0 May 31 11:45 subsystem ->
../../../../../../class/block
drwxr-xr-x 2 root root    0 May 31 14:18 trace
-rw-r--r-- 1 root root 4096 May 31 11:45 uevent
[root at dbatest3 ~]#

Any hint to avoid guest reboot and have fdisk recognize the happened resize?
In the future I'm going to upgrade from the current 6.5 version, so that I
can also use Virtio-SCSI driver and so standard SCSI commands when adding
disks or resizing existing ones, but this VM was "imported" by another
environment and I have initially to be stick with it in this precise
configuration.

Thanks in advance,
Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170531/9cbc87ed/attachment.html>