Troubleshooting

The topics in this section provide troubleshooting information that is related to IBM® Storage Support for Microsoft VSS and VDS support for Hyper-V.

Provider cannot find FC or iSCSI initiator

If Provider cannot find FC of iSCSI initiator, complete the following steps:

  1. Verify the FC and iSCSI configurations on the host, SAN, and storage system. Make sure that at least one initiator is installed on the host or the guest OS.
  2. Verify the settings for Hyper-V. Ensure that the following situations are true:
    • The IP address, user name, password, and domain are set correctly
    • The user is authorized to access WMI on the host
    • The domain is set as the host's computer name if it is not the domain user
  3. Ensure that the storage protocol setting and the existing initiator configuration are not in conflict.

Unsupported volumes

Verify that the volume on the disk is supported by the IBM Storage Support for Microsoft VSS and VDS. The disk must be from SAN Volume Controller or DS8000® and must be added to the guest OS as a pass-through disk. Virtual hard disks are not supported by the IBM Storage Support for Microsoft VSS and VDS, although they might be supported on the LUN from SAN Volume Controller or DS8000.

Importing a shadow copy failed or locating a LUN failed while taking the shadow copy

Either the guest OS has no iSCSI controller or the address on the iSCSI controller or the guest OS is insufficient. Shut down the guest OS and add the iSCSI controller to the guest OS.

Target LUNs are not attached to the host through the virtual port

If target LUNs are not attached to the host through the virtual port, complete the following steps:

  1. Verify the virtual port configuration on the host, SAN, and storage system.
  2. Verify that the guest OS configuration files are on the LUN through the virtual port. The volume on the LUN must be assigned a drive letter. A mount point is not supported.
  3. Ensure that the storage protocol is not set to iSCSI.

VMware virtual machine not recognized as a virtual machine

The VMware VM is not recognized as a VM because the result of the systeminfo command in the VM is incorrect.

The result of the systeminfo command appears like the following example:
  • System Manufacturer: VMware, Inc
  • System Model: VMware Virtual Platform

If the option SMBIOS.reflectHost = "TRUE" in the VM's configuration file (vmx) is added, the result of the systeminfo command changes.

For example:
  • System Manufacturer: IBM
  • System Model: Custom_
To correct this problem, complete the following steps:
  1. Shut down the VM.
  2. From the VMware ESXi/vCenter datastore, delete the SMBIOS option from the configuration file whose suffix is .vmx.
  3. Turn on the VM.

Ensuring that no shadow copy exists before you change settings that are related to FC/ISCSI initiators

If you configured IBM Storage Support for Microsoft VSS and VDS to attach the target LUN to the guest OS through the host FC/ISCSI when creating or importing a shadow copy, delete or mask the shadow copy with the same configuration.

Ensure that no shadow copy exists before you change settings that are related to FC/ISCSI initiators.

The ibmvss settings are as follows:
  • storageProtocol
  • VMHost
  • Vmusername
  • vmpassword
  • vmdomain
The hardware or OS settings are as follows:
  • enable/disable host FC/ISCSI HBA
  • enable/disable host software ISCSI
  • enable/disable guest OS software ISCSI

Incremental FlashCopy mapping persists

Incremental FlashCopy® makes a copy of only the changes to either the source or target data since the last FlashCopy operation. It is designed to enable completion of point-in-time online backups much more quickly than using traditional FlashCopy.

To enable incremental FlashCopy mapping, in the IBM VSS hardware provider, issue the following command:
ibmvcfg.exe set incrementalFC Yes
After setting to incremental, all FlashCopy created is incremental until you return to regular FlashCopy by issuing the following command:
ibmvcfg.exe set incrementalFC No

Assume that an Incremental FlashCopy mapping called fcmap1 was created, where F1 is the source volume that is mapped to the host and F2 is the target volume. Then, F1 can be used as a source volume in only one FlashCopy mapping. If the FlashCopy mapping is deleted from IBM VSS hardware provider, the target volume F2 returns to the free storage pool, but the FlashCopy mapping still exists in storage. When a new incremental FlashCopy using F1 as the source volume is later created, F2 and fcmap1 are reused.

Deleting and restoring cascaded FlashCopy mappings

SAN Volume Controller and the IBM Storwize® Family can minimize the overhead that is required to maintain multiple snapshots of the same source volume. To minimize the overhead, put the target volumes into a cascade where each target depends on changes that are recorded in target volumes of subsequent snapshots.

For example, assume that four VSS snapshots are created of a source volume, where S is the source volume and T1 through T4 are the targets, T1 being first chronologically and T4 the last. The following cascade occurs: S > T4 > T3 > T2 > T1

With this type of cascade relationship, a copy-on-write process is needed only between the source volume and the latest FlashCopy target. Any block that remains unchanged on the source volume are not copied at all.

In IBM VSS Hardware Provider, to enable cascading FlashCopy mapping, issue the ibmvcfg.exe set backgroundCopy 0 command.

To disable cascading FlashCopy mapping, issue the ibmvcfg.exe set backgroundCopy <n> command, where <n> is a number in the range 1–100.

When you enable cascading, sequentially create the FlashCopy mappings: S > T1, S > T2, S > T3, and S > T4.

If you delete mapping S > T2, then S > T1 is also deleted, and only S > T3 and S > T4 exist.

If you restore mapping S > T2, then S > T2, S > T3, and S > T4 are deleted, and only S > T1 exists.

To use space efficient volume, set the backgroundCopy to zero. Mixed volume types (fully allocated and space-efficient) of VDisks in VSS_FREE storage pool and mixed copy rates in cascading/multi-target volumes are not recommended.

Volume Shadow Copy Service supports Windows Failover Cluster

When you attach the source volume to the VM, first add an available storage to the VM from the cluster and add pass-through disks to the VM.
Prerequisites:

The following prerequisites must be satisfied.

  • The cluster node IP addresses must be in one subnet
  • Add the cluster node IP addresses and the host names to the VM hosts file
  • The DNS server must already be configured

Storage protocol special cases and exceptions

The IBM Storage Support for Microsoft VSS and VDS offer the option to choose the storage protocol.

You are responsible for ensuring that changing the storage protocol and IBM Storage Support for Microsoft VSS and VDS settings for VMware does not affect the previously created snapshots.

The following example illustrates a special case that can cause some problems. The procedure in this example is as follows:
  1. Create a snapshot with the FC protocol.
  2. Change the protocol setting to virtual machine iSCSI.
  3. Incorrectly modify or clear the VMware settings.
  4. Delete the previously created snapshot.

In this case, the FlashCopy map is removed from storage and the target LUN is unmapped from the hosts. However, the pRDM file remains on the VMware ESX(i) Server because the VMware settings (vmhost, vmuser, vmpassword, or vmcredential) were incorrectly set. The Volume Shadow Copy Service and Virtual Disk Service is therefore unable to communicate with the VMware ESX(i) Server.

If the settings are correct, the deletion process can still be successful with the pRDM file removal.

If this example case occurs, a warning message is issued if the VMware settings are changed using ibmvcfg.

It is not necessary to configure the IBM Storage Support for Microsoft VSS and VDS parameters (such as vmhost and vmuser) for VMware. If you decide to use the VM software iSCSI protocol, all processes are run using Ethernet protocol.