HP StorageWorks SAN Virtualization Services Platform 3.0 release notes (5697-0404, April 2010)

Error with Continuous Access license capacity when replicated differently
The SVSP 3.0 Continuous Access license correctly charges the size of the source on both sites as long
as it is the same type of replication (for example, remote copy (snapclone) or async mirror). However,
if the same source virtual disk is replicated using both the async mirror and remote copy (remote
snapclone) operations, the destination Continuous Access license will be reduced twice— once for
the first async mirror copy, and once for the first snapclone clone.
HP XP array volumes show as failed after creation of storage pool
After creating a storage pool and adding XP volumes that are visible in the VSM GUI, they may show
as failed, even though the HBA can see the volumes and the path has not failed. A workaround is to
add only the volumes that are visible to any one path, and then later VSM only recognizes the other
path. For example, if 30 volumes from the XP array are exposed from 2 ports, then VSM shows them
as 60 XP volumes (30 from one port and 30 from other port). You need to add only 30 volumes from
one port to create storage pool.
Long boot time with large configurations
In a configuration with large numbers of devices, configured with large number of paths, the host
system takes more time to boot up. This is normal Windows behavior, which takes awhile to detect
devices and load drivers.
Open port 5988 for SMI-S in Windows Firewall
The appendix titled “Using VSM with firewalls” in the HP StorageWorks SAN Virtualization Services
Platform administrator guide states that port 5989 should be opened in the Windows Firewall for
HTTPS access to the SMI-S provider. In addition, port 5988 should be opened for HTTP access to the
SMI-S provider.
Cannot write to file error when using an MSA22xx array
The following scenario has been found to cause the virtual disk or LUN of an MSA to become
non-operational.
1. The virtual disk or LUN from an MSA is added to a VSM storage pool.
2. The virtual disk or LUN is removed from the storage pool.
3. The virtual disk or LUN is again added to a pool, or a pool is created from the LUN, and the
pool creation or expansion fails with a Cannot write to file error.
A workaround is to reboot the VSM servers, one after the other. A best practice for avoiding this issue
is to dissolve or delete the virtual disk after completing step 2, instead of trying to reuse the virtual
disk as a back-end logical unit in step 3. The reason is that the disk may contain some SVSP signatures
left over from step 1, which may be recognized in step 3.
ForceActive with VSM server in unknown state
If the ForceActive utility is running and the VSM server enters an unknown state, stop the VSM GUI,
stop the ForceActive utility, restart the VSM, and then run the utility again.
SAN Virtualization Services Platform 3.0 release notes 15