HP StorageWorks SAN Virtualization Services Platform 2.1.1 release notes (5697-0066, July 2009)

PA-RISC machines for HP-UX cannot boot from an external disk
PA-RISC machines running HP-UX were tested for the ability of HP-UX to be installed directly to a disk
presented by a storage array. The machines could not consistently reboot from an external disk,
therefore this is not supported at this time.
Setting the cluster bit for Serviceguard in Linux or HP-UX
When creating virtual disks that are to be used by Linux or HP-UX, the cluster bit check box must be
set in the Create Virtual Disk wizard—Enter Virtual Disk parameters screen. See Figure 21 in the HP
StorageWorks SAN Virtualization Services Platform Manager user guide on page 110 for an example
of the set check box. However, if the virtual disks are presented through the Data Path Modules, do
not set the cluster bit, as this will force the DPMs to abort pending writes after a period of time.
Capacity limits with thinly provisioned volumes
When you run out of free space in a storage pool, a write to a thinly provisioned virtual disk may
appear successful, but the data is missing. You should receive a message from any operating system
that thin volume expansions has exceeded the threshold limit. This can be prevented by properly
setting and actively monitoring your pool protection thresholds, adding capacity, or adding thin
provisioning licenses.
VSM issues
VSM server failure during upgrade
During an upgrade of the VSM server, occasionally the server will fail after the initial load on the first
reboot. The VSM server performs another reboot and restarts successfully. The problem is believed to
be caused by the upgraded VSM server restarting itself as the active device, and when connected to
the fabric, getting election messages from the other VSM server. HP is still working to resolve this
issue. In the meantime, the following is a workaround for this issue:
1. Wait for the upgraded VSM server to complete its validation steps after startup.
2. Stop the VSM service with the VSM Monitor.
3. Connect the VSM server to the fabric.
4. Wait several minutes to allow discovery to occur between the VSM servers.
5. Reactivate the VSM service with the VSM Monitor.
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 dissolve or delete the virtual disk after completing step 2, instead of trying to reuse the virtual
10