Skip to main content
Start a Conversation

Unsolved

This post is more than 5 years old

caii-marcosa

8 Posts

36509

March 29th, 2010 13:00

vmware image backups failing - error code 10013

I'm trying to get the VMware image backups working...

And in fact, if I shut down the VM I'm trying to back up, it works just fine.

However, if the VM is running, I get errors in vSphere saying it's unable access vmname/vmname.vmx... and also vmname/vmname.nvram

Then it fails. The Activity log in the avamar administrator shows "Cancelled" and "10013" as the error code.

I tried manually copying this file to another location on the same datastore using the vSphere client, and it also fails with the same error (in vSphere)... "unable to access file..."

If I manually snapshot a VM using the vSphere client, the snapshot works just fine.

Any help on this would be appreciated.

caii-marcosa

8 Posts

March 29th, 2010 15:00

Just to provide some more info...

Avamar version 5.0.0.410

ESX version 4.0.0, 236512 (8 hosts, in a cluster doing DRS)

Log of failure:

--------------------------------------------------------------------------------------------------------

----- START avvcbimage log 2010-03-29 14:49:12 EDT  [5.0.100-409 Linux-i686]
--------------------------------------------------------------------------------------------------------

2010-03-29 14:49:12 avvcbimage Info <5241>: Logging to /usr/local/avamar/var/MOD-1269888518992-a5c2af6a74e913a88014f83172b2e9dd912a67a8-3016-vmimage.log
2010-03-29 14:49:12 avvcbimage Info <5174>: - Reading /usr/local/avamar/var/avvcbimage.cmd
2010-03-29 14:49:12 avvcbimage Info <6636>: CTL listening on port 59487
2010-03-29 14:49:12 avvcbimage Info <5174>: - Reading /usr/local/avamar/var/avvcbimage.cmd
2010-03-29 14:49:12 avvcbimage Info <7045>: target[0]=[satastore-3] Test2/Test2.vmdk
2010-03-29 14:49:12 avvcbimage Info <9642>: a VM snapshot has been requested
2010-03-29 14:49:17 avvcbimage Info <9645>: Requesting create snapshot progress from MC: query #1.
2010-03-29 14:49:18 avvcbimage Info <9649>: Create snapshot succeeded on cycle #1.
2010-03-29 14:49:18 avvcbimage Info <9650>: snapshot moref is snapshot-284
2010-03-29 14:49:18 avvcbimage Info <9651>: create snapshot succeeded: moref='snapshot-284' : query count=1 : vmInfo='
 
   
 

'
2010-03-29 14:49:18 avvcbimage Info <0000>: VixDiskLib: config options: libdir '/usr/lib/vmware', tmpDir '/tmp/vmware-root'.

2010-03-29 14:49:20 avvcbimage Info <0000>: VixDiskLib: Advanced transport plugin was successfully loaded into vixDiskLib. Accelerated transport modes available.

2010-03-29 14:49:20 avvcbimage Info <0000>: VixDiskLib: Enabling advanced transport modes.

2010-03-29 14:49:20 avvcbimage Info <0000>: VMware VixDiskLib (1.1) Release build-163495

2010-03-29 14:49:20 avvcbimage Info <0000>: System libcrypto.so.0.9.8 library is older than our library (90802F < 90807F)

2010-03-29 14:49:20 avvcbimage Info <0000>: System libcrypto.so.6 library is older than our library (90802F < 90807F)

2010-03-29 14:49:20 avvcbimage Info <9616>: Available transport modes are file:san:hotadd:nbdssl:nbd
2010-03-29 14:49:20 avvcbimage Info <9617>: Calling ConnectEx with servername=creative51.caii-dc.com vmxspec=moref=vm-242 on port 0 snapshot(snapshot-284)
2010-03-29 14:49:20 avvcbimage Info <9618>: virtual machine will be connected readonly
2010-03-29 14:49:20 avvcbimage Info <0000>: UUID: SMBIOS UUID is reported as '42 09 8c 2c 27 5b 8c 0c-29 05 86 f1 cb 90 c0 32'.

