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

Table Of Contents
NOTE: All the above communications are confined to the SVSP domains. External communications
(for example, the GUI and other SOAP clients connected to the web server) are done according
to the site configuration (either through IPv4 or IPv6 addresses).
If an IPv6 address is added or deleted while VSM is running, the SVSP Monitor cannot detect this
change without restarting the VSM application.
Downloading the VSM GUI client for IPv6 (for example, when IPv6 is configured as the desired
communication protocol between the web server and the client) must be done using the Microsoft
Internet Explorer 7 or Mozilla Firefox (version 3.0.3 and higher) browser. There is a known
limitation with Microsoft Internet Explorer 6, and it cannot be used.
To log in to the VSM GUI using IPv6 format, you need to enclose the address within right and left
brackets. For example: [fd00::21d:9ff:fe6b:1da9].
PiT deletions after reaching threshold Guard level
There are three configurable capacity threshold limits: Warning, Guard, and Emergency. When the
Guard level is reached, more than one of the older PiTs may be deleted. See the HP StorageWorks
SAN Virtualization Services Platform Manager User Guide for details.
Read-only permissions are not supported in the VSM GUI
Do not assign read-only permissions to a virtual disk using the VSM GUI, even if this is allowed in the
GUI. Some operating systems (for example, Windows) require write permission for their own file system
activities. Assigning read-only permissions will generate I/O retries and increase the load on the DPM.
Potential for I/O loss with synchronous mirrors due to active DPM failure
I/O loss could occur with synchronous mirroring using “Sync Always groups (not with “Continue on
Fail” groups) when an active DPM is completely disconnected from the domain. Ensure that members
of the synchronous mirror group are failed over to the other DPM before disconnecting an active DPM
from the SAN.
DPM issues
DPM ports stay present during a DPM reboot
The DPM shutdown command works at the software level, but does not actually shut down the hardware.
The DPM ports stay logged in to the Fibre Channel but do not respond to inquiries. The consequences
of using this command are:
Front-end hosts may hang due to unresponsive ports in the SAN.
The VSM will show the DPM ports as working, but may show them in a failed state.
The VSMs may also be briefly affected by the DPM for awhile, and become unresponsive.
After executing the DPM software command, the DPM will have to be disconnected from the power
supply and then reconnected.
Failback operation does not work after DPM replacement
The VSM failback operation does not fail back all the I/O to the preferred DPM after a DPM
replacement. The workaround is to reboot the replacement DPM, and then perform the failback
operation.
Physically disconnecting a DPM port results in a high rate of invalid transmitted word port errors
When a DPM port is physically disconnected from a Fibre Channel switch, the switch port may register
a large number of invalid transmitted word port errors. These port errors can be safely ignored.
18 Issues and workarounds