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):
- Create a RW Virtual Volume copy of the RO LUN at the remote site
- Unexport the RO LUN from the remote VMWare hosts
- Export the RW LUN to the remote VMware hosts
- Mount this RW LUN
- Import the configuration
- Unexport the remote RW LUN
- Export the remote RO LUN
- 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?
Posted this to the VMware forums:
ReplyDeletehttp://communities.vmware.com/thread/435815
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.
ReplyDeleteStrange thing is Hyper-V manages this just fine. :(
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?
ReplyDeleteThanks 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.
ReplyDeleteWhich command are you using?
ReplyDeleteThe command is as above:
Deleteesxcli 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 :(