This Knowledgebase article explains the operation of the "Switchover vetoed" message that can be found in the nflogs.
The Veto Mechanism
A switch operation proceeds with the controller querying each of the components it controls to determine if the components are prepared to switch. If the components respond that they are ready to switch, they place themselves into the switch-prepare state. The controller then asks each originally-active component to stop, switches the originally-active state to passive, starts the newly-passive components, stops the originally-passive components, switches the originally-passive state to active, and starts the newly-active components.
In the first "switch-prepare" phase, if any component reports that it is not prepared to switch, the switch is vetoed and the servers continue in their original roles.
If the process gets past the switch-prepare stage, with all components reporting that they will switch, and one of them subsequently cannot switch, then the switch is abandoned. Even though some of the components may have already stopped and some may still be started, the roles may or may not have already switched. If the two servers are not connected, one server may not be able to determine the exact state of the other.
A worst-case scenario is occurs where connection is lost after the local controller has started switching the roles on the remote server and does not know if it is alive or not. Under these circumstances, the two servers have to agree up front that only one of them will be active.
Currently, we address the worst case scenario and decide that the application will be started on the originally passive server, but without replication. The user is supposed to check before starting replication but frequently does not.