330 Virtualization

From Documentacao LPI
Jump to: navigation, search

Contents

330.1_Virtualization_Conccepts_and_Theory-Peso8

Objetivo do tópico:

Weight: 8

Description: Candidates should know and understand the general concepts, theory and terminology of Virtualization. This includes Xen, KVM and libvirt terminology. Key Knowledge Areas:

  Terminology
  Pros and Cons of Virtualization
  Variations of Virtual Machine Monitors
  Migration of Physical to Virtual Machines
  Migration of Virtual Machines between Host systems
  Cloud Computing

The following is a partial list of the used files, terms and utilities:

   Hypervisor
   Hardware Virtual Machine (HVM)
   Paravirtualization (PV)
   Container Virtualization
   Emulation and Simulation
   CPU flags
   /proc/cpuinfo
   Migration (P2V, V2V)
   IaaS, PaaS, SaaS

Terminology

  • Hypervisor

Hypervisor, também chamado de Virtual Machine Manager (VMM), é uma de muitas técnicas de virtualização por hardware, permitindo múltiplos sistemas operacionais, chamados guests, rodarem concorrentemente em um mesmo computador host. É chamado de hypervisor porque conceitualmente é um nível superior que um programa de supervisão. O hypervisor apresenta para os sistemas operacionais convidados uma plataforma operacional virtual e gerencia a execução dos sistemas operacionais convidados. Múltiplas instâncias de uma variedade de sistemas operacionais podem compartilhar o recurso de hardware virtualizado. Hypervisors são muito comumente instalados no hardware do servidor, com a função de executar sistemas operacionais convidados. Alguns exemplos de Hypervisors são: Xen, KVM.

  • HVM (HardwareVirtualMachine)

Hardware com suporte a virtualização (hardware-assisted virtualization) é um tipo de plataforma de virtualização que habilita uma eficiente virtualização completa (full virtualization) usando a ajuda de recursos de hardware compatível, principalmente do processador do host. Virtualização completa (full virtualization) é utilizada para simular um completo ambiente de hardware, ou maquina virtual, no qual um sistema operacional não modificado (usando as mesmas instruções configuradas na maquina host) executa em um isolamento completo. O hardware com suporte a virtualização (hardware-assisted virtualization) foi adicionado aos processadores x86 (Intel VT-x ou AMD-V) em 2006. Virtualização assistida por hardware também é conhecida como virtualização acelerada; Xen chama de hardware da máquina virtual (HVM).

  • PV(Paravirtualization)- Paravirtualização

Paravirtualização é uma tecnica de virtualização que apresenta uma interface de software para a maquina virtual similar mas não idêntica a do hardware.

    • A intenção da interface de software modificada é reduzir a parcela de tempo de execução do cliente gasto em operações que são substancialmente mais difíceis de serem executadas em um ambiente virtual em comparação com a realizada em um ambiente não virtualizado. A paravirtualização fornece "ganchos" especialmente definidos para permitir que o visitante 'realoque' estas tarefas sendo acolhidas pelo Host que reconhece essas tarefas, que seriam executados no domínio virtual (onde o desempenho de execução é pior). Uma plataforma paravirtualizada bem sucedida pode permitir que o monitor de máquina virtual (VMM) (realocando a execução de tarefas críticas da maquina virtual(Dominio virtual) para o host (Domínio Host)), reduza a degradação do desempenho geral da máquina em execução dentro do cliente(guest).
    • Com isso a paravirtualização requer que o sistema operacional do cliente(guest) seja portado para esta API. Os sistemas operacionais convencionais não suportam paravirtualização e não podem ser executados em um gerenciador de maquinas virtuais paravirtualizado, eles devem ser modificados para que suportem a paravirtualização. No caso do GNU/Linux, Kernels específicos adotando estas modificações são necessários. No entanto, mesmo nos casos em que o sistema operacional não pode ser modificado, ainda componentes podem estar disponíveis que permitem muitas das vantagens significativas de desempenho de virtualização; por exemplo, o projeto XenWindowsGplPv fornece um kit de drivers de dispositivo de paravirtualização, licenciado sob os termos da GPL, que se destinam a ser instalado em um cliente(Guest) Microsoft Windows em execução no hypervisor Xen. Outro exemplo é o conjunto de drivers Virtio que são instalados no Windows e Linux, permitindo o uso de dispositivos paravirtualizados, como placas de rede e controladores de disco em ambientes KVM.
  • Emulação e simulação (Emulation and simulation):

Em design de circuitos integrados, emulação de hardware é o processo de imitar o comportamento de uma ou mais peças de hardware (tipicamente um sistema em desenvolvimento) com outra peça de hardware, tipicamente uma emulação de sistema para fins específicos. O modelo de emulação é baseado usualmente no código fonte RTL (ex. Verilog) que é compilado no formato pelo sistema de emulação. O objetivo é normalmente depuração e verificação funcional do sistema que está sendo projetado. Muitas vezes, um emulador é rápido o suficiente para ser conectado no lugar de um chip ainda a ser construído, por isso todo o sistema pode ser depurado com dados ao vivo. Este é um caso específico de emulação em circuito.

    • Às vezes emulação de hardware pode ser confundida com dispositivos de hardware como placas de expansão com processadores de hardware que auxiliam funções de emulação de software, tais como placas de expansão mais velhas com chips x86 para permitir que sistemas operacionais x86 rodem em placas-mãe de diferentes famílias de processadores.
    • Uma simulação de computador, um modelo de computador, ou um modelo computacional é um programa de computador ou rede de computadores, que tenta simular um modelo abstrato de um sistema particular. As simulações de computador tornaram-se uma parte útil de modelagem matemática de muitos sistemas naturais em física (física computacional), astrofísica, química e biologia, sistemas humanos em economia, psicologia, ciências sociais e engenharia. Simulação de um sistema é representada como o funcionamento do modelo do sistema. Ele pode ser usado para explorar e obter novas perspectivas sobre novas tecnologias, e para estimar o desempenho de sistemas muito complexos de soluções analíticas.
  • CPU Flags:

Indicam os recursos suportados pelos processadores. Flags relevantes para virtualização:

    • HVM: Suporte de Hardware para maquinas virtuais (No Xen AMD SVM / Intel VMX)
    • SVM: Secure Virtual Machine. (Extensão de virtualização da AMD para arquitetura 64-bits e x86, equivalente ao intel VMX, ambos são conhecidos como HVM no Hypervisor Xen)
    • VMX: Equivalente Intel do AMD SVM

Onde identificar estas informações no Host Gnu/linux:

# cat /proc/cpuinfo
  • Container Virtualization:

Uma virtualização baseada em container, provê compartilhamento, imagem de sistema operacional virtualizada consistindo em um filesystem root, um compartilhamento seguro de bibliotecas de sistemas e executáveis. Cada VM pode ser iniciada, desligada e reiniciada, como uma operação regular de sistema. Recursos como espaço em disco, garantias de CPU, memória, etc. são definidos para cada VM na criação, ou podem ser alteradas dinamicamente como o sistema em execução. As aplicações e usuários de uma maquina virtual baseada em container ficam isolados em cada VM assim como em hosts separados.

  • Principais Características:
    • O kernel do host é compartilhado com os containers
    • Não necessita de virtualização de hardware assistida (HVM)
    • Limita-se a guests com Sistemas Operacionais Linux pela necessidade de compartilhamento de kernel
    • Menor utilização de recursos de memória e CPU em comparação com a utilização de virtualização tradicional, por trabalhar sobre o mesmo kernel

Pros and Cons of Virtualization

Vantagens do sistema de virtualização

  • Múltiplos ambientes de sistemas operacionais podem coexistir em um mesmo computador, com forte isolamento entre eles
  • A máquina virtual pode proporcionar um conjunto de instruções que é diferente do que a da máquina real
  • Provisionamento de aplicações, manutenção, alta disponibilidade e recuperação de desastres
  • Utilização mais eficiente dos recursos de hardware

As principais desvantagens do sistema de virtualização são:

  • A maquina virtual é menos eficiente que a maquina real por acessar recursos de hardware indiretamente.
  • Quando múltiplas maquinas virtuais rodam concorrentemente no mesmo host físico, cada VM pode exibir uma performance instável e variada, porque dependente da carga de trabalho impostas ao sistema por outras VMs, a menos que as técnicas apropriadas sejam utilizados para isolamento temporal entre máquina virtual

Variations of Virtual Machine Monitors

Virtual Machine Monitor, ou Monitor de Maquina virtual é o software que cria um ambiente de máquina virtual em um computador. Em um ambiente regular, não-virtual, o sistema operacional é o programa de controle mestre, que gerencia a execução de todas as aplicações e atua como uma interface entre os aplicativos e o hardware. O sistema operacional tem o maior nível de privilégio na máquina, conhecida como "ring 0" (Anel 0).

  • Em um ambiente de maquinas virtuais, o virtual machine monitor (VMM) torna-se o programa controlador mestre, com o maior nível de privilégio e o VMM gerencia um ou mais sistemas operacionais, agora referidos como guest ou sistemas operacionais clientes. Cada Sistema Operacional guest, gere suas aplicações normalmente como um ambiente não virtual, exceto pelo fato de estar isolado pelo VMM. Cada sistema operacional guest com suas aplicações é conhecido também como uma "máquina virtual" e é às vezes chamado de "Guest OS Stack".
  • Antes da introdução do hardware com suporte a virtualização, o VMM apenas usava técnicas de software para virtualização de processadores x86 e provendo hardware virtual. Esta abordagem de software, tradução binária (BT), foi usada para instruções de virtualização e unidades de gerenciamento de memória. Hoje e dia tanto a Intel como a AMD provem suporte de hardware para virtualziação com Inter VT-x e AMD-V, respectivamente. Mais recentemente foi adicionado suporte para virtualização do gerenciamento de unidade de memória (memory management unit - MMU) com Intel EPT e AMD RVI. Em processadores x86 modernos o VMM tem a opção de escolher entre vários modos de gerenciamento possíveis. No entanto, nem todos os modos proporcionam um desempenho similar. Depende de muita coisa como os recursos de CPU disponíveis e o comportamento sistema operacional convidado (guest). O VMware ESX identifica a plataforma de hardware e escolhe um modo de gerenciamento padrão para um guest especial nessa plataforma. Esta decisão é feita pelo VMM com base nos recursos de CPU disponíveis na plataforma e do comportamento do convidado nessa plataforma.

Migration of Physical to Virtual Machines

A conversão de hosts físicos para maquinas virtuais é uma técnica chamada de p2v Physical to Virtual. O procedimento P2V pode ser feito de várias formas e depende do tipo do host e algumas características particulares.

  • Uma das maneiras é utilizar um software de cópia das configurações da maquina, como Clonezilla ou outro similar, restaurando em seguida esta cópia em uma Maquina Virtual anteriormente criada.
  • Outra técnica é a utilização de um programa intermediário e outro software cliente. A máquina física é iniciada pelo software cliente que é acessado pelo programa intermediário. Com esta conexão estabelecida o software intermediário faz a cópia dos dados, seguido pela criação da maquina virtual e a restauração dos dados da maquina física na maquina virtual criada.
    • Um exemplo de software que trabalha desta forma é o virt-v2v e virt-p2v.

Migration of Virtual Machines between Host systems

A migração de maquinas virtuais entre hosts com diferentes Virtual Machine Managers são chamados de V2V ou seja Virtual para Virtual. Existem várias tecnicas que permitem a migração das maquinas virtuais entre hosts diferentes. No caso de hosts compatíveis, a migração é basicamente transparente.

  • No caso de hosts diferentes e com VMM não diretamente compatíveis, pode-se utilizar as mesmas técnicas do modelo P2V ou fazer a exportação dos discos da Maquina Virtual utilizando o formato comum padrão chamado de OVF (Open Virtualization Format), seguido da importação da imagem pelo novo host.

Cloud Computing

Cloud computing é a capacidade de computação infinitamente disponível e flexível. A nuvem é tudo aquilo que fica por detrás da conexão. As preocupações com a largura de banda, espaço de armazenamento, poder de processamento, confiabilidade e segurança, são postas à parte.

  • Serviço gerido pelo cliente - O cliente pode, unilateralmente, requerer ou dispensar capacidades de computação, tais como o tempo do servidor, a capacidade de armazenamento, ou outros, conforme necessário e de forma automática.
  • Acesso dos recursos - O acesso aos recursos do cloud se dão através da rede pública Internet.
  • Pool de recursos - Os recursos de computação podem ser concebidos para servir vários clientes
  • Elasticidade – Os recursos podem ser rapidamente alocados e, em alguns casos, de forma automática, para aumentar as capacidades disponíveis ou para as libertar quando já não são necessárias
  • Mensurável – Os sistemas em cloud devem controlar e optimizar a utilização dos recursos de forma automática, efetuando a medição da utilização, de forma adequada ao tipo de serviço

Um dos nomes mais fortes e líderes no mercado de CloudComputing é a Amazon AWS que estabeleceu por sua liderança alguns padrões neste ramo tecnológico, porém é errado pensar em nuvem apenas como a prestação de serviços por algumas grandes empresas pelo mundo. É possível a criação de núvens particulares, utilizando os recursos de datacenters locais. Um exemplo de projeto para este fim é o Openstack e o Cloudstack. A núvem é a evolução do uso da virtualização, abrangendo o gerenciamento de equipamentos como storages, switchs de redes entre outros com o objetivo de automatização e orquestração dos dispositivos alcançando assim os objetivos da computação em nuvem.

  • A computação em nuvem trouxe uma série de formatos de negócios ou maneiras de entregar os produtos. Abaixo uma descrição das principais nomenclaturas e definições de produtos cloud.
    • SaaS – Software as a Service (Software como Serviço): Modelo no qual é utilizado um software hospedado na nuvem, mediante a pagamento por uso. Exemplo: Skype
    • IaaS – Infrastructure as a Service (Infraestrutura como Serviço): Modelo no qual é oferecido ao cliente a criação e o gerenciamento de uma estrutura, como computadores virtuais, mediante a pagamento conforme o uso. Exemplo EC2 da Amazon
    • PaaS – Platform as a Service (Plataforma como Serviço): É um modelo intermediário onde oferece uma plataforma de desenvolvimento na qual o cliente cria ou envia o seu próprio código de desenvolvimento e ele automaticamente fica disponível para ser utilizado, abstraindo a necessidade de gerenciamento de infra estrutura.


330.2_Xen-Peso9

Objetivo do tópico

Description: Candidates should be able to install, configure, maintain, migrate and troubleshoot Xen installations. The focus is on Xen version 4.x. Key Knowledge Areas:

   Xen architecture, networking and storage
   Xen configuration
   Xen utilities
   Troubleshooting Xen installations
   Basic knowledge of XAPI
   Awareness of XenStore
   Awareness of Xen Boot Parameters
   Awareness of the xm utility

Terms and Utilities:

   Domain0 (Dom0), DomainU (DomU)
   PV-DomU, HVM-DomU
   /etc/xen/
   xl
   xl.cfg
   xl.conf
   xe
   xentop

Definições básicas

O Xen Project cria um Virtual Machine Monitor (VMM) também conhecido como hypervisor, este é um software que permite a execução de múltiplos Sistemas Operacionais guests (clientes) virtuais em uma mesma máquina física. O Xen Project cria um hypervisor 'tipo 1' ou 'bare-metal', o que significa que ele é executado diretamente no topo da máquina física (host), antes do sistema operacional instalado nela.

  • Máquinas virtuais convidadas em execução em um projeto Xen Hypervisor são conhecidas como domínios e um domínio especial, conhecido como dom0 é responsável por controlar o hypervisor e iniciar outros sistemas operacionais convidados. Esses outros sistemas operacionais convidados são chamados domUs, isso porque estes domínios estão "sem privilégios" no sentido de que eles não podem controlar o hypervisor ou iniciar/parar a outros domínios.
  • O Xen Project suporta dois tipos principais de virtualização: para-virtualização e hardware virtual machine (HVM), também conhecido como Full Virtualization. Para-virtualização usa sistemas operacionais convidados modificados. Esses sistemas operacionais estão "cientes" de que eles estão sendo virtualizados e, como tal, não necessitam de dispositivos virtuais "hardware", em vez disso, fazem chamadas especiais para o hypervisor que lhes permitem acessar CPUs, armazenamentos e recursos de rede.


  • Em contraste Guests HVM não precisam ser modificados, porque o hypervisor vai criar um conjunto totalmente virtual de dispositivos de hardware para esta máquina que se assemelham a um computador x86 físico. Essa emulação exige muito mais sobrecarga do que a abordagem de para-virtualização, mas permite que os sistemas operacionais convidados (guests) que não podem ser modificados como o Microsoft Windows possam rodar em cima do hypervisor. O Suporte ao HVM requer extensões de CPU especiais - VT-x para processadores Intel e AMD-V para máquinas baseadas AMD.
  • Um terceiro tipo de virtualização é chamado PVHVM ou "Para-virtualização em HVM", que é um domínio HVM com armazenamento, rede e outros dispositivos para-virtualizado. Isso oferece o melhor dos dois mundos, reduzindo sobrecarga na emulação.

