+++ This bug was initially created as a clone of Bug #961532 +++ Description of problem: I setup an iSCSI storage domain with a LUN that was too small. After I resized the LUN on the storage array, ovirt still saw the original size. I got a command line on the node running spm, and tried running pvresize to no avail. I ended up doing low level hacking by attaching to the VG group from another Linux box and running pvresize, then rebooting all my nodes. This needs to be handled much more gracefully and from the UI. --- Additional comment from Jiri Vitek on 2013-09-17 12:29:06 EDT --- This feature will be very welcome, i was asking on same in very first 3.0 release --- Additional comment from Juan Pablo Lorier on 2013-11-20 06:38:01 EST --- Hi, Same situation. I need to enlarge my iscsi LUN, peace of cake by the linux side but had no solution from within ovirt. I had set the SD to mantainance and back to active as suggested in the list, but it didn't work. Also tried force a SPM reelection as another suggested and it didn't work either. I shouldn't be that hard to recheck the size of the SD once you re activate it (at least) --- Additional comment from Ayal Baron on 2013-11-21 08:35:16 EST --- (In reply to Juan Pablo Lorier from comment #2) > Hi, > > Same situation. I need to enlarge my iscsi LUN, peace of cake by the linux > side but had no solution from within ovirt. > I had set the SD to mantainance and back to active as suggested in the list, > but it didn't work. Also tried force a SPM reelection as another suggested > and it didn't work either. > I shouldn't be that hard to recheck the size of the SD once you re activate > it (at least) Ack, we're already pulling the data from the spm when activating so it should just be a matter of updating the info in the db. Daniel, let's track that change here. --- Additional comment from Jiri Vitek on 2013-11-21 10:41:22 EST --- please keep on mind features like netapp volume/lun autogrow --- Additional comment from Daniel Erez on 2014-01-01 09:15:08 EST --- According to the suggestion solution, added LUN device size synchronization as part of storage domain activation. I.e. when activating an iSCSI storage domain, device size mismatch is detected and updated accordingly in the DB. --- Additional comment from Allon Mureinik on 2014-01-13 12:03:40 EST --- In order to make the scope of this RFE clear, it only handles resizing a LUN that is part of storage domain. Handling direct LUNs should be tracked in a different BZ.
Verified using 3.4 av2 TCMS run - https://tcms.engineering.redhat.com/run/118096 Please be aware that after expanding the lun from the storage side, we need to run pvresize to the new lun size to get the new SD (vg) size for example - ----------------- pvresize --setphysicalvolumesize 125G /dev/mapper/3600601601282300056f0075c3f81e311
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, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2014-0506.html
(In reply to Aharon Canan from comment #1) > Verified using 3.4 av2 > TCMS run - https://tcms.engineering.redhat.com/run/118096 > > Please be aware that after expanding the lun from the storage side, we need > to run pvresize to the new lun size to get the new SD (vg) size > > for example - > ----------------- > pvresize --setphysicalvolumesize 125G > /dev/mapper/3600601601282300056f0075c3f81e311 The --setphysicalvolumesize is unneeded, no? Without that switch it will just match the PV to the size of the LUN.
Hey, not clear to me what does this bug cover. Reading this: https://bugzilla.redhat.com/show_bug.cgi?id=609689#c42 Does it mean, that this bug only covers iscsi lun resize. I.e. when lun is resized for a VG for iscsi storage domain, storage domain size would be automatically adjusted in RHEV to match it?
(In reply to Marina from comment #6) > Hey, not clear to me what does this bug cover. > Reading this: > https://bugzilla.redhat.com/show_bug.cgi?id=609689#c42 > > Does it mean, that this bug only covers iscsi lun resize. I.e. when lun is > resized for a VG for iscsi storage domain, storage domain size would be > automatically adjusted in RHEV to match it? Daniel, can you answer this please?
(In reply to Marina from comment #6) > Hey, not clear to me what does this bug cover. > Reading this: > https://bugzilla.redhat.com/show_bug.cgi?id=609689#c42 > > Does it mean, that this bug only covers iscsi lun resize. I.e. when lun is > resized for a VG for iscsi storage domain, storage domain size would be > automatically adjusted in RHEV to match it? Hi Marina, This bug addresses mismatch detection of LUN device size merely in the DB (for block storage domains). I.e. resize of the underlining storage should still be done manually (as mentioned in [1]). So the domain size would be automatically adjusted in DB after proper resizing of the PV (FC storage requires additional steps described in [2]). [1] https://bugzilla.redhat.com/show_bug.cgi?id=1053890#c1 [2] https://access.redhat.com/solutions/376873
Daniel, thanks. Do we ever plan automating the complete process? And what does this bug come to cover? https://bugzilla.redhat.com/show_bug.cgi?id=609689#c42
(In reply to Marina from comment #9) > Daniel, thanks. > Do we ever plan automating the complete process? > > And what does this bug come to cover? > https://bugzilla.redhat.com/show_bug.cgi?id=609689#c42 This bug is for automating the entire process. As we already doing the rescan step as part of [1], the rest should be basically invoking pvresize (and probably expose a means to specify new size for a lun/domain). Not sure about priority though (as the effort is not trivial). @Allon - what do you think? [1] http://gerrit.ovirt.org/#/c/34245/