I updated my ESX4 to update2 and now, the image-level backup doesn't work !
When I backup a VM, I can see a "reconfigure" of my VM in Virtual Center, and after nothing ! no snapshot...
The Avamar activity show a "Time Out Response !"
Before, in ESX4 Update 1, the backups were almost OK (sometimes, I had locked vmx, but it worked better).
Somebody who has an idea ???
The Avamar VMware image level backup fails with the following error message in the backup client session log:
avvcbimage Error <0000>: vmx file is suspiciously small (under 30 bytes), please examine the log on the Avamar Administrator for root cause analysis
High Level Cause:
The high level cause for why this message is reported is that the .vmx file was not able to be backed up.
Four Possible Root Causes:
There are 4 different possible root causes for why the .vmx file was not able to be backed up. It is important to examine the system to determine which of these 4 possible root causes might be applicable:
Possible Root Cause #1: Failed to get VMware vCenter connection
One possible reason why the .vmx file did not get backed up is because the Avamar Administrator Server (also known as the Management Console Server, or MCS) was not able to connect to the VMware vCenter server to coordinate the backup of the .vmx file.
In v184.108.40.206xx, the MCS requests that vCenter allocate a pool of 3 connections for its use. These connections are required for short periods of time at various points throughout the image level backup for each backup proxy server, for example, to create the snapshot, to initiate the backup, to delete the snapshot, etc. If the Avamar system is performing image level backups concurrently through multiple different backup proxy servers, it's possible that 3 connections might not be adequate.
There is a hard limit on the number of available connections to a vCenter. The limit is 15 if the vCenter is running on a 32 bit Windows OS and 30 if running on a 64 bit OS. Instances of the standard VMware vSphere Client GUI consume connections from this limited pool so Avamar consumption of connections is subject to interaction with customer usage patterns. Source: http://www.vmware.com/pdf/vsphere4/r40/vsp_40_config_max.pdf
The symptom of this issue is that the following message will be reported in the /usr/local/avamar/var/mc/server_log/mcserver.log.* files on the Avamar grid's utility node:
WARNING: FAILED TO GET VC CONNECTION
a) In v220.127.116.11xx, the workaround is to increase the "connection_pool_size" parameter in the /usr/local/avamar/var/mc/server_data/prefs/mcserver.xml file on the Avamar grid's utility node. We recommend increasing this value from the default of 3 to 5.
The trade-off of making this value too large is that this consumes connections that might be required by other systems that connect to the vCenter server. Therefore, do not increase this value beyond 5 unless you know that the value needs to be increased.
b) In the upcoming v5.0 SP1 release, the default value will be set to 5 connections. If the MCS runs into an issue where it fails to get a vCenter connection, then the MCS will automatically request additional connections, as required.
Possible Root Cause #2: Unable to retrieve .vmx file because "Datacenters" is not at root level of vCenter node.
Even if the MCS was able to connect to the vCenter server, then the reason why the .vmx file might not get backed up is because of either or both of the following possible issues:
a) If the Datacenter where the .vmx file is located is not at the root vCenter folder, then the .vmx file will not get backed up. This is described in Avamar bug 17366. The issue is that the v18.104.22.168xx version of the Avamar software assumes that the Datacenter is located directly at the root level of the vCenter node.
b) If the root folder internal name, as shown in the vCenter Managed Object Browser, is not "Datacenters", then the .vmx file will not get backed up. This is described in Avamar bug 17591. This issue could also be caused if, for example, the Datacenter name is not in English but is in another language.
a) In v22.214.171.124xx, the workaround is to apply hotfix 17760 to both the MCS and the MC client.
b) Upgrade the Avamar grid to the upcoming v5.0 SP1 release.
Possible Root Cause #3: Unable to retrieve .vmx file because of special characters in datastore, folder, and/or datacenter names
Another possible cause for why Avamar is unable to retrieve the .vmx file for backup is because there might be "special characters" in the datastore, folder, and/or datacenter names. This is a limitation of the vCenter server, and is tracked by VMware under VMware Support Request SR# 1483856391. This issue is also being tracked under Avamar bug 17608.
The following is a list of the "special characters" (in the format of "character"/"escape sequence" format) that will cause the .vmx file to fail to be backed up:
a) The workaround is to rename the datastore, folder, and/or datacenter names to avoid the use of these special characters.
b) The solution is to apply a fix from VMware when it is available.
Possible Root Cause #4: Unable to retrieve .vmx file because the ESX server has an exclusive lock on the file
In ESX 4.0, the ESX server maintains an exclusive lock on the .vmx and nvram files. Therefore, if the vCenter attempts to use another ESX server (other than the one that has the exclusive lock on the file) to back up the files, the other ESX server will not be able to read the .vmx and nvram files to back them up. Because of the algorithm used by vCenter to select the ESX server that is used to attempt to read the .vmx and nvram files, the probability of encountering this issue increases as the number of ESX servers managed by vCenter increases.
This issue is tracked by VMware under VMware Support Request SR# 1483856391. This issue is also being tracked under Avamar bug 17608.
a) The workaround is pass the following option into the avvcbimage plugin: --x22=8192. This can be passed in through the dataset by setting:
Value : 8192
Alternatively, you can create an avvcbimage.cmd file in the Avamar var directory on the client that contains one line:
This allows the backup to complete even if the vmx file (that contains the VM configuration) is not backed up.
Because the VM configuration information is NOT backed up (if the .vmx file is 0 bytes), the following will apply during the restore process: The restore for this backup will work for restore to original and restore to existing, but not for restore to new. To do restore to new, you need to manually create a VM with the same configuration as the original VM, and do restore to existing to the newly created VM.
Be advised that restore to a manually created VM will issue new virtual NIC MAC addresses and new virtual disk serial numbers which may cause license activation issues with VMs running Windows.
b) The solution is to apply a fix from VMware when it is available, and to upgrade the Avamar grid to v5.0 SP1. Avamar v5.0 SP1 has been modified to include retries for retrieving the vmx file, which will be required to accommodate the upcoming fix from VMware.
Resolved all problems with this configuration:
Update all for:
VMWare vSphere 4 Update 2 (build 258672)
Avamar Server 126.96.36.199
Avamar VM Proxy 5.0.105-169 (Included with SP2 on the Grid)
Hello, i have problem too :
2014-01-31 08:38:43 avvcbimage Error <12016>: vmx file is suspiciously small (under 30 bytes), please examine the log on the Avamar Administrator for root cause analysis (Log #2)
2014-01-31 08:38:43 avvcbimage Error <9760>: Backup of VM metadata failed. (Log #2)
2014-01-31 08:38:47 avvcbimage Error <9768>: Avtar exited with 'code 163: externally cancelled' (Log #2)
If I use parameter x22=8192 don't work too.
Avamar Administrator 6.1.2-47
Avamar Combined Proxy-linux-sles11_64-6.1.102-47
This issue may occur from different causes. Adding parameter x22=8192 may resolve issue if this issue is caused by Possible Root Cause #4: Unable to retrieve .vmx file because the ESX server has an exclusive lock on the file as mentioned in earlier posts here.
I would suggest you to please open a SR with EMC support to get this issue resolved.