KVM: Administrando máquinas virtuales por consola / KVM with virsh


Listar las Máquinas Virtuales

[root@test ~]# virsh list
 Id    Name                           State
----------------------------------------------------
 1     w2003                        running
 2     centos                       running
 4     fedora                       running

Apagar Máquina Virtual

# virsh shutdown centos

Reiniciar Máquina Virtual

# virsh reboot centos

Forzar / Detener Máquina Virtual

# virsh destroy centos

Obtener Información acerca de la Máquina Virtual

# virsh dominfo centos

Obtener información acerca del Nodo

[root@test ~]# virsh nodeinfo
CPU model:           x86_64
CPU(s):              24
CPU frequency:       1596 MHz
CPU socket(s):       1
Core(s) per socket:  6
Thread(s) per core:  2
NUMA cell(s):        2
Memory size:         32814444 kB

Editar Configuración de Máquina Virtual

# virsh edit centos

Instalar Máquina Virtual CenOS 5.5 utilizando un mirror http:

Con 512Mb de RAM, 4GB de espacio en disco y utilizando la interfaz de red br0 (bridged network).

# virt-install \
 -n centos \
 -r 512 \
 --vcpus=1 \
 --os-variant=rhel5.4 \
 --accelerate \
 -v \
 -l http://mirrors.kernel.org/centos/5.5/os/x86_64/ \
 -w bridge:br0 \
 --vnc \
 --disk path=/tmp/centos.img,size=4 

Podemos conectarnos a dicha máquina virtual haciendo un:

# virt-viewer centos

Ubicación de archivos log:

$HOME/.virtinst/virt-install.log
$HOME/.virt-manager/virt-manager.log
/var/log/libvirt/qemu

Ubicación de archivos de configuración:

/etc/libvirt/qemu/centos.xml

Otras herramientas que podemos utilizar para resolver problemas:

ps, pstree, top
vmstat, iostat, lsof
tcpdump, brctl, ip, ifconfig

entre otras.

 

 

Conectando a instancia de Maquina Virtual de Amazon AWS EC2


Hace un tiempo hice unas pruebas con las máquinas virtuales que ofrece Amazon AWS. Hay una opción interesante de servicio gratuito durante un año para pruebas o para ingresar al producto, y por eso me puse a explorar sus alternativas.

Lo que hay que tener muy en cuenta es que, inclusive para probar, hay que ingresar los datos de una tarjeta de crédito (Microsoft Azure hace lo mismo), y luego del año de prueba se comienza a facturar en función de la demanda (ojo con eso).

En el proceso de creación de la instancia de la maquina virtual, debemos crear una clave .pem que luego nos servirá para ingresar al servidor.

Una vez creada la instancia, en el panel de control, debemos localizar la IP o el nombre DNS de dicha instancia.

Pantallazo-15Luego, utilizaremos el certificado .pem descargado al crear la máquina virtual y conectaremos del siguiente modo:

[usuario@host ~]$ ssh -i usuario_aws.pem ec2-user@ec2-54-242-160-64.compute-1.amazonaws.com

Para estas pruebas yo di de alta un Linux RHEL 6.4

Acceder a servidor SQL Server en Servidor Virtual Azure / Connect to SQL Server on Azure Server


Si necesitamos acceder desde un equipo cualquiera a un servidor de base de datos SQL Server hosteado en una máquina virtual Azure, debemos hacer dos cosas en el servidor virtual:

1) Mapear el puerto 1433 para tener acceso al motor de la base de datos.

Esto lo hacemos en el gestor de máquinas virtuales, seleccionando nuestra máquina virtual, luego EndPoints y agregando una nueva regla.

windowsAzure_endpoints

2) Permitir conexiones entrantes al puerto 1433 en el firewall de Windows.

Esto asumo que ya saben como hacerlo, pero basicamente es agregar una regla en Panel de Control –> Firewall, permitiendo la entrada de los paquetes entrantes por TCP al puerto 1433.

Instalar Servidor SVN en Maquina Virtual Windows Azure / Visual SVN on Windows Azure Virtual Machine


Hace unos días descubrí un servicio de Microsoft para Emprendedores, (gracias Daniel Levi), llamado BizSpark,  que puede resultarnos muy útil en entornos de desarrollo, dado que nos proporciona software para desarrollo sin costo, hosting, entre otros beneficios.

Adicionalmente, obtenemos una cuenta de Windows Azure, donde podemos configurar una máquina virtual con buenos recursos a nuestra disposición y sin costo.

Sin embargo, no pasará mucho tiempo, antes de preguntarnos como hacemos para instalar un servidor svn en dicha cuenta, así que acá dejo una guía de configuración de un servidor svn en un servidor virtual Windows Azure (Gracias Marco Pasin – Microsoft SW Artchitect):

windowsazure_visualsvnquickstart

Enjoy !

Backup de Volúmenes Lógicos en servidor remoto / LVM Snapshot to Remote


Tengo varias máquinas virtuales KVM corriendo en un CentOS. Estas VMs trabajan sobre volúmenes LVM almacenados en /dev/VolGroup01/vm01 , /dev/VolGroup01/vm02, etc
El tema es que necesitaba realizar backups de estos LVMs para tenerlos como respaldo en un equipo backup , y en caso de contingencia levantar la máquina virtual en dicho equipo.
El CentOS que administra todas estas máquinas virtuales, no tiene mas espacio en disco como para hacer snapshots locales de los LVM para luego transferirlos a otro equipo.
Como hacer para mandar estos snapshots a otro equipo? La opción que encontré hasta ahora es la siguiente:

# dd if=/dev/VolGoup01/vm01 | ssh root@equiporemoto “dd of=/var/lib/libvirt/images/vm01.img”

opcionalmente , puedo poner un gzip en el medio para reducir el tamaño del archivo y el tráfico:

# dd if=/dev/VolGoup01/vm01 | gzip |ssh root@equiporemoto “dd of=/var/lib/libvirt/images/vm01.img.gz”

Con esto, teniendo preconfigurada la máquina en el KVM del equipo backup, en caso de necesidad, solo debo descomprimir el archivo y ponerla en marcha.

Si alguien tiene una sicutación similar y le encontró otra vuelta lo escucho ansioso !!!

Physical to Virtual with rsync – Migrar Servidores Fisicos a Virtuales


Resulta que me encuentro con un gran tema: como pasar un servidor (linux por supuesto) de físico a virtual sin tener que reinstalarlo por completo.

Un opción que evalúe fué: http://www.mondorescue.org/ (gracias Mauro) esta aplicación (excelente por cierto) permite realizar un backup completo del sistema operativo y lo almacena en archivos .ISO, uno o varios, del tamaño que le indiquemos.
Esta opción no debe descartarse para esta taréa, aunque merece que sea evaluada en otro post.

La opción que hoy nos interesa es la del rsync.
(Vale la aclaración de que hay cientos de maneras de hacer esta taréa. Yo les planteo la que se me ocurrió a mi y dió resultado.)

Para pasar un equipo fisico a virtual con rsync, lo que hice fué lo siguiente:
Crear la maquina virtual destino con los parámetros adecuados, e instalando el mismo sistema operativo base que el servidor físico (en mi caso un CentOS 5.5).
Para que? Para que el filesystem sea lo mas parecido entre el orígen y el destino.

En el equipo físico realice un rsync como el siguiente:
# rsync -vah –exclude-from=excludes.cfg / root@equipo-virtual:/

En el excludes.cfg puse lo siguiente:

/proc/
/tmp/
/mnt/
/mirror/
/etc/fstab
/etc/grub/
/etc/sysconfig/network-scripts/ifcfg-eth0

En el equipo virtual necesito que el fstab mantenga la configuración original, al igual que la placa de red y el grub. Es por eso que están en la exclusión.

Una vez realizado el rsync, y verificado que se hayan copiado todos los directorios, en la maquina virtual, necesitamos bootear con el CD de intalación en modo rescate “linux rescue” para hacer la reinstalación del grub:

# grub-install /dev/hdc

Si el grub-install nos da el error:
“/dev/hdc does not have any corresponding BIOS drive”
Lo resolvemos agregando la siguiente línea en el /boot/grub/device.map:
(hd2) /dev/hdc

Un detalle muy importante:
Va a ser necesario generar una nueva imagen de los módulos del kernel dado que el initrd del equipo fisico, tiene una entrada (init) donde guarda los nombres de los dispositivos de disco en uso (sda, sdb, etc) y por mas que hayamos guardado el fstab de la máquina virtual, en el momento de booteo va a buscar estos dispositivos definidos en el initrd.
Para crear un nuevo initrd que se utilizará en el booteo hagamos lo siguiente:
Hacemos un backup primero del actual en uso:
# cp initrd-$(uname -r).img initrd-$(uname -r).img.back

Compilamos uno nuevo:
# mkinitrd initrd-$(uname -r).img $(uname -r)

Con esto, la máquina virtual debería reinicar correctamente y deberíamos tener el sistema operativo funcionando igual que en el equipo físico.

KVM: Configurar Bridged Networking – Adaptador Puente


Bueno, resulta que entrando en el mundo de la virtualización, este es un tema de consulta permanente, así que merece la presente entrada.

Aplicable a: Fedora / CentOS / Redhat con KVM / qemu / libvirt

– Deshabilitar el Network Manager. Aparentemente el Network Manager no soporta el bridging.

# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

Otra opción para no deshabilitar el servicio es editar el /etc/sysconfig/network-scripts/ifcfg-eth0 y agregar la entrada: “NM_CONTROLLED=no”.

– Creamos las interfaces bridge:

Editar el /etc/sysconfig/network-scripts/ifcfg-eth0 y agregar la entrada:

BRIDGE=br0

Crear el archivo /etc/sysconfig/network-scripts/ifcfg-br0

con un contenido similar a este:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

Ojo que “Bridge” es case-sensitive y va como en el ejemplo.

– Restarteamos la red

# service network restart

– Configuramos las iptables para que permitan que el trafico sea redirigido forwarded a través del bridge:

# iptables -I FORWARD -m physdev –physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Opcionalemente podemos evitar que el trafico del puente sea procesado por las reglas de las iptables. Esto lo hacemos modificando los parámetros del kernel en el /etc/sysctl.conf y agregando las siguientes líneas:

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Luego, releemos los parametros del kernel:

# sysctl -p /etc/sysctl.conf

– Restarteamos el libvirt daemon:

# service libvirtd reload

Ahora, debería aparecer el “shared physical device” habilitado.

– Podemos chequear el bridge de la siguiente manera:

# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0

Ojo que este bridge es completamente independiente del virbr0.

El virbr0 se utiliza unicamente para hacer NAT.