Configuring CHAP Parameters for iSCSI Adapters

Because the IP networks that the iSCSI technology uses to connect to remote targets do not protect the data they transport, you must ensure security of the connection. One of the protocols that iSCSI implements is the Challenge Handshake Authentication Protocol (CHAP), which verifies the legitimacy of initiators that access targets on the network.

CHAP uses a three-way handshake algorithm to verify the identity of your host and, if applicable, of the iSCSI target when the host and target establish a connection. The verification is based on a predefined private value, or CHAP secret, that the initiator and target share.

ESXi supports CHAP authentication at the adapter level. In this case, all targets receive the same CHAP name and secret from the iSCSI initiator. For software and dependent hardware iSCSI adapters, ESXi also supports per-target CHAP authentication, which allows you to configure different credentials for each target to achieve greater level of security.

ESXi supports one-way CHAP for all types of iSCSI initiators, and mutual CHAP for software and dependent hardware iSCSI.

Before configuring CHAP, check whether CHAP is enabled at the iSCSI storage system and check the CHAP authentication method the system supports. If CHAP is enabled, enable it for your initiators, making sure that the CHAP authentication credentials match the credentials on the iSCSI storage.

ESXi supports the following CHAP authentication methods:

One-way CHAP

In one-way CHAP authentication, also called unidirectional, the target authenticates the initiator, but the initiator does not authenticate the target.

Mutual CHAP

In mutual CHAP authentication, also called bidirectional, an additional level of security enables the initiator to authenticate the target. VMware supports this method for software and dependent hardware iSCSI adapters only.

For software and dependent hardware iSCSI adapters, you can set one-way CHAP and mutual CHAP for each initiator or at the target level. Independent hardware iSCSI supports CHAP only at the initiator level.

When you set the CHAP parameters, specify a security level for CHAP.

Note

When you specify the CHAP security level, how the storage array responds depends on the array’s CHAP implementation and is vendor specific. For example, when you select Use CHAP unless prohibited by target, some storage arrays use CHAP in response, while others do not. For information on CHAP authentication behavior in different initiator and target configurations, consult the array documentation.

CHAP Security Level

CHAP Security Level	Description	Supported
Do not use CHAP	The host does not use CHAP authentication. Select this option to disable authentication if it is currently enabled.	Software iSCSI Dependent hardware iSCSI Independent hardware iSCSI
Do not use CHAP unless required by target	The host prefers a non-CHAP connection, but can use a CHAP connection if required by the target.	Software iSCSI Dependent hardware iSCSI
Use CHAP unless prohibited by target	The host prefers CHAP, but can use non-CHAP connections if the target does not support CHAP.	Software iSCSI Dependent hardware iSCSI Independent hardware iSCSI
Use CHAP	The host requires successful CHAP authentication. The connection fails if CHAP negotiation fails.	Software iSCSI Dependent hardware iSCSI

Set Up CHAP Credentials for iSCSI Initiator

You can set up all targets to receive the same CHAP name and secret from the iSCSI initiator at the initiator level. By default, all discovery addresses or static targets inherit CHAP parameters that you set up at the initiator level.

The CHAP name should not exceed 511 alphanumeric characters and the CHAP secret should not exceed 255 alphanumeric characters. Some adapters, for example the QLogic adapter, might have lower limits, 255 for the CHAP name and 100 for the CHAP secret.

Prerequisites

■

Before setting up CHAP parameters for software or dependent hardware iSCSI, determine whether to configure one-way or mutual CHAP. Independent hardware iSCSI adapters do not support mutual CHAP. ■ In one-way CHAP, the target authenticates the initiator. ■ In mutual CHAP, both the target and the initiator authenticate each other. Use different secrets for CHAP and mutual CHAP. When you configure CHAP parameters, verify that they match the parameters on the storage side.

■

Required privilege: Host.Configuration.Storage Partition Configuration

Procedure

