-
Notifications
You must be signed in to change notification settings - Fork 1
330_Virtualization
João Batista Correa Junior edited this page Jan 18, 2023
·
1 revision
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
- Hypervisor
- HVM (HardwareVirtualMachine)
- PV(Paravirtualization)- Paravirtualização
- 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):
- À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:
- 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:
- 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
- Fontes:
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
- 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
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.
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.
- Fontes:
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 é 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
- 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.
- Fontes:
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
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.
- 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
# 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"
- Fontes:
- Guia do iniciante: http://wiki.xenproject.org/wiki/Xen_Project_Beginners_Guide
- Guia do iniciante Ubuntu: https://help.ubuntu.com/community/Xen
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.
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.
- Fontes:
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:
- É 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:
- 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:
- 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:
- Fontes:
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:
- Algumas definições sobre Xen Storage:
- Block Device:
- 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.
- 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.
- 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
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' ]
- Fontes:
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
- Fontes:
- http://wiki.xenproject.org/wiki/Xen_Man_Pages#Xen_Project_Configuration
- xl → http://xenbits.xen.org/docs/unstable/man/xl.1.html
- xl.cfg → http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
- xl.conf → http://xenbits.xen.org/docs/unstable/man/xl.conf.5.html
- Scheduler de processameto: http://wiki.xen.org/wiki/Credit_Scheduler
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.
- Cada novo domínio Xen criado com xen-tools terá automaticamente as configurações de:
* 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.
- Fontes:
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.
- Fontes:
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. right
- 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
- Fontes:
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
- Fontes:
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
- Fontes:
- http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
- https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/chap-Virtualization-Configuring_the_Xen_kernel_boot_parameters.html
- Lista de opções: http://www.informit.com/articles/article.aspx?p=1187966&seqNum=4
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
- Fontes:
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 (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 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
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:
# 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
- Fontes:
- https://www.ibm.com/developerworks/community/blogs/ibmvirtualization/entry/kvm_architecture_the_key_components_of_open_virtualization_with_kvm2?lang=en
- http://en.wikipedia.org/wiki/Kernel-based_Virtual_Machine#Internals
- https://wiki.archlinux.org/index.php/QEMU
- http://www.linux-kvm.org/page/RunningKVM
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).
- Criação de uma rede de infraestrutura:
-netdev TYPE,id=NAMEOnde:
- 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
-
User(SLIRP): Este é o tipo padrão de infraestrutura de rede. Não requer privilégios de administrador, porém tem algumas limitações:
-
Tipos de infraestrutura de rede:
* 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
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
- Fontes:
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.
- Fontes:
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></dev> a saída pode ser direcionada.
- Abaixo as principais opções do qemu monitor
* 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
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
- Fontes:
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
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:
- 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;
* 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
- Após instalado o OpenVZ, podemos criar os containers e gerenciá-los
# 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-minimalOs 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 respectivamenteUma 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
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:
- 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.
- Fontes:
- Características: https://openvz.org/Features
- Passo-a-passo de instalação no Debian 7: https://openvz.org/Installation_on_Debian
- Operações Básicas: https://openvz.org/Basic_operations_in_OpenVZ_environment
- Manual básico: http://download.openvz.org/doc/OpenVZ-Users-Guide.pdf
- Configuração OpenVZ http://www.vivaolinux.com.br/artigo/OpenVZ-Virtualizacao-para-servidores-Linux?pagina=3
- http://wiki.openvz.org/Differences_between_venet_and_veth
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:
- Kernel namespaces (ipc, uts, mount, pid, network and user)
- Apparmor and SELinux profiles
- Seccomp policies
- Chroots (using pivot_root)
- Kernel capabilities
- CGroups (control groups)
- 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:
* Exemplo de instalação no Ubuntu: # sudo apt-get install lxcTodos 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:
- Fontes:
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
- 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.
* 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"
- Fontes:
- Manual: https://www.virtualbox.org/manual/ch01.html
- Command Line: http://www.virtualbox.org/manual/ch08.html
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:right
- 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
- 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
- Contêineres Docker
- Alguns comandos de gerenciamento do Docker:
** 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
- Fontes:
- https://docs.docker.com/linux/started/
- https://docs.docker.com/
- https://www.digitalocean.com/community/tutorials/como-instalar-e-utilizar-o-docker-primeiros-passos-pt
- https://coreos.com/docs/launching-containers/building/getting-started-with-docker/
- Informações essenciais sobre funcionameto da arquitetura do docker: http://www.dasblinkenlichten.com/docker-essentials/
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
"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.
- Fontes:
- Documentação: https://www.packer.io/intro/why.html
- Instalação e uso: https://www.packer.io/intro/getting-started/build-image.html
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 upAs 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.
- Fontes:
- Guia de inicialização: http://friendsofvagrant.github.io/v1/docs/getting-started/index.html
- Exemplo de uso: http://flaviosilveira.com/2012/vagrant-facil-e-util/
- Vagrant DOCS versão 2: http://docs.vagrantup.com/v2/getting-started/
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
- 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.
- 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 qemu/KMV # virsh -c qemu+ssh://[email protected]/ * 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://[email protected]/ 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?
* 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
- Fontes:
- Explicação completa da arquitetura: http://www.ibm.com/developerworks/linux/library/l-libvirt/
- http://wiki.libvirt.org
- Rede Virtual:
- 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:
* 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, não inicializa-la e deixar como definitiva # virsh -c xen:///system net-define --file ./nova_rede.xml
- 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:
<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:
<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:
<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:
<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:
<pool type="disk">
<name>sda</name>
<source>
<device path='/dev/sda'/>
</source>
<target>
<path>/dev</path>
</target>
</pool>
- Pool iSCSI:
<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:
<pool type="scsi">
<name>virtimages</name>
<source>
<adapter name="host0"/>
</source>
<target>
<path>/dev/disk/by-path</path>
</target>
</pool>
- Pool e volume Multipath:
<pool type="mpath">
<name>virtimages</name>
<target>
<path>/dev/mapper</path>
</target>
</pool>
- Pool de volumes RBD
- Pool de volumes Sheepdog:
<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:
<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:
<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:
* 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
- Fontes:
- Arquitetura storage: https://libvirt.org/archstorage.html
- Storage Management: https://libvirt.org/storage.html
- XML storage:https://libvirt.org/formatstorage.html
- Exemplo de uso libvirt + disco tipo qcow2: https://www.berrange.com/posts/2009/12/02/using-qcow2-disk-encryption-with-libvirt-in-fedora-12/
- Exemplo de uso libvirt + iscsi: https://www.berrange.com/posts/2010/05/05/provisioning-kvm-virtual-machines-on-iscsi-the-hard-way-part-2-of-2/
- Exemplo de uso geral do comando virsh:
* 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 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
- Fontes:
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.
- Fonte
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
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
- 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.
- Fontes:
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
- 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.
- Fontes:
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.
- Fontes:
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
- Fontes:
- http://opennebula.org/about/technology/