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

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.
Changing back-end virtual disks to be write protected is not supported
Changing back-end virtual disks to be write protected could lead to I/O errors and data unavailability,
and is therefore not supported.
Enabling Ethernet port without a cable results in diagnostic message on console
Enabling an Ethernet port on a DPM that is not physically connected causes a diagnostic message to
be printed to the serial console. This message can be ignored. This issue will be fixed in a future
release.
A DPM upgrade reverts to SNMP host name setup
Upgrading a DPM triggers the loss of the host name information configured for SNMP. After a DPM
upgrade, SNMP traps are generated with the default IP address (127.0.1.1), instead of the actual
address for the DPM. Performing a modify chassis name xxx command (reassigning the same
chassis name) after the upgrade fixes the configuration. This issue will be fixed in a future release.
SAN Virtualization Services Platform 3.0.4 Release Notes 21