First off, I'll just get this out of the way: It is not recommended to run any additional workloads on the parent partition (host OS) of Hyper-V. Its sole purpose in life is to provide management and control functionality to the other guest VMs on the system and to give the administrator a view into the other guest VMs on the system. That said, you can certainly do it and it might work great for you. But the official Microsoft stance is avoid running any additional workloads on your parent partition. Now that that's out of the way:
Happy fun ASCII architecture diagram:
| Parent | Child | Child | Child |
----------------------------------
Hypervisor
----------------------------------
Physical Hardware
The parent partition, which is the OS that you boot into and from which you create and control all the other child VMs, is itself really just another logical partition at the same level as the child partitions. All these partitions run in parallel. The only difference is that the root partition is given special privileges and responsibilities by the hypervisor. There are CPU weights and reserves and limits that you can assign to the child virtual machines through the Hyper-V Management console, but it is unclear to me if or how these would map to what we know of as thread priorities in the hypervisor.
On your root partition (or management OS or host OS,) you will see a vmms.exe and 1 instance of vmwp.exe for each virtual machine. The VM Management Service (vmms.exe) is responsible for providing the WMI interface to the hypervisor so that you can manage VMs from an MMC. It also creates a new instance of vmwp.exe when you create a new VM on the system. The VM Worker Process (vmwp.exe) performs virtualization work that a typical monolithic hypervisor would perform, like managing the state of the virtual machine.
On a system with child partitions performing lots of I/O or privileged
operations, you would expect most of the CPU usage to be visible in
the parent partition: you can identify them by the name Vmwp.exe (one
for each child partition). The worker process also includes
components responsible for remote management of the virtualization
stack... -- Russinovich et al, Windows Internals 6th ed.
But unfortunately, vmwp.exe is not the whole story in terms of what all is going on inside a VM, and if you're thinking about manipulating the priority of those processes from the management OS, you'd probably be in uncharted, possibly unsupportable territory. There are also hypercalls and enlightened calls, etc., that might not be charged against a vmwp.exe process but could still be considered part of the overall workload of a virtual machine.
Apart from critical Hyper-V components that might be present in the root partition and not in the child partitions, that might preempt the execution of other child VM code, I would assume that all partitions are equal to the hypervisor in terms of thread scheduling.
Unfortunately, Microsoft doesn't publish many deeply technical articles to answer these questions. If it weren't for Russinovich and his friends, we wouldn't even have Windows Internals. There's a brief section in there on Hyper-V, which I consulted in writing this post, but even it is not much more in-depth than this post.
