----- Original Message ----- > > On Wed, Sep 26, 2012 at 6:12 PM, Ayal Baron < aba...@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. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users