Bug 1092741 - [DOC] pvresize is required when resizing a LUN in RHEVM
Summary: [DOC] pvresize is required when resizing a LUN in RHEVM
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.5.0
Assignee: Andrew Burden
QA Contact: Tahlia Richardson
Whiteboard: storage
Depends On: 1053890
Blocks: 1193259
TreeView+ depends on / blocked
Reported: 2014-04-29 21:07 UTC by Scott Herold
Modified: 2016-02-10 20:22 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-03-13 06:27:49 UTC
oVirt Team: Storage
Target Upstream Version:

Attachments (Terms of Use)
iSCSI Edit Domain (68.44 KB, image/png)
2014-04-29 21:07 UTC, Scott Herold
no flags Details
tail -f /var/log/vdsm/vdsm.log | grep iSCSI -- from SPM (12.25 KB, text/x-log)
2014-04-29 21:07 UTC, Scott Herold
no flags Details

Description Scott Herold 2014-04-29 21:07:00 UTC
Created attachment 890940 [details]
iSCSI Edit Domain

Description of problem:
While testing the new iSCSI Resize in RHEV 3.4 Beta 3, the new LUN size is not properly reflected in the Storage Tab of a Datacenter.

Version-Release number of selected component (if applicable):

How reproducible:
I seem to be good at it

Steps to Reproduce:
1. Created 150GB Storage Domain using tgtd on standalone RHEL 6.5 Server.  Backing on tgtd is .img file created with "fallocate -l 150G iscsi2.img"
2. Configure RHEV Manager in a mixed storage domain (NFS Master) to access the iSCSI Data Domain.
3. Create a 147GB Disk file on the iSCSI Storage Domain putting the SD very near capacity
4. Put iSCSI Storage Domain into Maintenance Mode
5. Resize the iscsi2.img file with "fallocate -l 200G iscsi2.img"
6. Stop and Restart tgtd service on storage server to ensure new file size has taken effect
7. Activate iSCSI Storage Domain on RHEV Manager

Actual results:
Looking at the storage tab of a datacenter and the iSCSI Storage Domain does not reflect the new size of the LUN.  Running "tgt-admin --show" on the storage server running tgtd shows the following results:

LUN: 4
            Type: disk
            SCSI ID: IET     00010004
            SCSI SN: beaf14
            Size: 214748 MB, Block size: 512
            Online: Yes
            Removable media: No
            Prevent removal: No
            Readonly: No
            Backing store type: rdwr
            Backing store path: /nfs/iscsi2.img
            Backing store flags: 

Going into the iSCSI storage domain and editing the details shows that the LUN Dev. Size is reflected as 200GB for the target in question (See Screenshot "iSCSI Edit Domain.png".  In the same screenshot, you can see that the storage domain still has "149GB" listed as Total Space.

Expected results:
Expecting storage domain to match the LUN size that is seen by RHEV as per the 3.4 RFE.

Additional info:
I did a quick tail -f of the vdsm.log file of the SPM while trying to scan the updated storage... I may have greped out too much info, but it may help.  Otherwise I can provide additional log files, or provide direct access to the systems I'm using.

Comment 1 Scott Herold 2014-04-29 21:07:59 UTC
Created attachment 890942 [details]
tail -f /var/log/vdsm/vdsm.log | grep iSCSI  --  from SPM

Comment 2 Scott Herold 2014-04-29 21:44:11 UTC
It appears there are additional manual steps required on the SPM before the Storage Domain shows the proper total space...

Continuing steps from original Summary:

8. With the iSCSI storage domain activated i ran pvscan from the SPM and saw that the pv for the LUN was still set to 150G.

9. With the iSCSI storage domain still activated, I ran the following from the SPM: "pvresize --setphysicalvolumesize 200G /dev/mapper/1IET_00010004" <--proper /dev/mapper found from pvscan in prior step.

10. Put the iSCSI storage domain back into maintenance, then reactivated again.  After a few moments of being active, the Total Space and Free Space in the UI were properly reflected.

If this is, in fact the process, it definitely isn't in the docs yet anywhere I was able to find.  Is the manual pvresize 100% necessary for this feature to function, or am I doing something wrong?

Comment 3 Allon Mureinik 2014-04-30 08:16:25 UTC
Indeed, pvresize is 100% required to use this feature (otherwise, VDSM has no way of knowing the lun was resized).
Moving this bug to docs to document this.

Comment 4 Andrew Burden 2015-02-02 09:03:50 UTC
Topic ID: 42622: Tentatively titled 'Resizing LUNs'.
Comprehensive draft complete.
Requires sanity and proofread, and technical verification.

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