Xen Hypervisor - Slackware (Compilação, instalação e configuração de um kernel compatível com o Xen)

Na postagem anterior abordamos passo a passo a instalação do FreeBSD sobre uma vm através do VirtualBox.

Está postagem abre uma sessão de outras postagens, quais abordarão a instalação e configuração do Xen Hypervisor, assim como a instalação do Solaris através da paravirtualização em Xen.

Empresas que procuram aumentar a utilização de servidores, otimizar soluções já implementadas, reduzir tanto a complexidade, como o custo total do patrimônio alocado estão adotando a virtualização de servidores. O Xen hypervisor é, além de ser o único com technologia "open source",  a mais rápida e mais segura solução de virtualização de infraestrutura disponível atualmente, suportando uma vasta gama de sistemas operacionais como convidados, tais como o Windows®, Solaris®, dentre outros.

A instalação do Xen sobre o Slackware será o centro desta postagem, assim, antes de entrar-mos nos detalhes técnicos, quero aqui colocar algumas considerações:

• O kernel passou a dá suporte nativo ao Xen a partir da versão 3.x, e a versão nativa contida no Slackware 13.37 é a 2.6.37.6;
• Como o Xen é um software de paravirtualização, ele usa uma imagem de inicialização, qual é utilizada junto com a imagem do kernel, sendo que o Grub oferece melhor suporte do que o Lilo, e o Slackware sempre trouxe o Lilo como o seu boot loader nativo, e nem disponibiliza o Grub em seu disco de instalação;
• Até o momento, muito raramente serão encontrados pacotes de instalação do Xen hypervisor para o Slackware disponíveis na rede, porém o fonte disponibilizado no pŕoprio site da suporte ao recurso "DESTDIR".

Bem, após as considerações acima, entraremos agora nos detalhes técnicos.

Iniciaremos fazendo o download da versão estável mais atual do kernel, a versão 3.1.6;

Agora iremos descompactar o nosso novo kernel, lembrando que a localização padrão para os fontes do kernel é sempre em /usr/src:

bash-4.1# tar -jxvf linux-3.1.6.tar.bz2 --directory=/usr/src/

Obs.: A opção --directory já encaminha o fonte do kernel direto para caminho desejado.

Para ampliar, clique sobre a figura.

Conforme a figura acima, foram seguidos os seguintes passos, após descompactado o fonte do kernel para o caminho específico:

1. Foi acessado o diretório onde localizam-se os fontes dos kernels (/usr/src/);
2. Foi removido (rm) o link simbólico vinculado ao fonte do kernel corrente;
3. Foi criado o link simbólico (ln -s) vinculado já ao novo kernel (3.1.6);
4. Foi acessado o diretório onde localizam-se os fontes do novo kernel através do link simbílico(/usr/src/linux);
5. Foi expandido (zcat) o config do kernel corrente para o caminho do novo kernel, mantendo assim, as configurações anteriores para a compilação do kernel 3.1.6;
6. Foi feita uma atualização do .config (oldnoconfig) com base no disponibilizado pelo kernel corrente, definindo todos as novas implementações como n, adicionalmente às atualizações das dependências...

Para ampliar, clique sobre a figura.

 ... E ao acessar o menu de configuração do novo kernel (menuconfig), o primeiro a ser feito foi definir o suporte para memórias grandes para 64 Gb (Processor type and features - High emory Support), caso contrário, não aparecerão as opções de suporte para o Xen. (Figura acima);

Para ampliar, clique sobre a figura.

Conforme a figura acima, foi habilitado o suporte para sistemas convidados paravirtualizados...

Para ampliar, clique sobre a figura.

... E ao acessar-mos o seu submenu, habilitamos o suporte para sistemas convidados Xen, dentre outros conforme mostrado na figura acima;

Para ampliar, clique sobre a figura.

Retornando ao menu anterior (Processor type and features), foi habilitado também o recurso, conforme mostra a figura acima.

Para ampliar, clique sobre a figura.

Retornando ao menu principal, conforme mostra a figura acima, acessamos a opção de suporte a barramentos...

Para ampliar, clique sobre a figura.

... E habilitamos o suporte ao PCI frontend para Xen.

Para ampliar, clique sobre a figura.

Para ampliar, clique sobre a figura.

