Guia de iniciantes do projeto Xen – xen artrite significado em árabe

O projeto Xen cria um monitor de máquina virtual (VMM) também conhecido como hipervisor: um sistema de software que permite a execução de vários sistemas operacionais virtuais convidados simultaneamente em uma única máquina física. Em particular, o projeto cria um hipervisor tipo 1 ou “bare-metal”, o que significa que ele é executado diretamente na parte superior da máquina física, e não no sistema operacional.

Máquinas virtuais convidadas em execução em um hipervisor de projeto xen são conhecidas como “domínios”. Um domínio especial conhecido como domínio0 (ou dom0) é responsável por controlar o hipervisor e iniciar outros sistemas operacionais convidados. Esses outros sistemas operacionais convidados são chamados de domus. Isso ocorre porque esses domínios são “desprivilegiados”, no sentido de que não podem controlar o hipervisor ou iniciar / parar outros domínios.

Nosso hipervisor suporta dois tipos principais de virtualização: a paravirtualização (PV) e a máquina virtualizada de hardware (HVM), também conhecida como “virtualização completa”. Paravirtualização usa sistemas operacionais convidados modificados aos quais nos referimos como "iluminado" convidados. Esses sistemas operacionais sabem que estão sendo virtualizados e, como tal, não precisam de dispositivos de hardware virtual. Em vez disso, eles fazem chamadas especiais para o hipervisor que permitem que eles acessem os recursos de CPU, armazenamento e rede.

Por outro lado, os convidados do HVM não precisam ser modificados, pois o hipervisor criará um conjunto totalmente virtual de dispositivos de hardware para a máquina que se parece com um computador x86 físico. Essa emulação requer mais sobrecarga do que a abordagem de paravirtualização, mas permite que sistemas operacionais convidados não modificados, como o Microsoft Windows, sejam executados na parte superior do hypervisor. Os HVMs são suportados por meio de extensões de virtualização na CPU. Várias iterações dessas extensões foram introduzidas na última década, conhecidas coletivamente como intel VT e AMD-V, e o desenvolvimento continua. A tecnologia é agora predominante; todos os servidores recentes, muitos desktops e alguns sistemas móveis devem estar equipados com pelo menos algumas extensões.

A virtualização Xen agora é vista como em um espectro, com PV em uma extremidade e HVM na outra. Entre eles estão vários aprimoramentos para melhorar o desempenho: HVM com drivers PV, PVHVM ou “paravirtualization on HVM” e, mais recentemente, PVH. Cada um se esforça para fornecer o melhor dos dois mundos, reduzindo a emulação dispendiosa. Para simplificar as coisas para os propósitos deste guia, criaremos um convidado PV genérico e, opcionalmente, um convidado HVM. Para uma análise mais detalhada de como os vários modos (PV, HVM, PVHVM, PVH etc.) se encaixam na imagem, consulte

2. O domínio de controle, por padrão, contém os drivers de dispositivo necessários para endereçar o hardware. Isso interrompe o problema que frequentemente atormentava os usuários do Linux nos anos 90: você instala seu software em um novo hardware, apenas para descobrir que não possui drivers para usá-lo. Desde os primeiros dias, o linux e os bsds tornaram-se bastante bons em suportar mais peças de hardware rapidamente após o nascimento. O projeto Xen aproveita esse suporte usando os drivers no sistema operacional do domínio de controle para acessar vários tipos de hardware.

Para implementar a paravirtualização, cada caminho de dados paravirtualizado consiste em duas partes: 1) um “backend” que vive em dom0, que fornece o dispositivo virtual e 2) um driver “frontend” no domínio guest, que permite que o sistema operacional convidado acesse o virtual dispositivo. O backend e o frontend usam uma interface de software de alta velocidade baseada na memória compartilhada para transferir dados entre o convidado e o dom0.

No caso de convidados do HVM, o dom0 usa extensões de virtualização de hardware fornecidas pela CPU. O mais básico deles é a virtualização da própria CPU. O suporte foi posteriormente adicionado para gerenciamento de tabela de páginas (MMU) e virtualização de E / S (IOMMU). Dom0 também emula algum hardware usando componentes do qemu (o emulador rápido). A emulação no software requer a maior sobrecarga, no entanto, o desempenho é reduzido.