Instalação:

  • Para instalação do Xen em distribuições Debian 8
* Instalar pacote Xen
# aptitude install xen-hypervisor-4.4-amd64

* Reiniciar Host pelo novo Kernel instalado
  • Também deve-se configurar a rede do host para modo bridge, utilizando o pacote bridge-utils

Após instalado, o Hypervisor Xen também é listado como uma maquina virtual, porém associado ao Domain-0 ou Dom0 que tem acessos privilegiados ao hardware.

# xl list
Name                                        ID   Mem VCPUs	State	Time(s)
Domain-0   

* Verificar todas as informações do HOST Xen:
# xl info

Criação de Guests Uma vez instalado e funcional, o Xen permite que sejam criadas as máquinas virtuais. Existem dois tipos de guests possíveis, o para-virtualizado e o Guest HVM.

  • Para criação ou instalação de uma maquina virtual (Guest) básica sobre HVM devemos:
    • Criar arquivo de configuração da maquina virtual baseado em /etc/xen/xlexample.hvm
    • Criar uma unidade Lógica LVM, associada como HD da máquina virtual a ser criada.
    • Criar a maquina virtual com os comandos xl
# xl create /etc/xen/xlubuntu01.hvm
Onde xlubuntu01.hvm é o arquivo de configuração criado a partir do exemplo
  • Para criação ou instalação de uma maquina virtual (Guest) básica para-virtualizado devemos:
    • Criar arquivo de configuração da maquina virtual baseado em /etc/xen/xlexample.pvlinux
    • Criar uma unidade Lógica LVM, associada como HD da máquina virtual a ser criada.
    • Criar a maquina virtual com os comandos xl
# xl create /etc/xen/xlubuntu01.pvlinux
Onde xlubuntu01.pvlinux é o arquivo de configuração criado a partir do exemplo


No arquivo de configuração de exemplo, a principal diferença entre Guests para-virtualizados para os do tipo HVM é a opção:

* Do tipo HVM:
builder = "hvm"

----------------------------------

* Do tipo Paravirtualizado:
# Kernel image to boot
kernel = "/boot/vmlinuz"

# Ramdisk (optional)
#ramdisk = "/boot/initrd.gz"

# Kernel command line options
extra = "root=/dev/xvda1"

Xen architecture

Neste tópico serão apresentados os detalhes do funcionamento e a arquitetura do Project Xen.

  • O hypervisor Xen, roda diretamente sob o hardware e é responsável pelo tratamento de CPU, memória e interrupções. Ele é o primeiro programa rodando após finalizar o bootloader. Sob o hypervisor, rodam as maquinas virtuais. Uma instância de máquina virtual é chamada de domain (dominio) ou guest. O domínio especial chamado domain-0 contem os drivers para todos os dispositivos no sistema. Domain-0 também tem uma pilha de controle para o gerenciamento, criação, destruição e configuração da maquina virtual guest.
  • Imagem com detalhes da arquitetura Xen.
Arquitetura xen.png


Detalhes sobre os tipos de Maquinas Virtuais (Guests)

  • O hypervisor suporta a execução de dois tipos diferentes de guests: Paravirtualização (PV) e virtualização completa assistida por Hardware (HVM). Ambos os tipos de clientes podem ser usados ao mesmo tempo em um único hipervisor. É também possível a utilização de técnicas utilizadas para Paravirtualização em um Guest HVM e vice-versa: criando essencialmente uma mescla entre as capacidades de PV e HVM. São usadas diferentes siglas para se referir a essas configurações, chamados HVM drivers PV, PVHVM e PVH.
  • PV:
    • Para-virtualização (PV) é uma eficiente e leve técnica de virtualização, originalmente introduzida pelo Xen Project, depois adotada por outras plataformas de virtualização. PV não requer extenção de virtualização da CPU do Host, contudo, guests paravirtualizados requerem um Kernel com PV habilitado e PV drivers, assim os guests estão "conscientes" que estão sob um hypervisor e podem rodar de forma eficiente sem emulação ou hardware virtual emulado. Kernel com PV habilitado existe para Linux, NetBSD, FreeBSD e OpenSolaris. Kernels Linux tem o PV habilitado a partir da versão 2.6.24, usando o Linux pvops framework. Na prática isso significa que o PV irá funcionar na maioria das distribuições Linux.
  • HVM
    • Full Virtualization ou Hardware-assisted virtualization (HVM) usa a extensão de virtualização da CPU do host para virtualizar guests. HVM requer Intel VT ou AMD-V. O software Xen Project uso o Qemu para emular o hardware PC, incluindo BIOS, Controlador de disco IDE, adaptador gráfico VGA, controlador USB, adaptador de rede, etc. A extensão de virtualização é utilizada para aumentar a performance da emulação. Clientes Full Virtualization não precisam nenhum suporte de Kernel. O sistema operacional Windows pode ser usado no modo HVM. Clientes Full virtualizados são usualmente mais lentos que clientes para-virtualizados, pela necessidade da emulação.
    • É possível utilizar Drivers Para-virtualizados para incrementar velocidade de I/O dos clientes. No Windows isto requer a instalação destes drivers. Em sistemas operacionais com suporte o Xen, os drivers PV são selecionados automaticamente.
  • PVHVM
    • Para aumentar o desempenho, os guests HVM full virtualizados podem usar drivers de dispositivos especiais para-virtuais (PVHVM ou driver PV-no-HVM). Estes drivers PV são otimizados para ambientes HVM e ignoram a emulação I/O para discos e rede, dando o PV um melhor desempenho em sistemas HVM. Isto significa que pode-se obter um ótimo desempenho nos sistemas operacionais guests como o Windows.
  • PVH
    • O Xen Project 4.4 introduz um modo de virtualização chamado PVH para DomUs. Xen Project 4.5 introduz PVH para Dom0 (Para Linux e BSDs). Isto é essencialmente um PV guest usando PV drivers para boot e I/O. De outro modo ele usa extensão de virtualização da CPU do Host, sem necessidade de emulação. PVH é considerado experimental na versão 4.4 e 4.5. O PVH tem o potencial de combinar as melhores trade-offs de todos os modos de virtualização, além de simplificar a arquitetura Xen.


Xen Networking

Detalhes dos tipos e características de rede utilizados pelo Xen Project.

  • Paravirtualised Network Devices:
    • Um cliente (guest) Xen, tipicamente tem acesso a um ou mais interfaces de rede paravirtualizadas (PV). Essas interfaces habilitam comunicação de rede rápida e eficiente para domínios sem a sobrecarga de emular um dispositivo de rede real. Drivers para dispositivos de rede PV estão disponíveis por padrão para a maioria dos sistemas operacionais Guests. Adicionalmente, os drivers dos dispositivos para-virtualizados estão disponíveis para vários sistemas operacionais full virtualizados (HVM) como drivers para Linux ou Windows
    • Um dispositivo de rede para-virtualisado consiste de um par de dispositivos de rede. O primeiro deles (o frontend) residirá no domain Guest (cliente), enquanto o segundo (backend) residirá no domain backend (tipicamente Dom0). Um par semelhante de dispositivos é criado para cada interface de rede virtual. Os dispositivos frontend são semelhantes com qualquer outra placa de rede Ethernet física no domain convidado. Normalmente sob o Linux é vinculado ao driver "xen-NetFront" e cria um dispositivo ethN. Sob NetBSD e FreeBSD os dispositivos frontend são nomeados xennetN e xnN respectivamente. O dispositivo de backend é normalmente nomeado de modo a conter tanto o domain ID guest e o índice do dispositivo. No Linux esses dispositivos são, por padrão, chamados vifDOMID.DEVID enquanto sob NetBSD é usado xvifDOMID.DEVID.
    • Os dispositivos frontend e backend estão ligados por um canal de comunicação virtual, as redes dos guests são obtidas na medida que o tráfego passe do dispositivo de backend para a rede mais ampla, por exemplo, usando bridging, roteamento ou Network Address Translation (NAT).
Exemplo de nomenclatura:

Pl. fisica → Placa Virtual Backend → Placa virtual Frontend
ethN → vifA.B → ethB

Exemplo:
eth0 → vif4.0 → eth0(Dom-4)
  • Emulated Network Devices:
    • Guests HVM também podem ser configurados com um ou mais dispositivos de rede emulada. Estes dispositivos emulam uma verdadeira peça de hardware e são úteis quando um sistema operacional convidado não tem Drivers Para-virtualizados disponíveis. Um dispositivo de rede emulado, normalmente é emparelhado com dispositivos para-virtualizados com o mesmo mac address e mesma configuração. Isto permite que o guest (cliente) possa ter uma transição suave de um dispositivo emulado para um para-virtualizado, assim que um driver estiver disponível. O dispositivo de rede emulado é provido pelo modelo de dispositivo(Device Model - DM). Rodando como um processo em Domain-0 ou como StubDomain
    • Quando o Device Model (DM) roda como um processo no Domain-0 , então um dispositivo TAP é criado no backend domain. Historicamente era nomeado como tapID ou tapDOMID.DEVID. Mais recentemente esta sendo renomeado como vifDOMID.DOMID-emu para deixar claro a relação de paridade entre o dispositivo para-virtualizado e o dispositivo emulado.
    • Se o Device Model rodar em um stub domain, então o dispositivo criado no Domain-0 é um dispositivo de rede para-virtualizado atachado ao "stub domain". O stub Domain vai cuidar do encaminhamento entre o dispositivo emulado e este dispositivo para-virtualizado.
  • MAC addresses:
    • O início do Mac: 00:16:3e:xx:xx:xx é associado conforme a Organizationally Unique Identifier (OUI) ao Project Xen e está disponível para usuários do Xen
    • Um endereço MAC deve ser único entre todos os dispositivos de rede, tanto físico como virtual, em um mesmo segmento de rede local
  • Bridging:

O padrão e a configuração Xen mais comum é usar bridging no Domain-0, para permitir que vários dominio apareçam na rede como hosts individuais.

    • É necessária a criação de uma configuração de bridge no Domain-0. O dispositivo Backend virtual (vifDOMID.DEVID) é adicionado ao bridge que por sua vez esta associado (isto é opcional) ao dispositivo físico de rede para prover conectividade ao guest. Se o dispositivo físico ethernet for omitido, apenas dominios guests podem ser criados em redes isoladas.
    • Existem dois comuns esquemas de nomes quando se usa rede bridge. Em um primeiro esquema, o dispositivo eth0 é renomeado para peth0 e a Bridge nomeada para eth0. Em outro esquema, o dispositivo físico permanece eth0 enquanto a Bridge é chamada de xenbr0 ou br0.
    • Configurando uma rede Bridge:
* No Debian: instalar o pacote bridge-utils
* Editar o arquivo /etc/network/interfaces adicionando o conteúdo:
---
iface eth0 inet manual

auto xenbr0
iface xenbr0 inet static
	address  192.168.X.X
	netmask  255.255.255.0
	gateway  192.168.X.XX
	bridge_ports eth0
	bridge_stp off
	bridge_fd 0
---

* Configurar o arquivo de configuração /etc/xen/xl.conf
---
vif=[ 'bridge=xenbr0' ]
---
  • Open vSwitch:
    • A partir do release 4.3 foi adicionada uma feature de integração com o Open vSwitch. Conceitualmente isto é similar à configuração de Bridge mas em vez de colocar o dispositivo vif, utilizar o Open vSwitch. Open vSwitch suporta a mais avançada "Sofware-defined Networking (SDN)"
    • Configuração Open vSwitch:
* Incluir as configurações no arquivo /etc/xen/xl.conf

---
vif.default.script="vif-openvswitch"
vif.default.bridge="ovsbr0"
---

  • Routing:

Em uma configuração de rede roteado é criado um link ponto-a-ponto entre o domínio de backend (tipicamente de dom-0) e cada interface de rede virtual guest domU. O tráfego é então encaminhado entre estas ligações ponto-a-ponto e o mundo exterior, usando a funcionalidade de roteamento da rede do domínio backend. Por as rotas serem criadas dinamicamente juntamente aos dominios as placas virtuais dos guests devem ter ips estáticos conhecidos.

    • Quando domU é iniciado, o script vif-route é executado para cada dispositivo virtual vifDOMID.DEVID. Este script adiciona um IP a interface, levanta a interface e adiciona a rota para a mesma.
    • Configuração:
* Editar o arquivo de configuração do guest (domU) com a informação do IP da interface

 vif=[ 'ip=192.168.1.12' ]


  • NAT:

NAT é uma forma de roteamento que dá a cada VIF Guest seu próprio endereço IP em uma rede privada, usando tradução de endereço (geralmente no Dom-0) para a conexão entre a rede privada e o restante da rede via apenas um ip "público". Também conhecido por masquerade.

    • Os guests podem tanto ser configurado estaticamente com endereços no espaço de rede escolhida ou pode ser escolhido para executar um servidor DHCP dentro da rede (talvez no próprio host) para fornecer endereços para os guests.
    • Quando domU é iniciado, o script vif-nat é executado para cada dispositivo virtual vifDOMID.DEVID. Se o servidor DHCP-ISC esta instalado, esse script irá tentar reconfigurar dinamicamente o serviço DHCP para servir entradas para as chaves de configuração MAC e IP no arquivo de configuração do convidado. Isto é específico para a sintaxe do arquivo de configuração de servidores DHCP ISC e funciona somente para este servidor. Se outro servidor de DHCP é utilizado, então o script vif-nat deve ser desabilitado.


  • Sobre Stub Domain:

Stub Domain é um Domain especializado rodando no Xen host, usado para desagregar o domain control (dom-0). Muitos stub domains são baseados no Mini-OS. No caso específico do device model (DM) stub domain no system domain é usado para rodar o modelo de dispositivo Qemu associado ao dominio HVM. Muitas vezes, o modelo do dispositivo Qemu seria um processo normal em execução no ambiente do Domain-0.

Xen Storage

O Xen Storage se refere principalmente ao local e a forma de armazenamento das imagens das maquinas virtuais guests, em outras palavras, a forma que serão disponibilizados os HDs das VMs.

  • Local Storage:

Existem duas principais opções para armazenamento local de imagens de disco guest. Pode ser usado uma ferramenta como LVM do Linux para dividir o disco físico em múltiplos dispositivos de bloco, cada um dos quais pode ser usado como um disco de guest, ou pode armazenar imagens de disco como arquivos (usando tanto raw, qcow2 ou o formato vhd) em um sistema de arquivos local. Usando uma configuração de armazenamento baseado dispositivo de bloco (LVM), permite que você tire vantagem do driver blkback que roda melhor do que os drivers que suportam o armazenamento de imagem de disco (por exemplo blktap ou qdisk). Soluções baseadas em imagem de disco normalmente oferecem um desempenho mais lento, mas são mais flexíveis em algumas áreas (por exemplo, snapshotting, implantações de imagens master/gold). É possível fazer uma mistura entre as duas tecnicas, por exemplo, pode ser criado um LVM com um Volume lógico grande e nele inserir os arquivos de imagens de disco. Na configuração do Xen e indicado o uso de LVM sempre que possível.

  • Algumas definições sobre Xen Storage:
  • Block Device:

