v Immediately after the T3 recovery process runs, compressed disks do not know
the correct value of their used capacity. The disks initially set the capacity as the
entire real capacity. When I/O resumes, the capacity is shrunk down to the
correct value.
Similar behavior occurs when you use the -autoexpand option on vdisks. The
real capacity of a disk might increase slightly, caused by the same kind of
behavior that affects compressed vdisks. Again, the capacity shrinks down as
I/O to the disk is resumed.
Before using the block volumes that are accessed by the SAN or with iSCSI,
complete the following tasks:
v Start the block host systems.
v Manual actions might be necessary on the hosts to trigger them to rescan for
devices. You can complete this task by disconnecting and reconnecting the Fibre
Channel cables to each host bus adapter (HBA) port.
v Verify that all mapped volumes can be accessed by the hosts.
v Run file system consistency checks on the block hosts.
v Run the application consistency checks.
Before using the file volumes that are used by GPFS on the file modules to provide
Network Attached Storage (NAS), complete the following task:
v Contact IBM support for assistance with recovering the GPFS quorum state so
that access to files as NAS can be restored.
For Virtual Volumes (VVols), complete the following tasks.
v After you confirm that the T3 completed successfully, restart Spectrum Control
Base (SCB) services. Use the Spectrum Control Base command service
ibm_spectrum_control start.
v Refresh the storage system information on the SCB GUI to ensure that the
systems are in sync after the recovery.
– To complete this task, login to the SCB GUI.
– Hover over the affected storage system, select the menu launcher, and then
select Refresh. This step repopulates the system.
– Repeat this step for all Spectrum Control Base instances.
v Rescan the storage providers from within the vSphere Web Client.
– Select vCSA > Manage > Storage Providers > select Active VP > Re-scan
icon.
For Virtual Volumes (VVols), also be aware of the following information.
FlashCopy mappings are not restored for VVols. The implications are as follows.
v The mappings that describe the VM's snapshot relationships are lost. However,
the Virtual Volumes that are associated with these snapshots still exist, and the
snapshots might still appear on the vSphere Web Client. This outcome might
have implications on your VMware back-up solution.
– Do not attempt to revert to snapshots.
– Use the vSphere Web Client to delete any snapshots for VMs on a VVol data
store to free up disk space that is being used unnecessarily.
v The targets of any outstanding 'clone' FlashCopy relationships might not
function as expected (even if the vSphere Web Client recently reported clone
388 Storwize V7000 Unified: Problem Determination Guide 2073-720
To Next Page
Loading...
Need help?
General
