Product SiteDocumentation Site

Red Hat Enterprise Linux 5

Guia de Virtualização

Virtualization Documentation

Edição 5.8

Red Hat Engineering Content Services

Nota Legal

Copyright © 2008, 2009, 2010, 2011, 2012 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
All other trademarks are the property of their respective owners.


1801 Varsity Drive
 RaleighNC 27606-2072 USA
 Phone: +1 919 754 3700
 Phone: 888 733 4281
 Fax: +1 919 754 3701

Resumo
The Red Hat Enterprise Linux Virtualization Guide contains information on installation, configuring, administering, and troubleshooting virtualization technologies included with Red Hat Enterprise Linux.

Prefácio
1. A respeito deste livro
2. Convenções de Documentos
2.1. Convenções Tipográficas
2.2. Convenções de Pull-Quote
2.3. Notas e Avisos
3. We need your feedback
3.1. Technical review requests
4. What is Virtualization?
5. Types of Virtualization
5.1. Full Virtualization
5.2. Para-Virtualization
5.3. Para-virtualized drivers
6. How CIOs should think about virtualization
I. Requerimentos e Limitações para a Tecnologia de Virtualização com o Red Hat Enterprise Linux
1. Requerimentos de Sistema
2. Restrições do Xen e suporte
3. Suporte e restrições do KVM
4. Hyper-V restrictions and support
5. Limitações da Tecnologia de Virtualização
5.1. Limitações Gerais da Tecnologia de Virtualização
5.2. Limitações do KVM
5.3. Limitações do Xen
5.4. Limitações de aplicativo.
II. Instalação
6. Instalando os pacotes de virtualização
6.1. Instalando o Xen com uma nova instalação do Red Hat Enterprise Linux
6.2. Instalando os pacotes de Xen em um sistema Red Hat Enterprise Linux existente
6.3. Instalando o KVM com uma nova instalação do Red Hat Enterprise Linux
6.4. Instalando os pacotes do KVM em um sistema Red Hat Enterprise Linux existente
7. Visão Geral da Instalação do convidado virtualizado
7.1. Criando convidados com o virt-install
7.2. Criando convidados com o virt-manager
7.3. Instalando convidados com o PXE
8. Procedimentos de instalação do sistema operacional convidado
8.1. Instalando um Red Hat Enterprise Linux 5 como um convidado para-virtualizado
8.2. Instalando o Red Hat Enterprise Linux como convidado totalmente virtualizado
8.3. Instalando o Windows XP como um convidado totalmente virtualizado.
8.4. Instalando o Servidor Windows 2003 como um convidado totalmente virtualizado
8.5. Instalando o Instalando o Servidor Windows 2008 como convidado totalmente virtualizado
III. Configuração
9. Virtualized storage devices
9.1. Criando um controlador de disquete virtualizado
9.2. Adicionando dispositivos de armazenamento aos convidados
9.3. Configuração de armazenamento persistente no Red Hat Enterprise Linux 5
9.4. Adicione um CD-ROM virtualizado ou dispositivo DVD a seu convidado
10. Configuração de Rede
10.1. A tradução do endereço da rede (NAT) com libvirt
10.2. Pontes de rede com o libvirt
11. Rede Xen do Pré-Red Hat Enterprise Linux 5.4
11.1. Configuração das pontes de rede convidadas múltiplas para uso de cartões Ethernet múltiplos
11.2. Configuração da rede de laptop do Red Hat Enterprise Linux 5.0
12. Drivers Xen Para-virtualizados
12.1. Solicitações de Sistema
12.2. Restrições e Suporte para a Tecnologia de Para-Virtualização
12.3. Instalando os Drivers Para-virtualizados
12.3.1. Passos da instalação comum
12.3.2. Instalação e Configuração dos Drivers Para-virtualizados no Red Hat Enterprise Linux 3
12.3.3. Instalação e Configuração dos Drivers Para-virtualizados no Red Hat Enterprise Linux 4
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Configuração do Driver de Rede Para-virtualizado
12.5. Configuração de Hardware adicional Para-virtualizado.
12.5.1. Interfaces de Rede Virtual
12.5.2. Dispositivos de Armazenamento Virtual
13. Drivers para-virtualizados KVM
13.1. Instalando os drivers para-virtualizados do KVM Windows
13.2. Installing drivers with a virtualized floppy disk
13.3. Usando os drivers para-virtualizados para dispositivos existentes
13.4. Usando os drivers para-virtualizados KVM para novos dispositivos
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Gerenciamento de tempo do convidado KVM
IV. Administração
17. As melhores práticas do Servidor
18. Segurança para a Tecnologia de Virtualização
18.1. Storage security issues
18.2. Tecnologia de Virtualização e SELinux
18.3. SELinux
18.4. Virtualization firewall information
19. Gerenciando convidados com xend
20. Migração Ativa do Xen
20.1. Um exemplo de migração ativa
20.2. Configurando a migração ativa do convidado
21. Migração Ativa KVM
21.1. Solicitações da Migração Ativa
21.2. Compartilhe a amostra de armazenamento: NFS para uma migração simples
21.3. Migração KVM Ativa com virsh
21.4. Migrando com o virt-manager
22. Gerenciamento remoto de convidados virtualizados
22.1. Gerenciamento remoto com o SSH
22.2. Gerenciamento remoto em TLS e SSL
22.3. Modos de transporte
V. Virtualization Storage Topics
23. Using shared storage with virtual disk images
23.1. Using iSCSI for storing virtual disk images
23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux
23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install
VI. Guia de Referência da Tecnologia de Virtualização
24. Ferramentas da Tecnologia de Virtualização
25. Gerenciando convidados com virsh
26. Gerenciando convidados com o Gestor de Máquina Virtual (virt-manager)
26.1. The Add Connection window
26.2. A janela principal do Gestor de Máquina Virtual
26.3. The guest Overview tab
26.4. Console Gráfico de Máquina Virtual
26.5. Iniciando o virt-manager
26.6. Restaurando uma máquina salva
26.7. Exibindo detalhes de convidado
26.8. Monitoramento de Status
26.9. Exibindo Identificadores de convidado
26.10. Displaying a guest's status
26.11. Exibindo as CPUs Virtuais
26.12. Exibindo o Uso da CPU
26.13. Exibindo o Uso de Memória
26.14. Gerenciando uma Rede Virtual
26.15. Criando uma rede virtual
27. A referência rápida do comando xm
28. Configurando os parâmetros de inicialização do kernel Xen
29. Configurando ELILO
30. libvirt configuration reference
31. Arquivos de Configuração do Xen
VII. Dicas e Truques
32. Dicas e Truques
32.1. Iniciando convidados automaticamente
32.2. Alternando entre hypervisors KVM e Xen
32.2.1. De Xen para KVM
32.2.2. KVM para Xen
32.3. Usando o qemu-img
32.4. Overcommitting Resources
32.5. Modificando /etc/grub.conf
32.6. Verificando as extensões de virtualização
32.7. Accessing data from a guest disk image
32.8. Setting KVM processor affinities
32.9. Gerar um novo endereço de MAC único.
32.10. Limitar a largura de banda de rede para um convidado do Xen
32.11. Configurando as afinidades de processador do Xen.
32.12. Modificando o hypervisor do Xen
32.13. O ftpd seguro
32.14. Configurando o Lun Persistance
32.15. Desativar o monitoramente de disco SMART para convidados
32.16. Limpando Arquivos de Configuração do Xen antigos
32.17. Configurando um Servidor VNC
32.18. Clonagem de Arquivos de Configuração de Convidado
32.19. Duplicando um convidado existente e seus Arquivos de Configuração
33. Criação dos scripts libvirt padronizados
33.1. Usando os arquivos de configuração do XML com o virsh
VIII. Troubleshooting
34. Ferramentas de Solução de Problemas do Xen
34.1. Depurando e Solucionando Problemas (Troubleshooting) do Xen
34.2. Visão Geral de Arquivo de Registro
34.3. Descrições de Arquivo de Registro
34.4. Localizações de Diretórios Importantes
34.5. Solucionando Problemas com os Registros
34.6. Solucionando Problemas com o Console em Serial
34.7. Acesso de Console de convidado Para-virtualizado.
34.8. Acesso ao Console de convidado com Virtualização Completa.
34.9. Problemas Comuns do Xen
34.10. Erros de Criação de Convidados
34.11. Solucionando Problemas com o Console Serial
34.11.1. Resultado de Console Serial para Xen
34.11.2. O resultado do console serial do Xen a partir dos convidados para-virtualizados.
34.11.3. Resultado de console serial a partir dos convidados totalmente virtualizados.
34.12. Arquivos de Configuração do Xen
34.13. Interpretando Mensagens de Erro do Xen
34.14. O layout dos diretórios do log
35. Troubleshooting
35.1. Identificando armazenamento e partições disponíveis
35.2. Após inicializar os convidados baseados em Xen, o console trava
35.3. Os dispositivos de Ethernet virtualizados não são encontrados pelas ferramentas de rede.
35.4. Erros de Dispositivo de Loop
35.5. Criação de domínio falhou, devido à falta de memória
35.6. Falha de Imagem de Kernel errada
35.7. Falha de imagem de kernel errada - Kernel não PAE em uma plataforma PAE
35.8. O convidado de 64 bits totalmente virtualizado falha ao iniciar.
35.9. Uma entrada de localhost faltando, faz com que o virt-manager falhe
35.10. Erro de microcódigo durante a inicialização do convidado
35.11. Mensagem de aviso de depreciação do Python ao iniciar a máquina virtual
35.12. Ativando as extensões de hardware de virtualização do Intel VT e AMD-V, no BIOS.
35.13. Desempenho de rede de KVM
36. Solucionando Problemas dos drivers para-virtualizados do Xen
36.1. Arquivos de registro e diretórios da Tecnologia de Virtualização do Red Hat Enterprise Linux 5
36.2. O convidado para-virtualizado falha ao carregar em um sistema operacional convidado Red Hat Enterprise Linux 3.
36.3. Uma mensagem de erro é exibida durante a instalação dos drivers para-virtualizados no Red Hat Enterprise Linux 3.
36.4. Carregando manualmente os drivers para-virtualizados.
36.5. Verificando se os drivers para-virtualizados carregaram com sucesso.
36.6. O sistema limitou a transferência com os drivers para-virtualizados.
Glossary
A. Recursos Adicionais
A.1. Recursos Online
A.2. Documentação instalada
B. Colofão

Prefácio

The Red Hat Enterprise Linux Virtualization Guide covers all aspects of using and managing virtualization products included with Red Hat Enterprise Linux.

1. A respeito deste livro

This book is divided into 8 parts:
  • Solicitações de Sistema
  • Instalação
  • Configuração
  • Administração
  • Storage
  • Referência
  • Dicas e Truques
  • Problemas de Inicialização
Key terms and concepts used throughout this book are covered in the Glossary.
This book covers virtualization topics for Red Hat Enterprise Linux 5. The KVM and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization. Refer to Seção 4, “What is Virtualization?” and the Glossary for more details on these terms.

2. Convenções de Documentos

Este manual usa diversas convenções para destacar certas palavras e frases e chamar a atenção para informações específicas.
Em PDF e edições de texto, este manual usa tipos de letras retiradas do conjunto de Fontes Liberation Fonts. O conjunto de Fontes Liberation Fonts, também é usado em formato HTML, caso o conjunto esteja instalado em seu sistema. Caso ainda não esteja, como forma alternativa, estão disponíveis tipos de letras equivalentes. Nota: O Red Hat Enterprise Linux 5 e versões mais recentes do mesmo, incluem o conjunto Liberation Fonts por padrão.

2.1. Convenções Tipográficas

São usadas quatro convenções tipográficas para realçar palavras e frases específicas. Estas convenções, e circunstâncias a que se aplicam, são as seguintes:
Negrito Espaço Único (Mono-spaced Bold)
Usada para realçar entradas do sistema, incluindo comandos de shell, nomes de arquivos e caminhos. São também usadas para realçar tecla de Maiúsculas/Minúsculas e as combinações de teclas. Por exemplo:
Para ver o conteúdo do arquivo my_next_bestselling_novel em sua pasta de trabalho atual, insira o comando cat my_next_bestselling_novel na janela de solicitação e pressione Enter para executar o comando.
O comando acima inclui um nome de arquivo, um comando de shell e uma tecla cap, todos apresentados em Negrito Espaço Único (Mono-spaced Bold) e todos distintos, graças ao conteúdo.
As combinações de Teclas podem ser diferenciadas da tecla Caps Lock por um hífen, conectando cada parte de uma combinação de teclas. Por exemplo:
Pressione Enter para executar o comando.
Pressione Ctrl+Alt+F2 para mudar para o primeiro terminal virtual. Pressione Ctrl+Alt+F1 para voltar para sua sessão do X-Windows.
A primeira sentença, destaca uma tecla específica a ser pressionada. A segunda destaca duas combinações de teclas (cada conjunto de três teclas Caps com cada um pressionado simultaneamente).
Caso o código fonte seja discutido, serão apresentados como acima, os nomes de classe, métodos, funções, nomes de variantes e valores retornados mencionados em um parágrafo, em Negrito de Espaço Único (Mono-spaced Bold). Por exemplo:
Classes baseadas em arquivo, incluem filesystem para sistemas de arquivo, file para arquivos, e dir para diretórios. Cada classe possui seu conjunto próprio de permissões associadas.
Negrito Proporcional
Esta representa as palavras e frases encontradas no sistema, incluindo os nomes de aplicativos, texto de caixa de diálogo, botões rotulados, caixa de seleção e rótulos de botão de opção, títulos de menus e sub-menus. Por exemplo:
Escolha Sistema Preferências Mouse a partir da barra de menu para obter Preferências de Mouse. Na aba Botões, clique na caixa de seleção Mouse para mão esquerda e clique em Fechar para mudar o botão do mouse anterior da esquerda para a direita (deixando-o assim, mais adequado para o uso do canhoto).
Para inserir um caractere especial em um arquivo gedit, escolha Aplicativos Acessórios Mapa de Caracteresa partir da barra de menu principal. Depois, escolha a opçãoPesquisar Encontrar…a partir da barra de menu Mapa de Caracteres , digite o nome do caractere no campo Pesquisar e clique em Próximo. O caractere que você buscou estará em destaque na Tabela de Caracteres. Clique novamente nestes caracteres realçados para colocá-los no campo Texto para cópia e depois clique em Copiar. Agora mude novamente para seu documento e escolha Editar Colar a partir da barra de menu do gedit.
O texto acima inclui nomes de aplicativos, nomes de menu e itens de todo o sistema, nomes de menu específicos do aplicativo, e botões e textos encontrados na Interface Gráfica GUI, todos apresentados em Negrito Proporcional (Proportional Bold) e todos diferenciados de acordo com o contexto.
Itálico em Negrito de Espaço Único (Mono-spaced Bold Italic) ouItálico em Negrito Proporcional (Proportional Bold Italic)
Sendo o Negrito Espaço Único (Mono-spaced Bold) ou Negrito Proporcional (Proportional Bold), os itálicos extras indicam textos substituíveis ou variáveis. O Itálico denota o texto que você não inseriu literalmente ou textos exibidos que mudam dependendo das circunstâncias. Por exemplo:
Para conectar-se à uma máquina remota usando o ssh, digite ssh nome do usuário@domain.name na janela de comandos. Por exemplo, considre que a máquina remota seja example.com e seu nome de usuário nesta máquina seja john, digite ssh john@example.com.
O comando mount -o remount file-system remonta o sistema de arquivo nomeado. Por exemplo, para remontar o sistema de arquivo /home, o comando é mount -o remount /home.
Para ver a versão de um pacote instalado, use o comando rpm -q package. Ele retornará um resultado como este: package-version-release.
Observe as palavras em negrito e itálicas acima — nome de usuário, nome do domínio, sistema de arquivo, pacote, versão e lançamento. Cada palavra é um espaço reservado, tanto para o texto que você inseriu ao emitir um comando ou para o texto exibido pelo sistema.
Além de uso padrão para apresentar o título de um trabalho, os itálicos denotam a primeira vez que um termo novo e importante é usado. Por exemplo:
O Publican é um sistema de publicação do DocBook.

2.2. Convenções de Pull-Quote

Resultado de terminal e listagem de código fonte são definidos visualmente com base no contexto.
O resultado enviado à um terminal é configurado em Romano de Espaço Único (Mono-spaced Roman) e apresentado assim:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
As listas de código fonte também são configuradas em Romano de Espaço Único (Mono-spaced Roman), porém são apresentadas e realçadas como a seguir:
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

2.3. Notas e Avisos

E por fim, usamos três estilos visuais para chamar a atenção para informações que possam passar despercebidas.

Nota

Uma nota é uma dica ou símbolo, ou ainda uma opção alternativa para a tarefa em questão. Se você ignorar uma nota, provavelmente não resultará em más consequências, porém poderá deixar passar uma dica importante que tornará sua vida mais fácil.

Importante

Caixas importantes detalham coisas que são geralmente fáceis de passarem despercebidas: mudanças de configuração que somente se aplicam à sessão atual, ou serviços que precisam ser reiniciados antes que uma atualização seja efetuada. Se você ignorar estas caixas importantes, não perderá dados, porém isto poderá causar irritação e frustração.

Aviso

Um Aviso não deve ser ignorado. Se você ignorar avisos, muito provavelmente perderá dados.

3. We need your feedback

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you. Submit a report in Bugzilla: http://bugzilla.redhat.com/ against Red Hat Enterprise Linux with the Virtualization_Guide component.
When submitting a bug report, be sure to mention the manual's identifier: Virtualization_Guide and version number: 5.
If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, include the section number and some of the surrounding text so we can find it easily.

3.1. Technical review requests

All review requests are classified into one of the following five categories:
New content
content documented for the first time — an entirely new feature, procedure, or concept. For example: "Section now describes the new procedure for creating bootable USB devices."
Correction
a factual error previously present in the text has been corrected. For example: "Section previously stated (incorrectly) that IPv4 and IPv6 were both supported; section now states that IPv6 has never been supported."
Clarification
material that was already factually correct but is now better explained. Clarifications are usually in response to reader feedback that the previous content was confusing or misleading in some way. For example: "Paths described in Example 1.2.3 now better reflect the directory structure of an actual installed system."
Obsoletion
a description of a feature or a procedure has been dropped. Material might be obsolete because of a feature that is no longer supported, a known issue that has been corrected, or hardware that is now obsolete. For example, "Section no longer describes how to update kernel modules using a floppy disk."
Verification
a request to check a fact, procedure, or whether material should be obsoleted. For example, "Section describes how to connect to a generic iSCSI storage device. Please verify this on your hardware" or "Section still describes how to update kernel modules using a LS-120 SuperDisk; please verify that we still need to tell readers about this obsolete hardware."

4. What is Virtualization?

Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer that controls hardware and provides guest operating systems with access to underlying hardware devices. The hypervisor allows multiple operating systems to run on the same physical system by offering virtualized hardware to the guest operating system.

5. Types of Virtualization

5.1. Full Virtualization

Red Hat Enterprise Linux contains virtualization packages and tools which provide system administrators with the means to run fully virtualized, unmodified, operating system guests on Red Hat Enterprise Linux. This provides companies with the ability to consolidate older systems onto newer, more efficient hardware. This reduces physical space and operating costs involved with powering and cooling older, less efficient systems. Full virtualization incurs worse I/O performance than native, also known as bare-metal, installations of operating systems.

5.2. Para-Virtualization

Para-virtualization is a virtualization technique which involves running modified versions of operating systems. The para-virtualized operating system is modified to be aware that it is being virtualized, offering an increased ability for optimization as the guest is more aware of its environment. Performance is generally very close to running bare-metal, non-virtualized operating systems.

5.3. Para-virtualized drivers

These two techniques, para-virtualization and full virtualization, can be combined to allow unmodified operating systems to receive near native I/O performance by using para-virtualized drivers on fully virtualized operating systems. This guide covers installation and configuration of the Red Hat Enterprise Linux para-virtualized drivers package for fully virtualized Microsoft Windows® guests.
The para-virtualized drivers package contains storage and network device drivers for fully virtualized Microsoft Windows® guests. The drivers provide Microsoft Windows® guests running on Red Hat Enterprise Linux with enhanced disk and network I/O performance.

6. How CIOs should think about virtualization

by Lee Congdon, Chief Information Officer, Red Hat, Inc.
Você pode já pode estar totalmente imerso nas tecnologias rapidamente emergentes da virtualização. Se este for o caso, considere algumas das idéias abaixo para explorar sobre a tecnologia. Caso contrário, agora é o momento certo para iniciar.
A Virtualização fornece um conjunto de ferramentas para aumentar a flexibilidade e abaixar custos, os quais sáo importantes em todas as empresas e empresas de Tecnologia da Informação. As soluções de virtualização estão se tornando cada vez mais disponíveis e ricas em recursos.
Como a virtualização pode fornecer diversos benefícios para sua empresa em diversas áreas, você deve estabelecer pilotos, desenvolvendo conhecimento e colocando a tecnologia de virtualização para funcionar agora.
Virtualização para Inovação
Na verdade, a virtualização aumenta a flexibilidade desacoplando um sistema operacional e os serviços e aplicativos suportados pelo sistema de uma plataforma de hardware específica. Isto permite o estabelecimento de ambientes virtuais múltiplos em uma plataforma de hardware compartilhada.
Empresas procurando inovar, acreditam que a habilidade de criar novos sistemas e serviços sem instalar hardware adicional (e para descartar rapidamente aqueles sistemas e serviços quando eles não forem mais necessários) pode ser uma grande contribuição para a inovação.
Entre as situações possíveis, se encontram o estabelecimento rápido de sistemas de desenvolvimento para a criação de software padronizado, a habilidade para estabelecer rapidamente ambientes de test, a capacidade de provisionar soluções de software alternadas e compará-las sem investimentos de hardware estensivos, suporte para prototipo rápido e ágeis ambientes de desenvolvimento, e a habilidade para estabelecer rapidamente novos serviços de produção sob demanda.
Estes ambientes podem ser criados in loco ou provisionados externamente, como com a oferta do EC2 do Amazon. Uma vez que o custo para criar um novo ambiente virtual pode ser bastante baixo, e pode tirar vantagem de hardware existentes, a inovação pode ser facilitada e acelerada com um investimento mínimo.
Virtualização pode também superar as expectativas em inovação de suporte através do uso de ambientes virtuais para treinamento e aprendizado. Estes serviços são aplicativos ideais para a tecnologia de virtualização. Um aluno pode iniciar um caso de estudo com um ambiente de sistema padrão conhecido. O trabalho de aula pode ser isolado da rede de produção. Alunos podem estabelecer ambientes de software único sem exclusivamente demandar o uso de recursos de hardware.
Como as capacidades de ambientes virtuais continuam a crescer, nós provavelmente veremos o crescente uso da virtualização possibilitar ambientes portáteis sob medida de acordo com as necessidades de um usuário específico. Estes ambientes podem ser transferidos dinamicamente para um ambiente processador local ou acessível, não importando onde o usuário esteja localizado. Os ambientes virtuais do usuário podem ser armazenados em uma rede ou carregador em um dispositivo de memória portátil.
Um conceito relacionado é um Sistema Operacional do Aparelho, um sistema operacional de aplicativo baseado em pacote, criado para rodar em um ambiente virtual. O objetivo do pacote pode produzir um desenvolvimento menor e suportar custos assim como assegurar que o aplicativo roda em um ambiente seguro e conhecido. Uma solução de Sistema Operacional do Aparelho fornece benefícios à ambos desenvolvedores do aplicativo e consumidores destes mesmos aplicativos.
A forma que estes aplicativos da tecnologia de virtualização se aplicam em sua empresa, irá variar. Se você já usa a tecnologia em mais de uma das áreas mencionadas acima, conte com um investimento adicional em uma solução que requeira desenvolvimento rápido. Se você não se iniciou com a ferramenta de virtualização, inicie com uma implementação de treinamento e aprendizado para desenvolver as habilidades, depois mude para um desenvolvimento de aplicativo e teste. Empresas com experiências mais amplas em virtualização deve considerar a possibilidade de implementar ambientes virtuais portáteis ou aparelhos de aplicativo.
Virtualização para Economia de Custos
A Virtualização pode também ser usada para baixar custos. Um benefício óbvio vem da consolidação de servidores em um conjunto menor de plataformas de hardware mais potentes rodando uma coleção de ambientes virtuais. Não somente os custos podem ser reduzidos, reduzindo a quantia de hardware e reduzindo a quantia de capacidade sem uso, quanto também o desempenho do aplicativo pode na verdade ser aprimorado, uma vez que os convidados virtuais executam em hardware mais potentes.
Mais benefícios incluem a habilidade de adicionar a capacidade de hardware de forma ininterrupta e para migrar de forma dinâmica cargas de trabalho para disponibilizar recursos.
Dependendo da necessidade de sua empresa, pode ser possível criar um ambiente virtual para recuperação de desastres. A introdução da virtualização pode reduzir de maneira significante a necessidade de replicar ambientes de hardware idênticos e pode também possibilitar testes de cenários de desastres sob um menor custo.
A Virtualização fornece uma solução excelente para se direcionar à cargas de trabalhos de pico ou sasionais. Se você tem cargas de trabalho complementares em sua empresa, você pode alocar recursos de forma dinâmica à aplicativos que tenham atualmente a maior demanda. Se você tiver cargas de trabalho de pico que esteja fornecendo atualmente em sua empresa, você poderá comprar capacidade sob demanda externamente e implementá-la de forma eficiente usando uma tecnologia virtual.
A economia de custo a partir da consolidação do servidor pode ser convincente. Se você não está explorando a virtualização para este propósito, você deve iniciar um programa agora mesmo. A medida que ganha experiência com a virtualização, explore os benefícios do balanceamento de carga de trabalho e ambientes de recuperação de desastres virtualizado.
Virtualização como uma Solução Padrão
Não importa a necessidade específica de sua empresa, você deve estar investigando a virtualização como parte do portfolio de seu sistema e aplicativo como uma tecnologia que será provavelmente predominante. Esperamos que os fabricantes de sistemas operacionais incluam a ferramenta de virtualização como um componente padrão, que os fabricantes de hardware construam capacidades virtuais em suas plataformas e que os fabricantes da ferramenta de virtualização expandam o escopo de suas ofertas.
Se você não tiver planos de incorporar a virtualização em sua arquitetura de solução, agora é uma boa hora para identificar o projeto piloto, alocar algumas plataformas de hardware subutilizadas e desenvolver o conhecimento com esta tecnologia flexível e de ótimo custo-benefício. Depois, estenda suas arquiteturas alvo para incorporar soluções virtuais. Embora benefícios substanciais estejam disponíveis em serviços virtualizados existentes, construir um novo aplicativo com a estratégia de virtualização integrada pode produzir mais benefícios em ambos gerenciamento ou disponibilidade.
Você pode aprender mais sobre as soluções de virtualização da Red Hat em http://www.redhat.com/products/

Parte I. Requerimentos e Limitações para a Tecnologia de Virtualização com o Red Hat Enterprise Linux

Requerimentos de sistema, restrições de suporte e limitações

Estes capítulos tratam sobre os requerimentos de sistema, restrições de suporte e limitações da tecnologia de virtualizações no Red Hat Enterprise Linux.

Capítulo 1. Requerimentos de Sistema

This chapter lists system requirements for successfully running virtualization with Red Hat Enterprise Linux. Virtualization is available for Red Hat Enterprise Linux 5 Server.
The requirements for virtualization vary depending on the type of hypervisor. The Kernel-based Virtual Machine (KVM) and Xen hypervisors are provided with Red Hat Enterprise Linux 5. Both the KVM and Xen hypervisors support Full virtualization. The Xen hypervisor also supports Para-virtualization.
For information on installing the virtualization packages, read Capítulo 6, Instalando os pacotes de virtualização.
Requerimentos mínimos de sistema
  • Espaço de disco livre 6GB
  • 2GB de RAM.

O overcommit do KVM

KVM can overcommit physical resources for virtualized guests. Overcommiting resources means the total virtualized RAM and processor cores used by the guests can exceed the physical RAM and processor cores on the host. For information on safely overcommitting resources with KVM refer to Seção 32.4, “Overcommitting Resources”.
Solicitações da Para-Virtualização do Xen.
Os convidados para-virtualizados requerem uma instalação do Red Hat Enterprise Linux 5, disponível sob a rede usando os protocolos NFS, FTP ou HTTP
Solicitações de Virtualização Total Xen
Virtualização Total com o Hipervisor do Xen, requer:
  • an Intel processor with the Intel VT extensions, or
  • um processador AMD com extensões AMD-V, ou
  • um processador Itanium da Intel
Refer to Seção 32.6, “Verificando as extensões de virtualização” to determine if your processor has the virtualization extensions.
Solicitações do KVM
O Hipervisor do KVM precisa:
  • um processador da Intel com o Itenl VT e as extensões da Intel 64, ou
  • um processador AMD com as extensões AMD-V e AMD64.
Refer to Seção 32.6, “Verificando as extensões de virtualização” to determine if your processor has the virtualization extensions.
Suporte de Armazenamento
Os métodos de armazenamento do convidado suportado são:
  • Files on local storage
  • Physical disk partitions
  • Locally connected physical LUNs
  • LVM partitions
  • iSCSI and Fibre Channel based LUNs

Armazenamento de convidado baseado em arquivo

File-based guest images are stored in the /var/lib/libvirt/images/ directory by default. If you use a different directory you must label the new directory according to SELinux policy. Refer to Seção 18.2, “Tecnologia de Virtualização e SELinux” for details.

Capítulo 2. Restrições do Xen e suporte

Red Hat Enterprise Linux 5 supports various architecture combinations for hosts and virtualized guests. All architectures have processor and memory limitations. Refer to the following URLs for the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

Nota

To utilize para-virtualization on Red Hat Enterprise Linux 5, your processor must have the Physical Address Extension (PAE) instruction set.

suporte Itanium®

Virtualization with the Xen hypervisor on the Intel Itanium architecture requires the guest firmware image package, refer to Instalando o hypervisor do Xen com o yum for more information.

Capítulo 3. Suporte e restrições do KVM

The KVM hypervisor requires a processor with the Intel-VT or AMD-V virtualization extensions.
To verify whether your processor supports the virtualization extensions and for information on enabling the virtualization extensions if they are disabled, refer to Seção 32.6, “Verificando as extensões de virtualização”.
The following URLs explain the processor and memory amount limitations for Red Hat Enterprise Linux:
The following URL shows a complete chart of supported operating systems and host and guest combinations:

Capítulo 4. Hyper-V restrictions and support

Certification of guests running under the Microsoft Hyper-V server is conducted by Microsoft. Red Hat Enterprise Linux 5 is fully certified to run under the Microsoft Hyper-V server.

Nota

To avoid timing errors when running Red Hat Enterprise Linux 5 under the Microsoft Hyper-V server, use the divider=10 option in the grub.conf file.

Capítulo 5. Limitações da Tecnologia de Virtualização

Este capítulo trata sobre as limitações adicionais dos pacotes de virtualização no Red Hat Enterprise Linux .

5.1. Limitações Gerais da Tecnologia de Virtualização

Converting between hypervisors
Presently, there is no support for converting Xen-based guests to KVM or KVM-based guests to Xen. Guests can only be supported on the hypervisor type on which they were created. However, at the time of writing, a tool is in development which may be released with future versions of Red Hat Enterprise Linux.
Outras limitações
For other details affecting virtualization, refer to the Red Hat Enterprise Linux Release Notes at http://docs.redhat.com for your version. The Release Notes cover the present new features, known issues and limitations as they are updated or discovered.
Teste antes do desenvolvimento
You should test for the maximum anticipated system and virtualized network load before deploying heavy I/O applications. Load testing and planning are important as virtualization performance can suffer due to high I/O usage.

5.2. Limitações do KVM

As seguintes limitações se aplicam ao hypervisor do KVM:
TSC bit constante
Systems without a Constant Time Stamp Counter require additional configuration. Refer to Capítulo 16, Gerenciamento de tempo do convidado KVM for details on determining whether you have a Constant Time Stamp Counter and configuration steps for fixing any related issues.
Overcommit de Memória
KVM supports memory overcommit and can store the memory of guests in swap. A guest will run slower if it is swapped frequently. When Kernel SamePage Merging (KSM) is used, make sure that the swap size is equivalent to the size of the overcommit ratio.
Overcommit de CPU
Não há suporte por ter mais de 10 CPUs virtuais por núcleo de processador físico. Qualquer número de CPUs virtuais comprometidas acima do número dos núcleos de processador físicos, pode causar problemas com certos convidados virtualizados.
Overcommitting CPUs has some risk and can lead to instability. Refer to Seção 32.4, “Overcommitting Resources” for tips and recommendations on overcommitting CPUs.
Dispositivos de SCSI virtualizados
SCSI emulation is presently not supported. Virtualized SCSI devices are disabled in KVM.
Dispositivos IDE Virtualizados
O KVM é limitado à um máximo de quatro dispositivos IDE virtualizados (emulados) por convidado.
Dispositivos Para-virtualizados.
Os dispositivos para-virtualizados, os quais usam os drivers virtio são dispositivos PCI. Atualmente, os convidados são limitados à um máximo de 32 dispositivos de PCIs. Alguns dispositivos de PCI são especiais para o convidado rodar e estes dispositivos não podem ser removidos. O padrão dos dispositivos requeridos são:
  • a ponte do host,
  • a ponte de ISA e a ponte do USB (as pontes do usb e isa são o mesmo dispositivo),
  • a placa gráfica (usando tanto o driver Cirrus ou qxl), e
  • o dispositivo de balão de memória.
Entre os 32 dispositivos de PCI disponíveis para um convidado, 4 não são removíveis. Isto significa que existem somente 28 PCI slots disponíveis para dispositivos adicionais por convidado. Cada rede para-virtualizada ou dispositivo de bloco usa um slot. Cada convidado pode usar até 28 dispositivos adicionais, criados a partir de qualquer combinação de rede para-virtualizada, dispositivos de disco para-virtualizado, ou outros dispositivos de PCI usando o VT-d.
Limitações de migração
Migração ativa é possível somente com CPUs do mesmo fabricante (ou seja, de Intel para Intel ou de AMD para AMD.)
O bit do No eXecution (NX) bit deve ser configurado para on ou off em ambas as CPUs, no caso de migração ativa.
Storage limitations
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guests should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.

5.3. Limitações do Xen

Nota

All limitations in this chapter are limitations for Red Hat Enterprise Linux 5.8 except where noted. Older versions may have fewer limitations.
Limitações do host do Xen (dom0)
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.

Reparando o limite de dispositivo para-virtualizado.

There are two methods for working around the para-virtualized device limit: using phy devices (devices using the physical access mode) or using LVM on the guest.
Um host não possui limite para o número de dispositivos que o phy possa ter se possuir recursos suficientes.
O LVM, ou ferramenta de particionamento lógico, pode ser usado em um dispositivo de bloco para criar partições lógicas adicionais em um dispositivo de bloco para-virtualizado.
Limitações de Para-virtualização do Xen.
  • For x86 guests, a maximum of 16GB memory per guest.
  • For x86_64 guests, a maximum of 168GB memory per guest.
  • A maximum of 254 devices per virtualized guest.
  • Um máximo de 15 dispositivos de rede por convidado virtualizado.
Limitações de virtualização completa do Xen
  • For x86 guests, a maximum of 16GB memory per guest.
  • Um máximo de quatro dispositivos IDE virtualizados (emulado) por convidado.
    Os dispositivos que usam as unidades para-virtualizadas para convidados totalmente virtualizadas não possuem esta limitação.
  • Virtualized (emulated) IDE devices are limited by the total number of loopback devices supported by the system. The default number of available loopback devices on Red Hat Enterprise Linux 5.8 is 8. That is, by default, all virtualized guests on the system can each have no more than 8 virtualized (emulated) IDE devices.
    For more information on loopback devices, refer to the Red Hat KnowledgeBase, article DOC-1722.

    Usando mais do que 8 dispositivos de auto-retorno

    Por padrão, o Red Hat Enterprise Linux limita o número de dispositivos de auto-retorno disponíveis. Este número pode ser aumentado, modificando o limite do kernel.
    No arquivo /etc/modprobe.conf adicione a seguinte linha:
    options loop max_loop=64
    
    Reboot the machine or run the following commands to update the kernel with this new limit:
    # rmmod loop
    # modprobe loop
    
  • A limit of 254 para-virtualized block devices per host. The total number of block devices (using the tap:aio driver) attached to virtualized guests cannot exceed 254 devices.
  • A maximum of 254 block devices using the para-virtualized drivers per virtualized guest.
  • Um máximo de 15 dispositivos de rede por convidado virtualizado.
  • Um máximo de 15 dispositivos SCSI virtualizados por convidado virtualizado.
PCI passthrough limitations
  • PCI passthrough (attaching PCI devices to guests) is presently only supported on the following architectures:
    • 32 bit (x86) systems.
    • Intel 64 systems.
    • Intel Itanium 2 systems.

5.4. Limitações de aplicativo.

Existem aspectos da tecnologia de virtualização, os quais a torna inadequada para certos tipos de aplicativos.
Os aplicativos com altos requerimentos de transferência de Entrada/Saída, devem usar as unidades para-virtualizadas para convidados totalmente virtualizados. Sem os drivers para-virtualizados, certos aplicativos podem ficar instáveis sob cargas pesadas de Entrada/Saída.
Os seguintes aplicativos devem ser evitados devido aos requerimentos de Entrada/Saída:
  • servidor kdump
  • servidor netdump
You should carefully evaluate database applications before running them on a virtualized guest. Databases generally use network and storage I/O devices intensively. These applications may not be suitable for a fully virtualized environment. Consider para-virtualization or para-virtualized drivers in these cases for increased I/O performance.
Other applications and tools which heavily utilize I/O or require real-time performance should be evaluated carefully. Using full virtualization with the para-virtualized drivers or para-virtualization results in better performance with I/O intensive applications. Applications still suffer a small performance loss from running in virtualized environments. The performance benefits of virtualization through consolidating to newer and faster hardware should be evaluated against the potential application performance issues associated with using fully virtualized hardware.

Parte II. Instalação

Capítulo 6. Instalando os pacotes de virtualização

Antes que você use a virtualização, os pacotes de virtualização devem ser instalados no Red Hat Enterprise Linux. Os pacotes de virtualização podem ser instalados durante a sequência de instalação ou após a instalação usando o comando yum e o Red Hat Network (RHN).
Você pode instalar os hypervisors KVM e Xen em um sistema único. O hypervisor do Xen usa o pacote do kernel-xen e o hypervisor do KVM usa o kernel padrão do Red Hat Enterprise Linux com o módulo do kernel kvm. Xen e KVM usam um kernel diferente do outro e somente um hypervisor pode ser ativado a qualquer momento. A Red Hat recomenda instalar somente um hypervisor, o hypervisor que você deseja usar para a virtualização.
To change hypervisor from Xen to KVM or KVM to Xen refer to Seção 32.2, “Alternando entre hypervisors KVM e Xen”.

6.1. Instalando o Xen com uma nova instalação do Red Hat Enterprise Linux

Esta seção trata sobre a instalação de ferramentas de virtualização e pacotes de Xen como parte de uma nova instalação do Red Hat Enterprise Linux.

Você precisa de ajuda na instalação?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.
  1. Inicie uma instalação interativa do Red Hat Enterprise Linux a partir do CD-ROM, DVD ou PXE de instalação do Red Hat Enterprise Linux.
  2. You must enter a valid installation number when prompted to receive access to the virtualization and other Advanced Platform packages. Installation numbers can be obtained from Red Hat Customer Service.
  3. Complete all steps until you see the package selection step.
    Selecione o grupo de pacote Virtualização, e o botão Padronizar agora.
  4. Selecione o grupo de pacote Virtualização. O grupo de pacote Virtualização seleciona o hypervisor do Xen, virt-manager, libvirt e virt-viewer e todas as dependências para a instalação.
  5. Padronize os pacotes (se necessário)

    Padronize o grupo Virtualização caso precise de outros pacotes de virtualização.
    Press the Close button then the Forward button to continue the installation.

Nota

Você precisa de um serviço de virtualização RHN válido para receber atualizações para os pacotes de virtualização.
Instalando os pacotes Xen com os arquivos Kickstart.
Esta seção descreve como usar um arquivo Kickstart para instalar o Red Hat Enterprise Linux com os pacotes de hypervisor de Xen. Os arquivos kickstart permitem instalações grandes e automatizadas sem que um usuário instale manualmente cada sistema individual. Os passos nesta seção irão assistí-lo na criação e uso do arquivo Kickstart para instalar o Red Hat Enterprise Linux com os pacotes de virtualização.
Na seção de %packages de seu arquivo Kickstart, adicione o seguinte grupo de pacote:
%packages
@xen

Para sistemas Itanium Intel

Fully virtualized guests on the Itanium® architecture require the guest firmware image package (xen-ia64-guest-firmware). Append the following package to your kickstart file:
xen-ia64-guest-firmware
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.2. Instalando os pacotes de Xen em um sistema Red Hat Enterprise Linux existente

A seção descreve os passos necessários para instalar os pacotes de virtualização em um sistema Red Hat Enterprise Linux em funcionamento
Adicionando pacotes à sua lista de serviços do Red Hat Network
Esta seção descreve como ativar os serviços Red Hat Network (RHN) para os pacotes de virtualização. Você precisa destes serviços ativados para instalar e atualizar os pacotes da tecnologia de virtualização no Red Hat Enterprise Linux. Você precisa de uma conta Red Hat Network válida para instalar os pacotes de virtualização no Red Hat Enterprise Linux.
Além disso, suas máquinas devem estar registradas com o RHN. Para registrar uma instalação ainda não registrada do Red Hat Enterprise Linux, execute o comando rhn_register e siga as solicitações.
Se você não tiver uma subscrição válida da Red Hat, visite a loja online da Red Hat.
Procedimento 6.1. Adicionando os serviços de Virtualização com o RHN
  1. Registre-se no RHN usando seu nome de usuário e senha da RHN.
  2. Selecione os sistemas onde você deseja instalar a tecnologia de virtualização.
  3. Na seção Propriedades do Sistema os serviços de sistemas presentes estão listados próximo ao cabeçalho de Serviços. Use o link (Edite Estas Propriedades) para modificar seus serviços.
  4. Selecione o ítem Virtualization.
Seu sistema agora está apto a receber os pacotes da tecnologia de virtualização. A próxima seção explicará como instalar estes pacotes.
Instalando o hypervisor do Xen com o yum
Para usar a Tecnologia de Virtualização no Red Hat Enterprise LInux, você precisa do xen e pacotes kernel-xen. O pacote xen contém o hypervisor e ferramentas de virtualização básicas. O pacote kernel-xen contém um kernel do Linux modificado, o qual executa como um convidado de máquina virtual em um hypervisor.
Para instalar o xen e pacotes do kernel-xen, execute:
# yum install xen kernel-xen
Convidados totalmente virtualizados na arquitetura Itanium® precisam do pacote de imagens do firmware convidado (xen-ia64-guest-firmware) de um DVD de instalação suplementar. Este pacote pode também ser instalado a partir do RHN com o comando yum:
# yum install xen-ia64-guest-firmware
It is advised to install additional virtualization packages for management and configuration. Os pacotes de virtualização recomendados: lists the recommended packages.
Instale os outros pacotes de virtualização recomendados:
# yum install virt-manager libvirt libvirt-python python-virtinst

6.3. Instalando o KVM com uma nova instalação do Red Hat Enterprise Linux

Esta seção explica sobre a instalação de ferramentas de virtualização e pacote KVM como parte de uma nova instalação do Red Hat Enterprise Linux.

Você precisa de ajuda na instalação?

The Installation Guide (available from redhat.com) covers installing Red Hat Enterprise Linux in detail.

Você precisa de um número de instalação válido.

Você não pode selecionar os pacotes de virtualização durante a instalação sem um número de instalação válido.
  1. Inicie uma instalação interativa do Red Hat Enterprise Linux a partir do CD-ROM, DVD ou PXE de instalação do Red Hat Enterprise Linux.
  2. Você precisa inserir um número de instalação válido quando lhe for solicitado, para receber acesso à virtualização e outros pacotes de Plataforma Avançada.
  3. Complete all steps up to the package selection step.
    Selecione o grupo de pacote Virtualização, e o botão Padronizar agora.
  4. Selecione o grupo de pacote KVM. Desselecione o grupo de pacoteVirtualization. Este seleciona o hypervisor do KVM, virt-manager, libvirt e virt-viewer para a instalação.
  5. Padronize os pacotes (se necessário)

    Padronize o grupo Virtualização caso precise de outros pacotes de virtualização.
    Press the Close button then the Forward button to continue the installation.

Nota

Você precisa de um serviço de virtualização RHN válido para receber atualizações para os pacotes de virtualização.
Instalando os pacotes do KVM com os arquivos do Kickstart
Esta seção explica sobre como usar um arquivo do Kickstart para instalar o Red Hat Enterprise com os pacotes do hypervisor do KVM. Os arquivos do Kickstart permitem instalações grandes, automatizadas, sem que um usuário tenha que instalar manualmente cada sistema individual. Os passos nesta seção irão assistí-lo na criação e uso do arquivo de Kickstart para instalar o Red Hat Enterprise Linu com os pacotes da tecnologia de virtualização.
Na seção de %packages de seu arquivo Kickstart, adicione o seguinte grupo de pacote:
%packages
@kvm
More information on Kickstart files can be found on Red Hat's website, redhat.com, in the Installation Guide.

6.4. Instalando os pacotes do KVM em um sistema Red Hat Enterprise Linux existente

Esta seção descreve os passos para instalar o hypervisor do KVM em um Red Hat Enterprise Linux 5.4 ou mais recente.
Adicionando pacotes à sua lista de serviços do Red Hat Network
Esta seção descreve como ativar os serviços Red Hat Network (RHN) para os pacotes de virtualização. Você precisa destes serviços ativados para instalar e atualizar os pacotes da tecnologia de virtualização no Red Hat Enterprise Linux. Você precisa de uma conta Red Hat Network válida para instalar os pacotes de virtualização no Red Hat Enterprise Linux.
Além disso, suas máquinas devem estar registradas com o RHN. Para registrar uma instalação ainda não registrada do Red Hat Enterprise Linux, execute o comando rhn_register e siga as solicitações.
Se você não tiver uma subscrição válida da Red Hat, visite a loja online da Red Hat.
Procedimento 6.2. Adicionando os serviços de Virtualização com o RHN
  1. Registre-se no RHN usando seu nome de usuário e senha da RHN.
  2. Selecione os sistemas onde você deseja instalar a tecnologia de virtualização.
  3. Na seção Propriedades do Sistema os serviços de sistemas presentes estão listados próximo ao cabeçalho de Serviços. Use o link (Edite Estas Propriedades) para modificar seus serviços.
  4. Selecione o ítem Virtualization.
Seu sistema agora está apto a receber os pacotes da tecnologia de virtualização. A próxima seção explicará como instalar estes pacotes.
Instalando o hypervisor do KVM com o yum
Para usar a virtualização no Red Hat Enterprise LInux, você precisará do pacote kvm. O pacote kvm contém o módulo do kernel KVM fornecendo o hypervisor no kernel padrão do Red Hat Enterprise Linux.
Para instalar o pacote kvm execute:
# yum install kvm
Agora instale os pacotes de gerenciamento de virtualização adicionais.
Instale os outros pacotes de virtualização recomendados:
# yum install virt-manager libvirt libvirt-python python-virtinst

Capítulo 7. Visão Geral da Instalação do convidado virtualizado

Depois de instalar os pacotes de virtualização no sistema host, você pode criar sistemas operacionais convidados. Este capítulo descreve os processos gerais para instalar os sistemas operacionais convidados em suas máquinas virtuais. Você pode criar convidados usando o botão New em virt-manager ou use a interface da linha de comando virt-install. Ambos métodos estão inclusos neste capítulo.
Detailed installation instructions are available for specific versions of Red Hat Enterprise Linux, other Linux distributions and Windows. Refer to Capítulo 8, Procedimentos de instalação do sistema operacional convidado for those procedures.

7.1. Criando convidados com o virt-install

Você pode usar o comando virt-install para criar convidados virtualizados a partir da linha de comando. O comando virt-install é usado de forma interativa ou como parte de um script para automatizar a criação das máquinas virtuais. O uso do virt-install com os arquivos Kickstart permite instalações de máquinas virtuais sem a presença de um assistente.
A ferramenta virt-install fornece diversas opções que você pode passar na linha de comando. Para visualizar a lista completa de opções, execute:
$ virt-install --help
A página man do virt-install também documenta cada opção de comando e variantes importantes.
qemu-img é um comando relacionado que pode ser usado antes do virt-install para configurar opções de armazenamento.
An important option is the --vnc option which opens a graphical window for the guest's installation.
Exemplo 7.1. Usando o virt-install com o KVM para criar um convidado Red Hat Enterprise Linux 3
Este exemplo cria um convidado Red Hat Enterprise Linux 3, chamado rhel3support, a partir de um CD-ROM, com rede virtual e com imagem de dispositivo de bloco baseada em arquivo de 5GB. Este exemplo usa o hypervisor do KVM.
# virt-install --accelerate --hvm --connect qemu:///system \
   --network network:default \
   --name rhel3support --ram=756\
   --file=/var/lib/libvirt/images/rhel3support.img \
   --file-size=6 --vnc --cdrom=/dev/sr0

Exemplo 7.2. Usando o virt-intall para criar um convidado fedora 11
# virt-install --name fedora11 --ram 512 --file=/var/lib/libvirt/images/fedora11.img \
	--file-size=3 --vnc --cdrom=/var/lib/libvirt/images/fedora11.iso

7.2. Criando convidados com o virt-manager

virt-manager, mais conhecido como Gestor de Máquina Virtual, é uma ferramenta gráfica para criar e gerenciar convidados virtualizados.
Procedimento 7.1. Criando convidados virtualizados com o virt-manager
  1. Open virt-manager

    Start virt-manager. Launch the Virtual Machine Manager application from the Applications menu and System Tools submenu. Alternatively, run the virt-manager command as root.
  2. Optional: Open a remote hypervisor

    Open the File -> Add Connection. The dialog box below appears. Select a hypervisor and click the Connect button:
  3. Create a new guest

    A janela do virt-manager permite que você crie uma máquina virtual nova. Clique em Novo para criar um novo convidado. Isto abre o assistente exibido no screenshot.
  4. New guest wizard

    The Create a new virtual machine window provides a summary of the information you must provide in order to create a virtual machine:
    Reveja a informação para sua instalação e clique em Próximo.
  5. Name the virtual machine

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  6. Choose virtualization method

    A janela Escolhendo um método de virtualização aparece. Escolha entre Para-virtualizado ou Totalmente virtualizado.
    A Virtualização Total requer um sistema com Intel® VT ou processador AMD-V. Se as extensões da virtualização não estiverem presentes, o botão de seleção totalmente virtualizado ou Ativar kernel/aceleração de hardware não poderá ser selecionado. A opção Para-virtualizado não estará disponível para seleção se o kernel-xen não for o kernel em execução no momento.
    Se você conectou um hypervisor do KVM, somente estará disponível a virtualização total.
    Choose the virtualization type and click the Forward button.
  7. Select the installation method

    The Installation Method window asks for the type of installation you selected.
    Guests can be installed using one of the following methods:
    Local media installation
    This method uses a CD-ROM or DVD or an image of an installation CD-ROM or DVD (an .iso file).
    Network installation tree
    This method uses a mirrored Red Hat Enterprise Linux installation tree to install guests. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS.
    The network services and files can be hosted using network services on the host or another mirror.
    Network boot
    This method uses a Preboot eXecution Environment (PXE) server to install the guest. Setting up a PXE server is covered in the Red Hat Enterprise Linux Deployment Guide. Using this method requires a guest with a routable IP address or shared network device. Refer to Capítulo 10, Configuração de Rede for information on the required networking configuration for PXE installation.
    Set the OS type and OS variant.
    Choose the installation method and click Forward to proceed.

    Para-virtualized guest installation

    Para-virtualized installation must be installed with a network installation tree. The installation tree must be accessible using one of the following network protocols: HTTP, FTP or NFS. The installation media URL must contain a Red Hat Enterprise Linux installation tree. This tree is hosted using NFS, FTP or HTTP.
  8. Installation media selection

    This window is dependent on what was selected in the previous step.
    1. ISO image or physical media installation

      If Local install media was selected in the previous step this screen is called Install Media.
      Select the location of an ISO image or select a DVD or CD-ROM from the dropdown list.
      Click the Forward button to proceed.
    2. Network install tree installation

      If Network install tree was selected in the previous step this screen is called Installation Source.
      Network installation requires the address of a mirror of a Linux installation tree using NFS, FTP or HTTP. Optionally, a kickstart file can be specified to automated the installation. Kernel parameters can also be specified if required.
      Click the Forward button to proceed.
    3. Network boot (PXE)

      PXE installation does not have an additional step.
  9. Storage setup

    The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to Seção 18.2, “Tecnologia de Virtualização e SELinux” for details.
    Your guest storage image should be larger than the size of the installation, any additional packages and applications, and the size of the guests swap file. The installation process will choose the size of the guest's swap based on size of the RAM allocated to the guest.
    Aloque espaço extra para o caso do convidado precisar espaço extra para aplicativos ou outros dados. Por exemplo, servidores da web requerem espaço adicional para arquivos de log.
    Escolha o tamanho adequado para o convidado em seu tipo de armazenamento selecionado e clique em Próximo.

    Nota

    It is recommend that you use the default directory for virtual machine images, /var/lib/libvirt/images/. If you are using a different location (such as /images/ in this example) make sure it is added to your SELinux policy and relabeled before you continue with the installation (later in the document you will find information on how to modify your SELinux policy).
  10. Network setup

    Select either Virtual network or Shared physical device.
    The virtual network option uses Network Address Translation (NAT) to share the default network device with the virtualized guest. Use the virtual network option for wireless networks.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  11. Memory and CPU allocation

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Os convidados requerem memória física suficientes (RAM) para executar de forma eficiente e eficaz. Escolha um valor de memória que mais se adequa ao seu sistema operacional convidado e requerimentos de aplicativo. A maioria dos sistemas operacionais requerem ao menos 512MB de RAM para funcionar bem. Lembre-se, os convidados usam RAM física. Ao executar muitos convidados ou deixar memória insuficiente para o sistema host, resultará em uso significante de memória virtual. A memória virtual é muito mais lenta, causando desempenho de sistema comprometido. Assegure-se de alocar memória suficiente para todos os convidados e o host para operar efetivamente.
    Atribua CPUs virtuais suficientes para o convidado virtualizado. Se o convidado executar um aplicativo de vários segmentos, atribua um número de CPUs virtualizadas que ele precisar para rodar com maior eficiência. Não atribua mais CPUs virtuais do que existirem processadores físicos (ou hiper segmentos) disponíveis no sistema host. É possível super alocar processadores virtuais, no entanto, a super alocação tem um efeito significante e negativo no convidado e desempenho do host, devido ao contexto do processador mudar os cabeçalhos.
    Press Forward to continue.
  12. Verify and start guest installation

    The Finish Virtual Machine Creation window presents a summary of all configuration information you entered. Review the information presented and use the Back button to make changes, if necessary. Once you are satisfied click the Finish button and to start the installation process.
    Uma janela VNC se abre exibindo o início do processo de instalação do sistema operacional convidado.
This concludes the general process for creating guests with virt-manager. Capítulo 8, Procedimentos de instalação do sistema operacional convidado contains step-by-step instructions to installing a variety of common operating systems.

7.3. Instalando convidados com o PXE

Esta seção trata dos passos necessários para instalar convidados com o PXE. A instalação do convidado PXE requer um dispositivo de rede compartilhado, também conhecido como uma ponte de rede. Os procedimentos abaixo explicam a criação de uma ponte e passos necessários para usar a ponte para uma instalação PXE.
  1. Criar uma nova ponte

    1. Crie um novo arquivo de script de rede no diretório /etc/sysconfig/network-scripts/. Este exemplo cria um arquivo chamado ifcfg-installation o qual cria uma ponte chamada installation
      # cd /etc/sysconfig/network-scripts/
      # vim ifcfg-installation
      DEVICE=installation
      TYPE=Bridge
      BOOTPROTO=dhcp
      ONBOOT=yes
      

      Aviso

      The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
    2. Start the new bridge by restarting the network service. The ifup installation command can start the individual bridge but it is safer to test the entire network restarts properly.
      # service network restart
      
    3. Ainda não existem interfaces adicionadas à nova ponte. Use o comando brctl show para visualizar detalhes sobre as pontes de rede no sistema.
      # brctl show
      bridge name     bridge id               STP enabled     interfaces
      installation    8000.000000000000       no
      virbr0          8000.000000000000       yes
      
      A ponte virbr0 é a ponte padrão usada pelo libvirt para o Network Address Translation (NAT) no dispositivo de Ethernet padrão.
  2. Adicione uma interface à nova ponte.

    Edite o arquivo de configuração para a interface. Adicione o parâmetro BRIDGE para o arquivo de configuração com o nome da ponte criada nos passos anteriores.
    # Intel Corporation Gigabit Network Connection
    DEVICE=eth1
    BRIDGE=installation
    BOOTPROTO=dhcp
    HWADDR=00:13:20:F7:6E:8E
    ONBOOT=yes
    
    Após editar o arquivo de configuração, reinicie a rede e reinicialize.
    # service network restart
    
    Verifique se a interface está anexada com o comando vif :
    # brctl show
    bridge name     bridge id               STP enabled     interfaces
    installation    8000.001320f76e8e       no              eth1
    virbr0          8000.000000000000       yes
    
  3. Configurações de Segurança

    Configure iptables para permitir que todo o trânsito seja enviado pela ponte.
    # iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
    # service iptables save
    # service iptables restart
    

    Desabilite iptables nas pontes

    Como forma alternativa, previna que o trânsito em ponte seja processado pelas regras iptables. Adicione as seguintes linhas em /etc/sysctl.conf:
    net.bridge.bridge-nf-call-ip6tables = 0
    net.bridge.bridge-nf-call-iptables = 0
    net.bridge.bridge-nf-call-arptables = 0
    
    Recarregue os parâmetros do kernel configurado com o sysctl.
    # sysctl -p /etc/sysctl.conf
    
  4. Reinicie o libvirt antes da instalação

    Reinicie o daemon do libvirt
    # service libvirtd reload
    
A ponte está configurada, você pode agora inciar uma instalação.
A instalação do PXE com o virt-install
Para o virt-install adicione o parâmetro de instalação --network=bridge:installation onde instalação é o nome de sua ponte. Para instalações PXE use o parâmetro --pxe.
Exemplo 7.3. A instalação do PXE com o virt-install
# virt-install --accelerate --hvm --connect qemu:///system \
    --network=bridge:installation --pxe\
    --name EL10 --ram=756 \
    --vcpus=4
    --os-type=linux --os-variant=rhel5
    --file=/var/lib/libvirt/images/EL10.img \

Instalação PXE com o virt-manager
The steps below are the steps that vary from the standard virt-manager installation procedures. For the standard installations refer to Capítulo 8, Procedimentos de instalação do sistema operacional convidado.
  1. Selecione PXE

    Selecione o PXE como o método de instalação.
  2. Selecione a ponte

    Selecione Dipositivo físico compartilhado e selecione a ponte criada no procedimento anterior.
  3. Inicie a instalação

    A instalação está pronta para ser iniciada.
Uma requisição de DHCP é enviada e se um servidor PXE válido for encontrado, a instalação convidada será iniciada.

Capítulo 8. Procedimentos de instalação do sistema operacional convidado

This chapter covers how to install various guest operating systems in a virtualized environment on Red Hat Enterprise Linux. To understand the basic processes, refer to Capítulo 7, Visão Geral da Instalação do convidado virtualizado.

Importante

When installing a Red Hat Enterprise Linux guest, the installer will ask to perform an integrity check on your installation source (CD/DVD media, or ISO file). If you select to perform the check, once the media is tested and the installation continues, you may encounter a message that states: The Red Hat Enterprise Linux Server CD was not found in any of your CDROM drives. Please insert the Red Hat Enterprise Linux Server CD and press OK to retry.
This behavior is intentional, provided as a convenience to make sure media is ejected in case a CD install (requiring multiple discs/images) is being performed as opposed to a DVD install.
To proceed past this message, make sure you either insert the next CD, or edit the guest's XML file specifying the next ISO file (or re-insert the DVD media). Next, run virsh update-device Guest1 ~/Guest1.xml (substituting your guest's name and XML file), and select OK to continue past this step.

8.1. Instalando um Red Hat Enterprise Linux 5 como um convidado para-virtualizado

Esta seção descreve como instalar o Red Hat Enterprise Linux 5 como um convidado para-virtualizado. A para-virtualização é mais rápida do que a virtualização total e suporta todoas as vantagens da virtualização total. A para-virtualização requer um kernel especial, suportado, o kernel kernel-xen.

Nota importante sobre para-virtualização

A para-virtualização somente funciona com o hypervisor do Xen. A para-virtualização não funciona com o hypervisor KVM.
Assegure-se de que você possui acesso root antes de iniciar a instalação.
Este método instala o Red Hat Enterprise Linux de um servidor remoto. As instruções de instalação apresentadas nesta seção, são semelhantes à instalação do CD-ROM ativo mínimo.
Create para-virtualized Red Hat Enterprise Linux 5 guests using virt-manager or virt-install. For instructions on virt-manager, refer to the procedure in Seção 7.2, “Criando convidados com o virt-manager”.
Crie um convidado para-virtualizado com a linha de comando baseada na ferramenta virt-install. A opção --vnc exibe a instalação gráfica. O nome do convidado no exemplo é rhel5PV, o arquivo de imagem de disco é rhel5PV.dsk e um espelho local das instalações do Red Hat Enterprise Linux 5 é ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/. Substitua estes valores com os valores corretos para seu sistema e rede.
# virt-install -n rhel5PV -r 500 \
-f /var/lib/libvirt/images/rhel5PV.dsk -s 3 --vnc -p \
-l ftp://10.1.1.1/trees/RHEL5-B2-Server-i386/

Automatizando a Instalação

O Red Hat Enterprise Linux pode ser instalado sem uma interface gráfica ou inserção manual. Use os arquivos do Kickstart para automatizar o processo de instalação.
O uso de qualquer um dos métodos abre esta janela, exibindo as fases de inicialização de seu convidado:
Depois que seu convidado tiver concluído o primeiro estágio da inicialização, o processo de inicialização padrão para o Red Hat Enterprise Linux se dá início. Para a maioria dos sistemas as respostas padrão são aceitáveis.
Procedimento 8.1. Procedimento de Instalação do convidado do Red Hat Enterprise Linux para-virtualizado
  1. Selcione o idioma e clique OK.
  2. Selecione o layout do teclado e clique OK.
  3. Assign the guest's network address. Choose to use DHCP (as shown below) or a static IP address:
  4. Se você selecionar o DHCP o processo de instalação irá agora tentar adquirir um endereço de IP:
  5. If you chose a static IP address for your guest this prompt appears. Enter the details on the guest's networking configuration:
    1. Insira um endereço válido de IP. Lembre-se que o endereço IP que você insere pode alcançar o servidor com a árvore de instalação.
    2. Insira uma máscara de Subnet válida, a gateway padrão e o endereço de servidor do nome.
    Selcione o idioma e clique OK.
  6. Este é um exemplo de uma configuração de endereço de IP estático:
  7. O processo de instalação agora recupera os arquivos que ele precisa do servidor:
Depois dos passos iniciais concluídos, o processo de instalação gráfico inicia-se.
Se você estiver instalando um Beta ou uma distribuição de lançamento antecipado, confirme que você deseja instalar o sistema operacional. Clique em Instalar Mesmo Assim, e clique OK:
Procedimento 8.2. O processo de instalação gráfica
  1. Insira um código de registro válido. Se você tiver uma chave de subscrição do RHN válida, por favor insira-a no campo Número de Instalação:

    Nota

    Se você pular o passo do registro, confirme seus detalhes de conta do Red Hat Network após a instalação com o comando rhn_register. O comando rhn_register requer um acesso de usuário root.
  2. A instalação lhe solicita que você confirme a remoção de todos os dados no armazenamento que você selecionou para a instalação:
    Clique em Sim para continuar.
  3. Review the storage configuration and partition layout. You can chose to select the advanced storage configuration if you want to use iSCSI for the guest's storage.
    Make your selections then click Forward.
  4. Confirme o armazenamento selecionado para a instalação.
    Clique em Sim para continuar.
  5. Configure a rede e configurações do hostname. Estas configurações são preenchidas com os dados inseridos anteriormente no processo de instalação. Mude estas configurações se necessário.
    Clique OK para continuar.
  6. Selecione o horário adequado para seu ambiente.
  7. Insira a senha do root para o convidado.
    Clique em Próximo para continuar.
  8. Selecione os pacotes do software a instalar. Selcione o botão Padronizar agora. Você precisa instalar o pacote kernel-xen no diretório Sistemas. O pacote kernel-xen é necessário para a para-virtualização.
    Click Forward.
  9. Serão calculados o requerimento de dependências e espaço.
  10. After the installation dependencies and space requirements have been verified click Forward to start the actual installation.
  11. Todos os pacotes de software selecionados são instalados automaticamente.
  12. Após a conclusão da instalação reinicie seu convidado:
  13. O convidado não irá reinicializar, ao invés disso será fechado...
  14. Boot the guest. The guest's name was chosen when you used the virt-install in Seção 8.1, “Instalando um Red Hat Enterprise Linux 5 como um convidado para-virtualizado”. If you used the default example the name is rhel5PV.
    Use virsh para reinicializar o convidado:
    # virsh reboot rhel5PV
    Como forma alternativa, abra o virt-manager, selecione o nome de seu convidado, clique em Abrir, e depois clique em Executar.
    A VNC window displaying the guest's boot processes now opens.
  15. Inicializar o convidado inicia a tela de configuração da Primeira Inicialização. Este assistente lhe apresenta algumas escolhas de configurações básicas para seu convidado.
  16. Leia e concorde com o acordo de licença.
    Clique Avançar na janela do acordo de licença.
  17. Configure o firewall.
    Clique em Próximo para continuar.
    1. Se você desativar o firewall, lhe será solicitado que confirme sua escolha. Clique em Sim para confirmar e continue. Não recomenda-se desativar seu firewall.
  18. Configure o SELinux. É altamente recomendado que você execute o SELinux no modo enforcing. Você pode escolher executar o SELinux no modo permissive ou desativá-lo completamente.
    Clique em Próximo para continuar.
    1. Se você escolher desativar o SELinux este aviso aparecerá. Clique em Yes to disable SELinux.
  19. Disable kdump. The use of kdump is unsupported on para-virtualized guests.
    Clique em Próximo para continuar.
  20. Confirm time and date are set correctly for your guest. If you install a para-virtualized guest time and date should synchronize with the hypervisor.
    If the users sets the time or date during the installation it is ignored and the hypervisor's time is used.
    Clique em Próximo para continuar.
  21. Defina as atualizações de software. Se você tiver uma subscrição do Red Hat Network ou desejar tentar usar uma, use a tela abaixo para registrar seu convidado recentemente instalado no RHN.
    Clique em Próximo para continuar.
    1. Confirme suas escolhas para o RHN.
    2. Você pode ver uma tela adicional se não configurou o acesso ao RHN. Se o acesso ao RHN não estiver ativado, você não receberá atualizações de software.
      Clique em Avançar.
  22. Crie uma conta de usuário não root. Recomenda-se criar um usuário não root para o uso normal e segurança aprimorada. Insira um Username, Nome e senha.
    Clique em Avançar.
  23. Se um dispositivo de som for detectado e você desejar mantê-lo, sintonize-o. Conclua o processo e clique Avançar.
  24. You can install additional packages from a CD or another repository using this screen. It is often more efficient to not install any additional software at this point but add packages later using the yum command or RHN. Click Finish.
  25. O convidado agora configura qualquer configuração que você modificou e continua o processo de inicialização.
  26. A tela de login do Red Hat Enterprise Linux 5 é exibida. Registre-se usando o username criado nos passos anteriores.
  27. Você instalou agora com sucesso um convidado Red Hat Enterprise Linux para-virtualizado.

8.2. Instalando o Red Hat Enterprise Linux como convidado totalmente virtualizado

This section covers installing a fully virtualized Red Hat Enterprise Linux 5 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Procedimento 8.3. Criando um Red Hat Enterprise Linux 5 convidado totalmente virtualizado, com o virt-manager
  1. Abrir virt-manager

    Inicie virt-manager. Lance o aplicativo Gestor de Máquina Virtual a partir do menu Applicativos e submenu Ferramentas de Sistema. Como forma alternativa, execute o virt-manager como root.
  2. Selecione o Hypervisor

    Selecione o hypervisor. Selecione o Xen ou KVM, caso esteja instalado. Por este exemplo, selecione o KVM. Observe que atualmente o KVM é chamado de qemu.
    Connect to a hypervisor if you have not already done so. Open the File menu and select the Add Connection... option. Refer to Seção 26.1, “The Add Connection window”.
    Depois que uma conexão de hypervisor for selecionada, o botão Novo ficará disponível. Clique em Novo
  3. Inicie o novo assistente da máquina virtual

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Nome da máquina virtual

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. Escolha um método de virtualização

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (Passo 4) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Selecione o método de instalação

    Red Hat Enterprise Linux pode ser instalado usando um destes seguintes métodos:
    • mídia de instalação local, tanto uma imagem de ISO ou mídia ótica física.
    • Selecione Árvore de instalação de Rede se você possuir a árvore de instalação para o Red Hat Enterprise Linux hospedado em algum lugar em sua rede via HTTP, FTP ou NFS.
    • O PXE pode ser usado se você possuir um servidor PXE configurado para inicializar a mídia de instalação do Red Hat Enterprise Linux. A configuração de um servidor em inicialização PXE de uma instalação do Red Hat Enterprise Linux não está inclusa neste guia. No entanto, a maioria dos passos de instalação são os mesmos após a mídia inicializar.
    Set OS Type to Linux and OS Variant to Red Hat Enterprise Linux 5 as shown in the screenshot.
    Press Forward to continue.
  7. Localize a Mídia de Instalação

    Selecione o local de imagem ISO ou o dispositivo de CD-ROM ou DVD. Este exemplo usa uma imagem de arquivo ISO do DVD de instalação do Red Hat Enterprise Linux.
    1. Clique em Navegar.
    2. Procure o local do arquivo ISO e selecione a imagem ISO. Clique em Open para confirmar sua seleção.
    3. The file is selected and ready to install.
      Press Forward to continue.

    Arquivos de imagem e SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Seção 18.2, “Tecnologia de Virtualização e SELinux” for details.
  8. Configuração do Armazenamento

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.

    Migração

    Live and offline migrations require guests to be installed on shared network storage. For information on setting up shared storage for guests refer to Parte V, “Virtualization Storage Topics”.
  9. Configuração da Rede

    Selecione Rede Virtual, ou Dispositivo físico compartilhado.
    A opção de rede virtual usa a Tradução de Endereço de Rede (NAT) para compartilhar o dispositivo de rede padrão com o convidado virtualizado. Use a opção de rede virtual para redes sem fio.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  10. Alocação de CPU e Memória

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Os convidados virtualizados precisam de memória física suficientes (RAM) para executar de forma eficiente e eficaz. Escolha um valor de memória que se adequa ao seu sistema operacional convidado e requerimentos de aplicativo. Lembre-se, os convidados usam a RAM física. Ao executar muitos convidados ou deixar memória insuficiente para o sistema host, resultará em uso significante da memória virtual e swap. A memória virtual é muito mais lenta, causando um comprometimento do desempenho do sistema. Assegure-se de alocar memória suficiente para todos os convidados e host para operar com eficácia.
    Atribua CPUs virtuais suficientes para o convidado virtualizado. Se o convidado executar um aplicativo de vários segmentos, atribua um número de CPUs virtualizadas que ele precisar para rodar com maior eficiência. Não atribua mais CPUs virtuais do que existirem processadores físicos (ou hiper segmentos) disponíveis no sistema host. É possível super alocar processadores virtuais, no entanto, a super alocação tem um efeito significante e negativo no convidado e desempenho do host, devido ao contexto do processador mudar os cabeçalhos.
    Press Forward to continue.
  11. Verifique e inicie a Instalação do convidado

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Instalando o Red Hat Enterprise Linux

    Conclua a sequência de instalação do Red Hat Enterprise Linux 5. A sequência de instalação está inclusa no Guia de Instalação, consulte o Red Hat Documentation para obter o Guia de Instalação do Red Hat Enterprise Linux.
Um Convidado Red Hat Enterprise Linux 5 totalmente virtualizado foi instalado.

8.3. Instalando o Windows XP como um convidado totalmente virtualizado.

O Windows XP pode ser instalado como um convidado totalmente virtualizado. Esta seção descreve como instalar o Windows XP como um convidado totalmente virtualizado em um Red Hat Enterprise Linux.
This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Antes de iniciar este procedimento, assegure-se de que você possui acesso root.

Itanium® support

Atualmente os hosts do Red Hat Enterprise Linux na arquitetura Itanium® não suporta os convidados Windows XP totalmente virtualizados. Somente o Servidor Windows 2003 para sistemas baseados em Itanium, é suportado pelos sistemas Itanium.
  1. Iniciando virt-manager

    Open Applications > System Tools > Virtual Machine Manager. Open a connection to a host (click File > Add Connection). Click the New button to create a new virtual machine.
  2. Nomeando seu sistema virtual

    Insira o Nome do Sistema virtual e depois clique em Próximo.
  3. Escolhendo um método de virtualização

    If you selected KVM or Xen earlier (step Passo 1 ) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    O Windows só pode ser instalado usando virtualização total.
  4. Escolhendo um método de instalação

    Esta tela possibilita que você especifique o método de instalação e o tipo de sistema operacional.
    Seleicone Windows a partir da lista de Tipos de SO e Microsoft Windows XP a partir da lista de Variantes do SO .
    Os convidados de instalação com o PXE é suportado no Red Hat Enterprise Linux 5.2. A instalação do PXE não está inclusa neste capítulo.

    Arquivos de imagem e SELinux

    For ISO image files and guest storage images the recommended to use the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Seção 18.2, “Tecnologia de Virtualização e SELinux” for details.
    Clique em Próximo para continuar.
  5. Choose installation image

    Choose the installation image or CD-ROM. For CD-ROM or DVD installation select the device with the Windows installation disc in it. If you chose ISO Image Location enter the path to a Windows installation .iso image.
    Clique em Próximo para continuar.
  6. The Storage window displays. Choose a disk partition, LUN or create a file-based image for the guest's storage.
    All image files are stored in the /var/lib/libvirt/images/ directory by default. In the default configuration, other directory locations for file-based images are prohibited by SELinux. If you use a different directory you must label the new directory according to SELinux policy. Refer to Seção 18.2, “Tecnologia de Virtualização e SELinux” for details.
    Aloque espaço extra se o convidado precisar de espaço para os aplicativos ou outros dados. Por exemplo, os servidores de rede precisam de espaço adicional para arquivos de log.
    Escolha o tamanho apropriado para o convidado em seu tipo de armazenamento selecionado e clique em Próximo.

    Nota

    Recomenda-se que você use o diretório padrão para imagens de máquina virtual, /var/lib/libvirt/images/. Se você estiver usando um local diferente (tal como /images/ neste exemplo), assegure-se de que ele está em sua política do SELinux e que foi rotulado antes de você continuar com a instalação (mais tarde no documento, você encontrará informações sobre como modificar sua política SELinux.
  7. Configuração da Rede

    Selecione Rede Virtual, ou Dispositivo físico compartilhado.
    A opção de rede virtual usa a Tradução de Endereço de Rede (NAT) para compartilhar o dispositivo de rede padrão com o convidado virtualizado. Use a opção de rede virtual para redes sem fio.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  8. The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Os convidados virtualizados precisam de memória física suficiente (RAM) para executar eficientemente e com eficácia. Escolha um valor de memória que se adequa ao seu sistema operacional convidado e requerimentos de aplicativo. A maioria dos sistemas operacionais precisam de ao menos 512MB de RAM para funcionar bem. Lembre-se, os convidados usam RAM física. Se você executar muitos convidados ou deixar pouca memória para o sistema host, resultará em uso significante de memória virtual e swapping. A memória virtual é muito mais lenta, causando desempenho de sistema e funcionamento comprometido. Assegure-se de alocar memória suficiente para todos os convidados e hosts para operar efetivamente.
    Atribua CPUs virtuais suficientes para o convidado virtualizado. Se o convidado executar um aplicativo de vários segmentos, atribua um número de CPUs virtualizadas que ele precisar para rodar com maior eficiência. Não atribua mais CPUs virtuais do que existirem processadores físicos (ou hiper segmentos) disponíveis no sistema host. É possível super alocar processadores virtuais, no entanto, a super alocação tem um efeito significante e negativo no convidado e desempenho do host, devido ao contexto do processador mudar os cabeçalhos.
  9. Antes que a instalação continue você verá a tela de sumário. Clique em Terminar para proceder com a instalação do convidado:
  10. You must make a hardware selection so open a console window quickly after the installation starts. Click Finish then switch to the virt-manager summary window and select your newly started Windows guest. Double click on the system name and the console window opens. Quickly and repeatedly press F5 to select a new HAL, once you get the dialog box in the Windows install select the 'Generic i486 Platform' tab. Scroll through selections with the Up and Down arrows.
  11. A instalação continua com a instalação padrão do Windows.
  12. Particione o hard drive ao ser solicitado.
  13. Depois que o drive for formatado o Windows iniciará a cópia dos arquivos para o hard drive.
  14. Os arquivos são copiados para o dispositivo de armazenamento, o Windows pode agora ser reiniciado.
  15. Reinicie seu convidado Windows:
    # virsh start WindowsGuest
    Onde WindowsGuest é o nome de sua máquina virtual.
  16. Quando a janela do console se abrir, você verá a fase de configuração da instalação do Windows.
  17. Se sua instalação parecer estar travada durante a fase de configuração, reinicie o convidado com virsh rebootWindowsGuestName. A medida que você reinicia sua máquina virtual, você verá uma mensagem de Configuração está sendo reiniciada:
  18. Após a conclusão da configuração, você verá a tela de inicialização do Windows:
  19. Agora você pode continuar com a configuração padrão de sua instalação do Windows:
  20. O processo de configuração foi concluído.

8.4. Instalando o Servidor Windows 2003 como um convidado totalmente virtualizado

This chapter describes installing a fully virtualized Windows Server 2003 guest with the virt-install command. virt-install can be used instead of virt-manager This process is similar to the Windows XP installation covered in Seção 8.3, “Instalando o Windows XP como um convidado totalmente virtualizado.”.

Itanium® support

No momento, os hosts do Red Hat Enterprise Linux na arquitetura Itanium® não suportam convidados de janelas totalmente virtualizados. Esta seção se aplica somente aos hosts do x86 e x86-64.
  1. Using virt-install for installing Windows Server 2003 as the console for the Windows guest opens the virt-viewer window promptly. The examples below installs a Windows Server 2003 guest with the virt-install command.
    1. Xen virt-install

      # virt-install --virt-type=xen -hvm  \
         --name windows2003sp1 
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
    2. KVM virt-install

      # virt-install --accelerate --hvm --connect qemu:///system \
         --name rhel3support  \
         --network network:default \
         --file=/var/lib/libvirt/images/windows2003sp2.img \
         --file-size=6 \
         --cdrom=/var/lib/libvirt/images/ISOs/WIN/en_windows_server_2003_sp1.iso \
         --vnc --ram=1024
      
  2. Depois que o convidado inicializa na instalação você deve pressionar rapidamente a tecla F5. Se você não pressionar a tecla F5 dentro do tempo exato, será necessário reiniciar a instalação. Ao pressionar a tecla F5 você poderá selecionar HAL ou Computer Type. Escolha Standard PC como Tipo de Computador. É necessário modificar o Tipo de Computador para os convidados virtualizados do Windows Server 2003.
  3. Conclua a instalação.
  4. O Windows Server 2003 está agora instalado como um convidado totalmente virtualizado.

8.5. Instalando o Instalando o Servidor Windows 2008 como convidado totalmente virtualizado

This section covers installing a fully virtualized Windows Server 2008 guest. This procedure covers both the KVM and the Xen hypervisors; the steps are interchangeable and different steps are noted.
The KVM hypervisor requires Red Hat Enterprise Linux 5.4 or newer.
Procedimento 8.4. Instalando o Windows Server 2008 com o virt-manager
  1. Abra o virt-manager

    Inicie o virt-manager. Lance o aplicativo Gestor de Máquina Virtual a partir do menu Applications e o submenu Ferramentas de Sistama. Como forma alternativa, execute o comando virt-manager como root.
  2. Selecione o Hypervisor

    Selecione o hypervisor. Selecione o Xen ou KVM, caso esteja instalado. Por este exemplo, selecione o KVM. Observe que atualmente o KVM é chamado de qemu.
    Quando as opções forem selecionadas, o botão Novo fica disponível. Clique em Novo.
  3. Inicie o assistente da máquina virtual

    Pressing the New button starts the virtual machine creation wizard.
    Press Forward to continue.
  4. Nome da máquina virtual

    Provide a name for your virtualized guest. Punctuation and whitespace characters are not permitted in versions before Red Hat Enterprise Linux 5.5. Red Hat Enterprise Linux 5.5 adds support for '_', '.' and '-' characters.
    Press Forward to continue.
  5. Escolha um método de virtualização

    Choose the virtualization method for the virtualized guest. Note you can only select an installed virtualization method. If you selected KVM or Xen earlier (step 2) you must use the hypervisor you selected. This example uses the KVM hypervisor.
    Press Forward to continue.
  6. Selecione o método de instalação

    Para todas as versões do Windows, use a mídia de instalação local, tanto uma imagem de ISO ou mídia ótica física.
    Você deve usar o PXE se você possuir um servidor do PXE configurado para a instalação de rede do Windows. a Instalação do WIndows PXE não está inclusa neste guia.
    Set OS Type to Windows and OS Variant to Microsoft Windows 2008 as shown in the screenshot.
    Press Forward to continue.
  7. Localize a Mídia de Instalação

    Selecione o local da imagem ISO ou o dispositivo de CD-ROM ou DVD. Este exemplo usa uma imagem de arquivo ISO do CD de instalação do Windows Server 2008.
    1. Clique em Navegar.
    2. Search to the location of the ISO file and select it.
      Press Open to confirm your selection.
    3. The file is selected and ready to install.
      Press Forward to continue.

    Arquivos de imagem e SELinux

    For ISO image files and guest storage images, the recommended directory to use is the /var/lib/libvirt/images/ directory. Any other location may require additional configuration for SELinux, refer to Seção 18.2, “Tecnologia de Virtualização e SELinux” for details.
  8. Configuração do Armazenamento

    Assign a physical storage device (Block device) or a file-based image (File). File-based images must be stored in the /var/lib/libvirt/images/ directory. Assign sufficient space for your virtualized guest and any applications the guest requires.
    Press Forward to continue.
  9. Configuração da Rede

    Selecione Rede Virtual, ou Dispositivo físico compartilhado.
    A opção de rede virtual usa a Tradução de Endereço de Rede (NAT) para compartilhar o dispositivo de rede padrão com o convidado virtualizado. Use a opção de rede virtual para redes sem fio.
    The shared physical device option uses a network bond to give the virtualized guest full access to a network device.
    Press Forward to continue.
  10. Alocação de CPU e Memória

    The Memory and CPU Allocation window displays. Choose appropriate values for the virtualized CPUs and RAM allocation. These values affect the host's and guest's performance.
    Os convidados virtualizados precisam de memória física suficientes (RAM) para executar de forma eficiente e eficaz. Escolha um valor de memória que se adequa ao seu sistema operacional convidado e requerimentos de aplicativo. Lembre-se, os convidados usam a RAM física. Ao executar muitos convidados ou deixar memória insuficiente para o sistema host, resultará em uso significante da memória virtual e swap. A memória virtual é muito mais lenta, causando um comprometimento do desempenho do sistema. Assegure-se de alocar memória suficiente para todos os convidados e host para operar com eficácia.
    Atribua CPUs virtuais suficientes para o convidado virtualizado. Se o convidado executar um aplicativo de vários segmentos, atribua um número de CPUs virtualizadas que ele precisar para rodar com maior eficiência. Não atribua mais CPUs virtuais do que existirem processadores físicos (ou hiper segmentos) disponíveis no sistema host. É possível super alocar processadores virtuais, no entanto, a super alocação tem um efeito significante e negativo no convidado e desempenho do host, devido ao contexto do processador mudar os cabeçalhos.
    Press Forward to continue.
  11. Verifique e inicie a Instalação do convidado

    Verify the configuration.
    Press Finish to start the guest installation procedure.
  12. Instalação Windows

    Complete the Windows Server 2008 installation sequence. The installation sequence is not covered by this guide, refer to Microsoft's documentation for information on installing Windows.

Parte III. Configuração

Configurando a Tecnologia de Virtualização no Red Hat Enterprise Linux

These chapters cover configuration procedures for various advanced virtualization tasks. These tasks include adding network and storage devices, enhancing security, improving performance, and using the Para-virtualized drivers on fully virtualized guests.

Índice

9. Virtualized storage devices
9.1. Criando um controlador de disquete virtualizado
9.2. Adicionando dispositivos de armazenamento aos convidados
9.3. Configuração de armazenamento persistente no Red Hat Enterprise Linux 5
9.4. Adicione um CD-ROM virtualizado ou dispositivo DVD a seu convidado
10. Configuração de Rede
10.1. A tradução do endereço da rede (NAT) com libvirt
10.2. Pontes de rede com o libvirt
11. Rede Xen do Pré-Red Hat Enterprise Linux 5.4
11.1. Configuração das pontes de rede convidadas múltiplas para uso de cartões Ethernet múltiplos
11.2. Configuração da rede de laptop do Red Hat Enterprise Linux 5.0
12. Drivers Xen Para-virtualizados
12.1. Solicitações de Sistema
12.2. Restrições e Suporte para a Tecnologia de Para-Virtualização
12.3. Instalando os Drivers Para-virtualizados
12.3.1. Passos da instalação comum
12.3.2. Instalação e Configuração dos Drivers Para-virtualizados no Red Hat Enterprise Linux 3
12.3.3. Instalação e Configuração dos Drivers Para-virtualizados no Red Hat Enterprise Linux 4
12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5
12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6
12.4. Configuração do Driver de Rede Para-virtualizado
12.5. Configuração de Hardware adicional Para-virtualizado.
12.5.1. Interfaces de Rede Virtual
12.5.2. Dispositivos de Armazenamento Virtual
13. Drivers para-virtualizados KVM
13.1. Instalando os drivers para-virtualizados do KVM Windows
13.2. Installing drivers with a virtualized floppy disk
13.3. Usando os drivers para-virtualizados para dispositivos existentes
13.4. Usando os drivers para-virtualizados KVM para novos dispositivos
14. PCI passthrough
14.1. Adding a PCI device with virsh
14.2. Adding a PCI device with virt-manager
14.3. PCI passthrough with virt-install
14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux
15. SR-IOV
15.1. Introduction
15.2. Using SR-IOV
15.3. Troubleshooting SR-IOV
16. Gerenciamento de tempo do convidado KVM

Capítulo 9. Virtualized storage devices

This chapter covers installing and configuring storage devices in virtualized guests. The term block devices refers to various forms of storage devices. All the procedures in this chapter work with both Xen and KVM hypervisors.

Valid disk targets

The target variable in libvirt configuration files accepts only the following device names:
  • /dev/xvd[a to z][1 to 15]
    Example: /dev/xvdb13
  • /dev/xvd[a to i][a to z][1 to 15]
    Example: /dev/xvdbz13
  • /dev/sd[a to p][1 to 15]
    Example: /dev/sda1
  • /dev/hd[a to t][1 to 63]
    Example: /dev/hdd3

9.1. Criando um controlador de disquete virtualizado

Os controladores de disquetes são requeridos para um número de sistemas operacionais antigos, especialmente para instalar os drivers. No momento, os dispositivos de disquetes físicos não podem ser acessados a partir de convidados virtualizados. No entanto, a criação e acesso às imagens do disquete a partir de drivers de disquetes virtualizados é suportada. Esta seção cobre a criação de um dispositivo de disquete virtualizado.
An image file of a floppy disk is required. Create floppy disk image files with the dd command. Replace /dev/fd0 with the name of a floppy device and name the disk appropriately.
# dd if=/dev/fd0 of=~/legacydrivers.img

Nota de drivers Para-virtualizados

The para-virtualized drivers can map physical floppy devices to fully virtualized guests. For more information on using para-virtualized drivers read Capítulo 13, Drivers para-virtualizados KVM.
Esta amostra usa um convidado criado com o virt-manager rodando com uma instalação do Red Hat Enterprise Linux inteiramente virtualizado com uma imagem localizada no /var/lib/libvirt/images/rhel5FV.img. O hypervisor Xen é usado nesta amostra.
  1. Crie o arquivo de configuração XML para sua imagem de convidado usando o comando virsh num convidado ativado.
    # virsh dumpxml rhel5FV > rhel5FV.xml
    
    This saves the configuration settings as an XML file which can be edited to customize the operations and devices used by the guest. For more information on using the virsh XML configuration files, refer to Capítulo 33, Criação dos scripts libvirt padronizados.
  2. Crie uma imagem de disquete para o convidado.
    # dd if=/dev/zero of=/var/lib/libvirt/images/rhel5FV-floppy.img bs=512 count=2880
    
  3. Add the content below, changing where appropriate, to your guest's configuration XML file. This example is an emulated floppy device using a file-based image.
    <disk type='file' device='floppy'>
    	<source file='/var/lib/libvirt/images/rhel5FV-floppy.img'/>
    	<target dev='fda'/>
    </disk>
    
  4. Force the guest to stop. To shut down the guest gracefully, use the virsh shutdown command instead.
    # virsh destroy rhel5FV
  5. Reinicialize o convidado usando o arquivo de configuração XML.
    # virsh create rhel5FV.xml
    
O dispositivo de disquete está disponível no convidado e armazenado como um arquivo de imagem no host.

9.2. Adicionando dispositivos de armazenamento aos convidados

Esta seção cobre a adição dos dispositivos de armazenamento à máquina convidada virtual. O armazenamento adicional pode ser apenas adicionado após os convidados serem criados. Os dispositivos de armazenamento suportados e protocolo incluem:
  • partições de disco rígido local;
  • volumes lógicos;
  • Canal de Fibra ou iSCSI diretamente conectado ao convidado;
  • os recipientes do arquivo residindo num sistema do arquivo no host;
  • sistemas de arquivo NFS montados diretamente pela máquina virtual;
  • o armazenamento iSCSI diretamente acessado pelo convidado.
  • Sistemas de Arquivo Cluster (GFS).
Adicionando o armazenamento baseado em arquivo ao convidado
O armazenamento de arquivo baseado ou recipientes de arquivo baseado são arquivos no sistema de arquivo dos hosts que agem como discos rígidos virtualizados para os convidados virtualizados. Para adicionar o recipiente de arquivo baseado, execute os seguintes passos:
  1. Crie um arquivo de recipiente vazio ou use um recipiente de arquivo existente (tal como um arquivo ISO).
    1. Crie um arquivo esparso usando o comando dd. Os arquivos esparsos não são recomendados devido à integridade de dados e problemas de execução. Os arquivos esparsos são criados muito mais rápidos e podem ser usados para testes, porém não devem ser usados em ambientes de produção.
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M seek=4096 count=0
      
    2. Os arquivos pré-alocados e não esparsos são recomendados para as imagens de armazenamento baseado em arquivo. Crie um arquivo não-esparso, executando:
      # dd if=/dev/zero of=/var/lib/libvirt/images/FileName.img bs=1M count=4096
      
    Both commands create a 4GB file which can be used as additional storage for a virtualized guest.
  2. Despeje a configuração para o convidado. Nesta amostra o convidado é chamado Guest1 e o arquivo é salvo no diretório principal dos usuários.
    # virsh dumpxml Guest1 > ~/Guest1.xml
    
  3. Abra o arquivo de configuração (Guest1.xml neste exemplo) no editor de texto. Encontre os elementos <disk>, estes elementos descrevem os dispositivos de armazenamento. Segue um exemplo de elemento de disco:
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    
  4. Insira o armazenamento adicional, duplicando ou criando um novo elemento <disk>. Assegure-se de que você especificou o nome do dispositivo para os atributos de dispositivo de bloco virtual. Estes atributos devem ser únicos a cada arquivo de configuração convidado. O exemplo a seguir é uma seção de arquivo de configuração, a qual contém um container de armazenamento com base de arquivo extra chamado FileName.img .
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/Guest1.img'/>
        <target dev='xvda'/>
    </disk>
    <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/var/lib/libvirt/images/FileName.img'/>
        <target dev='hda'/>
    </disk>
    
  5. Reinicialize o convidado a partir do arquivo de configuração atualizado.
    # virsh create Guest1.xml
    
  6. The following steps are Linux guest specific. Other operating systems handle new storage devices in different ways. For other systems, refer to that operating system's documentation
    The guest now uses the file FileName.img as the device called /dev/sdb. This device requires formatting from the guest. On the guest, partition the device into one primary partition for the entire device then format the device.
    1. Pressione n para uma nova partição.
      # fdisk /dev/sdb
      Command (m for help):
      
    2. Pressione p para uma partição primária.
      Command action
         e   extended
         p   primary partition (1-4)
      
    3. Escolha um número de partição disponível. Nesta amostra, a primeira partição é escolhida entrando 1.
      Partition number (1-4): 1
      
    4. Entre o primeiro cilindro padrão pressionando Enter.
      First cylinder (1-400, default 1):
      
    5. Selecione o tamanho da partição. Nesta amostra, o disco inteiro é alocado apenas pressionando Enter.
      Last cylinder or +size or +sizeM or +sizeK (2-400, default 400):
      
    6. Configure o tipo de partição pressionando t.
      Command (m for help): t
      
    7. Escolha a partição que você criou nos passos anteriores. Nesta amostra, ela é partição 1.
      Partition number (1-4): 1
      
    8. Entre 83 para uma partição de linux.
      Hex code (type L to list codes): 83
      
    9. Grave as alterações ao disco e saia.
      Command (m for help): w 
      Command (m for help): q
      
    10. Formate a nova partição com o sistema do arquivo ext3.
      # mke2fs -j /dev/sdb1
      
  7. Monte o disco no convidado.
    # mount /dev/sdb1 /myfiles
    
O convidado possui agora um dispositivo de armazenamento de arquivo virtualizado adicional.
Adição de discos rígidos e outros dispositivos de bloco a um convidado
System administrators use additional hard drives for to provide more storage space or to separate system data from user data. This procedure, Procedimento 9.1, “Adição de dispositivos de bloco físico para convidados virtualizados”, describes how to add a hard drive on the host to a virtualized guest.
O procedimento funciona para todos os dispositivos de bloco físico, incluindo CD-ROM, DVD e dispositivos de disquete.

Block device security

The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes the host system could be compromised.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Virtualized guests with access to block devices may be able to access other block devices on the system or modify volume labels which can be used to compromise the host system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this issue.
Procedimento 9.1. Adição de dispositivos de bloco físico para convidados virtualizados
  1. Anexe fisicamente o dispositivo de disco rígido ao convidado. Configure o host, caso o drive não seja acessível por padrão.
  2. Configure o dispositivo com multipath e persistência no host, caso solicitado.
  3. Use the virsh attach command. Replace: myguest with your guest's name, /dev/sdb1 with the device to add, and sdc with the location for the device on the guest. The sdc must be an unused device name. Use the sd* notation for Windows guests as well, the guest will recognize the device correctly.
    Append the --type cdrom parameter to the command for CD-ROM or DVD devices.
    Anexe o parâmetro --type floppy ao comando para os dispositivos de disquete.
    # virsh attach-disk myguest
    					/dev/sdb1
    					sdc --driver tap --mode readonly
    
  4. The guest now has a new hard disk device called /dev/sdb on Linux or D: drive, or similar, on Windows. This device may require formatting.

9.3. Configuração de armazenamento persistente no Red Hat Enterprise Linux 5

Esta seção é para sistemas com armazenamento externo ou com rede, ou seja, Canal de Fibra ou dispositivos de armazenamento baseado em iSCSI. Recomenda-se que estes sistemas possuam nomes de dispositivos persistentes configurados para os seus hosts. Isto auxilia a migração ativa assim como o fornecimento dos nomes do dispositivo consistente e armazenamento para os sistemas múltiplos virtualizados.
Identificadores Únicos Universais - Universally Unique Identifiers (UUIDs) são um método padronizado para os computadores de identificação e dispositivos em ambientes de computação distribuídos. Estas seções usam os UUIDs para identificar o iSCSI ou LUNs de Canal de Fibra. Os UUIDs persistem após reinicializações, desconexão ou trocas de dispositivos. O UUID se parece com uma etiqueta no dispositivo.
Systems which are not running multipath must use Configurações de caminho único. Systems running multipath can use Configuração de caminho múltiplo.
Configurações de caminho único
This procedure implements LUN device persistence using udev. Only use this procedure for hosts which are not using multipath.
  1. Edite o arquivo /etc/scsi_id.config.
    1. Garanta que o options=-b é uma linha comentada.
      # options=-b
      
    2. Adicione a seguinte linha:
      options=-g
      
      Esta opção configura o udev para assumir que todos os dispositivos SCSI anexados retornam ao UUID.
  2. Para exibir o UUID a um dispositivo gerado, rode o comando scsi_id -g -s /block/sd*. Por exemplo:
    # scsi_id -g -s /block/sd*
    3600a0b800013275100000015427b625e
    
    O resultado pode variar do exemplo acima. O resultado executa o UUID do /dev/sdc do dispositivo.
  3. Certifique-se que o resultado UUID do comando scsi_id -g -s /block/sd* é idêntico ao do computador que acessa o dispositivo.
  4. Crie uma regra ao nome do dispositivo. Crie um 20-names.rules de arquivo nomeado no diretório /etc/udev/rules.d. Adicione novas regras a este arquivo. Todas as regras são adicionadas ao mesmo arquivo usando o mesmo formato. As regras seguem o formato abaixo:
    KERNEL=="sd[a-z]", BUS=="scsi", PROGRAM="/sbin/scsi_id -g -s /block/%k", RESULT="UUID", NAME="devicename"
    
    Substitua o UUID e devicename com o UUID restaurado acima e um nome para um dispositivo. Esta é uma regra para os exemplos acima:
    KERNEL="sd*", BUS="scsi", PROGRAM="/sbin/scsi_id -g -s", RESULT="3600a0b800013275100000015427b625e", NAME="rack4row16"
    
    O udev daemon procura agora por todos os dispositivos nomeados /dev/sd* para o UUID na regra. Assim que um dispositivo de combinação é conectado ao sistema, o dispositivo determina o nome a partir da regra. No dispositivo com um UUDI de 3600a0b800013275100000015427b625e, aparecerá como /dev/rack4row16.
  5. Anexe esta linha ao /etc/rc.local:
    /sbin/start_udev
    
  6. Copie as alterações nos arquivos /etc/scsi_id.config, /etc/udev/rules.d/20-names.rules e /etc/rc.local para todos os hosts relevantes.
    /sbin/start_udev
    
Os dispositivos de armazenamento da rede com regras configuradas, possuem agora nomes persistentes em todos os hosts onde os arquivos foram atualizados. Isto significa que você pode migrar convidados entre hosts usando armazenamento compartilhado e os convidados podem acessar os dispositivos de armazenamento nos próprios arquivos de configuração.
Configuração de caminho múltiplo
O pacote multipath é usado para os sistemas com mais de um caminho físico a partir do computador com dispositivos de armazenamento. O multipath fornece tolerância de defeito, falha e desempenho aprimorado para os dispositivos de armazenamento da rede anexados aos sistemas do Red Hat Enterprise Linux.
Implementing LUN persistence in a multipath environment requires defined alias names for your multipath devices. Each storage device has a UUID which acts as a key for the aliased names. Identify a device's UUID using the scsi_id command.
# scsi_id -g -s /block/sdc
Os dispositivos de caminho múltiplo serão criados no diretório /dev/mpath. No exemplo abaixo, 4 dispositivos são definidos no /etc/multipath.conf:
multipaths { 
	multipath { 
	wwid		3600805f30015987000000000768a0019 
	alias		oramp1 
	} 
	multipath { 
	wwid		3600805f30015987000000000d643001a 
	alias		oramp2 
	} 
	mulitpath { 
	wwid		3600805f3001598700000000086fc001b 
	alias		oramp3 
	} 
	mulitpath { 
	wwid		3600805f300159870000000000984001c 
	alias		oramp4 
	} 
}
This configuration will create 4 LUNs named /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3 and /dev/mpath/oramp4. Once entered, the mapping of the devices' WWID to their new names are now persistent after rebooting.

9.4. Adicione um CD-ROM virtualizado ou dispositivo DVD a seu convidado

To attach an ISO file to a guest while the guest is online use virsh with the attach-disk parameter.
# virsh attach-disk [domain-id] [source] [target] --driver file --type cdrom --mode readonly
The source and target parameters are paths for the files and devices, on the host and guest respectively. The source parameter can be a path to an ISO file or the device from the /dev directory.

Capítulo 10. Configuração de Rede

Esta página fornece uma introdução às configurações de rede comum usadas pelos aplicativos libvirt baseados. Esta informação aplica-se a todos hypervisors, independente de ser Xen, KVM ou outro. Para informação adicional consulte os docs de arquitetura de rede libvirt.
As duas configurações comuns são "rede virtual" ou "dispositivo físico compartilhado". O primeiro é idêntico em todos os distribuidores e disponível imediatamente . O segundo precisa da configuração manual específica da distribuição.
Network services on virtualized guests are not accessible by default from external hosts. You must enable either Network address translation (NAT) ir a network Bridge to allow external hosts access to network services on virtualized guests.

10.1. A tradução do endereço da rede (NAT) com libvirt

Um dos métodos mais comuns das conexões de rede compartilhadas é usar a remessa da tradução do endereço da rede - network address translation (NAT) (também conhecida como redes virtuais).
Configuração do Host
Every standard libvirt installation provides NAT based connectivity to virtual machines out of the box. This is the so called 'default virtual network'. Verify that it is available with the virsh net-list --all command.
# virsh net-list --all
Name                 State      Autostart 
-----------------------------------------
default              active     yes
Caso seja ausente, o arquivo de configuração XML pode ser recarregado e ativado:
# virsh net-define /usr/share/libvirt/networks/default.xml
A rede padrão é definida a partir do /usr/share/libvirt/networks/default.xml
Marque a rede padrão para inicializar automaticamente:
# virsh net-autostart default
Network default marked as autostarted
Inicialize a rede padrão:
# virsh net-start default
Network default started
Quando a rede padrão libvirt estiver operando, você verá um dispositivo ponte isolado. Este dispositivo não possui interfaces físicas adicionadas, pois ele usa as remessas NAT e IP para conectar-se com o mundo. Não adicione novas interfaces.
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
libvirt adiciona as regras iptables que permitem o tráfego para e a partir de convidados anexados ao dispositivo virbr0 nas cadeias INPUT, FORWARD, OUTPUT e POSTROUTING. O libvirt tenta ativar o parâmetro ip_forward. Alguns outros aplicativos poderão desativar o ip_forward, portanto a melhor opção é adicionar o abaixo ao /etc/sysctl.conf.
 net.ipv4.ip_forward = 1
Configuração Convidada
Once the host configuration is complete, a guest can be connected to the virtual network based on its name. To connect a guest to the 'default' virtual network, the following XML can be used in the guest:
<interface type='network'>
  <source network='default'/>
</interface>

Nota

A definição de um endereço MAC é opcional. O endereço MAC é automaticamente gerado, caso seja omitido. A configuração manual do endereço MAC é útil em certas situações.
<interface type='network'>
  <source network='default'/>
  <mac address='00:16:3e:1a:b3:4a'/>
  </interface>

10.2. Pontes de rede com o libvirt

A Rede com ponte (também conhecida como compartilhamento de dispositivo físico) é usada para dedicar um dispositivo físico à uma máquina virtual. A Ponte é normalmente usada para configurações mais avançadas e em servidores com interfaces de rede múltiplas.
Scripts de rede Xen desativados
Se o seu sistema usou uma ponte Xen, é recomendável desativar a ponte de rede Xen padrão pela edição /etc/xen/xend-config.sxp e alteração da linha:
 (network-script network-bridge)
To:
 (network-script /bin/true)
Desative o NetworkManager
NetworkManager does not support bridging. Running NetworkManager will overwrite any manual bridge configuration. Because of this, NetworkManager should be disabled in order to use networking via the network scripts (located in the /etc/sysconfig/network-scripts/ directory):
# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

Nota

As an alternative to turning off NetworkManager, add "NM_CONTROLLED=no" to the ifcfg-* scripts used in the examples. If you do not either set this parameter or disable NetworkManager entirely, any bridge configuration will be overwritten and lost when NetworkManager next starts.
Criando os initscripts da rede
Crie ou edite os dois arquivos seguintes de configuração da rede. Este passo pode ser repetido (com nomes diferentes) para pontes de redes adicionais.
Altere o diretório /etc/sysconfig/network-scripts:
# cd /etc/sysconfig/network-scripts
Abra o script para o dispositivo que você está adicionando à ponte. Neste exemplo, o ifcfg-eth0 define a interface de rede física que é ajustada como parte de uma ponte:
DEVICE=eth0
# change the hardware address to match the hardware address your NIC uses
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
BRIDGE=br0

Tip

You can configure the device's Maximum Transfer Unit (MTU) by appending an MTU variable to the end of the configuration file.
MTU=9000
Cria um novo script de rede no diretório /etc/sysconfig/network-scripts chamado ifcfg-br0 ou similar. O br0 é o nome da ponte, ele pode ser qualquer coisa, contando que o nome do arquivo seja o mesmo ao do parâmetro do DISPOSITIVO.
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

IP address configuration

IP address configuration, be it dynamic or static, should be configured on the bridge itself (for example, in the ifcfg-br0 file). Network access will not function as expected if IP address details are configured on the physical interface that the bridge is connected to.

Aviso

The line, TYPE=Bridge, is case-sensitive. It must have uppercase 'B' and lower case 'ridge'.
Após a configuração, reinicialize a rede ou reinicialize o computador.
# service network restart
Configure o iptables para permitir que todos os tráfegos sejam enviados através da ponte.
# iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Desative os iptables nas pontes

Como forma alternativa, evite que o tráfego com ponte seja processado pelas regras iptables. Anexe as seguintes linhas ao /etc/sysctl.conf:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Recarregue os parâmetros do kernel configurados com sysctl.
# sysctl -p /etc/sysctl.conf
Reinicialize o libvirt daemon.
# service libvirtd reload
Você deve possuir agora um "dispositivo físico compartilhado", que os convidados podem ser anexados e possuem acesso LAN completo. Verifique a sua nova ponte:
# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0
Perceba que, a ponte é completamente independente da ponte virbr0. Não tente anexar um dispositivo físico ao virbr0. A ponte virbr0 é apenas para a conectividade da Tradução do Endereço de Rede (NAT).

Capítulo 11. Rede Xen do Pré-Red Hat Enterprise Linux 5.4

Este capítulo cobre os tópicos especiais para a rede e configuração da rede como hypervisor Xen.
Most guest network configuration occurs during the guest initialization and installation process. To learn about configuring networking during the guest installation process, read the relevant sections of the installation process, Capítulo 7, Visão Geral da Instalação do convidado virtualizado.
Network configuration is also covered in the tool specific reference chapters for virsh (Capítulo 25, Gerenciando convidados com virsh) and virt-manager (Capítulo 26, Gerenciando convidados com o Gestor de Máquina Virtual (virt-manager)). Those chapters provide a detailed description of the networking configuration tasks using both tools.

Tip

Using para-virtualized network drivers improves performance on fully virtualized Linux guests. Capítulo 12, Drivers Xen Para-virtualizados explains how to utilize para-virtualized network drivers.

11.1. Configuração das pontes de rede convidadas múltiplas para uso de cartões Ethernet múltiplos

Processo para configurar as pontes de rede (com o hypervisor Xen):
  1. Configure outra interface de rede usando qualquer aplicativo system-config-network. Alternativamente, crie uma nova configuração ifcfg-ethX de arquivo nomeado no diretório /etc/sysconfig/network-scripts/ onde o X é um número que ainda não está em uso. Segue abaixo, uma amostra do arquivo de configuração para uma segunda interface de rede chamada eth1.
    $ cat /etc/sysconfig/network-scripts/ifcfg-eth1
    DEVICE=eth1
    BOOTPROTO=static
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    GATEWAY=10.1.1.254
    ARP=yes
    
  2. Copie o arquivo, /etc/xen/scripts/network-bridge, para /etc/xen/scripts/network-bridge.xen.
  3. Comment out any existing network scripts in /etc/xen/xend-config.sxp and add the line (network-xen-multi-bridge). A typical xend-config.sxp file should have the following line. Comment this line out. Use the # symbol to comment out lines.
    network-script network-bridge
    
    Below is the commented out line and the new line, containing the network-xen-multi-bridge parameter to enable multiple network bridges.
    #network-script network-bridge
    network-script network-xen-multi-bridge
  4. Create a script to create multiple network bridges. This example creates a script called network-xen-multi-bridge.sh in the /etc/xen/scripts/ directory. A sample scripts is below, this example script will create two Xen network bridges (xenbr0 and xenbr1) one will be attached to eth1 and the other one to eth0. If you want to create additional bridges just follow the example in the script and copy nad paste the lines as required:
    #!/bin/sh
    # network-xen-multi-bridge
    # Exit if anything goes wrong.
    set -e
    # First arg is the operation.
    OP=$1
    shift
    script=/etc/xen/scripts/network-bridge.xen
    case ${OP} in
    start)
    	$script start vifnum=1 bridge=xenbr1 netdev=eth1
    	$script start vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    stop)
    	$script stop vifnum=1 bridge=xenbr1 netdev=eth1
    	$script stop vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    status)
    	$script status vifnum=1 bridge=xenbr1 netdev=eth1
    	$script status vifnum=0 bridge=xenbr0 netdev=eth0
    	;;
    *)
    	echo 'Unknown command: ' ${OP}
    	echo 'Valid commands are: start, stop, status'
    	exit 1
    esac
    
  5. Make the script executable.
    # chmod +x /etc/xen/scripts/network-xen-multi-bridge.sh
  6. Restart networking or restart the system to activate the bridges.
    # service network restart
Multiple bridges should now be configured for guests on the Xen hypervisor.

11.2. Configuração da rede de laptop do Red Hat Enterprise Linux 5.0

Para o Red Hat Enterprise Linux 5.1 ou mais avançado

Esta seção descreve a adição manual de pontes de rede. Este procedimento não é solicitado ou recomendado para todas as versões do Red Hat Enterprise Linux mais recentes do que a versão 5.0. Para as versões mais novas use os adaptadores "Virtual Network" ao criar os convidados no virt-manager. O NetworkManager funciona com os dispositivos de rede virtual por padrão no Red Hat Enterprise Linux 5.1 e mais recentes.
Uma amostra de um arquivo de configuração do XML para um dispositivo de rede virtual:
<interface type='network'>
	<mac address='AA:AA:AA:AA:AA:AA'/>
	<source network='default'/>
	<target dev='vnet0'/>
	<model type='virtio'/>
</interface>
Nos arquivos de configuração xm, os dispositivos de rede virtual são etiquetados com "vif".
The challenge in running the Xen hypervisor on a laptop is that most laptops will connected to the network via wireless network or wired connections. Often these connections are switched multiple times a day. In such an environment, the system assumes it has access to the same interface all the time and it also can perform ifup or ifdown calls to the network interface it is using. In addition wireless network cards do not work well in a virtualization environment due to Xen's (default) bridged network usage.
Esta configuração permitirá também que você rode o Xen no modo offline quando você não tiver conexão ativa no seu laptop. A solução mais fácil para rodar o Xen num laptop é seguir o procedimento descrito abaixo:
  • You will be configuring a 'dummy' network interface which will be used by Xen. In this example the interface is called dummy0. This will also allow you to use a hidden IP address space for your guests.
  • Você precisará usar o endereço de IP estático, pois o DHCP não escutará na interface fictícia de solicitações DHCP. Você pode compilar sua própria versão do DHCP para escutar nas interfaces fictícias, no entanto você poderá observar no dnsmasq pelos serviços DNS, DHCP e tftpboot num ambiente Xen. Instalação e configuração são explicados adiante nesta seção/capítulo.
  • Você pode configurar o NAT e IP mascarado, com o objetivo de ativar o acesso à rede a partir dos convidados.
Configurando uma interface de rede fictícia
Execute os seguintes passos de configuração no seu host:
  1. Crie uma interface de rede dummy0 e determine um endereço IP. Na nossa amostra I selecionou 10.1.1.1 para evitar os problemas de roteamento em seu ambiente. Para ativar o suporte de dispositivo fictício, adicione as seguintes linhas ao /etc/modprobe.conf.
    alias dummy0 dummy
    options dummy numdummies=1
    
  2. Para configurar a rede para o dummy0 edite/crie /etc/sysconfig/network-scripts/ifcfg-dummy0:
    DEVICE=dummy0
    BOOTPROTO=none
    ONBOOT=yes
    USERCTL=no
    IPV6INIT=no
    PEERDNS=yes
    TYPE=Ethernet
    NETMASK=255.255.255.0
    IPADDR=10.1.1.1
    ARP=yes
    
  3. Vincule o xenbr0 para dummy0, de forma que você possa usar a rede mesmo quando não conectado a uma rede física. Edite /etc/xen/xend-config.sxp para incluir a entrada netdev=dummy0:
    (network-script 'network-bridge bridge=xenbr0 netdev=dummy0')
    
  4. Open /etc/sysconfig/network in the guest and modify the default gateway to point to dummy0. If you are using a static IP, set the guest's IP address to exist on the same subnet as dummy0.
    NETWORKING=yes
    HOSTNAME=localhost.localdomain
    GATEWAY=10.1.1.1
    IPADDR=10.1.1.10
    NETMASK=255.255.255.0
    
  5. Configurando um NAT no host permitirá que os convidados acessem a Internet, incluindo sem fio, resolvendo o Xen e os problemas de placa wireless. O script abaixo ativará o NAT baseado na interface atualmente usada para a sua conexão de rede.
Configurando NAT para os convidados virtualizados
A tradução do endereço de rede (NAT) permite que endereços múltiplos conectem através de um endereço IP único pela intercepção de pacotes e passando-os ao endereço IP privado. Você pode copiar o seguinte script ao /etc/init.d/xenLaptopNAT e criar um link leve ao /etc/rc3.d/S99xenLaptopNAT. Isto iniciará automaticamente o NAT no período de inicialização.

NetworkManager e NAT sem fio

O script abaixo talvez não funcione bem com a rede sem fio ou NetworkManager devido a atrasos. Neste caso, rode o script manualmente uma vez a máquina tenha sido inicializada.
#!/bin/bash
PATH=/usr/bin:/sbin:/bin:/usr/sbin
export PATH
GATEWAYDEV=`ip route | grep default | awk {'print $5'}`
iptables -F
case "$1" in
start)
	if test -z "$GATEWAYDEV"; then
	echo "No gateway device found"
    else
	echo  "Masquerading using $GATEWAYDEV"
	/sbin/iptables -t nat -A POSTROUTING -o $GATEWAYDEV -j MASQUERADE
fi
	echo "Enabling IP forwarding"
	echo 1 > /proc/sys/net/ipv4/ip_forward
	echo "IP forwarding set to `cat /proc/sys/net/ipv4/ip_forward`"
	echo "done."
	;;
*)
echo "Usage: $0 {start|restart|status}"
;;
esac
Configurando dnsmasq para os serviços DNS, DHCP e tftpboot.
Um dos desafios ao executar a tecnologia de virtualização num laptop (ou qualquer outro computador que não esteja conectado por uma conexão de rede estável ou única) é a troca nas interfaces de rede e disponibilidade. O uso de uma interface de rede fictícia, ajudará a construir um ambiente mais estável, mas isto trará novos desafios no fornecimento dos serviços DHCP, DNS e tftpboot às suas máquinas/convidados virtuais. O DHCP daemon padrão distribuído com o Red Hat Eterprise Linux e Fedora Core não escutarão nas interfaces fictícias, sua informação enviada DNS poderá alterar assim que você conectar-se a diferentes redes e VPNs.
Uma solução aos desafios acima é o uso do dnsmasq que pode fornecer todos os serviços acima num pacote único e também permitir que você controle seus serviços apenas estando disponível a sua interface fictícia. Segue abaixo, um trecho pequeno de como configurar dnsmasq num laptop rodando a virtualização:
  • Obtenha a última versão do dnsmasq a partir do aqui.
  • Documentation for dnsmasq can be found here.
  • Copy the other files referenced below from http://et.redhat.com/~jmh/tools/xen/ and grab the file dnsmasq.tgz. The tar archive includes the following files:
    • O nm-dnsmasq pode ser usado como um script despachante para o NetworkManager. Isto será rodado a cada instante que o NetworkManager detectar uma alteração à conectividade e forçar uma reinicialização/recarregamento do dnsmasq. Ele deve ser copiado ao /etc/NetworkManager/dispatcher.d/nm-dnsmasq;
    • O xenDNSmasq pode ser usado como um script de inicialização ou desligamento principal para o /etc/init.d/xenDNSmasq;
    • O dnsmasq.conf é uma amostra de arquivo de configuração para o /etc/dnsmasq.conf;
    • O dnsmasq é uma inagem binária para o /usr/local/sbin/dnsmasq.
  • Uma vez que você tenha desempacotado e construído o dnsmasq (a instalação padrão será a binária no /usr/local/sbin/dnsmasq), você precisará editar seu arquivo de configuração dnsmasq. O arquivo é alocado no /etc/dnsmaqs.conf.
  • Edite a configuração para suprir suas necessidades locais e solicitações. Os parâmetros seguintes são, provavelmente, os que você desejará modificar:
    • o parâmetro interface permite o dnsmasq escutar pelas solicitações DHCP e DNS apenas nas interfaces solicitadas. Elas poderão ser interfaces fictícias, mas não suas interfaces públicas ou a interface loopback local. Adicione outra linha de interface para mais de uma interface. O interface=dummy0 é uma amostra de escuta na interface dummy0;
    • o dhcp-range para ativar o servidor DHCP integrado, você precisará suprir a variedade de endereços disponíveis para aluguel e, opcionalmente, um período de aluguel. Caso você possua mais que uma rede, você precisará repetir isto para cada rede que você queira suprir o serviço DHCP. Uma amostra pode ser o (para rede 10.1.1.* e período de aluguel de 12hrs): dhcp-range=10.1.1.10,10.1.1.50,255.255.255.0,12h;
    • o dhcp-option para substituir a rota padrão fornecida pelo dnsmasq, que assume que o roteador é a mesma máquina àquela rodando o dnsmasq. Uma amostra pode ser o dhcp-option=3,10.1.1.1.
  • Após a configuração dnsmasq, você poderá copiar o script abaixo como xenDNSmasq ao /etc/init.d
  • Caso você deseje inicializar automaticamente o dnsmasq durante a inicialização do sistema, você deverá registrá-lo usando o chkconfig(8):
    chkconfig --add xenDNSmasq
    
    Ative isto para inicialização automática:
    chkconfig --levels 345 xenDNSmasq on
    
  • Para configurar o dnsmasq para reinicializar a cada momento que o NetworkManager detectar uma alteração na conectividade, você poderá usar o nm-dnsmasq de script fornecido.
    • Copie o script nm-dnsmasq para o /etc/NetworkManager/dispatcher.d/;
    • O despachante NetworkManager executará o script (em ordem alfabética caso você tenha outros scripts no mesmo diretório) a cada instante que existir uma alteração na conectividade.
  • O dnsmasq detectará também as alterações no seu /etc/resolv.conf e automaticamente recarregá-las (quer dizer, se você inicializar uma sessão VPN por exemplo).
  • Ambos os scripts nm-dnsmasq e xenDNSmasq configurarão o NAT, caso você tenha seus convidados virtualizados numa rede oculta para permití-los acessar à rede pública.

Capítulo 12. Drivers Xen Para-virtualizados

Para-virtualized drivers provide increased performance for fully virtualized Red Hat Enterprise Linux guests. Use these drivers if you are using fully virtualized Red Hat Enterprise Linux guests and require better performance.

Outros drivers para-virtualizados

Estes são outros drivers para-virtualizados para o Windows para os hipervisors Xen e KVM.
Para convidados Windows em hosts Xen, consulte o Guia de Drivers Windows Para-virtualizados, o qual trata sobre a instalação e administração.
For Windows guests on KVM hosts, refer to Capítulo 13, Drivers para-virtualizados KVM.
Os pacotes RMP para os drivers para-virtualizados incluem os módulos para drivers de armazenamento e rede de trabalho paravirtualizados para os sistemas operacionais convidados do Red Hat Enterprise Linux suportados. Estes drivers possibilitam alto desempenho em operações de Entrada/Saída em sistemas operacionais convidados do Red Hat Enterprise Linux que não foram modificados no host do Red Hat Enterprise Linux 5.1 (ou acima deste).
Os sistemas operacionais convidados suportados são:
  • Red Hat Enterprise Linux 3
  • Red Hat Enterprise Linux 4
  • Red Hat Enterprise Linux 5

Suporte de arquitetura para drivers para-virtualizados.

Os requerimentos mínimos do sistema operacional são dependentes de arquitetura. Somente os convidados x86 e x86-64 são suportados.
Os drivers não são suportados nos sistemas operacionais convidados do Red Hat Enterprise Linux anteriores ao Red Hat Enterprise Linux 3.
O uso do Red Hat Enterprise Linux 5 como plataforma de virtualização, permite que os Administradores de Sistemas consolidem a carga de trabalho do Linux e Windows em um hardware mais potente e mais novo, com maior potência e eficiência de diminuição de temperatura. Os sistemas operacionais convidados Red Hat Enterprise Linux 4 (a partir da atualização 6) e o Red Hat Enterprise Linux 5, conhecem a tecnologia de virtualização adjacente e podem interagir com ela de forma eficiente, usando interfaces e capacidades específicas. Esta ação pode alcançar características de rítmo de transferência e desempenho comparados à execução em um sistema bare metal.
As para-virtualization requires a modified guest operating system, not all operating systems can use para-virtualization. For operating systems which can not be modified, full virtualization is required. Full virtualization, by default, uses emulated disk, network, video and other hardware devices. Emulated I/O devices can be very slow and are not suited for applications requiring high disk and/or network throughput. The majority of the performance loss with virtualization occurs through the use of emulated devices.
As unidades de dispositivos para-virtualizados estão inclusos nos pacotes do Red Hat Enterprise Linux. Os drivers oferecem muitas vantagens de desempenho para sistemas operacionais convidados para-virtualizados para sistemas operacionais não modificados, pois somente o driver de dispositivo para-virtualizado (e não o resto dos sistemas operacionais) sabe da plataforma de virtualização adjacente.
Depois de instalar os drivers de dispositivo para-virtualizados, um dispositivo de disco ou placa de rede, continuarão a parecer um disco físico normal ou placa de rede para o sistema operacional. No entanto, agora o driver de dispositivo interage diretamente com a plataforma de virtualização (sem emulação) para entregar acesso à disco e rede de forma eficiente, permitindo que os subsistemas de disco e rede operem em velocidade quase original, até em um ambiente virtualizado, sem precisar de mudanças em sistemas operacionais convidados existentes.
Os drivers para-virtualizados possuem certos requerimentos de host. Hosts de 64 bits podem ser executados:
  • 32 bit guests.
  • 64 bit guests.
  • mesclagem de convidados de 32 bits e 64 bits.

12.1. Solicitações de Sistema

Esta seção fornece requerimentos para drivers para-virtualizados com o Red Hat Enterprise Linux.
Instalação
Antes de você instalar os drivers para-virtualizados, deve-se checar os seguintes requerimentos (listados abaixo).

Red Hat Enterprise Linux 4.7 e 5.3 e mais recentes

Todas as versões do Red Hat Enterprise Linux a partir do 4.7 e 5.3 possuem módulo de kernel para os drivers para-virtualizados, o módulo pv-on-hvm, no pacote kernel padrão. Isto significa que os drivers para-virtualizados estão disponíveis para o Red Hat Enterprise Linux 4.7 e mais recentes ou o 5.3 e convidados mais recentes.
Você precisará dos seguintes pacotes de RPM para os drivers para-virtualizados para cada instalação de sistema operacional convidado.
Minimum host operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
Minimum guest operating system version:
  • Red Hat Enterprise Linux 5.1 or newer.
  • Red Hat Enterprise Linux 4 Update 6 or newer.
  • Red Hat Enterprise Linux 3 Update 9 or newer.
Red Hat Enterprise Linux 5 requires:
  • kmod-xenpv.
Red Hat Enterprise Linux 4 requires:
  • kmod-xenpv,
  • modules-init-tools (for versions prior to Red Hat Enterprise Linux 4.6z you require modules-init-tools-3.1-0.pre5.3.4.el4_6.1 or greater), and
  • modversions.
Red Hat Enterprise Linux 3 requires:
  • kmod-xenpv.
You require at least 50MB of free disk space in the /lib file system.

12.2. Restrições e Suporte para a Tecnologia de Para-Virtualização

Esta seção trata sobre restrições de suporte e requerimentos para o uso de drivers para-virtualizados no Red Hat Enterprise Linux. O que suportamos e as restrições de suporte podem ser encontradas nas seções abaixo.
Sistemas Operacionais Convidados Suportados
Suporte para os drivers para-virtualizados está disponível para os seguintes sistemas operacionais e versões:
  • Red Hat Enterprise Linux 5.1 e mais novos
  • Red Hat Enterprise Linux 4 Update 6 e mais novos
  • Red Hat Enterprise Linux 3 Atualização 9 e outros mais recentes.
Você possui suporte para executar um sistema operacional convidado de 32 bits com os drivers para-virtualizados na Tecnologia de Virtualização do Red Hat Enterprise Linux 5 de 64 bits.
A tabela abaixo indica as variantes do kernel suportadas com os drivers para-virtualizados. Você pode usar o comando exibido abaixo para identificar a revisão do kernel exata atualmente instalada em seu host. Compare o resultado com a tabela para determinar se é suportado.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
O Red Hat Enterprise Linux 5 com variantes de kernel i686 e x86_64, incluem Symmetric Multiprocessing(SMP), não é necessário um RPM de kernel SMP separado.
Tome nota do processador dos requerimentos do kernel específico para os Convidados do Red Hat Enterprise Linux 3 na tabela abaixo.
Tabela 12.1. As arquiteturas do kernel convidado suportadas para os drivers para-virtualizados
Arquitetura do Kernel Red Hat Enterprise Linux 3 Red Hat Enterprise Linux 4 Red Hat Enterprise Linux 5
athlon Suportado (AMD)   
athlon-SMP Suportado (AMD)   
i32e Suportado (Intel)   
i686 Suportado (Intel) Suportado Suportado
i686-PAE Suportado
i686-SMP Suportado (Intel) Suportado  
i686-HUGEMEM Suportado (Intel) Suportado  
x86_64 Suportado (AMD) Suportado Suportado
x86_64-SMP Suportado (AMD) Suportado  
x86_64-LARGESMP Suportado  
Itanium (IA64) Suportado

Importante

O sistema host requer um Red Hat Enterprise Linux 5.1 ou mais recente.

Encontrando o kernel que você está usando

Tome nota do resultado do comando abaixo ou lembre-a mais tarde. Este é o valor que determina quais pacotes e módulos você precisa para fazer o download.
# rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
Seu resultado deve se parecer com este:
kernel-PAE-2.6.18-53.1.4.el5.i686
O nome do kernel é PAE ( uma abreviação para Physical Address Extensions), a versão do kernel é 2.6.18, o lançamento é 53.1.4.el5 e a arquitetura é i686. O rpm do kernel deve sempre ser em formato kernel-name-version-release.arch.rpm.
Restrições Importantes
Os drivers do dispositivo para-virtualizado podem ser instalados após instalar um sistema operacional convidado com sucesso. Você irá precisar de um host funcionando e um convidado antes que possa instalar estes drivers.

Dispositivos de bloco para-virtualizados e GRUB

GRUB não pode acessar atualmente dispositivos de bloco para-virtualizados. Portanto, um convidado não pode ser inicializado de um dispositivo que usa os drivers de dispositivo de bloco para-virtualizados. Especialmente, o disco que contém o Master Boot Record(MBR), um disco que contém um carregador de inicialização (GRUB), ou um disco que contém as imagens initrd do kernel. Ou seja, qualquer disco que contenha o diretório ou partição /boot não pode usar os drivers de dispositivos de bloco para-virtualizados.
As dependências de arquiteturas de variantes do kernel do Red Hat Enterprise Linux 3
Para o Red Hat Enterprise Linux 3, com sistemas operacionais convidados, você deve usar o kernel específico do processador e RPMs de driver para-virtualizados como mencionado nas tabelas abaixo. Caso ocorra erro ao instalar, a carga do pacote de driver para-virtualizado coincidente do módulo xen-pci-platform irá falhar.
A tabela abaixo demonstra qual kernel do host é necessário para executar um Red Hat Enterprise Linux 3 convidado, se o conficado for compilado para um processador Intel.
Tabela 12.2. A arquitetura do kernel do host necessária para convidados, usando os drivers para-virtualizados no Red Hat Enterprise Linux 3 para processadores Intel.
Tipo de kernel convidado Tipo de kernel do host necessário
ia32e (UP e SMP) x86_64
i686 i686
i686-SMP i686
i686-HUGEMEM i686

A tabela abaixo demonstra qual kernel de host é necessário para executar um Red Hat Enterprise Linux 3 convidado, se o convidado foi compilado por um processador AMD.
Tabela 12.3. As arquiteturas do kernel do host necessárias para convidados usando drivers para-virtualizados em Red Hat Enterprise Linux 3 para processadores AMD.
Tipo de kernel convidado Tipo de kernel do host necessário
athlon i686
athlon-SMP i686
x86_64 x86_64
x86_64-SMP x86_64

12.3. Instalando os Drivers Para-virtualizados

Os três seguintes capítulos descrevem como instalar e configurar seus convidados totalmente virtualizados para ser executado no Red Hat Enterprise Linux 5.1 ou acima deste para drivers para-virtualizados.

Verifique se sua arquitetura é suportada antes de proceder

Os drivers para-virtualizados são somente suportados em certos hardwares e combinações de versão. Verifique se seu hardware e sistema operacional condizem com os requerimentos antes de proceder a instalação dos drivers para-virtualizados.

Maximizar os benefícios dos drivers para-virtualizados para as novas instalações

Se você estiver instalando um novo sistema convidado, para obter o máximo benefício dos driver de dispositivo de bloco para-virtualizados, você deve criar um convidado com ao menos dois discos.
O uso dos drivers para-virtualizados para o disco que contém o MBR e o carregador de inicialização (GRUB), e para a partição /boot. Esta partição pode ser muito pequena, pois somente precisa ter capacidade suficiente para deter a partição /boot.
Use o segundo disco e quaisquer outros discos para todos as outras partições (por exemplo, /, /usr) ou volumes lógicos.
O uso deste método de instalação, quando os driver so dispositivo de bloco para-virtualizado for instalado mais tarde após completar a instalação do convidado, inicializar somente os convidados e acessar a partição /boot, irá usar os drivers de dispositivo de bloco virtualizado.

12.3.1. Passos da instalação comum

A lista abaixo inclui os passos de alto nível comuns em todas as versões de sistema operacional convidado.
  1. Copy the RPMs for your hardware architecture to a suitable location in your guest operating system. Your home directory is sufficient. If you do not know which RPM you require verify against the table at Seção 12.2, “Restrições e Suporte para a Tecnologia de Para-Virtualização”.
  2. Use o comando rpm ou o comando yum para instalar os pacotes. O utilitário rpm irá instalar os quatro seguintes módulos de kernel novos em /lib/modules/[%kversion][%kvariant]/extra/xenpv/%release:
    • the PCI infrastructure module, xen_platform_pci.ko,
    • the ballooning module, xen_balloon.ko,
    • the virtual block device module, xen_vbd.ko,
    • and the virtual network device module, xen_vnif.ko.
  3. Se o convidado que estiver operando não suportar carregamento automaticamente, os drivers para-virtualizados (por exemplo, Red Hat Enterprise Linux 3) realizará os passos de pós instalação requeridos para copiar os drivers para os locais específicos do sistema operacional.
  4. Feche seu sistema operacional convidado.
  5. Reconfigure the guest operating system's configuration file on the host to use the installed para-virtualized drivers.
  6. Remova a entrada “type=ioemu” para o dispositivo de rede.
  7. Add any additional disk partitions, volumes or LUNs to the guest so that they can be accessed via the para-virtualized (xen-vbd) disk driver.
  8. For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
  9. A typical disk entry resembles the following:
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/dev/hda6'/>
      <target dev='hda'/>
    </disk>
    
    Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
    <disk type='file' device='disk'>
      <driver name='tap' type='aio'/>
      <source file='/dev/hda6'/>
      <target dev='xvda'/>
    </disk>
    
  10. Adicione quaisquer entidades de armazenamento adicionais que você desejar usar para o driver de dispositivo de bloco para-virtualizado.
  11. Reinicie seu convidado:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.
  12. Reconfigure the guest network.

12.3.2. Instalação e Configuração dos Drivers Para-virtualizados no Red Hat Enterprise Linux 3

Esta seção contém instruções detalhadas para os drivers para-virtualizados no sistema operacional convidado Red Hat Enterprise 3

Nota

Estes pacotes não suportam a inicialização de um disco para-virtualizado. Para inicializar o kernel do sistema operacional convidado, você precisa usar o driver emulado IDE, enquanto qualquer outro (não sistema) aplicativo de espaço de usuário e dados pode usar os drivers de dispositivo de bloco para-virtualizado.
Instalação do Driver
A lista abaixo se refere aos passos necessários para instalar os drivers para-virtualizados convidados no Red Hat Enterprise Linux 3.
  1. Install the latest kernel version. The para-virtualized drivers require at least Red Hat Enterprise Linux 3.9 kernel version kernel-2.4.21-60.EL for all the required headers.
  2. Copie o rpm kmod-xenpv para sua arquitetura de hardware e variante de kernel para seu sistema operacional convidado.
  3. Use o utilitário rpm para instalar os parcotes de RPM. Assegure-se de que você identificou corretamente qual o pacote que você precisa para sua variante de sistema operacional convidado e arquitetura.
    [root@rhel3]# rpm -ivh kmod-xenpv*
    
  4. Use the commands below load the para-virtualized driver modules. %kvariant is the kernel variant the para-virtualized drivers have been build against and %release corresponds to the release version of the para-virtualized drivers.
    [root@rhel3]# mkdir -p /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# cp -R /lib/modules/2.4.21-52.EL[%kvariant]/extra/xenpv/%release \
    /lib/modules/'uname -r'/extra/xenpv
    [root@rhel3]# depmod -ae
    [root@rhel3]# modprobe xen-vbd
    [root@rhel3]# modprobe xen-vnif
    

    Nota

    Serão gerados avisos pelo insmod ao instalar os módulos do driver binários, porque o MODVERSIONS do Red Hat Enterprise Linux 3 está ativado. Estes avisos podem ser ignorados.
  5. Verifique o arquivo /etc/modules.conf e tenha a certeza de que você possui um alias para eth0 como este abaixo. Se você deseja configurar interfaces múltiplas, adicione uma linha para cada interface.
    alias eth0 xen-vnif
    
    Edite /etc/rc.local e adicione a linha:
    insmod /lib/modules/'uname -r'/extra/xenpv/%release/xen-vbd.o
    

    Nota

    Substitua o “%release” pela versão de lançamento atual (por exemplo 0.1-5.el) para os drivers para-virtualizados. Se você atualizar o pacote de RPM do driver para-virtualizado, lembre-se de atualizar a versão de lançamento para a versão adequada.
  6. Feche a máquina virtual (use “#shutdown -h now” dentro do convidado).
  7. Edit the guest configuration file in /etc/xen/YourGuestName with a text editor, performing the following changes:
    • Remova a entrada “type=ioemu” da entrada “vif=”.
    • Adicione qualquer partição de disco, volumes ou LUNs no convidado para que ele possa ser acessado via driver de disco (xen-vbd) para-virtualizado.
    • For each physical device, LUN, partition or volume you want to use the para-virtualized drivers you must edit the disk entry for that device in the libvirt configuration file.
    • A typical disk entry resembles the following:
      <disk type='file' device='disk'>
        <driver name='file'/>
        <source file='/dev/hda6'/>
        <target dev='hda'/>
      </disk>
      
      Modify each disk entry, as desired, to use the para-virtualized by changing the driver elements as shown below.
      <disk type='file' device='disk'>
        <driver name='tap' type='aio'/>
        <source file='/dev/hda6'/>
        <target dev='xvda'/>
      </disk>
      
      
    • Once complete, save the modified configuration file and restart the guest.
  8. Boot the virtual machine:
    # xm start YourGuestName
    Where YourGuestName is the name of the configuration file or the guest operating system's name as defined in its configuration file in the name = "os_name" parameter.

Atenção

Os drivers para-virtualizados não são adicionados automaticamente e carregados no sistema porque o suporte weak-modules e modversions não é fornecido no Red Hat Enterprise LInux 3. Para inserir o módulo, execute o comando abaixo.
insmod xen_vbd.ko
O Red Hat Enterprise Linux 3 precisa da criação manual dos arquivos especiais para os dispositivos de bloco que usam xen-vbd. Os passos abaixo se referem a como criar um registro de dispositivos de bloco para-virtualizados.
Use o seguinte script para criar os arquivos especiais, depois que o driver de dispositivo de bloco para-virtualizado for carregado.
#!/bin/sh
module="xvd"
mode="664"
major=`awk "\\$2==\"$module\" {print \\$1}" /proc/devices`
# < mknod for as many or few partitions on xvd disk attached to FV guest >
# change/add xvda to xvdb, xvbd, etc. for 2nd, 3rd, etc., disk added in
# in xen config file, respectively.
mknod /dev/xvdb b $major 16
mknod /dev/xvdb1 b $major 17
mknod /dev/xvdb2 b $major 18
chgrp disk /dev/xvd*
chmod 0660 /dev/xvd*
Para cada disco virtual adicional, incremente um número mínimo por 16. No exemplo abaixo foi criado um dispositivo adicional, número mínimo 16.
# mknod /dev/xvdc b $major 16
# mknod /dev/xvdc1 b $major 17
Isto torna o próximo dispositivo 32, o qual pode ser criado por:
# mknod /dev/xvdd b $major 32
# mknod /dev/xvdd1 b $major 33
Agora você deve verificar se as partições que você criou estão disponíveis.
[root@rhel3]# cat /proc/partitions
major   minor     #blocks   name

  3        0      10485760  hda
  3        1        104391  hda1
  3        2      10377990  hda2
202        16         64000  xvdb
202        17         32000  xvdb1
202        18        32000  xvdb2
253        0       8257536  dm-0
253        1       2031616  dm-1
No resultado acima, você pode observar que o dispositivo particionado “xvdb” está disponível para o sistema.
O procedimento abaixo adiciona um novo dispositivo ao convidado e o torna persistente após a reinicialização. Todos estes comandos são executados no convidado.
  1. Crie diretórios onde deseja montar a imagem do dispositivo de bloco:
    [root@rhel3]# mkdir /mnt/pvdisk_p1
    [root@rhel3]# mkdir /mnt/pvdisk_p2
    
  2. Monte os dispositivos nas novas pastas.
    [root@rhel3]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel3]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Verifique se os dispositivos são montados corretamente.
    [root@rhel3]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Atualize o arquivo /etc/fstab dentro do convidado para montar os dispositivos durante a sequência de inicialização. Adicione as seguintes linhas:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Dica de Desempenho

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Um dom0 do Red Hat Enterprise Linux 5.2 não irá precisar deste parâmetro de kernel para o convidado.

Importante

Os pacotes de RPM de binários (ia64) Itanium e construções, não estão disponíveis no momento.

12.3.3. Instalação e Configuração dos Drivers Para-virtualizados no Red Hat Enterprise Linux 4

Esta seção contém instruções detalhadas para os drivers para-virtualizados no sistema operacional convidado do Red Hat Enterprise 4.

Nota

Estes pacotes não suportam a inicialização de um disco para-virtualizado. Para inicializar o kernel do sistema operacional convidado, você precisa usar o driver emulado IDE, enquanto qualquer outro (não sistema) aplicativo de espaço de usuário e dados pode usar os drivers de dispositivo de bloco para-virtualizado.
Instalação do Driver
A lista abaixo refere-se aos passos para instalar o convidado Red Hat Enterprise Linux 4 com drivers para-virtualizados.
  1. Copie os RPMs kmod-xenpv, modules-init-tools e modversions para sua arquitetura de hardware e variante de kernel para seu sistema operacional convidado.
  2. Use o utilitário rpm para instalar os pacotes de RPM. Lembre-se de identificar corretamente qual pacote você precisa para a variante do seu sistema operacional convidado e arquitetura. É necessário possuir as ferramentas module-init atualizadas para este pacote e está disponível com o Red Hat Enterprise Linux 4-6-z kernel ou mais recentes.
    [root@rhel4]# rpm -ivh modversions
    [root@rhel4]# rpm -Uvh module-init-tools
    [root@rhel4]# rpm -ivh kmod-xenpv*
    

    Nota

    Existem pacotes diferentes para UP, SMP, Hugemen e arquiteturas, portanto assegure-se de que você possui os RPMs corretos para seu kernel.
  3. Execute cat /etc/modprobe.conf to verify you have an alias for eth0 like the one below. If you are planning to configure multiple interfaces add an additional line for each interface. If it does not look like the entry below change it.
    alias eth0 xen-vnif
    
  4. Feche a máquina virtual (use “#shutdown -h now” dentro do convidado).
  5. Edite o arquivo de configuração convidado em /etc/xen/YourGuestsName nas seguintes formas:
    • Remova a entrada “type=ioemu” da entrada “vif=”.
    • Adicione qualquer partição de disco, volumes ou LUNs no convidado para que ele possa ser acessado via driver de disco (xen-vbd) para-virtualizado.
    • Para cada dispositivo físico adicional, LUN, partição ou volume, adicione uma entrada semelhante à esta embaixo da seção “disk=” no arquivo de configuração convidado. A entrada “disk=” original, deve se parecer com esta abaixo.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    • Depois de adicionar os dispositivos físicos extras, LUNs, partições ou volumes, a entrada de driver para-virtualizada em seu arquivo de configuração XML, deve se parecer com a entrada exibida abaixo.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Nota

      Use “tap:aio” para o dispositivo para-virtualizado quando usar uma imagem com base em arquivo.
  6. Inicialize a máquina virtual usando o comando virsh:
    # virsh start YourGuestName
Na primeira reinicialização do convidado virtual, kudzu irá lhe perguntar se você deseja "Manter ou Remover o dispositivo Realtek Network" e "Configurar o dispositivo xen-bridge". Você deve configurar o xen-bridge e remover o dispositivo Realtek network.

Dica de Desempenho

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Um dom0 do Red Hat Enterprise Linux 5.2 não irá precisar deste parâmetro de kernel para o convidado.
Agora, verifique se as partições que você criou estão disponíveis.
[root@rhel4]# cat /proc/partitions
major    minor   #blocks   name

   3        0    10485760  hda
   3        1      104391  hda1
   3        2    10377990  hda2
 202        0       64000  xvdb
 202        1       32000  xvdb1
 202        2       32000  xvdb2
 253        0     8257536  dm-0
 253        1     2031616  dm-1
No resultado acima, você pode ver se o dispositivo particionado “xvdb” está disponível para o sistema.
O procedimento abaixo adiciona um novo dispositivo à um convidado e o torna persistente após reinicializar. Todos estes comandos são executados em um convidado.
  1. Crie diretórios onde deseja montar imagem de dispositivo de bloco.
    [root@rhel4]# mkdir /mnt/pvdisk_p1
    [root@rhel4]# mkdir /mnt/pvdisk_p2
    
  2. Monte os dispositivos em novas pastas.
    [root@rhel4]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel4]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Verifique se os dispositivos estão montados corretamente.
    [root@rhel4]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Atualize o arquivo /etc/fstab dentro do convidado para montar dispositivos durante a sequência de inicialização. Adicione as seguintes linhas:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Nota

Este pacote não é suportado no Red Hat Enterprise Linux 4-GA nos sistemas e kernels Red Hat Enterprise Linux 4 atualização 2.

Nota Importante

Os pacotes de RPM binários IA64 e construções não estão disponíveis no momento.

Carregamento automático do módulo

O driver xen-vbd pode não carregar automaticamente. Execute o seguinte comando no convidado, substituindo %release pela versão de lançamento correta para os drivers para-virtualizados.
# insmod /lib/modules/'uname -r'/weak-updates/xenpv/%release/xen_vbd.ko

12.3.4. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 5

This section contains detailed instructions for the para-virtualized drivers in a Red Hat Enterprise Linux 5 guest operating system.

Nota

Estes pacotes não suportam a inicialização de um disco para-virtualizado. Para inicializar o kernel do sistema operacional convidado, você precisa usar o driver emulado IDE, enquanto qualquer outro (não sistema) aplicativo de espaço de usuário e dados pode usar os drivers de dispositivo de bloco para-virtualizado.
The procedure below covers the steps to enable the para-virtualized drivers for a Red Hat Enterprise Linux 5 guest.
Procedimento 12.1. Enable para-virtualized drivers for a Red Hat Enterprise Linux Guest
  1. Feche a máquina virtual (use “#shutdown -h now” dentro do convidado).
  2. Edite o arquivo de configuração convidado em /etc/xen/<Your GuestsName> das seguintes formas:
    1. Remova a entrada “type=ioemu” da entrada “vif=”.
    2. Adicione qualquer partição de disco, volumes ou LUNs no convidado para que ele possa ser acessado via driver de disco (xen-vbd) para-virtualizado.
    3. Para cada dispositivo físico adicional, LUN, partição ou volume, adicione uma entrada semelhante à esta embaixo da seção “disk=” no arquivo de configuração convidado. A entrada “disk=” original, deve se parecer com esta abaixo.
      disk = [ "file:/var/lib/libvirt/images/rhel4_64_fv.dsk,hda,w"]
      
    4. Depois de adicionar os dispositivos físicos extras, LUNs, partições ou volumes, a entrada de driver para-virtualizada em seu arquivo de configuração XML, deve se parecer com a entrada exibida abaixo.
      disk = [ "file:/var/lib/libvirt/images/rhel3_64_fv.dsk,hda,w",
      "tap:aio:/var/lib/libvirt/images/UserStorage.dsk,xvda,w" ]
      

      Nota

      Use “tap:aio” para o dispositivo para-virtualizado quando usar uma imagem com base em arquivo.
  3. Inicialize a máquina virtual usando o comando virsh:
    # virsh start YourGuestName
    
Para verificar se a interface de rede surgiu após instalar os drivers para-virtualizados, emita o seguinte comando no convidado. Ele deve exibir as informações de interface incluindo um endereço IP atribuído.
[root@rhel5]# ifconfig eth0
Agora, verifique se as partições que você criou estão disponíveis.
[root@rhel5]# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvdb
 202     1      32000   xvdb1
 202     2      32000   xvdb2
 253     0    8257536   dm-0
 253     1    2031616   dm-1
No resultado acima, você pode ver se o dispositivo particionado “xvdb” está disponível para o sistema.
O procedimento abaixo adiciona um novo dispositivo ao convidado e o torna persistente após reinicializar. Todos estes comandos são executados no convidado.
  1. Crie diretórios onde deseja montar imagens de dispositivos de bloco.
    [root@rhel5]# mkdir /mnt/pvdisk_p1
    [root@rhel5]# mkdir /mnt/pvdisk_p2
    
  2. Monte os dispositivos nas novas pastas.
    [root@rhel5]# mount /dev/xvdb1 /mnt/pvdisk_p1
    [root@rhel5]# mount /dev/xvdb2 /mnt/pvdisk_p2
    
  3. Verifique se os dispositivos foram montados corretamente.
    [root@rhel5]# df /mnt/pvdisk_p1
    Filesystem           1K-blocks      Used   Available Use%  Mounted on
    /dev/xvdb1               32000        15       31985   1%  /mnt/pvdisk_p1
    
  4. Atualize o arquivo /etc/fstab dentro do convidado para montar os dispositivos durante a sequência de inicialização. Adicione as seguintes linhas:
    /dev/xvdb1   /mnt/pvdisk_p1   ext3    defaults        1 2
    /dev/xvdb2   /mnt/pvdisk_p2   ext3    defaults        1 2
    

Dica de Desempenho

Using a Red Hat Enterprise Linux 5.1 host (dom0), the "noapic" parameter should be added to the kernel boot line in your virtual guest's /boot/grub/grub.conf entry as seen below. Keep in mind your architecture and kernel version may be different.
kernel /vmlinuz-2.6.9-67.EL ro root=/dev/VolGroup00/rhel4_x86_64 rhgb noapic
Um dom0 do Red Hat Enterprise Linux 5.2 não irá precisar deste parâmetro de kernel para o convidado.
Hiding fake interfaces
Sometimes, activating the para-virtualized drivers does not delete the old virtualized network interfaces. To remove these interfaces from guests use the following procedure.
  1. Add the following lines to the /etc/modprobe.d/blacklist file. Blacklist 8139cp and 8139too for the RealTek 8139 and e1000 for the virtualized Intel e1000 NIC.
    8139cp
    8139too
    e1000
    
  2. Remove the old network scripts from the /etc/sysconfig/network-scripts directory.
  3. Reboot the guest. The default network interface should now use the para-virtualized drivers.

12.3.5. Xen Para-virtualized Drivers on Red Hat Enterprise Linux 6

This section describes the use of para-virtualized drivers in a Red Hat Enterprise Linux 6 guest.
The para-virtualized drivers are enabled by default for a Red Hat Enterprise Linux 6 guest. The guest will automatically unplug any emulated devices that are presented to it, and will use the para-virtualized drivers instead.
Although the para-virtualized drivers are enabled by default, they can be disabled. Add the following to the guest kernel command line upon boot to disable the para-virtualized drivers:
xen_emul_unplug=never

12.4. Configuração do Driver de Rede Para-virtualizado

Once the para-virtualized network driver is loaded you may need to reconfigure the guest's network interface to reflect the driver and virtual Ethernet card change.
Realize os seguintes passos para reconfigurar a interface de rede dentro do convidado.
  1. Em virt-manager abra a janela do console para o convidado e faça o loggin como usuário root.
  2. No Red Hat Enterprise Linux 4 verifique se o arquivo /etc/modprobe.conf contém a linha “alias eth0 xen-vnif”.
    # cat /etc/modprobe.conf
    alias eth0 xen-vnif
    
  3. To display the present settings for eth0 execute “# ifconfig eth0”. If you receive an error about the device not existing you should load the modules manually as outlined in Seção 36.4, “Carregando manualmente os drivers para-virtualizados.”.
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:00:00:6A:27:3A  
              BROADCAST MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:846 (846.0 b)
    
  4. Start the network configuration utility(NetworkManager) with the command “# system-config-network”. Click on the “Forward” button to start the network card configuration.
  5. Select the 'Xen Virtual Ethernet Card (eth0)' entry and click 'Forward'.
    Configure the network settings as required.
  6. Complete the configuration by pressing the 'Apply' button.
  7. Press the 'Activate' button to apply the new settings and restart the network.
  8. Agora você precisa ver a nova interface de rede com um endereço de IP atribuído.
    ifconfig eth0
    eth0      Link encap:Ethernet  HWaddr 00:16:3E:49:E4:E0
              inet addr:192.168.78.180  Bcast:192.168.79.255  Mask:255.255.252.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:630150 errors:0 dropped:0 overruns:0 frame:0
              TX packets:501209 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000 
              RX bytes:109336431 (104.2 MiB)  TX bytes:46265452 (44.1 MiB)
    

12.5. Configuração de Hardware adicional Para-virtualizado.

Esta seção explicará como adicionar rede virtual ou armazenamento para um sistema operacional convidado. Para mais detalhes sobre configuração de rede e recursos de armazenamento na tecnologia de Virtualização do Red Hat Enterprise Linux 5, leia o documento disponível em Tecnologias Emergentes, Red Hat.com

12.5.1. Interfaces de Rede Virtual

Realize os seguintes passos para configurar dispositivos de rede adicionais para seu convidado.
Edite seu arquivo de configuração em /etc/xen/YourGuestName replacing YourGuestName com o nome do seu convidado.
A entrada original deve se parecer com esta abaixo.
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0" ]
Adicione uma entrada na seção “vif=” do arquivo de configuração semelhante a este abaixo.
vif = [ "mac=00:16:3e:2e:c5:a9,bridge=xenbr0",
    "mac=00:16:3e:2f:d5:a9,bridge=xenbr0" ]
Tenha a certeza de gerar um endereço MAC único para a nova interface. Você pode usar o comando abaixo.
# echo 'import virtinst.util ; print virtinst.util.randomMAC()' | python
Depois que o convidado foi reinicializado, realize os seguintes passos no sistema operacional convidado. Verifique se a atualização foi adicionada em seu /etc/modules.conf no Red Hat Enterprise Linux 3 ou /etc/modprobe.conf no Red Hat Enterprise Linux 4 e Red Hat Enterprise Linux 5. Adicione um novo alias para cada interface nova que você adicionar.
alias eth1 xen-vnif
Agora teste para verificar se cada interface nova que você adicionou está disponível dentro do convidado.
# ifconfig eth1
O comando acima deve exibir as propriedades de eth1, repita o comando para eth2 se você adicionou uma terceira interface e assim por diante.
Agora você pode configurar as novas interfaces de rede usando redhat-config-network ou Red Hat Enterprise Linux3 ou system-config-network no Red Hat Enterprise Linux 4 e Red Hat Enterprise Linux 5.

12.5.2. Dispositivos de Armazenamento Virtual

Realize os seguintes passos para configurar dispositivos de armazenamento virtual adicionais para seu convidado.
Edite seu arquivo de configuração convidado em /etc/xen/YourGuestName replacing YourGuestName com o nome de seu convidado. A entrada original deve se parecer com esta abaixo.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w"]
Agora adicione uma entrada para seu dispositivo físico novo, LUN, partição ou volume para o parâmetro de “disk=” no arquivo de configuração. As entidades de armazenamento que usam o driver para-virtualizado, se parecem com a entrada abaixo. O parâmetro “tap:aio” instrui o hipervisor a usar o driver para-virtualizado.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w" ]
Se você deseja adicionar entradas, faça isto na seção “disk=” como uma lista separada por vírgulas.

Nota

You need to increment the letter for the 'xvd' device, that is for your second storage entity it would be 'xvdb' instead of 'xvda'.
disk = [ "file:/var/lib/libvirt/images/rhel5_64_fv.dsk,hda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage1.dsk,xvda,w",
    "tap:aio:/var/lib/libvirt/images/UserStorage2.dsk,xvdb,w" ]
Verifique as partições que foram criadas e estão disponíveis.
# cat /proc/partitions
major minor  #blocks    name
   3     0   10485760   hda
   3     1     104391   hda1
   3     2   10377990   hda2
 202     0      64000   xvda
 202     1      64000   xvdb
 253     0    8257536   dm-0
 253     1    2031616   dm-1
No resultado acima, você pode ver a partição ou dispositivo “xvdb” disponível ao sistema.
MOnte os dispositivos novos e discos nos pontos de montagens locais e atualize o /etc/fstab dentro do convidado para montar os dispositivos e partições durante a inicialização.
# mkdir /mnt/pvdisk_xvda
# mkdir /mnt/pvdisk_xvdb
# mount /dev/xvda /mnt/pvdisk_xvda
# mount /dev/xvdb /mnt/pvdisk_xvdb
# df /mnt
Filesystem           1K-blocks      Used   Available Use%  Mounted on
/dev/xvda                64000        15       63985   1%  /mnt/pvdisk_xvda
/dev/xvdb                64000        15       63985   1%  /mnt/pvdisk_xvdb

Capítulo 13. Drivers para-virtualizados KVM

Para-virtualized drivers are available for virtualized Windows guests running on KVM hosts. These para-virtualized drivers are included in the virtio-win package. The virtio-win package supports block (storage) devices and network interface controllers.
As with the KVM module, the virtio-win drivers package is only available on hosts running Red Hat Enterprise Linux 5.4 and newer.
Os drivers para-virtualizados aprimoram o desempenho dos convidados de virtualização completa. Com os drivers para-virtualizados a latência I/O convidada abaixa e o rendimento aumenta próximo aos níveis de bare-metal. Recomenda-se usar os drivers para-virtualizados para os convidados de virtualização completa rodando as tarefas e aplicativos pesados do I/O.
The KVM para-virtualized drivers are automatically loaded and installed on the following versions of Red Hat Enterprise Linux:
  • Red Hat Enterprise Linux 4.8 and newer
  • Red Hat Enterprise Linux 5.3 and newer
  • Red Hat Enterprise Linux 6.
Those Red Hat Enterprise Linux versions detect and install the drivers so additional installation steps are not required.

Nota

PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
As seguintes versões do Microsoft Windows suportam os drivers para-virtualizados KVM.
  • Windows XP (32-bit only)
  • Windows Server 2003 (32-bit and 64-bit versions)
  • Windows Server 2008 (32-bit and 64-bit versions)
  • Windows 7 (32-bit and 64-bit versions)

13.1. Instalando os drivers para-virtualizados do KVM Windows

Esta seção cobre o processo de instalação para os drivers para-virtualizados do KVM Windows. Os drivers para-virtualizados KVM podem ser carregados durante a instalação do Windows ou instalado após o convidado for instalado.
You can install the para-virtualized drivers on your guest by one of the following methods:
  • hosting the installation files on a network accessible to the guest,
  • using a virtualized CD-ROM device of the driver installation disk .iso file, or
  • using a virtualized floppy device to install the drivers during boot time (for Windows guests).
This guide describes installation from the para-virtualized installer disk as a virtualized CD-ROM device.
  1. Baixe os drivers

    The virtio-win package contains the para-virtualized block and network drivers for all supported Windows guests.
    If the Red Hat Enterprise Linux Supplementary channel entitlements are not enabled for the system, the download will not be available. Enable the Red Hat Enterprise Linux Supplementary channel to access the virtio-win package.
    Download the virtio-win package with the yum command.
    # yum install virtio-win
    
    The drivers are also available on the Red Hat Enterprise Linux Supplementary disc or from Microsoft (windowsservercatalog.com). Note that the Red Hat Enterprise Virtualization Hypervisor and Red Hat Enterprise Linux are created on the same code base so the drivers for the same version (for example, 5.5) are supported for both environments.
    O pacote virtio-win instala uma imagem de CD-ROM, virtio-win.iso, no diretório /usr/share/virtio-win/.
  2. Instala os drivers para-virtualizados

    É recomendável instalar os drivers no convidado antes de anexar ou modificar um dispositivo para uso dos drivers para-virtualizados.
    Para dispositivos de blocos armazenarem os sistemas de arquivo raiz ou outros dispositivos de bloco solicitados para inicialização do convidado, os drivers deverão ser instalados antes do dispositivo ser modificado. Caso os drivers não estiverem instalados no convidado e o driver for ajustado para o driver virtio, o convidado não inicializará.
Installing drivers with a virtualized CD-ROM
This procedure covers installing the para-virtualized drivers with a virtualized CD-ROM after Windows is installed.
Follow Procedimento 13.1, “Usando o virt-manager para montar uma imagem CD-ROM para o convidado do Windows.” to add a CD-ROM image with virt-manager and then install the drivers.
Procedimento 13.1. Usando o virt-manager para montar uma imagem CD-ROM para o convidado do Windows.
  1. Open virt-manager and the virtualized guest

    Open virt-manager, select your virtualized guest from the list by double clicking the guest name.
  2. Open the hardware tab

    Click the Add Hardware button in the Hardware tab.
  3. Select the device type

    This opens a wizard for adding the new device. Select Storage from the dropdown menu.
    Click the Forward button to proceed.
  4. Select the ISO file

    Choose the File (disk image) option and set the file location of the para-virtualized drivers .iso image file. The location file is named /usr/share/virtio-win/virtio-win.iso.
    Caso os drivers sejam armazenados em um CD-ROM físico, use a opção Partição de Disco Normal.
    Set the Device type to IDE cdrom and click Forward to proceed.
  5. Disc assigned

    The disk has been assigned and is available for the guest once the guest is started. Click Finish to close the wizard or back if you made a mistake.
  6. Reboot

    Reboot or start the guest to add the new device. Virtualized IDE devices require a restart before they can be recognized by guests.
Once the CD-ROM with the drivers is attached and the guest has started, proceed with Procedimento 13.2, “Windows installation”.
Procedimento 13.2. Windows installation
  1. Open My Computer

    On the Windows guest, open My Computer and select the CD-ROM drive.
  2. Select the correct installation files

    There are four files available on the disc. Select the drivers you require for your guest's architecture:
    • the para-virtualized block device driver (RHEV-Block.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • the para-virtualized network device driver (RHEV-Network.msi for 32-bit guests or RHEV-Block64.msi for 64-bit guests),
    • or both the block and network device drivers.
    Double click the installation files to install the drivers.
  3. Install the block device driver

    1. Start the block device driver installation

      Double click RHEV-Block.msi or RHEV-Block64.msi.
      Press Next to continue.
    2. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    3. Finish

      Press Finish to complete the installation.
  4. Install the network device driver

    1. Start the network device driver installation

      Double click RHEV-Network.msi or RHEV-Network64.msi.
      Press Next to continue.
    2. Performance setting

      This screen configures advanced TCP settings for the network driver. TCP timestamps and TCP window scaling can be enabled or disabled. The default is, 1, for window scaling to be enabled.
      TCP window scaling is covered by IETF RFC 1323. The RFC defines a method of increasing the receive window size to a size greater than the default maximum of 65,535 bytes up to a new maximum of 1 gigabyte (1,073,741,824 bytes). TCP window scaling allows networks to transfer at closer to theoretical network bandwidth limits. Larger receive windows may not be supported by some networking hardware or operating systems.
      TCP timestamps are also defined by IETF RFC 1323. TCP timestamps are used to better calculate Return Travel Time estimates by embedding timing information is embedded in packets. TCP timestamps help the system to adapt to changing traffic levels and avoid congestion issues on busy networks.
      ValueAction
      0Disable TCP timestamps and window scaling.
      1Enable TCP window scaling.
      2Enable TCP timestamps.
      3Enable TCP timestamps and window scaling.
      Press Next to continue.
    3. Confirm the exception

      Windows may prompt for a security exception.
      Press Yes if it is correct.
    4. Finish

      Press Finish to complete the installation.
  5. Reboot

    Reboot the guest to complete the driver installation.
Change the device configuration to use the para-virtualized drivers (Seção 13.3, “Usando os drivers para-virtualizados para dispositivos existentes”) or install a new device which uses the para-virtualized drivers (Seção 13.4, “Usando os drivers para-virtualizados KVM para novos dispositivos”).

13.2. Installing drivers with a virtualized floppy disk

Este procedimento cobre a instalação dos driver para-virtualizados durante a instalação do Windows.
  • Na instalação do Windows VM, anexe o viostor.vfd como disco na primeira vez que usando o menu executar-uma vez.
    1. Servidor do Windows 2003

      Quando a janela aparecer para pressionar o F6 para drivers terceirizados, pressione isto e siga as instruções.
    2. Servidor do Windows 2008

      Quando o instalador lhe solicitar o driver, clique em Carregar o Driver, aponte o instalador ao drive A: e escolha o drive que se adequa melhor ao seu SO e arquitetura.

13.3. Usando os drivers para-virtualizados para dispositivos existentes

Modify an existing hard disk device attached to the guest to use the virtio driver instead of virtualized IDE driver. This example edits libvirt configuration files. Alternatively, virt-manager, virsh attach-disk or virsh attach-interface can add a new device using the para-virtualized drivers Seção 13.4, “Usando os drivers para-virtualizados KVM para novos dispositivos”.
  1. Abaixo é um dispositivo de bloco de arquivo baseado usando o driver IDE virtualizado. Esta é uma entrada típica para o convidado virtualizado que não está usando os drivers para-virtualizados.
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='ide'/>
    </disk>
    
  2. Altere a entrada de uso para o dispositivo pela modificação da entrada bus= para o virtio.
    <disk type='file' device='disk'>
       <source file='/var/lib/libvirt/images/disk1.img'/>
       <target dev='vda' bus='virtio'/>
    </disk>
    

13.4. Usando os drivers para-virtualizados KVM para novos dispositivos

Este procedimento cobre a criação de novos dispositivos usando os drivers para-virtualizados KVM com o virt-manager.
Alternativamente, os comandos virsh attach-disk ou virsh attach-interface podem ser usados usando os drivers para-virtualizados.

Instale primeiro os drivers

Garanta que os drivers foram instalados no convidado do Windows antes de proceder à instalação de novos dispositivos. Caso os drivers não estiverem disponíveis, o dispositivo não será reconhecido e não funcionará.
  1. Abra o convidado virtualizado, clicando duas vezes no nome do convidado no virt-manager.
  2. Clique na aba Hardware.
  3. Pressione o botão Adicionar Hardware.
  4. Na aba Adicionar Hardware Virtual selecione o Armazenamento ou Rede para o tipo de dispositivo.
    1. New disk devices
      Selecione o dispositivo de armazenamento ou imagem com base de arquivo. Selecione o Disco Virtio como Tipo de Dispositivo e clique em Próximo.
    2. New network devices
      Selecione Rede Virtual ou Dispositivo Físico Compartilhado. Selecione virtio como o Tipo de Dispositivo e pressione Próximo.
  5. Clique em Finalizar para salvar o dispositivo.
  6. Reinicie o convidado. O dispositivo pode não ser reconhecido até que o convidado Windows reinicie.

Capítulo 14. PCI passthrough

Este capítulo explica sobre o uso de PCI passthrough com os hypervisors Xen e KVM.
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
PCI devices are limited by the virtualized system architecture. Out of the 32 available PCI devices for a guest 4 are not removable. This means there are up to 28 PCI slots available for additional devices per guest. Each PCI device can have up to 8 functions; some PCI devices have multiple functions and only use one slot. Para-virtualized network, para-virtualized disk devices, or other PCI devices using VT-d all use slots or functions. The exact number of devices available is difficult to calculate due to the number of available devices. Each guest can use up to 32 PCI devices with each device having up to 8 functions.
The VT-d or AMD IOMMU extensions must be enabled in BIOS.
Procedimento 14.1. Preparing an Intel system for PCI passthrough
  1. Enable the Intel VT-d extensions

    The Intel VT-d extensions provides hardware support for directly assigning a physical devices to guest. The main benefit of the feature is to improve the performance as native for device access.
    The VT-d extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
    These extensions are often called various terms in BIOS which differ from manufacturer to manufacturer. Consult your system manufacturer's documentation.
  2. Activate Intel VT-d in the kernel

    Activate Intel VT-d in the kernel by appending the intel_iommu=on parameter to the kernel line of the kernel line in the /boot/grub/grub.conf file.
    The example below is a modified grub.conf file with Intel VT-d activated.
    default=0
    timeout=5
    splashimage=(hd0,0)/grub/splash.xpm.gz
    hiddenmenu
    title Red Hat Enterprise Linux Server (2.6.18-190.el5)
       root (hd0,0)
       kernel /vmlinuz-2.6.18-190.el5 ro root=/dev/VolGroup00/LogVol00 intel_iommu=on
       initrd /initrd-2.6.18-190.el5.img
  3. Ready to use

    Reboot the system to enable the changes. Your system is now PCI passthrough capable.
Procedimento 14.2. Preparing an AMD system for PCI passthrough
  • Enable AMD IOMMU extensions

    The AMD IOMMU extensions are required for PCI passthrough with Red Hat Enterprise Linux. The extensions must be enabled in the BIOS. Some system manufacturers disable these extensions by default.
AMD systems only require that the IOMMU is enabled in the BIOS. The system is ready for PCI passthrough once the IOMMU is enabled.

PCI passthrough with Xen

Xen and KVM require different kernel arguments to enable PCI passthrough. The previous instructions are for KVM. For both AMD and Intel systems, PCI passthrough on Xen requires the iommu=on parameter to the hypervisor command line. Modify the /boot/grub/grub.conf file as follows to enable PCI passthrough:
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=on
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 
   module /initrd-2.6.18-190.el5xen.img

14.1. Adding a PCI device with virsh

These steps cover adding a PCI device to a fully virtualized guest under the Xen or KVM hypervisors using hardware-assisted PCI passthrough. Refer to Seção 14.4, “PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux” for details on adding a PCI device to a para-virtualized Xen guest.

Importante

The VT-d or AMD IOMMU extensions must be enabled in BIOS.
This example uses a USB controller device with the PCI identifier code, pci_8086_3a6c, and a fully virtualized guest named win2k3.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Information on the domain, bus and function are available from output of the virsh nodedev-dumpxml command:
    # virsh nodedev-dumpxml pci_8086_3a6c
    <device>
      <name>pci_8086_3a6c</name>
      <parent>computer</parent>
      <capability type='pci'>
        <domain>0</domain>
        <bus>0</bus>
        <slot>26</slot>
        <function>7</function>
        <id='0x3a6c'>82801JD/DO (ICH10 Family) USB2 EHCI Controller #2</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
  3. Detach the device from the system. Attached devices cannot be used and may cause various errors if connected to a guest without detaching first.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  4. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
    For example, if bus = 0, slot = 26 and function = 7 run the following:
    $ printf %x 0
    0
    $ printf %x 26
    1a
    $ printf %x 7
    7
    The values to use:
    bus='0x00'
    slot='0x1a'
    function='0x7'
  5. Run virsh edit (or virsh attach device) and add a device entry in the <devices> section to attach the PCI device to the guest. Only run this command on offline guests. Red Hat Enterprise Linux does not support hotplugging PCI devices at this time.
    # virsh edit win2k3
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
          <address domain='0x0000' bus='0x00' slot='0x1a' function='0x7'/>
      </source>
    </hostdev>
  6. Once the guest system is configured to use the PCI address, we need to tell the host system to stop using it. The ehci driver is loaded by default for the USB PCI controller.
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/ehci_hcd
  7. Detach the device:
    $ virsh nodedev-dettach pci_8086_3a6c
  8. Verify it is now under the control of pci_stub:
    $ readlink /sys/bus/pci/devices/0000\:00\:1d.7/driver
    ../../../bus/pci/drivers/pci-stub
  9. Set a sebool to allow the management of the PCI device from the guest:
    # setsebool -P virt_use_sysfs 1
  10. Start the guest system :
    # virsh start win2k3
    
The PCI device should now be successfully attached to the guest and accessible to the guest operating system.

14.2. Adding a PCI device with virt-manager

PCI devices can be added to guests using the graphical virt-manager tool. The following procedure adds a 2 port USB controller to a virtualized guest.
  1. Identify the device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
    Record the PCI device number; the number is needed in other steps.
  2. Detach the PCI device

    Detach the device from the system.
    # virsh nodedev-dettach pci_8086_3a6c 
    Device pci_8086_3a6c dettached
  3. Power off the guest

    Power off the guest. Hotplugging PCI devices into guests is presently unsupported and may fail or crash.
  4. Open the hardware settings

    Open the virtual machine and select the Hardware tab. Click the Add Hardware button to add a new device to the guest.
  5. Add the new device

    Select Physical Host Device from the Hardware type list. The Physical Host Device represents PCI devices. Click Forward to continue.
  6. Select a PCI device

    Select an unused PCI device. Note that selecting PCI devices presently in use on the host causes errors. In this example a PCI to USB interface device is used.
  7. Confirm the new device

    Click the Finish button to confirm the device setup and add the device to the guest.
The setup is complete and the guest can now use the PCI device.

14.3. PCI passthrough with virt-install

To use PCI passthrough with the virt-install parameter, use the additional --host-device parameter.
  1. Identify the PCI device

    Identify the PCI device designated for passthrough to the guest. The virsh nodedev-list command lists all devices attached to the system. The --tree option is useful for identifying devices attached to the PCI device (for example, disk controllers and USB controllers).
    # virsh nodedev-list --tree
    For a list of only PCI devices, run the following command:
    # virsh nodedev-list | grep pci
    Each PCI device is identified by a string in the following format (Where **** is a four digit hexadecimal code):
    pci_8086_****
    

    Tip: determining the PCI device

    Comparing lspci output to lspci -n (which turns off name resolution) output can assist in deriving which device has which device identifier code.
  2. Add the device

    Use the PCI identifier output from the virsh nodedev command as the value for the --host-device parameter.
    # virt-install \
     -n hostdev-test -r 1024 --vcpus 2 \
     --os-variant fedora11 -v --accelerate \
     -l http://download.fedoraproject.org/pub/fedora/linux/development/x86_64/os \
     -x 'console=ttyS0 vnc' --nonetworks --nographics  \
     --disk pool=default,size=8 \
     --debug --host-device=pci_8086_10bd 
    
  3. Complete the installation

    Complete the guest installation. The PCI device should be attached to the guest.

14.4. PCI passthrough for para-virtualized Xen guests on Red Hat Enterprise Linux

PCI passthrough is used to allow a Xen guest exclusive access to a PCI device, rather than sharing with other guests or with dom0. PCI passthrough for para-virtualized Xen guests is supported on all Red Hat Enterprise Linux 5 systems, however PCI passthrough with fully virtualized guests is only supported on Red Hat Enterprise Linux 5.4 and newer.

Atenção

PCI passthrough to para-virtualized guests is considered insecure and is not supported for Red Hat Enterprise Linux 6 guests.
Limitations of Xen PCI passthrough:
Any guest using PCI passthrough will no longer be available for save, restore, or migration capabilities, as it will be tied to a particular non-virtualized hardware configuration.
A guest which has access to a non-virtualized PCI device via PCI passthrough also has the potential to access the DMA address space of dom0, which is a potential security concern.
To link a PCI device to a guest the device must first be hidden from the host. If the host is using the device the device cannot be assigned to the guest.
Procedimento 14.3. Example: attaching a PCI device
  1. Given a network device which uses the bnx2 driver and has a PCI id of 0000:09:00.0, the following lines added to /etc/modprobe.conf hides the device from dom0. Either the bnx2 module must be reloaded or the host must be restarted.
    install bnx2 /sbin/modprobe pciback; /sbin/modprobe --first-time --ignore-install bnx2
    options pciback hide=(0000:09:00.0)
  2. Multiple PCI identifiers can be added to /etc/modprobe.conf to hide multiple devices.
    options pciback hide=(0000:09:00.0)(0000:0a:04.1)
  3. Use one of the following methods to add the passed-through device to the guest's configuration file:

Capítulo 15. SR-IOV

15.1. Introduction

The PCI-SIG (PCI Special Interest Group) developed the Single Root I/O Virtualization (SR-IOV) specification. The PCI-SIG Single Root IOV specification is a standard for a type of PCI passthrough which natively shares a single device to multiple guests. SR-IOV does not require hypervisor involvement in data transfer and management by providing an independent memory space, interrupts, and DMA streams for virtualized guests.
SR-IOV enables a Single Root Function (for example, a single Ethernet port), to appear as multiple, separate, physical devices. A physical device with SR-IOV capabilities can be configured to appear in the PCI configuration space as multiple functions, each device has its own configuration space complete with Base Address Registers (BARs).
SR-IOV uses two new PCI functions:
  • Physical Functions (PFs) are full PCIe devices that include the SR-IOV capabilities. Physical Functions are discovered, managed, and configured as normal PCI devices. Physical Functions configure and manage the SR-IOV functionality by assigning Virtual Functions.
  • Virtual Functions (VFs) are simple PCIe functions that only process I/O. Each Virtual Function is derived from a Physical Function. The number of Virtual Functions a device may have is limited by the device hardware. A single Ethernet port, the Physical Device, may map to many Virtual Functions that can be shared to virtualized guests.
The hypervisor can map one or more Virtual Functions to a virtualized guest. The Virtual Function's configuration space is mapped, by the hypervisor, to the virtualized guest's configuration space.
Each Virtual Function can only be mapped once as Virtual Functions require real hardware. A virtualized guest can have multiple Virtual Functions. A Virtual Function appears as a network card in the same way as a normal network card would appear to an operating system.
The SR-IOV drivers are implemented in the kernel. The core implementation is contained in the PCI subsystem, but there must also be driver support for both the Physical Function (PF) and Virtual Function (VF) devices. With an SR-IOV capable device one can allocate VFs from a PF. The VFs appear as PCI devices which are backed on the physical PCI device by resources (queues, and register sets).
Advantages of SR-IOV
SR-IOV devices can share a single physical port with multiple virtualized guests.
Virtual Functions have near-native performance and provide better performance than para-virtualized drivers and emulated access. Virtual Functions provide data protection between virtualized guests on the same physical server as the data is managed and controlled by the hardware.
These features allow for increased virtualized guest density on hosts within a data center.
Disadvantages of SR-IOV
Live migration is presently unsupported. As with PCI passthrough, identical device configurations are required for live (and offline) migrations. Without identical device configurations, guest's cannot access the passed-through devices after migrating.

15.2. Using SR-IOV

This section covers attaching Virtual Function to a guest as an additional network device.
SR-IOV requires Intel VT-d support.

SR-IOV with Xen

Xen requires additional kernel arguments to use SR-IOV. Modify the /boot/grub/grub.conf file to enable SR-IOV. To enable SR-IOV with Xen for Intel systems append the pci_pt_e820_access=on parameter to the kernel.
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-192.el5xen)
   root (hd0,0)
   kernel /xen.gz-2.6.18-192.el5 iommu=1
   module /vmlinuz-2.6.18-192.el5xen ro root=/dev/VolGroup00/LogVol00 pci_pt_e820_access=on
   module /initrd-2.6.18-192.el5xen.img
Procedimento 15.1. Attach an SR-IOV network device
  1. Enable Intel VT-d in BIOS and in the kernel

    Enable Intel VT-D in BIOS. Refer to Procedimento 14.1, “Preparing an Intel system for PCI passthrough” for more information on enabling Intel VT-d in BIOS and the kernel, or refer to your system manufacturer's documentation for specific instructions.
  2. Verify support

    Verify if the PCI device with SR-IOV capabilities are detected. This example lists an Intel 82576 network interface card which supports SR-IOV. Use the lspci command to verify if the device was detected.
    # lspci
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    

    Nota

    Note that the output has been modified to remove all other devices.
  3. Start the SR-IOV kernel modules

    If the device is supported the driver kernel module should be loaded automatically by the kernel. Optional parameters can be passed to the module using the modprobe command. The Intel 82576 network interface card uses the igb driver kernel module.
    # modprobe igb [<option>=<VAL1>,<VAL2>,]
    # lsmod |grep igb
    igb    87592  0
    dca    6708    1 igb
    
  4. Activate Virtual Functions

    The max_vfs parameter of the igb module allocates the maximum number of Virtual Functions. The max_vfs parameter causes the driver to spawn, up to the value of the parameter in, Virtual Functions. For this particular card the valid range is 0 to 7.
    Remove the module to change the variable.
    # modprobe -r igb
    Restart the module with the max_vfs set to 1 or any number of Virtual Functions up to the maximum supported by your device.
    # modprobe igb max_vfs=1
    
  5. Inspect the new Virtual Functions

    Using the lspci command, list the newly added Virtual Functions attached to the Intel 82576 network device.
    # lspci | grep 82576
    03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
    03:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    03:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
    
    The identifier for the PCI device is found with the -n parameter of the lspci command.
    # lspci -n | grep 03:00.0
    03:00.0 0200: 8086:10c9 (rev 01)
    # lspci -n | grep 03:10.0
    03:10.0 0200: 8086:10ca (rev 01)
    
    The Physical Function corresponds to 8086:10c9 and the Virtual Function to 8086:10ca.
  6. Find the devices with virsh

    The libvirt service must find the device to add a device to a guest. Use the virsh nodedev-list command to list available host devices.
    # virsh nodedev-list | grep 8086
    pci_8086_10c9
    pci_8086_10c9_0
    pci_8086_10ca
    pci_8086_10ca_0
    [output truncated]
    
    The serial numbers for the Virtual Functions and Physical Functions should be in the list.
  7. Get advanced details

    The pci_8086_10c9 is one of the Physical Functions and pci_8086_10ca_0 is the first corresponding Virtual Function for that Physical Function. Use the virsh nodedev-dumpxml command to get advanced output for both devices.
    # virsh nodedev-dumpxml pci_8086_10ca
    # virsh nodedev-dumpxml pci_8086_10ca_0
    <device>
      <name>pci_8086_10ca_0</name>
      <parent>pci_8086_3408</parent>
      <driver>
        <name>igbvf</name>
      </driver>
      <capability type='pci'>
        <domain>0</domain>
        <bus>3</bus>
        <slot>16</slot>
        <function>1</function>
        <product id='0x10ca'>82576 Virtual Function</product>
        <vendor id='0x8086'>Intel Corporation</vendor>
      </capability>
    </device>
    
    This example adds the Virtual Function pci_8086_10ca_0 to the guest in Passo 8. Note the bus, slot and function parameters of the Virtual Function, these are required for adding the device.
  8. Add the Virtual Function to the guest

    1. Shut down the guest.
    2. Use the output from the virsh nodedev-dumpxml pci_8086_10ca_0 command to calculate the values for the configuration file. Convert slot and function values to hexadecimal values (from decimal) to get the PCI bus addresses. Append "0x" to the beginning of the output to tell the computer that the value is a hexadecimal number.
      The example device has the following values: bus = 3, slot = 16 and function = 1. Use the printf utility to convert decimal values to hexadecimal values.
      $ printf %x 3
      3
      $ printf %x 16
      10
      $ printf %x 1
      1
      This example would use the following values in the configuration file:
      bus='0x03'
      slot='0x10'
      function='0x01'
    3. Open the XML configuration file with the virsh edit command. This example edits a guest named MyGuest.
      # virsh edit MyGuest
      
    4. The default text editor will open the libvirt configuration file for the guest. Add the new device to the devices section of the XML configuration file.
      <hostdev mode='subsystem' type='pci' managed='yes'>
            <source>
              <address bus='0x03' slot='0x10' function='0x01'/>
            </source>
      </hostdev>
      
    5. Save the configuration.
  9. Restart

    Restart the guest to complete the installation.
    # virsh start MyGuest
    
The guest should start successfully and detect a new network interface card. This new card is the Virtual Function of the SR-IOV device.

15.3. Troubleshooting SR-IOV

This section contains some issues and solutions for problems which may affect SR-IOV.
Error starting the guest
Start the configured vm , an error reported as follows:
# virsh start test
error: Failed to start domain test
error: internal error unable to start guest: char device redirected to
/dev/pts/2
get_real_device: /sys/bus/pci/devices/0000:03:10.0/config: Permission denied
init_assigned_device: Error: Couldn't get real device (03:10.0)!
Failed to initialize assigned device host=03:10.0
This error is often caused by a device which is already assigned to another guest or to the host itself.

Capítulo 16. Gerenciamento de tempo do convidado KVM

A virtualização coloca diversos desafios para a manutenção de tempo do convidado. Os convidados, os quais usam o Contador de Carimbo de Hora - Time Stamp Counter (TSC) como uma fonte de relógio, podem ter problemas com a contagem de tempo, pois algumas CPUs não possuem um Time Stamp Counter constante. Os convidados que são executados sem uma manutenção de tempo apurada, podem ter problemas sérios com alguns aplicativos em rede, pois seu convidado irá rodar mais rápido ou mais lento do que o tempo atual e sair da sincronização.
O KVM soluciona este problema, fornecendo convidados com o relógio para-virtualizado. Como forma alternativa, alguns convidados podem usar outras fontes de relógio x86 para suas contagens de tempo em versões futuras destes sistemas operacionais.
Atualmente, somente convidados Red Hat Enterprise Linux 5.4 e mais recentes suportam totalmente o relógio para-virtualizado.
Os convidados podem ter diversos problemas causados pela relógios e contadores inadequados:
  • Os relógios podem sair de sincronização com a hora atual que invalida as sessões e afeta as redes.
  • Os convidados com relógios mais lentos podem possuir problemas de migração.
Estes problemas existem em outras plataformas de virtualização e a hora deve ser sempre testada.

NTP

O daemon de Protocolo de Hora da Rede - Network Time Protocol (NTP) deve rodar no host e os convidados. Ative o serviço ntpd:
# service ntpd start
Adicione o serviço ntpd à seqüência de inicialização padrão:
# chkconfig ntpd on
O uso do serviço ntpd deve minimizar os efeitos da distorção do relógio em todos os casos.
Determinando se o seu CPU possui o Contador do Carimbo de Hora constante
Seu CPU possui um Contador de Carimbo de Hora, caso o aviso constant_tsc esteja presente. Para determinar se o seu CPU possui um aviso constant_tsc, rode o seguinte comando:
$ cat /proc/cpuinfo | grep constant_tsc
Caso qualquer saída for gerada, o seu CPU possuirá o trecho constant_tsc. Caso nenhuma saída seja fornecida, siga as instruções abaixo:
A configuração dos hosts sem um Contador de Carimbo de Hora constante
Os sistemas sem os contadores de carimbo de hora constante solicitam configuração adicional. Os recursos de gerenciamento potentes interferem em manter a hora atual e devem ser desativados para os convidados manterem a hora de acordo com o KVM.

Nota

Estas instruções são para os cpus F de revisão AMD apenas.
Caso o CPU não possua a parte constant_tsc, desative todos os recursos de gerenciamento potentes (BZ#513138). Cada sistema possui diversos cronômetros usados para controlar o tempo. O TSC não é estável para manter o host, que é às vezes causado pelas alterações do cpufreq, estado C profundo ou migração para um host com um TSC mais rápido. Para evitar que o kernel use os estados C, adicione "processor.max_cstate=1" às opções de inicialização do kernel no arquivo grub.conf no host:
term Red Hat Enterprise Linux Server (2.6.18-159.el5)
        root (hd0,0)
	kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet processor.max_cstate=1
Desative o cpufreq (apenas necessário nos hosts sem o constant_tsc) pela edição do arquivo da configuração /etc/sysconfig/cpuspeed e altere as variáveis MIN_SPEED e MAX_SPEED para a freqüência mais alta disponível. Os limites válidos podem ser encontrados nos arquivos /sys/devices/system/cpu/cpu*/cpufreq/scaling_available_frequencies.
Usando o relógio para-virtualizado com os convidados da Red Hat Enterprise Linux
Para certos convidados do Red Hat Enterprise Linux, parâmetros de kernel adicional são requeridos. Estes parâmetros podem ser configurados anexando-os ao final da linha do /kernel no arquivo /boot/grub/grub.conf do convidado.
A tabela abaixo lista as versões do Red Hat Enterprise Linux e os parâmetros solicitados para convidados nos sistemas sem o Contador do Carimbo da Hora constante.
Red Hat Enterprise LinuxParâmetros de kernel convidado adicional
5.4 AMD64/Intel 64 com o relógio para-virtualizadoParâmetros adicionais não são solicitados
5.4 AMD64/Intel 64 sem o relógio para-virtualizadodivider=10 notsc lpj=n
5.4 x86 com o relógio para-virtualizadoParâmetros adicionais não são solicitados
5.4 x86 com o relógio para-virtualizadodivider=10 clocksource=acpi_pm lpj=n
5.3 AMD64/Intel 64divider=10 notsc
5.3 x86divider=10 clocksource=acpi_pm
4.8 AMD64/Intel 64notsc divider=10
4.8 x86clock=pmtmr divider=10
3.9 AMD64/Intel 64Parâmetros adicionais não são solicitados
3.9 x86Parâmetros adicionais não são solicitados
Using the Real-Time Clock with Windows Server 2003 and Windows XP guests
O Windows usa o Real-Time Clock (RTC) e o Time Stamp Counter (TSC). Para os convidados do Windows o Real-Time Clock pode ser usado ao invés do TSC para todas as fontes de horário, o qual resolve os problemas de contagem de tempo do convidado.
Para ativar o Real-Time Clock para a fonte de relógio do PMTIMER (o PMTIMER geralmente usa o TSC), adicione a seguinte linha à configuração de inicialização do Windows. As configurações de inicialização do Windows são armazenadas no arquivo boot.ini. Adicione a seguinte linha ao arquivo boot.ini :
/use pmtimer
Para maiores informações a respeito do Windows e a opção pmtimer, refira-se ao Available switch options for the Windows XP and the Windows Server 2003 Boot.ini files.
Using the Real-Time Clock with Windows Vista, Windows Server 2008 and Windows 7 guests
O Windows usa o Real-Time Clock (RTC) e o Time Stamp Counter (TSC). Para os convidados do Windows o Real-Time Clock pode ser usado ao invés do TSC para todas as fontes de horário, o qual resolve os problemas de contagem de tempo do convidado.
The boot.ini file is no longer used from Windows Vista and newer. Windows Vista, Windows Server 2008 and Windows 7 use the Boot Configuration Data Editor (bcdedit.exe) to modify the Windows boot parameters.
This procedure is only required if the guest is having time keeping issues. Time keeping issues may not affect guests on all host systems.
  1. Open the Windows guest.
  2. Open the Accessories menu of the start menu. Right click on the Command Prompt application, select Run as Administrator.
  3. Confirm the security exception, if prompted.
  4. Set the boot manager to use the platform clock. This should instruct Windows to use the PM timer for the primary clock source. The system UUID ({default} in the example below) should be changed if the system UUID is different than the default boot device.
    C:\Windows\system32>bcdedit /set {default} USEPLATFORMCLOCK on
    The operation completed successfully
This fix should improve time keeping for Windows Vista, Windows Server 2008 and Windows 7 guests.

Parte IV. Administração

Capítulo 17. As melhores práticas do Servidor

As seguintes tarefas e dicas podem auxiliá-lo com a confiabilidade de segurança e garantia de seu host do servidor Red Hat Enterprise Linux 5 (dom0).
  • Rode o SELinux no modo enforcing. Você pode fazer isto executando o comando abaixo:
    # setenforce 1
    
  • Remova ou desative quaisquer serviços desnecessários, tais como AutoFS, NFS, FTP, HTTP, NIS, telnetd, sendmail e assim por diante.
  • Apenas adicione o número mínimo de contas de usuários necessárias para o gerenciamento da plataforma no servidor e remova as contas de usuário desnecessárias.
  • Evite rodar quaisquer aplicativos que não sejam essenciais em seu host. A execução de aplicativos no host pode influenciar o desempenho da máquina virtual e pode afetar a estabilidade do servidor. Qualquer aplicativo que falhe o servidor irá causar a paralisação de todas as máquinas virtuais no servidor.
  • Use uma localização central para as instalações de máquina virtual e imagens. As imagens da máquina virtual deve ser armazenada sob /var/lib/libvirt/images/. Caso você esteja usando um diretório diferente para suas imagens de máquina virtual, certifique-se de adicionar o diretório a sua política SELinux e etiquetá-lo novamente antes de inicializar a instalação.
  • Imagens, árvores e fontes de instalação devem ser armazenadas numa localização central, normalmente na localização de seu servidor vsftpd.

Capítulo 18. Segurança para a Tecnologia de Virtualização

Ao implementar a Tecnologia de Virtualização em sua empresa, assegure-se que o host não está comprometido. O host, no hipervisor Xen, é o domínio previlegiado que manipula o gerenciamento de sistema e gerencia todas as máquinas virtuais. Se o host não está seguro todos os outros domínios no sistemas estarão vulneráveis. Existem diversas formas de aumentar a segurança em sistemas usando a virtualização. Reuna-se com outras pessoas de sua empresa e crie um Plano de Implementação que contenha as especificações operacionais e serviços que serão necessários em seus convidados virtualizados e servidores de host , assim como o suporte necessário para estes serviços. Segue abaixo, alguns problemas de segurança que você deve levar em consideração ao fazer um plano de implementação:
  • Execute somente os serviços necessários nos hosts. Quanto menos processos e serviços sendo executados em um host, maior será o nível de segurança e desempenho.
  • Enable Security-Enhanced Linux (SELinux) on the hypervisor. Read Seção 18.2, “Tecnologia de Virtualização e SELinux” for more information on using SELinux and virtualization.
  • Use um firewall para restringir o tráfego para o dom0. Você pode ajustar um firewall com regras padrão-rejeitar que irão ajudar a proteger ataques em dom0. É também muito importante limitar serviços opostos de rede.
  • Não permita que usuários normais acessem o dom0. Se você permitir que usuários normais acessem o dom0, você correrá o risco de renderizar os dom0 vulneráveis. Lembre-se que o dom0 é privilegiado, e obter contas desprivilegiadas pode comprometer o nível de segurança.

18.1. Storage security issues

Administrators of virtualized guests can change the partitions the host boots in certain circumstances. To prevent this administrators should follow these recommendations:
The host should not use disk labels to identify file systems in the fstab file, the initrd file or used by the kernel command line. If less privileged users, especially virtualized guests, have write access to whole partitions or LVM volumes.
Guest should not be given write access to whole disks or block devices (for example, /dev/sdb). Use partitions (for example, /dev/sdb1) or LVM volumes.

18.2. Tecnologia de Virtualização e SELinux

Security Enhanced Linux was developed by the NSA with assistance from the Linux community to provide stronger security for Linux. SELinux limits an attackers abilities and works to prevent many common security exploits such as buffer overflow attacks and privilege escalation. It is because of these benefits that Red Hat recommends all Red Hat Enterprise Linux systems should run with SELinux enabled and in enforcing mode.
SELinux prevents guest images from loading if SELinux is enabled and the images are not correctly labeled. SELinux requires that image files have the virt_image_t label applied to them. The /var/lib/libvirt/images directory has this label applied to it and its contents by default. This does not mean that images must be stored in this directory; images can be stored anywhere, provided they are labeled with virt_image_t.
A adição do armazenamento com base em LVM com o SELinux em modo enforcing.
A seção a seguir é um exemplo da adição de um volume lógico para um convidado virtualizado com o SELinux ativado. Estas instruções também funcionam para as partições de drive rígido.
Procedimento 18.1. Criando e montando um volume lógico em um convidado virtualizado com o SELinux ativado.
  1. Criar um volume lógico. Este exemplo cria um volume lógico de 5 gigabyte chamado NewVolumeName no grupo de volume chamado volumegroup.
    # lvcreate -n NewVolumeName -L 5G volumegroup
  2. Formate o volume lógico NewVolumeName com um sistema de arquivo que suporte os atributos estendidos, tais como ext3.
    # mke2fs -j /dev/volumegroup/NewVolumeName
    
  3. Crie um novo diretório para a montagem do novo volume lógico. Este diretório pode estar em qualquer lugar em seu sistema de arquivo. Recomenda-se não colocá-lo em diretórios de sistema importantes (/etc, /var, /sys) ou em diretórios locais (/home or /root). Este exemplo usa o diretório chamado /virtstorage
    # mkdir /virtstorage
    
  4. Monte um volume lógico
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. Set the correct SELinux type for a Xen folder.
    semanage fcontext -a -t xen_image_t "/virtstorage(/.*)?"
    
    Como forma alternativa, defina o tipo correto do SELinux para uma pasta KVM.
    semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"
    
    Se a política alvo é usada (a política alvo é a padrão) o comando adiciona uma linha ao arquivo /etc/selinux/targeted/contexts/files/file_contexts.local o qual torna a mudança persistente. A linha adicionada pode se parecer com esta:
    /virtstorage(/.*)?    system_u:object_r:xen_image_t:s0
    
  6. Label the device node (for example, /dev/volumegroup/NewVolumeName with the correct label:
    # semanage fcontext -a -t xen_image_t /dev/volumegroup/NewVolumeName
    # restorecon /dev/volumegroup/NewVolumeName
    

18.3. SELinux

Esta seção contém alguns fatores que devem ser considerados ao implementar um SELinux em seu ambiente de Tecnologia de Virtualização. Quando você implementar as mudanças de sistema ou adicionar dispositivos, você deve atualizar sua política SELinux de forma correta. Para configurar um volume LVM para um convidado, você deve modificar o contexto SELinux para o dispositivo de bloqueio adjacente respectivamente e o grupo de volume.
# semanage fcontext -a -t xen_image_t -f -b /dev/sda2
# restorecon /dev/sda2
O parâmetro booleano xend_disable_t pode definir o xend em um modo desconfinado, após reiniciar o daemon. É melhor desabilitar a proteção para um daemon simples do que para todo um sistema. Aconselha-se que você não reetiquete os diretórios como xen_image_t pois, você poderá precisar para algum outro lugar.
KVM and SELinux
There are several SELinux booleans which affect KVM. These booleans are listed below for your convenience.
KVM SELinux Booleans
SELinux BooleanDescription
allow_unconfined_qemu_transitionDefault: off. This boolean controls whether KVM guests can be transitioned to unconfined users.
qemu_full_networkDefault: on. This boolean controls full network access to KVM guests.
qemu_use_cifsDefault: on. This boolean controls KVM's access to CIFS or Samba file systems.
qemu_use_commDefault: off. This boolean controls whether KVM can access serial or parallel communications ports.
qemu_use_nfsDefault: on. This boolean controls KVM's access to NFS file systems.
qemu_use_usbDefault: on. This boolean allows KVM to access USB devices.

18.4. Virtualization firewall information

Various ports are used for communication between virtualized guests and management utilities.

Guest network services

Any network service on a virtualized guest must have the applicable ports open on the guest to allow external access. If a network service on a guest is firewalled it will be inaccessible. Always verify the guests network configuration first.
  • ICMP requests must be accepted. ICMP packets are used for network testing. You cannot ping guests if ICMP packets are blocked.
  • Port 22 should be open for SSH access and the initial installation.
  • Ports 80 or 443 (depending on the security settings on the RHEV Manager) are used by the vdsm-reg service to communicate information about the host.
  • Ports 5634 to 6166 are used for guest console access with the SPICE protocol.
  • Port 8002 is used by Xen for live migration.
  • Ports 49152 to 49216 are used for migrations with KVM. Migration may use any port in this range depending on the number of concurrent migrations occurring.
  • Enabling IP forwarding (net.ipv4.ip_forward = 1) is required for virtual bridge devices. Note that installing libvirt enables this variable so it will be enabled when the virtualization packages are installed unless it was manually disabled.

Nota

Note that enabling IP forwarding is not required for physical bridge devices. When a guest is connected through a physical bridge, traffic only operates at a level that does not require IP configuration such as IP forwarding.

Capítulo 19. Gerenciando convidados com xend

O daemon de controle de nó do Xend realiza certas funções de gerenciamento de sistema que se refere à máquinas virtuais. Este daemon controla os recursos virtualizados, e o Xend precisa estar rodando para interagir com as máquinas virtuais. Antes de você iniciar o xend, você deve especificar os parâmetros operacionais, editando o arquivo de configuração doxend, /etc/xen/xend-config.sxp . Estes são os parâmetros que você pode habilitar ou desabilitar no arquivo de configuração xend-config.sxp:
Tabela 19.1. Arquivo de Configuração xend
Ítem Descrição
(console-limit)
Determines the console server's memory buffer limit and assigns that limit on a per domain basis.
(min-mem)
Determina um número mínimo de megabytes que seja reservado para o domínio0 (se você inserir 0, o valor não muda).
(dom0-cpus)
Determina o número de CPUs em uso pelo domínio0 (pelo menos 1 CPU é atribuído por padrão).
(enable-dump)
Se estiver ativado, quando ocorrer um travamento, o Xen cria um arquivo dump (padrão é 0).
(external-migration-tool)
Determina o script ou aplicativo que manipula a migração de dispositivo externo. Os scripts devem residir no etc/xen/scripts/external-device-migrate.
(logfile)
Determina o local do arquivo de registro (padrão é /var/log/xend.log).
(loglevel)
Filtros fora dos valores de modo de registro: DEBUG, INFO, WARNING, ERROR, ou CRITICAL (padrão é DEBUG).
(network-script)
Determina o script que habilita o ambiente de rede. Os scripts devem residir no diretório etc/xen/scripts .
(xend-http-server)
Habilita o servidor de gerenciamento de pacote da faixa http (padrão é não).
(xend-unix-server)
Habilita o servidor de soquete de domínio UNIX. O servidor de soquete é a ponta de comunicação que manipula níveis baixos de conexões de rede e aceita ou rejeita conexões de entrada. O valor padrão é configurado para sim.
(xend-relocation-server)
Habilita o servidor de recolocação para migrações de cross-machine (padrão é não).
(xend-unix-path)
Determina o local onde o comando xend-unix-server resulta os dados (padrão é var/lib/xend/xend-socket)
(xend-port)
Determina a porta que o servidor de gerenciamento http usa (padrão é 8000).
(xend-relocation-port)
Determina a porta que o servidor de recolocação usa (padrão é 8002).
(xend-relocation-address)
Determina os endereços de host permitidos para migração. O valor padrão é o valor de xend-address.
(xend-address)
Determina o endereço que o servidor de soquete de domínio se vincula. O valor padrão permite todas as conexões.

Depois de ajustar estes parâmetros operacionais, você deve verificar se o xend está rodando e caso não esteja, inicialize o daemon. Na janela de comando, você pode iniciar o daemon xend inserindo o seguinte:
service xend start
Você pode usar o xend para parar o daemon:
service xend stop
Isto irá parar de executar o daemon
Você pode usar o xend para reinicializar o daemon:
service xend restart
O daemon iniciará mais uma vez.
Você verifica o status do daemon xend.
service xend status
The output displays the daemon's status.

Habilitando xend durante a inicialização

Use o comando chkconfig para adicionar o xend para o initscript.
chkconfig --level 345 xend
O xend iniciará os níveis de execução 3, 4 e 5.

Capítulo 20. Migração Ativa do Xen

The Xen hypervisor supports Virtualization Migration for para-virtualized guests and fully virtualized guests. Migration is only supported on Red Hat Enterprise Linux 5.1 and newer systems. Migration can be performed offline or live.
  • A migração em offline suspende o convidado virtualizado no host original, transfere'o para o host de destino e depois resume-o depois que o convidado estiver totalmente transferido. A migração em offline usa o comando virsh migrate.
    # virsh migrate GuestName libvirtURI
  • A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. The Xen hypervisor estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until Xen predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
    A migração ativa usa a opção --live para o comando virsh migrate.
    # virsh migrate--live GuestName libvirtURI

Nota de suporte do Itanium®

A migração não é suportada atualmente na arquitetura Itanium®.
Para ativar a migração com o Xen, deve-se realizar algumas mudanças no arquivo de configuração /etc/xen/xend-config.sxp. Por padrão, a migração é desativada, pois a migração pode ser um alto risco de segurança caso seja configurado de forma errada. Abrir uma porta de migração, pode permitir que um host não autorizado inicie uma migração ou se conecte à portas de migração. A autenticação e autorização não são configuradas para os requisitos de migração e somente o mecanismo de controle é baseado em endereços de hostnames e IP. Deve-se tomar um cuidado especial para garantir que a porta de migração não seja acessada por hosts não autorizados.

Segurança de migração de virtualização.

O endereço IP e filtros de hostname somente oferecem uma segurança mínima. Ambos estes atributos podem ser forjados se o atacante souber o endereço ou hostname do cliente de migração. O melhor método para assegurar migração é isolar a rede de conexões internas não autorizadas e externas.
Ativando a Migração
Mofifique as seguintes entradas em /etc/xen/xend-config.sxp para ativar a migração. Modifique os valores, quando necessário, e remova os comentários (o símbolo #) precendendo os seguintes parâmetros:
(xend-relocation-server yes)
O valor padrão, o qual desabilita a migração, é o no. Mude o valor do xend-relocation-server para yes para ativar a migração.
(xend-relocation-port 8002)
O parâmetro (xend-relocation-port), especifica a porta que xend deve usar para a interface de relocação, se xend-relocation-server estiver definido para yes
O valor padrão desta variante deve funcionar para a maioria das instalações. Se você mudar o valor, lembre-se de que está usando um porta nova no servidor de relocação.
A porta definida pelo parâmetro xend-relocation-port deve ser aberta em ambos os sistemas.
(xend-relocation-address '')
(xend-relocation-address) é o endereço que o xend ouve para os comandos de migração na conexão do relocation-socket se o xend-relocation-server estiver definido.
The default is to listen on all active interfaces. The (xend-relocation-address) parameter restricts the migration server to only listen to a specific interface. The default value in /etc/xen/xend-config.sxp is an empty string(''). This value should be replaced with a single, valid IP address. For example:
(xend-relocation-address '10.0.0.1')
(xend-relocation-hosts-allow '')
The (xend-relocation-hosts-allow 'hosts') parameter controls which hostnames can communicate on the relocation port.
Unless you are using SSH or TLS, the guest's virtual memory is transferred in raw form without encryption of the communication. Modify the xend-relocation-hosts-allow option to restrict access to the migration server.
Se o valor estiver vazio, como denotado no exemplo acima por uma faixa vazia rodeada de cotas únicas, então todas as conexões são permitidas. Isto significa que a conexão chega em uma porta e interface na qual o servidor de relocação ouve, veja também xend-relocation-port e xend-relocation-address.
Caso contrário, o parâmetro (xend-relocation-hosts-allow) deve ser uma sequência de expressões regulares separadas por espaços. Qualquer host ocm um nome de domínio totalmente qualificado ou um endereço IP o qual coincide com uma destas expressões regulares, serã aceito.
Um exemplo de um atributo de (xend-relocation-hosts-allow):
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
Depois que você configurou os parâmetros em seu arquivo de configuração, reinicie o serviço Xen.
# service xend restart

20.1. Um exemplo de migração ativa

Abaixo, segue um exemplo de como configurar um ambiente simples para migração ativa. Esta configuração está usando o NFS para o armazenamento compartilhado. O NFS se adequa à ambientes de demonstração mas para um ambiente de produção, recomenda-se uma configuração de armazenamento compartilhado mais robusto, usando o Canal de Fibra ou iSCSI e GFS.
A configuração abaixo consiste de dois servidores (et-virt07 e et-virt08), ambos usando o eth1 como sua interface de rede padrão, apesar de usarem o xenbr1 como sua ponte de rede do Xen. Estamos usando um disco SCSI anexado localmente (/dev/sdb) em et-virt07 para armazenamento compartilhado, usando NFS.
Configuração de migração ativa
Crie e monte o diretório usado para migração:
# mkdir /var/lib/libvirt/images
# mount /dev/sdb /var/lib/libvirt/images

Importante

Assegure-se de que o diretório é exportado com as opções corretas. Se você estiver exportando o diretóri padrão /var/lib/libvirt/images/ assegure-se de que você somente exportará o /var/lib/libvirt/images/ e não/var/lib/xen/ pois este diretório é usado pelo daemon xend e outras ferramentas. Compartilhar /var/lib/xen/ causará um comportamente imprevizível.
# cat /etc/exports
/var/lib/libvirt/images  *(rw,async,no_root_squash)
Verifique se ele é exportado via NFS:
# showmount -e et-virt07
Export list for et-virt07:
/var/lib/libvirt/images *
Instalar o convidado
O comando de instalação no exemplo usado para instalar o convidado:
# virt-install -p -f /var/lib/libvirt/images/testvm1.dsk -s 5 -n\
testvm1 --vnc -r 1024 -l http://example.com/RHEL5-tree\
Server/x86-64/os/ -b xenbr1
For step by step installation instructions, refer to Capítulo 8, Procedimentos de instalação do sistema operacional convidado.
Verifique o ambiente para migração
Lembre-se de que as pontes de rede virtualizadas são configuradas corretamente e possuem o mesmo nome em ambas as máquinas:
[et-virt08 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
[et-virt07 ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr1          8000.feffffffffff       no              peth1
vif0.1
Verifique se os parâmetros de relocação estão configurados em ambas as máquinas:
[et-virt07 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
[et-virt08 ~]# grep xend-relocation /etc/xen/xend-config.sxp |grep -v '#'
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
Verifique se o servidor de relocação iniciou e está aguardando na porta dedicada para migrações do Xen (8002):
[et-virt07 ~]# lsof -i :8002
COMMAND  PID  USER   FD   TYPE  DEVICE SIZE NODE NAME
python 3445 root 14u IPv4 10223 TCP *:teradataordbms (LISTEN)
[et-virt08 ~]# lsof -i :8002
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
python 3252 root 14u IPv4 10901 TCP *:teradataordbms (LISTEN)
That the default /var/lib/libvirt/images directory is available and mounted with networked storage on both hosts. Shared, networked storage is required for migrations.
[et-virt08 ~]# df /var/lib/libvirt/images
Filesystem           1K-blocks      Used Available Use% Mounted on
et-virt07:/var/lib/libvirt/images    70562400   2379712  64598336   4% /var/lib/libvirt/images
[et-virt08 ~]# file /var/lib/libvirt/images/testvm1.dsk 
/var/lib/libvirt/images/testvm1.dsk: x86 boot sector; partition 1: ID=0x83,
active, starthead 1, startsector 63, 208782 sectors; partition 2: ID=0x8e, 
starthead 0, startsector 208845, 10265535 sectors, code offset 0x48
[et-virt08 ~]# touch /var/lib/libvirt/images/foo
[et-virt08 ~]# rm -f /var/lib/libvirt/images/foo
Verifique se está salvando ou recuperando o convidado
Iniciar a máquina virtual ( se a máquina virtual não estiver ligada):
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
[et-virt07 ~]# virsh start testvm1
Domain testvm1 started
Verificar se a máquina virtual está rodando:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Salvar a máquina virtual no host local:
[et-virt07 images]# time virsh save testvm1 testvm1.sav
real    0m15.744s
user    0m0.188s
sys     0m0.044s
[et-virt07 images]# ls -lrt testvm1.sav
-rwxr-xr-x 1 root root 1075657716 Jan 12 06:46 testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Recupere a máquina virtual no host local:local:
[et-virt07 images]# virsh restore testvm1.sav
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Start the live migration of domain-id from et-virt08 to et-virt07. The hostname you are migrating to and <domain-id> must be replaced with valid values. This example uses the et-virt08 host which must have SSH access to et-virt07
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
Verify the virtual machine is no longer present on et-virt08
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Verify the virtual machine has been migrated to et-virt07:
[et-virt07 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        running
Testando o progresso e iniciando a migração ativa
Create the following script inside the virtual machine to log date and hostname during the migration. This script performs I/O tasks on the guest's file system.
#!/bin/bash

while true
do
touch /var/tmp/$$.log
echo `hostname` >>  /var/tmp/$$.log
	echo `date`     >>  /var/tmp/$$.log
	cat  /var/tmp/$$.log
	df /var/tmp
	ls -l  /var/tmp/$$.log
	sleep 3
	done
Lembre-se que o script é somente para propósito de teste e desnecessário para uma migração ativa em um ambiente de produção.
Verifique se a máquina virtual está rodando no et-virt08 antes de tentarmos migrá-lo para et-virt07:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Inicie uma migração ativa para et-virt07. Você pode adicionar o time para ver quando tempo a migração demora:
[et-virt08 ~]# xm migrate --live testvm1 et-virt07
rode o script dentro do convidado:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 02:26 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:30 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:33 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 02:26 /var/tmp/2279.log
Fri Jan 12 02:26:45 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:48 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:51 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:54:57 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:55:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 744 Jan 12 06:55 /var/tmp/2279.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:26:27 EST 2007
Verifique se a máquina virtual foi fechada em et-virt08:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Verifique se a máquina virtual foi iniciada em et-virt07:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
Rode através de outra migração de ciclo a partir do et-virt07 para o et-virt08. Inicie uma migração do et-virt07 para o et-virt08:
[et-virt07 images]# xm migrate --live testvm1 et-virt08
Verifique se a máquina virtual foi fechada:
[et-virt07 images]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
Antes de iniciar a migração, inicie o script simples no convidado e observe a mudança no tempo quando migrar o convidado:
# ./doit
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 62 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 124 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 186 Jan 12 06:57 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 248 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 310 Jan 12 02:30 /var/tmp/2418.log
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:53 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:57:56 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 06:58:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:00 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:03 EST 2007
dhcp78-218.lab.boston.redhat.com
Fri Jan 12 02:30:06 EST 2007
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
2983664   2043120    786536  73% /
-rw-r--r-- 1 root root 372 Jan 12 02:30 /var/tmp/2418.log
Depois que o comando de migração for concluído no et-virt07 verifique em et-virt08 que a máquina virtual iniciou:
[et-virt08 ~]# virsh list
 Id Name                 State
----------------------------------
Domain-0                 running
testvm1        blocked
e rode um outro ciclo:
[et-virt08 ~]# time virsh migrate --live testvm1 et-virt07
real    0m10.378s
user    0m0.068s
sys     0m0.052s
Neste ponto você já realizou um teste de migração em offline e ativo com sucesso.

20.2. Configurando a migração ativa do convidado

Esta seção trata sobre migração offline de convidados Xen para para outros servidores rodando um Red Hat Enterprise Linux. Mais adiante, a migração é realizada no método offline (usando o comando xm migrate ). A migração ativa pode ser feita a partir do mesmo comando. No entanto, existem algumas modificações adicionais que você deve fazer para o arquivo de configuração xend-config . Este exemplo identifica as entradas que você deve modificar para garantir uma migração bem sucedida:
(xend-relocation-server yes)
The default for this parameter is 'no', which keeps the relocation/migration server deactivated (unless on a trusted network) and the domain virtual memory is exchanged in raw form without encryption.
(xend-relocation-port 8002)
Este parâmetro ajusta a porta que o xend usa para migração.Usa este valor a não ser que seu ambiente de rede requeira um valor padronizado. Lembre-se de remover o símbolo de comentário para ativá-la.
(xend-relocation-address )
Este parâmetro é o endereço que recebe as conexões de soquete de recolocação, depois de habilitar o xend-relocation-server . O hypervisor Xen espera somente pelo tráfego de rede de migração na interface específica.
(xend-relocation-hosts-allow )
Este parâmetro controla a máquina que comunica com a porta de recolocação. Se o valor for vazio, todas as conexões de entrada serão permitidas. Você deve mudar isto para sequências de espaço separado de expressões comuns, como por exemplo:
(xend-relocation-hosts-allow- '^localhost\\.localdomain$' )>
Valores aceitos inclusos nos nomes de domínios totalmente qualificados, endereços de IP expressões regulares com separação de espaço.
Depois de configurar, reinicialize o host para carregar as novas configurações.

Capítulo 21. Migração Ativa KVM

Este capítulo cobre os convidados de migração rodando num hypervisor KVM a outro host KVM.
Migration is the process of moving a virtualized guest from one host to another. Migration is a key feature of virtualization as software is completely separated from hardware. Migration is useful for:
  • Carregamento de carga - os convidados podem ser movidos aos hosts de mais baixo uso quando um host torna-se sobrecarregado.
  • Falha de Hardware - quando os dispositivos de hardware no host começam a falhar, os convidados podem ser seguramente alocados, de forma que o host pode ser desligado e ajustado.
  • Economia de Energia - os convidados podem ser redistribuídos a outros hosts e sistemas de hosts desligados para economizar energia e cortar custos em períodos de baixo uso.
  • Migração Geográfica - os convidados podem ser movidos a outra localização para uma latência mais baixa ou em sérias circunstâncias.
Migrations can be performed live or offline. To migrate guests the storage must be shared. Migration works by sending the guests memory to the destination host. The shared storage stores the guest's default file system. The file system image is not sent over the network from the source host to the destination host.
A migração desativada suspende o convidado e move uma imagem da memória convidada ao host destino. O convidado é simplificado no host de destino e a memória do convidado usada no host fonte é liberada.
O período que uma migração desativada levará, dependerá da latência e largurade banda da rede. Um convidado com 2GB de memória deve levar uma média de dez ou mais segundos em uma conexão de 1 Gbit Ethernet.
Uma migração ativa mantém o convidado rodando em um host fonte e inicializa a movimentação da memória sem interromper o convidado. Todas as páginas de memórias modificadas são monitoradas para mudanças e enviadas ao destino, enquanto a imagem é enviada. A memória é atualizada com as páginas alteradas. O processo continua até que a quantia de tempo de pausa permitida ao convidado se iguala ao tempo premeditado para as poucas páginas finais serem transferidas. O KVM estima o restante do tempo e tenta transferir a quantia máxima de página desde a fonte ao destino, até que o KVM prevê a quantia de páginas remanescentes que podem ser transferidas durante muito pouco tempo, enquanto o convidado virtualizado estiver em pausa. Os registros são carregados no novo host e o convidado é resumido no host de destino. Caso o convidado não possa ser mesclado (o que acontece quando convidados estão sob carregamentos extremos), o convidado será pausado e em troca a migração offline será inicializada.
O período que uma migração desativada levará, dependerá da latência e largura de banda da rede. Se a rede estiver sendo muito usada ou em banda baixa, a migração levará muito mais tempo.

21.1. Solicitações da Migração Ativa

A migração de convidados solicita o seguinte:
Solicitações de Migração
  • Um convidado virtualizado instalado num armazenamento com rede compartilhada usando um dos seguintes protocolos:
    • Canal de Fibra
    • iSCSI
    • NFS
    • GFS2
  • Dois ou mais sistemas do Red Hat Enterprise Linux da mesma versão com as mesmas atualizações.
  • Ambos os sistemas devem possuir portais apropriados abertos.
  • Ambos os sistemas devem possuir configurações de rede idênticas. Todas as pontes e configurações de rede devem ser exatamente as mesmas em ambos os hosts.
  • O armazenamento compartilhado deve montar na mesma localização dos sistemas de destino e fonte. O nome do diretório montado deve ser idêntico.
Configurando o armazenamento da rede
Configure shared storage and install a guest on the shared storage. For shared storage instructions, refer to Parte V, “Virtualization Storage Topics”.

21.2. Compartilhe a amostra de armazenamento: NFS para uma migração simples

Esta amostra usa o NFS para compartilhar imagens de convidado com outros convidados KVM. Esta amostra não é prática para instalações grandes, ela serve apenas para demonstração das técnicas de migração e implementações pequenas. Não use esta amostra para migrar ou executar mais do que alguns convidados virtualizados.
For advanced and more robust shared storage instructions, refer to Parte V, “Virtualization Storage Topics”
  1. Exporte seu diretório de imagem libvirt

    Adicione o diretório de imagem padrão ao arquivo /etc/exports:
    /var/lib/libvirt/images *.example.com(rw,no_root_squash,async)
    
    Altere os parâmetros dos hosts, conforme solicitado para seu ambiente.
  2. Inicialize o NFS

    1. Instale os pacotes NFS, caso eles não tenham sido instalados:
      # yum install nfs
      
    2. Abra os portais para o NFS no iptables e adicione o NFS ao arquivo/etc/hosts.allow.
    3. Inicialize o serviço NFS:
      # service nfs start
      
  3. Monte o armazenamento compartilhado no destino

    No sistema de destino, monte o diretório /var/lib/libvirt/images:
    # mount sourceURL:/var/lib/libvirt/images /var/lib/libvirt/images
    

    As localizações devem estar na mesma fonte e destino

    Independente do diretório escolhido para os convidados, ele deve ser exatamente o mesmo no host e convidado. Isto aplica-se a todos os tipos de armazenamento compartilhado. O diretório deve ser o mesmo ou a migração falhará.

21.3. Migração KVM Ativa com virsh

Um convidado pode serr migrado a outro host com o comando virsh. O comando migrate aceita os parâmetros no seguinte formato:
# virsh migrate --live GuestName DestinationURL
O parâmetro GuestName representa o nome do convidado que você deseja migrar.
O parâmetro DestinationURL é o URL ou hostname do sistema de destino. O sistema de destino deve rodar a mesma versão do Red Hat Enterprise Linux, usando o mesmo hypervisor e possuir o libvirt rodando.
Uma vez que o comando é inserido, você terá inserir a senha raiz do sistema de destino.
Amostra: migração ativa com virsh
Esta amostra migra a partir do test1.example.com ao test2.example.com. Altere os nomes host para seu ambiente. Esta amostra migra uma máquina virtual nomeada RHEL4test.
This example assumes you have fully configured shared storage and meet all the prerequisites (listed here: Solicitações de Migração).
  1. Verifique se o convidado está rodando

    A partir do sistema fonte, test1.example.com, verifique se o RHEL4test está rodando:
    [root@test1 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
  2. Migre o convidado

    Execute o seguinte comando para a migração ativa do convidado à destino, test2.example.com. Anexe o /system ao final do destino URL para informar ao libvirt que você precisa de acesso completo.
    # virsh migrate --live RHEL4test qemu+ssh://test2.example.com/system
    Uma vez que o comando é inserido, você terá inserir a senha raiz do sistema de destino.
  3. Espere

    A migração pode levar algum tempo, dependendo da carga e tamanho do convidado. O virsh apenas reporta erros. O convidado continua a rodar o host fonte até a completa migração.
  4. Verifique se o convidado chegou ao host destino

    A partir do sistema de destino, test2.example.com, verifique se o RHEL4test está rodando:
    [root@test2 ~]# virsh list
    Id Name                 State
    ----------------------------------
     10 RHEL4                running
    
A migração ativa está completa agora.

Outros métodos de rede

libvirt supports a variety of networking methods including TLS/SSL, unix sockets, SSH, and unencrypted TCP. Refer to Capítulo 22, Gerenciamento remoto de convidados virtualizados for more information on using other methods.

21.4. Migrando com o virt-manager

Esta seção cobre a migração de convidados de KVM baseados com o virt-manager.
  1. Conecte os hosts fonte e destino. No menu Arquivo, clique em Adicionar Conexão, a janela Adicionar Conexão aparecerá.
    Entre os seguintes detalhes:
    • Hypervisor: Selecione QEMU.
    • Conexão: Selecione o tipo de conexão.
    • Hostname: Entre o hostname.
    Clique em Conectar.
    O Gerenciador de Máquina Virtual exibirá uma lista de hosts conectados.
  2. Adicione um pool de armazenamento com o mesmo NFS aos hosts fonte e destino.
    No menu Editar, clique nos Detalhes do Host, a janela dos Detalhes do Host aparecerá.
    Clique na aba Armazenamento.
  3. Adicione um novo pool de armazenamento. No canto esquerdo inderior da janela, clique bo botão +. Aparecerá uma janela Adicionar um Novo Pool de Armazenamento.
    Entre os seguintes detalhes:
    • Nome: Entre o nome do pool de armazenamento.
    • Tipo: Selecione netfs: Diretório de Exportação de Rede.
    Clique em Próximo.
  4. Entre os seguintes detalhes:
    • Formato: Seleciona o tipo de armazenamento. Ele deve ser NFS ou iSCSI para migrações ativas.
    • Nome do Host: Entra o endereço IP ou nome do domínio completamente qualificado do servidor de armazenamento.
    Clique em Finalizar.
  5. Crie um novo volume no pool de armazenamento qualificado, clique em Novo Volume.
  6. Insira os detalhes e clique em Criar Volume.
  7. Crie uma máquina virtual com o novo volume e rode a máquina virtual.
    Aparecerá uma janela de Máquina Virtual.
  8. Na janela do Gerenciador de Máquina Virtual, clique com o botão direito na máquina virtual, selecione Migrar e clique na localização da migração.
  9. Clique em Sim para confirmar a migração.
    The Virtual Machine Manager displays the virtual machine in its new location.
    The VNC connection displays the remote host's address in its title bar.

Capítulo 22. Gerenciamento remoto de convidados virtualizados

Esta seção explica como gerenciar remotamente seus convidados virtualizados usando o ssh ou TLS e SSL.

22.1. Gerenciamento remoto com o SSH

O pacote ssh fornece um protocolo de rede criptografada, a qual pode enviar funções de gerenciamento, com segurança, para servidores de virtualização remotos. O método descrito usa a conexão de gerenciamento libvirt sintonizada de forma segura com uma conexão SSH, para gerenciar máquinas remotas. Todas as autenticações são realizadas com a criptografia de chave pública e senhas ou frases de senha SSH reunidas pelo seu agente de SSH local. Além disso, o console do VNC para cada máquina virtual de agente é sintonizado com SSH.
O SSH é configurado geralmente por padrão, portanto você provavelmente já possua chaves SSH definidas e não será necessário definir regras extras para acessar o serviço de gerenciamento ou console VNC.
Lembre-se dos problemas ao usar o xm para gerenciar remotamente suas máquinas virtuais, incluindo:
  • você precisará de um loggin root de acesso para máquinas remotas para gerenciar máquinas virtuais.
  • o processo de configuração de conexão inicial pode ser lento.
  • there is no standard or trivial way to revoke a user's key on all hosts or guests, and
  • ssh não escala bem com números maiores de máquinas remotas.
Configuring password less or password managed SSH access for virt-manager
The following instructions assume you are starting from scratch and do not already have SSH keys set up. If you have SSH keys set up and copied to the other systems you can skip this procedure.

The user is important for remote management

SSH keys are user dependent. Only the user who owns the key may access that key.
virt-manager must run as the user who owns the keys to connect to the remote host. That means, if the remote systems are managed by a non-root user virt-manager must be run in unprivileged mode. If the remote systems are managed by the local root user then the SSH keys must be own and created by root.
You cannot manage the local host as an unprivileged user with virt-manager.
  1. Optional: Changing user

    Change user, if required. This example uses the local root user for remotely managing the other hosts and the local host.
    $ su -
  2. Generating the SSH key pair

    Generate a public key pair on the machine virt-manager is used. This example uses the default key location, in the ~/.ssh/ directory.
    $ ssh-keygen -t rsa
    
  3. Coping the keys to the remote hosts

    Remote login without a password, or with a passphrase, requires an SSH key to be distributed to the systems being managed. Use the ssh-copy-id command to copy the key to root user at the system address provided (in the example, root@example.com).
    # ssh-copy-id -i ~/.ssh/id_rsa.pub root@example.com root@example.com's password: Now try logging into the machine, with "ssh 'root@example.com'", and check in: .ssh/authorized_keys to make sure we haven't added extra keys that you weren't expecting 
    
    Repeat for other systems, as required.
  4. Optional: Add the passphrase to the ssh-agent

    Add the passphrase for the SSH key to the ssh-agent, if required. On the local host, use the following command to add the passphrase (if there was one) to enable password-less login.
    # ssh-add ~/.ssh/id_rsa.pub
The SSH key was added to the remote system.
The libvirt daemon (libvirtd)
The libvirt daemon provide an interface for managing virtual machines. You must have the libvirtd daemon installed and running on every remote host that needs managing.
$ ssh root@somehost
# chkconfig libvirtd on
# service libvirtd start
Depois que o libvirtd e SSH forem configurados, você deve conseguir acessar remotamente suas máquinas virtuais. Nesta fase, você também pode conseguir acessar seus convidados com o VNC .
Accessing remote hosts with virt-manager
Remote hosts can be managed with the virt-manager GUI tool. SSH keys must belong to the user executing virt-manager for password-less login to work.
  1. Start virt-manager.
  2. Open the File->Add Connection menu.
  3. Input values for the hypervisor type, the connection, Connection->Remote tunnel over SSH, and enter the desired hostname, then click connection.

22.2. Gerenciamento remoto em TLS e SSL

You can manage virtual machines using TLS and SSL. TLS and SSL provides greater scalability but is more complicated than ssh (refer to Seção 22.1, “Gerenciamento remoto com o SSH”). TLS and SSL is the same technology used by web browsers for secure connections. The libvirt management connection opens a TCP port for incoming connections, which is securely encrypted and authenticated based on x509 certificates. In addition the VNC console for each guest virtual machine will be setup to use TLS with x509 certificate authentication.
This method does not require shell accounts on the remote machines being managed. However, extra firewall rules are needed to access the management service or VNC console. Certificate revocation lists can revoke users' access.
Passos para definir o acesso TLS/SSL para virt-manager
O guia breve a seguir, pressupõe que você esteja iniciando e que ainda não possua qualquer conhecimento sobre certificado TLS/SSL. Se você tiver sorte suficiente para ter um servidor de gerenciamento de certificado, você provavelmente poderá pular estes primeiros passos.
libvirt server setup
Para mais informações sobre como criar certificados, consulte a página da Web libvirt website, http://libvirt.org/remote.html.
Xen VNC Server
O servidor VNC do Xen pode ter o TLS ativado, editando o arquivo de configuração,/etc/xen/xend-config.sxp. Remova o comentário no parâmetro de configuração do (vnc-tls 1) no arquivo de configuração.
The /etc/xen/vnc directory needs the following 3 files:
  • ca-cert.pem - The CA certificate
  • server-cert.pem - The Server certificate signed by the CA
  • server-key.pem - The server private key
This provides encryption of the data channel. It might be appropriate to require that clients present their own x509 certificate as a form of authentication. To enable this remove the commenting on the (vnc-x509-verify 1) parameter.
Configuração de cliente virt-manager e virsh
A configuração para clientes é um pouco inconsistente atualmente. Para ativar o API sobre TLS de gerenciamento de libvirt, os certificados do CA e cliente devem ser colocados em /etc/pki.Para maiores detalhes sobre isto, consulte http://libvirt.org/remote.html
In the virt-manager user interface, use the 'SSL/TLS' transport mechanism option when connecting to a host.
Para virsh, o URI possui o seguinte formato:
  • qemu://hostname.guestname/system para KVM.
  • xen://hostname.guestname/para Xen.
Para ativar o SSL e TLS para VNC, é necessário colocar a autoridade do certificado e cerficados de cliente em $HOME/.pki, os quais são estes três arquivos:
  • CA ou ca-cert.pem - O certificado CA
  • libvirt-vnc ou clientcert.pem - O certificado do cliente assinado pelo CA.
  • libvirt-vnc ou clientkey.pem - A chave privada do cliente.

22.3. Modos de transporte

Para gerenciamento remoto, o libvirt suporta os seguintes modos de transporte:
Transport Layer Security (TLS - Segurança de Camada de Transporte)
O Transport Layer Security TLS 1.0 (SSL 3.1) autenticado e criptografado soquete TCP/IP, geralmente ouvidno em um número de porta pública. Para usá-lo você precisará gerar certificados de servidor e cliente. A porta padrão é 16514.
Soquetes UNIX
Os soquetes de domínio do UNIX são acessíveis somente na máquina local. Os soquetes não são criptografados, e usa permissões do UNIX ou SELinux para autenticações. Os nomes de soquete padrão são /var/run/libvirt/libvirt-sock e /var/run/libvirt/libvirt-sock-ro (para conexões de somente-leitura).
SSH
Transportado pela conexão Secure Shell Protocol (SSH - Protocolo de Shell Seguro). Necessita do Netcat (o pacote nc) instalado. O daemon do libvirt (libvirtd) deve estar rodando em uma máquina remota. A porta 22 deve estar aberta para acesso SSH. Você precisa usar algum tipo de gerenciamento de chave ssh (por exemplo, o ssh-agent) ou lhe será solicitado uma senha.
ext
O parâmetro ext é usado para um programa externo, o qual faz conexão com a máquina remota por fora do escopo do libvirt. Este parâmetro não é suportado.
tcp
O soquete não criptografado TCP/IP. Não é recomendado para uso de produção, ele geralmente se encontra desativado, mas um administrador pode ativá-lo para testar ou usar em redes confiáveis. A porta padrão é 16509.
O transporte padrão,caso nenhum outro seja especificado, é o TLS.
URIs remotos.
Um Uniform Resource Identifier (URI - Identificador de Recursos Uniformes) é usado pelo virsh e libvirt para conectar-se com um host remoto. Os URIs também podem ser usados com o parâmetro --connect para o comando virsh para executar comandos únicos ou migrações em hosts remotos.
libvirt URIS tomam a forma geral (conteúdo em colchetes, "[]", representam funções opcionais):
driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]
O método do transporte ou hostname deve ser providenciado para focar em local externo.
Exemplos de parâmetros de gerenciamento remoto
  • Conecte-se à um hypervisor Xen remoto no host chamado towada, usando o transporte do SSH e o username do SSH ccurran.
    xen+ssh://ccurran@towada/
    
  • Conecte-se à um hypervisor do Xen em um host chamado towada usando TLS.
    xen://towada/
    
  • Connect to a remote Xen hypervisor on host towada using TLS. The no_verify=1 tells libvirt not to verify the server's certificate.
    xen://towada/?no_verify=1
    
  • Conecte-se à um hypervisor do KVM remoto em host towada usando o SSH.
    qemu+ssh://towada/system
    
Testando exemplos
  • Conecte-se à um hypervisor KVM local com um soquete UNIX não padrão. O caminho completo para o soquete do Unix é fornecido explicitamente neste caso.
    qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
    
  • Conecte-se ao daemon libvirt com uma conexão não criptografada do TCP/IP para o servidor com o endereço de IP 10.1.1.10 na porta 5000. Isto usa o driver de teste com configurações padrão.
    test+tcp://10.1.1.10:5000/default
    
Parâmetros URI extras
Extra parameters can be appended to remote URIs. The table below Tabela 22.1, “Parâmetros URI extras” covers the recognized parameters. All other parameters are ignored. Note that parameter values must be URI-escaped (that is, a question mark (?) is appended before the parameter and special characters are converted into the URI format).
Tabela 22.1. Parâmetros URI extras
Nome Modo de transporte Descrição Uso de exemplo
nome todos os modos O nome passado para a função remota virConnectOpen. O nome é geralmente formado pela remoção do transporte, hostname, número de porta, nome do usuário e parâmetros extras de um URI remoto, mas em certos casos bem complexos pode ser melhor fornecer o nome explicitamente. name=qemu:///system
command ssh e text O comando externo. É necessário para o transporte ext. Para o ssh o padrão é ssh. O PATH é pesquisado para o comando. command=/opt/openssh/bin/ssh
socket unix e ssh O caminho para o soquete de domínio UNIX, o qual substitui o padrão.Para transporte ssh, ele é passado para o comando netcat remoto (veja netcat). socket=/opt/libvirt/run/libvirt/libvirt-sock
netcat ssh
O comando netcat pode ser usado para conectar à sistemas remotos. O parâmetro netcat padrão, usa o comando nc. Para transporte SSH, o libvirt constrói um comando SSH usando a forma abaixo:
								command -p port [-l username] hostname
								netcat -U socket
Os parâmetrosport, username ehostname podem ser especificados como parte do URI remoto. O command, netcat e socket vêm de outros parâmetros extras.parameters.
netcat=/opt/netcat/bin/nc
no_verify tls If set to a non-zero value, this disables client checks of the server's certificate. Note that to disable server checks of the client's certificate or IP address you must change the libvirtd configuration. no_verify=1
no_tty ssh Se não for definido para valor não zero, ele bloqueia o ssh de pedir por uma senha caso ele não se registre em uma máquina remota automaticamente (por usar ssh-agent ou semelhante). Use este quando não possuir acesso à um terminal, por exemplo em programas gráficos que usem libvirt. no_tty=1

Parte V. Virtualization Storage Topics

Introduction to storage administration for virtualization

This part covers using shared, networked storage with virtualization on Red Hat Enterprise Linux.
The following methods are supported for virtualization:
  • Fibre Channel
  • iSCSI
  • NFS
  • GFS2
Networked storage is essential for live and offline guest migrations. You cannot migrate guests without shared storage.

Capítulo 23. Using shared storage with virtual disk images

This chapter covers the use of shared and network storage devices for virtual disks.

23.1. Using iSCSI for storing virtual disk images

This section demonstrates how to set up an iSCSI target on Red Hat Enterprise Linux and how to configure iSCSI on a libvirt KVM host using virsh, and finally how to provision a guest on iSCSI using virt-install.

Importante

Setting up a Red Hat Enterprise Linux server as an iSCSI target is not recommended. The example used in this section should not be used in production, and is provided as an example which should only be referred to for basic shared storage testing and educational purposes.

23.1.1. How to set up an iSCSI target on Red Hat Enterprise Linux

  1. Install and enable the iSCSI target service

    Install and enable the iSCSI target service with the following commands:
    # yum install scsi-target-utils
    # chkconfig tgtd on
    # service tgtd start
    

    Importante

    The scsi-target-utils package required for this example is provided only in the Cluster Storage add-on for Red Hat Enterprise Linux 5, and may not be available for your system. Contact your support agent to activate this add-on if you are currently unable to install this package.
  2. Allocate storage for the LUNs

    The iSCSI target service is not dependent on a particular type of exported LUN. The LUNs can be plain files, LVM volumes, or block devices. There is however a performance overhead if using the LVM and/or file system layers as compared to block devices. The guest providing the iSCSI service in this example has no spare block or LVM devices, so raw files will be used.
    This example demonstrates the creation of two LUNs; one is a 10GB thin-provisioned (sparse file) LUN, and the other has 500MB, of which are fully-allocated. The following commands will achieve this configuration. Be aware that your environment will be different and this is provided only as an example:
    # mkdir -p /var/lib/tgtd/kvmguest
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/rhelx86_64.img bs=1M seek=10240 count=0
    # dd if=/dev/zero of=/var/lib/tgtd/kvmguest/shareddata.img bs=1M count=512
    # restorecon -R /var/lib/tgtd
    
  3. Export the iSCSI target and LUNs

    For Red Hat Enterprise Linux 5, a series of tgtadm commands is required to create a target and associate the storage volumes created earlier. First, the following command adds a target using an iSCSI Qualified Name (IQN):
    # tgtadm --lld iscsi --op new --mode target --tid 1 --targetname \ 
    iqn.2004-04.rhel:rhel5:iscsi.kvmguest
    
    Now the storage volumes must be associated with LUNs in the iSCSI target with these two commands:
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 \
    --backing-store /var/lib/tgtd/kvmguest/rhelx86_64.img
    
    # tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 2 \
    --backing-store /var/lib/tgtd/kvmguest/shareddata.img
    

    Importante

    Add the previous 3 tgtadm commands to the end of the /etc/rc.local file to ensure normal operation upon restarting of the system.
    To confirm the successful operation of the previous commands, query the iSCSI target setup:
    tgtadm --lld iscsi --op show --mode target
    Target 1: iqn.2004-04.rhel:rhel5:iscsi.kvmguest
        System information:
            Driver: iscsi
            State: ready
        I_T nexus information:
        LUN information:
            LUN: 0
                Type: controller
                SCSI ID: IET     00010000
                SCSI SN: beaf10
                Size: 0 MB, Block size: 1
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: null
                Backing store path: None
                Backing store flags: 
            LUN: 1
                Type: disk
                SCSI ID: IET     00010001
                SCSI SN: beaf11
                Size: 10737 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/rhelx86_64.img
                Backing store flags: 
            LUN: 2
                Type: disk
                SCSI ID: IET     00010002
                SCSI SN: beaf12
                Size: 537 MB, Block size: 512
                Online: Yes
                Removable media: No
                Readonly: No
                Backing store type: rdwr
                Backing store path: /var/lib/tgtd/kvmguest/shareddata.img
                Backing store flags: 
        Account information:
        ACL information:
    
  4. Allow client access to the target

    Finally, this example command allows access to all clients without any authentication:
    # tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address ALL
    

Two common mistakes

The two most common problems encountered when configuring the iSCSI target are SELinux and iptables. If adding plain files as LUNs in an iSCSI target, ensure the files are labelled system_u:object_r:tgtd_var_lib_t:s0. TCP port 3260 must also be open in your iptables configuration.

23.1.2. How to configure iSCSI on a libvirt KVM host and provision a guest using virt-install

The previous section described how to set up an iSCSI target. This section demonstrates how to configure iSCSI on a libvirt KVM instance using virsh, and then how to provision a guest using virt-install.
  1. Defining the storage pool

    All libvirt storage is managed through storage pools, of which there are many possible types: SCSI, NFS, ext4, plain directory and iSCSI. All libvirt objects are configured via XML description files, and storage pools are no different in this regard. For an iSCSI storage pool there are three important pieces of information to provide:
    • The target path - this determines how libvirt will expose device paths for the pool. Paths like /dev/sda and /dev/sdb are not an ideal choice as they can change between reboots, and can change across machines within a cluster; in other words, the names are assigned on a first come, first served basis by the kernel. It is strongly recommended to use the /dev/disk/by-path format. This results in a consistent naming scheme across all machines.
    • The host name - this is simply the fully-qualified DNS name of the iSCSI server.
    • The source path - this is the iSCSI qualified name (IQN) seen in the previous setup procedure (iqn.2004-04.rhel:rhel5:iscsi.kvmguest).
    Although your environment will likely be different, the following text is what an iSCSI configuration will look like:
    <pool type='iscsi'>
        <name>kvmguest</name>
        <source>
            <host name='myiscsi.example.com'/>
            <device path='iqn.2004-04.rhel:rhel5:iscsi.kvmguest'/>
        </source>
        <target>
            <path>/dev/disk/by-path</path>
        </target>
    </pool>
    
    Save this XML code to a file named iscsirhel5.xml and load it into libvirt using the pool-define command:
    # virsh pool-define iscsirhel5.xml
    Pool kvmguest defined from iscsirhel5.xml
    
    # virsh pool-list --all
    Name                 State      Autostart
    -----------------------------------------
    default              active     yes
    kvmguest             inactive   no
    
  2. Starting the storage pool

    The configuration is saved, but the iSCSI target has not yet been logged into, so no LUNs will be visible on the host at this point. Use the pool-start command the make the LUNs visible with the vol-list command.
    # virsh pool-start kvmguest
    Pool kvmguest started
    
    # virsh vol-list kvmguest
    Name                 Path
    -----------------------------------------
    10.0.0.1             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    10.0.0.2             /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2
    
  3. Querying LUN information

    Further information about each LUN can be obtained using the vol-info and vol-dumpxml commands:
    # virsh vol-info /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    
    Name:           10.0.0.1
    Type:           block
    Capacity:       10.00 GB
    Allocation:     10.00 GB
    
    
    # virsh vol-dumpxml /dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1
    <volume>
      <name>10.0.0.1</name>
      <key>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1</key>
      <source>
      </source>
      <capacity>10737418240</capacity>
      <allocation>10737418240</allocation>
      <target>
        <path>/dev/disk/by-path/ip-192.168.122.2:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2</path>
        <format type='unknown'/>
        <permissions>
          <mode>0660</mode>
          <owner>0</owner>
          <group>6</group>
          <label>system_u:object_r:fixed_disk_device_t:s0</label>
        </permissions>
      </target>
    </volume>
    
  4. Activating the storage at boot time

    If everything is configured properly, the pool can be set to start automatically upon booting of the host:
    # virsh pool-autostart kvmguest
    Pool kvmguest marked as autostarted
    
  5. Provisioning a guest on iSCSI

    The virt-install command can be used to install new guests from the command line. The --disk argument can take the name of a storage pool, followed by the name of any contained volumes. Continuing this example, the following command will begin the installation of a guest with two disks; the first disk is the root file system, the second disk can be shared between multiple guests for common data:
    # virt-install --accelerate --name rhelx86_64 --ram 800 --vnc --disk \ vol=kvmguest/10.0.0.1 --disk vol=kvmguest/10.0.0.2,perms=sh --pxe
    
    Once this rhelx86_64 guest is installed, the following command and output shows the XML that virt-install used to associate the guest with the iSCSI LUNs:
    # virsh dumpxml rhelx86_64
    
    <domain type='kvm' id='4'>
      <name>rhelx86_64</name>
      <uuid>ad8961e9-156f-746f-5a4e-f220bfafd08d</uuid>
      <memory>819200</memory>
      <currentMemory>819200</currentMemory>
      <vcpu>1</vcpu>
      <os>
        <type arch='x86_64' machine='rhel'>hvm</type>
        <boot dev='network'/>
      </os>
      <features>
        <acpi/>
        <apic/>
        <pae/>
      </features>
      <clock offset='utc'/>
      <on_poweroff>destroy</on_poweroff>
      <on_reboot>destroy</on_reboot>
      <on_crash>destroy</on_crash>
      <devices>
        <emulator>/usr/libexec/qemu-kvm</emulator>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-1'/>
          <target dev='hda' bus='ide'/>
          <alias name='ide0-0-0'/>
          <address type='drive' controller='0' bus='0' unit='0'/>
        </disk>
        <disk type='block' device='disk'>
          <driver name='qemu' type='raw'/>
          <source dev='/dev/disk/by-path/ip-192.168.122.170:3260-iscsi-iqn.2004-04.rhel:rhel5:iscsi.kvmguest-lun-2'/>
          <target dev='hdb' bus='ide'/>
          <shareable/>
          <alias name='ide0-0-1'/>
          <address type='drive' controller='0' bus='0' unit='1'/>
        </disk>
        <controller type='ide' index='0'>
          <alias name='ide0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
        </controller>
        <interface type='network'>
          <mac address='52:54:00:0a:ca:84'/>
          <source network='default'/>
          <target dev='vnet1'/>
          <alias name='net0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
        </interface>
        <serial type='pty'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </serial>
        <console type='pty' tty='/dev/pts/28'>
          <source path='/dev/pts/28'/>
          <target port='0'/>
          <alias name='serial0'/>
        </console>
        <input type='mouse' bus='ps2'/>
        <graphics type='vnc' port='5901' autoport='yes' keymap='en-us'/>
        <video>
          <model type='cirrus' vram='9216' heads='1'/>
          <alias name='video0'/>
          <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
        </video>
      </devices>
    </domain>
    
    There are two important items of note in this output:
    • The guest uses the large /dev/disk/by-path paths to refer to the LUNs. As described earlier, this is so that file names and paths will remain constant.
    • The second disk has the <shareable/> flag set. Critical for the disk to be safely shared between guests, this ensures that the SELinux labelling will be appropriate for multiple guests to access the disk and that all I/O caching is disabled on the host.
For migration of guests between hosts to succeed, some form of shared storage is required. Although NFS is often used for this purpose, the lack of SELinux labelling for NFS means there is limited sVirt protection between guests. This lack of sVirt support could allow one guest to use another guest's disks, which is usually undesirable.
Using iSCSI provides full sVirt isolation between guests to the same degree of non-shared storage.

Parte VI. Guia de Referência da Tecnologia de Virtualização

Capítulo 24. Ferramentas da Tecnologia de Virtualização

Segue uma lista de ferramentas para a administração de virtualização, ferramentas de depuração e rede de trabalho que são úteis para sistemas rodando o Xen.
Ferramentas de Administração de Sistema
  • vmstat
  • iostat
  • lsof
    # lsof -i :5900
    xen-vncfb 10635  root  5u  IPv4 218738  TCP grumble.boston.redhat.com:5900 (LISTEN)
    
  • qemu-img
Ferramentas de Depuração Avançada
  • systemTap
  • crash
  • xen-gdbserver
  • sysrq
  • sysrq t
  • sysrq w
  • sysrq c
Networking
brtcl
  • # brctl show
    bridge name  bridge id            STP enabled    interfaces
    xenbr0       8000.feffffffffff    no             vif13.0
    						 pdummy0
                                                     vif0.0
    
  • # brctl showmacs xenbr0
    port no  mac addr                is local?       aging timer
      1      fe:ff:ff:ff:ff:ff       yes             0.00
    
  • # brctl showstp xenbr0
    xenbr0
    bridge id              8000.feffffffffff
    designated root        8000.feffffffffff
    root port              0                    path cost                 0
    max age                20.00                bridge max age            20.00
    hello time             2.00                 bridge hello time         2.00
    forward delay          0.00                 bridge forward delay      0.00
    aging time            300.01
    hello timer            1.43                 tcn timer                 0.00
    topology change timer  0.00                 gc timer                  0.02
    flags
    
    vif13.0 (3)
    port id                8003                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8003                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
    pdummy0 (2)
    port id                8002                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8002                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
    vif0.0 (1)
    port id                8001                 state                    forwarding
    designated root        8000.feffffffffff    path cost                100
    designated bridge      8000.feffffffffff    message age timer        0.00
    designated port        8001                 forward delay timer      0.00
    designated cost        0                    hold timer               0.43
    flags
    
  • ifconfig
  • tcpdump
ferramentas KVM
  • ps
  • pstree
  • top
  • kvmtrace
  • kvm_stat
Xen tools
  • xentop
  • xm dmesg
  • xm log

Capítulo 25. Gerenciando convidados com virsh

virsh é uma ferramenta de interface de linha de comando para gerenciar arquivos e o hypervisor.
A ferramenta virsh é construída na API de gerenciamento do libvirt e opera como uma alternativa para o comando xm e o Gerenciador de convidado gráfico (virt-manager). virsh pode ser usado em modo de somente-leitura por usuários sem previlégios. Você pode usar o virsh para executar scripts para as máquinas convidadas.
Referência de comando rápido virsh
As seguintes tabelas fornecem uma referência rápida para todas as opções de linha de comando do virsh.
Tabela 25.1. Comandos de gerenciamento de convidado.
Command Descrição
help Imprime Informações de ajuda básica
list Lista todos os convidados
dumpxml Apresenta o arquivo de configuração do XML para o convidado.
create Cria um convidado a partir do arquivo de configuração do XML e inicia um novo convidado.
start Inicia um convidado inativo.
destroy Força um convidado a parar.
define Apresenta como resultado um arquivo de configuração do XML para um convidado.
domid Displays the guest's ID.
domuuid Displays the guest's UUID.
dominfo Exibe Informações sobre Convidados.
domname Displays the guest's name.
domstate Exibe o Estado de um convidado
quit Interrompe o terminal interativo.
reboot Reinicializa um convidado
restore Restaura um convidado salvo anteriormente, armazenado em um arquivo.
resume Resume um convidado pausado.
save Salva o estado presente de um convidado para um arquivo.
shutdown Fecha com delicadeza um convidado.
suspend Pausa um convidado
undefine Remove todos os arquivos associados à um convidado.
migrate Migra um convidado para host de outros.

A opção de comando a seguir virsh gerencia convidados e os recursos de hypervisor:
Tabela 25.2. Recurso de opções de gerenciamento.
Command Descrição
setmem Define a memória alocada para um convidado.
setmaxmem Define limite de memória máxima par ao hypervisor.
setvcpus Muda o número de CPUs virtuais atribuídas ao convidado.
vcpuinfo Exibe informações de CPU Virtual sobre um convidado
vcpupin Controla a afinidade da CPU virtual de um convidado.
domblkstat Exibe estatísticas de dispositivos de bloco para um convidado em execução.
domifstat Exibe estatísticas de interface de rede para um convidado em execução.
attach-device Anexe um dispositivo à um convidado, usando uma definição de dispositivo em um arquivo do XML.
attach-disk Anexa um novo dispositivo de disco novo à um convidado.
attach-interface Anexa uma interface de rede nova à um convidado.
detach-device Desanexar um dispositivo de um convidado, leva o mesma tipo de descrições do XML que o comando attach-device.
detach-disk Desanexe um dispositivo de disco de um convidado.
detach-interface Desanexe uma interface de rede de um convidado.

Existem diversas opções do virsh:
Tabela 25.3. Opções Diversas
Command Descrição
version Exibe a versão do virsh
nodeinfo Apresenta informações como resultado sobre o hypervisor

Conectando-se ao Hypervisor
Conecte à sessão do hypervisor com o virsh:
# virsh connect {hostname OR URL}
Onde <name> é o nome da máquina do hypervisor. Se você quiser iniciar uma conexão de somente-leitura, acrescente o comando acima com o readonly.
Criando uma máquina virtual de despejo do XML (arquivos de configuração)
Output a guest's XML configuration file with virsh:
# virsh dumpxml {domain-id, domain-name or domain-uuid}
This command outputs the guest's XML configuration file to standard out (stdout). You can save the data by piping the output to a file. An example of piping the output to a file called guest.xml:
# virsh dumpxml GuestID > guest.xml
This file guest.xml can recreate the guest (refer to Editing a guest's configuration file. You can edit this XML configuration file to configure additional devices or to deploy additional guests. Refer to Seção 33.1, “Usando os arquivos de configuração do XML com o virsh” for more information on modifying files created with virsh dumpxml.
Um exemplo de resultado do virsh dumpxml:
# virsh dumpxml r5b2-mySQL01
<domain type='xen' id='13'>
    <name>r5b2-mySQL01</name>
    <uuid>4a4c59a7ee3fc78196e4288f2862f011</uuid>
    <bootloader>/usr/bin/pygrub</bootloader>
    <os>
        <type>linux</type>
        <kernel>/var/lib/libvirt/vmlinuz.2dgnU_</kernel>
	<initrd>/var/lib/libvirt/initrd.UQafMw</initrd>
        <cmdline>ro root=/dev/VolGroup00/LogVol00 rhgb quiet</cmdline>
    </os>
    <memory>512000</memory>
    <vcpu>1</vcpu>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>restart</on_crash>
    <devices>
        <interface type='bridge'>
            <source bridge='xenbr0'/>
            <mac address='00:16:3e:49:1d:11'/>
            <script path='vif-bridge'/>
        </interface>
        <graphics type='vnc' port='5900'/>
        <console tty='/dev/pts/4'/>
    </devices>
</domain>
Criando um convidado de um arquivo de configuração
Guests can be created from XML configuration files. You can copy existing XML from previously created guests or use the dumpxml option (refer to Criando uma máquina virtual de despejo do XML (arquivos de configuração)). To create a guest with virsh from an XML file:
# virsh create configuration_file.xml
Editing a guest's configuration file
Instead of using the dumpxml option (refer to Criando uma máquina virtual de despejo do XML (arquivos de configuração)) guests can be edited either while they run or while they are offline. The virsh edit command provides this functionality. For example, to edit the guest named softwaretesting:
# virsh edit softwaretesting
Isto abre um editor de texto. O editor de texto padrão é o parâmetro da shell $EDITOR (definido para vi por padrão).
Suspendendo um convidado
Suspende um convidado com o virsh:
# virsh suspend {domain-id, domain-name or domain-uuid}
When a guest is in a suspended state, it consumes system RAM but not processor resources. Disk and network I/O does not occur while the guest is suspended. This operation is immediate and the guest can be restarted with the resume (Resumindo um convidado) option.
Resumindo um convidado
Recupere um convidado suspenso com virsh usando a opçãoresume:
# virsh resume {domain-id, domain-name or domain-uuid}
Esta operação é imediata e os parâmetros do convidado são preservados para operações suspend e resume .
Salve um convidado
Salve um estado atual de um convidado em um arquivo usando o comando virsh:
# virsh save {domain-name, domain-id or domain-uuid} filename
This stops the guest you specify and saves the data to a file, which may take some time given the amount of memory in use by your guest. You can restore the state of the guest with the restore (Recupere um convidado) option. Save is similar to pause, instead of just pausing a guest the present state of the guest is saved.
Recupere um convidado
Restore a guest previously saved with the virsh save command (Salve um convidado) using virsh:
# virsh restore filename
This restarts the saved guest, which may take some time. The guest's name and UUID are preserved but are allocated for a new id.
Feche o convidado
Feche um convidado utilizando o comando virsh:
# virsh shutdown {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_shutdown parameter in the guest's configuration file.
Reinicializando um convidado
Reinicialize um convidado utilizando o comando virsh:
#virsh reboot {domain-id, domain-name or domain-uuid}
You can control the behavior of the rebooting guest by modifying the on_reboot element in the guest's configuration file.
Forçando um convidado a parar
Force um convidado a parar com o comando virsh:
# virsh destroy {domain-id, domain-name or domain-uuid}
This command does an immediate ungraceful shutdown and stops the specified guest. Using virsh destroy can corrupt guest file systems . Use the destroy option only when the guest is unresponsive. For para-virtualized guests, use the shutdown option(Feche o convidado) instead.
Obtendo o ID de Domínio de um convidado
Para obter um ID de domínio de um convidado:
# virsh domid {domain-name or domain-uuid}
Obtendo o ID de Domínio de um convidado
Para obter um ID de domínio de um convidado:
# virsh domname {domain-id or domain-uuid}
Obtendo o UUID de um convidado
Para obter o Identificador Único Universal (UUID) para um convidado:
# virsh domuuid {domain-id or domain-name}
Um exemplo de resultado do virsh domuuid:
# virsh domuuid r5b2-mySQL01
4a4c59a7-ee3f-c781-96e4-288f2862f011
Exibindo Informações sobre convidado
Using virsh with the guest's domain ID, domain name or UUID you can display information on the specified guest:
# virsh dominfo {domain-id, domain-name or domain-uuid}
Este é um exemplo de resultado do virsh dominfo:
# virsh dominfo r5b2-mySQL01
id:             13
name:           r5b2-mysql01
uuid:           4a4c59a7-ee3f-c781-96e4-288f2862f011
os type:      	linux
state:          blocked
cpu(s):         1
cpu time:     	11.0s
max memory:     512000 kb
used memory:    512000 kb
Exibindo Informações sobre host
Para exibir informações sobre o host:
# virsh nodeinfo
Um exemplo de um resultado de virsh nodeinfo:
# virsh nodeinfo
CPU model                    x86_64
CPU (s)                      8
CPU frequency                2895 Mhz
CPU socket(s)                2      
Core(s) per socket           2
Threads per core:            2
Numa cell(s)                 1
Memory size:                 1046528 kb
Isto exibe informações de nó e máquinas que suportam o processo de virtualização.
Exibindo os convidados
Para exibir a lista de convidados e seus estados atuais com virsh:
# virsh list
Outras opções disponíveis incluem:
A opção --inactive para listar os convidados inativos (ou seja, os convidados que já foram definidos mas ainda não se encontram ativos), e
a opção --all lista todos os convidados. Por exemplo:
# virsh list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  1 Domain202            paused
  2 Domain010            inactive
  3 Domain9600           crashed
O resultado de virsh list é categorizado como um dos seis estados (listados abaixo).
  • O estado running se refere aos convidados que estão ativos atualmente em uma CPU.
  • Os convidados listados como blocked são bloqueados, e não são executados ou executáveis. Isto é causado por um convidado em espera na E/S (um estado de espera tradicional) ou convidados em um modo sleep.
  • O estado paused lista domínios que são pausados. Isto ocorre se um administrador usa o pause em virt-manager, xm pause ou virsh suspend. Quando um convidado é pausado ele consome memória e outros recursos mas não é elegível para agendamento e recursos de CPU a partir do hypervisor.
  • O estado shutdown é para convidados no processo de fechamento. O convidado recebe um sinal de fechamento e deve estar no processo de parar suas operações suavemente. Isto pode não funcionar com todos os convidados de sistemas operacionais, alguns sistemas operacionais não respondem à estes sinais.
  • Domínios no estado dying estão no processo de apagar, o qual é um estado onde o domínio não fechou completamente ou travou.
  • Os convidados crashed falharam enquanto são executados e não estão mais em execução. Este estado pode ocorrer somente se o convidado foi configurado para reiniciar no travamento.
Exibindo Informações de CPU Virtual
Para exibir informações de CPU virtual de um convidado com o virsh:
# virsh vcpuinfo {domain-id, domain-name or domain-uuid}
Um exemplo de resultado do virsh vcpuinfo:
# virsh vcpuinfo r5b2-mySQL01
VCPU:           0
CPU:            0
State:          blocked
CPU time:       0.0s
CPU Affinity:   yy
Configurando Afinidade da CPU Virtual
Para configurar a afinidade de CPUs virtuais com CPUs físicas:
# virsh vcpupin domain-id vcpu cpulist
The domain-id parameter is the guest's ID number or name.
O parâmetro vcpu denota o número das CPUs virtualizadas alocadas ao convidado. O parâmetro vcpu deve ser fornecido.
O parâmetro cpulist é uma lista de números identificadores de CPU física, separada por vírgulas. O parâmetro cpulist determina em qual CPU física os VCPUs irão rodar.
Configurando Conta de CPU Virtual
Para modificar o número de CPUs atribuídas ao convidado com virsh:
# virsh setvcpus {domain-name, domain-id or domain-uuid} count
O novo valor de count não pode exceder a conta acima da quantia especificado quando o convidado foi criado.
Configurando uma Alocação de Memória
To modify a guest's memory allocation with virsh :
# virsh setmem {domain-id or domain-name} count
Você deve especificar a count em kilobytes. Note que a nova conta não pode exceder a quantia que você especificou ao criar o convidado. Os valores menores que 64MB provavelmente não funcionarão com a maioria dos sistemas operacionais convidados. A memória máxima não afeta um convidado ativo. Se o novo valor for menor menor, a memória disponível irá diminuir e o convidado pode travar.
Exibindo Informações sobre dispositivo de bloco convidado.
Use virsh domblkstat para exibir estatíscas de dispositivo de bloco para um convidado em execução.
# virsh domblkstat GuestName block-device
Exibindo Informações sobre Dispositivo de rede convidado
Use o virsh domifstat para exibir as estatísticas de interface de rede para um convidado em execução.
# virsh domifstat GuestName interface-device 
Migrando convidados com o virsh
Um convidado pode migrar para um outro host com o virsh. Migre o domínio para outro host. Adicione --live para migrações ativas. O comando migrate aceita parâmetros no seguinte formato:
# virsh migrate --live GuestName DestinationURL
O parâmetro --live é opcional. Adicione o parâmetro --live para migrações ativas.
O parâmetro GuestName representa o nome do convidado para onde você deseja migrar.
O parâmetro DestinationURL é a URL ou o hostname do sistema de destino. O sistema de destino requer:
  • a mesma versão do Red Hat Enterprise Linux,
  • o mesmo hypervisor (KVM ou Xen), e
  • o serviço libvirt deve ser iniciado.
Depois que o comando é inserido, coloque sua senha do root do sistema de destino.
Gerenciando Redes Virtuais
Esta seção trata sobre gerenciamento de redes virtuais com o comando virsh. Para listar redes virtuais:
# virsh net-list
Este comando gera um resultado semelhante a este:
# virsh net-list
Name                 State      Autostart
-----------------------------------------
default              active     yes      
vnet1	             active     yes      
vnet2	             active     yes
Para visualizar informações de rede para uma rede virtual específica:
# virsh net-dumpxml NetworkName
Isto exibe informações sobre uma rede virtual específica no formato XML:
# virsh net-dumpxml vnet1
<network>
  <name>vnet1</name>
  <uuid>98361b46-1581-acb7-1643-85a412626e70</uuid>
  <forward dev='eth0'/>
  <bridge name='vnet0' stp='on' forwardDelay='0' />
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.128' end='192.168.100.254' />
    </dhcp>
  </ip>
</network>
Outros comandos virsh usados no gerenciamento de redes virtuais são:
  • virsh net-autostart network name — Auto-inicia uma rede especificada como network name.
  • virsh net-create XML file — Gera e inicia uma nova rede usando um arquivo XML pré-existente
  • virsh net-define XML file — Gera uma nova rede de um arquivo XML pré-existente sem iniciar
  • virsh net-destroy network name — Destroi uma rede especificada como network name.
  • virsh net-name network UUID — Converte um network UUID especificado em um nome de rede
  • virsh net-uuid network name — Converte um network name, ou seja nome de rede, em um UUID de rede
  • virsh net-start name of an inactive network — Inicia uma rede inativa, não definida anteriormente
  • virsh net-undefine name of an inactive network — remove a definição de uma rede inativa.

Capítulo 26. Gerenciando convidados com o Gestor de Máquina Virtual (virt-manager)

Esta seção descreve o Gestor de Máquina Virtual (virt-manager) as janelas, caixas de diálogo e diversos controles GUI.
O virt-manager fornece uma visualização gráfica de hypervisors e convidado em seu sistema e em máquinas remotas. Você pode usar o virt-manager para definir ambos convidados para-virtualizados e totalmente virtualizados. O virt-manager pode realizar as tarefas de gerenciamento de virtualização, incluindo:
  • atribuição de memória,
  • atribuição de CPUs virtuais,
  • monitoramento de desempenho operacional,
  • salvar e restaurar, pausar e resumir, e fechar e iniciar convidados virtualizados,
  • links para os consoles textual e gráfico, e
  • em tempo real e migrações offline.

26.1. The Add Connection window

Esta janela aparece primeiro e solicita que o usuário escolha uma sessão de hypervisor. Usuários não privilegiados podem iniciar uma sessão de somente leitura. Os usuários root podem iniciar uma sessão com status de somente leitura ampliada. Para uso normal, selecione a opção Local Xen host ou o QEMU (para KVM).
Janela de Conexão do Gestor de Máquina Virtual
Figura 26.1. Janela de Conexão do Gestor de Máquina Virtual

26.2. A janela principal do Gestor de Máquina Virtual

This main window displays all the running guests and resources used by guests. Select a virtualized guest by double clicking the guest's name.
Janela principal do Gestor de Máquina Virtual
Figura 26.2. Janela principal do Gestor de Máquina Virtual

26.3. The guest Overview tab

The Overview tab displays graphs and statistics of a guest's live resource utilization data available from virt-manager. The UUID field displays the globally unique identifier for the virtual machines.
The Overview tab
Figura 26.3. The Overview tab

26.4. Console Gráfico de Máquina Virtual

This window displays a virtual machine's graphical console. Para-virtualized and fully virtualized guests use different techniques to export their local virtual framebuffers, but both technologies use VNC to make them available to the Virtual Machine Manager's console window. If your virtual machine is set to require authentication, the Virtual Machine Graphical console prompts you for a password before the display appears.
Janela de Console Gráfico
Figura 26.4. Janela de Console Gráfico

Uma nota sobre segurança e VNC

VNC is considered insecure by many security experts, however, several changes have been made to enable the secure usage of VNC for virtualization on Red Hat enterprise Linux. The guest machines only listen to the local host (dom0)'s loopback address (127.0.0.1). This ensures only those with shell privileges on the host can access virt-manager and the virtual machine through VNC.
Remote administration can be performed following the instructions in Capítulo 22, Gerenciamento remoto de convidados virtualizados. TLS can provide enterprise level security for managing guest and host systems.
Your local desktop can intercept key combinations (for example, Ctrl+Alt+F11) to prevent them from being sent to the guest machine. You can use the virt-manager sticky key capability to send these sequences. To use this capability, you must press any modifier key (Ctrl or Alt) 3 times and the key you specify gets treated as active until the next non-modifier key is pressed. You can then send Ctrl-Alt-F11 to the guest by entering the key sequence 'Ctrl Ctrl Ctrl Alt+F1'.

Nota

Due to a limitation of virt-manager, it is not possible to use this sticky key feature to send a Sysrq key combination to a guest.

26.5. Iniciando o virt-manager

Para iniciar uma sessão do virt-manager, a partir do menu Aplicativos, clique em Ferramentas de Sistema e selecione (virt-manager).
Aparecerá uma janela principal do virt-manager
Iniciando virt-manager
Figura 26.5. Iniciando virt-manager

Alternatively, virt-manager can be started remotely using ssh as demonstrated in the following command:
ssh -X host's address[remotehost]# virt-manager
Using ssh to manage virtual machines and hosts is discussed further in Seção 22.1, “Gerenciamento remoto com o SSH”.

26.6. Restaurando uma máquina salva

Depois que você iniciar o Gestor de Máquina Virtual, todas as máquinas virtuais em seu sistema são exibidas na janela principal. O Domínio0 é sistema hospedeiro. Se não houver nenhuma máquina, significa que atualmente não há máquinas rodando no sistema.
Para restaurar uma sessão anteriormente salva:
  1. A partir do menu Arquivo, selecione Restaure uma máquina salva.
    Restaurando uma máquina virtual
    Figura 26.6. Restaurando uma máquina virtual

  2. A janela principal de Restaurar uma Máquina Virtual aparecerá.
  3. Navegar para corrigir o diretório e selecionar o arquivo de sessão salva
  4. Clique em Open.
O sistema virtual salvo aparece na janela principal do Getor de Máquina Virtual
Uma sessão de gestor de máquina virtual restaurada.
Figura 26.7. Uma sessão de gestor de máquina virtual restaurada.

26.7. Exibindo detalhes de convidado

Você pode usar o Monitor de Máquina Virtual para visualizar informações de dados de atividade para quaisquer máquinas virtuais em seu sistema.
To view a virtual system's details:
  1. Na janela principal do Getor de Máquina Virtual, destaque a máquina virtual que você quer visualizar.
    Selecionando uma máquina virtual para exibir
    Figura 26.8. Selecionando uma máquina virtual para exibir

  2. From the Virtual Machine Manager Edit menu, select Machine Details (or click the Details button on the bottom of the Virtual Machine Manager main window).
    Displaying the overview window
    Figura 26.9. Displaying the overview window

    On the Virtual Machine window, click the Overview tab.
    The Overview tab summarizes CPU and memory usage for the virtualized guest you specified.
    Exibindo Visão Geral de Detalhes de Máquina Virtual
    Figura 26.10. Exibindo Visão Geral de Detalhes de Máquina Virtual

  3. On the Virtual Machine window, click the Hardwaretab.
    Exibindo detalhes de hardware de convidado
    Figura 26.11. Exibindo detalhes de hardware de convidado

  4. Na aba Hardware, clique em Processador para visualizar ou mudar a alocação do processador atual.
    Exibindo a Alocação do Processador
    Figura 26.12. Exibindo a Alocação do Processador

  5. Na aba Hardware, clique em Memória para visualizar ou mudar a alocação da memória RAM atual.
    Exibindo a Alocação de Memória
    Figura 26.13. Exibindo a Alocação de Memória

  6. Na aba Hardware, clique em Disco para visualizar ou mudar a configuração do disco rígido atual.
    Exibindo a Configuração do Disco
    Figura 26.14. Exibindo a Configuração do Disco

  7. On the Hardware tab, click on NIC to view or change the current network configuration.
    Exibindo a Configuração de Rede
    Figura 26.15. Exibindo a Configuração de Rede

26.8. Monitoramento de Status

Status status monitoring preferences can be modified with virt-manager's preferences window.
To configure status monitoring:
  1. Selecione Preferências a partir do menu Editar
    Modificando as Preferências de convidado
    Figura 26.16. Modificando as Preferências de convidado

    The Preferences window appears.
  2. From the Stats tab specify the time in seconds or stats polling options.
    Configurando o Monituramento do Status
    Figura 26.17. Configurando o Monituramento do Status

26.9. Exibindo Identificadores de convidado

Para visualizar os IDs do domínio para todas as máquinas virtuais em seu sistema:
  1. Selecione a caixa de seleção ID de Domínio a partir do menu Visualizar
    Visualizando IDs de convidado
    Figura 26.18. Visualizando IDs de convidado

  2. O Gestor de Máquina Virtual lista os Domain IDs para todos os domínios em seu sistema.
    Exibindo os Domain IDs
    Figura 26.19. Exibindo os Domain IDs

26.10. Displaying a guest's status

Para visualizar o status de todas as máquinas virtuais em seu sistema
  1. Selecione Status a partir do menu Visualizar
    Selecting a virtual machine's status
    Figura 26.20. Selecting a virtual machine's status

  2. O Gestor de Máquina Virtual lista o status de todas as máquinas virtuais em seu sistema.
    Displaying a virtual machine's status
    Figura 26.21. Displaying a virtual machine's status

26.11. Exibindo as CPUs Virtuais

Para visualizar a quantia de CPUs virtuais para todas as máquinas virtuais em seu sistema:
  1. A partir do menu Arquivo, selecione CPUs Virtuais.
    Selecionando a opção de CPUs virtuais
    Figura 26.22. Selecionando a opção de CPUs virtuais

  2. O Gestor de Máquina Virtual lista as CPUs Virtuais para todas as máquinas virtuais em seu sistema.
    Exibindo as CPUs Virtuais
    Figura 26.23. Exibindo as CPUs Virtuais

26.12. Exibindo o Uso da CPU

Para visualizar o uso da CPU para todas as máquinas virtuais em seus sistema:
  1. Selecione CPU Usage a partir do menu Visualizar.
    Selecionando a classe de CPU
    Figura 26.24. Selecionando a classe de CPU

  2. O Gestor de Máquina Virtual lista a porcentagem de CPU em uso para todas as máquinas virtuais em seu sistema.
    Exibindo o Uso da CPU
    Figura 26.25. Exibindo o Uso da CPU

26.13. Exibindo o Uso de Memória

Para visualizar o uso de memória para todas as máquinas virtuais em seu sistema:
  1. A partir do menu Arquivo, selecione Uso de Memória.
    Exibindo o Uso de Memória
    Figura 26.26. Exibindo o Uso de Memória

  2. O Gestor de Máquina Virtual lista a porcentagem de memória em uso (em megabytes) para todas as máquinas de seu sistema.
    Exibindo o Uso de Memória
    Figura 26.27. Exibindo o Uso de Memória

26.14. Gerenciando uma Rede Virtual

Para configurar as redes virtuais em seu sistema:
  1. Selecione Detalhes da Máquina a partir do menu Editar
    Selecting a host's details
    Figura 26.28. Selecting a host's details

  2. Isto abrirá o menu Detalhes da Máquina. Clique na aba Redes Virtuais.
    Configuração de Rede Virtual
    Figura 26.29. Configuração de Rede Virtual

  3. Todas as redes virtuais disponíveis estão listaas na caixa à esquerda do menu. Você pode editar a configuração de uma rede virtual, selecionando-a nesta caixa e editando de acordo com suas necessidades.

26.15. Criando uma rede virtual

Para criar uma rede virtual em seu sistema:
  1. Open the Host Details menu (refer to Seção 26.14, “Gerenciando uma Rede Virtual ”) and click the Add button.
    Configuração de Rede Virtual
    Figura 26.30. Configuração de Rede Virtual

    Isto abrirá o menu Criar uma nova rede virtual. Clique em Próximo para continuar.
    Criando uma nova rede virtual
    Figura 26.31. Criando uma nova rede virtual

  2. Insira um nome apropriado para sua rede virtual e clique em Próximo.
    Nomeando sua rede virtual
    Figura 26.32. Nomeando sua rede virtual

  3. Insira um espaço de endereço IPv4 para sua rede virtual e clique em Próximo.
    Escolhendo um espaço de endereço IPv4
    Figura 26.33. Escolhendo um espaço de endereço IPv4

  4. Defina a classe de DHCP para sua rede virtual especificando uma classe Iniciar e Finalizar de endereços IP. Clique em Próximo para continuar.
    Selecionando a classe DHCP
    Figura 26.34. Selecionando a classe DHCP

  5. Selecione como a rede virtual deve se conectar em uma rede física.
    Conectando à uma rede física
    Figura 26.35. Conectando à uma rede física

    Se você selecionar Encaminhando para rede física, escolha se o Destino deve ser NAT para qualquer dispositivo físico ou NAT para um eth0 de dispositivo físico.
    Clique em Próximo para continuar.
  6. Você agora está prestes a criar uma rede. Verifique a configuração de sua rede e clique em Finalizar.
    Pronto para criar rede
    Figura 26.36. Pronto para criar rede

  7. A nova rede virtual está agora disponível na aba Rede Virtual do menu Detalhes da Máquina
    Nova rede virtual está agora disponível
    Figura 26.37. Nova rede virtual está agora disponível

Capítulo 27. A referência rápida do comando xm

O comando xm pode gerenciar o hypervisor do Xen. A maioria das operações podem ser realizadas com as ferramentas do libvirt, o aplicativo virt-manager ou o comando virsh. O comando xm não tem a capacidade de verificação de erro das ferramentas do libvirt e não deve ser usada para tarefas que as ferramentas do libvirt suportam.
Existem algumas operações que atualmente não podem ser realizadas usando o virt-manager. Algumas opções para outras implementações do Xen do comando xm não funcionam no Red Hat Enterprise Linux 5. A lista abaixo fornece uma visão geral de opções de comando disponíveis e não disponíveis.

Aviso

Recomenda-se usar o virsh ou virt-manager ao invés do xm. O comando xm não lida com a verificação de erro ou erros de arquivo de configuração muito bem e erros podem levar à instalabilidade do sistema ou erros em máquinas virtuais. Editar os arquivos de configuração Xen é perigoso e deve ser evitado. Use este capítulo sob sua responsabilidade.
Opções de gerenciamento básico
Estes são comandos básicos e geralmente usados xm:
  • xm help [--long]: visualizar opções disponíveis e texto de ajuda.
  • use o comando xm para listar os domínios ativos:
    $ xm list
    Name                                ID  Mem(MiB)   VCPUs      State      Time(s)
    Domain-0                            0     520       2         r-----     1275.5
    r5b2-mySQL01                       13     500       1         -b----       16.1
    
  • xm create [-c] DomainName/ID: start a virtual machine. If the -c option is used, the start up process will attach to the guest's console.
  • xm console DomainName/ID: attach to a virtual machine's console.
  • xm destroy DomainName/ID: finaliza uma máquina virtual, semelhante ao cancelamento de energia.
  • xm reboot DomainName/ID: reinicia uma máquina virtual, roda através do processo de fechamento normal do sistema e inicialização.
  • xm shutdown DomainName/ID: fecha uma máquina virtual, executa um procedimento de fechamento de sistema normal.
  • xm pause
  • xm unpause
  • xm save
  • xm restore
  • xm migrate
Opções de gerenciamento de recursos.
Use os seguintes comandos xm para gerenciar recursos:
  • xm mem-set
  • use o xm vcpu-list para listar afinidades de CPU virtualizada:
    $ xm vcpu-list
    Name                          ID  VCPUs   CPU State  Time(s)  CPU Affinity
    Domain-0                       0    0      0    r--   708.9    any cpu
    Domain-0                       0    1      1   -b-    572.1    any cpu
    r5b2-mySQL01                  13    0      1   -b-     16.1    any cpu
    
  • xm vcpu-pin
  • xm vcpu-set
  • use o comando xm shed-credit para exibir os parâmetros do agendados para um dado domínio:
    $ xm sched-credit -d 0
    {'cap': 0, 'weight': 256}
    $ xm sched-credit -d 13
    {'cap': 25, 'weight': 256}
    
Opções de monitoramento e troubleshooting
Use os seguintes comandos xm para monitorar e fazer o troubleshooting:
  • xm top
  • xm dmesg
  • xm info
  • xm log
  • use xm uptime para exibir o tempo limite dos convidados e hosts:
    $ xm uptime
    Name                       ID  Uptime
    Domain-0                    0  3:42:18
    r5b2-mySQL01               13  0:06:27
    
  • xm sysrq
  • xm dump-core
  • xm rename
  • xm domid
  • xm domname
Opções que não são suportadas atualmente
O xm vnet-list não é suportado atualmente.

Capítulo 28. Configurando os parâmetros de inicialização do kernel Xen

O GNU Grand Unified Boot Loader (ou GRUB) é um programa que inicializa diversos sistemas operacionais instalados ou kernels. O GRUB também permite que o usuário passe argumentos ao kernel. O arquivo de configuração GRUB (localizado no /boot/grub/grub.conf) é usado para criar uma lista de sistemas operacionais para inicializar a interface do menu do GRUB. Quando você instalar o kernel-xen RPM, um post script adiciona as entradas kernel-xen ao arquivo de configuração GRUB, o qual aprimora o kernel-xen por padrão. Edite o arquivo grub.conf para modificar o kernel padrão ou adicione outros parâmetros do kernel.
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
Se você ajustar as entradas do grub Linux para espelhar este exemplo, o carregador de inicialização carregará o hypervisor, a imagem initrd e o kernel Linux. Como a entrada do kernel se encontra à frente de outras entradas, o kernel irá primeiro carregar para a memória. O carregador de inicialização envia os argumentos da linha de comando (e os recebe) para e do hypervisor e kernel de Linux. Esta amostra de entrada mostra como você pode restringir a memória do kernel linux Domínio0 para 800MB.
title Red Hat Enterprise Linux Server (2.6.18-3.el5xen)
root (hd0,0)
	kernel  /xen.gz.-2.6.18-3.el5 dom0_mem=800M
	module  /vmlinuz-2.6..18-3.el5xen ro root=/dev/VolGroup00/LogVol00  rhgb quiet
	module  /initrd-2.6.18-3. el5xenxen.img
Você pode usar estes parâmetros GRUB para configurar o hypervisor da Virtualização:
mem
Isto limita a quantidade de memória que está disponível para o kernel do hypervisor.
com1=115200, 8n1
Isto habilita a primeira porta serial no sistema para agir como console serial (com2 é atribuído para a próxima porta, e assim se segue...).
dom0_mem
Isto limita a memória disponível para o hypervisor.
dom0_max_vcpus
Este limita a quantidade de CPUs visíveis para o domínio0 do Xen.
acpi
Este troca o hypervisor da ACPI para o hypervisor e domínio0. As opções de parâmetro da ACPI incluem:
/*   ****  Linux config options: propagated to domain0  ****/
/*   "acpi=off":      Disables both ACPI table parsing and interpreter.   */
/*   "acpi=force":    Overrides the disable blacklist.                    */
/*   "acpi=strict":   Disables out-of-spec workarounds.                   */
/*   "acpi=ht":       Limits ACPI from boot-time to enable HT.            */
/*   "acpi=noirq":    Disables ACPI interrupt routing.                    */
noacpi
Este habilita a ACPI para entrega interrompida.

Capítulo 29. Configurando ELILO

ELILO é o carregador de inicialização usado em sistemas baseados em EFI, particularmente Itanium®. Assim como o GRUB, o carregador de inicialização em sistemas x86 e x86-64, o ELILO permite que o usuário para selecionar quais kernel instalados para carregar durante a sequência de inicialização do sistema. O ELILO também permite que o usuário passe argumentos para o kernel. O arquivo de configuração do ELILO, o qual está localizado na partição de inicialização do EFI e simbolicamente ligado à /etc/elilo.conf, contém uma lista de opções globais e estâncias de imagens. Quando você instala o RPM kernel-xen um script pós instalação adiciona a estância de imagem apropriada ao elilo.conf.

ELILO

Esta seção sobre o ELILO é para sistemas que executem o kernel Xen em arquiteturas Itanium da Intel.
O arquivo de configuração do ELILO possui duas seções:
  • Opções globais que afetam o comportamento de ELILO e todas as entradas. Geralmente não há necessidade para mudar dos valores padrão.
  • Estâncias de imagens que definem uma seleção de inicialização junto à opções associadas.
Here is a sample image stanza in elilo.conf:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="-- rhgb quiet"
The image parameter indicates the following lines apply to a single boot selection. This stanza defines a hypervisor (vmm), initrd, and command line arguments (read-only, root and append) to the hypervisor and kernel. When ELILO is loaded during the boot sequence, the image is labeled linux.
ELILO traduz o read-only para a opção de linha de comando do kernel ro a qual faz com que o sistema de arquivo root serja montado como somente-leitura até que initscripts monte o drive root como read-write. ELILO copia a linha "root" para a linha de comando do kernel. Estes são mesclados com a linha "append" para construir uma linha de comando completa:
"-- root=/dev/VolGroup00/rhel5_2 ro rhgb quiet"
O símbolo -- delimita o hypervisor e argumentos do kernel. Os argumentos do hypervisor vêm primeiro, depois os delimitador do --, seguido dos argumentos do kernel. O hypervisor geralmente não possui nenhum argumento.

Nota técnica

O ELILO passa toda a linha de comando para o hipervisor. O hipervisor divide o conteúdo e passa as opções do kernel para o kernel.
Para padronizar o hipervisor, insira parâmetros antes do --. Um exemplo de parâmetro de memória de hipervisor (mem) e o parâmetro quiet para o kernel:
append="dom0_mem=2G -- quiet"
Parâmetro de hipervisor ELILO
ParâmetroDescrição
mem=O parâmetro mem define o uso máximo de RAM do hipervisor. Qualquer RAM adicional no sistema é ignorada. O parâmetro pode ser especificado com um sufixo B, K, M ou G, representando bytes, kilobytes, megabytes, e gigabytes respectivamente. Caso nenhum sufixo seja especificado a unidade padrão é kilobytes.
dom0_mem=O dom0_mem= define a quantia de RAM para alocar ao dom0. Os mesmos sufixos são respeitados como para o parâmetro de memória acima. O padrão em Red Hat Enterprise Linux 5.2 em Itanium® é 4G.
dom0_max_vcpus=dom0_max_vcpus= define o número de CPUs para alocar ao hipervisor. O padrão no Red Hat Enterprise Linux 5.2 em Itanium® é 4.
com1=<baud>,DPS,<io_base>,<irq>com1= estabelece os parâmetros para a primeira linha em série. Por exemplo, com1=9600,8n1,0x408,5. As opçõesio_base e irq podem ser omitidas para deixá-las como padrão. O parâmetro baud pode ser estabelecido como auto que indicar as configurações do carregador de inicialização devem ser preservadas. O parâmetro com1 pode ser omitido se parâmetros de série forem definidos como opções globais em ELILO ou na configuração EFI.
com2=<baud>,DPS,<io_base>,<irq>Define parâmetros para a segunda linha serial. Consulte a descrição do parâmetro com1 acima.
console=<specifier_list>O console é uma lista de preferências delimitada por vírgulas para as opções de consolte. As opções incluem vga, com1 e com2. Esta configuração deve ser omitida pois o hipervisor tenta herdar as configurações do console EFI.

Para maiores informações sobre os parâmetros ELILO.

Uma lista completa dos parâmetros ELILO estão disponívies a partir do XenSource.
Um exemplo modificado da configuração acima, mostrando a sintaxe para adicionar a parâmetros de alocação de memória e cpu para o hipervisor:
image=vmlinuz-2.6.18-92.el5xen
        vmm=xen.gz-2.6.18-92.el5
        label=linux
        initrd=initrd-2.6.18-92.el5xen.img
        read-only
        root=/dev/VolGroup00/rhel5_2
        append="dom0_mem=2G dom0_max_vcpus=2 --"
Além disso, este exemplo remove os parâmetros do kernel "rhgb quiet" para que o kernel e o resultado do initscript sejam gerados no consolte. Observe que o hífen duplo continua, assim a linha adicionada é interpretada corretamente como argumentos do hipervisor.

Capítulo 30. libvirt configuration reference

This chapter provides is a references for various parameters of libvirt XML configuration files
Tabela 30.1. libvirt configuration files
Item Description
pae
Specifies the physical address extension configuration data.
apic
Specifies the advanced programmable interrupt controller configuration data.
memory
Specifies the memory size in megabytes.
vcpus
Specifies the numbers of virtual CPUs.
console
Specifies the port numbers to export the domain consoles to.
nic
Specifies the number of virtual network interfaces.
vif
Lists the randomly-assigned MAC addresses and bridges assigned to use for the domain's network addresses.
disk
Lists the block devices to export to the domain and exports physical devices to domain with read only access.
dhcp
Enables networking using DHCP.
netmask
Specifies the configured IP netmasks.
gateway
Specifies the configured IP gateways.
acpi
Specifies the advanced configuration power interface configuration data.

Capítulo 31. Arquivos de Configuração do Xen

Red Hat Enterprise Linux uses libvirt configuration files for most tasks. Some users may need Xen configuration files which contain the following standard variables. Configuration items within these files must be enclosed in single quotes('). These configuration files reside in the /etc/xen directory.
The table below, Tabela 31.1, “Arquivos de Configuração de Xen”, is formatted output from xm create --help_config.
Tabela 31.1. Arquivos de Configuração de Xen
Parameter
Description
vncpasswd=NAME Senha para o console VNC no domínio HVM
vncviewer=no | yes Gere um vncviewer aguardando por um servidor vnc no domínio. O endereço do vncviewer é passado para o domínio na linha de comando do kernel usando o VNC_SERVER=<host>:<port>. A porta usado pelo vnc é 5500 + DISPLAY. É escolhido um valor de exibição com uma porta livre, se possível. Somente válido quando vnc=1.
vncconsole=no | yes Spawn a vncviewer process for the domain's graphical console. Only valid when vnc=1.
name=NAME Nomde do Domínio. Deve ser único.
bootloader=FILE Caminho para o carregador de inicialização.
bootargs=NAME Argumentos para passar para o carregador do inicializador.
bootentry=NAME DEPRECATED. Entry to boot via boot loader. Use bootargs.
kernel=FILE Path to kernel image.
ramdisk=FILE Path to ramdisk.
features=FEATURES Recursos para ativar no kernel do convidado.
builder=FUNCTION Função a usar para construir o domínio.
memory=MEMORY Memória do domínio no MB.
maxmem=MEMORY Memória máximo do domínio no MB.
shadow_memory=MEMORY Memória da sombra do domínio em MB.
cpu=CPU CPU que hospeda o VCPU0.
cpus=CPUS CPUs onde executar o domínio.
pae=PAE Desativar e ativar o domínio do PAE do HVM.
acpi=ACPI Desativar ou ativar o ACPI do domínio do HVM.
apic=APIC Desativar ou ativar o APIC do domínio de HVM.
vcpus=VCPUs A quantidade de CPUs virtuais no domínio.
cpu_weight=WEIGHT Set the new domain's cpu weight. WEIGHT is a float that controls the domain's share of the cpu.
restart=onreboot | sempre | nunca Obsoleto. Use o on_poweroff, on_reboot, e on_crash. Se o domínio deve ser reiniciado na saída. - onreboot: reinicie na saída com a reinicialização de código de fechamento - always: Always reinicia na saída, ignore o código de saída - never: never reinicia na saída, ignore o código de saída.
on_poweroff=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'poweroff'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_reboot=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'reboot'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
on_crash=destroy | restart | preserve | destroy Behavior when a domain exits with reason 'crash'. - destroy: the domain is cleaned up as normal; - restart: a new domain is started in place of the old one; - preserve: no clean-up is done until the domain is manually destroyed (using xm destroy, for example); - rename-restart: the old domain is not cleaned up, but is renamed and a new domain started in its place.
blkif=no | yes Faça com que o domínio bloqueie a parte de trás do dispositivo.
netif=no | yes Transformar o domínio em um back-end da interface de rede.
tpmif=no | yes Tranformar o domínio em um back-end de interface de TPM.
disk=phy:DEV,VDEV,MODE[,DOM] Adicionar um dispositivo à um domínio. O dispositivo físico é DEV, o qual é exportado para o domínio como um VDEV. O disco é somente-leitura se o MODE for r, Leitura-gravação se MODE forw. Se DOM é especificado, ele define o back-end do domain do driver para uso do disco. A opção pode ser repetida para adicionar mais do que um disco.
pci=BUS:DEV.FUNC Adicionar um dispositivo de PCI para um domínio, usando os parâmetros apresentados (em hex). Por exemplo pci=c0:02.1a. A opção pode ser repetida para adicionar mais do que um dispositivo pci.
ioports=FROM[-TO] Adicionar uma legacia de classe de Entrada/Saída para um domínio, usando os parâmetros apresentados (em hex). Por exemplo ioports=02f8-02ff. A opção pode ser repetida para adicionar mais do que uma classe de Entrada/Saída.
irq=IRQ Adicionar um IRQ (linha interrupta) à um domínio. Por exemplo irq=7. Esta opção pode ser repetida para adicionar mais do que um IRQ.
usbport=PATH Adicionar uma porta física de USB em um domínio, como especificado pelo caminho para a porta. Esta opção pode ser repetida para adicionar mais do que uma porta.
vfb=type={vnc,sdl}, vncunused=1, vncdisplay=N,
vnclisten=ADDR, display=DISPLAY,
xauthority=XAUTHORITY, vncpasswd=PASSWORD,
keymap=KEYMAP
Make the domain a framebuffer backend. The backend type should be either sdl or vnc. For type=vnc, connect an external vncviewer. The server will listen on ADDR (default 127.0.0.1) on port N+5900. N defaults to the domain id. If vncunused=1, the server will try to find an arbitrary unused port above 5900. For type=sdl, a viewer will be started automatically using the given DISPLAY and XAUTHORITY, which default to the current user's ones.
vif=type=TYPE, mac=MAC, bridge=BRIDGE, ip=IPADDR,
script=SCRIPT, backend=DOM, vifname=NAME
Adicionar uma interface de rede com um dado endereço e ponte MAC. O vif é configurado ao chamar o script de configuração dada. Se o tipo não for especificado, o padrão é o script de configuração dada. Se o mac não é especificado um endereço aleatório de MAC é usado. Se não especificado, então o back-ed da rede escolhe seu próprio endereço de MAC. Se a ponte não for especificada a primeira ponte encontrada é usada. Se o script não for especificado, o script padrão será usado. Se o back-ends não forem especificados o domínio do driver back-end padrão será usado. Se o vifname não for especificado a interface virtual de back-end terá o nome de vifD.N onde D é o id de domínio e N é o id de interface. Esta opção pode ser repetida para adicionar mais do que um vif. Especificar vifs aumentará o número de interface a medida que necessárias.
vtpm=instance=INSTANCE,backend=DOM Adicionar uma interface de TPM. No lado de back-end use a instância dada como instância de TPM virtual. O número dado é meramente o númer de instância preferida. O script de hotplug irá determinar qual o número de instância que será realmente atribuído ao domínio. A associação entre a máquina virtual e o númer de instância de TPM pode ser encontrado em /etc/xen/vtpm.db. Use o back-end no domínio dado.
access_control=policy=POLICY,label=LABEL Adicionar o rótulo de segurança e a referência de política de segurança que define isso. A referência de ssid local é calculada ao iniciar ou resumir o domínio. Neste momento, a política é verficada em relação à política ativa também. Desta forma, a migração pelas funções salvas e recupearadas são cobertas e rótulos locais são automaticamente criados corretamente no sistema onde um domínio é iniciado ou resumido.
nics=NUM OBSOLETO. Use entradas de vif vazias ao invés disso. Defina o número de interfaces de rede. Use a opção de vif para definir os parâmetros de interface, caso contrário os padrões serão usados. Especificar os vifs irá aumentar o número de interfaces a medida que sejam necessários.
root=DEVICE Definir o root= parâmetro na linha de comando do kernel. Use o dispositivo, ex.: /dev/sda1, ou /dev/nfs for NFS root.
extra=ARGS Definir argumentos extras para adicionar à linha de comando do kernel.
ip=IPADDR Definir o endereço de interface do IP do kernel.
gateway=IPADDR Definir o gateway IP do kernel.
netmask=MASK Definir a netmask IP do kernel.
hostname=NAME Definir o hostname IP do kernel.
interface=INTF Definir o nome de interface IP do kernel.
dhcp=off|dhcp Definir a opção dhcp do kernel.
nfs_server=IPADDR Definir o endereço do servidor do NFS para o root do NFS.
nfs_root=PATH Definir o caminho do diretório NFS root.
device_model=FILE Caminho para o programa do modelo do dispositivo.
fda=FILE Caminho para o fda.
fdb=FILE Caminho para fdb
serial=FILE Caminh opara o serial ou pty ou vc.
localtime=no | yes O RTC está definido para o horário local
keymap=FILE Definir o layout do teclado usado
usb=no | yes Emular os dispositivos do USB
usbdevice=NAME Nome de um dispositivo USB a adicionar.
stdvga=no | yes Use std vga or Cirrus Logic graphics
isa=no | yes Estimular um ISA somente sistema
boot=a|b|c|d Dispositivo de inicialização padrão
nographic=no | yes Os modelos de dispositivos devem usar gráficos?
soundhw=audiodev Os modelos de dispositivo devem ativar o dispositivo de áudio?
vnc O mode de dispositivo deve usar o VNC?
vncdisplay O dispositivo de VNC a usar
vnclisten Endereço para o servidor do VNC a aguardar
vncunused Tente encontrar uma porta não usada para o servidor do VNC. Somente válido quando o vnc=1.
sdl O modelo de dispositivo deve usar o SDL?
display=DISPLAY O dispositivo do X11 a usar
xauthority=XAUTHORITY A Autoridade do X11 a usar
uuid O xenstore UUID (universally unique identifier) a usar. Um será gerado aleatoriamente se esta opção não estiver definida, como os endereços do MAC para interfaces de rede virtuais. Esta deve ser um valor único em todo o cluster.

Tabela 31.3, “Valores padrão de parâmetro de configuração ” lists all configuration parameters available, the Python parser function which sets the value and default values. The setter function gives an idea of what the parser does with the values you specify. It reads these as Python values, then feeds them to a setter function to store them. If the value is not valid Python, you get an obscure error message. If the setter rejects your value, you should get a reasonable error message, except it appears to get lost somehow, along with your bogus setting. If the setter accepts, but the value is incorrect the application may fail.
Tabela 31.2. As funções do Python que definem valores de parâmetros.
Função de analisador Argumentos válidos
set_bool
Valores aceitos:
  • yes
  • y
  • no
  • yes
set_float
Accepts a floating point number with Python's float(). For example:
  • 3.14
  • 10.
  • .001
  • 1e100
  • 3.14e-10
set_int
Accepts an integer with Python's int().
set_value
aceita qualquer valor de Python.
append_value
aceita qualquer valor de Python, e adiciona-o ao valor anterior que é armazenado na matriz.

Tabela 31.3. Valores padrão de parâmetro de configuração
Parameter Função de analisador Valor padrão
name setter default value
vncpasswd set_value None
vncviewer set_bool None
vncconsole set_bool None
name set_value None
bootloader set_value None
bootargs set_value None
bootentry set_value None
kernel set_value None
ramdisk set_value ''
features set_value ''
builder set_value 'linux'
memory set_int 128
maxmem set_int None
shadow_memory set_int 0
cpu set_int None
cpus set_value None
pae set_int 0
acpi set_int 0
apic set_int 0
vcpus set_int 1
cpu_weight set_float None
restart set_value None
on_poweroff set_value None
on_reboot set_value None
on_crash set_value None
blkif set_bool 0
netif set_bool 0
tpmif append_value 0
disk append_value []
pci append_value []
ioports append_value []
irq append_value []
usbport append_value []
vfb append_value []
vif append_value []
vtpm append_value []
access_control append_value []
nics set_int -1
root set_value ''
extra set_value ''
ip set_value ''
gateway set_value ''
netmask set_value ''
hostname set_value ''
interface set_value "eth0"
dhcp set_value 'off'
nfs_server set_value None
nfs_root set_value None
device_model set_value ''
fda set_value ''
fdb set_value ''
serial set_value ''
localtime set_bool 0
keymap set_value ''
usb set_bool 0
usbdevice set_value ''
stdvga set_bool 0
isa set_bool 0
boot set_value 'c'
nographic set_bool 0
soundhw set_value ''
vnc set_value None
vncdisplay set_value None
vnclisten set_value None
vncunused set_bool 1
sdl set_value None
display set_value None
xauthority set_value None
uuid set_value None

Parte VII. Dicas e Truques

Capítulo 32. Dicas e Truques

Este capítulo contém dicas e idéias úteis para aprimorar o desempenho de virtualização, a escala e escalabilidade.

32.1. Iniciando convidados automaticamente

This section covers how to make virtualized guests start automatically during the host system's boot phase.
Este exemplo usa virsh para definir um convidado, TestServer, para iniciar automaticamente quando o host inicializar.
# virsh autostart TestServer
Domain TestServer marked as autostarted
O convidado inicia agora automaticamente com o host.
Para parar um convidado automaticamente inicializando, use o parâmetro --disable
# virsh autostart --disable TestServer
Domain TestServer unmarked as autostarted
O convidado não inicia mais automaticamente com o host

32.2. Alternando entre hypervisors KVM e Xen

Esta seção trata sobre a mudança entre os hypervisors do KVM e Xen.
A Red Hat somente suporta um hypervisor ativo por vez.

Migrar convidados virtualizados entre hypervisors.

Atualmente, não há aplicativo para alternar os convidados baseados em Xen para KVM ou vice-versa. Os convidados podem ser usados somente no tipo de hypervisor onde foram criados.

Aviso

Este procedimento está disponível somente para a versão Intel 64 ou AMD64 do Red Hat Enterprise Linux 5.4 ou mais novos. Nenhuma outra configuração ou versões do Red Hat Enterprise Linux são suportadas. O KVM não está disponível nas versões anteriores ao Red Hat Enterprise Linux 5.4.

32.2.1. De Xen para KVM

O procedimento a seguir trata sobre a mudança do hypervisor do Xen para o hypervisor do KVM. Este procedimento necessita do pacote kernel-xen instalado e ativado.
  1. Instalar o pacote do KVM

    Instalar o pacote do kvm , se você já não houver instalado.
    # yum install kvm
    
  2. Verifique qual kernel está em uso.

    O pacote do kernel-xen pode ser instalado. Use o comandouname para determinar qual kernel está rodando:
    $ uname -r
    2.6.18-159.el5xen
    
    O kernel atual, "2.6.18-159.el5xen", está rodando no sistema. Se o kernel padrão, "2.6.18-159.el5", estivr rodando, você poderá pular este passo.
    1. Alterando o kernel do Xen para kernel padrão

      O arquivo grub.conf determina qual kernel é inicializado. Para mudar o kernel padrão, edite o arquivo /boot/grub/grub.conf como demonstrado anteriormente.
      								default=1
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
      Note o parâmetro default=1. Ele está instruindo o carregador de inicialização do GRUB para inicializar a segunda entrada, o kernel do Xen. Mude padrão para 0 (ou para o número para o kernel padrão):
      								default=0
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. Reinicialie para carregar o novo kernel

    Reinicialize o sistema. O computador irá reiniciar com o kernel padrão. O módulo KVM deve ser carregado automaticamente com o kernel. Verifique se o KVM está rodando:
    $ lsmod | grep kvm
    kvm_intel              85992  1 
    kvm                   222368  2 ksm,kvm_intel
    
    O módulo kvm e o módulo kvm_intel ou o módulo kvm_amd estão presentes se tudo funcionar.

32.2.2. KVM para Xen

O procedimento a seguir trata sobre a mudança do hypervisor KVM para o hypervisor Xen. Este procedimento necessita do pacote kvm instalado e ativado.
  1. Instalar os pacotes do Xen

    Instale o pacote kernel-xen e xen caso ainda não o tenha feito.
    # yum install kernel-xen xen
    
    O pacote kernel-xen pode ser instalado mas não desativado.
  2. Verifique qual kernel está em uso.

    Use o comando uname para determinar qual kernel está rodando.
    $ uname -r
    2.6.18-159.el5
    
    O kernel atual, "2.6.18-159.el5", está rodando no sistema. Este kernel é o padrão. Se o kernel possui o xen ao final (por exemplo 2.6.18-159.el5xen) então o kernel do Xen está rodando e você pode pular este passo.
    1. Alterando o kernel padrão para o kernel Xen.

      O arquivo grub.conf determina qual kernel é inicializado. Para mudar o kernel padrão, edite o arquivo /boot/grub/grub.conf como demonstrado anteriormente.
      								default=0
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
      Observe o parâmetro default=0. Ele está instruindo o inicializador do GRUB para iniciar a primeira entrada, o kernel padrão. Mude o padrão para 1 (ou para o número para o kernel do Xen):
      								default=1
      timeout=5
      splashimage=(hd0,0)/grub/splash.xpm.gz
      hiddenmenu
      title Red Hat Enterprise Linux Server (2.6.18-159.el5)
              root (hd0,0)
              kernel /vmlinuz-2.6.18-159.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              initrd /initrd-2.6.18-159.el5.img
      title Red Hat Enterprise Linux Server (2.6.18-159.el5xen)
              root (hd0,0)
              kernel /xen.gz-2.6.18-159.el5
              module /vmlinuz-2.6.18-159.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet
              module /initrd-2.6.18-159.el5xen.img
      
  3. Reinicialie para carregar o novo kernel

    Reinicializar o sistema. O computador irá reiniciar com o kernel do Xen. Verifique com o comando uname:
    $ uname -r
    2.6.18-159.el5xen
    
    Se o resultado possui um xen no final, significa que o kernel Xen está rodando.

32.3. Usando o qemu-img

A ferramenta de linha de comando do qemu-img é usada para formatar diversos sistemas de arquivos, usados pelo Xen e KVM. O qemu-img deve ser usado para formatar imagens de convidados virtualizados, dispositivos de armazenamento adicional e armazenamento de rede, as opções qemu-img e uso estão listados abaixo.
Formatando e criando novas imagens ou dispositivos
Criar um novo nome de arquivo de imagem do tamanho size e formato format.
# qemu-img create [-6] [-e] [-b base_image] [-f format] filename [size]
Se o base_image for especificado, a imagem irá gravar somente as diferenças entre o base_image. Não é necessário especificar nenhum tamanho neste caso. O base_image nunca será modificado a menos que você use o comando de monitoramento do "commit".
Converter uma imagem existente para um outro formato
A opção convert é usada para converter um formato reconhecido para outro formato de imagem.
Formato de comando:
# qemu-img convert [-c] [-e] [-f format] filename [-O output_format] output_filename
Converter imagem de disco filename para imagem de disco output_filename usando formato output_format. A imagem de disco pode ser criptografada opcionalmente com a opção -e compactada com a opção-c.
Somente o formato "qcow" suporta a criptografia ou compactação. A compactação é somente-leitura, ou seja, se um setor compactado é regravado, ele será regravado como dados compactados.
A criptografia usa o formato AES com chaves de 128 bits muito seguras. Use uma senha longa (mais de 16 caracteres) para obter proteção máxima.
A conversão de imagem também é útil para obter imagens menores quando utilizar um formato que pode crescer, tal como qcow oucow. Os setores vazios são detectados e suprimidos para a imagem de destino.
Obtendo Informações de imagem
o parâmetro do info exibe informações sobre uma imagem de disco. O formato para a opção info é esta a seguir:
# qemu-img info [-f format] filename
fornece informações sobre o filename de imagem de disco. use-o especialmente para saber o tamanho reservado em cada disco, que pode ser diferente do tamanho exibido. se os snapshots do vm são armazenados na imagem de disco, também serão exibidos.
Formatos suportados
O formato de uma imagem é geralmente adivinhado automaticamente. Os formatos a seguir são suportados:
raw
O formato de imagem de disco bruto (padrão). Este formato tem a vantagem de ser simples e fácil de exportar para todos os outros emuladores. Se seu sistema de arquivos suporta buracos (por exemplo em ext2 ou ext3 no Linux ou NTFS no Windows.), então somente os setores gravados irão reservar espaço. Use o qemu-img info para saber o tamanho real usada pela imagem ou ls -ls no Unix/Linux.
qcow2
O formato de imagem QEMU, o formato mais versátil. Use-o para diminuir imagens (útil se seu sistema de arquivo não suportar holes, por exemplo: no Windows), criptografia AES adicional, compactação baseada em zlib e suporte de snapshots de VM múltiplos.
qcow
Formato de imagem de QEMU antigo. Somente incluso para compatibilidade com versões mais antigas.
cow
Formato de imagem User Mode Linux Copy On Write (Modo de Usuário do Linux de Cópia na Gravação). O formato cow é incluso somente para compatibilidade com versões anteriores. Não funciona com o Windows.
vmdk
Formato de imagem compatível com VMware 3 e 4.
cloop
Imagem de auto-retorno compactada do Linux, útil somente para reusar diretamente as imagens de CD-ROM compactadas presentes por exemplo no Knoppix CD-ROMs.

32.4. Overcommitting Resources

The KVM hypervisor supports overcommitting CPUs and memory. Overcommitting is the process of allocating more virtualized CPUs or memory than there are physical resources on the system. CPU overcommit allows under-utilized virtualized servers or desktops to run on fewer servers which saves power and money.

Suporte do Xen

Memory overcommitting is not supported for the Xen hypervisor, however CPU overcommitting is supported.
Overcommit de memória
A maioria dos sistemas operacionais e aplicativos não usam 100% da RAM disponível o tempo todo. Este comportamento pode ser explorado com o KVM para usar mais memória para os convidados virtualizados do que houver fisicamente disponível.
When using KVM, virtual machines operate as Linux processes. Guests on the KVM hypervisor do not have blocks of physical RAM assigned to them, instead they function as processes. Each process in a Linux system is allocated memory when it requests more memory. In a similar way, KVM allocates memory for guests when the guest requests more or less memory. The guest only uses slightly more physical memory than the virtualized operating system appears to use.
When physical memory is nearly completely used or a process is inactive for some time, Linux moves the process's memory to swap. Swap is usually a partition on a hard disk drive or solid state drive which Linux uses to extend virtual memory. Swap is significantly slower than RAM.
As KVM virtual machines are Linux processes, memory used by virtualized guests can be put into swap if the guest is idle or not in heavy use. Memory can be committed over the total size of the swap and physical RAM. This can cause issues if virtualized guests use their total RAM. Without sufficient memory and swap space for the virtual machine processes, the system can run completely out of memory, leading to the failure of one or more virtual machine processes.

Aviso

Se não houver Swap suficiente disponível, os sistemas operacionais do convidado irão fechar forçadamente. Isto pode deixar os convidados sem operação. Evite que isto aconteça, nunca comprometendo mais memória do que houver disponível no Swap.
A partição do Swap é usada para alternar memória sem uso para o disco rígido para acelerar desempenho de memória. O tamanho padrão da partição do Swap é calculado a partir da quantia de RAM e taxa de comprometimento (overcommit). Recomenda-se fazer sua partição do Swap maior, caso pretenda comprometer a memória, com o KVM. Recomenda-se um overcommit de 50% (0,5). A fórmula usada é:
(0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size
Red Hat Knowledgebase possui um artigo sobre determinar com segurança e eficiência o tamanho da partição do swap.
Overcommitting guests by swapping out temporarily unused guest memory can be very slow, due to the IO latency introduced by disk seek times. However, Red Hat Enterprise Linux virtualization with KVM can often avoid this disk IO penalty by merging multiple pages with identical content into the same physical pages. This is done by the KSM (Kernel Samepage Merging) kernel process, which scans memory to find identical pages. The KSM kernel process uses CPU time to avoid disk IO. This tradeoff is often beneficial in workloads with many smaller, similar guests.
É possível rodar com uma taxa de overcommit de dez vezes o número de convidados virtualizados sobre a quantidade de RAM física no sistema. Isto funciona somente com certas cargas de aplicativo (por exemplo, a virtualização do desktop com menos de 100% de uso). A fórmula de taxas de overcommit não é difícil, você precisa testar e padronizar a taxa para seu ambiente.
Overcommit de CPUs virtualizadas.
O hypervisor do KVM suporta o overcommit de CPUs virtualizadas. As CPUs virtualizadas podem ser comprometidas (overcommitted) até o limite de cargas de convidados virtualizados permitido. Cuidado ao comprometer as VCPUs, pois as cargas de quase 100% podem causar queda de requisição ou tempo de respostas impossíveis.
O overcommit de CPUs virtualizadas é melhor quando cada convidado virtualizado possui somente um único VCPU. O agendador do Linux é mais eficiente com este tipo de carga. O KVM deve suportar com segurança os convidados com cargas abaixo de 100% em uma taxa de cinco VCPUs.O overcommit de convidados virtualizados de VCPU único não é um problema.
Você não pode comprometer convidados simétricos de multi-processamento em mais do que o número físico de núcleos de processamento. Por exemplo, um convidado com quatro VCPUs não deve rodar em um host com um processador de núcleo duplo. Comprometer convidados de multiprocessamento simétrico em mais do que o número físico de núcleos de processamento causará danos significantes de desempenho.
É adequado atribuir VCPUs de convidados até o número de núcleos físicos e funciona como o esperado. Por exemplo, executar os convidados virtualizados com quatro VCPUs em um host de núcleo quádruplo. Os convidados com menos de 100% de cargas devem funcionar bem com esta definição.

Sempre teste primeiro

Não faça o overcommit da memória ou das CPUs em um ambiente de produção sem um teste estensivo. Os aplicativos que usam 100% de memória ou recursos de processamento podem se tornar instáveis ao comprometer (overcommit) ambientes. Teste antes de implementar.

32.5. Modificando /etc/grub.conf

This section describes how to safely and correctly change your /etc/grub.conf file to use the virtualization kernel. You must use the xen kernel to use the Xen hypervisor. Copy your existing xen kernel entry make sure you copy all of the important lines or your system will panic upon boot (initrd will have a length of '0'). If you require xen hypervisor specific values you must append them to the xen line of your grub entry.
O resultado abaixo é um exemplo de uma entrada do grub.conf de um sistema que esteja executando o pacote kernel-xen. O grub.conf pode variar em seu sistema. A parte importante no exemplo abaixo é a seção da linha do title até a nova próxima linha.
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

Um ponto importante sobre edição do grub.conf...

Your grub.conf could look very different if it has been manually edited before or copied from an example. Read Capítulo 28, Configurando os parâmetros de inicialização do kernel Xen for more information on using virtualization and grub.
Para definir a quantidade de memória atribuída ao sistema host durante a inicialização para 256 MB, adicione dom0_mem=256M à linha xen em seu grub.conf. Uma versão modificada do arquivo de configuração grub no exemplo anterior:
#boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21.el5xen)
	root (hd0,0)
	kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
	module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro
	root=/dev/VolGroup00/LogVol00
	module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.6. Verificando as extensões de virtualização

Use esta seção para determinar se seu sistema possui extensões de virtualização de hardware. As extensões de virtualização (Intel VT ou AMD-V) são requeridas para virtualização completa.

Posso usar a virtualização sem as extensões da mesma?

Se as extensões de virtualização do hardware não estiverem presentes você pode usar a para-virtualização do Xen com o pacote da Red Hat kernel-xen.
  1. Rode o seguinte comando para verificar se as extensções de virtualização da CPU estão disponíveis:
    $ grep -E 'svm|vmx' /proc/cpuinfo
    
  2. Analyze the output.
    • O resultado a seguir contém uma entrada de vmx indicando um processador da Intel com as extensões do VT Intel:
      flags   : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush 
      	dts acpi mmx fxsr sse sse2 ss ht  tm syscall lm constant_tsc pni monitor ds_cpl
      	vmx est tm2 cx16 xtpr lahf_lm
      
    • O resultado a seguir contém uma entrada do svm indicando um processador do AMD com extensões do AMD-V:
      flags   :  fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush
      	mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni cx16
      	lahf_lm cmp_legacy svm cr8legacy ts fid vid ttp tm stc
      
    If any output is received, the processor has the hardware virtualization extensions. However in some circumstances manufacturers disable the virtualization extensions in BIOS.
    O conteúdo "flags:" pode aparecer diversas vezes para cada hyperthread, núcleo ou CPU no sistema.
    The virtualization extensions may be disabled in the BIOS. If the extensions do not appear or full virtualization does not work refer to Procedimento 35.1, “Ativando as extensões de virtualização em BIOS”.
  3. For users of the KVM hypervisor

    If the kvm package is installed. I As an additional check, verify that the kvm modules are loaded in the kernel:
    # lsmod | grep kvm
    
    If the output includes kvm_intel or kvm_amd then the kvm hardware virtualization modules are loaded and your system meets requirements. sudo

Additional output

If the libvirt package is installed, the virsh command can output a full list of virtualization system capabilities. Run virsh capabilities as root to receive the complete list.

32.7. Accessing data from a guest disk image

There are various methods for accessing the data from guest image files. One common method is to use the kpartx tool, covered by this section, to mount the guest file system as a loop device which can then be accessed.
The kpartx command creates device maps from partition tables. Each guest storage image has a partition table embedded in the file.
The libguestfs and guestfish packages, available from the EPEL repository, allow advanced modification and access to guest file systems. The libguestfs and guestfish packages are not covered in this section at this time.

Aviso

Guests must be offline before their files can be read. Editing or reading files of an active guest is not possible and may cause data loss or damage.
Procedimento 32.1. Accessing guest image data
  1. Install the kpartx package.
    # yum install kpartx
    
  2. Use kpartx to list partition device mappings attached to a file-based storage image. This example uses a image file named guest1.img.
    # kpartx -l /var/lib/libvirt/images/guest1.img
    loop0p1 : 0 409600 /dev/loop0 63
    loop0p2 : 0 10064717 /dev/loop0 409663
    guest1 is a Linux guest. The first partition is the boot partition and the second partition is an EXT3 containing the root partition.
  3. Add the partition mappings to the recognized devices in /dev/mapper/.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
    1. Test that the partition mapping worked. There should be new devices in the /dev/mapper/ directory
      # ls /dev/mapper/
      loop0p1
      loop0p2
      
      The mappings for the image are named in the format loopXpY.
  4. Mount the loop device which to a directory. If required, create the directory. This example uses /mnt/guest1 for mounting the partition.
    # mkdir /mnt/guest1
    # mount /dev/mapper/loop0p1 /mnt/guest1 -o loop,ro
  5. The files are now available for reading in the /mnt/guest1 directory. Read or copy the files.
  6. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/tmp
  7. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be started again.
Accessing data from guest LVM volumes
Many Linux guests use Logical Volume Management (LVM) volumes. Additional steps are required to read data on LVM volumes on virtual storage images.
  1. Add the partition mappings for the guest1.img to the recognized devices in the /dev/mapper/ directory.
    # kpartx -a /var/lib/libvirt/images/guest1.img
    
  2. In this example the LVM volumes are on a second partition. The volumes require a rescan with the vgscan command to find the new volume groups.
    # vgscan
    Reading all physical volumes . This may take a while...
    Found volume group "VolGroup00" using metadata type lvm2
  3. Activate the volume group on the partition (called VolGroup00 by default) with the vgchange -ay command.
    # vgchange -ay VolGroup00
    2 logical volumes in volume group VolGroup00 now active.
  4. Use the lvs command to display information about the new volumes. The volume names (the LV column) are required to mount the volumes.
    # lvs
    LV VG Attr Lsize Origin Snap% Move Log Copy%
    LogVol00 VolGroup00 -wi-a- 5.06G
    LogVol01 VolGroup00 -wi-a- 800.00M
  5. Mount /dev/VolGroup00/LogVol00 in the /mnt/guestboot/ directory.
    # mount /dev/VolGroup00/LogVol00 /mnt/guestboot
  6. The files are now available for reading in the /mnt/guestboot directory. Read or copy the files.
  7. Unmount the device so the guest image can be reused by the guest. If the device is mounted the guest cannot access the image and therefore cannot start.
    # umount /mnt/
  8. Disconnect the volume group VolGroup00
    # vgchange -an VolGroup00
    
  9. Disconnect the image file from the partition mappings.
    # kpartx -d /var/lib/libvirt/images/guest1.img
    
The guest can now be restarted.

32.8. Setting KVM processor affinities

This section covers setting processor and processing core affinities with libvirt for KVM guests.
By default, libvirt provisions guests using the hypervisor's default policy. For most hypervisors, the policy is to run guests on any available processing core or CPU. There are times when an explicit policy may be better, in particular for systems with a NUMA (Non-Uniform Memory Access) architecture. A guest on a NUMA system should be pinned to a processing core so that its memory allocations are always local to the node it is running on. This avoids cross-node memory transports which have less bandwidth and can significantly degrade performance.
On a non-NUMA systems some form of explicit placement across the hosts’ sockets, cores and hyperthreads may be more efficient.
Identifying CPU and NUMA topology
The first step in deciding what policy to apply is to determine the host’s memory and CPU topology. The virsh nodeinfo command provides information about how many sockets, cores and hyperthreads there are attached a host.
# virsh nodeinfo
CPU model:           x86_64
CPU(s):              8
CPU frequency:       1000 MHz
CPU socket(s):       2
Core(s) per socket:  4
Thread(s) per core:  1
NUMA cell(s):        1
Memory size:         8179176 kB
This system has eight CPUs, in two sockets, each processor has four cores.
The output shows that that the system has a NUMA architecture. NUMA is more complex and requires more data to accurately interpret. Use the virsh capabilities to get additional output data on the CPU configuration.
# virsh capabilities
<capabilities>
  <host>
    <cpu>
      <arch>x86_64</arch>
    </cpu>
    <migration_features>
      <live/>
      <uri_transports>
        <uri_transport>tcp</uri_transport>
      </uri_transports>
    </migration_features>
    <topology>
      <cells num='2'>
        <cell id='0'>
          <cpus num='4'>
            <cpu id='0'/>
            <cpu id='1'/>
            <cpu id='2'/>
            <cpu id='3'/>
          </cpus>
        </cell>
        <cell id='1'>
          <cpus num='4'>
            <cpu id='4'/>
            <cpu id='5'/>
            <cpu id='6'/>
            <cpu id='7'/>
          </cpus>
        </cell>
      </cells>
    </topology>
    <secmodel>
      <model>selinux</model>
      <doi>0</doi>
    </secmodel>
  </host>

 [ Additional XML removed ]

</capabilities>
The output shows two NUMA nodes (also know as NUMA cells), each containing four logical CPUs (four processing cores). This system has two sockets, therefore we can infer that each socket is a separate NUMA node. For a guest with four virtual CPUs, it would be optimal to lock the guest to physical CPUs 0 to 3, or 4 to 7 to avoid accessing non-local memory, which are significantly slower than accessing local memory.
If a guest requires eight virtual CPUs, as each NUMA node only has four physical CPUs, a better utilization may be obtained by running a pair of four virtual CPU guests and splitting the work between them, rather than using a single 8 CPU guest. Running across multiple NUMA nodes significantly degrades performance for physical and virtualized tasks.
Decide which NUMA node can run the guest
Locking a guest to a particular NUMA node offers no benefit if that node does not have sufficient free memory for that guest. libvirt stores information on the free memory available on each node. Use the virsh freecell command to display the free memory on all NUMA nodes.
# virsh freecell
0: 2203620 kB
1: 3354784 kB
If a guest requires 3 GB of RAM allocated, then the guest should be run on NUMA node (cell) 1. Node 0 only has 2.2GB free which is probably not sufficient for certain guests.
Lock a guest to a NUMA node or physical CPU set
Once you have determined which node to run the guest on, refer to the capabilities data (the output of the virsh capabilities command) about NUMA topology.
  1. Extract from the virsh capabilities output.
    <topology>
      <cells num='2'>
        <cell id='0'>
        <cpus num='4'>
          <cpu id='0'/>
          <cpu id='1'/>
          <cpu id='2'/>
          <cpu id='3'/>
        </cpus>
      </cell>
      <cell id='1'>
        <cpus num='4'>
          <cpu id='4'/>
          <cpu id='5'/>
          <cpu id='6'/>
          <cpu id='7'/>
        </cpus>
      </cell>
      </cells>
    </topology>
  2. Observe that the node 1, <cell id='1'>, has physical CPUs 4 to 7.
  3. The guest can be locked to a set of CPUs by appending the cpuset attribute to the configuration file.
    1. While the guest is offline, open the configuration file with virsh edit.
    2. Locate where the guest's virtual CPU count is specified. Find the vcpus element.
      <vcpus>4</vcpus>
      The guest in this example has four CPUs.
    3. Add a cpuset attribute with the CPU numbers for the relevant NUMA cell.
      <vcpus cpuset='4-7'>4</vcpus>
  4. Save the configuration file and restart the guest.
The guest has been locked to CPUs 4 to 7.
Automatically locking guests to CPUs with virt-install
The virt-install provisioning tool provides a simple way to automatically apply a 'best fit' NUMA policy when guests are created.
The cpuset option for virt-install can use a CPU set of processors or the parameter auto. The auto parameter automatically determines the optimal CPU locking using the available NUMA data.
For a NUMA system, use the --cpuset=auto with the virt-install command when creating new guests.
Tuning CPU affinity on running guests
There may be times where modifying CPU affinities on running guests is preferable to rebooting the guest. The virsh vcpuinfo and virsh vcpupin commands can perform CPU affinity changes on running guests.
The virsh vcpuinfo command gives up to date information about where each virtual CPU is running.
In this example, guest1 is a guest with four virtual CPUs is running on a KVM host.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            3
State:          running
CPU time:       0.5s
CPU Affinity:   yyyyyyyy
VCPU:           1
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           2
CPU:            1
State:          running
CPU Affinity:   yyyyyyyy
VCPU:           3
CPU:            2
State:          running
CPU Affinity:   yyyyyyyy
The virsh vcpuinfo output (the yyyyyyyy value of CPU Affinity) shows that the guest can presently run on any CPU.
To lock the virtual CPUs to the second NUMA node (CPUs four to seven), run the following commands.
# virsh vcpupin guest1 0 4
# virsh vcpupin guest1 1 5
# virsh vcpupin guest1 2 6
# virsh vcpupin guest1 3 7
The virsh vcpuinfo command confirms the change in affinity.
# virsh vcpuinfo guest1
VCPU:           0
CPU:            4
State:          running
CPU time:       32.2s
CPU Affinity:   ----y---
VCPU:           1
CPU:            5
State:          running
CPU time:       16.9s
CPU Affinity:   -----y--
VCPU:           2
CPU:            6
State:          running
CPU time:       11.9s
CPU Affinity:   ------y-
VCPU:           3
CPU:            7
State:          running
CPU time:       14.6s
CPU Affinity:   -------y

32.9. Gerar um novo endereço de MAC único.

In some case you will need to generate a new and unique MAC address for a guest. There is no command line tool available to generate a new MAC address at the time of writing. The script provided below can generate a new MAC address for your guests. Save the script to your guest as macgen.py. Now from that directory you can run the script using ./macgen.py and it will generate a new MAC address. A sample output would look like the following:
$ ./macgen.py 
00:16:3e:20:b0:11
	
#!/usr/bin/python
# macgen.py script to generate a MAC address for virtualized guests on Xen
#
import random
#
def randomMAC():
	mac = [ 0x00, 0x16, 0x3e,
		random.randint(0x00, 0x7f),
		random.randint(0x00, 0xff),
		random.randint(0x00, 0xff) ]
	return ':'.join(map(lambda x: "%02x" % x, mac))
#
print randomMAC()
Outro método a gerar um novo MAC para seu convidado
Você também pode usar módulos embutidos do python-virtinst para gerar endereços MAC novos e UUID para uso no arquivo de configuração do convidado:
# echo  'import virtinst.util ; print\
 virtinst.util.uuidToString(virtinst.util.randomUUID())' | python
# echo  'import virtinst.util ; print virtinst.util.randomMAC()' | python
O script acima também pode ser implementado como um arquivo de script como visto abaixo.
#!/usr/bin/env python
#  -*- mode: python; -*-
print ""
print "New UUID:"
import virtinst.util ; print virtinst.util.uuidToString(virtinst.util.randomUUID())
print "New MAC:"
import virtinst.util ; print virtinst.util.randomMAC()
print ""

32.10. Limitar a largura de banda de rede para um convidado do Xen

In some environments it may be required to limit the network bandwidth available to certain guests. This can be used to implement basic Quality of Service on a host running multiple virtual machines. By default, the guest can use any bandwidth setting available which your physical network card supports. The physical network card must be mapped to one of virtual machine's virtual network interfaces. In Xen the “rate” parameter part of the VIF entries can throttle virtualized guests.
Esta lista cobre as variantes
rate
The rate= option can be added to the VIF= entry in a virtual machine configuration file to limit a virtual machine's network bandwidth or specify a specific time interval for a time window.
janela de horário
A janela de horário é opcional para a opção rate=:
A janela de horário padrão é 50ms.
Uma janela de horário menor irá fornecer menos transmissão de estouro, no entanto, a taxa de repreenchimento e latência irão aumentar.
A janela de horário de 50ms padrão é um bom balanço entre a latência e transmissão e na maioria dos casos não requer mudança.
Exemplos de valores de parâmetros de rate e uso.
rate=10Mb/s
Limita de tráfego de rede de saída a partir do convidado para 10MB/s
rate=250KB/s
Limitar o tráfego de rede de saída do convidado para 250KB/s.
rate=10MB/s@50ms
Limitar a largura de banda para 10MB/s e fornecer o convidado com um 50KB a cada 50ms.
Na configuração de máquina virtual uma amostra de entrada de VIF se pareceria com esta a seguir:
vif = [ 'rate=10MB/s , mac=00:16:3e:7a:55:1c, bridge=xenbr1']
This rate entry would limit the virtual machine's interface to 10MB/s for outgoing traffic

32.11. Configurando as afinidades de processador do Xen.

O Xen possibilita que uma CPU virtual se associe com uma ou mais CPUs do host. Isto pode ser usado para alocar recursos reais entre um ou mais convidados. Esta forma permite que o Red Hat Enterprise Linux faça uso optimizado dos recursos do processador ao empregar centro duplo, hyperthreading, ou outras tecnologias de CPU avançadas. O agendador de crédito do Xen balanceia cpus virtuais entre as físicas, automaticamente, para maximizar o uso do sistema. O Red Hat Enterprise Linux permite que o agendador de crédito mova as CPUs o quanto for necessário, desde que a CPU virtual seja empilhada em uma CPU física.
Se você está rodando tarefas intensivas de E/S, recomenda-se dedicar uma hyperthread ou todo um núcleo de processador para rodar o domain0.
Observe que é desnecessário para o KVM pois ele usa o agendador do kernel do Linux padrão.
As afinidades da CPU pode ser definida com virsh ou virt-manager:
To set CPU affinities using virsh refer to Configurando Afinidade da CPU Virtual for more information.
To configure and view CPU information with virt-manager refer to Seção 26.11, “Exibindo as CPUs Virtuais ” for more information.

32.12. Modificando o hypervisor do Xen

Managing host systems often involves changing the boot configuration file /boot/grub/grub.conf. Managing several or more hosts configuration files quickly becomes difficult. System administrators often prefer to use the 'cut and paste' method for editing multiple grub.conf files. If you do this, ensure you include all five lines in the Virtualization entry (or this will create system errors). Hypervisor specific values are all found on the 'xen' line. This example represents a correct grub.conf virtualization entry:
# boot=/dev/sda/
default=0
timeout=15
#splashimage=(hd0, 0)/grub/splash.xpm.gz

hiddenmenu
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0, 0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1
    module /vmlinuz-2.6.17-1.2519.4.21el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img
For example, to change the memory entry on your hypervisor (dom0) to 256MB at boot time, edit the 'xen' line and append it with this entry: 'dom0_mem=256M'. This example is the grub.conf with the hypervisor's memory entry modified.
# boot=/dev/sda
default=0
timeout=15
#splashimage=(hd0,0)/grubs/splash.xpm.gz
hiddenmenu
serial --unit=0 --speed =115200 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console
title Red Hat Enterprise Linux Server (2.6.17-1.2519.4.21. el5xen)
root (hd0,0)
kernel /xen.gz-2.6.17-1.2519.4.21.el5 com1=115200,8n1 dom0_mem=256MB
    module /vmlinuz-2.6.17-1.2519.4.21.el5xen ro root=/dev/VolGroup00/LogVol00
    module /initrd-2.6.17-1.2519.4.21.el5xen.img

32.13. O ftpd seguro

O vsftpd pode fornecer acesso às árvores de instalação para os convidados para-virtualizados (por exemplo, os repositórios do Red Hat Enterprise Linux 5 repositories) ou outros dados. Se você ainda não instalou o vsftpd durante a instalação do servidor, pegue o pacote do RPM do seu diretório do Server de sua mídia de instalação e instale-o usando o rpm -ivh vsftpd*.rpm (observe que o pacote de RPM deve estar em seu diretório atual).
  1. To configure vsftpd, edit /etc/passwd using vipw and change the ftp user's home directory to the directory where you are going to keep the installation trees for your para-virtualized guests. An example entry for the FTP user would look like the following:
    ftp:x:14:50:FTP User:/xen/pub:/sbin/nologin
    
  2. Verifique se vsftpd não está embutido, usando o chkconfig --list vsftpd:
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
    
  3. Execute o chkconfig --levels 345 vsftpd on para iniciar o vsftpd automaticamente para níveis de execução 3, 4 e 5.
  4. Use o comando chkconfig --list vsftpd para verificar se o daemon do vsftpd está apto para iniciar durante a inicialização de sistema:
    $ chkconfig --list vsftpd
    vsftpd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
    
  5. use o service vsftpd start vsftpd para iniciar o serviço vsftpd:
    $service vsftpd start vsftpd
    Starting vsftpd for vsftpd:                  [  OK  ]
    

32.14. Configurando o Lun Persistance

This section covers how to implement LUN persistence in guests and on the host machine with and without multipath.
Implementando o Lun Persistance sem o multipath
Se seu sistema não estiver usando o multipath, você pode usar o udev para implementar o lun persistence. Antes de implementar o lun persistence em seu sistema, adquira UUIDs apropriados. Depois disso, você pode configurar o lun persistence, editando o arquivo scsi_id que reside no diretório /etc . Quando você tiver este arquivo aberto em um editor de texto, você deve comentar esta linha:
# options=-b
Depois, substitua-o por este parâmetro:
# options=-g
Isto informa o udev para monitorar todos os dispositivos SCSI do sistema para UUIDs retornando. Para determinar os UUIDs de sistema, use o comando scsi_id:
# scsi_id -g -s /block/sdc
*3600a0b80001327510000015427b625e*
Esta faixa longa de caracteres é o UUID. Os UUIDs não mudam quando você adicionar um novo dispositivo ao seu sistema. Adquira o UUID para cada dispositivo para criar regras para os dispositivos. Para criar estas regras, você precisa editar o arquivo 20-names.rules que se encontra no diretório /etc/udev/rules.d . As regras de nomeação do dispositivo que você criar aqui devem seguir este formato:
# KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="UUID", NAME="devicename"
Substitua seu UUID existente e devicename com a entrada recuperada do UUID acima. A regra deve se assemelhar a esta:
KERNEL="sd*",  BUS="scsi",  PROGRAM="sbin/scsi_id", RESULT="3600a0b80001327510000015427b625e", NAME="mydevicename"
Isto ativa todos os dispositivos que coincidem com o modelo /dev/sd* para inspecionar o UUID dado. Quando ele encontrar um dipositivo que combine, ele criará um nó de dispositivo chamado /dev/devicename. Para este exemplo, o nó de dispositivo é /dev/mydevice . Finalmente, você precisará adicionar o arquivo /etc/rc.local com esta linha:
/sbin/start_udev
Implementando o Lun Persistance com multipath
Para implementar o Lun Persistence em um ambiente de caminho múltiplo, você deve definir os aliases para os dipositivos de multipath. Para este exemplo, você deve definir quatro aliases de dispositivos, editando o arquivo multipath.conf que se encontra no diretório /etc/:
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp1
}
multipath  {  
             wwid       3600a0b80001327510000015427b6
             alias      oramp2
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp3
}
multipath  {  
             wwid       3600a0b80001327510000015427b625e
             alias      oramp4
}
Isto define 4 luns: /dev/mpath/oramp1, /dev/mpath/oramp2, /dev/mpath/oramp3, edev/mpath/oramp4. Os dispositivos se encontrarão no diretório /dev/mpath . Estes nomes de lun são persistentes nas reinicializações a medida que cria nomes de alias no wwid dos Luns.

32.15. Desativar o monitoramente de disco SMART para convidados

O monitoramento de disco SMART pode ser desativado ao executar em discos virtuais e o armazenamento físico é gerenciado pelo host.
/sbin/service smartd stop
/sbin/chkconfig --del smartd

32.16. Limpando Arquivos de Configuração do Xen antigos

Over time you will see a number of files accumulate in /var/lib/xen, the usually named vmlinuz.****** and initrd.******. These files are the initrd and vmlinuz files from virtual machines which either failed to boot or failed for some other reason. These files are temporary files extracted from virtual machine's boot disk during the start up sequence. These files should be automatically removed after the virtual machine is shut down cleanly. Then you can safely delete old and stale copies from this directory.

32.17. Configurando um Servidor VNC

Para configurar um servidor VNC use o aplicativo do Desktop Remoto em System > Preferences. Como forma alternativa, execute o comando vino-preferences.
Os passos a seguir definem uma sessão do servidor VNC dedicada:
  1. Edite o arquivo ~/.vnc/xstartup para iniciar uma seção do GNOME, sempre que o vncserver é iniciado. E primeira vez que você rodar o script do vncserver ele irá pedir por uma senha que você deseje usar para sua seção do VNC.
  2. Um arquivo de amostra do xstartup :
    #!/bin/sh
    # Uncomment the following two lines for normal desktop:
    # unset SESSION_MANAGER
    # exec /etc/X11/xinit/xinitrc
    [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
    [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
    #xsetroot -solid grey
    #vncconfig -iconic &
    #xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
    #twm &
    if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
    	eval `dbus-launch --sh-syntax –exit-with-session`
    	echo "D-BUS per-session daemon address is: \
    	$DBUS_SESSION_BUS_ADDRESS"
    fi
    exec  gnome-session
    

32.18. Clonagem de Arquivos de Configuração de Convidado

You can copy an existing configuration file to create an all new guest. You must modify the name parameter of the guests' configuration file. The new, unique name then appears in the hypervisor and is viewable by the management utilities. You must generate an all new UUID as well by using the uuidgen command. Then for the vif entries you must define a unique MAC address for each guest (if you are copying a guest configuration from an existing guest, you can create a script to handle it). For the xen bridge information, if you move an existing guest configuration file to a new host, you must update the xenbr entry to match your local networking configuration. For the Device entries, you must modify the entries in the 'disk=' section to point to the correct guest image.
You must also modify these system configuration settings on your guest. You must modify the HOSTNAME entry of the /etc/sysconfig/network file to match the new guest's hostname.
Modifique o endereço HWADDR do /etc/sysconfig/network-scripts/ifcfg-eth0 para combinar com a saída do ifconfig eth0 e caso você use os endereços IP estáticos, modifique a entrada IPADDR.

32.19. Duplicando um convidado existente e seus Arquivos de Configuração

This section outlines copying an existing configuration file to create a new guest. There are key parameters in your guest's configuration file you must be aware of, and modify, to successfully duplicate a guest.
name
O nome de seus convidados é conhecido pelo hypervisor e exibido nos utilitários de gerenciamento. Esta entrada deve ser única em seu sistema.
uuid
Uma manipulação única para o convidado, um novo UUID pode ser regenerado usando o comando uuidgen. Um resultado de UUID de amostra:
$ uuidgen 
a984a14f-4191-4d14-868e-329906b211e5
vif
  • The MAC address must define a unique MAC address for each guest. This is automatically done if the standard tools are used. If you are copying a guest configuration from an existing guest you can use the script Seção 32.9, “Gerar um novo endereço de MAC único.”.
  • Se você estiver movendo ou duplicando um arquivo de configuração de convidado para um novo host, lembre-se de ajustar a entrada do xenbr para corresponder com a configuração de rede (você pode obter as informações de ponte usando o comando brctl show).
  • As entradas de dispositivo, lembre-se de ajustar as entradas na seção disk= para apontar para a imagem de convidado correta.
Agora, ajuste as configurações de sistema em seu convidado:
/etc/sysconfig/network
Modify the HOSTNAME entry to the guest's new hostname.
/etc/sysconfig/network-scripts/ifcfg-eth0
  • Modifique o endereço do HWADDR para o resultado a partir do ifconfig eth0
  • Modifique a entrada IPADDR se um endereço estático for utilizado.

Capítulo 33. Criação dos scripts libvirt padronizados

Esta seção irá fornecer informações que podem ser úteis para programadores e administradores de sistema que pretendem escrever scripts padronizados para facilitar suas vidas usando o libvirt.
Capítulo 32, Dicas e Truques is recommended reading for programmers thinking of writing new applications which use libvirt.

33.1. Usando os arquivos de configuração do XML com o virsh

virsh can handle XML configuration files. You may want to use this to your advantage for scripting large deployments with special options. You can add devices defined in an XML file to a running para-virtualized guest. For example, to add a ISO file as hdc to a running guest create an XML file:
# cat satelliteiso.xml
<disk type="file" device="disk">
	<driver name="file"/>
	<source file="/var/lib/libvirt/images/rhn-satellite-5.0.1-11-redhat-linux-as-i386-4-embedded-oracle.iso"/>
	<target dev="hdc"/>
	<readonly/>
</disk>
Run virsh attach-device to attach the ISO as hdc to a guest called "satellite" :
# virsh attach-device satellite satelliteiso.xml

Parte VIII. Troubleshooting

Introdução ao Troubleshooting e Solução de Problemas

Os capítulos a seguir fornecem informações para assistí-lo em problemas com troubleshooting que você possa encontrar usando a virtualização.

Nota importante sobre problemas com a tecnologia de virtualização

Principalmente seu problema pode não aparecer neste livro devido à desenvolvimento contínuo que cria e repara erros. Para obter uma lista mais atualizada dos erros conhecidos, problemas e reparos de erros, leia o Red Hat Enterprise Linux Release Notes para sua versão e arquitetura de hardware. O Lançamento de Notas pode ser encontrado na seção de documentação do Red Hat website, www.redhat.com/docs/manuals/enterprise/.

Se todos estes falharem...

Entre em contato com o Serviço de Suporte Red Hat Global Support Services (https://www.redhat.com/apps/support/). Nossos funcionários irão assistí-lo na resolução de seus problemas.

Índice

34. Ferramentas de Solução de Problemas do Xen
34.1. Depurando e Solucionando Problemas (Troubleshooting) do Xen
34.2. Visão Geral de Arquivo de Registro
34.3. Descrições de Arquivo de Registro
34.4. Localizações de Diretórios Importantes
34.5. Solucionando Problemas com os Registros
34.6. Solucionando Problemas com o Console em Serial
34.7. Acesso de Console de convidado Para-virtualizado.
34.8. Acesso ao Console de convidado com Virtualização Completa.
34.9. Problemas Comuns do Xen
34.10. Erros de Criação de Convidados
34.11. Solucionando Problemas com o Console Serial
34.11.1. Resultado de Console Serial para Xen
34.11.2. O resultado do console serial do Xen a partir dos convidados para-virtualizados.
34.11.3. Resultado de console serial a partir dos convidados totalmente virtualizados.
34.12. Arquivos de Configuração do Xen
34.13. Interpretando Mensagens de Erro do Xen
34.14. O layout dos diretórios do log
35. Troubleshooting
35.1. Identificando armazenamento e partições disponíveis
35.2. Após inicializar os convidados baseados em Xen, o console trava
35.3. Os dispositivos de Ethernet virtualizados não são encontrados pelas ferramentas de rede.
35.4. Erros de Dispositivo de Loop
35.5. Criação de domínio falhou, devido à falta de memória
35.6. Falha de Imagem de Kernel errada
35.7. Falha de imagem de kernel errada - Kernel não PAE em uma plataforma PAE
35.8. O convidado de 64 bits totalmente virtualizado falha ao iniciar.
35.9. Uma entrada de localhost faltando, faz com que o virt-manager falhe
35.10. Erro de microcódigo durante a inicialização do convidado
35.11. Mensagem de aviso de depreciação do Python ao iniciar a máquina virtual
35.12. Ativando as extensões de hardware de virtualização do Intel VT e AMD-V, no BIOS.
35.13. Desempenho de rede de KVM
36. Solucionando Problemas dos drivers para-virtualizados do Xen
36.1. Arquivos de registro e diretórios da Tecnologia de Virtualização do Red Hat Enterprise Linux 5
36.2. O convidado para-virtualizado falha ao carregar em um sistema operacional convidado Red Hat Enterprise Linux 3.
36.3. Uma mensagem de erro é exibida durante a instalação dos drivers para-virtualizados no Red Hat Enterprise Linux 3.
36.4. Carregando manualmente os drivers para-virtualizados.
36.5. Verificando se os drivers para-virtualizados carregaram com sucesso.
36.6. O sistema limitou a transferência com os drivers para-virtualizados.

Capítulo 34. Ferramentas de Solução de Problemas do Xen

Este capítulo cobre conceitos essenciais para assistí-lo em problemas de troubleshooting no Xen. Os tópicos do troubleshooting tratados neste capítulo incluem:
  • Ferramentas de troubleshooting para o Linux e virtualização
  • técnicas de troubleshooting para identificação de problemas
  • O local dos arquivos log e explicações de informações no log.
Este capítulo prentende fornecer, a você leitor, um conhecimento para identificar quais são os problemas com as tecnologias da virtualização. O troubleshooting (solução de problemas) leva prática e experiência, as quais são difíceis para aprender somente com este livro. Recomendamos que você experimente e teste a virtualização no Red Hat Enterprise Linux para desenvolver suas habilidades de troubleshooting.
If you cannot find the answer in this document there may be an answer online from the virtualization community. Refer to Seção A.1, “Recursos Online” for a list of Linux virtualization websites.

34.1. Depurando e Solucionando Problemas (Troubleshooting) do Xen

Esta seção sumariza os aplicativos do Administrador de Sistemas, os utilitários de rede, e as Ferramentas de Depuração. Você pode empregar estas Ferramentas de Administrador de Sistema padrão e registros para assistí-lo na solução de problemas:
Comandos úteis e aplicativos para Solução de Problemas
xentop
xentop exibe informações em tempo real sobre o sistema host e os domínios do convidado.
xm
Usando o dmesg e log.
  • vmstat
  • iostat
  • lsof
Os comandos iostat, mpstat e sar são todos fornecidos pelo pacote sysstat.
Você pode empregar estas Ferramentas de Depuração Avançada e registros para assistí-lo na solução de problemas:
  • XenOprofile
  • systemtap
  • crash
  • sysrq
  • sysrq t
  • sysrq w
Estas Ferramentas de Rede podem assistí-lo na solução de problemas de rede de virtualização:
  • ifconfig
  • tcpdump
    The tcpdump command 'sniffs' network packets. tcpdump is useful for finding network abnormalities and problems with network authentication. There is a graphical version of tcpdump named wireshark.
  • brctl
    brctl é uma ferramenta de rede que inspeciona e ajusta a configuração da ponte ethernet no kernel de Virtualização linux. Você precisa ter acesso root antes de realizar estes exemplos de comandos:comandos:
    # brctl show 
    
    bridge-name    bridge-id          STP  enabled  interfaces  
    -----------------------------------------------------------------------------
    xenbr0             8000.feffffff       no        vif13.0
    xenbr1             8000.ffffefff       yes       pddummy0
    xenbr2             8000.ffffffef       no        vif0.0
    
    # brctl showmacs xenbr0
    
    port-no           mac-addr                  local?       aging timer
    
    1                 fe:ff:ff:ff:ff:           yes            0.00
    2                 fe:ff:ff:fe:ff:           yes            0.00
    
    
    # brctl showstp xenbr0
    xenbr0 
    bridge-id              8000.fefffffffff
    designated-root        8000.fefffffffff
    root-port              0                   path-cost             0
    max-age                20.00               bridge-max-age        20.00
    hello-time             2.00                bridge-hello-time     2.00
    forward-delay          0.00                bridge-forward-delay  0.00
    aging-time            300.01
    hello-timer            1.43                tcn-timer             0.00
    topology-change-timer  0.00                gc-timer              0.02
    
Abaixo segue uma lista de alguns comandos úteis para solucionar problemas de virtualização no Red Hat Enterprise Linux 5. Todas as utilidades mencionadas podem ser encontradas nos repositórios do Red Hat Enterprise Linux 5.
  • strace é um comando que rastreia chamadas de sistemas e eventos recebidos e usados por outro processo.
  • vncviewer: connect to a VNC server running on your server or a virtual machine. Install vncviewer using the yum install vnc command.
  • vncserver: inicie um desktop remoto em seu servidor. Fornece a habilidade de executar interfaces de usuário gráfico, tais como virt-manager via sessão remota. Instale o vncserver usando o comando yum install vnc-server.

34.2. Visão Geral de Arquivo de Registro

When deploying Red Hat Enterprise Linux 5 with Virtualization into your network infrastructure, the host's Virtualization software uses many specific directories for important configuration, log files, and other utilities. All the Xen logs files are standard ASCII files, and accessible with a text editor:
  • O diretório de configuração do Xen é /etc/xen/. Este diretório contém o daemon xend e outros arquivos de configuração do convidado virtual. Os arquivos de script da rede também se econtram aqui no subdiretório /scripts .
  • Todos os arquivos de log do Xen são armazenados no diretório /var/log/xen.
  • O diretório padrão para todas as imagens baseadas em arquivo é o /var/lib/libvirt/images .
  • As informações do kernel do Xen são armazenadas no diretório /proc/xen/.

34.3. Descrições de Arquivo de Registro

O Xen apresenta o daemon xend e o processo qemu-dm , dois utilitários que escrevem os arquivos de registros múltiplos para o diretório /var/log/xen/ :
  • O xend.log é o arquivo de registro que contém todos os dados coletados pelo daemon xend, seja ele um evento de sistema normal ou uma ação iniciada por operador. Todas as operações de máquina virtual (tais como, criar, fechar, destruir, etc.) aparecem aqui. O xend.log é geralmente o primeiro lugar que se deve consultar quando você determinar quais os problemas de evento ou desempenho. Ele contém entradas detalhadas e condições de mensagens de erro.
  • xend-debug.log é o arquivo de registro que contém registro de erros de eventos do xend e subsistemas de Virtualização (tais como, buffer de quadros, scripts de Python, etc.)
  • xen-hotplug-log é o arquivo de registro que contém dados dos eventos de hotplug. Se um dispositivo ou um script de rede não se conectar, o evento aparecerá aqui.
  • qemu-dm.[PID].log é um arquivo de registro criado pelo processo qemu-dm para cada convidado virtualizado. Ao usar o arquivo de registro, você deve recuperar o processo PID qemu-dm dado, usando o comando ps para examinar os argumentos do processo para isolar o processo qemu-dm na máquina virtual. Note que você deve substituir o símbolo [PID] com o processo PID atual qemu-dm.
Se você se deparar com qualquer erro no Gestor da Máquina Virtual, revise os dados gerados no arquivo virt-manager.log, que reside no diretório /.virt-manager . Note que todas as vezes que você iniciar um Gestor de Máquina Virtual, ele sobrescreverá o conteúdo do arquivo de registro existente.

34.4. Localizações de Diretórios Importantes

Existem utilitários adicionais e arquivos de registros que você deve se lembrar ao determinar erros e solucionar problemas nos ambientes com o Xen:
  • As imagens de convidados virtualizados se encontram no diretório /var/lib/libvirt/images .
  • Ao reiniciar o daemon xend , ele atualiza o xend-database que se encontra no diretório /var/lib/xen/xend-db .
  • O despejo da máquina virtual (que você realiza com o comandxm dump-core ) se encontra no diretório /var/lib/xen/dumps .
  • O diretório /etc/xen contém os arquivos de configuração que você usa para gerenciar os recursos de sistema. O arquivo de configuração do daemon xend é o /etc/xen/xend-config.sxp. Este arquivo pode ser editado para implementar as mudanças de todo o sistema e configurar os textos explicativos da rede. No entanto, os arquivo de edição manuais na pasta /etc/xen/ não são recomendados.
  • O comando proc é outro recurso que lhe possibilitareunir informações do sistema. Estas entradas proc se encontram no diretório /proc/xen:
/proc/xen/capabilities
/proc/xen/balloon
/proc/xen/xenbus/

34.5. Solucionando Problemas com os Registros

When encountering installation issues with Xen, refer to the host system's two logs to assist with troubleshooting. The xend.log file contains the same basic information as when you run the xm log command. This log is found in the /var/log/ directory. Here is an example log entry for when you create a domain running a kernel:
[2006-12-27 02:23:02 xend] ERROR (SrvBase: 163) op=create: Error creating domain: (0, 'Error')
Traceback (most recent call list)
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvBase.py" line 107 in_perform val = op_method (op,req)
File
"/usr/lib/python2.4/site-packages/xen/xend/server/SrvDomainDir.py line 71 in op_create
raise XendError ("Error creating domain: " + str(ex))
XendError: Error creating domain: (0, 'Error')
O outro arquivo de registro, xend-debug.log , é bastante útil para os administradores de sistema, pois ele contém mais informações detalhadas do que o xend.log . Seguem aqui os mesmos dados de erro para o mesmo problema de criação do domínio kernel:
ERROR: Will only load images built for Xen v3.0
ERROR: Actually saw: GUEST_OS=netbsd, GUEST_VER=2.0, XEN_VER=2.0; LOADER=generic, BSD_SYMTAB'
ERROR: Error constructing guest OS
Quando você precisar da assistência ao consumidor e contatar o técnico de suporte, sempre inclua uma cópia dos dois arquivos de registro.

34.6. Solucionando Problemas com o Console em Serial

The serial console is helpful in troubleshooting difficult problems. If the Virtualization kernel crashes and the hypervisor generates an error, there is no way to track the error on a local host. However, the serial console allows you to capture it on a remote host. You must configure the host to output data to the serial console. Then you must configure the remote host to capture the data. To do this, you must modify these options in the grub.conf file to enable a 38400-bps serial console on com1 /dev/ttyS0:
title Red Hat Enterprise Linux (2.6.18-8.2080_xen0)
	root (hd0,2)
	kernel /xen.gz-2.6.18-8.el5 com1=38400,8n1 
	module /vmlinuz-2.618-8.el5xen ro root=LABEL=/rhgb quiet console=xvc console=tty xencons=xvc 	
	module /initrd-2.6.18-8.el5xen.img
O sync_console pode ajudar a determinar um problema que trava com a saída do console hypervisor assíncrono, e o "pnpacpi=off" soluciona um problema que quebra a entrada no console serial. Os parâmetros "console=ttyS0" e "console=tty" significam que os erros do kernel se autenticam com o console normal VGA assim como com o console serial. Depois disso, você pode instalar e configurar o ttywatch para capturar os dados em um convidado remoto conectado por um cabo de modem nulo padrão. Por exemplo, no convidado remoto você pode digitar:

O Solucionador de problemas de console serial Itanium

To access the hypervisor via a serial console on the Itanium® architecture you must enable the console in ELILO. For more information on configuring ELILO, refer to Capítulo 29, Configurando ELILO.
ttywatch --name myhost --port /dev/ttyS0
Isto canaliza a saída desde /dev/ttyS0 para dentro do arquivo /var/log/ttywatch/myhost.log .

34.7. Acesso de Console de convidado Para-virtualizado.

Para-virtualized guest operating systems automatically has a virtual text console configured to transmit data to the host operating system. Connect to a guest's virtual console with the following command:
# virsh console [guest name, ID or UUID]
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.8. Acesso ao Console de convidado com Virtualização Completa.

Fully virtualized guest operating systems automatically has a text console configured for use, but the difference is the kernel guest is not configured. To enable the guest virtual serial console to work with the Full Virtualized guest, you must modify the guest's grub.conf file, and include the 'console =ttyS0 console=tty0' parameter. This ensures that the kernel messages are sent to the virtual serial console (and the normal graphical console). To use the guest's serial console, you must edit the libvirt configuration file configuration file. On the host, access the serial console with the following command:
# virsh console
You can also use virt-manager to display the virtual text console. In the guest console window, select Serial Console from the View menu.

34.9. Problemas Comuns do Xen

Ao tentar iniciar o serviço xend e nada acontece. Você digita virsh list e recebe a seguinte resposta:
Error: Error connecting to xend: Connection refused. Is xend running?
Você tenta executar o xend start para iniciar manualmente e recebe mais erros:
Error: Could not obtain handle on privileged command interfaces (2 = No such file or directory)
Traceback (most recent call last:)
File "/usr/sbin/xend/", line 33 in ?
from xen.xend.server. import SrvDaemon
File "/usr/lib/python2.4/site-packages/xen/xend/server/SrvDaemon.py" , line 26 in ?
from xen.xend import XendDomain
File "/usr//lib/python2.4/site-packages/xen/xend/XendDomain.py" , line 33, in ?
		
from xen.xend import XendDomainInfo
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line37, in ?
import images
File "/usr/lib/python2.4/site-packages/xen/xend/image.py" , line30, in ?
xc = xen.lowlevel.xc.xc ()
RuntimeError: (2, 'No such file or directory' )
O mais provável que possa estar acontecendo aqui é que você reiniciou seu host em um kernel que não era um kernel kernel-xen. Para corrigir isto, você deve selecionar o kernel kernel-xen em tempo de reinicialização (ou ajuste o kernel kernel-xen como padrão em seu arquivo grub.conf ).

34.10. Erros de Criação de Convidados

Quando você tentar criar um convidado, você irá receber uma mensagem de erro "Invalid argument". Isto geralmente significa que a imagem do kernel que você está tentando iniciar é incompatível com o hypervisor. Um exemplo disto seria se você estivesse tentando executar um kernel não-PAE FC5 em um hypervisor PAE FC6.
Você realiza uma atualização de yum e recebe um novo kernel, o kernel padrão grub.conf retorna para um kernel de metal simples ao invés do kernel de Virtualização.
To correct this problem you must modify the default kernel RPM that resides in the /etc/sysconfig/kernel/ directory. You must ensure that kernel-xen parameter is set as the default option in your grub.conf file.

34.11. Solucionando Problemas com o Console Serial

Os kernels do Linux podem apresentar informações para portas seriais. Isto é útil para depurar pânico de kernel e problemas com hardware com dispositivos de vídeo ou servidores sem cabeçalho. As sub-seções nesta seção, trata sobre a configuração de resultado de console em série para máquinas rodando nos kernels de virtualização do Red Hat Enterprise Linux e seus convidados virtualizados.

34.11.1. Resultado de Console Serial para Xen

By default, the serial console for the Xen hypervisor is disabled and no data is output from serial ports.
Para receber informações do kernel em um porta em série, modifique o arquivo /boot/grub/grub.conf, configurando os parâmetros de dispositivos em série adequados.
Se seu console serial estiver em com1, modifique o /boot/grub/grub.conf inserindo as linhas com1=115200,8n1, console=tty0 e console=ttyS0,115200 onde demonstrado.
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com1=115200,8n1
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
				console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
Se seu console serial estiver em com2, modifique o /boot/grub/grub.conf inserindo as linhascom2=115200,8n1 console=com2L, console=tty0 e console=ttyS0,115200 onde demonstrado.
title Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
	root (hd0, 8)
	kernel /boot/xen.gz-2.6.18-92.el5 com2=115200,8n1 console=com2L
	module /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=tty0
	console=ttyS0,115200
	module /boot/initrd-2.6.18-92.el5xen.img
Salve as mudanças e reinicialize o host. O hypervisor apresenta os dados em série no serial (com1, com2 e assim por diante) que você selecionou no passo anterior.
Observe o exemplo usando a porta com2 o parâmetroconsole=ttyS0 na linha vmlinuz usada. O comportamento de toda porta que esteja sendo usada como console=ttyS0 é não padronizar o comportamento do Linux e especificar para o ambiente do Xen.

34.11.2. O resultado do console serial do Xen a partir dos convidados para-virtualizados.

Esta seção descreve como configurar um console serial virtualizado para convidados para-virtualizados do Red Hat Enterprise Linux.
O resultado do console em série dos convidados para-virtualizados pode ser recebido usando o "virsh console" ou na janela "Serial Console" do virt-manager. Defina o console em série virtual usando este procedimento:
  1. Registre-se em seu convidado para-virtualizado.
  2. Edite /boot/grub/grub.conf como se segue:
    Red Hat Enterprise Linux 5 i386 Xen (2.6.18-92.el5xen)
    	root (hd0, 0) kernel /boot/vmlinuz-2.6.18-92.el5xen ro root=LABEL=VG_i386 console=xvc0 
    	initrd /boot/initrd-2.6.18-92.el5xen.img
    
  3. Reinicialize o convidado para-virtualizado.
Você agora deve receber mensagens do kernel no virt-manager "Serial Console" e "virsh console".
Registrando o resultado do console serial do domínio para-virtualizado.
O daemon do Xen (xend) pode ser configurado para registrar o resultado a partir dos consoles seriais de convidados para-virtualizados.
Para configurar xend edite /etc/sysconfig/xend. Mude a entrada:
# Log all guest console output (cf xm console)
#XENCONSOLED_LOG_GUESTS=no
to:
# Log all guest console output (cf xm console)
XENCONSOLED_LOG_GUESTS=yes
Reinicialize o host para ativar o registro do resultado do console serial do convidado.
Os registros a partir de consoles seriais convidados estã armazenados no arquivo /var/log/xen/console

34.11.3. Resultado de console serial a partir dos convidados totalmente virtualizados.

Esta seção trata-se de como ativar um registro do console serial para convidados totalmente virtualizados
Resultado de console serial de convidado totalmente virtualizado pode ser visualizado com o comando "virsh console".
Tenha em mente que os consoles seriais convidados totalmente virtualizados possuem algumas limitações. As limitações atuais incluem:
  • resultado de registro com o xend não estã disponível
  • dados de resultado pode ser solto e mesclado.
A porta serial é chamada de ttyS0 no Linux ou COM1 no Windows.
Você precisa configurar o sistema operacional virtualizado para apresentar informações para a porta serial virtual.
Para apresentar informações de kernel de um convidado do Linux totalmente virtualizado no domain, modifique o arquivo /boot/grub/grub.conf inserindo a linha "console=tty0 console=ttys0,115200".
title Red Hat Enterprise Linux Server (2.6.18-92.el5)
	root (hd0,0)
	kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/volgroup00/logvol00
	console=tty0 console=ttys0,115200
	initrd /initrd-2.6.18-92.el5.img
Reinicialize o convidado
Visualize as mensagens do console serial usando o comando "virsh console"

Nota

Mensagens de console serial de domínios totalmente virtualizados não são registrados no /var/log/xen/console como são para os convidados para-virtualizados.

34.12. Arquivos de Configuração do Xen

When you create guests with the virt-manager or virt-install tools on Red Hat Enterprise Linux 5, the guests configuration files are created automatically in the /etc/xen directory.

Warning

Red Hat advises users not to manually edit Xen configuration files. Xen configuration files have limited error checking and many unsupported variables. Editing Xen configuration files may damage your guests, make guests unbootable or cause data loss.
The example below is a typical a para-virtualized guest configuration file:
name = "rhel5vm01"
memory = "2048"
disk = ['tap:aio:/var/lib/libvirt/images/rhel5vm01.dsk,xvda,w',]
vif = ["type=ieomu, mac=00:16:3e:09:f0:12 bridge=xenbr0', 
"type=ieomu, mac=00:16:3e:09:f0:13 ]
vnc = 1
vncunused = 1
uuid = "302bd9ce-4f60-fc67-9e40-7a77d9b4e1ed"
bootloader = "/usr/bin/pygrub"
vcpus=2
on_reboot = "restart"
on_crash = "restart"
Note que o serial="pty" é o padrão para o arquivo de configuração. Este arquivo de configuração é para um convidado totalmente virtualizado:
name = "rhel5u5-86_64"
builder = "hvm"
memory = 500
disk = ['/var/lib/libvirt/images/rhel5u5-x86_64.dsk.hda,w']
vif = [ 'type=ioemu, mac=00:16:3e:09:f0:12, bridge=xenbr0', 'type=ieomu, mac=00:16:3e:09:f0:13, bridge=xenbr1']
uuid = "b10372f9-91d7-ao5f-12ff-372100c99af5'
device_model = "/usr/lib64/xen/bin/qemu-dm"
kernel = "/usr/lib/xen/boot/hvmloader/"
vnc = 1
vncunused = 1
apic = 1
acpi = 1
pae = 1
vcpus =1
serial ="pty" # enable serial console
on_boot = 'restart'

Arquivos de Configuração do Xen

A edição arquivos de configuração do Xen configuration files não é suportada. Use o virsh dumpxml e virsh create (ou virsh edit) para editar os arquivos de configuração do libvirt (baseado em xml) os quais possuem erro de verificação e segurança.

34.13. Interpretando Mensagens de Erro do Xen

Suponha que você receba a seguinte mensagem de erro:
failed domain creation due to memory shortage, unable to balloon domain0
Um domínio pode falhar se não existir RAM suficiente disponível. O Domínio0 não esvazia o suficiente para oferecer espaço para o convidado recentemente criado. Você pode consultar o arquivo xend.log para este erro:
[2006-12-21] 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 Kib free; 0 to scrub; need 1048576; retries: 20
[2006-12-21] 20:33:31 xend. XendDomainInfo 3198] ERROR (XendDomainInfo: 202
Domain construction failed
Você pode observar a quantidade de memória usada pelo domínio0, usando o comando xm list Domain0 . Se o dom0 não for esvaziado, você pode usar o comando virsh setmem dom0 NewMemSize para checar a memória.
Suponha que você receba a seguinte mensagem de erro:
wrong kernel image: non-PAE kernel on a PAE
Esta mensagem indica que você está tentando rodar uma imagem de kernel de convidado sem suporte em seu Hypervisor. Isto acontece quando você tenta inicializar um kernel de convidado para-virtual de não- PAE em um host do Red Hat Enterprise Linux 5. O pacote do kernel-xen da Red Hat suporta somente kernel convidados com arquiteturas PAE e 64bit.
Digite este comando:
# xm create -c va-base

Using config file "va-base"
Error: (22, 'invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERRORs
(XendDomainInfo:202) Domain construction failed

Traceback (most recent call last)
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 195 in create vm.initDomain()
File " /usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", line 1363 in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1449]
XendDlomainInfo.destroy: domain=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XenDomainInfo: 1457]
XendDlomainInfo.destroy:Domain(1)
Se você precisar rodar um kernel de 32bit/não-PAE, você terá que rodar seu convidado como uma máquina virtual completamente virtualizada. Para convidados para-virtualizados, se você precisar rodar um convidado PAE de 32bit, você precisará de um hypervisor PAE de 32 bit. Para convidados para-virtualizados, se você precisar rodar um convidado PAE de 64bit, você precisará de um hypervisor PAE de 64 bit. Para convidados completamente virtualizados, você deve rodar um convidado de 64bit com um hypervisor de 64bit. O hypervisor de 32bit que vem com o RHEL 5 i686 suporta a execução de 32bit PAE para-virtualizado e convidado OSes de 32bit totalmente virtualizado. O hypervisor 64bit somente suporta convidados para-virtualizados de 64bits.
Isto acontece quando você muda o convidado HVM totalmente virtualizado para o sistema Red Hat Enterprise Linux 5. Seu convidado pode falhar na inicialização e você verá um erro na tela do console. Verifique a entrada PAE em seu arquivo de configuração e assegure-se de que pae=1. Você deve usar uma distribuição 32bit.
Suponha que você receba a seguinte mensagem de erro:
Unable to open a connection to the Xen hypervisor or daemon
Isto acontece quando um aplicativo vir-gestor falha ao lançar. Este erro ocorre quando não existe entrada de máquina local no arquivo de configuração /etc/hosts . Verifique no arquivo se a entrada do localhost está habilitado. Segue aqui um exemplo de uma entrada de máquina local incorreta:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
Segue aqui um exemplo de uma entrada de máquina local correta:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
localhost.localdomain. localhost
Suponha que você receba o seguinte erro (no xen-xend.log file ):
Bridge xenbr1 does not exist!
This happens when the guest's bridge is incorrectly configured and this forces the Xen hotplug scripts to timeout. If you move configuration files between hosts, you must ensure that you update the guest configuration files to reflect network topology and configuration modifications. When you attempt to start a guest that has an incorrect or non-existent Xen bridge configuration, you will receive the following errors:
# xm create mySQL01

Using config file " mySQL01"
Going to boot Red Hat Enterprise Linux Server (2.6.18.-1.2747 .el5xen)
kernel: /vmlinuz-2.6.18-12747.el5xen
initrd: /initrd-2.6.18-1.2747.el5xen.img
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
Além disso, o xend.log exibe os seguintes erros:
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:143) Waiting for devices vif
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:149) Waiting for 0
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status

[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=2
[2006-11-14 15:08:09 xend.XendDomainInfo 3875] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(2)
[2006-11-14 15:07:08 xend 3875] DEBUG (DevController:464) hotplugStatusCallback

/local/domain/0/backend/vif/2/0/hotplug-status
To resolve this problem, open the guest's configuration file found in the /etc/xen directory. For example, editing the guest mySQL01
# vim /etc/xen/mySQL01
Locate the vif entry. Assuming you are using xenbr0 as the default bridge, the proper entry should resemble the following:
# vif = ['mac=00:16:3e:49:1d:11, bridge=xenbr0',]
Suponha que você receba estes erros de depreciação de phyton:
# xm shutdown win2k3xen12
# xm create win2k3xen12

Using config file "win2k3xen12".

/usr/lib64/python2.4/site-packages/xenxm/opts.py:520: Deprecation Warning:
Non ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details

execfile (defconfig, globs, locs,)
Error: invalid syntax 9win2k3xen12, line1)
Python gera estas mensagens no caso de um arquivo de configuração inválido (ou incorreto). Para resolver este problema, você deve modificar o arquivo de configuração incorreto, ou você pode gerar um novo.

34.14. O layout dos diretórios do log

A estrutura de diretório básica no ambiente do Red Hat Enterprise Linux 5 Virtualização, segue abaixo:
O diretório /etc/xen/ contém
  • Arquivos de configuração usado pelo daemon xend.
  • o diretório do scripts o qual contém o scripts para a rede de Virtualização.
/var/log/xen/
  • diretório mantendo todos os Xen relacionados aos arquivos log
/var/lib/libvirt/images/
  • O diretório padrão para arquivos de imagem de máquinas virtuais.
  • Se você estiver usando um diretório diferente para suas imagens de máquina virtual, tenha certeza de que você adicinou o diretório em sua política do SELinux e rotule-o novamente antes de iniciar a instalação.
/proc/xen/
  • Nas informações relacionadas ao Xen no sistema de arquivos /proc.

Capítulo 35. Troubleshooting

Este capítulo se refere à problemas comuns e soluções com a virtualização do Red Hat Enterprise Linux.

35.1. Identificando armazenamento e partições disponíveis

Verifique se o driver do bloco foi carregado e se os dispositivos e partições estão disponíveis para o convidado. Isto pode ser feito executando "cat /proc/partitions" como segue abaixo.
# cat /proc/partitions
major minor  #blocks   name 
 202    16  104857600  xvdb
   3     0    8175688  hda

35.2. Após inicializar os convidados baseados em Xen, o console trava

Occasionally, a Xen guest's console freezes when the guest boots. The console still displays messages but the user cannot log in.
Para reparar este problema, adicione a seguinte linha ao arquivo /etc/inittab :
1:12345:respawn:/sbin/mingetty xvc0
Após salvar o arquivo, reinicialize. A sessão do console deve agora ser interativa como esperado.

35.3. Os dispositivos de Ethernet virtualizados não são encontrados pelas ferramentas de rede.

As ferramentas de rede não conseguem identificar a placa de rede Xen Virtual Ethernet dentro do sistema operacional convidado. Verifique isto executando o seuinte (para Red Hat Enterprise Linux 4 e Red Hat Enterprise Linux 5):
cat /etc/modprobe.conf
Ou (para Red Hat Enterprise Linux 3):
cat /etc/modules.conf
O resultado deve conter uma linha e uma linha semelhante para cada interface adicional.
alias eth0 xen-vnif
Para reparar este problema você precisará adicionar as linhas de alias (por exemplo, o alias eth0 xen-vnif) para todas as interfaces para-virtualizadas para o convidado.

35.4. Erros de Dispositivo de Loop

Se você usar as imagens de convidado baseado em arquivo, você pode precisar aumentar o número dos dispositivos de loop configurado. A configuração padrão permite até oito dispositivos de loop ativos. Se você precisar de mais de oito convidados baseados em arquivo ou dispositivos de loop, o número de dispositivos de loop configurado pode ser ajustado em /etc/modprobe.conf. Edite /etc/modprobe.conf e adicione a seguinte linha:
                options loop max_loop=64
Este exemplo usa o número 64, mas você pode especificar outro número para definir o valor máximo do loop. Você também pode ter que implementar os convidados de dispositivo de loop com back up em seu sistema. Para empregar os convidados de dispositivo de loop com backup para um convidado para-virtualizado, use os comandos phy: block device ou tap:aio. Para empregar os convidados de dispositivo de loop com backup em um sistema totalmente virtualizado, use os comandosphy: device ou file: file .

35.5. Criação de domínio falhou, devido à falta de memória

This may cause a domain to fail to start. The reason for this is there is not enough memory available or dom0 has not ballooned down enough to provide space for a recently created or started guest. In your /var/log/xen/xend.log, an example error message indicating this has occurred:
[2006-11-21 20:33:31 xend 3198] DEBUG (balloon:133) Balloon: 558432 KiB free;
	0 to scrub; need 1048576; retries: 20.
[2006-11-21 20:33:52 xend.XendDomainInfo 3198] ERROR (XendDomainInfo:202) Domain construction failed
You can verify the amount of memory currently used by dom0 with the command “xm list Domain-0”. If dom0 is not ballooned down you can use the command “xm mem-set Domain-0 NewMemSize” where NewMemSize should be a smaller value.

35.6. Falha de Imagem de Kernel errada

Convidados para-virtualizados não podem usar o kernel do kernel-xen. Use somente o kernel padrão para os convidados para-virtualizados.
Attempting to boot any kernel other than the Xen kernel as a para-virtualized guest results in the following error message:
# xm create testVM
Using config file "./testVM".
Going to boot Red Hat Enterprise Linux Server (2.6.18-1.2839.el5)
kernel: /vmlinuz-2.6.18-1.2839.el5
initrd: /initrd-2.6.18-1.2839.el5.img
Error: (22, 'Invalid argument')
In the above error you can see that the kernel line shows that the system is trying to boot a non kernel-xen kernel. The correct entry in the example is ”kernel: /vmlinuz-2.6.18-1.2839.el5xen”.
A solução é verificar que você realmente instalou um kernel-xen em seu convidado e é o kernel padrão para iniciar em seu arquivo de configuração do /etc/grub.conf.
Caso você possua o kernel-xen instalado em seu convidado, você pode iniciar seu convidado:
xm create -c GuestName
Where GuestName is the name of the guest. The previous command will present you with the GRUB boot loader screen and allow you to select the kernel to boot. You will have to choose the kernel-xen kernel to boot. Once the guest has completed the boot process you can log into the guest and edit /etc/grub.conf to change the default boot kernel to your kernel-xen. Simply change the line “default=X” (where X is a number starting at '0') to correspond to the entry with your kernel-xen line. The numbering starts at '0' so if your kernel-xen entry is the second entry you would enter '1' as the default,for example “default=1”.

35.7. Falha de imagem de kernel errada - Kernel não PAE em uma plataforma PAE

If you to boot a non-PAE kernel, para-virtualized guest the error message below will display. It indicates you are trying to run a guest kernel on your Hypervisor which at this time is not supported. The Xen hypervisor presently only supports PAE and 64 bit para-virtualized guest kernels.
# xm create -c va-base 
Using config file "va-base".
Error: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] ERROR (XendDomainInfo:202) Domain construction failed
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 195, in  create vm.initDomain()
File "/usr/lib/python2.4/site-packages/xen/xend/XendDomainInfo.py", 
	line 1363, in initDomain raise VmError(str(exn))
VmError: (22, 'Invalid argument')
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1449) XendDomainInfo.destroy: domid=1
[2006-12-14 14:55:46 xend.XendDomainInfo 3874] DEBUG (XendDomainInfo:1457) XendDomainInfo.destroyDomain(1)
If you need to run a 32 bit or non-PAE kernel you will need to run your guest as a fully-virtualized virtual machine. The rules for hypervisor compatibility are:
  • convidados para-virtualizados devem coincidir com o tipo de arquitetura de seu hypervisor. Para executar um convidado PAE de 32 bits, você precisa ter um hypervisor PAE com 32 bits.
  • Para executar um convidado de 64 bits, seu hypervisor deve ser uma versão de 64 bits também.
  • Em convidados totalmente virtualizados, seu hypervisor deve possuir 32 bits ou 64 bits para convidados de 32 bits. Você pode executar um convidado de 32 bits (PAE ou não PAE) ou hypervisor de 64 bits.
  • para executar um convidado totalmente virtualizado de 64 bits, seu hypervisor deve ser de 64 bits também.

35.8. O convidado de 64 bits totalmente virtualizado falha ao iniciar.

If you have moved the configuration file to a Red Hat Enterprise Linux 5 causing your fully-virtualized guest to fail to boot and present the error, Your CPU does not support long mode. Use a 32 bit distribution. This problem is caused by a missing or incorrect pae setting. Ensure you have an entry “pae=1” in your guest's configuration file.

35.9. Uma entrada de localhost faltando, faz com que o virt-manager falhe

O aplicativo virt-manager pode falhar ao lançar e exibir um erro, tal como “Unable to open a connection to the Xen hypervisor/daemon”. Geralmente é causado por uma entrada de localhost faltando no arquivo /etc/hosts. Verifique se você realmente possui uma entrada localhost e se está falando do /etc/hosts e insira uma nova entrada para localhost se não estiver presente. Um /etc/hosts pode se parecer com o seguinte:
# Do not remove the following line, or various programs
# that require network functionality will fail.
localhost.localdomain localhost
A entrada correta deve se parecer com esta abaixo:
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1               localhost.localdomain localhost
localhost.localdomain localhost

35.10. Erro de microcódigo durante a inicialização do convidado

During the boot phase of your virtual machine you may see an error message similar to:
Applying Intel CPU microcode update: FATAL: Module microcode not found.
ERROR: Module microcode does not exist in /proc/modules
As the virtual machine is running on virtual CPUs there is no point updating the microcode. Disabling the microcode update for your virtual machines will stop this error:
/sbin/service microcode_ctl stop
/sbin/chkconfig --del microcode_ctl

35.11. Mensagem de aviso de depreciação do Python ao iniciar a máquina virtual

Algumas vezes, o Python gera uma mensagem como esta abaixo, estas são geralmente causadas por arquivo de configuração inválido ou incorreto. Um arquivo de configuração de caractéres não ascii, causará estes erros. A solução é corrigir o arquivo de configuração ou gerar um novo.
Outra causa é um arquivo de configuração incorreto em seu diretório de trabalho atual. O comando “xm create” irá se parecer com o diretório atual para um arquivo de configuração e depois em /etc/xen.
# xm shutdown win2k3xen12
# xm create win2k3xen12
Using config file "win2k3xen12".
/usr/lib64/python2.4/site-packages/xen/xm/opts.py:520: DeprecationWarning:
Non-ASCII character '\xc0' in file win2k3xen12 on line 1, but no encoding
declared; see http://www.python.org/peps/pep-0263.html for details
execfile(defconfig, globs, locs)
Error: invalid syntax (win2k3xen12, line 1)

35.12. Ativando as extensões de hardware de virtualização do Intel VT e AMD-V, no BIOS.

Esta seção descreve como identificar as extensões de virtualização do hardware e ativá-las em seu BIOS se estiverem desabilitadas.
As extensões da Intel VT podem ser desativadas no BIOS. Certos fabricantes de laptop desativaram as extensões da Intel VT por padrão em suas CPUs.
As extensões virtualização não pode ser desativada no BIOS para AMD-V.
The virtualization extensions are sometimes disabled in BIOS, usually by laptop manufacturers. Refer to Seção 35.12, “Ativando as extensões de hardware de virtualização do Intel VT e AMD-V, no BIOS.” for instructions on enabling disabled virtualization extensions.
Verifique se as extensões de virtualização estão ativadas no BIOS. As configurações de BIOS para a VT e AMD-V da Intel® Estão geralmente nos menus Chipset ou Processor. Os nomes dos menus podem variar deste guia, as configurações de extensão de virtualização podem ser encontradas em Security Settings ou em outros nomes de menu não padrão.
Procedimento 35.1. Ativando as extensões de virtualização em BIOS
  1. Reboot the computer and open the system's BIOS menu. This can usually be done by pressing the delete key, the F1 key or Alt and F4 keys depending on the system.
  2. Select Restore Defaults or Restore Optimized Defaults, and then select Save & Exit.
  3. Desligue a máquina e desconecte o fornecimento de energia.
  4. Enabling the virtualization extensions in BIOS

    Note: BIOS steps

    Many of the steps below may vary depending on your motherboard, processor type, chipset and OEM. Refer to your system's accompanying documentation for the correct information on configuring your system.
    1. Power on the machine and open the BIOS (as per Step 1).
    2. Open the Processor submenu The processor settings menu may be hidden in the Chipset, Advanced CPU Configuration or Northbridge.
    3. Enable Intel Virtualization Technology (also known as Intel VT) or AMD-V depending on the brand of the processor. The virtualization extensions may be labeled Virtualization Extensions, Vanderpool or various other names depending on the OEM and system BIOS.
    4. Enable Intel VTd or AMD IOMMU, if the options are available. Intel VTd and AMD IOMMU are used for PCI passthrough.
    5. Select Save & Exit.
  5. Desligue a máquina e desconecte o fornecimento de energia.
  6. Execute o comando cat /proc/cpuinfo | grep vmx svm. Se o comando apresentar um resultado como: as extensões de virtualização foram ativadas. Caso não seja apresentado nenhum resultado, seu sistema pode não possuir extensões de virtualização ou configurações de BIOS corretas ativadas.

35.13. Desempenho de rede de KVM

Por padrão as máquinas virtuais do KVM são recebem um Realtek 8139 virtual (rtl8139) NIC (controlador de interface de rede).
O NIC de rtl8139 virtualizado, funciona bem na maioria dos ambientes. No entanto, este dispositivo pode sofrer de problemas de degradação de desempenho em algumas redes, por exemplo, uma rede de Ethernet com 10 Gigabites.
Uma solução para este problema é ligar em um tipo diferente de NIC virtualizado. Por exemplo, Intel PRO/1000 (e1000) ou virtio (a unidade de rede para-virtualizada).
Para alterar para um driver e1000
  1. Feche o sistema operacional convidado.
  2. Edit the guest's configuration file with the virsh command (where GUEST is the guest's name):
    # virsh edit GUEST
    O comando virsh edit usa a shell $EDITOR variante para deerminar qual editor usar.
  3. Encontre a seção de interface de rede da configuração. Esta seção se parece com o fragmento abaixo:
    <interface type='network'>
      [output truncated]
      <model type='rtl8139' />
    </interface>
    
  4. Change the type attribute of the model element from 'rtl8139' to 'e1000'. This will change the driver from the rtl8139 driver to the e1000 driver.
    <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  5. Salve as mudanças e saia do editor de texto.
  6. Reinicie o sistema operacional convidado.
Como forma alternativa, você pode instalar novos convidados virtualizados com um driver de rede diferente. Isto pode ser necessário caso tenha dificuldade em instalar convidados na conexão de rede. Este método requer ao menos uma máquina virtual já criada (possivelmente instalada do CD ou DVD) para usar como modelo.
  1. Crie um modelo de XML de uma máquina virtual existente:
    # virsh dumpxml GUEST > /tmp/guest.xml
    
  2. Copie e edite um arquivo XML e atualize os campos únicos: nome de máquina virtual, UUID, imagem de disco, endereço de MAC, e qualquer outros parâmetros únicos. Observe que você pode remover a UUID e linhas de endereço MAC e virsh irão gerar um endereço MAC e UUID.
    # cp /tmp/guest.xml /tmp/new-guest.xml
    # vi /tmp/new-guest.xml
    
    Adicione uma linha de modelo na seção de interface de rede:
     <interface type='network'>
      [output truncated]
      <model type='e1000' />
    </interface>
    
  3. Crie uma nova máquina virtual:
    # virsh define /tmp/new-guest.xml
    # virsh start new-guest
    
O desempenho de rede deve ser melhor com o driver e1000 ou virtio. (BZ#517181)

Capítulo 36. Solucionando Problemas dos drivers para-virtualizados do Xen

Este capítulo lida com problemas que você pode se deparar nos hosts do Xen e convidados do Red Hat Enterprise Linux totalmente virtualizados, usando drivers para-virtualizados.

36.1. Arquivos de registro e diretórios da Tecnologia de Virtualização do Red Hat Enterprise Linux 5

/var/log/xen/
diretório onde se encontram todos os arquivos de registros gerados pelo daemon xend e processo qemu-dm .
xend.log
  • Este logfile é usado pelo xend para registrar qualquer evento gerado pelos eventos de sistemas normais ou eventos iniciados por um operador.
  • as operações da máquina virtual, tais como create, shutdown, destroy etc., são registradas neste logfile.
  • Geralmente este logfile será o primeiro local a ser produrado, caso aconteça algum problema. Em muitos casos, você poderá identificar a raíz da causa, copiando o logfile e revendo as entradas registradas logo antes da mensagem de erro atual.
xend-debug.log
  • Grava eventos de erro do xend e seus subsistemas (a partir do buffer de estruturas e scripts de Python).
xen-hotplug.log
  • Eventos de logs a partir de eventos hotplug
  • Neste arquivo, são registradas as notificações de eventos de dispositivos que não são conectados à internet ou pontes de rede que não estejam conectadas.
qemu-dm.PID.log
  • Este arquivo é criado pelo processo qemu-dm o qual é iniciado para cada convidado totalmente virtualizado.
  • O PID é substituído pelo PID do processo do do qemu-dm relacionado.
  • Você pode recuperar o PID para um dado processo qemu-dm usando o comando ps e ao ver os argumentos de processo você poderá identificar a máquina virtual ao qual o processo qemu-dm pertence.
If you are troubleshooting a problem with the virt-manager application you can also review the logfile generated by it. The logfile for virt-manager will be in a directory called .virt-manager in the user's home directory whom ran virt-manager. This directory will usually be ~/.virt-manager/virt-manager.

Nota

O logfile é sobrescrito todas as vezes que você iniciar o virt-manager. Se você estiver solucionando um problema com o virt-manager, lembre-se de salvar o logfile antes de reiniciar o virt-manager, depois que um erro ocorrer.
/var/lib/libvirt/images/
o diretório padrão para as imagens convidadas baseadas em arquivo.
/var/lib/xen/xend-db/
diretório onde se encontra o banco de dados do xend, o qual é gerado todas as vezes que o daemon é reiniciado.
/etc/xen/
Armazena um número de arquivos de configuração para o hipervisor do Xen.
  • /etc/xen/xend-config.sxp é a configuração principal para o daemon do xend. O arquivo xend-config.sxp ativa ou desativa migração e outros recursos não configurados pelo libvirt. Use as ferramentas do libvirt para todos os outros recursos.
/var/lib/xen/dump/
Mantém os despejos (dumps) gerados pelas máquinas virtuais ou ao usar o comando xm dump-core.
/proc/xen/
Armazena informações sobre xend-kernel nos seguintes arquivos:
  • /proc/xen/capabilities
  • /proc/xen/privcmd
  • /proc/xen/balloon
  • /proc/xen/xenbus
  • /proc/xen/xsd_port
  • /proc/xen/xsd_kva

36.2. O convidado para-virtualizado falha ao carregar em um sistema operacional convidado Red Hat Enterprise Linux 3.

O Red Hat Enterprise Linux 3 usa RPMs de kernel, os quais são específicos para arquitetura do processador e por causa disto, os drivers para-virtualizados podem falhar ao carregar se o driver para-virtualizado RPM não coincide com a arquitetura do kernel instalada.
When the para-virtualized driver modules are inserted, a long list of unresolved modules will be displayed. A shortened excerpt of the error can be seen below.
# insmod xen-platform-pci.o 
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
xen-platform-pci.o: unresolved symbol __ioremap_R9eac042a
xen-platform-pci.o: unresolved symbol flush_signals_R50973be2
xen-platform-pci.o: unresolved symbol pci_read_config_byte_R0e425a9e
xen-platform-pci.o: unresolved symbol __get_free_pages_R9016dd82
[...]
The solution is to use the correct RPM package for your hardware architecture for the para-virtualized drivers.

36.3. Uma mensagem de erro é exibida durante a instalação dos drivers para-virtualizados no Red Hat Enterprise Linux 3.

Se você instalar os drivers para-virtualizados em um kernel do Red Hat Enterprise Linux 3 antes do 2.4.21-52, poderá resultar na exibição de uma mensagem de erro, relatando os módulos que foram compilados com uma versão mais nova do que a do kernel em execução.
Esta mensagem, como esta abaixo, pode ser ignorada com segurança.
Warning: kernel-module version mismatch
xen-platform-pci.o was compiled for kernel version 2.4.21-52.EL
while this kernel is version 2.4.21-50.EL
Warning: loading xen-platform-pci.o will taint the kernel: forced load
See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Module xen-platform-pci loaded, with warnings
A parte importante da mensagem acima é a última linha que deve relatar o módulo que foi carregado com avisos.

36.4. Carregando manualmente os drivers para-virtualizados.

Se, por alguma razão, os drivers para-virtualizados falharem ao carregar automaticamente durante o processo de inicialização, você pode tentar carregá-los manualmente.
Isto irá permitir que em primeiro lugar você reconfigure a rede ou entidades de armazenamento ou identificar que estas falharam. Os passos abaixo devem carregar os módulos dos drivers para-virtualizados.
Primeiro, localize os módulos do driver para-virtualizado em seu sistema.
# cd /lib/modules/`uname -r`/
# find . -name 'xen_*.ko' -print
Tome nota do local e carregue os módulos manualmente. Substitua {LocationofPV-drivers} pelo local correto que você tomou nota do resultado de comandos acima.
# insmod \
/lib/modules/'uname -r'/{LocationofPV-drivers}/xen_platform_pci.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_balloon.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vnif.ko
# insmod /lib/modules/'uname -r'/{LocationofPV-drivers}/xen_vbd.ko

36.5. Verificando se os drivers para-virtualizados carregaram com sucesso.

Uma das primeiras tarefas que você precisa fazer é verificar se os drivers foram realmente carregados em seu sistema.
After the para-virtualized drivers have been installed and the guest has been rebooted you can verify that the drivers have loaded. First you should confirm the drivers have logged their loading into /var/log/messages
# grep -E "vif|vbd|xen" /var/log/messages
                    xen_mem: Initialising balloon driver
                    vif vif-0: 2 parsing device/vif/0/mac
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    vbd vbd-768: 19 xlvbd_add at /local/domain/0/backend/vbd/21/76
                    xen-vbd: registered block device major 202
You can also use the lsmod command to list the loaded para-virtualized drivers. It should output a list containing the xen_vnif, xen_vbd, xen_platform_pci and xen_balloon modules.
# lsmod|grep xen
xen_vbd                19168  1 
xen_vnif               28416  0 
xen_balloon            15256  1 xen_vnif
xen_platform_pci       98520  3 xen_vbd,xen_vnif,xen_balloon,[permanent]

36.6. O sistema limitou a transferência com os drivers para-virtualizados.

If network throughput is still limited even after installing the para-virtualized drivers and you have confirmed they are loaded correctly (refer to Seção 36.5, “Verificando se os drivers para-virtualizados carregaram com sucesso.”). To fix this problem, remove the 'type=ioemu' part of 'vif=' line in your guest's configuration file.

Glossary

Este glossário possui por intenção definir os termos usados neste Guia de Instalação.
Bare-metal
The term bare-metal refers to the underlying physical architecture of a computer. Running an operating system on bare-metal is another way of referring to running an unmodified version of the operating system on the physical hardware. Examples of operating systems running on bare metal are dom0 or a normally installed operating system.
dom0
Also known as the host or host operating system.
dom0 refers to the host instance of Red Hat Enterprise Linux running the Xen hypervisor. Domain0 facilitates virtualized devices and virtualization for the guest operating systems. Dom0 runs on and manages the physical hardware and resource allocation for itself and the guest operating systems.
Domains
domU and dom0 are both domains. A domain is a term for a guest or virtual machine on the Xen hypervisor. The term domains has a similar meaning to virtual machines and the two are technically interchangeable.
domU
domU refers to the guest operating systems which run on the host system (the dom0 domain).
Drivers para-virtualizados
Os drivers para-virtualizados são drivers de dispositivo que operam nos convidados Linux de virtualização completa. Estes drivers aumentam intensamente o desempenho da rede e I/O do dispositivo bloco para os convidados de virtualização completa.
Endereço MAC
O Endereço de Controle de Acesso de Mídia é o endereço hardware para o Controlador da Interface da Rede. No contexto de virtualização, os endereços MAC devem ser gerados para as interfaces de rede virtual com cada MAC no seu domínio local sendo único.
Hardware Virtual Machine
See Full virtualization.
Host
The host operating system, also known as dom0.
The host operating system environment runs the virtualization software for Fully Virtualized and Para virtualized guest systems.
Hypervisor
The hypervisor is the software layer that abstracts the hardware from the operating system permitting multiple operating systems to run on the same hardware. The hypervisor runs on a host operating system allowing other virtualized operating systems to run on the host's hardware.
The Kernel-based Virtual Machine (KVM) and Xen) hypervisors are provided with Red Hat Enterprise Linux 5.
I/O
Abreviação para input/output (entrada/saída) (pronunciado "ii-oou"). O termo I/O descreve qualquer programa, operação ou dispositivo que transfere os dados para/de um computador e um idspositivo periférico. Cada transferência é uma saída de um dispositivo e uma entrada a outro. Os dispositivos tais como teclados e mouses são de entrada apenas enquanto os dispositivos como impressoras são de saída apenas. Um CD-ROM gravável é tanto um dispositivo de entrada quanto de saída.
Itanium®
A arquitetura do processador Intel Itanium®.
Kernel SamePage Merging
O módulo Kernel SamePage Merging (KSM) é usado pelo hypervisor do KVM para permitir que convidados do KVM compartilhem de páginas de memória idênticas. As páginas compartilhadas são geralmente bibliotecas comuns ou outros dados de alto uso, idênticos. O KSM pode aumentar o desempenho de certos convidados, mantendo estas bibliotecas em cache por diversos convidados, assim como aumentando a densidade do convidado.
Kernel-based Virtual Machine
KVM (Kernel-based Virtual Machine) is a Full virtualization solution for Linux on AMD64 and Intel 64 hardware. VM is a Linux kernel module built for the standard Red Hat Enterprise Linux kernel. KVM can run multiple, unmodified virtualized guest Windows and Linux operating systems. KVM is a hypervisor which uses the libvirt virtualization tools (virt-manager and virsh).
O KVM é um conjunto de módulos do kernel do Linux que gerencia dispositivos, memória e gerenciamento de APIs para o próprio módulo do Hypervisor. Os convidados virtualizados são executados como processos do Linux e segmentos que são controlados por estes módulos.
LUN
Um Número de Unidade Lógica - Logical Unit Number (LUN) é um número determinado a uma unidade lógica (uma entidade de protocolo SCSI).
Máquinas Virtuais
Uma máquina virtual é uma implementação de software de uma máquina física ou uma linguagem de programação (por exemplo o Ambiente de Período de Execução Java ou LISP). As máquinas virtuais são sistemas operacionais rodando no hardware virtualizado.
Migração
Migração é o nome do processo de movimentação de um convidado virtualizado de um host a outro. A migração pode ser conduzida desativada (onde o convidado é suspenso e então movido) ou ativada (onde o convidado é movido sem a suspensão). Os convidados de virtualização completa, o convidado para-virtualizado Xen e os convidados de virtualização completa KVM podem ser todos migrados.
A migração é recurso principal como o software é completamente separado do hardware. A migração é útil para:
  • Balanceamento de carga - os convidados podem ser movidos aos hosts com uso baixo quando um host torna-se sobrecarregado.
  • Falha de hardware - quando os dispositivos hardware no host começam a falhar, os convidados podem ser alocados seguramente de forma que o host pode ser desligado e ajustado.
  • Economia de energia - os convidados podem ser redistribuídos a outros hosts e sistemas host desligados para economizar energia e cortar custos em períodos de baixo uso.
  • Migração geográfica - os convidados podem ser movidos a outra localização para baixa latência ou em circunstâncias sérias.
O armazenamento compartilhado e com rede é usado para armazenamento de imagens convidadas. Isto não é possível sem a migração de armazenamento compartilhado.
A migração desconectada suspende o convidado e move uma imagem da memória dos convidados ao host de destino. O guest é resumido no host de destino e a memória do host usada no host de fonte é salva.
O tempo que uma migração desconectada leva, dependerá da latência e largura de banda da rede. Um convidado com 2GB de memória deve levar diversos segundos num link de 1 Gbit Ethernet.
A live migration keeps the guest running on the source host and begins moving the memory without stopping the guest. All modified memory pages are monitored for changes and sent to the destination while the image is sent. The memory is updated with the changed pages. The process continues until the amount of pause time allowed for the guest equals the predicted time for the final few pages to be transfer. KVM estimates the time remaining and attempts to transfer the maximum amount of page files from the source to the destination until KVM predicts the amount of remaining pages can be transferred during a very brief time while the virtualized guest is paused. The registers are loaded on the new host and the guest is then resumed on the destination host. If the guest cannot be merged (which happens when guests are under extreme loads) the guest is paused and then an offline migration is started instead.
O período que uma migração desativada leva, depende da largura de banda e latência da rede assim como atividade no convidado. Caso o convidado estiver usando o I/O ou CPU de forma significante, a migração demorará mais.
Para-virtualização
Para-virtualization uses a special kernel, sometimes referred to as the Xen kernel or the kernel-xen package. Para-virtualized guest kernels are run concurrently on the host while using the host's libraries and devices. A para-virtualized installation can have complete access to all devices on the system which can be limited with security settings (SELinux and file controls). Para-virtualization is faster than full virtualization. Para-virtualization can effectively be used for load balancing, provisioning, security and consolidation advantages.
A partir do Fedora 9 não será mais necessário um kernel especial. Uma vez que este ajuste é aceito numa árvore Linux principal, todos os kernels Linux após aquela versão terão a para-virtualização ativada ou disponível.
Para-virtualização
See Para-virtualization.
PCI passthrough
KVM and Xen hypervisors support attaching PCI devices on the host system to virtualized guests. PCI passthrough allows guests to have exclusive access to PCI devices for a range of tasks. PCI passthrough allows PCI devices to appear and behave as if they were physically attached to the guest operating system.
phy device
The phy device parameter allows guest's to access physical disks. Physical disks includes:
  • LVM volumes (for example, /dev/VolGroup00/LogVol02),
  • disk partitions (for example, /dev/sda5), and
  • whole block devices (for example, /dev/sda).
Physical mode provides the best performance as the hypervisor bypasses extra layers of software on the host at the price of slightly less flexibility in managing the device.
Security Enhanced Linux
Abreviação para o Linux de Segurança Aprimorada, o SELinux usa os Módulos de Segurança Linux (LSM) no Linux kernel para fornecer uma variedade de privilégios mínimos solicitados para políticas de segurança.
Sistema convidado
Also known as guests, virtual machines, virtual servers or domU.
tap:aio
The tap:aio parameter sets the Xen hypervisor to use an advanced access mode designed for safety and performance. File-based, are accessed using a kernel thread and a user-space process. The tap:aio method respects guest flush requests which makes it safer than the file driver. The virtualization tools use tap:aio by default for accessing file-based guest disks on the Xen Hypervisor.
Universally Unique Identifier
Um Identificador Único Universal - Universally Unique Identifier (UUID) é um método de numeração padronizado para dispositivos, sistemas e alguns objetos de software em ambientes de computação distribuídos. Os tipos de UUIDs na virtualização incluem: identificadores de sistemas de arquivo ext2 e ext3, identificadores de dispositivo RAID, identificadores de dispositivo LUN e iSCSI, endereços MAC e identificadores de máquina virtual.
Virtualização
Virtualization is a broad computing term for running software, usually operating systems, concurrently and isolated from other programs on one system. Most existing implementations of virtualization use a hypervisor, a software layer on top of an operating system, to abstract hardware. The hypervisor allows multiple operating systems to run on the same physical system by giving the guest operating system virtualized hardware. There are various methods for virtualizing operating systems:
  • Hardware-assisted virtualization is the technique used for full virtualization with Xen and KVM.
  • Para-virtualization is a technique used by Xen to run Linux guests.
  • Virtualização ou simulação do software. A virtualização do software usa a tradução binária e outras técnicas de simulação para rodar sistemas operacionais não-modificados. A virtualização de software é mais lenta que a virtualização e para-virtualização de hardware assistida. A virtualização de software, em forma de QEMU, não é suportada pelo Red Hat Enterprise Linux.
Red Hat Enterprise Linux 5 supports hardware-assisted, full virtualization with the Xen and KVM hypervisors and software para-virtualization with the Xen hypervisor for hosting Red Hat Enterprise Linux guests.
Virtualização completa
Xen and KVM can use full virtualization. Full virtualization uses hardware features of the processor to provide total abstraction of the underlying physical system (bare metal) and create a new virtual machine in which the guest operating systems can run. No modifications are needed in the guest operating system. The guest operating system and any applications on the guest are not aware of the virtualized environment and run normally. Para-virtualization requires a modified version of the Linux operating system.
Virtualização completa
See Full virtualization.
Virtualized CPU
Um sistema possui um número de CPUs virtuais (VCPUs) relativos ao número de centros dos processadores físicos. O número de CPUs virtuais é finito e representa o número total de CPUs virtuais que podem ser determinados para as máquinas virtuais convidadas.
Xen
Red Hat Enterprise Linux supports the Xen hypervisor and the KVM hypervisor. Both hypervisors have different architectures and development approaches. The Xen hypervisor runs underneath a Red Hat Enterprise Linux operating system which acts as a host managing system resources and virtualization APIs. The host is sometimes referred to as dom0, or Domain0.

Recursos Adicionais

Para aprender mais sobre virtualização e sobre o Red Hat Enterprise Linux, consulte os seguintes recursos.

A.1. Recursos Online

  • http://www.cl.cam.ac.uk/research/srg/netos/xen/ O website do projeto do gerenciador de máquina de para-virtualização do Xen™ a partir do qual originou-se o pacote kernel-xen da Red Hat. O site mantém os binários do projeto Xen e código de fonte, e também contém informações, visão geral de arquitetura, documentação e links relacionados referentes ao Xen e suas tecnologias associadas.
  • O Website do Centro da Comunidade Xen
  • http://www.libvirt.org/ é o website oficial para o API de virtualização do libvirt.
  • http://virt-manager.et.redhat.com/ é o website do projeto para o Gestor de Máquina Virtual (virt-manager), o aplicativo gráfico para máquinas virtuais de gerenciamento.

A.2. Documentação instalada

  • /usr/share/doc/xen-<version-number>/ Este diretório é rico em informação sobre o hypervisor de para-virtualização Xen e ferramentas de gerenciamento associado, incluindo uma checagem em vários exemplos de configuração, informação harware-específico, e a documentação do usuário de Xen superior atual.
  • man virsh e /usr/share/doc/libvirt-<version-number>— Contém subcomandos e opções para a máquina virsh virtual de utilitários de gerenciamento assim como informações sobre a API da biblioteca de virtualização do libvirt.
  • /usr/share/doc/gnome-applet-vm-<version-number> — Documentação para o miniaplicativo de painel gráfico GNOME, que monitora e gerencia máquinas virtuais rodando no local.
  • /usr/share/doc/libvirt-python-<version-number> — Oferece detalhes sobre vinculações de Python para a biblioteca libvirt. O pacote libvirt-python permite que os desenvolvedores de python criem programas que façam uma interface com a biblioteca de gerenciamento de virtualização libvirt.
  • /usr/share/doc/python-virtinst-<version-number> — Oferece documentação no comando virt-install que ajuda no início das instalações do Fedora e do Red Hat Enterprise Linux referentes à distribuições dentro de máquinas virtuais.
  • /usr/share/doc/virt-manager-<version-number> — Oferece documentação no Gestor de Máquina Virtual, que oferece uma ferramenta gráfica para administrar máquinas virtuais.

Colofão

Este manual foi escrito no formato DocBook XML v4.3.
This book is based on the work of Jan Mark Holzer, Chris Curran and Scott Radvan.
Outros créditos de escrita vão para:
  • Don Dutile contribui na edição técnica da seção dos drivers para-virtualizados.
  • Barry Donahue contribui na edição técnica da seção dos drivers para-virtualizados.
  • Rick Ring contribui na edição técnica da Seção do Gerenciador da Máquina Virtual.
  • Michael Kearey contribui na edição técnica para as seções usando os arquivos de configuração XML com virsh e disquetes virtualizados.
  • Marco Grigull contribui com a edição técnica para a compatibilidade de software e seção de desempenho.
  • Eugene Teo contribui para a edição técnica do Gerenciamento de convidados com a seção virsh.
Publican, a ferramenta de publicação que produziu este livro, foi escrito por Jeffrey Fearn.
O Time de Localização da Red Hat consiste das seguintes pessoas:
  • Chinês Simplificado
    • Leah Wei Liu
  • Chinês Tradicional
    • Chester Cheng
    • Terry Chuang
  • Japonês
    • Kiyoto Hashida
  • Coreano
    • Eun-ju Kim
  • Francês
    • Sam Friedmann
  • Alemão
    • Hedda Peters
  • Italiano
    • Francesco Valente
  • Português Brasileiro
    • Glaucia de Freitas
    • Leticia de Lima
  • Espanhol
    • Angela Garcia
    • Gladys Guerrero
  • Russo
    • Yuliya Poyarkova