Retornando ao menu principal, conforme mostram as figuras acima, acessamos a opção de suporte a dispositivos de hardware, em seguida o submenu de dispositivos de bloco (Block devices)...

Para ampliar, clique sobre a figura.

... Encontradas as opções sobre o Xen, habilitamos o suporte nativo a dispositivos de blocos virtuais do Xen, e o beckend habilitamos como módulo (M), conforme mostrado na figura acima.

Para ampliar, clique sobre a figura.

Retornando ao menu anterior, conforme mostra a figura acima, acessamos a opção de suporte a dispositivos de rede...

Para ampliar, clique sobre a figura.

... Encontradas as duas opções sobre o Xen, habilitamos os suportes da mesma forma que fizemos em Block devices, conforme mostrado na figura acima.

Para ampliar, clique sobre a figura.

Retornando ao menu anterior, conforme mostra a figura acima, acessamos a opção de suporte a dispositivos de caractere...

Para ampliar, clique sobre a figura.

... E habilitamos o suporte ao console do Xen conforme mostra a figura acima.

Para ampliar, clique sobre a figura.

Retornando ao menu anterior, conforme mostra a figura acima, acessamos a opção de suporte ao Watchdog Timer...

Para ampliar, clique sobre a figura.

... E habilitamos o suporte ao Watchdog do Xen conforme mostra a figura acima.

Para ampliar, clique sobre a figura.

Para ampliar, clique sobre a figura.

 Retornando ao menu anterior, conforme mostram as figuras acima, acessamos a opção de suporte a recursos gráficos, e em seguida ao submenu de suporte para frame buffer...

Para ampliar, clique sobre a figura.

... E habilitamos o suporte ao frame buffer virtual do Xen.

Para ampliar, clique sobre a figura.

Retornando ao menu anterior, conforme mostra a figura acima, acessamos a opção de suporte a drivers do Xen...

Para ampliar, clique sobre a figura.

... E habilitamos o suporte nativo a todos os drivers virtuais do Xen, exceto o driver "User-space grant reference allocator", qual  habilitamos como módulo (M), conforme mostrado na figura acima.

Para ampliar, clique sobre a figura.

E para finalizar esta etapa, retornando ao menu anterior, conforme mostra a figura acima, habilitamos o suporte a drivers de virtualização.

Retornamos ao menu principal, saímos do menu de configurações para o novo kernel, e salvamos as alterações de forma que foram escritas no .config.
Agora compilaremos o suporte a todos os recursos marcados como nativos (*) ao novo kernel, com o comando abaixo:

bash-4.1# make all

Obs.: ¹ O procedimento referente ao comando acima dura cerca de 60 minutos até a sua finalização; ² Caso o usuário queira habilitar mais algum recurso nativo ( * ), ou como módulo (M) no novo kernel, pode faze-lo, mas com muito critério, e cuidado para que a imagem de inicialização do kernel não fique grande de mais, provocando instabilidade, e até a não inicialização do sistema (kernel panic).

Finalizada a compilação dos módulos marcados como nativos, instalamos todos os módulos para o caminho de instalação dos mesmos, com o comando abaixo:

bash-4.1#  make modules_install

Finalizando mais uma etapa, instalamos o kernel para o seu caminho de instalação (/boot) com o comando abaixo:

bash-4.1#  make install

Obs.: Com o comando acima, serão criados os arquivos de imagem do kernel (vmlinuz), e o System.map, e logo em seguida será executado o lilo para a atualização das entradas do kernel no boot loader. Foi também criado o arquivo /etc/rc.d/rc.modules do novo kernel.

Para ampliar, clique sobre a figura.

Conforme a figura acima, foram seguidos os seguintes passos, após instalação do kernel:

