----- Original Message -----
On Wed, Sep 26, 2012 at 6:12 PM, Ayal Baron < abaron(a)redhat.com >
wrote:
Sounds really over-complicated for what you're trying to do.
Agreed! That's why I asked. =) To be clear, all that was necessary to
end up where I wanted was to reboot the hosts, which is not terribly
complicated, but time consuming and should not be necessary. I tired
all those other steps based on recommendations in this thread to
avoid the reboot.
After increasing the size of the LUN in the storage side try running
the following command on the SPM:
vdsClient -s 0 getDeviceList
(-s is only if ssl is enabled, otherwise just remove it)
After that run pvresize (for LVM to update its metadata).
That should be it on the SPM side.
This did not make any difference. I increased the LUN to 14.1 on the
Equallogics box and then ran these commands (you may want to skip
past this to the text below since I am leaning heavily toward the
add a LUN method):
[root@cloudhost04 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/364ed2a35d83f5d68b705e54229020027
VG Name 64c4a870-98dc-40fc-b21e-092156febcdc
PV Size 14.00 TiB / not usable 129.00 MiB
Allocatable yes
PE Size 128.00 MiB
Total PE 114686
Free PE 111983
Allocated PE 2703
PV UUID h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO
[root@cloudhost04 ~]# vdsClient -s 0 getDeviceList
[{'GUID': '364ed2a35d83f5d68b705e54229020027',
'capacity': '15393163837440',
'devtype': 'iSCSI',
'fwrev': '5.2',
'logicalblocksize': '512',
'partitioned': False,
'pathlist': [{'connection': '10.10.5.18',
'initiatorname': 'default',
'iqn':
'iqn.2001-05.com.equallogic:4-52aed6-685d3fd83-2700022942e505b7-cloud2',
'port': '3260',
'portal': '1'}],
'pathstatus': [{'lun': '0',
'physdev': 'sdd',
'state': 'active',
'type': 'iSCSI'}],
'physicalblocksize': '512',
'productID': '100E-00',
'pvUUID': 'h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO',
'serial': '',
'vendorID': 'EQLOGIC',
'vgUUID': 'XtdGHH-5WwC-oWRa-bv0V-me7t-T6ti-M9WKd2'}]
[root@cloudhost04 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/364ed2a35d83f5d68b705e54229020027
VG Name 64c4a870-98dc-40fc-b21e-092156febcdc
PV Size 14.00 TiB / not usable 129.00 MiB
Allocatable yes
PE Size 128.00 MiB
Total PE 114686
Free PE 111983
Allocated PE 2703
PV UUID h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO
[root@cloudhost04 ~]# pvresize
/dev/mapper/364ed2a35d83f5d68b705e54229020027
Physical volume "/dev/mapper/364ed2a35d83f5d68b705e54229020027"
changed
1 physical volume(s) resized / 0 physical volume(s) not resized
[root@cloudhost04 ~]# pvdisplay
--- Physical volume ---
PV Name /dev/mapper/364ed2a35d83f5d68b705e54229020027
VG Name 64c4a870-98dc-40fc-b21e-092156febcdc
PV Size 14.00 TiB / not usable 129.00 MiB
Allocatable yes
PE Size 128.00 MiB
Total PE 114686
Free PE 111983
Allocated PE 2703
PV UUID h8tZon-o5sB-FR4M-m8oT-UPub-eM1w-7eexhO
So, not change.
This looks like an LVM issue. Have you tried deactivating the VG before pvresize?
Then if indeed it succeeds, wait a little while for engine to catch
up (it periodically runs getStoragePoolInfo and updates its info
about free space, you can find this in vdsm.log)
regardless, see below for the preferred method.
Thanks for the confirmation. Any idea what the interval is?
> Alternately, would it just be better to create a new LUN on the
> iSCSI
> target and add it to the storage domain? Is that even doable?
This flow is fully supported and is currently the easiest way of
doing this (supported from the GUI and from the CLI). Simply extend
a domain with a new LUN
Great! I'll give that a shot.
> Certainly it is as simple as adding a new PV to the VG in LVM, but
> does the engine/GUI support it? It seems a bit more messy than
> growing an existing domain from an iSCSI target point of view, but
> are there any technical down sides?
The target has nothing to do with it, you can have multiple LUNs
behind the same target.
The target serves the LUNs and it was the additional LUNs that I was
referring to as being messier when a single LUN could do the job.
Not a big problem, just name the LUNs the same the same patters
(cloud<#> in my case), but when all other things are equal, less
LUNs is less to think about.
However, as I read this email, it occurred that some other things
might not be equal. Specifically, using multiple LUNs could provide
a means of shrinking the storage domain in the future. LVM provides
a simple means to remove a PV from a VG, but does the engine support
this in the CLI or GUI? That is, if the a storage domain has
multiple LUNs in it, can those be removed at a later date?
Not yet.