Everlinux’s Blog

Participei hoje do evento “VMware Virtualization Forum 2008“, patrocinado pela VmWare e suas patrocinadoras como a Intel, HP, CA, EMC… Embora o evento maior da VmWare se passe “lá fora”, o evento aqui no Brasil foi bem interessante e tiveram suas inscrições esgotadas.

O evento foi gratuíto, contando com café da manhã, Coffee Break, Almoço e Coquetel de encerramento com o sorteio de alguns prêmios, como dois Ipod Touch e dois Nintendos WII, no qual eu tive a puta sorte de ganhar!!! Nunca ganha nada em sorteio algum, porém dessa vez eu realmente preciso agradecer a Deus pelo presentão de aniversário que eu não teria condições de comprar!!! Alias, agradeço de algum usuário desta maravilhosa tecnologia pudesse deixar alguns dicas para mim a respeito do console

Bom, voltando ao evento em si, com tanta coisa “de graça” bancada pelos patrocinadores, era de se esperar que os mesmos tentassem vender seus produtos durante as palestras. Não gostei de ver apresentações com slides “shareados” dando aquela sensação estranha Deja’vu…

Portando, com as palestras mais voltadas ao publico gerencial e não técnico, o evento deve ter agradado as pessoas que não precisam saber como o motor funciona, querem apenas ligar a chave e esperam que o carro saiam andando — e seus técnicos que se virem para aprender como a coisa funciona

Na parte da manhã tivemos palestras muito interessantes como:

- a Polícia Federal, mostrando sua solução de Virtualização usando Blades (edizendo que os dados ainda não estão todos centralizados, portanto, teoricamente você ainda pode cometer um delito em cada cidade do brasil )

- um estudo da IDC, muito bem apresentado com conteúdo técnico e gerencial bem dosado falando sobre as próximas tendências do mercado, e ainda sugerindo métodos para você virtualizar seu ambiente com a maior segurança possível;

- Tecnologia Quad-Core da Intel, mostrando os aspectos voltados à virtualização e prometendo novidades enormes ainda este ano;

- Case da PRODAM, mostrando os desafios de migrar um Data Center de local, arruma-lo e ainda Virtualizar para abstrair o Hardware. Não posso deixar de citar a quantidade de equipamentos velhos e obsoletos que faziam parte do DC deles, e também as duas toneladas de cabos de rede desnecessários que foram removidos durante a migração, pois os comentários que se escutava era: “está vendo o que é feito com o seu dinheiro dos impostos?”

Acho ainda interessante dizer que na parte da tarde, a cada palestra de 1 hora o pessoal da vmware abriu um espaço de 15 minutos para algum parceiro deles falaram um pouco sobre a empresa, e por incrível que pareça, esses 15 minutos foram extremamente técnicos (NetApp, EMC e Sun com o Rafael Tinoco, que mandou muito bem no FISL 9.0) alegrando eu e mais o restante de público Nerd não-gerente ali presente.

Claro que eu já esperava que o evento seria mais voltado à executivos de Terno e Gravata do que para Nerds de Jeans e Camiseta, portanto não posso dizer que estou decepcionado pois eu sabia que isso não era nenhum FISL. Muito pelo contrário, o lugar foi muito bem escolhido, a organização foi ótima e o evento bastante proveitoso.

Também serviu para encontrar velhos amigos (ex-professores do meu colégio, colegas de classe da faculdade, amigos de outras empresas e figuras que eu só encontro no FISL), além de perder um pouco o medo do inglês tentando fazer uns gringos entender que na maior parte das vezes, nós não usamos Linux porque é “de graça” ou é mais barato do que a solução X ou Y — muito pelo contrário, na maior parte das vezes nós pagamos pelo Linux (SuSE, Red Hat) mas usamos devido a suas características serem superiores do que as dos concorrentes, como por exemplo Desempenho, Estabilidade e Segurança.

E foi bom saber também que as empresas estão correndo atrás em adaptar seus produtos/ soluções para Linux nos próximos meses (o VConverter da VizionCore me parece muito promissor). Além do mais, as empresas que já tem solução para Red Hat ainda não expandiram a mesma para SuSE ou Ubuntu devido a problemas gerenciais, como o treinamento do pessoal de suporte e etc, e não por problemas técnicos.

