Extend/rescan virtio disk in guest vm

[Frido Roose]

Hello,

I'm trying to figure out if there is a way to online extend a virtual disk (/dev/vdb) on the guest?

I checked http://pve.proxmox.com/wiki/Resizing_disks but I can't find the answer there.

On the proxmox host, I extended the logical volume for the data disk (it's not the vm boot/root disk but an additional data disk), but now I'm stuck at the point where I want to "rescan" the bus on the guest.
Since the virtio disk is not on the scsi bus, the usual methods to rescan the scsi bus don't work.

I even tried doing a "qemu-img resize /dev/guestdata/vm-100-disk-1 150G" on the logical volume, hoping that it would inform the guest about the new size, but no luck so far.

Anyone an idea how I can tell the guest about the new disk size without doing a reboot of the guest?

Thanks,
Frido

 

[Frido Roose]

After some more investigation, it looks like this has been implemented in libvirt 0.9.8:

https://www.redhat.com/archives/libvir-list/2011-November/msg01570.html
and
http://libvirt.org/news.html

block_resize: Update test file for RPC (Osier Yang),
block_resize: Expose the new API to virsh (Osier Yang),
block_resize: Implement qemu driver method (Osier Yang),
block_resize: Implement qemu monitor functions (Osier Yang),
block_resize: Wire up the remote protocol (Osier Yang),

libvirt0 0.9.8-2 is only available in Debian testing (Wheezy). The version in Debian Squeeze is still 0.8.3-5+squeeze2.

Any chance that this will be backported?

 

[dietmar]

Any chance that this will be backported?

We do not use libvirt.

 

[Frido Roose]

Does this also mean that Proxmox does/will not support this functionality or that it is implemented otherwise? Is it on the roadmap?

If I find a backport and try to get this working through libvirt, would that interfere with Proxmox?
What if we would like to have commercial support, would that break the support?

Thanks for some clarification.

 

[dietmar]

Does this also mean that Proxmox does/will not support this functionality or that it is implemented otherwise? Is it on the roadmap?

We do not plan to implement that. I suggest you simple stop/start the vm.

 

[lievenva]

We think the design concept of Proxmox is very nice. The clustered management is a key distinguising feature compared to other solutions. It's open source, enabling us to quickly identify issues and work around / fix blocking situations.

We are evaluating proxmox as enterprise virtualisation platform, but the above answer is not encouraging to keep evaluating proxmox as our target platform. I think live resizing of an underlying block device all the way up to the VM is a key enterprise feature, as valuable as live migration.

We indicated we are willing to invest into this solution by means of having a commercial support contract, though other options are feasible to. Though we are not going to go that way if you stick with the above statement. I ask you to please reconsider and think about the business cases that drive this question.

Thanks a lot,

Lieven

 

[tom]

commercial support is not the same as developing features, you should not mix that up.

if you want to contribute in any way, see http://www.proxmox.com/products/proxmox-ve/get-involved

 

[lievenva]

commercial support is not the same as developing features, you should not mix that up.

http://www.proxmox.com/products/proxmox-ve/get-involved

Thanks for your reply.

I do understand your point. Though I'm sure there must be a way to eventualy sponsor some feature development. That said, the question remains if you are open to the development of this kind of feature, or stick stricktly to the layed-out roadmap. But I guess there are better suited channels to communicate about this subject..

 

[tom]

yes, the link I sent contains details about the communication with the dev´s, and if you think of paying the feature development you can also contact office@proxmox.com

 

[spirit]

I'll try to add it for 2.0 release (command line), doesn't seem complicated:

it's just a qemu monitor command

block_resize deviceid newsize

 

[Frido Roose]

Thanks for your feedback!

I can be wrong, but isn't qm monitor block_resize intended for image files instead of LVM logical volumes?
We are using the LVM backend, that was not clear from the initial question.

 

[spirit]

I'll take a look more deeply at the libvirt code.

maybe we need to resize lvm first, then use qemu command to live resize disk in vm (without reboot).

On my side,I'm using iscsi lun and I can already resize them (on my san) and the vms can see the new size (without qemu command or reboot).

 

[Frido Roose]

That's interesting. I guess you are directly importing the iscsi lun on the guest? I suppose you have to rescan?

In our situation, the lun is on a fibre channel san, and I already do the necessary rescan and lvextend on the host.
It just isn't picked up in the guest, and since it is virtio and no scsi bus, the usual tools don't work.

Yesterday I tried qm monitor block_resize on the LVM logical volume, but no effect...

 

[spirit]

I made some verif, finally, I also can't see the new size without reboot the vm (with direct lun, or with lvm)

and I found interesting mail:

http://web.archiveorange.com/archive/v/1XS1v3R2g9iBX9UXsT64

"

This means that we can only use 'block_resize' for disks​

that are backed by image files (raw, qcow2, etc) that QEMU can actuallyresize."
To be able to support online resize of virtual disks backed by hostblock devices, LVM volumes, SCSI LUNs, iSCSI LUNs, etc we need to beable to decouple these tasks. The resize of the block device needs tobe done outside QEMU, either by privileged tools on the host, or by aremote SAN administrator, or a combo of both."


so seem to work only with files. (it's resizing the file + tell the vm the new size)

They said we need something like

"block_refresh or block_resize refreshonly"

I'm not sure it's already implemented in qemu ....

​

 

[spirit]

another interesting mail:

http://fossplanet.com/f13/[libvirt]-[patch-0-6]-support-online-block-resizing-189995/

"For block device of virtio bus, the guest can update the device
size automatically, needs kernel support, since kernel-2.6.32-117:

http://patchwork.usersys.redhat.com/patch/33040/

For block device of SCSI bus, one needs to execute command like
below in the guest (linux) to update the size:

% echo > /sys/class/scsi_device/0:0:0:0/device/rescan

For block device of IDE bus, seems there is no way to let guest
update the size after resizing."


I I understand, it must work with block device (lvm must work), but we need a kernel patch in guest for virtio device.

I'm using debian guests so I don't know if the patch is in the debian kernel > 2.6.32 .

 

[Frido Roose]

Thanks for sharing the information.
If I read this, I would think that the patch is included in the 2.6.32-117 kernel (the link to patchwork doesn't work here)?
Anyway, I tested with a 2.6.32.12 kernel in the guest, so that might explain why I couldn't see the new size in the guest.
Perhaps I'll try a centos 6.2 guest with a 2.6.32-220 to see if the patch is already included.