Armazenamento 'publicado' na forma de um arquivo de dispositivo tipo bloco, geralmente em algum lugar em / dev. Os dispositivos de bloco agem como um arquivo enorme, possivelmente com recursos extras definidos pelo hardware ou software por trás deles. Exemplo: /dev/md0 para utilização de dispositivo em Raid de software.

    • Hardware Block Device: Domain-0 acessa o storage físico real. Pode ser um disco Sata, uma partição ou uma Raid por Hardware
    • Software Block Device: Software de gerenciamento de volume (evms, LVM) e software RAID (md) juntando os dispositivos de hardware e software, criando outro bloco e dando-lhes novos nomes, como objetivo de adicionar funcionalidade para o armazenamento gerado. Por exemplo, uma Raid de Software /dev/hda e /dev/hdb pode ser acessada através de um dispositivo 'md' chamado /dev/md0. Como alternativa, ele também pode ser parte de um grupo de volume LVM que é gerido pelo evms e nomeado "exemplo". Nesse caso, seu nome seria /dev/evms/exemplo.
  • Network Block Device: Existem vários drivers do kernel que exportam o storage como um dispositivo de bloco simples que os clientes podem usar de forma idêntica à forma como eles iriam utilizar um dispositivo de bloco de hardware ou software tradicional. Um exemplo seria um host qualquer unix poderia criar um sistema de arquivos em um volume evms de gestão criado a partir de uma região de um recipiente lvm2 cujas regiões de armazenamento são dispositivos RAID de software criados a partir de dispositivos de blocos de rede exportados de outros hosts. Este tipo de configuração pode ser usado para criar um dispositivo de bloco de todo o cluster que iria tolerar algumas falhas de nó de armazenamento.

Tipos de network block devices:

    • nbd: Um protocolo extremamente simples disponível no "mainline" do kernel unix
    • gnbd: Um nbd aprimorado da RedHat, para utilização em cluster
    • iscsi: Complexo e robusto protocolo padrão da industria para acesso a dispositivo de bloco através de rede IP
  • Network File System: Sistemas de arquivos de rede diferem dos dispositivos de bloco em que, como sistemas de arquivos regulares, eles implementam a semântica do sistema de arquivos unix , como diretórios, links simbólicos, hardlinks, listas de controle de acesso e mecanismos de bloqueio. Nem todos os sistemas de arquivos de rede implementam esses recursos igualmente.

Alguns tipos de Network file systems:

    • nfs3: Largamente suportado
    • gfs: Desenvolvido pela RedHat para clusters
    • gfs2: Sucessor do gfs
    • afs: Designado para alto uso cliente:servidor e redes com alta latência
    • Coda
    • Lustre
  • Configuração dos Guests

Dom-0 garante acesso ao guest para conectar ao dispositivo de bloco disponível no Host, através do parâmetro disk na configuração do guest.

disk = [ 'phy:dom0,domU,mode' ]

* Onde:
dom0 : Caminho do dispositivo em Domain0, 
domU : Como o Dominio Host apresenta o dispositivo ao dominio guest
mode :'r' para read-only, 'w' para read-write. 

Obs: O caminho e o arquivo do dispositivo de bloco no Domain-0 vai depender dos modulos e configurações de hardware deste dispositivo.

Exemplo de uso:
disk = [ 'phy:/dev/vg/guest-volume,raw,xvda,rw' ]


Xen configuration

O Xen utiliza arquivos de configuração com os parâmetros para execução das maquinas virtuais. Cada maquina virtual tem um arquivo de configuração relacionado, geralmente em: /etc/xen/. Existe também o arquivo /etc/xen/xl.conf com as configurações globais de todas as VMs.

  • Abaixo o exemplo do arquivo de configuração de dois guests, um com full virtualização e outro para-virtualizado
    • DomU conf Full Virtualization:
# =====================================================================
# Example HVM guest configuration
# =====================================================================
#
# This is a fairly minimal example of what is required for an
# HVM guest. For a more complete guide see xl.cfg(5)

# This configures an HVM rather than PV guest
builder = "hvm"

# Guest name
name = "winxp01.hvm"

# 128-bit UUID for the domain as a hexadecimal number.
# Use "uuidgen" to generate one if required.
# The default behavior is to generate a new UUID each time the guest is started.
#uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

# Enable Microsoft Hyper-V compatibile paravirtualisation /
# enlightenment interfaces. Turning this on can improve Windows guest
# performance and is therefore recommended
#viridian = 1

# Initial memory allocation (MB)
memory = 512

# Maximum memory (MB)
# If this is greater than `memory' then the slack will start ballooned
# (this assumes guest kernel support for ballooning)
maxmem = 512

# Number of VCPUS
vcpus = 1

# Network devices
# A list of 'vifspec' entries as described in
# docs/misc/xl-network-configuration.markdown
vif = [ '' ]

# Disk Devices
# A list of `diskspec' entries as described in
# docs/misc/xl-disk-configuration.txt
disk = [ '/dev/xen01-vg/winxp01,raw,xvda,rw','file:/var/iso/WinXPPRO_SP2.iso,xvdb:cdrom,r' ]

# Inicializacao - Boot
boot="dc"
#boot="c"

# Guest VGA console configuration, either SDL or VNC
#sdl = 1
vnc = 1

    • DomU conf para-virtualizado:
# =====================================================================
# Example PV Linux guest configuration
# =====================================================================
#
# This is a fairly minimal example of what is required for a
# Paravirtualised Linux guest. For a more complete guide see xl.cfg(5)

# Guest name
name = "example.pvlinux"

# 128-bit UUID for the domain as a hexadecimal number.
# Use "uuidgen" to generate one if required.
# The default behavior is to generate a new UUID each time the guest is started.
#uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"

# Kernel image to boot
kernel = "/boot/vmlinuz"

# Ramdisk (optional)
#ramdisk = "/boot/initrd.gz"

# Kernel command line options
extra = "root=/dev/xvda1"

# Initial memory allocation (MB)
memory = 128

# Maximum memory (MB)
# If this is greater than `memory' then the slack will start ballooned
# (this assumes guest kernel support for ballooning)
#maxmem = 512

# Number of VCPUS
vcpus = 2

# Network devices
# A list of 'vifspec' entries as described in
# docs/misc/xl-network-configuration.markdown
vif = [ '' ]

# Disk Devices
# A list of `diskspec' entries as described in
# docs/misc/xl-disk-configuration.txt
disk = [ '/dev/vg/guest-volume,raw,xvda,rw' ]

  • Detalhes dos parâmetros nos arquivos de configuração pode ser obtidos com o comando: # man xl.cfg
  • O gerenciamento básico das maquinas virtuais é feito com o comando xl. Algumas opções importantes do comando são:
* Iniciar uma maquina virtual com o conf em /etc/xen
# xl create domU_CONFIG

* Incluir parametros extras na execução da VM com conf em /etc/xen/
# xl create hvm.cfg 'cpus="0-3"; pci=["01:05.1","01:05.2"]'

* Atualizar a VM que esta rodando com novas configurações
# xl config-update domid [configfile]

* Conectar na console da VM
# xl console domain-id

* Desligar de forma abrupta a VM
# xl destroy domain-id

* Pausar Guest
# xl pause domain-id

* Reinicializar Guest
# xl reboot domain-id

* Restaurar um Guest pausado
# xl restore domain-id

* Desligar Guest
# xl shutdown domain-id
  • Informações de execução e estado:

* O comando abaixo Lista as VMs em execução 
# xl list


r - rodando: O guest esta atualmente rodando na CPU
b - bloqueado: O Guest(dom) esta bloqueado e não esta rodando. Isto pode ser causado porque o dominio esta aguardando IO (wait state) ou foi colocado em sleep
 porque não havia mais nada a fazer.
p - pausado: O Guest (dom) foi colocado em pausa. Usualmente isto ocorre quando o administrador roda o comando xl pause. Quando o domínio esta em pausa, ele irá
 consumir alguns recursos como memória alocada, mas não outros recursos como CPU sheduler.
s - shutdown: O sistema operacional Guest esta desligado mas o dominio ainda não esta finalizado (morto)
c - crashed: O domíno esta com crash, isto pode ocorrer por um fim violento. Usualmente este estado apenas pode ocorrer se o domínio foi configurado para não
 restartar em crash. Opção "on_crash = 'restart'" no arquivo de configuração domU.
d - dying (morrendo): O domínio esta morrendo, mas não esta completamente finalizado ou crashed
  • O Xen, utilizando o scheduler permite a divisão do processador entre os dominios em um Host. O sub-comando utilizado para isso é xl sched-credit. Abaixo alguns exemplos:

# xl sched-credit -r [n]
# xl sched-credit -t [n]

* Lista as opções atuais
# xl sched-credit

Xen utilities

Alguns utilitários muito usados no Xen Project.

  • xentop: Mostra informações sobre o sistema Xen e os Domínios em tempo real. Opções na linha de comando podem exibir mais detalhes. Comando similar ao TOP, mas especificando os DOMs. Abaixo algumas opções principais:
-d, --delay=SECONDS: Segundos entre updates (default 3)
-n, --networks: Mostra informações de rede
-x, --vbds: Mostra dados referentes ao vbd (virtual block device)
-v, --vcpus: Exibe dados das VCPUs
-b, --batch: Redireciona saida para stdout (modo bach)
-i, --iterations=ITERATIONS: Numero máximo de updates que o Xentop irá processar antes de finalizar
  • xenpm: É uma ferramenta de nível userspace que pode listar informações de energia dos processadores disponíveis. Também controla a política de consumo de energia conforme a preferência do usuário. O gerenciamento de energia de uma CPU influi diretamente sobre a performance da mesma, onde uma economia de energia pode diminuir a frequencia de clock do processador. Abaixo exemplo de uso da ferramennta xenpm
* Verificar as frequencias atuais utilizadas pelos processadores:
# xenpm get-cpufreq-states

* Configurar processadores para o modo performance
# xenpm set-scaling-governor performance
  • Xentools: Xen-tools é um simples conjunto de scripts Perl que permitem criar facilmente novos domínios Xen guests em cima do sistema Debian/Linux. Para instalação automatizada do sistema operacional no Guest, geralmente é utilizado o utilitário debootstrap.
    • Cada novo domínio Xen criado com xen-tools terá automaticamente as configurações de:
      • Configuração de rede, tanto com múltiplos endereços IP estáticos ou DHCP.
      • Uma instalação do OpenSSH.
      • Um conjunto arbitrário de partições.

Exemplo de utilização do xentools

* O comando abaixo cria um Dom-Guest para-virtualizado com memória limitada em 512Mb e 2 Vcpus, rede em DHCP , Unidade logica LVM em um grupo de volumes vg0 
e distribuição Debian Wheezy. O pygrub é utilizado para extrair do host os arquivos necessários para o Boot da maquina guest para-virtualizada.

#  xen-create-image --hostname=tutorial-pv-guest --memory=512mb --vcpus=2 --lvm=vg0 --dhcp --pygrub --dist=wheezy

As Opções podem ser alteradas diretamente na execução da linha de comando ou as opçoes default podem ser alteradas no arquivo de configuração do xen-toos que fica em: /etc/xen-tools/xen-tools.conf.

  • Uma das opções importantes presentes no arquivo de configuração é passwd = 1, que pergunta durante a criação da imagem, qual a senha de root para o guest.

Troubleshooting Xen installations

Alguns erros podem ocorrer durante a instalação e uso do Xen Project.

  • Verificar se as requisições de hardware e software estão correspondidas
* Verificar se o hardware tem suporte a virtualização completa:
# egrep '(vmx|svm)' /proc/cpuinfo
  • Após instalado o Xen, o respectivo kernel deve ser inicializado e não o kernel anteior. Para isso, o grub deve ser configurado.
  • Verificar se o Kernel atual tem suporte ao uso do Xen.
  • A rede deve estar configurada para Bridge a fim de disponibilizar acesso a rede para os demais DOMs
  • Configurar ou desabilitar SeLinux (Fedora)
# grep <vairous_stuff_here> /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
  • Alguns erros comuns:
    • Dom0 (Host) reinicia sozinho: Quando ocorre um crash em Dom0 ele pode reiniciar sozinho se a opção GRUB_CMDLINE_XEN="noreboot" Não estiver configurada em: /etc/default/grub
    • Erro: unknown compression format, isto ocorre quando novos kernels que utilizam compreesão xz são botados em antigas instalações Xen.
    • Problemas com muitos pacotes de rede perdidos: Pode ser resolvido aumentando uma TAG chamada qlen da placa de rede, para valor semelhante a 1000
ip link set qlen 1000 dev vif-mydomU
  • Por fim, o comando xl info mostra se o Xen está conforme.

Basic knowledge of XAPI

O projeto XAPI é um sub-projeto do Xen Project, que desenvolve o enterprise ready XAPI toolstack. O hypervisor usado com o toolstack XAPI consolida as cargas de trabalho do servidor, permite economia em energia, refrigeração e custos de gestão, contribuindo, assim, para a computação ambientalmente sustentável, uma maior capacidade de adaptação às constantes mudanças dos ambientes de TI, uma utilização otimizada do hardware existente, e um melhorado nível de confiabilidade de TI.

Arquitetura xapi.png
  • O Xen Project Management API (XAPI) é:
    • O Xen Project Toolstack que expõe a interface XAPI.
    • Uma interface para configurar e controlar remotamente guests virtualizados rodando em um host Xen habilitado. XAPI é o componente central do XenServer e XCP.
    • A utilização do XAPI permite o uso do XEN em grandes ambientes, ambientes em nuvem e a capacidade de trabalho em pool.
  • O XAPI toolstack inclui uma poderosa interface de linha de comando chamada 'xe que fala com ambos hosts e grupos de recursos sobre https, invocando operações XenAPI sobre XMLRPC. Os comandos podem ser evocados tanto do próprio Host Dom-0 como de outros hosts. Ou seja, o comando xe utiliza as funcionalidades disponibilizadas pelo projeto XAPI para fazer a interação com os hosts XEN.
    • Alguns usos do comando;
* Uso padrão:
# xe -s <host> -u <username> -pw <password> <command-name> <argument=value>*

* Iniciar VM:
# xe vm-start vm=<target VM name>

* Listar VM
# xe vm-list 

* Deletar VM
# xe vm-destroy uuid=<UUID of target VM> 

* Criar repositórios STORAGE
# xe sr-create name-label=<name> physical-size=<size> type=<type> content-type=<content_type> device-config:<config_name>=<value> 
                                                               [host-uuid=<Xen Cloud Platform host UUID>] [shared=<true | false>] 

* Criação de uma VM
# xe vm-install template=<name of target template> new-name-label=<name of  VM>

* Adicionar uma interface de rede virtual a uma VM
# xe vif-create network-uuid=<network uuid from above>  vm-uuid=<uuid of new VM> device=0



Awareness of XenStore

XenStore é um espaço de armazenamento de informações compartilhadas entre domínios mantidos pelo Xenstored. Ele é destinado a configuração e informações de status e não para grandes transferências de dados. Cada domínio recebe o seu próprio caminho no store, o que é um pouco semelhante ao procfs. Quando os valores são alterados no store, os drivers apropriados são notificados.

  • XenStore é um banco de dados, armazenado no domain 0, com suporte transacional e atomicidade.
  • Os comandos xenstore-* permitem consultar e interagir com xenstored.
  • Alguns exemplos de uso:
* Lista as informações de status dos domínios
# xenstore-ls -f

* Adiciona ou modifica chaves e valores:
# xenstore-write

Awareness of Xen Boot Parameters

Algumas questões sobre parâmetros de boot de Kernel para o Host Xen que devem ser observadas e adicionadas em /etc/default/grub

mem: Limita a quantidade de memória que está disponível para o kernel hipervisor
dom0_mem: Limita a memória disponível para o hypervisor
dom0_max_vcpus: Limita a CPU visível em Dom-0

* Opções referentes a ACPI
acpi=off: Disables both ACPI table parsing and interpreter.   
acpi=force: Subscreve o blacklist desabilitado.
acpi=strict: Disables out-of-spec workarounds.
acpi=ht: Limits ACPI from boot-time to enable HT.
acpi=noirq: Desablita roteamento de interrupção ACPI. 
noacpi: Desabilita a entrega de ACPI

Awareness of the xm utility

Xm é uma obsoleta interface de usuário para gerenciamento do Xen. Este comando foi substituído pelo xl que manteve uma compatibilidade básica.

  • Todas as operações do xm são executadas acessando o daemon xend, que deve estar rodando para que o xm funcione. Este daemon também não é mais utilizado e está obsoleto.
  • Exemplo de utilização do comando:
* Criação de VM
# xm create -c myvmconf vmid=1

* Lista os domínios ativos
# xm list

* Finaliza domínio ativo
# xm destroy domain-id


Fonte

330.3_KVM-Peso9

Objetivos do tópico

Description: Candidates should be able to install, configure, maintain, migrate and troubleshoot KVM installations. Key Knowledge Areas:

   KVM architecture, networking and storage
   KVM configuration
   KVM utilities
   Troubleshooting KVM installations

