Video Screencast Help
Scheduled Maintenance: Symantec Connect is scheduled to be down Saturday, April 19 from 10am to 2pm Pacific Standard Time (GMT: 5pm to 9pm) for server migration and upgrade.
Please accept our apologies in advance for any inconvenience this might cause.

Backup Exec 2012 & AVVI : "Solution is not responding" from vCenter Alert Log

Created: 15 Jan 2013 | 9 comments

Hi everybody,

I have an Vcenter 5.1B up to date, on a windows 2008 R2 up to date, one esxi 5.1 hosts up to date, the 2 virtuals machines x and y have the last vmware tools.

I receive an error on the vCenter log :

Symantec backup <virtual machine x> A general system error occurred: solution is not responding

This error occure when I start the backup jobs for 2th virtual machine y. On the vCenter log, a normal message appear after the snapshot message :

Symantec backup xx%

The two backups works fine, the snapshots are removed correctly.

Any idea ?

Comments 9 CommentsJump to latest comment

Gurvinder Rait's picture

Is that ESX 5.1 or ESX 5 Update 1. If it is ESX 5.1 , then BE 2012 doesnt support it currently

nick1595's picture

Completely unacceptable that I cannot move forward with Server 2012 or update my VMWare environment because of this crippled backup solution.  

Rastorak's picture

Thank you for the response. Do you know when BE 2012 support the vSphere 5.1 ?

Best regrads

daames's picture

Another bug... Add it to the long list. Is there any developer in Backup Exec Team?

Colin Weaver's picture

Have you all left SAN Transport enabled when you do not have a SAN configuration?

Check the transport settings in the VMware section of the job configuration.

If you do not have a SAN that hold the VMFS datastores and is connected ESX Host and Backup Exec Media Server then disable SAN Transport  and use NBD.

 

Other than this please if on ESX 5.0 then please log a formal support case. If on ESX 5.1 then wait for the Service Pack that supports 5.1 (or register for the Beta) and then confirm if the issue still occurs (and then log a formal case if it does)

 

jelutz's picture

I'm no longer using this configuration, as I needed the backups to succeed, so support can not help me. I changed back to the VM Host configuration I was using before.

We use an iSCSI SAN, and I had SAN transport enabled. Does this option require SAN access to the datastores from the vCenter server or something?

IMO, I think that if there is transport directly from the SAN, it would require the media server to access the datastores. I assume that since this is not the case, that it is handled from the backup target, but this is where the vCenter gets confusing; is it backing up from the VM Host or vCenter server itself?

Colin Weaver's picture

The basic way SAN Transport works is:

1) Backup Exec requests that VMware make snapshot on the SAN (the request is made over the network port/LAN)

2) VMware makes the snapshot and then passes details of where the Snapshot is back to Backup Exec (again this communication is still over the LAN)

3) Backup Exec uses the snapshot information (and some VMware supplied program code) to directly attach to the snapshot from the media server (this would be over the SAN  and means the media server MUST have a SAN connection, over iSCSI or Fiber Channel as appropriate)

4) If the snapshot cannot be mounted over the SAN then an error is gerenated and Backup Exec will retry accessing the snapshot over the remaining active prototocls in the Job Configuration (which by default would probably end up with NDB and do the backup over the LAN.)

 

Comments:

Step 3 above does show that you cannot use SAN Transport unless the media server is connected to the SAN (specifically LUN that holds the datastore containing the snapshot)

Step 4 is usually a hidden error passed back to Backup Exec and only becomes a job log error if none of the available transports work. However just because it is a hidden error in Backup Exec, does not mean that the vCenter might not record something regarding the access request being made and failing, although I am guessing at this point, I am not sure if a failure of SAN Transport (with fallback to NBD) could cause the original error condition reported in this thread.

I am not aware that the vCenter ever needs direct access to the SAN holding the datastores, but the ESX Host and the media seerver do for SAN Transport to work.