Although this is an old thread, we hit this issue recently, after migrating volumes from EMC VMAX to 3PAR using Online Import Utility (OIU), and bitwizz's last post hit the nail on the head, albeit it with slight change needed in the setvv command syntax.
For each primary VV in question run:
3PAR01 cli% setvv –wwn auto <VVName>
This will change the VV’s WWN to one based on the source 3PAR S/N.
This scenario is documented in the HPE 3PAR Online Import for HDS Storage white paper (pages 24 and 30); unfortunately, the earlier HPE 3PAR Online Import for EMC Storage white paper did not mention this scenario.
Essentially the HPE 3PAR VSS Provider is doing as it is designed – only allowing you to take snapshots of 3PAR VVs.
Volumes created natively on a 3PAR have the serial number of the array in hexadecimal form in the last five characters of the WWN:
3PAR01 cli% showvv -showcols Id,Name,VV_WWN
Id Name VV_WWN
1222 snap_test 60002AC000000000000004C6000
1BE8E 3PAR01 cli% showsys
ID ---Name---- ---Model----
0x
1BE8E 3PAR01 HP_3PAR 8###
Clearly this isn’t the case with volumes migrated using OIU from an EMC array:
3PAR01 cli% showvv -showcols Id,Name,VV_WWN
Id Name VV_WWN
586 Volume_0157D 600009700002987002625330313
53744With the EMC VV_WWN digits:
- Digit 0-6 represent the <vendor id>. ('6006048' is the EMC Symmetrix vendor-id, '6000097' is EMC Symmetrix V-MAX vendor-id.)
- Digit 7-19 represent the <Symmetrix serial number>
- Digit 20-31 are the <ASCII representation of the Symmetrix device>. The ASCII sequence contains one, two or three ASCII characters followed by the device serial number in ASCII (either 3, 4 , 5 digit device numbers). This is Enginuity dependent.
(see How to decode a Symmetrix device WWN:
https://emcservice.force.com/CustomersP ... 0008TZKCA2).
If the host genuinely had storage presented to it from multiple arrays for example, it wouldn’t make much sense for the 3PAR VSS Provider to try and take snapshots of anything else.
OIU has also done as it’s designed – volumes migrated from non-3PAR arrays retain the data they had on the source – and that includes the name, size, WWN and export host data (when migrated as a host).
So it's not a bug, but it clearly is an omission in the OIU documents, as there are some additional steps needed post-migration for hosts which have LUNs which need to use the HPE 3PAR VSS Provider (or any HPE 3PAR Recovery Manager products) for managing snapshots.
Notes on Changing VV WWNs Changing VV WWNs is disruptive to I/O and requires the volume to be unexported from the host before changing the VV’s WWN.
In addition, this option is not allowed for an admitted volume before it is imported (during Online Import) or whilst the import process is taking place. It can only be run
post-migration.
When changing VV WWNs keep the following in mind:
- Operating Systems that use the VV WWN as identification may need additional steps to correctly recognise the LUN, once its WWN has changed. For example, VMware uses the NAA..<diskwwid> for multipathing. If the WWID is changed VMware may see the updated VV WWN as a separate volume or snapshot. In this instance the inventory may have to be reimported for the correct operation of cluster DRS.
- On clusters which make use of Remote Copy (e.g. with CLX or Peer Persistence) the VV WWN needs to be changed on the Primary/Source VV, and the VV WWN of the target VV on the Secondary/Target Array must be updated to match.
- Volumes that are part of a Remote Copy Group cannot have their WWNs updated whilst part of a group. The group must be stopped, volumes removed from the group, have their WWNs updated and then added back into the group, before restarting the group.
- For Peer Persistence to function, the (Remote Copy) source and target volumes must have the same WWN. Target volumes created automatically during the Remote Copy Group setup process share the same WWN by default. Volumes created manually during Remote Copy Group setup do not and will need to be updated to match (see steps 2 & 3 above).
- Any volume migrated using OIU may need to have their VV WWN updated post-migration to follow 3PAR conventions, in order to use HPE 3PAR Recovery Manager products, including the HPE 3PAR VSS provider.