I doubt that the VMware Workstation would perform any CPU scheduling internally; whatever you mean by internally.
First of all, it has to follow the host OS rules, otherwise chaos reigns. It also has to let the guest VM OS do its own thing.
Not all guest OS will behave the same way. The guest OS might have a different CPU scheduling scheme from the host OS (e.g. Linux guest running inside Windows host or vice-versa, an MS-DOS VM is perpetually busy with the CPU as that was how DOS and its variants was designed in the 1980s, earlier versions of Windows would be busy with the CPU even if you just move the mouse around).
Aside from multiple processes involved, there are multiple threads inside each process. The only prioritisation/scheduling (if ever) that VMware Workstation would be on the threads that it creates (at least in Windows). Some threads might be in relation to rendering the display, some threads to manage disk I/O, some threads to manage VM memory swapping, etc.; so each of these threads and their priority in theory can be controlled by VMware Workstation as they write the code for it. So the guest VM OS will then react accordingly depending on the situation. For example, if the guest OS is accessing virtual disk but there is a backlog at the VMware Workstation level, it has to do its own guest OS rules on how to handle stalled/slow disk I/O.
But CPU scheduling or VMware Workstation having its own CPU scheduling algorithms for VM(s) is unlikely to be part of it.