1:12 a.m.
----- Original Message -----
On Sat, Aug 11, 2012 at 5:56 PM, Ayal Baron < abaron(a)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.