BE2010 VMware Agent - SAN Transport Not Working

[Itchy92]

Hi all,
   I've been beating my head against a wall the last couple days trying to figure this out.

   I just rebuilt my BE2010 server from Windows 2003 to 2008R2. In the process, I decided to consolidate my VMDK backups into BE, rather than using VMDR. The test job completed successfully using the NBD transport, and got about 1GB/min. Not bad, but I've read that the SAN transport is substantially faster, and has less overhead on the host servers. So I looked through the BE Administrator's Guide... and the Symantec forums... and the VMware forums... and every random blog I came across... and could not find any solid info on getting this configured.

  Based on the bits and pieces I was able to gather, I used diskpart to disable automount (and to scrub the automount cache, just in case), attached my media server to my SAN via iSCSI, and confirmed that the VMFS LUNs showed up in Disk Management ("online", but no drive letter, and I didn't have to initialize them or anything). But every time I try to run a job with only the SAN transport selected, I get the following error within a few seconds.

	Backup- VMVCB::\\VCENTER-01.domain.local\VCGuestVm\Datacenter01\vm\Infrastructure VMs\VM-W8-DC01 V-79-57344-38277 - Unable to open a disk of the virtual machine.

VixDiskLib_Open() reported the error: You do not have access rights to this file

  Similarly, this error brings up very little useful info anywhere. I tried selecting the VM directly through one of the ESX hosts (using the root account) rather than through vCenter, with the same result.

   One post I found in these forums regarding this suggested that someone with a similar issue rebuilt his media server on 2003, and it started working. I'd *really* rather not re-rebuild this server just to confirm, so I was hoping someone here could shed some light on the error.

   Thanks in advance for any ideas or suggestions!

Aaron Firouz

[teiva-boy]

You are on the right track thus far...  diskpart to turn off automount.  Then in the disk manager, you should see an unknown volume, this is normal.  Make sure NO ONE EVER TOUCHES THAT with windows.

You've set the backup transport to SAN, or at least to the top of the list, BE2010 will just try till the next one works.

From there, you need to make sure you have the appropriate rights to perform the backup operation.  This is something that I believe is granted from within vCenter to the specific user account.  Unless you are using 'root'?  I think that account has it all, but you may want to make sure.

[Itchy92]

teiva-boy,
   Thanks for the reply. Unfortunately, that's exactly where I'm stuck. The account I'm using is already a member of the "Administrators" role in vCenter, so it should have all the necessary rights to access the file; I can log in using the vSphere client and perform all management tasks with the account. As I mentioned, I tried connecting directly to one of the ESX servers as root, but I still got the same error.

Despite the error message alluding to permissions, I still suspect that the issue is with the Media Server not recognizing the LUNs properly. I was able to do the backup using NBD, so I think it must be specific to the SAN transport. But again, that's about all I've got to go on.

   Thanks again for your reply, and for at least validating the setup process.

[JBird006]

Itchy92,

I am having the same issue and I suspect that it has to do with Server 2008R2.  My storage is an IBM DS3300.  I have the same storage at another location but my VCB proxy is installed on Server 2008X64 with Backup Exec 12.5 at that location.  The system I am having this issue with is Backup Exec 2010 (same DS3300 for storage) and Server 2008R2.  When I go into storage manager on the 2008R2 box it constantly asks me if I want to make the storage partition a mbr or guid partition.  The 2k8 box (nonR2) does not do this.  the storage shows as unknown, not initialized, and unallocated.  That should be fine according to some documentation I have read. 

Basically, the documentation from Symantec totally blows when it comes to this process.  Everyone wants a clear cut answer on this process and no one has it!  WIth so much at stake with the lun, and Windows desperately trying to screw up the lun, I wish some clear cut documentation existed. 

If anyone has experience with SAN transport mode and server 2008 R2 with iscsi....PLEASE HELP!!!!


PS.  the enivronment that works for me uses VMware 3.5 (Backup Exec 12.5)....the one that does not is VMware 4.0 update 1 (Backup Exec 2010).


 

[Itchy92]

JBird,
   Thanks for your insight, and sorry for the delay in my response. It is starting to seem more and more like this is an issue with the way 2008R2 addresses iSCSI storage, and the way that BE tries to identify the LUN disk signatures.

   Unfortunately, I have made no additional progress on this. I may have to bite the bullet and call Symantec Support. I will post back with any information that I get on the topic.

[teiva-boy]

VCB is not supported on anything but Win2k3 SP2.  This is a Vmware thing, not Symantec.

The fact that Win2k8 is asking to write a disk signature, means you are doing something wrong with not turning off automount or the like with Win2k8.

Basically if you have 12.5 and need to use VCB, you need to have your VCB proxy server on Win2k3 SP2.

If you go to BE2010, and at least 3.5U2, you can get rid of WIn2k3 and VCB altogether, and use vStorage which is better anyways.  Not to mention Vmware has ceased any future development of VCB going forward for about 3+ months now.

[YvieD]

Did you contact support regarding this issue?  I would like to share two simple checks that have been resolving many cases reporting

	Backup- VMVCB::\\VCENTER-01.domain.local\VCGuestVm\Datacenter01\vm\Infrastructure VMs\VM-W8-DC01 V-79-57344-38277 - Unable to open a disk of the virtual machine.

VixDiskLib_Open() reported the error: You do not have access rights to this file

 If you watch the byte count during the job, it should get to just over 20,100 bytes and report "snapshot processing" for a few minutes before failing. What seems to be happening is that Backup Exec can not mount the snapshot because it fails authentication or the media server  (where Backup Exec is installed) can't access the ESX host in the way that the VSphere server has it labled.

1. Create a new user account and give it administrator rights in vCenter or the ESX host and attempt the backup again using the new user account.  Ensure that the password does not include special characters such as & or @.

If this is changed and the same results are experienced

2. Determine exactly how VSphere is listing the ESX hosts in Host View. From the media server ping that exact name.  If you can't reach it, create a host file on the media server with the IP Adress and the exact host name of each ESX host.
 

[PetELong]

Here's How I fixed mine.

V-79-57344-38277 - Unable to open a disk of the virtual machine

PeteNetLive

[Jim_S]

I've got an odd issue where all of my VMs except 1 back up using the SAN transport method.  The other VM requires NDB in order to back up.  I'm using 2010R2 and vSphere 4.1, hardware level 7 on an iSCSI SAN.  The VM that only works with NDB has the same permissions and is generally configured the same as the other VMs as far as I can tell.

Any idea where to look if only 1 VM won't back up with SAN but 24 other ones will?

[ZeRoC00L]

Jim,

Are all your Vm's located on one LUN/Volume or do you have multiple LUNs/Volumes??

What is the exact error message you receive ?

[Jim_S]

I have multiple LUNs/Datastores, but the VM in question is located on a VMFS volume that has other VMs that back up just fine using the SAN transport.

Error message when I enable only SAN transport and disable NDB:

 V-79-57344-38283 - The selected transport mode is unsupported by the current setup.


VixDiskLib_Open():  Transport mode 'ndb' used for opening the disk.

The link points to a bunch of stuff about backing up templates, but this is not a template, nor has it ever been.  The other error page it links to is an acknowledgement by Symantec that their program is broken, but they don't really have any plans to fix it unless you call Symantec Sales and tell them you're pissed off. :)

