Estamos migrando nossa plataforma de virtualização do XenServer da Citrix para o Hyper-V no Windows Server 2008 R2. Como parte deste projeto, eu preciso migrar, de uma forma ou de outra, alguns servidores Debian Linux para o Hyper-V. Eu construí um servidor baseado em Debian com sucesso em nossa nova plataforma Hyper-V e estou começando a testá-lo.
O Debian 6 (Squeeze) usa o kernel 2.6.32, que inclui os drivers sintéticos do Hyper-V, mas não é considerado um sistema operacional convidado de operação da Microsoft. Estou um pouco hesitante em tentar usá-los, a menos que haja uma razão convincente para, como outras pessoas tiveram problemas ( aqui e aqui ).
Por que eu deveria me preocupar em a) lidar com a instabilidade relatada dos drivers Hyper-V atualmente no kernel, b) tentar construir um kernel mais novo, ou c) tentar fazer o Acessórios de máquinas virtuais funcionam com uma distribuição para a qual não foram projetados quando tudo parece "apenas trabalhe"?
EDIT: Para adicionar um pouco às respostas ... Desvio do relógio parece ser um problema significativo (já que o NTP não consegue manter o relógio no tempo) a menos que você esteja usando o Linux Serviços de Integração. Consulte KB918461 . Aparentemente, o uso dos componentes do vmbus incluídos no Linux Integration Services resolve isso. Meu teste descobre isso como um problema.
Os drivers sintéticos 'falam' mais diretamente ao hardware real, ignorando a maior parte do hypervisor (para operações de dados comuns). Isso reduz drasticamente a sobrecarga do hipervisor relacionada à maioria das atividades de rede.
Se o seu servidor não comunicar muito na rede, ou se o seu hardware não estiver bem comprometido, você deve estar bem com os drivers emulados. Há definitivamente uma penalidade de desempenho para fazer isso no entanto.
Quando seu hipervisor está emulando hardware, há muitos registros e problemas de tempo e outras coisas que o driver do cliente espera fazer quando está fazendo coisas como colocar pacotes no buffer da NIC ou colocar dados em um bloco. uma unidade de disco.
Quando você usa o driver sintético, você pula todo o "violino com este registro (que é emulado pelo hypervisor de qualquer forma)" e pule direto para o estágio "aqui está o dado - faça a coisa certa com ele".
Assim, todo o processo é muito mais eficiente.
Eu não tenho uma resposta completa para você, mas alguma experiência que possa ajudar a completar a discussão. Inicialmente, usamos os drivers emulados em nossas máquinas Red Hat, mas o administrador do Linux reclamou que o desempenho da rede era péssimo. Eventualmente, conseguimos que os drivers sintéticos funcionassem através do Virtual Machine Additions e isso fez uma grande diferença (eu não tenho provas ou detalhes, então leve isso com um pouco de sal).
Separadamente, às vezes, visualizamos as VMs pela rede e, quando fazemos isso, devemos usar a NIC emulada em uma caixa do Windows, porque a NIC sintética não oferece suporte à inicialização PXE. Quando a imagem estiver completa, substituiremos a NIC emulada por uma sintética. Mais uma vez, estou falando sobre o Windows aqui (não o Linux), mas é outra diferença.
Em geral, meu entendimento é que os dispositivos emulados emulam dispositivos mais antigos, mais estabelecidos ou mais genéricos, para os quais praticamente todos os sistemas operacionais ou distribuições terão suporte embutido. A este respeito eles são mais universais. Os dispositivos sintéticos não emulam nenhum outro dispositivo que seu sistema operacional ou distribuição reconheceria e, portanto, você precisa de drivers fornecidos pela Microsoft para os quais você obtém instalando o VM Additions.