Page 1 of 1

vmfs corruption

Posted: Fri Jul 18, 2025 12:10 pm
by aeon
Hello. In a 2-node StarWind vSAN(cvm) setup, there are two 10Gb replication and data cables directly connected between the nodes without a switch. The management ports are connected via a switch.

For testing, I’m running a single virtual machine on the vSAN datastore. To simulate network loss, I unplug both 10Gb cables and the management port of Node 1. The VM tries to failover to the other node, but most of the time, either immediately or when I reconnect the network cables, the VMFS becomes corrupt.

I wonder what I am doing wrong?

edit: i think this is split brain scenario. please dont say place a quorum node on a different dc. i need a two node solution.

Re: vmfs corruption

Posted: Fri Jul 18, 2025 1:13 pm
by yaroslav (staff)
What you describe looks like a spit-brain scenario. Check the logs for any "partner not synchronized" events without the node getting not synchronized itself.
Do you disconnect all networks?

Re: vmfs corruption

Posted: Fri Jul 18, 2025 1:23 pm
by aeon
yes i all cables except second nodes vm networks.

Re: vmfs corruption

Posted: Fri Jul 18, 2025 1:28 pm
by aeon
I'm already going to add a quorum virtual machine from another system into this environment. In this case, it doesn't really make sense to use a separate quorum for this system as well.

Is it somehow possible to continue from the second node (without a quorum) in a 2-node setup if there's a network loss scenario?

Re: vmfs corruption

Posted: Fri Jul 18, 2025 1:46 pm
by yaroslav (staff)
That was a split brain then https://www.starwindsoftware.com/blog/w ... -avoid-it/.
We design the systems in a way that there is no complete simultaneous network interruption to avoid split brain, OR suggest using the witness node.
Is it somehow possible to continue from the second node (without a quorum) in a 2-node setup if there's a network loss scenario?
Theoretically, the "connected" node will form the majority with the witness and remain up, while the "disconnected" node has its HA storage going not synchronized and not accessible over iSCSI.