[SAA_Verzekering]

I'm experiencing the exact same issue. We have about 20 VM's and three of them fail with the error:

Backup- VMVCB::\\SAA-VC01\VCGuestVm\(DC)SAA Rotterdam(DC)\vm\SAA10
V-79-57344-38283 - The selected transport mode is unsupported by the current setup.

VixDiskLib_Open(): Transport mode 'nbd' used for opening the disk.
  

This ofcourse only occurs when I try to force the SAN transport option by disabling the other options.

[Colin_Weaver]

Symantec are investigating some problems with this symptom, as such please confirm

1) What Languages your media servers are installed in

2) Whether your media server is also your vCenter Server

3) Whether your media server is a physical machine or a virtual machine

Thanks

Colin

[tbuchholz]

Hello.

I  have the exact same issue. We have 41 VM's and two of them fail with the error:

Backup- VMVCB::\\SAA-VC01\VCGuestVm\(DC)SAA Rotterdam(DC)\vm\SAA10
V-79-57344-38283 - The selected transport mode is unsupported by the current setup.

VixDiskLib_Open(): Transport mode 'nbd' used for opening the disk.
  

In the Backup Job I force the SAN transport option by disabling the other options.

 Is there any solution?

The answers for Colins Questions:

1) Media Server  Languages = German

2) No, Media Server and VMware vCenter are seperate Machines

3) Our Media Server is a physical Maschine.

[ZeRoC00L]

It seems to be a known issue:

http://www.symantec.com/business/support/index?page=content&id=TECH141218&actp=search&viewlocale=en_...

You can try to contact Symantec Support about the status of this issue.

[Colin_Weaver]

Where this is a French customer, the problem appeas to be caused by the accented é character that is used to define LocalSystem (LocalSystemé) against the startup of the BE Remote service. It appears that the vStorage API tries to create a tempfolder during the backup based on this user and because it cannot handle the accent it get an access denied message against the folder creation/use and fails. We are currently investigating this in consultation with VMware.

At this current time we have not specifically identified another languuage that might have a problem with an accent in the LocalSystem account - however should you have this issue and be using a server that is not configured in English - please check the characters used to define "Local System" for that language and let us know if there are any accented or non-English characters present.