Muito interessante também o pessoal da NetAPP elogiando o iSCSI que geralmente não é bem vindo por ser uma alternativa barata às caríssimas soluções com FC/HBA…

E para fechar, uma feature do VmWare que eu gostei muito e sinto falta no Xen é o chamado “VmWare LifeCycle Manager” que irá cuidar que as suas máquinas virtuais não se proliferem e espalhem em seu ambiente que nem coelhos, pois como é muito fácil provisionar a mesma é também muito fácil você perder o controle e não ter mais certeza se a VM está ou não sendo utilizada ainda…

Bom, vou parando por aqui e peço desculpas se o texto ficou muito grande ou com as idéias desordenadas… agora preciso descansar pois amanhã terei mais uma migração grande para fazer de madrugada, portanto, um dia desses eu arrumo melhor este texto

Boa noite para vocês
Diga “WI!!!!!!!”
PS: O console só chega semana que vem…

O script anterior foi atualizado contando com algumas melhorias sugeridas pelos seus usuários, como:

- Agora ele é escrito em Inglês, para maior portabilidade com outros usuários do xen ao redor do mundo;

- Você pode fazer backup de somente uma máquina específica, não é mais necessário esperar todo o laço terminar para ver o resultado do mesmo;

- Script parametrizado e funcões sub-divididas e

- Pequenos problemas corrigidos.

#!/bin/bash
# Backup of Xen VM's
# Tiago Cruz - tiagocruz@everlinux.com
# v 1.0 Mar/2008 - Initial version, just backup all VM's
# v 1.1 May/2008 - Now we have functions and parameters

case “$1″ in
list) listVM ;;
all ) backAll ;;
help) showHelp ;;
* ) i=$1; backXen ;;
esac

Caso tenha problemas com o copy-past, você pode pegar o mesmo aqui: back_xen.sh.txt.

Se você usa o Xen, usa Storage Devices sob LVM, e acha importante ter um backup das mesmas, você pode utilizar/ adaptar este pequeno script que tira um snapshot e em seguida faz um “tar.gz” de todo o “/” da sua VM, e a guarda em um local para que você possa restaura-lo caso necessário.

#!/bin/bash
# Backup das VM's do Xen
# Tiago Cruz - tiagocruz@everlinux.com
# Mar/2008
export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

echo "Backup finalizado em `date` com load de `cat /proc/loadavg`" >> $LOG
echo "=================================================================" >> $LOG
echo "=================================================================" >> $LOG


Trecho do log:

Backup ora_busca iniciado em Fri Mar 28 05:02:53 BRT 2008 com load de 1.31 1.33 1.21
Maquina Virtual ora_busca usa ora_busca como storage device
Logical volume “ora_busca_snap” created
Backup de /dev/mapper/Vol_LVM-ora_busca_snap1 - 16G de 95G usados
Criado /dados/backup/ora_busca-xen.tar.gz com 4.9G
Removendo snapshot ja backupeado ora_busca_snap
Logical volume “ora_busca_snap” successfully removed

1-) Estou armazenando as VMs no LVM:

# lvcreate -Ay -L 60G -n vm00 Vol_LVM
# lvcreate -Ay -L 60G -n vm01 Vol_LVM
# lvcreate -Ay -L 60G -n vm02 Vol_LVM

2-) Estou usando o “partimage-0.6.7_beta2.tar.bz2″, pois a versão stable não funciona bem em 64 bits:

3-) A primeira VM deve ser instalada/ configurada manualmente/normalmente. Depois você pode tirar uma cópia dela:

# kpartx -a /dev/mapper/Vol_LVM-vm01
# partimage -z1 save /dev/mapper/Vol_LVM-vm01p1 /LVM/vm01p1.partimg.gz
ou
# partimage -z0 -c -d -f0 save /dev/mapper/Vol_LVM-vm01p1 /LVM/vm01p1.partimg
# kpartx -d /dev/mapper/Vol_LVM-vm01

PS: Note que se você usar compressão (-z1) a geração da imagem vai demorar mais para ser criado, porém com o tamanho bem menor (515M vs 3.7GB) . A restauração da mesma também será mais lenta.

