The RA must be installed on the machine that you configure as the destination VM for the SFR session. In the SFR wizard, you can pick a source and destination VM. The destination VM ID is optional and will default to the source VM if not specified.
"No access permissions present for guest with BIOS ID : xxxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx"
This message just means that you do not have a valid SFR session configured within SMVI that allows the current VM. For your case, it happened when you ran the RA on a VM other than the destination VM that you configured within the SFR session. This could also happen if your SFR session has expired.
"Could not find SCSI disk device Port [1] - Target[1] - Bus [0] - Lun [0]"
I want to point out that we only support VMDKs attached to a VM using a SCSI controller. We do not support IDE disks as there is a severe limit to the number of IDE disks a VM can access (4 total). The above message can come up in a few different ways depending on how you created your SFR session. Diagnosis will usually require access to the VM and vCenter.
If you created a self-service session, then the VMDKs are added on demand from the RA. Using the RA, when you request a backup to be mounted, it will send the request to the SMVI server. The server will create a clone of your datastore. Since you are using NFS, this requires a FlexClone license to create a clone of the volume. This is clone is added as an export to your filer and mounted to your ESX host through vCenter as a NFS datastore. Next, the server will use the VMDKs from the backup that are in the new mounted datastore and attach those VMDKs to your VM. At this point, the server returns to the RA which VMDKs were added to the VM and on which SCSI controller and location on that controller. The RA forces the host OS to rescan the SCSI controllers for new disks and looks for those new disks so it can assign driver letters.
If you created an admin-assisted session, the datastore is cloned and the VMDKs are attached to the VM up front. The XML file for the RA contains all of the information about where the VMDKs were attached. The RA will rescan the SCSI controllers and assign driver letters.
To diagnose issues in either session type, first, use vCenter to check if the datastores were cloned properly. If you have an original datastore called 'Foo' and a backup called 'Bar', you'll see a new datastore similar to 'Foo (Backup Bar)'.
Next, use vCenter to see if your VM has new VMDKs attached to it from the new datastore. Select your VM in vCenter. Select the Edit Settings option. Select each Hard Disk attached to the VM. On the right side, you will see which datastore each disk is from. Alternatively, the Summary tab for a VM contains all of the datastores that the VM is using. Just glance at that to make sure the new datastore is being used by the VM.
If your VMDKs from the backup are attached to the VM correctly, then the next place to look is inside the guest OS itself. You can use your favorite Windows tool to view the disks attached to your VM. There are GUI and console tools on most Windows OSes. Control Panel -> Admin Tools -> Computer Manager for the GUI or diskpart for the console.
Most likely, if the VMDKs are attached to the VM and you are getting this error, then it may be a bug in the RA.
I hope this is enough background for you to get an idea of what caused the problem. Please post back with what you find.
Josh