1	Access the iSCSI Initiator Properties dialog box.
2	On the General tab, click CHAP.
3	To configure one-way CHAP, under CHAP specify the following: a Select the CHAP security level. ■ Do not use CHAP unless required by target (software and dependent hardware iSCSI only) ■ Use CHAP unless prohibited by target ■ Use CHAP (software and dependent hardware iSCSI only). To configure mutual CHAP, you must select this option. b Specify the CHAP name. Make sure that the name you specify matches the name configured on the storage side. ■ To set the CHAP name to the iSCSI initiator name, select Use initiator name. ■ To set the CHAP name to anything other than the iSCSI initiator name, deselect Use initiator name and type a name in the Name text box. c Enter a one-way CHAP secret to be used as part of authentication. Use the same secret that you enter on the storage side.
4	To configure mutual CHAP, first configure one-way CHAP by following the directions in Step 3. Make sure to select Use CHAP as an option for one-way CHAP. Then, specify the following under Mutual CHAP: a Select Use CHAP. b Specify the mutual CHAP name. c Enter the mutual CHAP secret. Make sure to use different secrets for the one-way CHAP and mutual CHAP.
5	Click OK.
6	Rescan the initiator.

If you change the CHAP or mutual CHAP parameters, they are used for new iSCSI sessions. For existing sessions, new settings are not used until you log out and log in again.

Set Up CHAP Credentials for Target

For software and dependent hardware iSCSI adapters, you can configure different CHAP credentials for each discovery address or static target.

When configuring CHAP parameters, make sure that they match the parameters on the storage side. The CHAP name should not exceed 511 and the CHAP secret 255 alphanumeric characters.

Required privilege: Host.Configuration.Storage Partition Configuration

Prerequisites

Before setting up CHAP parameters for software and dependent hardware iSCSI, determine whether to configure one-way or mutual CHAP.

■	In one-way CHAP, the target authenticates the initiator.
■	In mutual CHAP, both the target and initiator authenticate each other. Make sure to use different secrets for CHAP and mutual CHAP.

Procedure

1	Access the iSCSI Initiator Properties dialog box.
2	Select either Dynamic Discovery tab or Static Discovery tab.
3	From the list of available targets, select a target you want to configure and click Settings > CHAP.
4	Configure one-way CHAP in the CHAP area. a Deselect Inherit from parent. b Select one of the following options: ■ Do not use CHAP unless required by target ■ Use CHAP unless prohibited by target ■ Use CHAP. To be able to configure mutual CHAP, you must select this option. c Specify the CHAP name. Make sure that the name you specify matches the name configured on the storage side. ■ To set the CHAP name to the iSCSI initiator name, select Use initiator name. ■ To set the CHAP name to anything other than the iSCSI initiator name, deselect Use initiator name and enter a name in the Name field. d Enter a one-way CHAP secret to be used as part of authentication. Make sure to use the same secret that you enter on the storage side.
5	To configure mutual CHAP, first configure one-way CHAP by following directions in Step 4. Make sure to select Use CHAP as an option for one-way CHAP. Then, specify the following in the Mutual CHAP area: a Deselect Inherit from parent. b Select Use CHAP. c Specify the mutual CHAP name. d Enter the mutual CHAP secret. Make sure to use different secrets for the one-way CHAP and mutual CHAP.
6	Click OK.
7	Rescan the initiator.

If you change the CHAP or mutual CHAP parameters, they are used for new iSCSI sessions. For existing sessions, new settings are not used until you log out and login again.

Disable CHAP

You can disable CHAP if your storage system does not require it.

If you disable CHAP on a system that requires CHAP authentication, existing iSCSI sessions remain active until you reboot your host, end the session through the command line, or the storage system forces a logout. After the session ends, you can no longer connect to targets that require CHAP.

Required privilege: Host.Configuration.Storage Partition Configuration

Procedure

1	Open the CHAP Credentials dialog box.
2	For software and dependent hardware iSCSI adapters, to disable just the mutual CHAP and leave the one-way CHAP, select Do not use CHAP in the Mutual CHAP area.
3	To disable one-way CHAP, select Do not use CHAP in the CHAP area. The mutual CHAP, if set up, automatically turns to Do not use CHAP when you disable the one-way CHAP.
4	Click OK. Thanks to Vmware Documentation

Types of supported Virtual Disks on ESX/ESXi hosts (1022242)

Purpose

This article provides an overview of the types of virtual disks supported by ESX/ESXi.

Resolution

The supported disk formats in ESX are:

• zeroedthick (default) – Space required for the virtual disk is allocated during the creation of the disk file. Any data remaining on the physical device is not erased during creation, but is zeroed out on demand at a later time on first write from the virtual machine. The virtual machine does not read stale data from disk.
• eagerzeroedthick – Space required for the virtual disk is allocated at creation time. In contrast to zeroedthick format, the data remaining on the physical device is zeroed out during creation. It might take much longer to create disks in this format than to create other types of disks.

