Hyper-V Thread Priorities host and guest - how do they correspond?

Yes, funny question.

Given: A host for Hyper-V virtual machines. A HPC type Cluster.

THere are a number of virtual machines on it. They do not use up the CPU most of the time. We also run a HPC style Cluster in house - agents pull Jobs and process them.

There is a talk to install the Agent on our Hyper-V machines. AT the Moment that would give us a significant Performance boost - it will take summer until we really ramp up the Hardware for the calculation Cluster.

The Agents are running all calcualtions in low priority threads. For normal Computers that means that the Agent basically maxes up the CPU usage but does not really interfere with the Computer Operation per se - I even can watch a DVD while the Agent is running.

Now, how is that with Hyper-V? What "thred priority" does the Hyper-V core give the virtual CPU's? Does the root Partition have a higher priorities than the virtual machines? I do not want the agents to interfere with the running virtual machines.

The Hyper-V Parent Partition, or Management OS, is special within the hypervisor. If its virtual processors are runnable, they get a large boost in priority over guest VMs. This is because, in a supported Hyper-V configuration, the only thing the management OS does (statistically speaking) is I/O on behalf of guest VMs. If you install anything else in the management OS, then you're going to preempt work on behalf of guest VMs.

I assume that this has already occurred to you, but you could do this the supported way. Create a VM that is essentially the same size as the physical machine. Give it very low CPU and memory weights and turn on Dynamic Memory so that, when idle, it doesn't use much memory. Run your compute task in that VM. Hyper-V will then prefer doing work for any other guest than that one, but use idle cycles on behalf of your computational task.

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.