Re: Snapmanager for Exchange Verification fails

radnorsan · ‎2010-07-13

Hello all,

I have recently installed SME in our environment and seem to be having trouble with the Verification part of things. I'm running SME v6.0.0.706, SnapDrive v6.2.0.4519, Server 2003 R2 Enterprise x64 SP-2, and Exchange 2007 Enterprise SP-1. This is running on a VM in our vSphere 4 environment. Boot drive is on NFS. SnapDrive is attaching LUNs as RDMs using ESX iSCSI drivers. The only thing out-of-the-ordinary is that this VM was in a VMware 3.5 environment and has yet to have it virtual hardware upgraded. It's VM version 4 instead of 7. I've read some things about what drivers are necessary but I've seen it written both ways as far as SCSI drivers. Also, the Exchange server is the SME verification server.

About my issue... I can use SnapDrive to Create and mount LUNs on the Exchange server. I have two volumes right now. Vol1 has one LUN, with one storage group, with one database. Vol2 has two LUNs, one for SnapInfo and one for logs. All my paths seem to be right as I stepped through the SME configuration wizard and set everything up. The backups even seem to complete succesfully. The problem is when it tries to verify the backup, it has problems mounting the snapshot as a disk. I attached a screenshot of the error message I get most of the time.

Other times I get this error:

*****BACKUP DETAIL SUMMARY*****

Backup group set #1:

Backup SG/DB [Tech Storage Group] Error: Failed to verify physical integrity of the databases.

*****BACKUP RESULT SUMMARY*****

Backup group set #1:

Backup SG/DB [Tech Storage Group]: Backup OK, verification failed

Backup failed.[SnapDrive Error]:Failed to create disk in virtual machine, Failed to Map virtual disk: A general system error occurred: Failed to create disk: Error creating disk.

Any help would be much appreciated. Any other info that would be helpful, let me know. Thanks in advance.

ehazelden · ‎2010-07-16

Hi all,

I am having exactly the same problem with a VM running 2003 R2 SP2 32-bit and SQL server 2008 standard SP1. I am using SMSQL 5.0R1 and SnapDrive 6.2P1. This is also running in vSphere 4 and my VM is a brand new build (file system aligned), VM version 7.

I have three Luns for sysdb's, user db's and snapinfo all on individual vols as described in best practice guides as the simple setup. They are mapped as RDM's through my ESX hardware iSCSI initiators (QLA4052c's). My backup job runs absolutely fine but when it tries to attach the flexclone luns to verify the backup it fails with the same error as below...

Failed to connect to LUN in a FlexClone. Failure in connecting to the LUN.

LUN Name = salacia_db
Storage Path = /vol/sdw_cl_salacia_db_0/
Protocol Type = LUN
Storage System Name = *Removed for security purposes*

Requested Mount Point = C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint\MPDisk001\
Assigned Mount Point = C:\Program Files\NetApp\SnapManager for SQL Server\SnapMgrMountPoint\MPDisk001\

Error code : Failed to create disk in virtual machine, Failed to Map virtual disk: A general system error occurred: Failed to create disk: Error creating disk.

What is seen in vSphere is as follows after the HBA's have rescanned...(I have removed some username/machinename information for security purposes)

Reconfigure virtual machine
A general system error occurred: Failed to create disk: Error creating disk
16/07/2010 10:33:22
16/07/2010 10:33:22
16/07/2010 10:33:25

While the job is running, I have monitored the filer shell and can see that the same igroup is used to map the flexclone luns as is used already to map the original luns so there is no issue with initiator selection. After the HBA's are sent the command to rescan, new sessions are visible from the filer. It is a problem, it seems, at the vmware level where it attempts to add the disks to the VM but fails for some reason.

Any ideas?! Please help as Netapp tel support are not helping a great deal.

radnorsan · ‎2010-07-16

For what its worth, I called NetApp support. The guy I spoke with was great. He pointed out bug # 366856. The link is here http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=366856. This was exactly my issue. The resolution was simply to restart the SME service. That fixed the problem and my verifications have been working. Hope this helps.

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

EDIT:

The solution is not to simply restart the service. I have to go to the registry path HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\Scsi and under here there are subfolders named Scsi Port 0, Scsi Port 1, etc. Each of these subfolders should be expandable, meaning they have subfolders under them. If one doesn't, delete it, and then restart the service. For example, my "Scsi Port 0" has no folders under it, so I delete the folder "Scsi Port 0", then restart the SM services.

Also, this does not hold through reboots. You will need to delete this key after each reboot of the server.

ehazelden · ‎2011-04-01

Yes, I have also recently managed to get through to a useful Netapp Engineer who also pointed me to the same bug and further related bugs relating to iscsi and fc rdms being created or connected through sdw. My test rig was a vsphere 4.1u1 cluster running a server 2003 vm. With SDW 6.3 or prior, one would always get the error there are no available scsi controllers. Some of the fixes which seemed to be "temporary" included disabling the unused IDE channel on the vm as for some reason the operation to create or connect a lun would try and use the ide controller rather than the scsi!

The REAL fix tried and tested is to use SDW 6.3P2 which is available for download now, this fixes quite a few bugs and certainly provides the most stable netapp/vmware compatability yet. Make sure any server 2003 vm has the lsi storport driver as detailed in the release notes for SDW. You also need to make sure you have the latest version of Virtual Storage Console plugin for proper cooperation between sdw and virtual center.

This works with esxi sw iscsi adapter and also (in my environment) broadcom 5709 nic with iscsi offload which can be set up in esxi as hba. We used to make the vm do the hard work with the ms iscsi initiator, now we make the host's hardware do the hard work!