• thick – Space required for the virtual disk is allocated during creation. This type of formatting does not zero out any old data that might be present on this allocated space. A non-root user cannot create disks of this format.
• thin – Space required for the virtual disk is not allocated during creation, but is supplied and zeroed out, on demand at a later time.
• rdm – Virtual compatibility mode for raw disk mapping.
• rdmp – Physical compatibility mode (pass-through) for raw disk mapping.
• raw – Raw device.
• 2gbsparse – A sparse disk with 2GB maximum extent size. You can use disks in this format with other VMware products, however, you cannot power on sparse disk on a ESX host till you reimport the disk with vmkfstools in a compatible format, such as thick or thin.
• monosparse – A monolithic sparse disk. You can use disks in this format with other VMware products.
• monoflat – A monolithic flat disk. You can use disks in this format with other VMware products.

Use these commands to create a virtual disk:

 

vmkfstools
-c --createvirtualdisk <size>[kK|mM|gG]
-a --adaptertype [buslogic|lsilogic] <srcfile>
-d --diskformat [thin|zeroedthick|eagerzeroedthick]

Source:-

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

Changing the thick or thin provisioning of a virtual disk (2014832)

Purpose

This article provides steps to change the provisioning of a virtual disk from thick to thin, or from thin to thick. The procedure uses the vSphere Client and vCenter Server to perform this task.

Resolution

Note: Before following these procedures, VMware highly recommends that you have a valid backup of the virtual machine and enough space to convert the virtual machine's disk(s) from thin to thick.

To change the provisioning of a virtual machine base disk from thin to thick from the Datastore Browser:

1. Power off the virtual machine.
2. In vSphere Client, right-click the virtual machine in the inventory.
3. Click Edit Settings to display the Virtual Machine Properties dialog box.
4. Click the Hardware tab and select the appropriate hard disk in the Hardware list.
   
   Note: The Disk Provisioning Type section on the right displays either Thin Provision or Thick Provision. If the disk provision type is Thick, disk provisioning has already taken place. In this case, the disk provisioning is Thin.
   
5. Click Cancel to exit out of Virtual Machine Properties dialog box.
6. Click the Summary tab of the virtual machine.
7. Under Resources, right-click the datastore where the virtual machine resides and click Browse Datastore.
8. Double-click the virtual machine folder to display the  .vmdk file.
9. Right-click the .vmdk file, and click Inflate. The Inflate option converts the disk to thick provisioned.

Notes:

• If the Inflate option is grayed out, this may indicate that the virtual machine is not powered off or that it is not thin provisioned.
• There should be no snapshots and the conversion is performed on the base disk.

To convert a virtual machine base disk from thick to thin provisioning by changing the datastore and using offline virtual machine migration:

1. Power off the virtual machine.
2. Right-click the virtual machine, and click Migrate.
3. Click Change datastore.
4. Click Next, and select a datastore that is not the same as the current datastore.
5. From the dropdown, select the Thin Provision virtual disk format.
6. Click Next, then Finish.

Note: This process requires more than one datastore. If only a single datastore exists, you can clone the virtual machine to a destination machine with thin provisioned disks instead of migrating.

Source:-

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

Multipathing policies in ESXi 5.x and ESXi/ESX 4.x (1011340)

Purpose

This article describes the various pathing policies that can be used with VMware ESXi 5.x and ESXi/ESX 4.x.

Note: These are referred to as Path Selection Plug-ins (PSP), and are also called Path Selection Policies.

Resolution

These pathing policies can be used with VMware ESXi 5.x and ESXi/ESX 4.x:

• Most Recently Used (MRU): Selects the first working path, discovered at system boot time. If this path becomes unavailable, the ESXi/ESX host switches to an alternative path and continues to use the new path while it is available. This is the default policy for Logical Unit Numbers (LUNs) presented from an Active/Passive array. ESXi/ESX does not return to the previous path if, or when, it returns; it remains on the working path until it, for any reason, fails.
  
  Note: The preferred flag, while sometimes visible, is not applicable to the MRU pathing policy and can be disregarded.
  
• Fixed (Fixed): Uses the designated preferred path flag, if it has been configured. Otherwise, it uses the first working path discovered at system boot time. If the ESXi/ESX host cannot use the preferred path or it becomes unavailable, the ESXi/ESX host selects an alternative available path. The host automatically returns to the previously-defined preferredpath as soon as it becomes available again. This is the default policy for LUNs presented from an Active/Active storage array.
  