Terms and Utilities:

   Kernel modules: kvm, kvm-intel and kvm-amd
   /etc/kvm/
   /dev/kvm
   kvm
   KVM monitor
   qemu
   qemu-img


KVM architecture

KVM (Kernel-based Virtual Machine) é uma solução de virtualização completa (full-virtualization) para Linux em hardware x86 contendo extenções Intel VT ou AMD-V. Ele consiste em um modulo de kernel, kvm.ko, que fornece a infra-estrutura de virtualização do núcleo e um módulo de processador específico, kvm-intel.ko ou kvm-amd.ko. Usando o KVM, pode-se utilizar multiplas maquinas virtuais sem a necessidade de modificação dos Guests, como Windows ou Linux. Cada VM tem seu hardware virtualizado privado, como uma placa de rede, disco ou adaptador gráfico.

  • O KVM por si só não executa qualquer virtualização ou emulação, ele expõe a interface /dev/kvm para que programas a nível de usuário (userspace) o utilizem para fazer emulações ou virtualizações. Entre as tarefas do programa que trabalha com o KVM necessárias para a virtualização destacam-se;
    • Configurar o espaço de endereçamento da VM cliente. O Host deve também fornecer uma imagem firmware (Geralmente uma BIOS customizada) com o qual a VM Guest pode inicializar o sistema operacional.
    • Entregar ao Guest, simulação de I/O, como placa de rede, etc.
    • Mapear o display gráfico do Guest para para o Host

O QEMU versão 0.10.1 e posterior trabalha com KVM para virtualização. Do contrário o QEMU utiliza apenas emulação por software.

  • O KVM é disponibilizado geralmente através de módulos de kernel. O nome dos módulos são: kvm, kvm-intel e kvm-amd
# modprobe kvm
# modprobe kvm_intel

ou

# modprobe kvm
# modprobe kvm_amd

Um pouco sobre o QEMU

Falando de KVM, somos obrigados a também falar sobre o QEMU. Como visto o KVM é um módulo de baixo nível para utilização de virtualização e o QEMU é a ferramenta a nível de usuário que cria e gerencia realmente as VMs. O QEMU é anterior ao KVM, já existia antes dele e sofreu modificações primeiro em um Fork e posteriormente dentro do código oficial para suportar as funcionalidades extras do KVM.

  • O QEMU é um emulador completo, não apenas é capaz de virtualização completa (através do KVM) como também permite emulação de processadores, tudo isso por software, tornando a emulação algo bem mais lento que a virtualização completa.
  • Para criação de uma nova imagem de disco, é utilizado o binário: qemu-img. Para instalar/inicializar uma VM é utilizado o binário: qemu-system-x86_64.
    • Exemplos:

Criação de uma imagem de disco para VM por QEMU

# qemu-img create -f qcow2 vdisk.img 10G 

Instalação/Inicialização de uma VM por QEMU

* Instalação de uma Maquina Virtual
# qemu-system-x86_64 -hda vdisk.img -cdrom /path/to/boot-media.iso -boot d  -m 384

* Inicialização de uma Maquina Virtual
# qemu-system-x86_64 -hda vdisk.img -m 512 -soundhw es1370 -no-acpi -snapshot -localtime -boot c -usb -usbdevice tablet -net nic,vlan=0,
macaddr=00:00:10:52:37:48 -net tap,vlan=0,ifname=tap0,script=no

KVM networking

O KVM não disponibiliza rede aos Guests, isto é feito pelo QEMU que se incorpora e utiliza o modulo KVM para virtualização.

  • Há duas partes para rede dentro QEMU:
    • O dispositivo de rede virtual que é fornecido para os Guests (por exemplo, uma placa de rede PCI).
    • A infraestrutura de rede que interage com a placa de rede emulada (por exemplo, enviar os pacotes para a rede do host).

Há uma gama de opções para cada parte.

  • Criação de uma rede de infraestrutura:

Exemplo de opção para criação de infraestrutura de rede, que deve estar integrada ao comando qemu-system-x86_64.

-netdev TYPE,id=NAME

Onde:

  • A opção ID dá o nome pelo qual o dispositivo de rede virtual e a infraestrutura de rede são associados uns com os outros. O nome é usado para distinguir backends um do outro e deve ser utilizado mesmo quando apenas um backend é especificado.
  • A opção Type é o tipo de infraestrutura conforme os tipos explicados a seguir:
    • Tipos de infraestrutura de rede:
      • User(SLIRP): Este é o tipo padrão de infraestrutura de rede. Não requer privilégios de administrador, porém tem algumas limitações:
        • Há uma grande quantidade de sobrecarga de modo que o desempenho é ruim
        • Tráfego ICMP não funciona (para que você não pode usar o ping dentro de um convidado)
        • O Guest não é acessível diretamente a partir do host ou a rede externa

A Rede User é implementada usando "slirp", que fornece uma pilha TCP/IP completa dentro QEMU e usa esta pilha para implementar uma rede virtual NAT. Exemplo:

* Altera a configuração de rede para usar 192.168.76.0/24 e inicializar a alocação de IPs do DHCP no ip 9
-netdev user,id=mynet0,net=192.168.76.0/24,dhcpstart=192.168.76.9

* Isolar o guest do Host e da rede do Host
-netdev type=user,id=mynet0,restrict=yes

* Encaminhar portas do Host para o Guest
-netdev user,id=mynet0,hostfwd=hostip:hostport-guestip:guestport

* Algumas outras opções possíveis
-netdev user,id=mynet0,dns=xxx
-netdev user,id=mynet0,tftp=xxx,bootfile=yyy
-netdev user,id=mynet0,smb=xxx,smbserver=yyy
-netdev user,id=mynet0,host=xxx,hostname=yyy

      • Tap: A infraestrutura tipo TAP faz uso de um dispositivo de rede TAP no host. Ela oferece um desempenho muito bom e pode ser configurado para criar praticamente qualquer tipo de topologia da rede. Isso requer a configuração da topologia de rede que no host tende a ser diferente, dependendo do sistema operacional que está sendo usando. De um modo geral, ele também requer privilégios de root. Exemplo:
-netdev tap,id=mynet0
      • VDE: O backend rede VDE usa a infraestrutura "Virtual Distributed Ethernet" para os hóspedes da rede.
      • Socket: O backend socket de rede, juntamente com QEMU VLANs, permitem que você crie uma rede de guests que podem ver um ao outro. É útil principalmente em estender a rede criada pela SLIRP para múltiplas máquinas virtuais. Exemplo;
-netdev socket,id=mynet0,listen=:1234
-netdev socket,id=mynet0,connect=:1234
  • Criação de um dispositivo de rede virtual: O dispositivo de rede virtual escolhido depende das necessidades e do ambiente do guest (ou seja, o hardware que você está emulando). Por exemplo, se você estiver emulando uma placa onboard particular, então você deve usar o dispositivo de rede virtual que corresponde a configuração deste dispositivo incorporado. Em maquinas PCI bus, existe uma gama de opções. O e1000 é o adaptador de rede padrão no qemu. O rtl3139 é o padrão para o qemu-kvm. O tipo paravirtualizado "virtio-net" tem a melhor performance, porém necessita de drivers específicos no sistema operacional do guest. A opção -device adiciona um dispositivo de placa de rede virtual a maquina virtual.
-device TYPE,netdev=NAME
* O netdev é o nome de um -netdev anteriormente definido. O dispositivo de rede virtual irá ser associado com este backend rede.
    • Pode-se utilizar a opção -device ? para listar os dispositivos disponíveis
    • Existe a opção legada -net utilizada anteriormente com a sintaxe abaixo:
-net nic,model=MODEL


KVM storage

Suporte de dispositivos, mídias e tipos de arquivos:

  • Devices e midia:
    Floppy, CD-ROM, USB stick, SD card,harddisk
  • Host storage:
    Flat files (img, iso)
        Também sobre NFS
    CD-ROM host device (/dev/cdrom)
    Block devices (/dev/sda3, LVM volumes,iSCSI LUNs)
    Distributed storage (Sheepdog, Ceph)
  • Formatos de imagem suportada::
    QCOW2, QCOW, COW, RAW – QEMU
    VMDK – VMware
    VHD – Microsoft
    VDI – VirtualBox
  • Recursos que oferecem vários formatos de imagem:
    Sparse images
    Backing files (delta images)
    Encryption
    Compression
    Snapshots
  • Formato de uso de imagem no QEMU:
qemu -drive
   if=ide|virtio|scsi,
   file=path/to/img,
   cache=writethrough|writeback|none|unsafe

    Storage interface is set with if=
    Path to image file or device is set with path=
    Caching mode is set with cache=

qemu -drive file=install-disc-1.iso,media=cdrom ...

O QEMU suporta uma ampla variedade de formatos de armazenamento e backends. Mais fácil de usar são os formatos RAW e qcow2, mas para o melhor desempenho é melhor usar uma partição bruta. Você pode criar um volume lógico ou uma partição e atribuí-lo ao cliente:

# qemu-system-x86_64 -drive file=/dev/mapper/ImagesVolumeGroup-Guest1,cache=none,if=virtio

O QEMU também suporta uma ampla variedades de modos de cache. Se estamos utilizando volume RAW ou partições, é melhor evitar completamente o cache, o que reduz as cópias de dados e tráfego BUS.

  • Políticas de cache: O QEMU pode armazenar em cache o acesso aos arquivos de imagem de disco, e fornece vários métodos para fazê-lo. Isso pode ser especificado usando o modificador cache.
Politica	Descrição
writethrough	Dado é escrito no disco e na cache simutaneamente. (padrão)
writeback	Dado é escrito no disco quando descartado da cache
unsafe		Parecido com writeback, mas sem executar o fsync.
none		Desabilita uso de cache.

Exemplo de aplicação

-drive file=disk.img,cache=writeback
  • Observações:
    • Não é aconselhado o uso do sistema de arquivos btrfs no host para arquivos de imagem. Isto poderá resultar em uma performance baixa de IO. O Kvm guest pode congelar com alto tráfego de IO.
    • Virtual FAT filesystem (VVFAT): Qemu pode emular um drive virtual com sistema de arquivos FAT.
-drive file=fat:rw:some/directory

Criando a imagem: Para configurar uma imagem de guest, precisamos primeiro criar uma imagem em disco. QEMU usa o comando qemu-img para criar e manipular imagens de disco, e suporta vários formatos. Por padrão ele utiliza raw files. O formati nativo para o qemu é qcow2, e este fformato oferece muitas flexibilidades. Exemplo de criação de um arquivo de 13GB:

# qemu-img create -f qcow2 win7.img 13G

Uma via fácil para instalar um sistema operacional guest em QEMU/KVM é criar uma imagem ISO e chamar o QEMU para inicializar por ela.

# qemu-system-x86_64 -m 512 -hda win7.img -cdrom win7.iso -boot d
  • Snapshots: Snapshots no QEMU são imagens que se referem a uma imagem original usando Redirect-on-Write para evitar a alteração da imagem original. Se você deseja criar um snapshot de uma imagem chamada centos-cleaninstall.img existente, basta criar um novo arquivo qcow2 usando o parâmetro -b para indicar um arquivo de backup. A nova imagem é agora um snapshot de leitura/gravação da imagem original. Quaisquer alterações ao snapshot.img não será refletido no centos-cleaninstall.img. Basta que a VM seja iniciada nesta imagem.
# qemu-img create -f qcow2 -b centos-cleaninstall.img snapshot.img
    • Reversão de Snapshots: A imagem instantânea não pode ser devolvida ao seu estado original, uma vez modificado. Em vez disso apagar a primeira imagem snapshot (snapshot.img em nosso exemplo), criar uma outra snapshot da imagem de base como acima, e começar a usar o novo arquivo .img. Obs: Fazer quaisquer alterações em uma imagem base (centos-cleaninstall.img em nosso exemplo) irá corromper os snapshots.
  • Alguns outros sub-comandos importantes do qemu-img:
* Mostra informações da imagem:
# qemu-img info test.vmdk 

* Converter o tipo de imagem:
# qemu-img convert -O qcow2 test.vmdk test.qcow2

* Utilização de múltiplas imagens:
# qemu-system-x86_64 -m 256 -hda winxp.img -hdb pagefile.img -hdc testdata.img -hdd tempfiles.img -kernel-kqemu


KVM configuration

Normalmente as máquinas virtuais utilizadas sob KVM são criadas e gerenciadas por intermédio do Libvirt e também QEMU, mas é possível, apesar de pouco usual trabalhar diretamente com KVM.

  • O comando KVM é muito similar ao Qemu e é possível rodar maquinas a partir da linha de comando.
    • Sintaxe básica:
# kvm -m 512 -hda disk.img -cdrom ubuntu.iso -boot d -smp 2
Onde:
   -m = Memória (em MB)
    -hda = primeiro hard drive
       Pode ser utilizado inúmeros tipos de imagem incluíndo .img e .cow
       Pode ser usado  um disco rígido para inicialização.
            Sintaxe -hda /dev/sda
            Isto irá chamar o menu de grub da MBR quando botado pelo KVM.
    -cdrom pode ser uma imagem iso ou um drive CD/DVD.
    -boot [a|c|d|n]: boot em floppy (a), hard disk (c) , CD-ROM (d), ou network (n)
    -smp = numero de CPU
    -alt-grab: Altera a combinação Ctrl-Alt 'travamento' de mouse na colsole para Ctrl-Alt-Shift (Muito prático se as mesmas combinações de teclas são
 usadas para outras situações como  Ctrl-Alt-Del ou Windows-E)

O diretório /etc/kvm contém as configurações destas maquinas virtuais e demais scripts necessários para por exemplo iniciá-las automaticamente. Este diretório nas versões mais atuais do KVM não esta mais em uso. Atualmente os arquivos de configuração ficam o diretório /etc/qemu.


KVM utilities

Alguns utilitários importantes do KVM:

  • kvm_stat: O kvm_stat é um script python que colhe estatisticas do modulo de kernel KVM em tempo real. O comando kvm_stat pode ser usado para diagnosticar o comportamento de guests. Em particular, questões relacionadas com a performance. Atualmente, as estatísticas apresentadas são para todo o sistema; o comportamento de todos os convidados em execução é relatado.
    • O comando kvm_stat requer que o modulo de kernel kvm esteja carregado e debugfs esteja montado. Se algum dos requisitos não estiver OK, o comando retornará um erro.
    • Para montar o debugfs:
# mount -t debugfs debugfs /sys/kernel/debug
  • Ao executar o comando, uma tela é exibida, mostrando as estatísticas em tempo real e em Loop. Para finaliza-la executar control+c ou executar o comando com a opção -1, assim ele verifica, exibe as estatísticas e volta ao prompt.

# kvm_stat

kvm statistics

efer_reload                 94       0
exits                  4003074   31272
fpu_reload             1313881   10796
halt_exits               14050     259
halt_wakeup               4496     203
host_state_reload	1638354   24893
hypercalls                   0       0
insn_emulation         1093850    1909
insn_emulation_fail          0       0
...
...
..
.
  • Abaixo a explicação de cada variável exibida:

* efer_reload: O número de "Extended Feature Enable Register (EFER)" recarregados.
* exits : A contagem de todas chamadas VMEXIT.
* fpu_reload: O numero de vezes que o VMENTRY é recarregado o estado FPU. O fpu_reload é incrementado quando o guest utiliza o Floating Point Unit (FPU).
* halt_exits: Numero de saidas dos Guests utilizando a chamada halt. Este tipo de saída é usualmente vista quando o guest está inativo (idle).
* halt_wakeup: Numero de wakeups de um desligamento.
* host_state_reload: Contador de full reloads do estado do host (atualmente MSR setup e Leitura MSR do guest).
* hypercalls: Número de chamadas de serviço do hipervisor guest.
* insn_emulation: numero de instruções do guest emuladas pelo Host.
* insn_emulation_fail: Numero de falhas de tentativas insn_emulation.
* io_exits: Numero de saídas dos guests para acessos de portas I/O.
* irq_exits: Numero de saídas dos guests devido a interrupções externas.
* irq_injections: Numero de interrupções enviadas para os guests.
* irq_window: Número de saídas de guests a partir de uma janela de interrupção pendente.
* largepages: Numero de large pages atualmente em uso.
* mmio_exits: Número de saídas de hóspedes devido ào acesso a memória mapeada I/O (MMIO).
* mmu_cache_miss: Numero de KVM MMU shadow pages criadas.
* mmu_flooded: Contagem de detecção de operações de gravação excessivas para uma página MMU. Isso conta as operações de gravação detectados não de
 operações de gravação individuais.