1. Foi acessado o diretório onde se encontram os serviços do Slackware;
2. Foi feita uma cópia (cp) do script de inicialização dos módulos extras dentro do kernel do Linux, sendo renomeado conforme a versão do kernel, qual foi instalada (3.1.6-smp);
3. Foi removido o script rc.modules com nome genérico, gerado pela instalação do novo kernel;
4. Foi criado o link simbólico (rc.modules), apontando para o script do novo kernel (rc.modules-3.1.6-smp);
5. Foi renomeado (mv) o arquivo de imagem do novo kernel do Linux conforme a versão do kernel, qual foi instalada (vmlinuz-3.1.6-smp);
6. Foi renomeado também o arquivo System.map do novo kernel conforme a sua versão, qual foi instalada (System.map-3.1.6-smp);
7. Foi feita uma cópia do arquivo de configuração (.config) do novo kernel, sendo renomeado conforme a versão, qual foi instalada (config-3.1.6-smp);
8. Foi criado o link simbólico (vmlinuz), apontando para a imagem do novo kernel (vmlinuz-3.1.6-smp);
9. Foi criado o link simbólico (System.map), apontando para o arquivo do novo kernel (System.map-3.1.6-smp);
10. Foi criado o link simbólico (config), apontando para o arquivo de configuração do novo kernel (config-3.1.6-smp). Obs.: Não esquecer de remover o link simbólico /boot/config vinculado ao kernel corrente antes de criar o do novo kernel. 

 

Para ampliar, clique sobre a figura.

Conforme mostra a figura acima, encontramos a entrada padrão de inicialização do Slackware, e logo abaixo fui adicionada, por segurança, a entrada de inicialização com o kernel antigo, caso hajam problemas na inicialização com o novo kernel outrora compilado e instalado.

Para ampliar, clique sobre a figura.

Após fechado o arquivo /etc/lilo.conf salvando com a entrada do kernel antigo, foi reinstalado o lilo.



Tudo, até aqui.



Assim, continuaremos com a sessão de postagens sobre o Xen.



Aproveito para desejar a todos melhores votos para 2012.

Saudações.

Xen Hypervisor - Slackware (Instalação, configuração e network bridge)

Na postagem anterior, abordamos sobre a compilação, instalação e configuração do kernel 3.1.6, por já trazer nativo suporte a paravirtualização Xen.

Esta postagem abordaremos a instalação da versão mais atual do do Xen Hypervisor, a versão 4.1.2, qual eu disponibilizarei aqui para download o pacote de instalação para o Slackware na sua primeira revisão:
xen-4.1.2_x86-r1.txz.

Para ampliar, clique sobre a figura.

Conforme a figura acima, vemos que o Xen Hypervisor foi instalado (installpkg). A instalação cria o script /etc/rc.d/rc.xenhd, responsavel pela inicialização dos principais serviços do Xen, porém, ao iniciar o serviço (start), é verificado o erro dizendo que não existe o arquivo  
/proc/xen/capabilities. Ao verificar o kernel instalado (uname -a), verificamos que o novo kernel, qual terminamos de instalar é exatamente o que está sendo usado pelo sistema.
Afinal, por que o serviço do hypervisor não foi inicializado?

Para ampliar, clique sobre a figura.

Foi verificado, conforme a figura acima, que:

1. Ao listar tudo o que tem a seqüência de caracteres "xen" no diretório /boot, a instalação do Xen criou também as imagens de inicialização do Xen.
2. Foi instalado, então, o GNU Grub, multiboot loader. (Vide considerações na postagem anterior)
3. Foi instalado o Grub boot loader no setor MBR do disco rígido principal (/dev/sda)

Nota.: A versão do GNU Grub instalada foi a 1.99, qual disponibilizarei também o pacote de instalação Slackware para download aqui.

Para ampliar, clique sobre a figura.

Depois de instalado o Grub, foi gerado (grub-mkconfig) dentro de /boot/grub o arquivo de configuração (grub.cfg). Notamos que o comando detecta todas entradas de imagens de kernel existentes e gera o arquivo.
Notamos também que, ele encontra cinco entradas referentes ao kernel que instalamos. Por que? São justamente as cinco imagens referentes a inicialização do sistema com o suporte ao Xen.

Para ampliar, clique sobre a figura.

Aqui estão as entradas referentes ao kernel, qual compilamos, instalamos e configuramos na postagem anterior (vi /boot/grub/grub.cfg). Foram feitas apenas algumas edições necessárias, conforme mostra a figura acima.

Para ampliar, clique sobre a figura.

Aqui estão as entradas referentes ao Xen, editadas conforme mostra a figura acima. Foi atribuída ao dom0 aproximadamente metade da memória física presente nesta máquina.
Ao terminar a edição do arquivo, fechamos, salvando as alterações, reinstalamos o boot loader no MBR, conforme o passo de número 3 do tópico de instalação do Grub e mais uma vez reinicializaremos a máquina. Mas antes disto, deve ser adicionada a /etc/fstab a seguinte entrada:

