Hello,
I have a question about VSS providers potentially conflicting when backup up a VM via VIBE.
Using the following software:
ESX 3.5 U3 + current patches
Guest: Windows 2003 Standard SP2
SQL 2005 SP2
SnapDrive 5.01
SM:SQL 2.1.2
VIBE 1.08
VMware Tools are up to date, with the VSS sync driver installed.
OnTap 7.2.4 and 7.3.1 both produce the issue
When VIBE kicks off, and calls VC to snap the SQL VM, it seems to trigger the OnTap VSS Providor to clone the LUNs and try to present them to the OS. The VC snapshot process hangs at 95% until whatever is happening below completes. The VC snapshot eventually completes successfully. VIBE exits w/o errors - with status 0.
Check these logs from /etc/messages on the filer:
Tue Feb 17 20:00:33 PST [lun.offline:warning]: LUN /vol/cc_vcsql_snapinfo/{be54441b-f1fa-4336-89ab-67428b359cf5}.aux has been taken offline
Tue Feb 17 20:00:33 PST [lun.destroy:info]: LUN /vol/cc_vcsql_snapinfo/{be54441b-f1fa-4336-89ab-67428b359cf5}.aux destroyed
Tue Feb 17 20:00:34 PST [lun.offline:warning]: LUN /vol/cc_vcsql_db_master/{0ee0a747-56dc-438b-a473-f05a8182d8bb}.aux has been taken offline
Tue Feb 17 20:00:34 PST [lun.destroy:info]: LUN /vol/cc_vcsql_db_master/{0ee0a747-56dc-438b-a473-f05a8182d8bb}.aux destroyed
Tue Feb 17 20:00:34 PST [lun.offline:warning]: LUN /vol/cc_vcsql_db_virtualcenter/{1e6045d3-1f5f-4d22-8619-be4315669ff0}.aux has been taken offline
Tue Feb 17 20:00:34 PST [lun.destroy:info]: LUN /vol/cc_vcsql_db_virtualcenter/{1e6045d3-1f5f-4d22-8619-be4315669ff0}.aux destroyed
Tue Feb 17 20:00:34 PST [lun.offline:warning]: LUN /vol/cc_vc4sql_db_virtualcenter4/{08286ed9-e0a2-4409-981a-bd9dc012a3d8}.aux has been taken offline
Tue Feb 17 20:00:34 PST [lun.destroy:info]: LUN /vol/cc_vc4sql_db_virtualcenter4/{08286ed9-e0a2-4409-981a-bd9dc012a3d8}.aux destroyed
Tue Feb 17 20:00:36 PST [lun.newLocation.offline:warning]: LUN /vol/sdw_cc_vcsql_snapinfo_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vcsql_snapinfo has been taken offline to prevent map conflicts after a copy or move operation.
Tue Feb 17 20:01:12 PST [lun.map:info]: LUN /vol/sdw_cc_vcsql_snapinfo_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vcsql_snapinfo was mapped to initiator group cc_vcsql=4
Tue Feb 17 20:01:14 PST [lun.newLocation.offline:warning]: LUN /vol/sdw_cc_vcsql_db_master_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vcsql_db_master has been taken offline to prevent map conflicts after a copy or move operation.
Tue Feb 17 20:01:20 PST [lun.map:info]: LUN /vol/sdw_cc_vcsql_db_master_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vcsql_db_master was mapped to initiator group cc_vcsql=5
Tue Feb 17 20:01:22 PST [lun.newLocation.offline:warning]: LUN /vol/sdw_cc_vcsql_db_virtualcenter_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vcsql_db_virtualcenter has been taken offline to prevent map conflicts after a copy or move operation.
Tue Feb 17 20:01:58 PST [lun.map:info]: LUN /vol/sdw_cc_vcsql_db_virtualcenter_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vcsql_db_virtualcenter was mapped to initiator group cc_vcsql=6
Tue Feb 17 20:01:59 PST [lun.newLocation.offline:warning]: LUN /vol/sdw_cc_vc4sql_db_virtualcenter4_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vc4sql_db_virtualcenter4 has been taken offline to prevent map conflicts after a copy or move operation.
Tue Feb 17 20:02:35 PST [lun.map:info]: LUN /vol/sdw_cc_vc4sql_db_virtualcenter4_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vc4sql_db_virtualcenter4 was mapped to initiator group cc_vcsql=7
Tue Feb 17 20:02:53 PST [lun.map.unmap:info]: LUN /vol/sdw_cc_vcsql_snapinfo_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vcsql_snapinfo unmapped from initiator group cc_vcsql
Tue Feb 17 20:03:04 PST [lun.map.unmap:info]: LUN /vol/sdw_cc_vcsql_db_master_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vcsql_db_master unmapped from initiator group cc_vcsql
Tue Feb 17 20:03:16 PST [lun.map.unmap:info]: LUN /vol/sdw_cc_vcsql_db_virtualcenter_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vcsql_db_virtualcenter unmapped from initiator group cc_vcsql
Tue Feb 17 20:03:54 PST [lun.map.unmap:info]: LUN /vol/sdw_cc_vc4sql_db_virtualcenter4_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vc4sql_db_virtualcenter4 unmapped from initiator group cc_vcsql
SM:SQL snapshots are not scheduled at this time.
"vssadmin list providers" lists the OnTap Hardware Provider.
I do get duplicate disk signature messages from "partmgr" in the system error log, as well as emails from SnapDrive:
Virtual Disk Manager Event Detail:
Computer Name: CC-VC-SQL2005
Event ID: 310
Type: Warning
Category: Generic event
Description: Failed to enumerate virtual disk.
Device path: '\\?\mpio#disk&ven_netapp&prod_lun&rev_0.2_#1&7f6ac24&0&36304139383030343333343635373234363334344536443246373134313635#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}'
LUN path: '/vol/sdw_cc_vc4sql_db_virtualcenter4_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vc4sql_db_virtualcenter4'
SCSI address: (3,0,0,7)
Error code: 0xc0040375
Error description: 'LUN is not recognized by Windows. Possible reasons: this disk is not formatted, or this disk is under delete/disconnect/restore operation. Storage System 'goliath', path '/vol/sdw_cc_vc4sql_db_virtualcenter4_cl_3e54ae3f1fd2452f9d7a70d972e26a51_ss_0/cc_vc4sql_db_virtualcenter4', s/n 'C4erF4Nm/qAe'.
The production LUN never goes offline, nothing seems impacted. I'd just rather avoid this thrash if possible. Can I somehow specify which volumes apply to each VSS Hardware Provider, or disable the SQL Volumes from being quiesced by the VMware Tools VSS script?
I did lots of searching tonight with little luck, I'm sure someone has seen this before?
Thank you,
Matt Hallmark
