Hello from Veeam Support!
Veeam Support Team is excited to announce a brand-new way of sharing useful and important information with you. We have prepared a series of advanced-level tech articles based on real support cases. We hope you will like these articles as much as we like to help our customers.
Issue of the week: Linux FLR appliance deploy failed
Linux FLR appliance deploy failed: Module ‘MonitorLoop’ power on failed.
Identifying the issue: Houston, we have a problem
First of all, we need to identify the issue. The main trick is that it hits during a very special phase of OtherOS FLR — only deployment of the appliance is affected. The error happens right when we attempt to mount a restore point to FLR appliance. In the GUI, the error looks like this:
Fig 1. Error in UI
We can see the failed module ‘MonitorLoop’ in the log for the relevant FLR session (the name looks like “year_month_day_hour_minute_second.log”):
[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)
Keep in mind that the FLR appliance is deployed by the mount service, which also logs similar issue in Svc.VeeamMount log. However, it doesn’t show us the failing module:
[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])
Solving the issue: Resources are key
If we dig deeper, we notice that according to the VMware KB article, Module ‘MonitorLoop’ controls resources assigned to VMs. The error itself is thrown by VMkernel and can be traced in the relevant VMkernel log:
Fig 2. VMware log
The root cause of our issue is that ESXi host doesn’t have enough resources to start the appliance, and naturally FLR fails. Without scanning through VMkernel logs, we cannot directly point which of the resources are missing, but we can easily estimate that.
This is either CPU/RAM available for VMs on the hosts, or free space for swap file storage. The latter is much more plausible, so if vSphere environment does not face obvious lack of CPU/RAM — the issues narrows down to lack of free space for storing FLR appliance and its swap file. To find out what is happening and fix it, run the FLR restore and double-check that FLR appliance configuration meets following criteria.
Fig 3. Configuration setup
The selected Host should have enough CPU/RAM to store the appliance. Their consumption will usually be really low, so normally something more than 0 Mb of RAM and at least some CPU will do to start the FLR appliance. If needed, change Host to the one which has enough resources.
By default, Veeam stores swap file of our appliance in the NFS datastore which is just a Windows folder on the mount server. However, that is not always the case. On the picture below, you see the location of the setting which regulates where swap file is stored by default. Sometimes you may want to store it not in the VM directory, but on a specific datastore. That datastore may be full, so deployment of the FLR appliance — as well as new VMs — just fails. Check that it’s not your case.
Fig 4. Host configuration
The similar issue may hit the appliance during SureBackup as well, as it’s related to the allocation of the resources.
Did you know?
All detailed information about Veeam products is provided in the help section. If you click F1 in any product window, you will be taken to the online Help Center.
Clicking F1 when working with any wizard or dialog window (including the main window) will bring up the corresponding topic of the online Help Center, opened with your default internet browser.
Fig 5. Help window
In our next series
In our next series, we are going to cover the most common misconfigurations and issues we see in Veeam Support every day. Join our investigation trip and stay tuned!