xenfs            /proc/xen        xenfs       defaults         0   0

Obs.: Ao reinicializar a máquina, ao apresentar o menu do GNU Grub, deverá ser acessado o menu Xen 4.1.2, e em seguida o submenu Slackware Linux 13.37, with Xen (3.1.6-smp).

Para ampliar, clique sobre a figura.

Após reinicializado a máquina com suporte ao dom0 Xen, mais uma vez foi verificada a versão do kernel em execução e foram seguidos os seguintes passos, conforme mostra a figura acima:

1. Foram inicializados os principais serviços do xen;
2. Foras listadas as informações sobre o ¹ domínio virtual (dom0);
3. Foi inicializado o ² xend;

Notas.: ¹ Ao tentar listar o(s) domínio(s) virtual(is) presente(s), o sistema retorna uma mensagem de erro, e pergunta se o xend está sendo executado, assim, só foi possível listar após a inicialização do xend; ² O serviço do xend (/etc/rc.d/rc.xend) fica disponível somente depois que são inicializados os demais serviços em /etc.rc.d/rc.xenhd.

Para ampliar, clique sobre a figura.

Quando o rc.xend é inicializado, ele executa o script padrão network-bridge que:

1. Cria uma nova bridge chamada xenbr0;
2. Derruba a eth0 padrão;
3. Copia para a interface virtual veth0 os endereços IP e  MAC da eth0;
4. Renomeia a interface eth0 padrão para peth0;
5. Renomeia também a interface virtual veth0 para eth0;
6. Vincula peth0 e vif0.0 para a bridge xenbr0;
7. Faz subir a bridge, peth0, eth0 e vif0.0.

Nota.: A figura acima mostra que além do nome da bridge padrão ter sido baseado no da interface eth1, a peth1 obteve o endereço MAC da mesma. Por que? A partir da versão 3.3 do Xen se o nome da interface conectada é ethX, o nome da bridge padrão será pethX. Desta forma, como o hardware usado para as demonstrações desta postagem usa uma conexão sem fio na interface eth1, o nome da bridge padrão criada ficou peth1, e como a interface caiu, foi perdido também o roteamento com a internet porque a bridge peth1 assumiu o papel de eth1. 

Como aqui esta sendo usado IP dinâmico, e peth1 requer IP fixo, a solução encontrada foi a seguinte:

Criação do script /etc/xen/scripts/network-multi-bridge com o código abaixo:

Para ampliar, clique sobre a figura.

Após fechar e salvar o script acima, encontrar a linha (network-script network-bridge) em /etc/xen/xend-config.sxp, retirar o comentário, e substituir o nome de script pelo do criado acima. Desta forma, a linha ficara assim:

(network-script network-multi-bridge)

Obs.: Não esquecendo de tornar o script criado executável:


bash-4.1# chmod +x /etc/xen/scripts/network-multi-bridge

Para ampliar, clique sobre a figura.

Após fechar e salvar as alterações em /etc/xen/xend-config.sxp, e reiniciar-mos o rc.xend, notamos uma alteração nas interfaces de rede, conforme mostra a figura acima, sendo restabelecido o roteamento com a internet para eth1.


Para finalizar-mos, fizemos mais o seguinte:

Acessamos /etc/rc.d/rc.xenhd e retiramos o comentário das linhas abaixo:

      echo "Starting Xen Hypervisor: /etc/init.d/xend"
  /etc/rc.d/rc.xend start
 
Acrescentamos a /etc/rc.d/rc.local as linhas abaixo, quais serão responsáveis por inicializar o serviço em tempo de inicialização do sistema:

# Start Xen common services
/etc/rc.d/rc.xenhd start

Obs.: É recomendável que as linhas sejam acrescentadas no inicio do script.

E acrescentamos a /etc/rc.d/rc.0 a entrada abaixo antes da entrada referente ao apache web server, qual será responsável por parar o serviço ao desligar o sistema:

# Stop Xen common services
if [ -x /etc/rc.d/rc.xenhd ]; then

/etc/rc.d/rc.xenhd stop

fi



Tudo, até aqui.

Assim, continuaremos a sessão de postagens sobre o Xen com a instalação do Solaris paravirtualizado.


Saudações a todos.



Referências:

Xen Hypervisor Project

Xen: Add a Network Bridge for eth1 - I Do Linux Enterprise Linux Tips and Tricks.