Troubleshooting

The topics in this section provide troubleshooting information that is related to Volume Shadow Copy Service and Virtual Disk Service support for Hyper-V.

Provider cannot find FC or iSCSI initiator

  1. Verify the FC and iSCSI configurations on the host, SAN, and storage. 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 IP address, user name, password, and domain are set correctly, that the user is authorized to access WMI on the host, and that 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.

Volume not supported by Volume Shadow Copy Service and Virtual Disk Service

Verify that the volume on the disk is supported by the Volume Shadow Copy Service and Virtual Disk Service. 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 Volume Shadow Copy Service and Virtual Disk Service, although they may 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

  1. Verify the virtual port configuration on the host, SAN, and storage.
  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 virtual machine

The VMware virtual machine is not recognized as a virtual machine because the systeminfo in the VM is incorrect.

The correct systeminfo is:
  • System Manufacturer: VMware, Inc
  • System Model: VMware Virtual Platform

If the option SMBIOS.reflectHost = "TRUE" in the virtual machine’s configuration file (vmx) is added, the systeminfo is changed.

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

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

If you configured Volume Shadow Copy Service and Virtual Disk Service 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.

In IBM® VSS Hardware Provider, to enable incremental FlashCopy mapping, use the following command code: 
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 code:
ibmvcfg.exe set incrementalFC No

Assume an Incremental FlashCopy mapping called "fcmap1" was created, where F1 is the source volume mapped to 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 pool, but the FlashCopy mapping still exists in storage. When a new incremental FlashCopy using F1 as the source volume is created later, F2 and fcmap1 are reused.

Deleting and restoring cascaded FlashCopy mappings

SAN Volume Controller and the IBM Storwize® Family can minimize the overhead required to maintain multiple snapshots of the same source volume by putting the target volumes into a cascade where each target is dependent on changes 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, type ibmvcfg.exe set backgroundCopy 0.

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

When enabling 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 later restore mapping S > T1, S > T2, then S > T3 and S > T4 are deleted, and only S > T1 and S > T2 exist.

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