* mmu_pde_zapped: Numero de PDE-page directory entry. Operações de destruição.
* mmu_pte_updated: Numero de PTE-page table entry. Operações de destruição.
* mmu_pte_write: Numero de PTE-page table entry. Operações de escrita.
* mmu_recycled: Numero de shadow pages que podem ser recuperadas.
* mmu_shadow_zapped: numero de shadow pages inválidas.
* mmu_unsync: Numero de "non-synchronized pages" que ainda não estão desvinculadas.
* nmi_injections: Numero de Non-maskable Interrupt-NMI injections para o guest.
* nmi_window: Número de saídas de guests a partir da janela (outstanding) Non-maskable Interrupt (NMI).
* pf_fixed: Numero de fixed (non-paging) page table entry (PTE) maps.
* pf_guest: Numero de falhas de página injetadas nos guests.
* remote_tlb_flush: Numero de solicitações de liberação remotas (sibling CPU) Translation Lookaside Buffer-TLB.
* request_irq: Numeros de pedidos de saída das interrupções dos Guests.
* signal_exits: Número de saídas de guests devido à sinais pendentes do Host.
* tlb_flush: Numero de tlb_flush operações executadas pelo hypervisor.

Estas variáveis não são as únicas e também alteram conforme a versão do KVM instalado.

  • kvm monitor: Quando o QEMU esta rodando, é provido um console de monitoramento para interação com o QEMU. Através de vários comandos, o monitor permite inspecionar os Guests, fazer algumas alterações de dispositivos, fazer screenshots, controle de vários aspectos das maquinas virtuais. O monitor do QEMU é acessado geralmente diretamente na console. Usando a opção -monitor <dev> a saída pode ser direcionada.
    • Abaixo as principais opções do qemu monitor


* help: O comando Help lista todos os comandos disponíveis. Para mais detalhes de um comando usar conforme o exemplo abaixo:
# help [command] ou ? [command]

* info [option]: Mostra informações dos dispositivos do Guest conforme detalhado abaixo:

    block – block devices such as hard drives, floppy drives, cdrom
    blockstats – estatisticas de leitura e escrita nos block devices
    capture – ativar captura de audio (audio grabs)
    history – historico de comandos da console
    irq – estatisticas das interrupções 
    jit – estatisticas no QEMU's JIT
    kqemu – Se o modulo de kernel kqemu esta sendo utilizado
    mem – lista o mapeamento ativo de memória virtual
    mice – mouse sobre o convidado que está recebendo eventos
    network – dispositivo de rede e VLAN
    pci – Dispositivo PCI sendo emulado
    pcmcia – Dispositivo PCMCIA
    pic – estado de i8259 (PIC)
    profile – Informação de um profile interno, se compilado no QEMU
    registers – Os registradores de CPU
    snapshots – Lista os snapshots das VMs
    tlb – Lista de TLB (Translation Lookaside Buffer), Exemplo, mapeamento entre memória física e virtual
    usb – Dispositivo USB no Hub USB virtual
    usbhost – Dispositivo USB no S.O. do Host
    uuid – Id único da VM
    version – Versão do QEMU
    vnc – informação do VNC

* change: Modifica configurações de dispositivos:, permitindo alterar ou remover midias (parecido com CD-ROM), alterar informações de display, senha do VNC.
# change <device> <setting>
Exemplo:
#(qemu) change ide1-cd0 /path/to/my.iso

* eject: Remove o dispositivo de mídia especificado
# eject [-f] device

* usb_add: Adiciona um arquivo como um USB Flash ao Host
#(qemu) usb_add disk:/tmp/disk.usb

* usb_del: Deleta dispositivo usb conforme Device listado em "info usb".

* sendkey keys: Podemos emular eventos do teclado através do comando sendkey. A sintaxe é conforme o exemplo:
#(qemu) sendkey ctrl-alt-f1

* screendump: Captura um dump de tela e salva um arquivo de imagem PPM
#(qemu) screendump <filename>

* commit: Quando estamos rodando o QEU com a opção -snapshot, comita alerações ao dispositivo, ou todos todos dispositivos
#(qemu) commit <device> ou commit all

* quit: Sair

* savevm: Salva a maquina virtual com uma Tag. Não suporta todos os sistemas de arquivos
#(qemu) savevm <name>

* loadvm: Carrega a maquina virtual conforme a TAG

* stop: Suspende a execução da VM

* cont: reverte a execução do comando stop. Resume a execução da VM

* system_reset: Faz um efeito similar ao botão de reset em uma maquina física. O sistema de arquivos pode ser danificado

* system_powerdown: Efeito similar ao botão de power em uma moderna maquina física. Desligamento por ACPI

* log: Opções de geração de Log, o que deve ser mostrado no arquivo de log 
#(qemu) log <option>

* logfile: Escreve o log no arquivo especificado
#(qemu) logfile /tmp/qemu.log
 
* gdbserver; Inicia um debugger remoto para GNU debugger (gdb). 

* x: Mostra memoria em um endereço virtual especificado usando um formato específico.
#(qemu) x /format address

* xp: Mostra memória em um específico endereço físico usando um formato específico.
#(qemu) xp /<format> <address>
Formato: Usado para especificar o formato de saída que será mostrada a memória. O formato é discriminado como: /[count][data_format][size]
 count: number of item to display (base 10)
 data_format: 'x' for hex, 'd' for decimal, 'u' for unsigned decimal, 'o' for octal, 'c' for char and 'i' for (disassembled) processor instructions
 size: 'b' for 8 bits, 'h' for 16 bits, 'w' for 32 bits or 'g' for 64 bits. On x86 'h' and 'w' can select instruction disassembly code formats.

Exemplo, Exibindo 3 instruções em um processador x86 iniciando na instrução corrente
#(qemu) xp /3i $eip

* print: Print (or p), avalia e imprime a expressão que lhe é dada. O resultado vai ser impresso em formato hexadecimal, mas decimal, também pode
 ser utilizado na expressão.
#(qemu) print 16
0x10

Troubleshooting KVM installations

Algumas soluções de problemas no uso do KVM:

  • Verificar se o KVM esta instalado e funcional:
Erro ao executar uma maquina por QEMU: 
"open /dev/kvm: No such file or directory"
    • Verificar se /dev/kvm esta disponível
    • Verificar se o processador tem suporte a virtualização VT-x, SVM
# cat /pro/cpuinfo
    • Verificar se o modulo do KVM esta inicializado
# lsmod|grep kvm
    • No monitor do QEMU executar o comando abaixo e verificar se aparece a mensagem kvm support: enabled:
#(qemu) info kvm

Fonte

330.4_Other_Virtualization_Solutions

Objetivo do tópico

Description: Candidates should have some basic knowledge and experience with alternatives to Xen and KVM. Key Knowledge Areas:

   Basic knowledge of OpenVZ and LXC
   Awareness of other virtualization technologies
   Basic knowledge of virtualization provisioning tools

Terms and Utilities:

   OpenVZ
   VirtualBox
   LXC
   docker
   packer
   vagrant

Basic knowledge of OpenVZ and LXC

OpenVz

Openvz não é um virtualizador mas sim uma containerização parecida com o 'FreeBSD Jails'. Tecnologias como VMWare e Xen são mais flexíveis pois utilizam virtualização e podem rodar maquinas virtuais com múltiplos sistemas operacionais, ào custo de uma maior sobrecarga necessária para lidar com a virtualização de hardware. OpenVZ usa um único kernel do Linux (com um patch) e portanto, pode executar somente Linux. Todas as maquinas guests funcionam sob a mesma versão de kernel que o host físico.

  • As vantagens, no entanto, são de que a alocação de memória é 'soft' ou seja, a memória não usada em um ambiente virtual pode ser utilizada por outras pessoas ou para o cache de disco. OpenVZ usa um sistema de arquivos comum para que cada ambiente virtual, é apenas um diretório de arquivos que é isolado usando chroot. Versões mais recentes do OpenVZ também permitem que o recipiente tenha seu próprio sistema de arquivos. Assim, uma máquina virtual pode ser clonada apenas copiando os arquivos de um diretório para outro, criando um arquivo de configuração para a máquina virtual e iniciando-a.
  • Kernel: O OpenVZ Kernel é um Kernel Linux, modificado para adicionar suporte ao container OpenVZ. A modificação do kernel provê virtualização, isolamento, gerenciamento de recursos e checkpoint.
  • Virtualização e Isolamento: Cada container é uma entidade separada, e comporta-se em grande parte como um servidor físico faria. Cada container tem seus:
    • Arquivos: Bibliotecas de sistemas, aplicações, /proc e /sys virtualizados, locks virtualizados, etc.
    • Usuários e grupos: Cada container tem seu próprio usuário root, assim como outros usuários e grupos.
    • Árvores de processos: Os containers apenas visualizam seus próprios processos (iniciando por init). PIDs são virtualizados, de modo que o PID init é 1, como deve ser.
    • Rede: Dispositivo de rede virtualizado, que permite que o container tenha seus próprios endereços de IP, bem como configurações de netfilter (iptables), e regras de roteamento.
  • Devices (dispositivos): Se necessário, qualquer container pode ter acesso garantido ao dispositivo real , como interface de rede, porta serial, partições de disco, etc.
  • Gerenciamento de Recursos. O gerenciamento de recursos OpenVZ consiste em três componentes: Quota de disco em dois níveis, Planejamento "equitativo/fair" de CPU e user beancounter. Estes recursos podem ser ajustados com o container em execução sem a necessidade de reboot.
    • Quota de disco em dos níveis (Two-level disk quota): Cada container tem sua própria Quota de disco, medindo em termos de blocos de disco e inodes (+- número de arquivos). Dentro do contaner, é possível usar ferramentas padrões para configurar quotas de disco por usuários e por grupos.
    • Planejamento de CPU(Cpu scheduler): O planejamento de CPU no OpenVZ é uma implementação de dois níveis para estratégia de compartilhamento equitativo.
      • No primeiro nível, o planejador decide qual fatia de tempo de CPU ele dará para qual recipiente, com base nos valores por contêiner cpuunits. No segundo nível, o planejador Linux padrão decide qual processo a ser executado nesse recipiente, usando prioridades padrão do processo Linux. É possível definir valores diferentes para o CPUs em cada recipiente. Tempo real de CPU será distribuído proporcionalmente por estes valores. Limites estritos, tais como 10% do tempo total da CPU, também são possíveis.
  • I/O scheduler: Similar ao cpu scheduler, I/O scheduler no OpenVZ é feito em dois níveis, utilizando Jens Axboe's I/O scheduler no segundo nível. Para cada container é definida uma prioridade I/O, e o planejador (scheduler) distribui a disponibilidade de banda I/O de acordo com as prioridades definidas. Assim um único container não pode saturar o canal de I/O.
  • User Beancounters: É a configuração por container de contador, limites e garantias. Há um conjunto de cerca de 20 parâmetros que se destina a controlar todos os aspectos da operação do recipiente. Isto é feito para evitar que um único container monopolize os recursos do sistema.


  • Checkpointing e live migration: É possível mover container de um servidor físico para outro sem parar o container. O processo é conhecido como checkpointing: o container é congelado e seu estado é salvo em arquivos no disco. Este arquivo pode ser transferido para outras maquinas e containers e podem ser descongelados (restaurados) lá. O delay é de alguns segundos.
  • Algumas Limitações: OpenVZ restringe acessos ao /dev à um pequeno subconjunto. O container pode ser impactado em não ter acesso aos dispositivos que são usados, ao adicionar ou configurar recursos a nível de hardware.
    • OpenvZ é limitado a prover apenas tecologia de VPN baseados no PPP e TUN/TAP. IPsec não é suportado dentro do container, incluindo L2TP.
  • OpenVZ conta com ferramentas de administração e gerenciamento em linha de comando. Para o gerenciamento OpenVZ através de uma interface gráfica, utilizar o projeto Virtuozzo.
  • Instalação:

O processo de instalação do OpenVZ no Debian-7 consiste em: Mais detalhes aqui

    • Ajustar os repositórios para incluir Repositórios OpenVZ
    • Instalar o Kernel OpenVZ
    • Instalar os aplicativos de gerenciamento dos containers
    • Ajustar parametrizações de Kernel em sysctl
  • Arquivo de configuração do Openvz;

O OpenVZ tem os arquivos de configuração de seu serviço básico e também as configurações específicas dos containers.

* Configurações gerais do OpenVZ:
/etc/vz/vz.conf
* Diretório de configurações dos containers:
/etc/vz/conf
  • Criação e gerenciamento dos Containers
    • Após instalado o OpenVZ, podemos criar os containers e gerenciá-los
      • Para criar um container

# vzctl create CTID --ostemplate OSTEMP
Onde:
. CTID - ID do container, pode ser 100 por exemplo
. OSTEMP - Nome do template, pode ser por exemplo: ubuntu-15.04-x86_64-minimal

Os templates podem ser consultados e baixados diretamente para o diretório /var/lib/vz/template/cache/ do host, a partir do site: http://openvz.org/Download/template/precreated.


      • Para ajustar IP e DNS do container
# vzctl set CTID --ipadd a.b.c.d --save
# vzctl set CTID --nameserver a.b.c.d --save
Onde:
a.b.c.d é o IP do container e do DNS server respectivamente

Uma vez feita a instalação e configuração básica, o Container pode ser iniciado e utilizado

  • Alguns comandos importantes de administração do OpenVZ
vzctl: Programa avançado, utilizado para gerenciar containers.

Programa do OpenVZ. Alguns exemplos:
# vzctl enter CTID: Usado para conectar na console do container
# vzctl enter CTID --exec "apt-get install vim && logout": Instala o aplicativo no container e sai.
# vzctl start CTID: Iniciar Container
# vzctl stop CTID: Stop container
# vzctl status CTID: Status container

Vzlist: Lista os containers em execução.

.. Específicos de backup
vzdump: Utilitário de backup para maquina virtual.
vzrestore: Utilitário de restauração de backup OpenVz.
  • Tipos de rede:

O OpenVZ trabalha com basicamente dois tipos de configuração de rede: Venet e Veth

    • Tipo Roteamento (Venet):Virtual Network. O próprio VZ gerencia. Tipo padrão recomendado.
    • Tipo bridge (veth): Virtual Ethernet. Parecido com o funcionamento de rede de uma VM clássica. Placa de rede independente. Precisa ser configurada no S.O. do container.

LXC

LXC é uma interface de 'userspace' que trabalha com os recursos de container do Kernel Linux. Por meio de uma API poderosa e ferramentas simples, ele permite que os usuários do Linux de forma fácil gerenciem containers de aplicação o sistema.

  • Recursos:

Atualmente LXC usa as seguintes características do kernel para 'isolar' processos:

    • Kernel namespaces (ipc, uts, mount, pid, network and user)
    • Apparmor and SELinux profiles
    • Seccomp policies
    • Chroots (using pivot_root)
    • Kernel capabilities
    • CGroups (control groups)

Containers LXC são comumente consideradas um intermediário entre um ambiente chroot e uma maquina virtual full virtualizada. O objetivo do LXC é criar um ambiente padrão Linux mais isolado possível, porém compartilhando o seu Kernel, ou seja sem precisar de um kernel somente para o ambiente LXC.

  • Componentes:

LXC é composto por alguns componentes:

    • Liblxc library
    • Several language bindings for the API:
    • python3 (in-tree, long term support in 1.0.x)
    • lua (in tree, long term support in 1.0.x)
    • Go
    • ruby
    • python2
    • Haskell
    • A set of standard tools to control the containers
    • Container Templates das distribuições
  • Requerimento de versão de Kernel: Linux kernel >= 3.8
  • Instalação:

Na maioria dos casos o LXC está disponível nos repositórios da distribuição, ou nos backports da mesma.

* Exemplo de instalação no Ubuntu:
# sudo apt-get install lxc

Todos os comandos de gerenciamento do LXC assim como os templates ficam disponíveis após a instalação.

  • Segurança de containers
    • Containers sem privilégio são containers mais seguros.
    • LXC aloca um mapa de uid e gid separados para o container
    • Isso significa que uid 0 (root) no recipiente é realmente algo como uid 100000 fora do container. Então, se algo der muito errado e um atacante conseguir escapar do recipiente, ele vai encontrar-se com de tantos direitos como o usuário nobody.
    • Em virtude dos bloqueios de privilégios, um S.O. comun não pode rodar normalmente como um container. Deve ser baixado um template específico da distribuição desejada
  • Comandos de criação e gerenciamento de Containers::
    • Criar um container:
# lxc-create -t template_download -n meu-container
    • Iniciar um container:
# lxc-start -n meu-container -d
    • Verificar status do container:
# lxc-info -n meu-container
# lxc-ls -f
    • Conectar no Shell do Container
# lxc-console -n meu-container
# lxc-attach -n meu-container
    • Finalizar um container
# lxc-stop -n meu-container
    • Remover o container:
# lxc-destroy -n meu-container
  • Os principais Arquivos de configuração são:

* Arquivo de configurações gerais:
# /etc/default/lxc
* Arquivo de configurações de opções de rede:
# /etc/lxc/lxc.conf

Awareness of other virtualization technologies

Virtualbox

VirtualBox é uma aplicação de virtualização cross-platform, o que significa que ele pode ser instalado em arquiteturas Intel/AMD que estejam rodando Windows, Mac, Linux ou Solaris. o VirtualBox estende a capacidade do computador par que possa rodar múltiplos sistemas operacionais dentro de maquinas virtuais ao mesmo tempo. Por exempplo você pode rodar um Linux ou Windows dentro de um Mac, rodar Windows 2008 no seu servidor Linux ou mesmo rodar Linux em um PC com Windows. É possível instalar e rodar multiplas maquinas virtuais praticamente limitados pelo hardware (espaço em disco, e memória).

  • VirtualBox é simples, mas também muito poderoso. Ele pode ser executado em qualquer lugare a partir de pequenos sistemas embarcados ou máquinas desktop, até implantações de data center e até mesmo ambientes de nuvem.
  • Principais características:
    • Portabilidade: VirtualBox roda um largo número de sistemas operacionais 32 e 62 bits. (Várias versões de Windows, Linux, Mac e Solaris). O VirtualBox requer um sistema operacional existente para ser instalado. Assim, pode executar aplicativos existentes ao lado nesse host (Maquina que tem o VirtualBox instalado, também chamada de hospedeira). Maquinas virtuais criadas em um Host podem ser executadas em outro host com outro sistema operacional sem problemas. Adicionalmente as maquinas virtuais podem ser importadas e exportadas usando o formato OVF (Open Virtualization Format).
    • Hardware de Virtualização Não é necessário: Os recursos de processador como VT-x e AMD-V não são necessários para a criação e execução de maquinas virtuais.
    • Adição de funcionalidades de clientes: Chamado de Guest Additions, adicionam funcionalidades caso instalados nas maquinas virtuais, como compartilhamento de pastas e virtualização 3D. Provê um incremento de performance e integrações adicionais entre as maquinas virtuais e o Host.
    • Grande suporte a hardware: Multiprocessamnto SMP para VMs, até 32 CPUs virtuais; Suporte a dispositivos USB; Virtualização de inúmeros dispositivos como controladores SATA, placas de rede, placas de som assim como portas virtuais seriais e parelelas.
    • Suporte ACPI: A Advanced Configuration and Power Interface (ACPI) é suportada. VirtualBox pode até mesmo relatar a sistemas operacionais guests, alertas da ACPI sobre o status de energia do host.
    • Resoluções Multiscreen: o VirtualBox suporta várias resoluções de tela, permitindo inclusive o uso de vários monitores.
    • Suporte ISCSI: Esta feature permite conectar uma maquina virtual diretamente a um storage iSCSI sem passar pelo sistema do Host.
    • Boot-PXE: As VMs (guest) suportam boot por PXE
    • Snapshots: VirtualBox pode salvar snapshots arbitrárias do estado da máquina virtual. Você pode voltar no tempo e reverter a máquina virtual de qualquer snapshot e iniciar uma configuração alternativa da VM a partir daí. É possível criar e apagar snapshots enquanto a máquina virtual estiver em execução.
    • Grupos de maquinas virtuais: VirtualBox fornece um recurso de grupos que permite ao usuário organizar e controlar máquinas virtuais coletivamente, bem como individualmente. Em geral, as operações que podem ser realizadas em grupos são as mesmas que as que podem ser aplicadas para uma Maquina Virtual, ou seja, iniciar, pausar, Reset, Fechar, etc.
    • Arquitetura limpa: VirtualBox é estremamente modular e existe uma separação clara entre os códigos de cliente e servidor
    • Display de maquina remota: A Extensão da Área de Trabalho Remota do VirtualBox (VRDE) permite o acesso remoto de alto desempenho para qualquer máquina virtual em execução. Esta extensão suporta o Remote Desktop Protocol (RDP) originalmente construído para Microsoft Windows, com adições especiais para suporte ao cliente USB completo. Ele suporta diferentes sistemas operacionais na Maquina Virtual e não requer suporte a aplicativos na máquina virtual.
  • Funcionamento do VirtualBox:
    • Na ausência de um hardware com suporte a virtualização (VT-x e AMD-V), o VirtualBox adota a abordagem padrão de virtualização baseada a software. Neste modo guests de 32 bits são suportados.
    • O VirtualBox suporta tanto VT-x como AMD-V. Fazendo uso desta facilidade, o VirtualBox pode rodar cada VM Guest em um espaço de endereço separado. Alguns guests, incluindo maquinas virtuais de 64 bits, os guests SMP e certos OS proprietários, só são suportados por VirtualBox em hosts com virtualização assistida por hardware.
  • Os discos rígidos são emulados em um dos três formatos de imagem de disco:
    • Um recipiente de formato específico do VirtualBox, chamado de "Virtual Disk Image" (VDI), que são armazenados como arquivos (com a extensão .vdi) no sistema operacional hospedeiro;
    • VMware Virtual Machine Format Disk (VMDK);
    • Formato VHD Microsoft Virtual PC. Uma máquina virtual VirtualBox pode, portanto, usar discos que foram criados em VMware ou Microsoft Virtual PC, bem como o seu próprio formato nativo. O VirtualBox pode se conectar a partições raw no host, usando para isso os discos rígidos virtuais. VirtualBox emula IDE (PIIX4 e controladores ICH6), SCSI, SATA (controlador ICH8M) e controladores SAS para que os discos rígidos possam ser anexados.
  • Na configuração de rede Virtual Box utiliza por padrão o NAT para disponibilizar internet as maquinas virtuais. Rede Bridge via adaptador de rede do host ou rede virtual entre as maquinas virtuais guest podem ser configuradas. Até 36 adaptadores de rede podem ser atachados simultaneamente, mas somente 4 são configurados através da interface gráfica.
  • Gerenciamento

O VirtualBox possue duas interfaces padrões para gerenciamento, a primeira gráfica com acesso as configurações das maquinas virtuais e demais opções como rede, storage, etc. As maquinas virtuais podem ser iniciadas, paradas, pausadas por esta interface. Snapshots podem ser criados, e restaurados. Enfim praticamente todas as tarefas necessárias para administração e gerenciamento do VirtualBox.

  • A segunda interface de gerenciamento é o VBoxManage que é um utilitário de linha de comando que inclui opções de clonagem de discos e importação e exportação de sistemas de arquivos. Utilizando a interface de administração por linha de comando, o host não necessita de ambiente gráfico, liberando mais recursos para as maquinas virtuais. Abaixo alguns exemplos de utilização do VBoxManage.
* Lista as VMs registradas no host
# $ vboxmanage list vms

* Inicia a VM; onde VMNAME é o nome do guest
$ vboxmanage startvm "VMNAME"

* Pausar Máquina virtual
$ vboxmanage controlvm "VMNAME" pause

* Resummir Máquina virtual
$ vboxmanage controlvm "VMNAME" resume

* Parar Máquina virtual
$ vboxmanage controlvm "VMNAME" poweroff

* Mostra informações detalhadas da Maquina Virtual
$ vboxmanage showvminfo "VMNAME"


Docker

Docker é uma plataforma para desenvolvedores e sysadmins, com o objetivo de desenvolver, 'embarcar' e rodar aplicações. Docker permite montar rapidamente aplicações de componentes e elimina o atrito que pode vir ao enviar código. Docker permite obter o seu código testado e implantado em produção o mais rápido possível.

  • Aspectos gerais: O Docker funciona em camadas, podemos imaginar uma cebola, para funcionar um aplicativo independente do sistema que o hospeda, ele tem que trazer toda a gama de bibliotecas e do próprio S.O. embutidos, além do próprio aplicativo. Assim o docker inicializa o sistema operacional dentro de um container gerenciado por ele e chama o aplicativo para executar dentro do container, juntamente com as bibliotecas necessárias. Tudo isso deve estar dentro de uma imagem previamente construída por você ou que pode estar disponível no site Hub Docker.
  • Docker consiste em:
    • Docker Engine: Tecnologia de virtualização de container leve e poderosa, combinada com o fluxo de trabalho para construção e containeirização das aplicações.
    • Docker HUB: Serviço SaaS para compartilhamento e gerenciamento das aplicações
  • Você pode fazer um deploy de um container no desktop, servidor físico, maquina virtual, no data-center, assim como nas nuvens privadas ou públicas.
  • Docker não precisa de um hypervisor para funcionar.


  • Partes principais do Docker:
    Partes docker.jpg
    • docker daemon: usado para gereciar os contêineres docker no host onde ele roda
    • docker CLI: usado para comandar e se comunicar com o docker daemon
    • docker image index: um repositório (público ou privado) para as imagens do docker
  • Elementos principais do Docker
    • Contêineres docker: diretórios contendo tudo que constitui sua aplicação
    • docker images: imagens instantâneas dos contêineres ou do S.O. básico (Ubuntu por exemplo)
    • Dockerfiles: scripts que automatizam o processo de construção de imagens
    • Diferença entre imagem e container: Como visto o Docker trabalha com imagens e containers. A imagem é a base para execução. No momento da execução, é criado um container que permite escrita.
  • Elementos do Docker

Os seguintes elementos são usados pelas aplicações que formam o projeto docker.

    • Contêineres Docker
      • Todo o processo de portar aplicações usando docker depende, exclusivamente, do envio de contêineres.
      • Os contêineres docker são basicamente, diretórios que podem ser empacotados (agrupados com tar por exemplo) como qualquer outro, e então, compartilhados e executados entre várias máquinas e plataformas (hosts). A única dependência é ter os hosts ajustados para executar os contêineres (ou seja, ter o docker instalado).
    • LXC-Contêineres Linux foi utilizado até a versão Docker 0.8
    • Na versão 0.9 foi utilizado como engine de isolamento padrão do Docker o libcontainer em substituição do LXC
  • Alguns comandos de gerenciamento do Docker:
* Instalação do aplicativo Docker no ubuntu:
# apt-get install docker.io

** Comandos para trabalhar com imagens

* Listar as imagens atualmente instaladas
# docker images

* Baixar uma imagem para uso posterior
# docker pull NOME_IMAGEM

* Baixar uma imagem (se não foi baixada antes) e roda-la, juntamente a um aplicativo que esta embutido na imagem
# docker run imagem aplicativo 
Exemplo
# docker run -i -t ubuntu /bin/bash

* Criar uma nova imagem (deve ser criado o arquivo de receita Dockerfile)
# docker build

* Remover uma imagemm
# docker rmi imagem

** Comandos para trabalhar com os containers

* Listar os containers em execução
# docker ps

* Parar um container
# docker stop container_ID

* Remover um container
# docker rm container_ID

Basic knowledge of virtualization provisioning tools

packer

Packer é uma ferramenta para criação de maquinas e imagem de containers para múltiplas plataformas a partir de uma configuração de única origem.

  • Packer não substitui o gerenciamento de configuração como Chef ou Puppet. Na verdade, durante a construção de imagens, Packer é capaz de usar ferramentas como o Chef ou Puppet para instalar softwares na imagem.
  • Uma imagem de máquina é única e estática e contém um sistema operacional pré-configurado, com softwares instalados. É usada para criar novas máquinas rapidamente.
  • Packer é fácil de usar e automatiza a criação de qualquer tipo de imagem de máquina. Ela abrange um gerenciamento de configuração moderna, incentivando você a usar um framework como o Chef ou Puppet para instalar e configurar o software dentro de suas imagens Packer feitas.
  • Uma das vantagens do uso do Packer é a possibilidade de implantação de infra-estrutura super rápida. Packer imagens permitem que você rode máquinas totalmente provisionados e configurados em segundos, em vez de vários minutos ou horas.
  • Possibilidade de portabilidade Multi-provedor. O Packer cria imagens idênticas para várias plataformas, você pode executar a produção em AWS(Amazon), testes/QA em uma nuvem privada como OpenStack, e desenvolvimento em soluções de virtualização de desktop, tais como VMware ou VirtualBox. Cada ambiente está executando uma imagem de máquina idêntica, dando portabilidade.
  • Packer na prática:
    • Para instalação o packer deve ser simplesmente baixado do site do projeto e descompactado. Deve ser criado um atalho do comando packer em um diretório de binário.
    • Após 'instalado' as operações de deploy de maquinas virtuais, assim como pós instalação da Maquina que constitui a instalação automática, são feitas por um arquivo .JSON. Este arquivo é dividido internamente em seções:
  "variables": ["..."] → Informações de acesso a nuvem
  "builders": ["..."], → Informações de criação da maquina virtual
  "provisioners":["..."] → Informações de pós-instalação
  • Importante salientar que o packer não faz gerenciamento das maquinas, ele apenas provê as maquinas, porém é possível durante o deploy ocorrer a instalação de programas de maneira automática.
    • Abaixo o exemplo de um arquivo para deploy de uma Maquina na nuvem da Amazon Ec2:
{
  "variables": {
    "aws_access_key": "",
    "aws_secret_key": ""
  },
  "builders": [{
    "type": "amazon-ebs",
    "access_key": "{{user `aws_access_key`}}",
    "secret_key": "{{user `aws_secret_key`}}",
    "region": "us-east-1",
    "source_ami": "ami-de0d9eb7",
    "instance_type": "t1.micro",
    "ssh_username": "ubuntu",
    "ami_name": "packer-example {{timestamp}}"
  }]
}

Uma vez criado o arquivo de configuração, o packer pode ser executado:

  • Primeiro: Verificando se a configuração criada é válida:
# packer validate exemplo.json.
  • Segundo: Executando o Deploy efetivamente
# packer build exemplo.json.
  • Se adicionarmos o bloco abaixo, ao arquivo exemplo.json, então assim que o servidor for provisionado e funcional, será instalado o pacote apache2
{
  "variables": ["..."],
  "builders": ["..."],

  "provisioners": [{
    "type": "shell",
    "inline": [
      "sleep 30",
      "sudo apt-get update",
      "sudo apt-get install -y apache2"
    ]
  }]
}

Podem ser utilizados vários builders diferentes, provisionando configurações iguais de maquinas em diferentes estruturas de nuvens.

vagrant

Vagrant é um automatizador na criação de ambientes com o uso de maquinas virtuais, direcionado a projetos de desenvolvimento.

  • O Vagrant usa e depende do VirtualBox da Oracle para criar dinamicamente máquinas virtuais configuráveis, leves e portáteis.
  • Por meio do fornecimento de máquinas virtuais fáceis de configurar, leves, reproduzíveis e portáteis, direcionadas para ambientes de desenvolvimento, o Vagrant ajuda a maximizar tanto sua produtividade e sua flexibilidade quanto as de sua equipe.
  • O Vagrant fornece a você as ferramentas para construir ambientes de desenvolvimento únicos para cada projeto de uma vez, e depois facilmente derrubá-los e reconstruí-los apenas quando eles forem necessários para que você economize tempo.
  • Para instalar o Vagrant, baixe o pacote ou o instalador apropriado a partir da página de download e faça a instalação usando os procedimentos padrões do sistema operacional ou distribuição. No Debian 8 basta digitar:
# aptitude install vagrant

Após a instalação, ja podemos criar os ambientes e projetos com o Vagrant.

  • O primeiro passo para usar o Vagrant de maneira efetiva é criar um diretório do projeto.
$ mkdir projeto01
$ cd projeto1
  • Uma vez criado o diretório e dentro do mesmo, temos que criar os arquivos necessários para o Vagrant
$ vagrant init projeto01
  • O ambiente está quase pronto para ser utilizado e precisamos baixar a base necessária sobre a qual os programas do projeto irão rodar. Estas bases necessárias são chamadas de Box e estão disponíveis para download diretamente no site da vagrant em: https://atlas.hashicorp.com/boxes/search/ . Com esta informação em mãos vamos fazer o download do box para o projeto.
