VMware RDMs in Physical Vs Virtual compatibility mode

VMware RDMs in Virtual compatibility mode	VMware RDMs in Physical compatibility mode
advanced file locking for data protection	No
Take Snapshots and snapshot based back up is possible	No
Behaves exactly like a virtual disk & Guest OS sees it as a virtual disk and the real characteristics are hidden. RDM behaves as a virtual disk	Allows the Guest OS to access the hardware directly.
Luns with size limit of 2tb for RDMs	Luns of size greater than 2tb are supported
A disk device backed by a virtual compatibility mode raw disk mapping can use disk modes.	A disk device backed by a physical compatibility mode raw disk mapping cannot use disk modes, and commands are passed straight through to the LUN indicated by the raw disk mapping.
Doesn’t support MSCS (Microsoft clustering services)	Supports MSCS (Microsoft clustering services
For virtual compatibility mode RDMs, you can migrate the mapping file or convert to thick-provisioned or thin-provisioned disks during migration as long as the destination is not an NFS datastore. If you convert the mapping file, a new virtual disk is created and the contents of the mapped LUN are copied to this disk	For physical compatibility mode RDMs, you can migrate the mapping file only.
Bad for SAN aware applications.	Best for SAN aware applications.
Cloning is possible	No
Create templates of the VM with RDMs in virtual compatibility mode.	No
During migration you can either migrate the mapping file or copy the contents of the RDM lun into a virtual disk.	Can’t migrate if the migration involves the copying of the disk
No	Scsi Target based softwares & SAN Management agents
No	Physical server to Virtual Machine Clustering

ESXi 5 patch installation fails with error "Could not download from depot at zip:/var/log/vmware/*update name*.zip?index.xml..."

Issue : Trying to install the async driver for the ESXi 5 host with the help of the vmware kb/2005205 but it fails with a "MetadataDownloadError" reading:
Could not download from depot at zip:/var/log/vmware/*update name*.zip?index.xml, skipping (('zip:/var/log/vmware/*update name*.zip?index.xml', '', "Error extracting index.xml from :/var/log/vmware/*update name*.zip: [Errno 2] No such file or directory: '/var/log/vmware/*update name*.zip?index.xml'"))
url = zip:/var/log/vmware/*update name*.zip?index.xml
Please refer to the log file for more details.

command used to instal the driver

esxcli software vib install –d /vmfs/volumes/datastore/offline-bundle.zip

and/or

esxcli software vib install –d /vmfs/volumes/datastore/offline-bundle.vib

Cause: The datastore has a namespace in it

Solution: Sometimes you can bypass this error by just running the command with the full path to the offline-bundle just like the one i showed in the above example but not all the times. In such scenarios you have to use the datastore id instead of the name of the datastore in the above command.

example:

esxcli software vib install –d /vmfs/volumes/4f14e96d-673fa1b7-0b72-001e4f2f111a/offline-bundle.zip

or

esxcli software vib install –d /vmfs/volumes/4f14e96d-673fa1b7-0b72-001e4f2f111a/offline-bundle.vib

Alternatively you can just copy the driver to a datastore where the name of the datastore has no namespace in it and try the installation.

Note: no namespace should be present in the entire path of the patch; what i mean to say is no name space for the name of the datastore or the name of the folder inside the datastore where the patch(offline-bundle.zip) is located.

It is always advisable to avoid the namespace when you are in a unix/linux/vmware environment.

When your luns have lost their partition and you cannot add them in VMware

Issue: When you try to add your lun with vmware data in it it asks you to reformat it.

Unable to read partition information from this disk

The hard disk is blank.

Error during the configuration of the host: Failed to update disk partition information.

Solution: Recreate the partition

1. Try to add that particular lun which you are not able to add and make a note of the naa.xxxx number that you see for the lun.

2. run

Esxcfg-scsidevs -l in the command line which will list all the devices with their naa.xxxx

 compare the naa.xxx id that you copied earlier from the vcenter server to the list that you see here and make a note of the /vmfs/devices/disks/DeviceName for that particular naa.xxxx id and run the command

fdisk -l "/vmfs/devices/disks/DeviceName"

The output appears similar to:

Disk /vmfs/devices/disks/DeviceName: 536 MB, 536870912 bytes
255 heads, 63 sectors/track, 65 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

                        Device Boot    Start       End    Blocks   Id  System
/vmfs/devices/disks/DeviceName             1        66    524287+  ee  EFI GPT

The rest of it is in the below links from VMware.

Refer : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008886

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1014953