• Round Robin (RR): Uses an automatic path selection rotating through all available paths, enabling the distribution of load across the configured paths.
  
  
  • For Active/Passive storage arrays, only the paths to the active controller will be used in the Round Robin policy.
  • For Active/Active storage arrays, all paths will be used in the Round Robin policy.
  
  Note: This policy is not currently supported for Logical Units that are part of a Microsoft Cluster Service (MSCS) virtual machine.
  
• Fixed path with Array Preference: The VMW_PSP_FIXED_AP policy was introduced in ESXi/ESX 4.1. It works for both Active/Active and Active/Passive storage arrays that support Asymmetric Logical Unit Access (ALUA). This policy queries the storage array for the preferred path based on the array's preference. If no preferred path is specified by the user, the storage array selects the preferred path based on specific criteria.
  
  Note: The VMW_PSP_FIXED_AP policy has been removed from ESXi 5.0. For ALUA arrays in ESXi 5.0, the MRU Path Selection Policy (PSP) is normally selected but some storage arrays need to use Fixed. To check which PSP is recommended for your storage array, see the Storage/SAN section in the VMware Compatibility Guide or contact your storage vendor.

Notes:

• These pathing policies apply to VMware's Native Multipathing (NMP) Path Selection Plug-ins (PSP). Third-party PSPs have their own restrictions.
• Round Robin is not supported on all storage arrays. Please check with your array documentation or storage vendor to verify that Round Robin is supported and/or recommended for your array and configuration. Switching to a unsupported or undesirable pathing policy can result in connectivity issues to the LUNs (in a worst-case scenario, this can cause an outage).

Warning: VMware does not recommend changing the LUN policy from Fixed to MRU, as the automatic selection of the pathing policy is based on the array that has been detected by the NMP PSP.

Additional Information

• The Round Robin (RR) multipathing policies have configurable options that can be modified on the command line. Some of these options include:
  
  
  • Number of bytes to send along one path for this device before the PSP switches to the next path.
  • Number of I/O operations to send along one path for this device before the PSP switches to the next path.
    
  For more information, see Round Robin Operations with esxcli storage nmp psp roundrobin in the vSphere Command-Line Interface Installation and Reference Guide for the appropriate version of your VMware product.
  
• To change a LUN to use the Round Robin path policy, see Changing a LUN to use a different Path Selection Policy (PSP) (1036189).
  
• To change newly provisioned LUNs to use Round Robin by default, see Changing the default pathing policy for new/existing LUNs (1017760).
  
• For more information, search for Multipathing Considerations and PSP in the vSphere 5 Documentation Center.

Source:-

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

Virtual network adapters that support jumbo frames (1015556)

Details

This article provides information on products and adapters that support jumbo frames.

Solution

Jumbo frames are supported in these configurations:

 

Product	Supported Adapter
ESX/ESXi 4.0.x	vmxnet2 (enhanced vmxnet) or vmxnet3
ESX/ESXi 4.1.x	e1000, vmxnet2 (enhanced vmxnet) or vmxnet3
ESXi 5.x	e1000, vmxnet2 (enhanced vmxnet) or vmxnet3

 

Source:-

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

vSphere Client shows VMware Tools as Unsupported (2011350)

Symptoms

After upgrading vCenter Server 4.1 to 5.x with ESXi/ESX hosts still running on version 4.1, the status of VMware Tools for virtual machines is reported as Running (Unsupported). 

Cause

The VMware Tools status information comes from the vmx process (which is responsible for running the virtual machine) and can change only if the ESXi/ESX host is upgraded with a newer VMware Tools distribution.

Note: There has been a change in the VMware Tools status with vSphere 5.x.

Resolution

To resolve this issue, use the UI hint information for the various VMware Tools status messages.

To view the UI hint information:

1. Click the virtual machine.
2. Click on the Summary tab.
3. Hover the mouse over the VMware Tools current value in the General box. You see a text box that shows the current UI hint information.

This table lists the various VMware Tools status message and the corresponding UI hint:

Status	Internal values (VMODL)	UI values	UI hint
Green	guestToolsCurrent	Current	VMware Tools is installed and the version is current.
	guestToolsSupportedNew	Current	VMware Tools is installed and the version is current.
