2009-10-30 03:22 AM
Hi after upgrading to SMVI 2.0, i experienced some issues with the SFR feature.
First, is there a way to get some SMVI documentation? I am getting the below error messages on RestoreAgent and have no idea on there meaning.
Do we have to install Remoteagent on the destination VM, or can it be installed on any admin workstation or on the SMVI server?
Below is the message i get when starting Restore Agent console from my workstation :
"No access permissions present for guest with BIOS ID : xxxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx". Despite these, it starts after canceling the dialog box.
When it is installed on the destination VM (the one that needs file restore), the above message did'nt appear at Remoteagent startup, but when i try to mount a backup i get the following error message :
"Could not find SCSI disk device Port  - Target - Bus  - Lun "
Some considerations :
- Just to notice that my VMware storage Netapp setup is based on NFS. No iSCSI datastore were used. So does Remoteagent support VMs on NFS storage?
- For security reasons I have setup IP restrictions on the filer. Should the Restoreagent needs connecting directely to the filer or does it communicate only with the SMVI server or VCserver ?
Thks for help
2009-10-30 03:50 AM
The Installation and administration Guide is available on the NOW website.You could take a look at that. You can install restore agent(RA) on the destination VM. Restore agent interacts with SMVI which in turn talks to the vcenter server.RA does not have to connect directly to the filer. Also RA supports NFS VM's.
2009-10-30 04:43 AM
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  - Target - Bus  - Lun "
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.
2009-10-30 06:34 AM
Thks for your help,
Ok, the first error message was related to the fact that Destination VM wasn't the one where RA was installed. I tried by installing RA on the destiniation VM and it's worked fine.
By switching to admin-assisted mode the Backup VMDK were well mounted on the VM, but when going to adminstrative tools the disk didn't appeared in the diskpart console. I had to restart the VM in order to get them recognized by the OS. It's a big step in my problem but it will be appreciable to not have to restart the VM in order to remount new VMDK's. I think I had to search on the side of VMware or Windows from now.
Thks again, you were very helpful.
2009-10-30 06:37 AM
If you use the admin-mode, go ahead and use the RA as well. It will rescan your SCSI bus for you and assign the driver letters.
You did not need to restart the VM. Diskpart has an option to rescan the SCSI bus as well. You should be able to use that option so that Windows can see the new disks.
2009-10-30 06:58 AM
The concern of using admin-assisted mode isn't to manage restore sessions and mounts backup remotely without involving the requester or installing RA on the destination VM ? the admin-assisted will be less intersting if we had also to install RA (which is rather a heavy process with .Net Framework, ...and long) in order to rescan new attached VMDK's. I will test the windows SCSI bus scan option and keep it that way if it works .