Reason for un-mountability: the original volume has some extents online

[karlfoleyasp]

I've raised a support request, but thought I'd post this here to see if anyone else has seen the same issue on ESXi 5.1,914609.

We are implementing an HP Cloud Matrix system with ESXi 5.1 as one of the supported Hypervisors. Part of the delivered solution is HP Matrix Recovery Management which allows us to failover services to a DR site that has the VMFS volume synched across two 3Par V400 SANS.

As we understand it, the HP official guide to passing changes from the primary to DR site is to export the configuration, failover the storage, and then import the conifguration at the remote site. There is another way of doing this through the use of storage snapshots (we have tested this fine with Hyper-V):

1. Create a RW Virtual Volume copy of the RO LUN at the remote site
2. Unexport the RO LUN from the remote VMWare hosts
3. Export the RW LUN to the remote VMware hosts
4. Mount this RW LUN
5. Import the configuration
6. Unexport the remote RW LUN
7. Export the remote RO LUN
8. Delete the RW LUN

This process works fine on Hyper-V using CSV disks, but has the following problem on ESXi 5.1; When the LUN is changed, it is detected as a snapshot (as expected), but the snapshot is not mountable because the VMHost thinks it is already online:

~ # esxcli storage vmfs snapshot list

51128c21-f07c4a24-4e24-00215a9b20f7

   Volume Name: Vv_prim_vmfs_cloud_repl.02

   VMFS UUID: 51128c21-f07c4a24-4e24-00215a9b20f7

   Can mount: false

   Reason for un-mountability: the original volume has some extents online

   Can resignature: true

   Reason for non-resignaturability:

   Unresolved Extent Count: 1

~ # esxcli storage vmfs snapshot mount -l "Vv_prim_vmfs_cloud_repl.02"

Unable to mount this VMFS volume due to the original volume has some extents online

The only solution we have found is to reboot ALL the VM hosts in the remote cluster. They ALL then report the following, and can mount the volume:

~ # esxcli storage vmfs snapshot list

51128c21-f07c4a24-4e24-00215a9b20f7

   Volume Name: Vv_prim_vmfs_cloud_repl.02

   VMFS UUID: 51128c21-f07c4a24-4e24-00215a9b20f7

   Can mount: true

   Reason for un-mountability:

   Can resignature: true

   Reason for non-resignaturability:

   Unresolved Extent Count: 1

~ # esxcli storage vmfs snapshot mount -l "Vv_prim_vmfs_cloud_repl.02"

~#

We have tried various vmkfstools commands to release the LUN etc, but they don't seem able to see the LUN even though we can see the device for the volume.

Is this something you have seen before?

Is there anything you can suggest?

[karlfoleyasp]

Well, VMware came back and said this is known behaviour, and the only way to get the volume mounted is to reboot the host ESX server. This isn't acceptable, so we've come up with another way to migrate our images to DR without presenting a snapshot.
Strange thing is Hyper-V manages this just fine. :smileysad:

[SimonTodd]

I have seen this before if the original production datastore was presented and has been removed, this will result in a PDL on the ESXi host, and in Pre 5.5 the LUN/Datastore will still remain in the list on the ESXi host which will prevent the new DR datastore being mounted.

In ESXi 5.5 there was a new option intorduced which would automatically remove PDL devices.

My question is were the original LUNs/Datastores presented to this host prior to the DR LUNs being promoted?

Simon