/var/run/log/fm.log: The logs show the VM power state changed from "on" to "off". Immediately after, vSphere HA started a failover to move the VM.2026-02-20T18:57:12.324Z In(166) Fdm[92370748]: [Originator@6876 sub=Invt opID=WorkQueue-32ba9d1f] Vm /vmfs/volumes/vsan:527dede288d9ed60-###########/bc546a68-bec1-6924-4500-###########/vSAN File Service Node (15).vmx curPwrState=powered on curPowerOnCount=1 newPwrState=powered off clnPwrOff=false hostReporting=__localhost__2026-02-20T18:57:42.375Z Db(167) Fdm[92370753]: [Originator@6876 sub=Execution opID=host-11080:0:3bd82efd-0] Failing over vm /vmfs/volumes/vsan:527dede288d9ed60-###########/bc546a68-bec1-6924-4500-############/vSAN File Service Node (15).vmx (isRegistered=true)
The system logs (log/vdfs_support/containers/fs_vm_logs/fsvm_logs/journal) show the appliance is set up to update itself automatically. The logs below show the update tool started and then triggered an automatic reboot:
Feb 20 18:57:53.760693 photon-a0ae3c753c00 systemd: Started Reboot Automatically After System Update.Feb 20 18:57:53.760728 photon-a0ae3c753c00 systemd: Started Automatic System Update.Feb 20 18:57:53.760774 photon-a0ae3c753c00 systemd: Started Run tdnf-cache-updateinfo.service daily.
These lines show the tdnf-automatic tool started its work. The Reboot Automatically service confirms the system was told to restart as part of the update process.
This reboot is a normal part of the system update. No action is needed because the restart is expected. There is no loss of service because vSphere HA moves the file service duties to another node before the reboot finished.