cancel
Showing results for 
Search instead for 
Did you mean: 

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

Rastorak
Level 3

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 ?

9 REPLIES 9

Gurvinder
Moderator
Moderator
Employee Accredited Certified

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

Rastorak
Level 3

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

Best regrads

pkh
Moderator
Moderator
   VIP    Certified

See this

https://www-secure.symantec.com/connect/forums/vsphere-51-support-update

There is no announcement as to when ESX 5.1 will be supported.

nick1595
Not applicable

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

jelutz
Level 3

I'm experiencing this also, with vSphere 5.0.

daames
Level 3
Partner

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

Colin_Weaver
Moderator
Moderator
Employee Accredited Certified

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
Level 3

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
Moderator
Moderator
Employee Accredited Certified

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.