This is the website of an IT geek, technologist, freelance writer, photographer, musician, rock climber, classic mini enthusiast, iPad and Mac zealot.
You have been warned.

VMware SRM - NFS and RDM Support (Invalid Backing Bug)

Submitted by daemonchild on Tue, 2011-06-21 - 12:31
daemonchild's picture

I've just spent a few days working with a client of ours to implement VMware Site Recovery Manager (SRM). We had a number of issues along the way - mostly due to the way in which they are using a mixture of NFS and iSCSI datastores. It was when we threw RDMs (via iSCSI) into the mixture that the problem I'm describing came about. When we talked to VMware support, we discovered that it is a known bug likely to be fixed in Update 3 of SRM (due Q4 2011?). Luckily there is a work around.

Incompatible device backing specified for device ‘0’
When we tried a test recovery in SRM, we were seeing that some virtual machines would fail with a "Incompatible device backing specified for device ‘0’" error. This clearly relates to the availability of a disk that SRM is trying to map to the virtual machine. Once we looked into this more closely, it became clear that the "missing" disks were RDMs.

The client has this setup (don't ask - I'd have just used iSCSI):

.VMX file: stored on NFS
.VMDK (C drive): stored on NFS with VMX
.VMDK (RDM Map): stored on iSCSI datastore because you can't put one on NFS (try it!).
RDM: via iSCSI

Having been through a bunch of troubleshooting and checking of configuration, we were able to tell that:

  • The RDM was replicating to the recovery site perfectly;
  • SRM was asking the (NetApp) storage array to create a snapshot;
  • The snapshot worked and the LUN was presented available for the ESX servers to use;
  • They were failing to map this to the VM!
  • A manual attach of the snapshot RDM would work perfectly.

    Hence opening a support call.

    It turns out that it is not supported with SRM to have an RDM on a machine that is stored on NFS. This is because there is a bug that means that it fails where the RDM map file is on a different datastore from the VMX file (and more specifically the C drive VMDK.) We believe that this is because you can end up with two identically named .VMDK files. On different paths, maybe, but identically named.

    Workaround
    WARNING: First, you have to shut down your VM (!) and remove it from the vCentre inventory.

    After that, the fix is to rename the RDM Mapping file. Say your VMs is called "SomeVM". On the datastore that you have your RDM mapping files you'll have a folder called "SomeVM" too. Inside it will be an RDM vmdk:

    [RDM Datastore]/SomeVM/SomeVM-01.VMDK

    To rename it, insert something random (or better still, meaningful!):

    vmkfstools -E SomeVM-01.VMDK SomeVM-RANDOM-01.VMDK

    Then, you need to edit the VMX file and change the reference of SomeVM-01.VMDK to SomeVM-RANDOM-01.VMDK. Save the file and add it back into the inventory. Your VM should restart perfectly, and SRM will protect it properly too.

    • Tags: 
    vmware
    iscsi
    srm
    nfs
    Hello