Description of problem: After a LUN resize, Guest using it as a Direct LUN device is not able to see the new size. Version-Release number of selected component (if applicable): rhevm-3.4.2-0.2.el6ev.noarch How reproducible: 100% Steps to Reproduce: 1. Attach a Direct LUN to a VM 2. On-line resize the LUN (on underlying storage) 3. Check the new size on the Guest: fdisk -l /dev/vdb Actual results: Guest OS is listing the old size. Expected results: Provide button called "Update Size" or so, for Direct LUNs under VM Disks sub-TAB, which will update the Direct LUN size for that VM. Additional info: To make the Guest OS recognize the new size, currently we need to run (on the Host running the VM): # multipathd -k"resize map 35005907f1cb9a3d9" # virsh -c qemu:///system blockresize --path /dev/mapper/35005907f1cb9a3d9 --size 120G <guest_name>
Daniel, don't modern kernels (from the guest side) solve this?
(In reply to Allon Mureinik from comment #1) > Daniel, don't modern kernels (from the guest side) solve this? afaik, it's mandatory, see bug 1176550
*** Bug 1176550 has been marked as a duplicate of this bug. ***
Right now, in order to get the new direct lun size in the guest, this is what we should do: 1. Run a GET request via the REST API to get the storage details about the host of the relevant VM. For example: http://localhost:8080/api/hosts/<host_id>/storage 2. Get the LUN ID from the webadmin (Disks -> General -> LUN ID). 3. Get the VM ID from the webadmin (Virtual Machines -> General -> VM Id). 4. Run: virsh -c qemu:///system blockresize --path /dev/mapper/<LUN_ID> --size <new_block_size>G <VM_ID> And for the future: - In the vdsm side, we already have a function called "diskSizeExtend" in vm.py that eventually calls the block resize in qemu. - In the engine side, we already have ExtendVmDiskSizeVDSCommand that gets ExtendVmDiskSizeVDSCommandParameters and calls the disk resize in vdsm. What we can do is creating a new parameters object for LUN disks that will hold the LUN ID, and use ExtendVmDiskSizeVDSCommand with minor changes in vdsm to call the block resize function in qemu, but this time on a direct LUN.
I'm pushing out this RFE based on the stage we're in, and resetting the acks so this is re-discussed in a future version planning. Roman - can we get the steps described in comment 7 published in a KBase please?
Can we set a target release, hopefully 4.1.1 or 4.2? Thanks, Gianluca
(In reply to Gianluca Cecchi from comment #19) > Can we set a target release, hopefully 4.1.1 or 4.2? Not without a patch for it ;-) > Thanks, > Gianluca
Ah, ok. I thought one could set an attempt release for version even without a patch already in place. Sorry
(In reply to Gianluca Cecchi from comment #21) > Ah, ok. > I thought one could set an attempt release for version even without a patch > already in place. > Sorry We could, but I rather do it when I know we'll have someone working on it. I don't want to give the false impression.
This will be solved via Cinder integration.
Currently, this one can be done by using the refreshlun SDK command http://ovirt.github.io/ovirt-engine-api-model/master/#services/disk/methods/refresh_lun. It's also available from the UI: Storage > Disks > {choose a direct LUN disk} > {3 dots menu} > Refresh LUN. I'll work on adding that functionality to the VM resource (SDK and UI).
Comment 39 seems not to be updated/accurate. By using refreshLUNs SDK, the LUN size is being updated on the UI & DB, but not on the running guest. Work in progress.
Verified on rhv-4.4.5-7
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: RHV Manager (ovirt-engine) 4.4.z [ovirt-4.4.5] security, bug fix, enhancement), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:1169