Without a good understanding of VMFS, resignaturing is an important part of what goes on in the background that will remain a mystery to you, and troubleshooting will be tricky.
If you don't own the VMware SRM product, the first step after presenting a replicated volume or LUN to your ESX hosts is the resignaturing process. As a VMware Certified Instructor (VCI) I've often thought that replication and resignaturing has been glossed over in the official courseware; however, for most VMware shops replication is an essential part of their data recovery and disaster recovery strategy.
Before I begin, it's important to emphasize that this does not apply to Network File System (NFS) volumes; it only applies to the VMFS when accessed by block-level storage such as Fibre-Channel or iSCSI.
VMFS volume properties
Let's begin by reviewing some properties of VMFS volumes.
Before and after formatting a VMFS volume on a Fibre-Channel or iSCSI volume, the storage can be addressed in many different ways:
- By its Linux device name: /dev/sdk
- By its VMkernel "runtime" device name: vmhba1:0:0:15
- By is unique Network Address Authority (NAA) value:
Requires Free Membership to View
When you register, my team of editors will also send you alerts covering all areas of VMware, such as implementing VMware-related virtualization technologies for server consolidation, disaster recovery and backup strategies, management and performance, VM migration and more.
Cathleen A. Gagne, Senior Editorial Director
- naa.6000...
- By its volume name, which has to be unique to the ESX host: myvmfs
- By its data store name, which has to be unique to vCenter: myvmfs
- By its Universally Unique Identifier (UUID): 47877284-77d8f66b-fc04-001560ace43f
It's important to know that as with the NAA, the UUID value must be completely unique and an ESX host cannot have two UUIDs that are exactly the same presented to it at the same time.
UUIDs are generated by using three core variables, including date, time and LUN number in order to guarantee that the UUID value be absolutely unique. This can cause some interesting, or shall I say unpleasant consequences if you are not consistent in your LUN numbering. That is to say problems can occur if ESX1 believes the LUN/Volume number is 15, and another ESX hosts believes the same block of storage is LUN/Volume 20.
It's also worth saying that currently virtual machines do not find their VMDK and VSWP files using the friendly volume/data store name. If you examine the contents of a .VMX file you will see references to the UUID value.
Note: In this image you can see that the second virtual disk (ctx01_1.vmdk) is being stored on a different volume (..ea5bb) to the VMs Vmkernel swap file (...ea5bc). If the virtual disk is stored in the same location as the VMX file, then the /vmfs/volumes path is not displayed in the VMX file, but it is used.
As you can see, UUID numbers are very important. The requirement for unique UUIDs does present some interesting challenges to DR. By definition, any snapshot or replication process configured in the array is intended to create an exact duplicate of the VMFS volume, which would by definition include the UUID value.
In the next two parts of this series, we'll go over exactly how SRM resignatures the volumes. Stay tuned.|
Mike Laverick (VCP) has been involved with the VMware community since 2003. Laverick is a VMware forum moderator and member of the London VMware User Group Steering Committee. Laverick is the owner and author of the virtualization website and blog RTFM Education, where he publishes free guides and utilities aimed at VMware ESX/VirtualCenter users, and has recently joined SearchVMware.com as an Editor at Large. In 2009, Laverick received the VMware vExpert award and helped found the Irish and Scottish VMware user groups. Laverick has had books published on VMware Virtual Infrastructure 3, VMware vSphere4 and VMware Site Recovery Manager. |
This was first published in March 2010