HPE 3PAR StoreServ Storage

Online Import P6000 to 3Par issues with Vmware

Heiner Hardt
Occasional Contributor

Online Import P6000 to 3Par issues with Vmware

Does anyone here finished an Online Import from P6000 to 3Par succesfully using Vmware hosts/disks? When I mean sucessfully, it´s about Vmware recognize the disks as 3PAR model and with no downtime.

I´m in the middle of a huge fuzzy mistery. The Online Imports finished his process in a very smoothly way with sucess. No problem at this stage. The problem starts after the migration inside Vmware.

When I went in the disk informations inside Vsphere (using esxcli commands), I figured out that the disks were all showing the Vendor and Model informations as HP and HSV360 (P6000 controllers) and not 3PAR and VV as it should be. This informations comes from SCSI Inquiry commands made from the host to the target after LUN re-enumeration. We are using Vsphere 5.0 Update 3. When host is rebooted the disks appears right showing 3Par model.

Well, until no host has been rebooted everything it´s working fine. Volumes mounted and Vm´s up and running. When we rebooted the first host, neither one of the volumes can be mounted anymore. Looking further in the logs the migrated volumes are been detected as snapshots because of metadata inconsistency.

I know that the disks/filesystem can be forcibly mounted or reassigned in Vmware. But this is not the point. The point is that all the Online Import should work transparently, without all this mess. Otherwise the process is not "Online" being as much disruptive as the Windows process.

Before anyone comment , all OS, drivers and firmwares were adjusted to be compliance with SPOCK matrix.

So, with everything explained, someone has gone through something similar? Any thoughts?

Honored Contributor

Re: Online Import P6000 to 3Par issues with Vmware


Usually I migrate from EVA to 3PAR using VMware storage migration this is the best way.

online migration was not supported for VMware at first. it is now but read the compatability in SPOCK.

also another problem of online migration is that LUNs WWN remains as it was on EVA so you get EVA WWN from the 3PAR

to change this you have to unexport the LUN and run "Setvv –wwn auto <vvname>" from CLI.

this is of course an offline function.we have this problem working with 3PAR recovery manager for LUNS migrated from EVA.



Heiner Hardt
Occasional Contributor

Re: Online Import P6000 to 3Par issues with Vmware

What caught my attention is that during the entire migration process and after its completion, the VMware didn´t recognize the disks with his correct model. During all the process some "rescans" were triggered and the paths were changed correctly (PDL conditions showing old paths to the P6500 getting disconnected can be seen all over the process). But the volume only changed to the correct model after a host reboot. The disk changed to the right model but the datastore were not able to be mounted because disks were detected as snapshots.


I have two suspects. First, some issues with SCSI Inquiry not taking place correctly. Second, about something with the VML (Vmware Legacy) paths not been created pointing to right array.  The VML path is used for some operations such RDM´s. According to VMware, the VML path contains information such as LUN ID and WWID. An example follows bellow:






• CTL info – 02003c0000 (3c  =LUN ID HEX)

• NAA id – 600143801259bbb400007000160a0000 (Contains WWID)

• Vendor - 565620202020 ( don´t know the logic but this stands for 3Par)


Note that the only changed portion is the "Vendor" field. The volume kept its LUN ID and NAA characteristics after the migration process (P6000 to 3Par). This leads me to believe that features like LUN ID and WWID were kept healthy and unchanged (metadata attributes.). The only thing that really changed was the storage type (P6000 Vendor numbers shows 485356333630).


For me the 3Par Online Import cannot be done in an "non disruptive way". Vmware (at least for version 5.0 and earlier) for some reason, includes 3Par model or type hashed in the metadata and cannot handle with this process very well.


In this particular case, Storage Vmotion was not an option. The customers uses a lot of RDM´s.