Virtualizar dispositivos de E/S
A virtualização de E/S permite que um dispositivo físico de E/S seja compartilhado por mais de um SO convidado. A Figura 3 demonstra como vários SOs convidados em execução em VMs do sistema nativo compartilham um só computador de hardware. Como mostrado, o hipervisor constrói dispositivos virtuais de dispositivos físicos. Observe que tanto os SOs convidados quanto o hipervisor precisam ter drivers de dispositivo encapsulando as interfaces para os dispositivos. Isso significa que, com a virtualização, dois drivers de dispositivo diferentes precisam ter suporte para cada dispositivo, em vez de apenas um sem virtualização. Na realidade, isso é um problema porque os fornecedores de dispositivos geralmente fornecem drivers apenas para os SOs principais, mas não para hipervisores (embora isso possa mudar em um futuro próximo). Uma forma de evitar esse problema é colocando o hipervisor com um SO principal no mesmo computador. Dessa forma, as solicitações de E/S podem ser tratadas pelo SO que contém todos os drivers de E/S necessários. Essa é a abordagem adotada pelo Projeto Xen e discutida na próxima página.
Figura 3: Locais lógicos de drivers de dispositivo em vários SOs convidados em VMs de sistema nativas que compartilham um só computador de hardware
Além disso, com a virtualização de E/S, cada solicitação de E/S emitida por um programa de usuário em uma VM convidada deve ser interceptada pelo hipervisor porque as solicitações de E/S são todas privilegiadas e, portanto, precisam ser controladas pelo hipervisor. Claramente, isso envolveria uma interceptação do SO convidado para cada solicitação de E/S. Todas as solicitações de E/S são privilegiadas, sejam elas emitidas usando as instruções de E/S ou E/S mapeada em memória. Portanto, elas não são instruções críticas e todas interceptam o hipervisor. Assim, o hipervisor pode interceptar facilmente cada solicitação de E/S simplesmente quando ele intercepta o SO convidado. Em princípio, o hipervisor pode interceptar solicitações de E/S em qualquer uma das três interfaces: a interface de chamada do sistema, a interface de driver de dispositivo ou a interface de nível de operação.
Se o hipervisor interceptar uma solicitação de E/S na interface de nível de operação, algumas informações essenciais sobre a ação de E/S poderão ser perdidas. O hipervisor precisa dessas informações para manipular as solicitações de E/S corretamente. Quando uma solicitação de E/S chega à interface de driver de dispositivo, ela pode ser transformada em uma sequência de instruções. Quando a sequência de instruções é recebida na interface de nível de operação, torna-se difícil para o hipervisor identificá-las como instruções para uma só solicitação de E/S. Por exemplo, uma gravação de disco se torna várias instruções de armazenamento em caso de E/S mapeada em memória ou de várias instruções de E/S de ISA. Portanto, a interceptação de solicitações de E/S na interface de nível de operação normalmente é evitada. Por outro lado, a interceptação de uma solicitação de E/S na interface de driver de dispositivo permite que o hipervisor mapeie com eficiência a solicitação para o respectivo dispositivo físico e a transmita por meio da interface de nível de operação. Claramente, esse processo é um ponto natural para a virtualização de E/S; ainda assim, obrigaria os desenvolvedores de hipervisor a aprenderem sobre as diferentes interfaces de driver de dispositivo de vários SOs convidados para interceptar as solicitações de E/S. Por fim, a interceptação de solicitações de E/S na interface de chamada do sistema (ou seja, a ABI [interface binária do aplicativo]) pode teoricamente facilitar o processo de virtualização de E/S, no qual toda a operação de E/S poderia ser tratada para cada solicitação pelo hipervisor (o controlador solo, nesse caso). No entanto, para atingir essa meta, o hipervisor deve emular as rotinas da ABI de cada SO convidado (SOs diferentes têm rotinas de ABI diferentes). Consequentemente, os desenvolvedores de hipervisor precisam também aprender sobre os elementos internos de cada SO convidado em potencial. Além disso, a emulação de rotinas da ABI pode prejudicar o desempenho do sistema devido à sobrecarga imposta pelo processo de emulação. Na prática, a interceptação de solicitações de E/S na interface de driver de dispositivo pode ser mais eficiente. No vídeo a seguir, discutiremos o processo geral de virtualização de rede, conforme aplicado a um adaptador de rede física.
Conforme explicado no vídeo, uma placa de adaptador física pode aparecer como várias vNICs (placas de adaptador de rede virtual), cada uma com um endereço MAC separado e na mesma rede que a física. Para infraestruturas de rede, como LANs e SANs, vNICs aparecem como placas físicas regulares.