* Baixando o box Debian-8 mínimo
$ vagrant box add projeto01 https://github.com/holms/vagrant-jessie-box/releases/download/Jessie-v0.1/Debian-jessie-amd64-netboot.box
  • Para iniciar o projeto, ou seja, inicializar o ambiente virtual, digitar:
$ vagrant up

As maquinas virtuais necessárias são criadas e configuradas conforme o arquivo Vagrantfile que fica armazenado no diretório do projeto. Neste arquivo entre outras coisas é possível definir encaminhamento de portas da maquina física para a virtual, políticas de dependências e as automatizações necessárias para criação de um ambiente de desenvolvimento de forma automática.

330.5_Libvirt_and_Related_Tools

Objetivo do Tópico

Description: Candidates should have basic knowledge and experience with the libvirt library and commonly available tools. Key Knowledge Areas:

   libvirt architecture, networking and storage
   Basic technical knowledge of libvirt and virsh
   Awareness of oVirt

Terms and Utilities:

   libvirtd
   /etc/libvirt/
   virsh
   oVirt

libvirt architecture

  • API de virtualização Libvirt: Libvirt é uma coleção de softwares que provê uma via conveniente para gerenciar maquinas virtuais e outras funcionalidades de virtualização, como gerenciamento de storage e interfaces de rede. Este software inclui biblioteca API, o daemon libvirtd e um utilitário de linha de comando chamado virsh.
  • O primeiro objetivo do libvirt é prover uma via única para gerenciar multiplos diferentes provedores ou hypervisors de virtualização. Por exemplo, o comando virsh list --all pode ser usado para listar maquinas virtuais em vários hypervisors suportados, como KVM, Xen, VmWare ESX, etc, não precisando utilizar a ferramenta específica do hypervisor correspondente.
Comparação de arquitetura sem e com libvirt
  • O libvirt provê:
    • Gerenciamento remoto utilizando encriptação TLS e certifcados x509
    • Gerenciamento remoto utilizando autenticação com Kerberos e SASL
    • Controle de acesso local utilizando PolicyKit
    • Zero-conf usando Avahi multicast-DNS
    • Gerenciamento de maquinas virtuais, redes virtuais e storage
    • Cliente API portável para Linux, Solaris e Windows
    • Ela atualmente suporta QEMU, KVM, XEN, OpenVZ e VirtualBox
  • Instalação
    • Para instalar os pacotes necessários, digite a partir de um terminal:
# apt-get install libvirt-bin
    • A instalação do Libvirt no Host cria o daemon libvirtd que pode ser acessado pelo cliente virsh tanto do próprio host como de outro computador a fim de gerenciar as maquinas virtuais.
    • Dependendo do virtualizado, deve ser utilizada uma URI de conexão específica.
    • Exemplo de conexão a um hypervisor
* Conexão a um hypervisor Xen
# virsh -c xen+ssh://root@192.168.0.200/

* Conexão a um hypervisor qemu/KMV
# virsh -c qemu+ssh://root@192.168.0.200/

* Após conectado, o mesmo comando é executado, independente do Hypervior 
# virsh list
  • A console do servidor virtualizado, pode ser visualizada utilizando o programa virt-viewer
# virt-viewer -c xen+ssh://root@192.168.0.200/ ID_VM
  • Arquivos de configuração: Os arquivos de configurações do libvirt ficam em /etc/libvirt/.
    • libvirtd.conf: Arquivo de configuração do daemon responsável por receber as conexões libvirtd
    • libvirt.conf: Utilizado pelo cliente de linha de comando virsh
    • lxc.conf, qemu.conf e outros: Arquivos de configuração dos drivers de conexão conforme o hypervisor utilizado.
  • Configuração das Maquinas Virtuais, como editar os configs XML?

As configurações das VMs ficam armazenadas de acordo com o hypervisor utlizado. Por exemplo, o Xen e o VMWare amrazenam em seus próprios configs e o libvirt traduz para o modo XML quando o sub-comando virsh dumpxml é chamado. Já o qemu e o lxc são armazenados em formato XML no disco e na memória do host. De qualquer modo, editar diretamente os arquivos .XML armazenados no disco não é aconselhado e provavelmente o daemon libvirtd subscreverá as alterações feitas. Para editar as configurações, deve-se editar os parametros XML através dos comandos abaixo:

* Para redes virtuais:(Virtual Networks): net-edit, net-dumpxml
* Storage Pools: pool-edit, pool-dumpxml
* Storage Volumes: vol-edit, vol-dumpxml
* Interfaces: iface-edit, iface-dumpxml 

libvirt networking

  • Rede Virtual:

Existem várias diferentes maneiras para permtir que uma maquina virtual acesse a rede externa. A configuração padrão de configuração de rede inclui bridging e regras de iptables. O tráfico é 'NATeado' através da interface do host para rede externa. Para habilitar a possibilidade de hosts externos acessarem diretamente as maquinas virtuais, então uma configuração de bridge é necessária . Isto permite que uma interface virtual consiga conectar a rede externa através da interface física do host, tornando a Maquina Virtual semelhante a um equipamento físico normal na rede.

  • Como o Libvirt define as configurações de rede:
    • Libvirt usa o conceito de switch virtual de rede, que é uma construção de software no host server, onde a maquina virtual é "conectada" e o tráfico passa diretamente através dele.
    • No host server, o switch virtual de rede é exibido como uma interface de rede, por padrão com a nomenclatura: virbr0
    • Por padrão o switch virtual funciona em modo NAT
    • Cada switch de rede virtual pode disponibilizar um intervalo de endereços IP, fornecendo aos clientes por meio de DHCP. O libvirt utilza o dnsmasq para isso
    • Outro modo de trabalho do Switch virtual é o Routed Mode onde os pacotes são passados através da interface do Host para a rede externa
    • No Isolated mode as Maquinas Virtuais se comunicam através do switch virtual porém não acessam a rede externa ou mesmo não podem ser acessadas da rede externa.
  • O gerenciamento das opções de rede e tipos de roteamento do switch virtual podem ser feitas pelo software com uma GUI gráfica chamado virt-manager ou diretamente nas linhas de comando com o programa virsh conforme as linhas abaixo:
* Listar as configurações de rede;
# virsh -c xen:///system net-list [--all] [--inactive].

* Iniciar uma rede inativa
# virsh -c xen:///system net-start [--network] <network-identifier>

* Parar uma configuração da rede em uso e desalocar todos os recursos provenientes dela (como o dnsmasq por exemplo)
# virsh -c xen:///system net-destroy [--network] <network-identifier>

* Remove uma rede virtual persistente inativa a partir da configuração libvirt.
# virsh -c xen:///system net-undefine [--network] <network-identifier>

* Ativar ou desabilitar a ativação da rede ao iniciar o host
# virsh -c xen:///system net-autostart [--network] <network-identifier> [--disable]

* Fazer o dump XML da configuração da rede 
# virsh -c xen:///system net-dumpxml [--network] <network-identifier>
  • Para edição das configurações da rede utilizar:
# virsh -c xen:///system net-edit nome_rede
  • Para criação de novas configurações de rede, utiliza-se o mesmo mecanismo da criação de maquinas virtuais por XML. Deve-se criar um XML com as configurações da rede e utilizar os comandos abaixo para importa-lo no libvirt.
* Para criar a rede, inicializa-la mas não deixar como definitiva
# virsh -c xen:///system net-create --file ./nova_rede.xml

* Para criar a rede, não inicializa-la e deixar como definitiva
# virsh -c xen:///system net-define --file ./nova_rede.xml

libvirt storage

  • Arquitetura: O gerenciamento de armazenamento do libvirt é baseado em dois conceitos chaver:
    • Volume: Um volume simples de storage pode ser associado a um guest ou usado para criação de novos pools. O volume pode ser um dispositivo de bloco, um arquivo raw ou um arquivo com formato especial.
    • Pool: Fornece uma maneira de pegar uma parte de um storage e cria-lo como um volume. O Pool pode ser usado para gerenciar as coisas, como um disco físico, um servidor NFS, um target iSCSI, um adaptador de host, um grupo LVM.
  • Tipos de Storage Manager: Libvirt suporta os seguintes tipos de Storage Pool:
    Directory backend
    Local filesystem backend
    Network filesystem backend
    Logical backend
    Disk backend
    iSCSI backend
    SCSI backend
    Multipath backend
    RBD (RADOS Block Device) backend
    Sheepdog backend
    Gluster backend
    ZFS backend 
    • Pool de diretório:

Exemplo de configuração XML

      <pool type="dir">
        <name>virtimages</name>
        <target>
          <path>/var/lib/virt/images</path>
        </target>
      </pool>

Tipos de volumes suportados para um pool de diretório:

    raw: a plain file
    bochs: Bochs disk image format
    cloop: compressed loopback disk image format
    cow: User Mode Linux disk image format
    dmg: Mac disk image format
    iso: CDROM disk image format
    qcow: QEMU v1 disk image format
    qcow2: QEMU v2 disk image format
    qed: QEMU Enhanced Disk image format
    vmdk: VMWare disk image format
    vpc: VirtualPC disk image format

Os volumes podem ser criados utilizando a ferramenta qemu-img

    • Pool de filesystem:

Neste caso, o dispositivo de bloco é automaticamente montado. Abaixo exemplo de Configuração XML

    <pool type="fs">
        <name>virtimages</name>
        <source>
          <device path="/dev/VolGroup00/VirtImages"/>
        </source>
        <target>
          <path>/var/lib/virt/images</path>
        </target>
      </pool>

Vários tipos de sistemas de arquivos são suportados, como ext3, ext4, xfs, etc. Os Volumes suportados são os mesmos dos diretórios.


    • Network Filesystem Pool:

Ele requer o nome de um host e caminho de um diretório exportado. Ele vai montar este sistema de arquivos de rede e gerenciar arquivos dentro do diretório de seu ponto de montagem. Geralmente utiliza NFS. Abaixo exemplo de uso XML

    <pool type="netfs">
        <name>virtimages</name>
        <source>
          <host name="nfs.example.com"/>
          <dir path="/var/lib/virt/images"/>
          <format type='nfs'/>
        </source>
        <target>
          <path>/var/lib/virt/images</path>
        </target>
      </pool>

Os tipos de Pools de network suportados são: nfs, glusterfs, cifs. Os Volumes suportados são os mesmos dos diretórios.

    • Pool de Volume Logico:

Baseado em grupo de volume LVM. Para utilizar um grupo de volumes definido anteriormente, basta o nome dele. Para criação de um grupo de volumes, a origem é necessária, conforme exemplo de configuração XML abaixo:

  <pool type="logical">
        <name>HostVG</name>
        <source>
          <device path="/dev/sda1"/>
          <device path="/dev/sdb1"/>
          <device path="/dev/sdc1"/>
        </source>
        <target>
          <path>/dev/HostVG</path>
        </target>
      </pool>
    • Pool de Volume de disco:

Associado a disco adição de disco físico. Os volumes são criados, criando partições no disco. Abaixo exemplo do XML de configuração:

      <pool type="disk">
        <name>sda</name>
        <source>
          <device path='/dev/sda'/>
        </source>
        <target>
          <path>/dev</path>
        </target>
      </pool>
    • Pool iSCSI:

Os volumes devem ser pré-alocados no servidor iSCSI, e não pode ser criado por meio de APIs libvirt.

   <pool type="iscsi">
        <name>virtimages</name>
        <source>
          <host name="iscsi.example.com"/>
          <device path="iqn.2013-06.com.example:iscsi-pool"/>
        </source>
        <target>
          <path>/dev/disk/by-path</path>
        </target>
      </pool>
    • Pool de volume SCSI:

Os volumes devem pré existir nas LUNs e não pode ser criado por meio de APIs libvirt

     <pool type="scsi">
        <name>virtimages</name>
        <source>
          <adapter name="host0"/>
        </source>
        <target>
          <path>/dev/disk/by-path</path>
        </target>
      </pool>
    • Pool e volume Multipath:

Multipath com suporte parcial.

      <pool type="mpath">
        <name>virtimages</name>
        <target>
          <path>/dev/mapper</path>
        </target>
      </pool>
    • Pool de volumes RBD

Suporte parcial e somente utilizando QEMU.

    • Pool de volumes Sheepdog:

Provê alta disponibilidade a nível de bloco. Abaixo exemplo de configuração de Pool

      <pool type="sheepdog">
        <name>mysheeppool</name>
        <source>
          <name>mysheeppool</name>
          <host name='localhost' port='7000'/>
        </source>
      </pool>

Abaixo exemplo de saída de configuração de volume:

<volume>
         <name>myvol</name>
         <key>sheep/myvol</key>
         <source>
         </source>
         <capacity unit='bytes'>53687091200</capacity>
         <allocation unit='bytes'>53687091200</allocation>
         <target>
           <path>sheepdog:myvol</path>
           <format type='unknown'/>
           <permissions>
             <mode>00</mode>
             <owner>0</owner>
             <group>0</group>
           </permissions>
         </target>
       </volume>
    • Pool de volumes Gluster:

O gluster pode ser montado como um diretório de rede, porém não necessariamente, conforme exemplo abaixo:

   <pool type="gluster">
        <name>myglusterpool</name>
        <source>
          <name>volname</name>
          <host name='localhost'/>
          <dir path='/'/>
        </source>
      </pool>

Exemplo de criação de volumes:

      <volume>
         <name>myfile</name>
         <key>gluster://localhost/volname/myfile</key>
         <source>
         </source>
         <capacity unit='bytes'>53687091200</capacity>
         <allocation unit='bytes'>53687091200</allocation>
       </volume>
    • Pool de volume ZFS:

O ZFS deve ser criado anteriormente, abaixo a configuração do XML em Libvirt.

      <pool type="zfs">
        <name>myzfspool</name>
        <source>
          <name>zpoolname</name>
          <device path="/dev/ada1"/>
          <device path="/dev/ada2"/>
        </source>
      </pool>
  • Criando e alterando storages com virsh:

No Virsh, para gerenciar os armazenamentos os seguintes comandos são usados:

** Comandos relacionados a criação e gerenciamento de pools

* Listar Pools configurados do sistema
# virsh -c xen:///system pool-list

* Informação de um Pool
# virsh -c xen:///system pool-info nome_pool

* Editar um Pool
# virsh -c xen:///system pool-edit nome_pool

* Exportar informações de XML de um Pool
# virsh -c xen:///system pool-dumpxml nome_pool

* Criar um novo Pool
# virsh -c xen:///system pool-create arquivo.xml

** Comandos relacionados a criação e gerenciamento de volumes

* Criar um volume a partir de um arquivo .XML
# virsh -c xen:///system vol-create nome_pool arquivo.xml

* Dump das configurações XML de um volume
# virsh -c xen:///system vol-dumpxml nome_volume nome_pool

* Informação sobre o Storage Volume
# virsh -c xen:///system vol-info nome_volume nome_pool

* Listar Volumes de um determinado Pool
# virsh -c xen:///system vol-list nome_pool

Basic technical knowledge of libvirt and virsh

  • Exemplo de uso geral do comando virsh:
 
* Se o virsh esta sendo executado no próprio hypervisor não é necessário conectar por ip ou utilizar o virsh conectando por ssh (qemu+ssh), bastando o acesso
 direto conforme os exemplos abaixo:

* Listar todas máquinas virtuais:
# virsh -c qemu:///system list --all

* Iniciar uma máquina virtual:
# virsh -c qemu:///system start NOME_MAQUINA_VIRTUAL

* Iniciar uma maquina virtual automaticamente ao iniciar o Host
# virsh -c qemu:///system autostart NOME_MAQUINA_VIRTUAL

* Reiniciar uma máquina virtual:
# virsh -c qemu:///system reboot NOME_MAQUINA_VIRTUAL

* Para desligar uma máquina virtual:
# virsh -c qemu:///system shutdown NOME_MAQUINA_VIRTUAL

* Montar um dispositivo de CD-DROM em uma máquina virtual:
# virsh -c qemu:///system attach-disk NOME_MAQUINA_VIRTUAL /dev/cdrom /media/cdrom

* Semelhante a uma hibernação ou pausar uma VM ativa, é possível salvar o estado atual da VM em um aquivo para liberação de memória e CPU.
# virsh -c qemu:///system save NOME_MAQUINA_VIRTUAL NOME_MAQUINA_VIRTUAL-02022015.state