4-) Com base na primeira VM:

# fdisk -l /dev/mapper/Vol_LVM-vm00
Disk /dev/mapper/Vol_LVM-vm00: 64.4 GB, 64424509440 bytes
255 heads, 63 sectors/track, 7832 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/mapper/Vol_LVM-vm00p1 * 2 7395 59392305 83 Linux
/dev/mapper/Vol_LVM-vm00p2 7396 7832 3510202+ 82 Linux swap / Solaris


Você poderá preparar um arquivo, por exemplo, /tmp/parttable, com as especificações das demais partições.
1,7394,83,*
7395,,82,-

Estou usando uma partição primária para o raiz “/” (tipo 83) com ~ 60 GB e o restante para swap (tipo 82).

Você poderá usar o sfdisk e especificar os dados em: sectors, blocks, cylinders ou megabytes.

5-) Crie as partições para a segunda VM:

# dd if=/dev/zero of=/dev/mapper/Vol_LVM-vm01 count=1 bs=512
# sfdisk -uC /dev/mapper/Vol_LVM-vm01 < /tmp/parttable

Se preferir, simplesmente faça o processo manualmente:
# fdisk /dev/mapper/Vol_LVM-vm01

6-) Crie a SWAP para o segundo device:

Será necessário usar o “kpartx” para “mapear” as partições que existem dentro do device LVM:

# kpartx -a /dev/mapper/Vol_LVM-vm01
# ll /dev/mapper/Vol_LVM-vm01*
# mkswap /dev/mapper/Vol_LVM-vm01p2

7-) Restaure a imagem da primeira VM:

- Restauração com GZIP:

# partimage restore /dev/mapper/Vol_LVM-vm02p1 /LVM/vm01p1.partimg.gz
Time elapsed: 10m:59sec
Speed: 5.16 GiB/min
Data copied: 56.64 GiB

- Restauração sem GZIP:

# partimage restore /dev/mapper/Vol_LVM-vm03p1 /LVM/vm01p1.partimg.000
Time elapsed: 1m:15sec
Speed: 2.90 GiB/min
Data copied: 3.62 GiB

Monte a VM e troque endereços de IP, hostname e MAC Address:
# mount /dev/mapper/Vol_LVM-vm01p1 /mnt/xen/
# vi /mnt/xen/etc/sysconfig/network-scripts/ifcfg-eth0
# vi /mnt/xen/etc/sysconfig/network
# vi /mnt/xen/etc/hosts

PS: Use o macgen.py para alterar o MAC address:

$ cat macgen.py
#! /usr/bin/python
# macgen.py script generates a MAC address for Xen guests
#
import random
mac = [ 0×00, 0×16, 0×3e,
random.randint(0×00, 0×7f),
random.randint(0×00, 0xff),
random.randint(0×00, 0xff) ]
print ‘:’.join(map(lambda x: “%02x” % x, mac))

9-) Desmonte a partição, e arrume seu /etc/xen/vm02:

# umount /mnt/xen
# kpartx -d /dev/mapper/Vol_LVM-vm02


Utilize o “uuidgen” para gerar um novo UUID para sua VM.
Não esqueça de trocar também o MAC no campo “vif” e o device LVM, ex:

name = “vm02″
uuid = “82f89076-487e-4de5-ab4a-99ce07c586eb”
maxmem = 1000
memory = 800
vcpus = 1
bootloader = “/usr/bin/pygrub”
on_poweroff = “destroy”
on_reboot = “restart”
on_crash = “restart”
vfb = [ “type=vnc,vncunused=1,keymap=en-us” ]
disk = [ “phy:/dev/Vol_LVM/vm01,xvda,w” ]
vif = [ “mac=00:16:3e:5a:02:a6,bridge=xenbr0″ ]

10-) Inicie a VM e corra para o abraço:

# xm create vm02 -c

Em caso de problemas, consulte este artigo: Xen: Dicas rápidas e problemas resolvidos

1-) Problemas com o reconhecimento do disco durante o boot:

“Booting from Hard Disk
Boot from Hard Disk failed: coud not read the boot disk
FATAL: No bootable device”

