Primeiramente, vou tirar isso do caminho: não é recomendado executar nenhuma carga de trabalho adicional na partição pai (sistema operacional host) do Hyper-V. Seu único propósito na vida é fornecer funcionalidade de gerenciamento e controle para as outras VMs convidadas no sistema e fornecer ao administrador uma visão das outras VMs convidadas no sistema. Dito isto, você certamente pode fazê-lo e pode funcionar muito bem para você. Mas a postura oficial da Microsoft é evitar a execução de cargas de trabalho adicionais em sua partição pai. Agora que isso está fora do caminho:
Divertido diagrama de arquitetura ASCII:
| Parent | Child | Child | Child |
----------------------------------
Hypervisor
----------------------------------
Physical Hardware
A partição pai, que é o sistema operacional no qual você inicializa e a partir da qual você cria e controla todas as outras VMs filhas, é, na verdade, apenas outra partição lógica no mesmo nível das partições filhas. Todas essas partições são executadas em paralelo. A única diferença é que a partição raiz recebe privilégios e responsabilidades especiais pelo hypervisor. Existem pesos e reservas e limites de CPU que você pode atribuir às máquinas virtuais secundárias por meio do console de Gerenciamento do Hyper-V, mas não está claro se ou como elas seriam mapeadas para o que conhecemos como prioridades de encadeamento no hypervisor. / p>
Em sua partição raiz (ou sistema operacional de gerenciamento ou sistema operacional host), você verá uma vmms.exe e uma instância do vmwp.exe para cada máquina virtual. O VM Management Service (vmms.exe) é responsável por fornecer a interface WMI ao hipervisor, para que você possa gerenciar as VMs de um MMC. Ele também cria uma nova instância do vmwp.exe quando você cria uma nova VM no sistema. O processo de trabalho da VM (vmwp.exe) executa o trabalho de virtualização que um hipervisor monolítico típico executaria, como o gerenciamento do estado da máquina virtual.
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.
Mas, infelizmente, vmwp.exe não é toda a história em termos do que tudo está acontecendo dentro de uma VM, e se você está pensando em manipular a prioridade desses processos a partir do sistema operacional de gerenciamento, você provavelmente estaria em território inexplorado, possivelmente insustentável. Há também hiperchamadas e chamadas esclarecidas, etc., que podem não ser cobradas em um processo vmwp.exe, mas ainda podem ser consideradas parte da carga de trabalho geral de uma máquina virtual.
Além dos componentes críticos do Hyper-V que podem estar presentes na partição raiz e não nas partições filhas, que podem antecipar a execução de outro código VM da VM, suponho que todas as partições sejam iguais ao hypervisor em termos de agendamento de threads.
Infelizmente, a Microsoft não publica muitos artigos profundamente técnicos para responder a essas perguntas. Se não fosse por Russinovich e seus amigos, nós nem teríamos Windows Internals. Há uma breve seção lá no Hyper-V, que eu consultei ao escrever este post, mas mesmo assim é não muito mais profundo do que este post.