SmartMotion will create a directory with the structure:
\\NAS_Host_name(or IP)\share\Year_Month\Year_Month_Day_TimeofSmartmotion\Folder_defined_in_vmPRO\name_of_vm\

Here is an example of a file path. Keep in mind that the share portion of the path is ignored by the restore wizard.
\\freenas.quantum.com\vmpro\2012-12\2012-12-30-0100\Critical\ASPS WEBSERVER -Keep Running\

After you've clicked Next, you'll see the following screen:


 

2.  Fill in the Configuration section for the .vmx file (shown in the previous image), as follows. DO NOT click Next until you have filled in the Virtual Disk Configuration section (at the bottom of this screen).

1. VM Name: This is static and cannot be changed, since it already exists.
2. Source VMX Name: This is static and cannot be changed, since it already exists.
3. Target VMX Name: Shows what the VM will be named when it is restored. It is used for reference when the Stop on Conflict function comes into play.)
4. Target Datastore: Where the restored image will be written to. The default is the datastore that the image current resides on (defined in the .cfg file by UUID).
5. Target Directory:  The directory in the datastore into which files will be restored.
6. Action on Conflict: What to do if there already is a file of the same name in the /export_fs mount point of /vmfs/volumes/<datastore_uuid>/vm_name. There are two options here. You can stop the restore if a file with the same .vmx file name is found. This avoids overwriting the same VM. You can also rename the restore files at the time they are written. This also prevents  overwriting the original VM.
   
   • Add the VM… and Register… options: Options for the for ESX host to inventory the VM.

3.  Fill in the Virtual Disk Configuration section, which specifies the location of the restored .vmdk files. The options are:

• Use the Same Datastore… Puts the .vmdk files into the same directory as the .vmx file.  The .vmdk files follow the .vmk configuration above.
• Use the Original Configuration… Puts the .vmdk files into the same directory that the .cfg files say they came from. The .vmk files are still directed as configured above.
• Change each Virtual Disk's Configuration: To do this:

1. Select this option.
2. Click the Edit Configuration link.
3. Choose from the options shown in the following image. Notice that you can direct each disk to a specific Target Datastore and Target Directory, as well as choosing an option for Disk Provisioning.

 

4. To save your choices, click Save.
5. When you have set all the options in Steps 2-4, click Next.
6. The Recover Virtual Machines Wizard will display the configuration of the VM, as shown in the next image.

 

1. If the listing is correct, skip to Step C below. If it is not correct, continue with Step B.
2. If you need to make changes, click Back to return to the screen shown under Step 1B above. Then repeat Steps 2-5.
3. Now that the listing is correct, click Start to begin the VM recovery.

Example Configuration Screenshot and the Resulting File Listing

The following image shows a sample configuration for an Image-Level Restore. This is the same screen as the one in Step 1B of the previous section, but with Action on Conflict set to rename, and a different Target VMX Name.

Note: This listing is more complete than the one in Step 6.
 

Using the Logs to Troubleshoot Restore Problems

Looking at the vmPRO import and datastore logs can help you troubleshoot restore problems. The logs are:

Import_fs:
 

Datastore_fs:
 

For information that can help you when troubleshooting restore problems, look at the import and datastore logs (/var/log/datastore_fs and /var/log/import_fs). The messages log gives good general info (/var/log/messages).

Using the Logs to Troubleshoot a Failed Restore

The following log entries show an example of a failed restore. The text in bold green explains various aspects of the log entries, and how you can use them for troubleshooting.
 
This logging takes place while the .vmx and .vmdk restore parameters are being checked, before you press the Start button.
The Import_fs makes a directory and node:

 
The vm.cfg file is created, and the path of the .cfg file is opened:
 

 
Here's the Point of Failure. The error:17 listing and the following description show that data cannot be written, because the Target Directory already exists! Since we haven't set the rename flag, we cannot continue the restore operation.

 
Creation of cfg.err file: This will create an error in the present working directory with the error present in ASCII form (human readable. We can clear this quickly, as discussed after the next image. The text is what is presented in the GUI error display shown below.

 
At this point you would see an error in the GUI, for example:
 

 

 
As mentioned in the image above, click the Back button and make configuration changes to fix the error. After you fix the error, such as selecting Rename for Action On Conflict, you can proceed to a healthy recovery.

Using the Logs to Verify a Successful Restore

Here is an example of a successful store, with comments in bold green.

==> import_fs <==
The Import_fs makes a directory and node:

 
The vm.cfg file is created, and the path of the .cfg file is opened:
 

 
The .cfg file is closed (the Samba share will show the file touched then removed) and the import session is created:
 

 
At this point verification is done, and the GUI is waiting for the user to click the Start button: 
 

 
We begin moving data here: 
=> import_fs <==
 
Import_fs makes its directories and nodes and opens its paths and import session. This is the same process that we see with verification: 
 

 
The .vmx file is directed from its current datastore to the specified directory and name:
 

 
The .vmdk file is directed from its current datastore to the specified directory and name: 
 

  
The messages file showing the open of the image and copy of the .vmx file:
 

 
Creating nodes, pathing, open file, and flush: 
 

 
Import of the .vmx file: 
 

Now the .vmdk files:
 

 
Datastore_FS makdir and nodes, and opening a path; files being copied: 
 

 
Import_FS is now done importing the .vmx into our datastore_fs mount point (vmfs/volumes/): 
 

 
There will be little movement in the logs, if you're only doing a restore. By looking at the export mount, you can see the directories for the datastores, and the links identifying them by name:

 
We can see an example for the datastore VMStorage4 with a new directory, webserver_the_new directory. The ls command shows that our byte count increasing:
 

When a restore is done, using this new directory, oranges, you will see the flat.vmdk, .vmdk, and .vmx files listed:

 
Logging at the end of a restore looks something like this:
 

What's Next?

> File-Level Restore