Verifique qual é o device utilizado em seu arquivo de configuração. Máquinas Para-Virtualizadas geralmente utilizam ‘xvda’:

disk = [ 'phy:/dev/Vol_LVM/xen_01,xvda,w', ]

Máquinas Full-Virtualizadas (HVM) geralmente utilizam-se de ‘hda’ ou ’sda’.

disk = [ 'phy:/dev/Vol_LVM/xen_01,hda,w', ]

Para saber mais sobre os tipos de virtualizações existentes, consulte este post: Falando um pouco sobre Virtualização

2-) Se a sua placa de rede não é reconhecida depois do boot:

Experimente alterar o config da VM de
vif = [ 'mac=00:xx:xx:xx:xx:bc, bridge=xenbr0', ]

Para:
vif = [ 'type=ioemu, mac=00:xx:xx:xx:xx:bc, bridge=xenbr0', ]

Utilizando uma virtualização de um Red Hat 7.2, deu certo e apareceu a tal da Realtek

3-) Se o ‘xm console’ não funcionar…

- Altere o /etc/inittab (do guest) da seguinte forma:
...
# Console do Xen
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
...

- Dê um reload no inittab:
# /sbin/init q

- Altere o /etc/securetty para permitir o login de root via console:
...
tty11
xvc0

- Se o device não existir, crie-o:
# mknod /dev/xvc0 c 250 187

4-) Para gerar um UUID para uma nova máquina virtual:

# uuidgen

5-) Para gerar um MAC-ADDRESS para outra máquina virtual:

#! /usr/bin/python
# macgen.py script generates a MAC address for Xen guests
#
import random
mac = [ 0x00, 0x16, 0x3e,
random.randint(0x00, 0x7f),
random.randint(0x00, 0xff),
random.randint(0x00, 0xff) ]
print ':'.join(map(lambda x: "%02x" % x, mac))

Acredite: Seu roteador não vai gostar de encontrar duas máquinas com IP’s diferentes e MAC-ADDRESS iguais…

Este é um trabalho acadêmico realizado pelos meus alunos do 3 Semestre do curso de Tecnologia em Redes de Computadores, da FAENAC em São Caetano do Sul.

Os alunos fizeram algo muito interessante: Em um notebook P4 com 512 MB de RAM rodando Windows XP, instalaram o Ubuntu Feisty 7.04 dentro de um Vmware, e dentro desta máquina virtual configuraram um Xen para rodar uma para-virtualização do Ubuntu Edgy 6.10.

Uma pena que eles esqueceram de colocar as fontes das consultas, mas eu sei que uma delas foi retirada do Wiki do Ubuntu, a qual eu mesmo escrevi. E antes que eu esqueça, sim eles serão penalizados por esquecerem de citar a fonte!

A apresentação deles está bem recheada de ScreenShoots das configurações, mas você pode usar o Wiki se quiser fazer algo parecido (está mais legível).

Alunos:
Cezimar Nascimento / Diego Carvalho / Jose Wilter Frazão / Josiel Borges e Rodolfo Domingues

Link para download: Apresentação Acadêmica sobre o XEN

Abraços a todos

Uma dica rápida, colaboração do meu amigo Deny C. Luchetti:

Um problema de usar o virt-manager da Red Hat (também presente no Mandriva 2007.1!) para criar e administrar máquinas virtuais é o fato de que você simplesmente não consegue trocar de CD durante a instalação do guest OS, conforme eu havia comentado no artigo anterior sobre o Xen no Red Hat ES 5

O que acontece é uma pequena salada: O Xen não faz a instalação, ele executa uma versão modificada do qemu para faze-lo. E para trocar os CD’s pelo qemu existe um pequeno truque, bem documentado por sinal. O que não bem estava documentado era que o Xen da Red Hat chama o VNC por padrão quando você pede o console da máquina, e infelizmente, as teclas de atalho do qemu não funcionam dentro do VNC. Entendeu? Se não, leia de novo :-p

Para resolver isso, basta desabilitar o VNC no arquivo de configuração gerado pelo virt-manager (nota: o console gráfico continua funcionando, e até mais rápido!), mais ou menos assim:

name = “suse93″
builder = “hvm”
memory = “500″
disk = [ ‘phy:/dev/lvm/xen_suse93,hda,w’, ‘file:/home/dluchetti/suse93.iso,hdc:cdrom,r’,]
vif = [ ‘type=ioemu, mac=00:16:3e:36:5b:9b, bridge=xenbr1′,]
uuid = “e4e85bc7-b244-9d85-ec7a-b06728e6c70c”
device_model = “/usr/lib64/xen/bin/qemu-dm”
kernel = “/usr/lib/xen/boot/hvmloader”
vnc=0
vncunused=0
apic=0
acpi=0
pae=1
vcpus=1
boot=”d”
ne2000=1
serial = “pty”
on_reboot = ‘restart’
on_crash = ‘restart’

E, finalmente, para trocar a ISO do qemu e continuar a instalação, basta fazer assim:

Teclar “CRTL+ALT+2″ (atenção, não é F2!) e digitar:

(qemu) eject cdrom
(qemu) change cdrom /caminho/para/a/segunda/iso/arquivo.iso

Facinho né?
Abraços e boas virtualizações para vocês

Existe um pequeno truque para instalar corretamente o Windows XP ou o Windows 2003 sob um Hypervisor do Xen (na versão 3.0.3, pelo menos). Na verdade existem dois truques:

- O primeiro é logo na primeira etapa da Instalação, quando ele ainda está na tela de “Detectando Hardware”, algo assim… é logo a primeira tela depois do boot com o CD ou imagem de instalação. Nesse momento, o Xen ainda não entrou em cena, é apenas uma versão modificada do Qemu iniciando a instalação. Mas de qualquer forma, não sei porque raios, a instalação trava em uma tela preta (black screen) e não sai de lá.

Bom, é necessário apertar a tecla F6 e escolher um tipo de computador diferente para o Qemu se ligar e continuar a instalação. Na verdade, devido a um pau do Qemu/Xen, a tecla F6 não funciona e você deve teclar F5 no lugar (mesmo com o windão pedindo a tecla F6!!!).

Na lista que aparece, você deverá escolher “Standard PC” e mandar continuar, como você pode ver na imagem abaixo:

Depois a instalação vai continuar normalmente… até a VM reiniciar e não encontrar mais o CD para continuar a instalação… isso porque não é mais o Qemu, e sim o XEN que entra em ação e pode ser que você (ou alguma GUI como o virt-manager na Red Hat) não tenha colocado a linha do CD-ROM no arquivo de configuração do xen, portanto adicione-a:

O arquivo deve ter uma entrada parecida com essa:

disk = [ ‘file:/dados/winxp.img,hda,w’ ]

Deverá ficar mais ou menos assim:

disk = [ ‘file:/dados/winxp.img,hda,w’,'file:/tmp/winxp.iso,hdc:cdrom,r’, ]

Depois você pode criar sua máquina novamente para continuar a instalação do seu Windão

# xm create winxp

O Red Hat Enterprise Server 5, assim como o Fedora Core 6 tem agora suporte a virtualização “nativo de fábrica”, com a garantia pela produtora do mesmo.

A documentação está muito bem feita, conforme você pode ver nesses links Virtualization e aqui RHEL-5-manual Virtualization

Para fazer a instalação do RH AS 5 como guest do XEN, para-virtualizado ou com a virtualização full, o melhor caminho é você descompactar todas as ISO’s do RH e copiar tudo para uma único diretório acessível via http ou NFS.

# mkdir /mnt/redhat
# mount -o loop /iso/rhel-5-server-x86_64-disc1.iso /mnt/redhat
# cp -av /mnt/redhat /var/www/html/redhat

(algo assim, para todas as ISO’s)

A interface gráfica do red hat pergunta direto a URL caso o sistema seja para-vitualizado, caso não seja, passe o parâmetro abaixo para o instalador para que você possa continuar a instalação via web (isso é necessário porque não é possível alterar as ISO’s durante a instalação — o que deverá ser corrigido no próximo release do RH AS 5)

linux askmethod

Como nem tudo são flores, para iniciar a máquina virtual você pode pegar esse erro:

# xm create -c vm02

I get the following error:
Using config file “/etc/xen/xm02″.
Traceback (most recent call last):
File “/usr/bin/pygrub”, line 26, in ?
import grub.fsys
ImportError: No module named fsys

Este workaround pode te ajudar:
# cp -va /usr/lib64/python2.4/site-packages/grub/ /usr/lib/python/
# ls -l /usr/lib/python/grub/
total 44
drwxr-xr-x 3 root root 4096 Apr 27 17:16 fsys
-rw-r--r-- 1 root root 7733 Oct 15 2006 GrubConf.py
-rw-r--r-- 1 root root 8785 Mar 8 13:35 GrubConf.pyc
-rw-r--r-- 1 root root 8785 Mar 8 13:35 GrubConf.pyo
-rw-r--r-- 1 root root 0 Oct 15 2006 __init__.py
-rw-r--r-- 1 root root 131 Mar 8 13:35 __init__.pyc
-rw-r--r-- 1 root root 131 Mar 8 13:35 __init__.pyo


Um exemplo do arquivo de configuração gerado:

# cat vm02
# Automatically generated xen config file
name = “vm02″
memory = “1024″
disk = [ ‘phy:/dev/vol_lvm/xen_vm02,xvda,w’, ]
vif = [ ‘mac=00:16:3e:64:5c:e9, bridge=xenbr1′, ]
vfb = [”type=vnc,vncunused=1″]
uuid = “cf3861bd-9174-b58c-af84-768e251af31a”
bootloader=”/usr/bin/pygrub”
boot=”/dev/xvda2″
vcpus=1
on_reboot = ‘restart’
on_crash = ‘restart’

É isso ae!
Boa sorte com as VM’s

Virtualização, para quem ainda não sabe, nada mais é do que criar um computador novo dentro do seu computador atual. É como se ele pudesse emular uma máquina inteira: a BIOS, o processador, a memória RAM, o HD… A maior vantagem disso é a possibilidade de instalar vários Sistemas Operacionais no mesmo hardware, sem ter que se preocupar com dual-boot e coisas do tipo.

Como de praxe, temos várias alternativas para se fazer a tal virtualização, entre soluções comerciais e opensources. Porém, fora a virtualização “normal”, temos as sub-divisões chamadas de “para-virtualização” e agora recentemente os chamados de “virtualização completa” que tem uma ajudinha do processador da máquina.

A principal diferença entre eles é que na virtualização convencional, o SO convidado não sabe que está sendo emulado, portanto, o SO principal tem que se virar para fazer o outro não perceber isso. Isso gera um bocado de overhead, e uma lentidão perceptível na emulação como um todo.

Na virtualização completa, ocorre a mesma coisa que na convencional mas com um adendo: Os processadores recentes da Intel (Vanderpoo) ou os da AMD (Pacifica) conseguem auxiliar o SO principal nessa tarefa, gerando menos overhead do que na virtualização convencional. Infelizmente, essas flags do processador só funcionam se o conjunto inteiro do hardware suportar isso, ou seja, processador recente, chipset e BIOS provendo esse suporte.

Agora a para-virtualização ocorre algo bem bacana: O SO convidado sabe que está sendo virtualizado e tira o máximo de proveito disso tendo uma performance bem próxima da mesma em uma máquina “de verdade”. O único problema é que o SO convidado realmente precisa ser modificado para rodar dessa forma, portanto sistemas de código fechado não poderão usufruir desta vantagem, a não ser que sua produtora libere “ports” com essas modificações, provavelmente sob algum custo.

Seja lá qual for sua forma preferida de virtualização, segue alguns programas que podem ser utilizados:

- Comerciais:
VmWare ou o VirtualPC (escrito originalmente pela Connectix, posteriormente comprado pela Microsoft)

- OpenSources:
Convencionais: Qemu ou o Kvm (Kernel-based Virtual Machine);
Para-virtualizadores: Xen;
Full virtualization: Xen, kvm ou o qemu com o módulo kqemu;

Se você quiser aprender um pouco mais sobre o Xen, visite este post anterior que mostra como instalar e configurar o mesmo no Ubuntu Feisty

E, por fim, para saber mais consulte este ótimo artigo da Wikipedia.

Ufa… cansei de escrever… mas depois eu posto uns screenshoots de algumas dessas tecnologias em funcionamento!