Having worked on this, I feel the need to warn users about powering off the VMS without proper shutdown.
There appears to be a bug in Tesla VMS firmware (I suspect in the bootloader) where if the VMS is improperly shutdown (power pulled when running, or some other interruption during boot) the file system can become corrupted. The symptom for this is that either the linux.bin (Linux kernel) or vms.initrd (initial ram disk) files are missing on /flash disk. In such cases, the VMS will be reachable on the CAN4 diagnostics, but none of the other VMS traffic will respond, the VDS will report a communication prompt and be useless. VMSIO is unaffected. Reportedly this has already happened in several cases.
I don't think this is a normal filesystem corruption. The files are not damaged, they are simply removed. And these files should not be written in normal circumstances so should not be actively being changed during the shutdown.
The fix is not trivial, and requires proprietary engineering tools to accomplish. An equivalent replacement linux.bin or vms.initrd image needs to be uploaded to the VMS and put back on /flash with the correct name. Making a backup of linux.bin and vms.initrd on the same flash is useful, as it will simplify recovery should the problem happen again in future.
The correct way to power off the VMS imho is to a) inhibit APS, b) stop the VMS application, c) pull the service disconnect (optional?), and d) cleanly and smoothly powering down the VMS. Similarly, when powering on, the power should be applied smoothly. I would plug in J3 before J2. As the VMS is powered by both APS permanent power as well as BPS (little 12v) in 2.x cars, care should be taken to ensure that the BPS is good before messing with service disconnect.