Yellow	guestToolsSupportedOld	Out-of-date	OK. This version is supported on the existing host, but upgrade if new functionality does not work.
Red	guestToolsNotInstalled	Not Installed	Install VMware Tools. See the vSphere Client Help.
	guestToolsTooOld	Unsupported	Upgrade or reinstall VMware Tools. This version is not supported on the existing host. See the vSphere Client Help.
	guestToolsNeedUpgrade	Unsupported	Upgrade or reinstall VMware Tools. This version is not supported on the existing host. See the vSphere Client Help.
	guestToolsBlacklisted	Error	Upgrade immediately to avoid possible corrupt code. See the vSphere Client Help.
	guestToolsTooNew	Unsupported new version	Uninstall and reinstall this version of VMware Tools. This version is known to be too new to work correctly with this virtual machine. See the vSphere Client Help.
Gray	guestToolsUnmanaged	3rd-party/Independent	The status is unknown. Tools are installed, but are not managed by VMware.
	guestToolsNotRunning	3rd-party/Independent	Tools are installed but vmtoolsd was stopped using theinit.d script.

Source:-

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

Check All the Datastores Visible to ESXi Host from vSphere Web Client

Select ESXi Host --> Related Objects Tab --> Datastores

Add/Remove the Physical Adapter From vSwitch by Using vSphere Web Client

1. Select ESXi host --> Manage Tab --> Networking --> Select vSwitch --> Click on manage physical network adapters

2. Click on "+" or "x" to Add/Remove the Physical Adapter To/From your vSwitch

Enable HD Audio in vSphere 5

First step is to un-register the VM from vCenter.

Second, open up a PuTTy session to an ESX host and browse to your datastores and into your VM folder an do a vi vmname.vmx. Scroll all the way to the bottom and add the following lines (using i for insert):

sound.present = "true"
sound.allowGuestConnectionControl = "false"
sound.virtualDev = "hdaudio"
sound.fileName = "-1"
sound.autodetect = "true"

Before you add the next line, you need to verify an available PCI slot number. My example above used 34. In this demonstration, PCI slot numbers 33 and 34 are already in use, so I'll use PCI Slot number 35 (again using i for insert).

sound.pciSlotNumber = "35"

Press escape to exit and ZZ to write the changes

Now that we have added the new hardware via .vmx, browse the datastore and register the virtual machine into vCenter. Once the VM is back in vCenter, edit the settings of the VM and you will now see there is a new driver called HD Audio. This is Virutal Machine Hardware version 8

Here is hardware version 7.

So now what happens when you boot the VM? Windows does find the driver. I would expect that this would primarily be for VMware View environments, but it's just a guess.

Shout-out goes to William Lam over at virtuallyghetto.com for his help and he also uncovered a new virtual ethernet adapter called "e1000e" that I'm sure you will see him talk about soon.

After testing out a quick PCoIP session to this Windows 7 VM, found that sound DOES NOT WORK using the HD Audio playback device. I had to reset to the VMware Virtual Audio playback device to get sound working once again. My bet, this is for a future version of VMware View.

vSphere Storage Appliance (VSA) interoperability with vCenter Server(2039938)

Purpose

This article clarifies the interoperability between the vSphere Storage Appliance (VSA) and vCenter Server.

Resolution

The vSphere Storage Appliance (VSA) requires VMware vCenter Server to function.

It will not function with the VMware vCenter Server Appliance (sometimes referred to as the Linux vCenter, or the vCenter Appliance).

This applies to the VSA 1.x and 5.x releases.

Note: Future releases may or may not support interoperability with the vCenter Appliance. This article will be updated if there are any changes to this status.

Source:-

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

Upgrading vCenter Server Appliance from 5.0.x to 5.1 (2033990)

Purpose

This article provides steps to upgrade vCenter Server Appliance from 5.0.x to 5.1.

Resolution

vCenter Server Appliance 5.0.1 and 5.1 use PostgreSQL for the embedded database instead of IBM DB2, which was used in vCenter Server Appliance 5.0. 

If you use the embedded database with the vCenter Server Appliance, when you upgrade from 5.0 to 5.1, the embedded IBM DB2 database is migrated to a PostgreSQL database. The configuration state of your existing database is preserved and the schema is upgraded to be compatible with vCenter Server Appliance 5.1.

 

To upgrade vCenter Server Appliance from 5.0.x to 5.1:

