HP StorageWorks SAN Virtualization Services Platform 3.0.4 Release Notes (5697-0763, November 2010)

When performing remote asynchronous mirror split and merge operations, after the split, and
before the merge operation, you need to perform a VSM failover in the destination domain. After-
wards, you can perform the merge operation. Otherwise, the operation fails.
Do not set the LUN range for a UDH when only one LUN is assigned to the UDH (for example,
when the same LUN is assigned to both the first and last LU).
After changing the time on a running VSM server, restart the Monitor application (or reboot the
VSM server) to ensure that time-dependent operations continue to work as expected.
When a host belongs to a host group, LUN assignment is performed at the group level. The same
LUN must be free for all hosts in the group.
Use the following procedure to roll back a PiT with a host running Windows 2008 R2.
1. Stop all I/O to the selected virtual disk.
2. Offline the virtual disk:
a. Using the Disk Management Diskpart utility, run DISKPART.
b. Select the disk by running SELECT DISK disk_num ( where disk_num is the number of
the disk).
c. Run OFFLINE DISK.
3. Roll back the PiT using the VSM GUI.
4. Online the disk:
a. Using the Disk Management Diskpart utility, run DISKPART.
b. Select the disk by running SELECT DISK disk_num ( where disk_num is the number of
the disk).
c. Run ONLINE DISK.
Issues and workarounds
This section describes known issues for the SVSP operating systems, Virtualization Service Manager
(VSM), Data Path Module (DPM), and VSM command line interface (CLI) applications. Workarounds
are provided when possible.
Upgrade issues
Upgrading with large back-end disks
You must not upgrade to SVSP 3.0.x with a setup that already includes 2 TB or larger back-end virtual
disks.
Upgrade order
When upgrading from SVSP 2.x, upgrade the VSM servers first, then the Data Path Modules. Upgrade
each device one-at-a-time.
Replacing a DPM in a DPM group when upgrading from SVSP 2.x to SVSP 3.0.x
When upgrading from SVSP 2.x to SVSP 3.0.x, an issue occurs when replacing a DPM in a DPM
group that was created in SVSP 2.x. This may also occur when trying to add a new DPM to the old
SAN Virtualization Services Platform 3.0.4 Release Notes 11