Mount VMFS Datastore manually is sometimes necessary when working with DR plans. A volume that isn't automatically mounted on the other side has to be mounted manually. Normaly SRM takes care of it.
Also, sometimes when an existing VMFS volume is still present we have an option to keep an existing signature or choose to resignature. What's the options and the gotchas here? How does this impact the datas which are stored on those volumes?
Keep the existing signature – You basically cannot mount two datastores with the same UUID on the same host. ESXi uses the UUID to reference the device. However, you may un-mount the initial datastore and mount the duplicate datastore with the same UUID. You can also mount a snapshot/replicated lun, while keeping the existing signature, on a host that does not have access to the original lun (DR plans etc…).
Assign a new signature – This will change the UUID and allow it to be mounted. There are some things to bear in mind before you make your choice. Creating a new signature for a drive is irreversible – once a new signature applied, there is no way back. For example if you have datastore with extents, note that such a datastore may only be resignatured once, and all extents must be online. Last note concerning a resignature is that if a datastore is resignatured, the VMs stored on this a datastore must be reassociated with the disk in their respective configuration files and the VM must be re-registered within vCenter.
In this situation it is usually ok to mount the lun without resignaturing because the host to which you mount the lun is likely in a DR site, and as such doesn’t have access to the original lun. Basically, it’s fine not to perform the resignature when mounting the volume on a host that is unable to see the original disk. Resignaturing becomes important when you need to mount a replicated lun on the same host(s) that have the original mounted.
So, how it is done?
You can resignature a disk by using the vSphere Client or using the command line. vSphere client gave me no results recently, but normally it's very easy. You just do it when you first select your host > configuration > storage > add storage > chose disk/lun > and choose the option you want.
Select Assign new signature or keep existing signature, depending on your needs, and click next, next …
Using ESXCLI
We can list all detected VMFS snapshot volumes with the following command, even if for some reason we aren't able to mount the volume from within vSphere client (it was my case in a lab recently…).
This command will list the names of the VMFS datastores and their UUIDs.
esxcfg-volume –l
As you can see in our case we have the output like this:
Choose either:
esxcfg-volume –r
to resignature the volume. The general syntax is following:
esxcli storage vmfs snapshot resignature –volume-label=<label>|–volume-uuid=<id>
OR use the “M” switch (note it's a Capital M) to mount the volume as is (keep existing signature):
esxcfg-volume –M
to mount the volume without resignaturing (use lower case m for temporary mount rather than persistent).
Yes, if you do not wish the volume mount to persist a reboot, the -m switch shall be used instead.
Hope it will help when needed… If you liked this post, just share.
Don’t forget to subscribe to our RSS feed, FB and Twitter !!
have you ever tried to “keep existing signature” using the UI if the old datastore still exists within your vCenter inventory?
The documentation is unclear about this. It sais that the original datastore must be removed before mounting a copy using “keep existing signature”. Yet it also sais that the feature is ment to be used in DR cases. Also kb 1011387 mentions that the UI fully supports the force-mount (esxcfg-volume –M) option.
In my tests I have found however that in the event of a real DR this doesn’t work as one would expect it to work. If site A goes down and you try to attach the replicas to a host in cluster B (same datcenter object as cluster A) then the UI won’t let you do this. Fatclient will fail with no error message. Webclient will fail telling you that a datastore with the same signature already exists. Although it doesn’t exist on that host nor that cluster, I think the issue is that it exists on atleast one other host which is part of the same datacenter object in vSphere. There are many reasons why one would want to keep two clusters (sites) at the same datacenter object in vSphere. As of vSphere 5.5 even more then as of vSphere 6.0. Whatever the reasons are, the UI will fail you at that point.
What I found is, however, that using the CLI (esxcfg-volume –M) it will work. After that – again – using the CLI it’s possible to force re-assign a host for a VM that is still registred with a dead host of cluster A.
The hole point behind that is that one doesn’t want to loose the vCenter inventory information by removing the dead hosts or unregistering and re-registering the dead VMs.
awesome…it worked for ESXi 5.1 luns went missing..
for prod environment, multiple LUNs and those had snapshot of VMs as well.
Host was rebooted and after reboot LUns were not visible.
this command helped
esxcfg-volume –l
esxcfg-volume -M uuid
Thanks for your experience. Glad it worked for you…
THanks..it works for me…
worth a million….
for esxi 6.0
Works fine on ESXi 6.5
Just the ticket! After downgrading the scsi-hpvsa driver on esxi 6.5 due to performance issues and rebooting the datastore was missing. This worked like a charm.
Great article and comments. Is there a way to do this using PowerCLI?
Thank you very much, you saved me !
Thanks for this – very helpful
Thanks for this – production environment up and running again…!
Paul
can we add this in vsphere webclient VCP6.5?
This hint saves our life. Thanks a lot
Great article . Thank you.
This hint (-M) mounted my first datastore1 perfect.
After the reboot I tried it on the 3 remaining datastore2/3/4 it did not work
I see the drives under Datastore >>> Devices BUT the datastores wil not mount ?
When I run “esxcfg-volume -l” Nothing is listed anymore ?
Plse assit asap
It helped me a lot!
OVH Rents a 4 drive server, but 1 drive i did need to rescue using this method. OVH install ESXI in this drive and it is unmountable tru graphical interface.
Your procedure helps a lot thank you for your solution.