[Users] Increase storage domain

[Ayal Baron]

----- Original Message -----
> 
> On Sat, Aug 11, 2012 at 5:56 PM, Ayal Baron < abaron at redhat.com >
> wrote:
> 
> 
> 
> ----- Original Message -----
> > Hi,
> > 
> > pvresize doesn't work, still same size.
> > 
> > How do i disconnect the iscsi session?
> > 
> > Between disconnecting and ovirt connect again, will i loose
> > connection to my VMs?
> 
> Of course you would. Your VMs would automatically pause.
> I doubt this is what you want.
> What you can do prior to running pvresize is run:
> iscsiadm -m session -R
> Hope this helps.
> 
> 
> 
> 
> 
> Did anyone have any success with this? I was unable to get pvdisplay
> to show the new size until I rebooted the hosts and ran pvresize. I
> started with a 1TiB volume on our Equallogics SAN and set it to
> 5TiB. I put my non-SPM host into maintenance and ran pvresize on the
> SPM. I did not expect this to work because of previous experience
> and this thread. pvresize said it resized, but pvdisplay showed
> 1023GiB instead of 1TB, so it shrunk it a tiny bit?
> 
> 
> Next, I tried `iscsiadm -m session -R` and then pvresize which said
> it resized 0 PVs and pvdisplay confirms no change. I did a `iscsiadm
> -m node -T <iqn> -u` then `iscsiadm -m node -T <iqn> -l` followed by
> pvdisplay. pvdisplay spewed an IO error message for the PV and each
> LV and I noticed that the device had changed from /dev/mapper/<UUID>
> to /dev/sdf, which explains why it thought the PV and all the other
> LVs were missing. I should have deactivated the LVs/VG/PV first I
> supposed, and then reactivated them afterwords.
> 
> 
> Anyway, this gave me pause, but I'm still pre-production, so I went
> ahead and did a pvresize, which did nothing,and pvdisplay gave the
> same output, including errors, as before. So, I rebooted the host,
> activated the host, ran pvresize on the host, and all is as desired.
> 
> 
> I then rebooted my other host and all was well when it came up. I can
> deal with rebooting each host if necessary, but it is certainly not
> ideal. Has anyone worked out the correct steps make this happen
> without rebooting the hosts and minimal VM interruption? I might try
> it a couple more times if not.

Sounds really over-complicated for what you're trying to do.
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.
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.

> 
> 
> The bigger question is, how do I get the engine to see the new size?
> It is still seeing 1TB. Stopping and starting (why no restart on
> /etc/init.d/ovirt-engine?) did not cause a refresh. Oop! There it
> went, just as I was typing this, I saw it change in the window
> behind this one. So, was it just a cache time out, or did I need to
> restart the engine as well?
> 
> 
> An ideal setup would be for the engine to detect the change and run
> the necessary commands on each host. If auto detection is not
> reasonable, an option in the GUI to tell the engine the LUN has
> changed would be nearly as good.
> 
> 
> 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

> 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.

> 
> 
> Eventually, I think I'll look into filing a feature request, so I
> would appreciate if some one could point me in the right direction,
> but let's hash out what makes sense here before doing that.