Friday, 15 February 2013

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


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?

6 comments:

  1. Posted this to the VMware forums:
    http://communities.vmware.com/thread/435815

    ReplyDelete
  2. 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. :(

    ReplyDelete
  3. I think I'm in the middle of having this issue right now... not a lot of fun it has to be said. Do you know if the issue was resolved in any new patches?

    ReplyDelete
  4. Thanks for the comment, and not as far as I am aware. The best option I found was to use the command line, and then it worked going forwrds.

    ReplyDelete
  5. Replies
    1. The command is as above:
      esxcli storage vmfs snapshot list
      esxcli storage vmfs snapshot mount -l Volume_Name

      This will only work if the volume shows as mountable, if not, you have to reboot :(

      Delete