Giveback of one or more aggregate failed:operation vetoed by: lock_manager

[golden lion]

Hi all.

Need to upgrade a FAS2552 (9.7P4) to 9.8P18 so decided to reboot it first as it had over 1000 days of uptime.

I have never seen a cluster not come back clean after a simple reboot (reboot node 2) then (reboot node 1)

The error i got was

   Failed: Operation was vetoed by
                             lock_manager. Giveback failed during lock
                             manager veto checks or the pre-commit phase.
                             For veto failures, use the "vserver cifs
                             session file show -hosting-aggregate
                             <aggregate list> -continuously-available No"
                             command to view the open files that have
                             CIFS sessions with non-CA locks established.
                             <aggregate list> is the list of aggregates
                             sent home as a result of the giveback
                             operation. If lock state disruption for all
                             existing non-CA locks is acceptable, retry
                             the giveback operation by specifying
                             "-override-vetoes true". Warning: Overriding
                             vetoes to perform a giveback can be
                             disruptive. For pre-commit failure, search
                             for the lmgr.precommit.oplock.recall EMS
                             variant for information on how to proceed
                             using the "event log show -event
                             lmgr.precommit.oplock.recall.*" command. If
                             the error persists, contact technical
                             support for assistance.

I thought CIFS (SMB2/3) connections was supposed to fail over ? Anyone else seen this issue ?

we ended up running storage failover giveback -ofnode <node_name> -override-vetoes true and it finally came back... If it did not come back does that mean i need to stop the CIFS SVM's ? I thought it was meant to be NDO ?

[scarlet mirage]

Hey Greg, "Continuously available CIFS shares, which are accessed by Hyper-V or Microsoft SQL Server clients using the SMB 3.0 protocol, do not need to be terminated before upgrading."

https://docs.netapp.com/us-en/ontap/upgrade/task_identifying_current_cluster_activity.html#identifying-active-cifs-sessions-that-should-be-terminated

https://docs.netapp.com/us-en/ontap/upgrade/concept_considerations_for_session_oriented_protocols.html

[swift dagger]

CIFS has always been and will always be stateful and sessions will get closed during takeover/giveback. This is a design issue in the protocol. CA shares can mitigate that, but even there the session technically gets closed but the client can reconnect and get all its state back from the server. Also, CA shares should only be used for SQL and Hyper-V, because they consume memory in ONTAP and if you have every client connect to every share via CA, you will exhaust ONTAP's memory and run into trouble at some point

[mystic fractal]

I ran into this a lot on earlier releases when oplocks negotiation simply progressed to slowly for the number of connections we had, but I haven't seen this in quite a long time, perhaps 9.10.1 and later