Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1053890 - PRD34 - [RFE] Update storage domain's LUNs sizes in DB after lun resize
Summary: PRD34 - [RFE] Update storage domain's LUNs sizes in DB after lun resize
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.4.0
Assignee: Daniel Erez
QA Contact: Aharon Canan
URL:
Whiteboard: storage
Depends On: 961532
Blocks: rhev3.4beta 1092741 1142926
TreeView+ depends on / blocked
 
Reported: 2014-01-15 22:39 UTC by Sean Cohen
Modified: 2016-02-10 20:24 UTC (History)
17 users (show)

Fixed In Version: ovirt-3.4.0-beta2
Doc Type: Enhancement
Doc Text:
After a LUN has been expanded from the storage side, pvresize is now run in order to retrieve the correct storage domain volume group size.
Clone Of: 961532
Environment:
Last Closed: 2014-06-09 15:08:56 UTC
oVirt Team: Storage
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2014:0506 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Virtualization Manager 3.4.0 update 2014-06-09 18:55:38 UTC
oVirt gerrit 22887 None None None Never

Description Sean Cohen 2014-01-15 22:39:01 UTC
+++ 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.

Comment 1 Aharon Canan 2014-03-09 12:26:11 UTC
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

Comment 4 errata-xmlrpc 2014-06-09 15:08:56 UTC
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

Comment 5 Dax Kelson 2014-09-17 16:08:00 UTC
(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.

Comment 6 Marina 2015-01-21 21:51:11 UTC
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?

Comment 7 Allon Mureinik 2015-01-22 05:25:12 UTC
(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?

Comment 8 Daniel Erez 2015-01-22 07:14:08 UTC
(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

Comment 9 Marina 2015-01-22 15:26:06 UTC
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

Comment 10 Daniel Erez 2015-01-22 15:40:43 UTC
(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/


Note You need to log in before you can comment on or make changes to this bug.