2010-03-29 14:49:20 avvcbimage Info <9619>: VixDiskLib_ConnectEx returned VIX_OK
2010-03-29 14:49:20 avvcbimage Info <9654>: spawnp->get_stdio_fd(0) on avtar with pipe #97 on start
2010-03-29 14:49:20 avvcbimage Info <7213>: Generating PAX stream blocksize 512 to path ""
2010-03-29 14:49:20 avvcbimage Info <9656>: Adding file 'avamar vm configuration.xml' (1284 bytes)
2010-03-29 14:49:20 avvcbimage Info <9656>: Adding file 'snapshot description.xml' (441 bytes)
2010-03-29 14:49:20 avvcbimage Info <9656>: Adding file 'vm.ovf' (55 bytes)
2010-03-29 14:49:20 avvcbimage Info <9656>: Adding file 'vm.vmx' (0 bytes)
2010-03-29 14:49:20 avvcbimage Error <0000>: vmx file  is suspiciously small (under 30 bytes), please examine the log on the Avamar Administrator for root cause analysis
2010-03-29 14:49:20 avvcbimage Error <9710>: Backup of VM metadata failed.
2010-03-29 14:49:20 avvcbimage Info <9713>: snapshot created:true NOMC:false ChangeBlTrackingAvail:false UsingChBl:true
2010-03-29 14:49:20 avvcbimage Info <6649>: Process 6434 (/usr/local/avamar/bin/avtar) for workorder MOD-1269888518992 started
2010-03-29 14:49:20 avvcbimage Info <9622>: Disconnected from VM
2010-03-29 14:49:20 avvcbimage Info <8651>: Closing pax stream
2010-03-29 14:49:20 avvcbimage Info <9652>: Requesting snapshot (Avamar-1269888552a5c2af6a74e913a88014f83172b2e9dd912a67a8) removal
2010-03-29 14:49:20 avvcbimage Info <6651>: Process 6434 (/usr/local/avamar/bin/avtar) finished (code 163: Externally cancelled)
2010-03-29 14:49:20 avvcbimage Warning <6653>: CTL workorder "MOD-1269888518992" non-zero exit status 'code 163: Externally cancelled'
2010-03-29 14:49:22 avvcbimage Error <9718>: Avtar exited with 'code 163: Externally cancelled'
2010-03-29 14:49:22 avvcbimage Info <9722>: process_ctl_man_exit detected avtar termination
2010-03-29 14:49:22 avvcbimage Info <9723>: Final summary, cancelled/aborted 0, snapview 0, exitcode 0

--------------------------------------------------------------------------------------------------------
----- END avvcbimage log 2010-03-29 14:49:27 EDT  (1 warning, 3 errors, 0 fatal errors)
--------------------------------------------------------------------------------------------------------

mrozoo

16 Posts

March 30th, 2010 01:00

Hi,

its not recomended to take backup of running VM, state of operating system installed on VM  is reflected in files which you try to copy.

Since VM is running files constantly changing  its not make sense to copy them.

hope this clarify little bit,

Tomasz

caii-marcosa

8 Posts

March 30th, 2010 07:00

Two things.

1)  I thought we were supposed to be able to do this (backup a running VM).... it implies this in the manual where it says it will use a snapshot if the VM is powered on.  Is this incorrect?

2)  So snapshots do not overcome this problem?  I thought that was basically the same theory behind VSS, and the "snapshot" systems of yesterday (backup exec open file option, etc.)... that is, it "snapshots" the VM in a particular moment in time, and therefore, this is restorable. But I suppose this isn't actually the case, either?

caii-marcosa

8 Posts

March 30th, 2010 14:00

I ended up opening a support ticket with EMC...

It seems this is a problem on VMware's end, and they do not have a fix as of yet.  However, there is a workaround.  The workaround is a setting that causes the Avamar to ignore those files, and backup the VM without them.  This means you cannot restore from nothing, but must instead restore to an existing VM (which makes sense, given the files that it can't get).

I tested it, and it does work.

The solution is simply to add the following option in the dataset:

--x22 = 8192

Of course, it would be nice if the solution worked as intended, but this will do for now... I just wanted to share here to save people time on it...

Anonymous