Uma palavra sobre o VT / AMD-V: se você quiser ter certeza de que pode usar as extensões de hardware, é importante verificar se o chipset da CPU e a placa-mãe suportam virtualização. É bem possível ter recursos de virtualização no chipset que não podem ser ativados porque a mobo não foi projetada para isso. Além disso, se você planeja usar uma instância do HVM para mais fins de demonstração, o hardware subjacente deve suportar pelo menos VT-d e VT-i ou AMD-V e AMD-vi. Tendo dito tudo isso, às vezes a maneira mais fácil (ou única) de ver o que é suportado é verificar o BIOS.

As opções de virtualização aparecem de forma diferente em diferentes compilações de BIOS, mas geralmente são chamadas de “enable intel VT” para chipsets intel, "ativar o AMD-V" para a AMD ou simplesmente “habilitar a tecnologia de virtualização”. Muitas vezes essa opção pode ser encontrada no menu “recursos avançados do chipset” no BIOS ou usando a pesquisa se o BIOS suportar isso. Vale a pena pesquisar um pouco sobre isso. As opções podem ser especificadas individualmente, por exemplo: VT-x e VT-d ou AMD-V e AMD-IOMMU (também conhecido como AMD-vi ou AMD-RVI). Você pode até encontrar um está habilitado por padrão, mas o outro não é!

Reinicie antes de continuar. Durante a reinicialização, verifique se a opção de inicialização padrão era "debian GNU / linux, com hypervisor xen" (ou equivalente). Além disso, quando a máquina estiver ativa, execute brctl show novamente para verificar a ponte. Se o padrão de inicialização do GRUB e a ponte estiverem bem, pule a próxima seção e vá diretamente para os comandos básicos do xen project.

Antes de nos aprofundarmos na criação de alguns domínios convidados, abordaremos rapidamente alguns comandos básicos. Nos exemplos abaixo, usamos a ferramenta de linha de comando xl. Versões mais antigas do software de projeto xen usavam a ferramenta de linha de comando xm. Xl e xm são compatíveis com a linha de comando (o formato da saída pode ser ligeiramente diferente). Se, por exemplo, você se deparar "xm" ao ler a documentação antiga, digamos, basta substituir "xl".

Quando os convidados são paravirtualizados, não há “BIOS” ou o bootloader residente no sistema de arquivos guest e, por muito tempo, os convidados receberam kernels externos à imagem do convidado. No entanto, isso é ruim para a capacidade de manutenção (os convidados não podem atualizar seus kernels sem acesso ao dom0) e não é tão flexível em termos de opções de inicialização, pois eles devem ser passados ​​através do arquivo de configuração.

A comunidade de projetos xen escreveu um utilitário conhecido como pygrub que é um aplicativo python para convidados PV que permite ao dom0 analisar a configuração GRUB do domu e extrair seus parâmetros kernel, initrd e boot. Isso permite atualizações do kernel, etc. dentro de nossas máquinas convidadas junto com um menu do GRUB. Usar o pygrub ou a implementação stub-dom conhecida como pv-grub é a melhor prática para iniciar convidados PV. Em alguns casos o pv-grub é indiscutivelmente mais seguro, mas como não está incluído no debian, não o utilizamos aqui, embora seja recomendado em ambientes de produção em que os clientes não são confiáveis.

Esse comando instrui o xen-create-image (o binário primário do xen-tools toolkit) a criar um domínio convidado com 512MB de memória, 2 vcpus, usando o armazenamento do grupo de volume vg0 que criamos, usar DHCP para rede, pygrub para extrair o kernel da imagem quando inicializado e, por último, especificamos que queremos implantar um sistema operacional debian wheezy.

O ponto principal que vale a pena mencionar aqui é que o HVM requer a emulação de ATA, ethernet e outros dispositivos, enquanto o acesso virtualizado à CPU e à memória é realizado no hardware para alcançar um bom desempenho. Por causa disso, os dispositivos emulados padrão são muito lentos e geralmente tentamos usar drivers PV em domínios HVM. Estaremos instalando um conjunto de drivers de vídeo do Windows que aumentará muito o desempenho assim que tivermos o guest do Windows em execução.