HP SAN Virtualization Services Platform 3.0.5 Release Notes (5697-1031, June 2011)

MSA capacity can be reported in base 2 or base 10
The VSM reports capacity in base 2 (for example, 1 TB = 1024 GB). The MSA can report capacity
in base 10 (1 TB = 1000 GB) or can be configured to report in base 2. The MSA setting can be
changed from the management GUI or from the CLI:
From the management GUI:
1. Log in to the MSA using the management IP address in the browser window.
2. Click on the storage controller in the config view on the left side of the screen.
3. Select the Configuration pull-down menu on the right side of the screen.
4. Select Users > Modify User.
5. Select the user account to which you are logged in (usually the manage account).
6. Change the base preference to base 2 or base 10, as desired.
7. Click the Modify User button, and click OK on the Success pop-up screen.
From the CLI:
1. Log in using telnet or ssh.
2. Enter the set cli-parameters base <n> command, where <n> is 2 or 10.
Error with Continuous Access license capacity when replicated differently
The SVSP 3.0.x 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.
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.
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 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.
Issues and workarounds 15