1. Deploy the new version of the vCenter Server Appliance. For more information, see Downloading and deploying the vCenter Server Appliance 5.x (2007619). The new appliance has a default network configuration, and the Virtual Center Server service is not configured and disabled.
   
2. Connect to both the old and new appliances in separate browser windows. For Example:https://ip_address_of_vCenter_VM:5480.
   
3. In the new appliance, start the vCenter Server Setup wizard, and accept the end user license agreement.
   
4. In the new appliance, in the Configure Options panel, select Upgrade from previous version.
   
5. (Optional) Configure the vCenter Server Appliance to use an external vCenter Single Sign On instance instead of the default embedded Single Sign On.
   
   
   1. Click Configure SSO.
   2. On the SSO Settings page, set SSO deployment type to external.
   3. Enter the information for the Single Sign On instance.
      
      Note: The external Single Sign On instance must be hosted on another vCenter Server Appliance. It cannot be hosted on a Windows machine.
      
6. In the new appliance, click Next.
7. In the old appliance, on the Appliance Upgrade tab, select source for the appliance role, and click Set role.
8. In the old appliance, click Establish Trust.
9. In the new appliance, copy the local appliance key.
10. In the old appliance, paste the local appliance key into the Remote appliance key field, and click Import remote key.
11. In the old appliance, copy the local appliance key.
12. In the new appliance, paste the local appliance key into the Remote appliance key field and click Next.
13. In the new appliance, click Next. 
    
    The new appliance shuts down the old appliance and assumes the network identity of the old appliance. If the old appliance was configured to use dynamic addressing, the new appliance will also use dynamic addressing. When the import is complete, the new vCenter Server Appliance starts.
14. Review the list of hosts managed by the source appliance and make sure that the hosts you want the new appliance to manage are checked.
    
15. Review the pre-upgrade check of the source appliance hosts and correct any errors before proceeding.
    
16. Confirm that you have taken a backup or snapshot of the source appliance and the external database and click Next.
    
17. (Optional) To follow the upgrade process, open an SSH session to the vCenter Server Appliance and run this command:
    
    tail -f /var/log/vmware/vami/upgrade.log
    
    Note: This also helps in identifying where the process has stopped, if there are any issues with the upgrade.
18. When the upgrade is complete, click Close.
    
    The vCenter Server Appliance is upgraded and the new appliance reboots. 
    Source:-
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2033990
    
    

Difference between Physical compatibility RDMs and Virtual compatibility RDMs (2009226)

Purpose

This article provides information on the RDM compatibility modes and helps you to choose the mode that best suits your environment requirements.

Resolution

An RDM is a special mapping file in a VMFS volume that manages metadata for its mapped device. The mapping file is presented to the management software as an ordinary disk file, available for the usual file-system operations. To the virtual machine, the storage virtualization layer presents the mapped device as a virtual SCSI device.

RDM has two compatibility modes:

• Physical compatibility mode
• Virtual compatibility mode

Physical compatibility mode

• Physical mode specifies minimal SCSI virtualization of the mapped device, allowing the greatest flexibility for SAN management software.
• VMkernel passes all SCSI commands to the device, with one exception - The REPORT LUNs command is virtualized, so that the VMkernel can isolate the LUN to the owning virtual machine. Otherwise, all physical characteristics of the underlying hardware are exposed.
• Physical mode is useful while running SAN management agents or other SCSI target-based software in the virtual machine.
• Physical mode also allows virtual-to-physical clustering for cost-effective high availability.
• Virtual Machine Snapshots are not available when the RDM is used in physical compatibility mode.
• You can use this mode for Physical-to-virtual clustering and cluster-across-boxes.

Virtual compatibility mode

• Virtual mode specifies full virtualization of the mapped device.
• VMkernel sends only READ and WRITE to the mapped device. The mapped device appears to the guest operating system exactly the same as a virtual disk file in a VMFS volume.
• The real hardware characteristics are hidden.
• If you are using a raw disk in virtual mode, you can realize the benefits of VMFS, such as advanced file locking for data protection and snapshots for streamlining development processes.
• Virtual mode is more portable across storage hardware than physical mode, presenting the same behavior as a virtual disk file.
• You can use this mode for both Cluster-in-a-box and cluster-across-boxes.

Note: RDM is not available for direct-attached block devices or certain RAID devices. You cannot map a disk partition as RDM. RDMs require the mapped device to be a whole LUN.

Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2009226