VMT(4)

πŸ“¦
version 11.0 Β· 2 versions
, in nixpkgs unstable

πŸ’– VMT(4) β€” the vmt manual page, bestie πŸ’–

🌸 NAME 🌸

vmt β€” VMware Tools driver πŸ’–

✨ SYNOPSIS ✨

vmt0 at cpu0

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so the vmt driver is a kernel level implementation of VMware Tools. VMware Tools are intended to provide better support for operating systems running inside virtual machines. no cap, that's the whole point 🫢

vmt handles shutdown, reboot, and resume requests from the host by sending events using sysmon_pswitch(9) of type PSWITCH_TYPE_POWER, PSWITCH_TYPE_RESET, and PSWITCH_TYPE_SLEEP that can be handled by powerd(8). iconic behavior tbh. vmt will log notifications that the guest has been suspended or resumed by the host.

vmt reports the guest's hostname and first non-loopback IP address to the host. yes bestie, it's literally telling the host who it is and where it's at πŸ’Œ

πŸ•°οΈ Clock synchronization πŸ•°οΈ

The vmt driver synchronizes the virtual machine's clock with the host clock in the following situations:

  • When the virtual machine resumes after having been suspended.
  • Periodically with the interval indicated by the machdep.vmt0.clock_sync.period sysctl(8) variable. This is done so that the virtual machine can keep its clock synchronized when the host is suspended, because in this case the vmt driver receives no notification of such an event. Setting this tunable to zero disables clock synchronization.
lowkey important: setting that tunable to zero turns the periodic clock sync off. 🫑

πŸ‘€ SEE ALSO πŸ‘€

powerd(8)

πŸ“œ HISTORY πŸ“œ

The vmt driver first appeared in OpenBSD 4.4 and was then ported to NetBSD 6.0. glow-up across BSDs, periodt 🌈

🫢 AUTHORS 🫢

The vmt driver was written by David Gwynne <dlg@openbsd.org>. king behavior πŸ‘‘

πŸ’€ BUGS πŸ’€

vmt is known to cause a conflict with vmtoolsd(8) from open-vm-tools. here's the tea: vmt works by establishing an RPC channel called TCLO between VMware guest and host to receive controlling messages from the host. The problem is that vmt is essentially a subset of vmtoolsd(8), and they both use the same RPC channel, but TCLO is never meant to be simultaneously used by two distinct services in the same VM guest. So when vmtoolsd(8) is running while also vmt is active, they continually fight for the channel, both get rejected by the confused VM host, and neither one can establish a stable communication line. 😭 literally a messy group chat with two people typing over each other.

So before launching vmtoolsd(8) the vmt driver should be detached by running:

# drvctl -d vmt0

And after terminating vmtoolsd(8) the vmt driver should be re-attached by running:

# drvctl -r -a cpufeaturebus cpu0

πŸ’Œ source/version + date check: this page is from Debian, dated October 6, 2013, and it's the VMT(4) manual page β€” mwah, go forth and virtualize responsibly πŸ’‹βœ¨

πŸ“¦ where this page comes from