HP StorageWorks SAN Virtualization Services Platform 2.02 release notes (5697-8024, February 2009)

states. See Chapter 8 of the HP StorageWorks SAN Virtualization Services Platform installation
and configuration guide for information on the setup virtual disk.
The Windows system disk of the VSM server and the VSM setup virtual disk must not be converted
into a dynamic disk.
Restoring a VSM setup from a backup can be safely performed only if there are no PiTs in the
system. If PiTs exist (either created directly or by Business Copy or Continuous Access applications),
their metadata in the setup backup may be invalid and may result in data loss/corruption if restored.
Do not change any back-end logical unit characteristic (for example, number, name, size (by ex-
panding or contracting), and so on) once it has been virtualized (for example, entered into a VSM
storage pool) or is being managed by the VSM. The LUN identification has been written on the
LU by VSM. See “Operational best practices” on page 8.
You should not upgrade (or accept automatic updates for) operating-system software components
such as iSCSI initiators and QLogic HBA drivers. Only explicit VSM components are approved
for use. Operating system security updates are supported.
You must not change the computer name of the VSM server if it is the only VSM server that manages
the system, or if it is the only server that is currently connected to the SAN. Changing the computer
name of a VSM server is allowed if two VSM servers manage the system and are both connected
to the SAN according to the procedure in the HP StorageWorks SAN Virtualization Services
Platform installation and configuration guide.
Before starting a migration task, make sure the task does not have any PiTs (such as user PiTs or
mirror PiTs). If PiTs exist, they must be deleted before the task starts, otherwise a future snapshot
created on these PiTs (or a rollback to them) after migration will not be consistent.
Do not initiate an iSCSI connection for a VSM server to itself. Loopback is not supported.
Only one NIC should be used as the iSCSI initiator/target on a VSM server. The other NIC is used
for management. Therefore, the iSCSI NIC could be in a private Ethernet domain, used exclusively
for an SVSP domain-to-domain replication (remote mirroring).
Before installing or uninstalling VSM, you must make sure that all iSCSI connections are disconnec-
ted. You must log out of all existing iSCSI connections. See the HP StorageWorks SAN Virtualization
Services administrator guide for the upgrade procedure.
After a disruption (perturbation) of VSM connections, wait at least 15 minutes to let the VSM redis-
cover all paths.
The VSM server is intended to be used only for VSM-related tasks. No other applications should
be installed on the server except as configured during installation (for example, Symantec AntiVirus,
Symantec Ghost, PuTTYtel, and so on).
Do not overload the array that contains the setup virtual disks. An overloaded array is one where
the average write response time for the VSM setup virtual disk exceeds 20 msec.
When booting from the SAN, make sure the host only sees that LUN through one path when there
is no multipathing software on the host.
The default threshold for capacity alerts is 10%. When setting capacity alerts, you should set the
alerts slightly higher (for example, add 5%) to ensure that the storage administrator is notified in
time.
When rebooting one DPM, wait at least 30 minutes before rebooting the other DPM.
Before disconnecting a VSM server from the domain, ensure that the other VSM server is running.
There is an increased risk of a Windows fault when disconnecting (even partially) a VSM server
from the domain (for example, to perform maintenance). The lack of an operational second VSM
server can lead to I/O failure.
Keep in mind that once a synchronous mirror is created, you cannot:
Remove host permissions from a synchronous mirror group.
Change the LU number of a synchronous mirror group.
HP StorageWorks SAN Virtualization Services Platform 2.02 release notes 7