When vSRX3.0 with storage is mounted externally on a Network File System (NFS), you may observe instability on vSRX.
This article explains the thresholds on vSRX when NFS is unstable/down and when issues are seen on vSRX, while also providing a workaround when NFS instability cannot be avoided.
Connectivity issues between the kernel-based virtual machine (KVM) and the NFS can cause:
vSRX instability
Routing Engine-Packet Forwarding Engine disconnect
PFE restarts
As per vSRX design, chassisd monitors the Packet Forwarding Engine (PFE) by using keepalives every second with a threshold of 5 seconds. Beyond this threshold, the PFE is declared unresponsive and restarted.
And as per design, Junos OS can handle a maximum of 5 seconds of NFS disconnect.
If the NFS connection remains down for a longer period of time, upon resumption, pending IO tasks (due to NFS disconnection) schedule other tasks, which in turn can cause time slips between chassisd and the PFE, resulting in PFE restarts.
Note that a stable NFS connection without any interruptions is always recommended.
If NFS downtime can be longer than 5 seconds, then undesirable effects on the vSRX guest are expected. Therefore, it is recommended that you rectify the issues with NFS first.
If NFS disconnects are unavoidable, there are a few workarounds that you can try.
Use disk cache in VSRX KVM XML configuration. This will help to cache IO operations till the time NFS connection is not available.
Use NFSv4. Though this is not completely verified as solution, this has shown improvements in lab tests.
In scenarios when NFS snapshots are taken that can cause NFS going down, it is suggested to use separate path / resources for snapshot that would not interfere with hypervisor and NFS server.
Note also that these suggestions are workarounds only and are not the solution.
2023-07-27: Initial version