Running commands, such as sr-scan, breaks the mirror and receive the following error message on the NetApp SAN.
“incremental update not possible, a resync or initialize is necessary”
To recover, you have to re-initialize the SnapMirror.
Running # snapmirror status from NetApp SAN gives you the following error messages:
FAS3050> Mon Mar 16 15:32:30 CDT [wafl.snap.delete:info]: Snapshot copy FAS3050(0101188242)_mirror_XenStorage_d8e0542d_69e8_54e8_d75f_ede5f2f16148_FV0.3 on volume XenStorage_d8e0542d_69e8_54e8_d75f_ede5f2f16148_FV0 NetApp was deleted by the Data ONTAP function zapi_snapshot_delete. The unique ID for this Snapshot copy is (28, 411).
FAS3050> Mon Mar 16 15:33:00 CDT [replication.dst.err:error]: SnapMirror: destination transfer from fas3050:XenStorage_d8e0542d_69e8_54e8_d75f_ede5f2f16148_FV0 to mirror_XenStorage_d8e0542d_69e8_54e8_d75f_ede5f2f16148_FV0 : incremental update not possible; a resync or initialize is necessary.
Mon Mar 16 15:33:00 CDT [snapmirror.src.connDropped:error]: Error reading/writing to network, connection dropped.
The NetApp SnapMirror technology appears to generate it's own FlexVol snapshots to do periodic mirroring of LUNs. This conflicts with XenServer’s managed view of the of the storage volume/LUN when using the NetApp plug-in because XenServer remove unused snapshots (it depends on a LUN clone existing to indicate that a snap should not and cannot be deleted). To resolve this issue, the NetApp driver must be updated once the SnapMirror creation format is identified.
It should be possible to update the NetApp driver to avoid this happening if you can figure out in what format the SnapMirror snapshot is created.
This issue is resolved in XenServer 5.5 Update 2 and later.
XenServer 5.5 Update 2 must be applied to all servers in the Pool.
CTX124027 - XS55EU2 - XenServer 5.5 Update 2