The issue here is the vmkernel, which is VMware's proprietary OS that runs "worlds" which are similar to processes and run the virtual machine monitors that run

The issue here is the vmkernel, which is VMware's proprietary OS that runs "worlds" which are similar to processes and run the virtual machine monitors that run the VMs. It has its own network stack, derived from FreeBSD's, its own scheduler, and its own drivers. The drivers are the big issue here, since many of them are taken from the Linux kernel. VMware publishes source of the modified drivers and the source for the adapter layer that translates Linux kernel functions to vmkernel functions, but not the source of the vmkernel. Their historical claim was that the vmkernel was a binary-only kernel module loaded into the service console's Linux kernel. I always found this argument a bit sketchy. With ESXi, the "user-world" support in the vmkernel was used to move all the processes running in the service console to run directly by the vmkernel, avoiding the need for the service console, and the service console's Linux kernel. Obviously this invalidates their old "vmkernel is binary-only kernel module" argument, and as far as I know, no new argument was made.