* Para restaurar a VM, executar o comando:
# virsh -c qemu:///system restore NOME_MAQUINA_VIRTUAL-02022015.state
  • As maquinas virtuais criadas pelo libvirt são parametrizadas através de arquivos .XML, ou seja, cada Guest criado em um hypervisor utilizando o libvirt tem uma configuração com todos os seus parametros de configuração dentro de uma formatação .XML. Esta configuração pode ser exportada, assim como novas maquinas virtuais podem ser criadas a partir de arquivos .XML corretamente parametrizados.
* Exportar configurações .XML de uma maquina virtual
# virsh -c xen:///system dumpxml NOME_MAQUINA_VIRTUAL
  • Para criar uma maquina virtual através de um arquivo XML utilizar uma das opções abaixo:
* Criar uma Maquina Virtual a partir de um arquivo XML. Ele vai inicializar a Vm porém não irá salvar as definições da imagem, ou seja, após o desligamento as
 definições não serão salvas 
# virsh -c xen:///system create Arquivo.XML

* Criar uma Maquina Virtual a partir de um arquivo XML. Ele não vai inicializar a VM, porém as definições ficarão salvas.
# virsh -c xen:///system define Arquivo.XML
  • Outra maneira de criar uma Maquina Virtual é utilizando o programa 'virt-install do pacote virtinst, conforme os exemplos abaixo:
# virt-install --name=windows7 --memory 2048 --cdrom /dev/sr0 --os-variant=win7 --disk /mnt/storage/domains/windows7.qcow2,size=20GiB --network network=vm-net
--graphics spice


Awareness of oVirt

oVirt é uma aplicação de gerenciamento de virtualização. A arquitetura da aplicação utiliza o oVirt Management interface (oVirt engine) para gerenciar os nodes, storages e resursos de rede, assim como criar e monitorar maquinas virtuais rodando no data center. oVirt é a base do Red Hat Enterprise Virtualization (RHEV).

  • Algumas características do oVirt:
    • Gerencia múltiplas maquinas virtuais
    • Sofisticada interface de usuário permite gerenciar todos os aspectos de um datacenter de virtualização
    • Escolha de maneiras de alocação de VMs no host
    • Live Migration de VMs de um hypervisor para outro
    • Adição de um novo nó hypervisor é fácil e centralizado
    • Monitorar recursos usados nas VMs
    • Gerenciar cotas de uso de recursos (Storage, compute, rede)
    • Console de Auto-serviço para uso simples (para usuarios-VDI) ou avançado
    • Contruído no hypervisor KVM
    • OpenSource
  • Arquitetura Ovirt: O oVirt é dividido em módulos que cumprem tarefas específicas
    • Host: RH (ou CentOS) 6 ou 7 com KVM
    • Agentes e ferramentas que rodam no HOST(Node): VDSM, QEMU e Libvirt.
    • oVirt Manager: RH (ou CentOS) 6. Gerenciamento centralizado. Aplicação Java e Interface gráfica de gerenciamento
    • Storage Domains: Armazenamento
    • Database: Pode ficar junto com o oVirt. Banco de dados do estado das VMs
    • Acesso a Serviço de diretório externo para autenticação
    • Networking: Links fisicos e logicos
  • Ambiente Ovirt: Definições dentro do uso do oVirt
    • Data Center: Container de mais alto nível tanto para recusrsos físicos como lógicos. è uma coleção de cluster, VM, storage e networks
    • Cluster: É a configuração de hosts físicos e trata Pool de recursos. Hosts no cluster compartilham mesma infra estrutura de rede e storage. No cluster as vms podem ser movidas de um host para outro.
    • Logical Network: É a representação lógica da rede física. Grupo de redes lógicas agrupam trafico de rede e comunicação entre oVirt, Hosts, storage e VM
    • Host: O Host é um servidor físico que pode rodar uma ou várias VMs. Hosts são agrupados no cluster.
    • Storage Pool: É a entidade lógica que contém o repositório padrão para imagens. Pode ser tipo iSCSI, Fibre Channel, NFS ou POSIX. Cada storage pool pode conter vários domains para guardar virtual machine disks, ISO imagens e outros.
    • Virtual Machine: É a maquina virtual (VM) com o sistema operacional e configuração de aplicativos. VMs semelhantes podem ser criadas em um Pool.
    • Template: É um modelo de VM com as configuraçoes pré-definidas. Usando o Template é possível criar várias maquinas virtuais com apenas um passo.
    • Virtual Machine Pool: É um grupo de VMs identicas que estão disponíveis sob demanda por membros do grupo. Pode ser usado para diferentes propósitos. Por exemplo para dvidir VMs por departamentos.
    • Snapshot: É a visão de uma VM com suas configurações em um determinado tempo.
    • User Types: Vários levels de permissões podem ser usados
    • Events and Monitors: Alertas, warnings e outras noticias sobre atividades. Monitor de performance e status de recursos
    • Reports: Baseado no JasperReports. Relatórios gerados pelo report module. Usuarios podem usar comandos SQL para ver dados de hosts, VMs e storages.

330.6_Cloud_Management_Tools

Objetivo do tópico

Description: Candidates should have basic feature knowledge of commonly available cloud management tools. Key Knowledge Areas:

   Basic feature knowledge of OpenStack and CloudStack
   Awareness of Eucalyptus and OpenNebula

Terms and Utilities:

   OpenStack
   CloudStack
   Eucalyptus
   OpenNebula

Basic feature knowledge of OpenStack and CloudStack

OpenStack

OpenStack é uma plataforma Open Source que permite que seja construído a chamada nuvem de infraestrutura como serviço (IaaS) rodando em hardware convencional. Grandes corporações estão por traz do projeto como a NASA por exemplo.

  • Os serviços OpenStack controlam grandes pools de computação, armazenamento e recursos de rede ao longo de um data-center.
  • A tecnologia por trás OpenStack consiste em uma série de projetos inter-relacionados entregando vários componentes para uma solução de infraestrutura de nuvem. Cada serviço oferece uma API aberta para que todos esses recursos possam ser gerenciados através de um painel de controle que fornece aos administradores controle a recursos de provisão através de uma interface web, um cliente de linha de comando, ou kits de desenvolvimento de software que suportam a API. Muitas APIs OpenStack são extensíveis, o que significa que você pode manter a compatibilidade com um conjunto básico de chamadas, proporcionando acesso a mais recursos e inovando através de extensões de APIs. O projeto OpenStack é uma colaboração global de desenvolvedores e técnicos de computação em nuvem. O projeto produz uma plataforma de computação em nuvem padrão aberto para nuvens públicas e privadas. Ao concentrar-se na facilidade de implementação, escalabilidade massiva, uma variedade de recursos avançados, e uma enorme capacidade de extensão, o projeto tem como objetivo oferecer uma solução prática e confiável de nuvem para todos os tipos de organizações.
  • Arquitetura OpenStack

Existe uma gama complexa de serviços que funcionam como sub projetos dentro do guarda-chuva do OpenStack que juntos formam o projeto como um todo. Abaixo listados por tipo de serviço, nomenclatura e descrição.

Arquitetura Openstack.png
  • Serviço disponibilizado - Nome do Projeto - Descrição
    • Dashboard - Horizon - Provê a interface Web, para interagir com os serviços do OpenStack
    • Compute (Computação) - Nova - Gerencia o ciclo de vida das instâncias de computação. Gerencia as maquinas virtuais.
    • Rede - Neutron - Habilita conectividade de rede como um serviço para os serviços OpenStack, como o de computação por exemplo. Suporta as tecnologias e fabricantes mais populares
    • Object Storage (Armazenamento de objetos) - Swift - Armazena e recupera objetos de dados não estruturados. É altamente tolerante a falhas com a sua replicação de dados e arquitetura scale-out.
    • Block Storage (Armazenamento de blocos) - Cinder - Provê armazenamento de bloco persistente para as instâncias.
    • Identity Service (Serviço de identidade) - Keystone - Provê serviço de autenticação e autorização para os demais serviços do Openstack.
    • Image service (Serviço de imagem) - Glance - Armazena e recupera imagens de disco de máquina virtual. OpenStack Compute faz uso disto durante o provisionamento de instância.
    • Telemetry (Telemetria) - Ceilometer - Monitorar e medir a nuvem Openstack para billing, benchmark, escalabilidade, etc.

Cloudstack

CloudStack é uma plataforma de software de código aberto que reúne recursos de computação para construir uma pública, privada e hibrida Infra-estrutura como serviço (IaaS) de nuvens. CloudStack gerencia os nós de rede, armazenamento e computação que compõem uma infraestrutura de nuvem. CloudStack é usado para implantar, gerenciar e configurar ambientes de computação em nuvem.

  • O CloudStack foi comprado da empresa cloud.com pela Citrix e em seguida liberado na licença Apache2 disponibilizado e mantido pela Apache Foundation
Cloudstack arquitetura.jpg
  • Alguns recursos:
    • Configuração sob demanda, serviço de núvem elastico (adaptável). Provedores de serviços podem vender instâncias de máquinas virtuais, volumes de armazenamento e configurações de rede através da Internet.
    • Em uma configuração de nuvem privada, em vez de gerenciar máquinas virtuais da mesma forma como máquinas físicas, com CloudStack uma empresa pode oferecer auto-serviço de máquinas virtuais para os usuários sem envolver os departamentos de TI.
    • Suporte a multiplos hypervisors
    • Gestão de Infra-estrutura altamente escalável: CloudStack pode gerenciar dezenas de milhares de servidores instalados em vários datacenters geograficamente distribuídos. O servidor de gerenciamento centralizado escala linearmente, eliminando a necessidade de servidores intermediários de gerenciamento de nível de cluster. Nenhuma falha de componente único pode causar queda de toda a nuvem. A manutenção periódica do servidor de gerenciamento pode ser realizada sem afetar o funcionamento de máquinas virtuais rodando na nuvem.
    • Gerenciamento de Configuração Automática: CloudStack configura automaticamente as configurações de rede e de armazenamento de cada máquina virtual convidada (guest). CloudStack gerencia internamente um conjunto de dispositivos virtuais para dar suporte a própria nuvem. Estas aplicações oferecem serviços como firewall, roteamento, DHCP, acesso VPN, proxy de console, o acesso ao armazenamento e replicação de armazenamento. O uso extensivo de dispositivos virtuais simplifica a instalação, configuração e gerenciamento contínuo de uma implementação de nuvem.
    • Interface gráfica de usuário: Cloudstack oferece uma interface de administrador web, usada para provisionamento e gerenciamento do cloud, bem como interface web de usuário final, usada para rodar VMs e gerenciar templates. A interface pode ser customizada.
    • API: Cloudstack provê API para acessos de programas ou scripts aos recursos.
    • Alta disponibilidade: CloudStack tem um número de características para aumentar a disponibilidade do sistema. O próprio Management Server pode ser implantado em uma instalação multi-nó onde os servidores são load balancers. MySQL pode ser configurado para utilizar a replicação para proporcionar um limite de falha manual em caso de perda de dados. Para os Hosts, CloudStack suporta ligação NIC e o uso de redes separadas para armazenamento, bem como iSCSI Multipath.
  • Características em destaque:
    • Instalação simplificada, podendo ser instalado em 2 VMs. Como ponto negativo, a instalação pode se tornar engessada
    • Zona de segurança de rede. Isolamento de rede seguro
    • O suporte a hypervisors inclui Citrix XenServer, Oracle VM, Hyper-V
    • Facilidade de uso com uma interface web interativa e documentação bem organizada.

Awareness of Eucalyptus and OpenNebula

Eucalyptus

Assim como seus concorrentes, o Eucalyptus é um software livre e open-source para construir ambientes de nuvens de computação privadas e híbridas compatíveis com Amazon Web Service (AWS). Eucalyptus é um acronimo para "Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems". Ele disponibiliza computação em pool, recursos de storage e rede que podem ser dinamicamente escalados para cima ou para baixo (elasticidade) conforme a alteração da carga de trabalho. Em setembro de 2014 o projeto foi adquirido pela Hewlett-Packard.

  • Comandos do Eucalyptus podem gerenciar tanto a Amazon ou instâncias de Eucalyptus. Os usuários também podem se mover entre as instâncias de uma nuvem privada Eucalyptus e a Amazon Elastic Compute Cloud para criar uma nuvem híbrida. A virtualização de hardware isola as aplicações de detalhes de hardware do computador.


  • Visão geral da arquitetura e nomenclatura (Muito similares com AWS):
    • Images: Uma imagem é uma coleção fixa de módulos de software, software de sistema, software de aplicação e informações de configuração que é iniciado a partir de uma linha de comando conhecida (imutável/fixo). Quando empacotados e enviados para a nuvem Eucalyptus, ela se torna uma imagem de máquina Eucalyptus (EMI).
    • Instances: Quando uma imagem é colocada em uso, ela é chamada de uma instância. A configuração é executada em tempo de execução, e o Cloud Controller decide onde a imagem será executada, o armazenamento e a rede são anexados para atender às necessidades de recursos.
    • IP addressing: Instâncias do Eucalyptus podem ter endereços IP públicos e privados. Um endereço IP é atribuído a uma instância quando a instância é criada a partir de uma imagem. Para os casos que requerem um endereço IP persistente, como um servidor web, Eucalyptus fornece endereços IP elásticos. Estes são pré-alocados pela nuvem Eucalyptus e podem ser transferidos para uma instância em execução.
    • Security: Grupos de segurança TCP/IP compartilham um conjunto comum de regras de firewall. Este é o mecanismo para firewall desligado em uma instancia usando a funcionalidade de bloqueio/liberação de ip address e porta. As instâncias são isoladas no TCP/IP na camada 2.Se isto não estivesse presente, um usuário pode manipular a rede de instâncias e ter acesso a instâncias vizinhos que violam o princípio básico nuvem de isolamento e separação de instâncias.
    • Networking: Há três modos de redes. Em Managed Mode Eucalyptus gere uma rede local de instâncias, incluindo grupos de segurança e endereços IP. No System Mode, Eucalyptus atribui um endereço MAC e atribui interface de rede da instância para a rede física através de Bridge do Controlador do nó HOST. O System Mode não oferecer endereços IP elásticos, grupos de segurança, ou isolamento de VM. Em Static Mode Eucalyptus atribui endereços IP de instâncias. O Modo estático (Static Mode) não oferece IPs elásticos, grupos de segurança, ou isolamento de VM.
    • Access Control: Um usuário de Eucalyptus é atribuído uma identidade e identidades podem ser agrupadas para controle de acesso.

OpenNebula

OpenNebula é uma plataforma de computação em nuvem para o gerenciamento de infra-estruturas de data-centers distribuídos e heterogêneos. A plataforma OpenNebula gere infra-estrutura virtual de um data-center para construir implementações privadas, públicas e híbridas de infra-estrutura como um serviço (IaaS). OpenNebula é um software livre e de código aberto, sujeitos às exigências da Licença Apache versão 2. OpenNebula é uma solução enterprise que inclui todas as características necessárias para fornecer uma oferta de nuvem no local, e para oferecer serviços de nuvem pública.

  • OpenNebula fornece recursos para as duas principais camadas de Virtualização de Data Center e Cloud Infrastructure:
    • Gerenciamento de virtualização de data center: Muitos usuários usam OpenNebula para gerenciar virtualização de data center, consolidar servidores, e integrar os ativos de TI existentes para computação, armazenamento e networking. Neste modelo de implantação, OpenNebula integra diretamente com hypervisors (como KVM, Xen ou VMware ESX) e tem o controle completo sobre os recursos físicos e virtuais, fornecendo recursos avançados para gerenciamento de capacidade, otimização de recursos, alta disponibilidade e continuidade de negócios. Alguns destes usuários também desfrutam de gestão em nuvem do OpenNebula e recursos de provisionamento adicional quando desejam federar centros de dados, implementar cloudbursting, ou oferecer portais de auto-atendimento para os usuários.
    • Gerenciamento de nuvem: Alguns usuários utilizam OpenNebula para fornecer "um multi-tenant", provisionamento de camada de nuvem em cima de uma solução de gerenciamento de infra-estrutura existente (como o VMware vCenter). Esses usuários estão à procura de provisionamento, elasticidade e nuvem multi-tenancy características como provisionamento virtual de datacenter, federação de datacenter ou computação em nuvem híbrida para ligar as infra-estruturas in-house com nuvens públicas, enquanto a infra-estrutura é gerida por ferramentas já conhecidas para a gestão de infra-estrutura e operação.
  • O OpenNebula faz parte dos softwares de gerenciamento de nuvens, como o Openstack, CloudStack e Eucalyptos. Assim como os anteriores, as funcionalidades básicas se repetem e o objetivo é o mesmo