File locking isn't really a thing I think EtherDFS was designed for, it was designed to be a very small network file sharing solution with minimal safeguards.
If I can suggest another direction you might want to look, PC-NFS (it's another very small file sharing solution, and can be hosted from a linux box with NFS configured properly) or Netware 3 (you'll need a file host which can be a pain to get working in qemu-kvm, and mars-nwe has fallen off the development bus).
I've hosted 16 nodes of Mystic on qemu-kvm with a Netware 3.11 file server and a custom linux telnet gateway that did connection tracking and round-robin connecting of incoming "callers" to available nodes, or provided either a BUSY or PLEASE WAIT response (with countdown until the oldest connection was eligible for forced disconnect) back to the user when all nodes were in use. Put two network cards in each VM, each with their own driver. One card gets used by Netware for the file shares, the other gets used by rlfossil to provide an inward connection to the VM and simulate a modem for your BBS package. This also means you can isolate your filesharing environment on the backend from the telnet environment on the frontend.
I have seen reports of folks using EtherDFS, despite the reservations I have about doing so. So it may be possible to use it still. But I do wholeheartedly recommend the split network approach, it makes it much easier to get both a file sharing solution and rlfossil going.
Another couple thingsg I'd recommend:
writing a tiny program to get the local MAC address from one of your network cards and use that to set the node's hostname.
(there are some packet driver examples that can easily be pieced together to do this).
setup the minimal boot environment that does auto configuration of the hostname and starting of the network services. have it copy over everything else from a network share every boot. that makes it much easier to update things one time, and have all the nodes auto-deploy when they reboot.