5 Practitioner

 • 

274.2K Posts

April 9th, 2010 11:00

My customer is having similar issues:

and indicated the following: "when I try to go to do a full restore to a new machine at our DR site, I get `Invalid datastore for Disk xx¿ or on others it tells me that it cannot restore the backup because the vmx file is missing.  This is what I was trying to reiterate yesterday is that if you watch vcenter when the jobs are running, it errors when trying to copy the nvram and vmx files on each of the servers.

Any backups with multiple disks are failing with ¿Invalid datastore for disk xx.¿

The ones that are failing due to the missing vmx file error with 30933 ¿You cannot perform a restore to a new virtual machine if the .vmx file is missing from the backup.¿"

Any additional feedback on how to fix this particulare problem.

OscarG1

2 Intern

 • 

137 Posts

April 12th, 2010 20:00

One of my costumers has the same issue, the workaround works good for the backup, you cant do a restore from zero, you need to create a virtual machine with the same numbers of disks, and same size, then you can do the restore to the vm you already create, you dont have to have any snapshot cause the restore is gonna fail.

Does someone opened a ticket with vmware???

rpervan

266 Posts

April 13th, 2010 00:00

Hi to all,

As far as I can see you are running Avamar version 5.0.0.410 .

I would agree a number of issues are resolved with the newer version Avamar 5.0.1 build 32,  and I recommend an upgrade.

Actually it is recommended but not required for all previous installations of Avamar v5.0 to be upgraded to this release.

ftp://avamar_ftp:anonymous@ftp.avamar.com/software/5.0.1/v5.0.1.32-customer_unified.tar.gz

regards,

.R

infra12341

7 Posts

April 15th, 2010 02:00

Are there any release notes on the 5.0.1 build 32 release specifically? Is it just an upgrade to the avamar proxy or is it a full upgrade to the Avamar nodes themselves?

Thanks,

markaldridge

9 Posts

April 16th, 2010 02:00

Interestingly if the VM is on local storage it works fine, but if on ISCSI lun it fails.????

markaldridge

9 Posts

April 16th, 2010 02:00

can someone confirm that this is a fix for this issue?

rpervan

266 Posts

April 16th, 2010 03:00

Hello infra1234 / markaldridge,

You can download release notes directly from powerlink.
I could not reproduce this issue with 5.0.1 build 32 when MCS-to-vCenter Authentication is properly configured (Admin guide, page 456)

regards,

markaldridge

9 Posts

April 23rd, 2010 06:00

I have a customer POC that is having the issue. I have tried to replicate the error on my lab set up  but it just works perfectly in my lab, same versions of avamar and VMware release.if i cant figure this out very quickly we wont get the deal.The suggested work around is not acceptable to the customer.... I tried.Has anyone found out what the root cause of this is? I have read some info suggesting that it is datastore / name etc... but am not convinced... HELP

Avamar Exorcist

462 Posts

April 23rd, 2010 07:00

The following solution should be of help

http://solutions.emc.com/emcsolutionview.asp?id=esg111924

"Possible causes for "vmx file is suspiciously small (under 30 bytes)" error message in Avamar VMware image level backup client session log"

markaldridge

9 Posts

April 23rd, 2010 07:00

not able to view the link?

Avamar Exorcist

462 Posts

April 23rd, 2010 07:00

Symptom:
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
Description:
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 v5.0.0.4xx, 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
Symptom:
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

Workaround/Solution:
a) In v5.0.0.4xx, 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.
Description:
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 v5.0.0.4xx 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.

Workaround/Solution:
a) In v5.0.0.4xx, 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
Description:
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:
&   %26
+   %2B
/   %2F
=   %3D
?   %3F
%   %25
\   %5C
~   %7E
]   %5D

Workaround/Solution:
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
Description:
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.

Workaround/Solution:
a) The workaround is pass the following option into the avvcbimage plugin: --x22=8192.  This can be passed in through the dataset by setting:
Attribute: [avvcbimage]x22
Value    : 8192
Alternatively, you can create an avvcbimage.cmd file in the Avamar var directory on the client that contains one line:
--x22=8192

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.

View More

View All

No Events found!

Top