Hi, today’s the Veeam Support Team support team. We have already told Habr readers about the fantastic creatures of various clients and where they live, and about what and how our department does .

And in the new season we decided to start publishing technical posts with the analysis of real cases that users contact us with. I want to believe that these materials will help someone to understand the intricacies of working with our product without a call to the support - and we use the time saved in this way to write useful new articles.

So, today we are sorting out the case "The problem with file-level recovery is an error when deploying a Linux FLR appliance," which has become one of the most popular in the past months.
')

Essence of the question

During normal operation, to restore the guest OS files (not Windows) to the backup virtual machine, the mount of the disks of this backup machine to the auxiliary Linux VM (Linux FLR appliance) is performed. After that, you can view the contents of the file system using the Veeam Backup Browser, select the necessary files and restore them to the desired location. For more information, see here (in English. Language) or here (in Russian).

The secondary VM is temporarily deployed on an ESXi host solely for the purpose of supporting recovery, and then removed. However, when deploying it in the Veeam Backup & Replication console, you may receive an error message like this: “Linux FLR appliance deploy failed: Module 'MonitorLoop' power on failed.”

How to understand that something went wrong

The caveat is that the problem occurs at a rather specific stage - only when restoring guest OS files other than Windows, and specifically when deploying an auxiliary VM.

The error message looks like this in the console:


We see that the problem is with the MonitorLoop module. This is also indicated by the log of the corresponding session of the FLR-recovery, which is stored in a file with the name of the form year_month_day_hour_minute_second.log . In it we find the following entries:

[05/07/2017 17:16:49] <06> Info Mounting restore point. VM: [fileserver], BackupDate: [09/01/2017 18:31:12], Oib: [aa6038d3-bf68-42d6-86c0-de3a48784066]
[05/07/2017 17:17:49] <06> Error Failed to mount oib "aa6038d3-bf68-42d6-86c0-de3a48784066"
[05/07/2017 17:17:49] <06> Error Linux FLR appliance deploy failed: Module 'MonitorLoop' power on failed. (Veeam.Backup.Common.CAppException)

In addition, since the VeeamMountSvc mount service is responsible for deploying an auxiliary VM (FLR appliance), a similar entry will be made in its Svc.VeeamMount log (though the problem module will not appear in it):

[05/07/2017 17:16:49] <23> Error Recreating WCF proxy ...
[05/07/2017 17:16:49] <23> Error Linux FLR appliance deploy failed (System.ServiceModel.FaultException`1 [Veeam.Backup.Interaction.MountService.CRemoteInvokeExceptionInfo])

"Who is guilty?"

Continuing our investigation, we find out that there is an VMware KB article , from which it is clear that the MonitorLoop module controls the resources allocated to the virtual machine. Specifically, our error is generated by VMkernel, and it can be detected in the VMkernel log:



The root cause is the fact that the ESXi host does not have enough resources to run the secondary VM. Naturally, the process of restoring files without it will fail. To find out what is missing, you can delve into the analysis of VMkernel logs, and you can estimate the necessary resources based on common sense. And he claims that critical resources are, most likely, CPU and RAM, available for VM operation on this host, as well as free space for storing the paging file. The lack of the latter is quite common, so if you are sure that the resources of the RAM and the processor are OK, then the cause of the error is almost certainly the lack of space for storing the auxiliary VM files and its paging file.

"What to do?"

In order to understand exactly what needs to be corrected, run the File-Level Restore Restore Wizard and go to the settings of the auxiliary VM (FLR Helper Appliance).



Here for the host specified in the Host field, you need to check two things:

1. Does the host have enough memory and CPU resources to run the VM? The auxiliary machine consumes a minimum of these resources, so the main thing is that they are available at the time of its deployment. If necessary, select another host where these resources are guaranteed to be available.
2. By default, Veeam saves the paging file of the secondary VM to the storage specified as the NFS datastore - this is a regular Windows folder on the mount server (mount server). However, this is not always the case.
   
   The picture below shows the ESXi host configuration, which is responsible for the default storage location for the paging files of virtual machines: host → Configuration → Virtual Machines → Swap File Location .
   
   
   
   There is a possibility that the default setting - Virtual machine directory (stored in the VM directory) - has been changed, and the storage area specified for this purpose has run out. As a result, it is impossible to deploy new VMs, including auxiliary ones. Check if this is your case.
   

A similar error can occur with an auxiliary VM during SureBackup - the cause is still the same lack of resources.

Bonus track

Do you know that you can always read about the work of Veeam products in the online help, which is opened by pressing the F1 key from any dialog in the product console, including the main window?

This also applies to the steps of various wizards of settings - press F1 at any step of the wizard, and the corresponding paragraph of documentation opens in your online browser in the online Help Center.

Profit!



We are going to continue to spread the analysis of popular cases from among those that come to us in support. Your wishes can be expressed in the comments. See you again!

Links to today's post:

• The document "Basic scenarios of using Veeam Backup & Replication 9.5" in Russian
• Description of the process of restoring guest OS files (FLR)
• VMware Knowledge Base Article