Configurar acceso remoto para multiples usuarios a libvirt

Configurar acceso remoto para multiples usuarios a libvirt

Debemos editar archivo /etc/libvirt/libvirtd.conf, modificando los siguientes parametros

listen_tls = 0
listen_tcp = 1

Luego se debe reiniciar el servicio libvirtd para que tome los cambios

service libvirtd restart

Luego podemos crear los usuarios que queremos que accedan a nuestro KVM con el comando saslpasswd2 de la siguiente manera:

saslpasswd2 usuario -a libvirt

Esto nos pedira el nuevo password para dicho usuario.

Tambien podemos listar los usuarios existentes en caso de que ya hayamos agregado usuarios con el comando:

sasldblistusers2 /etc/libvirt/passwd.db

Una vez creados los usuarios, los mismos se pueden conectar utilizando virt-manager o virsh, utilizando la siguiente URL:

qemu+tcp://usuario@ip_del_host/system

Ejemplo con virsh:

virsh -c qemu+tcp://usuario@192.168.12.1/system

Create oVirt/RHEV’s VM backup

Create backup of oVirt / RHEV’s VMs

[TOC]

Introduction

I’ve been working with oVirt since version 3.5 as main virtualization platform, from day one i were looking for a tool to create VM backups based on snapshot as many solutions does with VMWARE, after some research i didn’t find a tool that fulfilled my requirements so i decided to create one using oVirt python API.

Requirements

  • oVirt >= 4.0
  • Virtual machine with CentOS 7 with this tools installed, we’ll call this VM bkpvm
  • bkpvm should be on the same oVirt Datacenter of the VM we need to take backup of
  • bkpvm should have enought space to store backups
  • Storage Domain should have enought space to take snapshots

How does it work?

This script should run on bkpvm and it connect to oVirt API to do:
– Create snapshot
– Attach disk to bkpvm
– Create a qcow2 file of the VM’s disk
– Delete snapshot

After finish it creates a qcow2 file for each VM’s disk

Instalation

Prerequisites

Install required repositories on bkpvm:

yum install -y epel-release
yum install -y http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm

Install required packages from repositories configured:

yum install -y qemu-img python-ovirt-engine-sdk4 python-requests git ovirt-guest-agent wget

Download

cd /opt
git clone https://github.com/vacosta94/VirtBKP.git

We need to get our oVirt’s CA in order to establish secure connections to oVirt API

cd /opt/VirtBKP
wget --insecure "https://ovirt.infratic.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA"

Usage

Configure

There is a configuration file default.conf inside VirtBKP folder, that file have all the parameters required by the tool. Should modify this file according your environment as follow:

vim /opt/VirtBKP/default.conf
[bkp]
url             = https://ovirt.example.com/ovirt-engine/api
user            = admin@internal
password        = password
ca_file         = ca.crt
bkpvm           = bkpvm
bckdir          = /mnt/

[restore]
url             = https://ovirt.example.com/ovirt-engine/api
user            = admin@internal
password        = password
ca_file         = ca.crt
storage         = gfs_pool0
proxy           = ovirt.example.com
proxyport       = 54323
  • url: oVirt API URL
  • user: User name
  • password: User password
  • ca_file: Path to ca.crt
  • bkpvm: Name of our bkpvm
  • bckdir: Path to store backups in .qcow2 format
  • storage: Storage domain where we’ll restore our backups
  • proxy: IP or hostname of the ovirt-image-proxy host (Default: ovirt-engine)
  • proxyport: TCP port of the ovirt-image-proxy (Default: 54323)

Create backup

In order to create backups of virtual machines you should use the syntax bellow:

/opt/VirtBKP/backup_vm.py <configuration_file> <vm_name>

Example:

/opt/VirtBKP/backup_vm.py /opt/VirtBKP/default.conf webserver

Restore backup

In order to restore an existing backup you should use the syntax bellow:

/opt/VirtBKP/upload_disk.py <configuration_file> <qcow2_file>

Example

/opt/VirtBKP/upload_disk.py /mnt/webserver_2017-04-28-00h.qcow2

Crear backup de maquinas virtuales oVirt

Crear backup de maquinas virtuales oVirt

Introduccion

Vengo trabajando con oVirt desde la version 3.5 como plataforma de virtualizacion tanto para ambientes de laboratorio, ambientes de produccion y hasta este mismo sitio, desde el inicio busque una forma facil de crear backups de maquinas virtuales basadas en snapshots, luego de investigar encontre de que existia una API pensada para realizar backups de maquinas virtuales, investigando un poco mas encontre scripts que permitian exportar maquinas virtuales de forma a tener un respaldo de las mismas.

Si bien esa solucion me sirvio durante mucho tiempo, rapidamente se volvio muy poco practica a medida que las maquinas virtuales que alojaba crecian, por el simple hecho de que esta solucion necesitaba 3 veces el tamaño de tu maquina virtual debido a que antes de exportar la maquina, la debe clonar.

Una vez que el espacio se volvio un problema decidi, crear mi propio script de backup para maquinas virtuales sobre oVirt.

El proceso es quizas un poco mas complejo que la solucion que acabo de comentar pero necesito menos espacio en disco!. En este documento detallare como funciona y como utilizar la herramienta que cree, espero que le sirva a alguien.

Como funciona

Requisitos:

Los requisitos para utilizar esta solucion son los siguientes:

  • oVirt >= 4.0
  • Una maquina virtual CentOS 7 a la que llamaremos bkpvm
  • Esta maquina virtual debe estar en el mismo Datacenter que las VMs a las que queremos respaldar
  • Esta maquina virtual debe tener espacio suficiente para copiar el disco virtual de las VMs

Que hace exactamente

El script se debe ejecutar en la bkpvm y la misma debe poder acceder a los dominios de almacenamiento donde estan los discos de las maquinas que queremos respaldar.
Los pasos que ejecuta el script son los siguientes:

  • Se conecta a la API de oVirt
  • Crea un snapshot de la maquina que queremos respaldar
  • Adjunta el disco del snapshot a la bkpvm
  • Crea una imagen qcow2 del disco en cuestion
  • Elimina el snapshot
  • Se desconecta de la API de oVirt

Al terminar en forma de respaldo nos queda un archivo qcow2 que no es mas que el disco de la maquina virtual, este archivo lo podemos luego subir al oVirt.

Descargar y utilizar la herramienta

Descargar

Una vez que tenemos nuestra bkpvm instalada debemos instalar un par de paquetes que utiliza el script
Primero debemos habilitar epel y el repositorio de oVirt

yum install -y epel-release
yum install -y http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm

Luego instalamos las librerias necesarias de python

yum install -y qemu-img python-ovirt-engine-sdk4 python-requests git

Luego descargamos la ultima version de la herramienta

cd /opt
git clone https://github.com/vacosta94/VirtBKP.git

Obtener CA de nuestro oVirt, deben reemplazar ovirt.example.com por la url de acceso de su oVirt

cd /opt/VirtBKP
curl --insecure "https://ovirt.example.com/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA" -o ca.crt;

Configurar

Dentro de la carpeta VirtBKP existe un archivo llamado default.conf, ese archivo es el ejemplo de configuracion que utiliza la herramienta, deben modificar ese archivo con sus datos de acceso, el archivo debe quedar de la siguiente forma:

vim /opt/VirtBKP/default.conf
[bkp]
url            = https://ovirt.example.com/ovirt-engine/api
user        = admin@internal
password    = password
ca_file        = ca.crt
bkpvm        = bkpvm
bckdir         = /mnt/

[restore]
url            = https://ovirt.example.com/ovirt-engine/api
user        = admin@internal
password    = password
ca_file        = ca.crt
storage        = gfs_pool0
proxy        = ovirt.example.com
proxyport    = 54323
  • url Es la URL de nuestro oVirt
  • user El usuario a utilizar para las tareas de backup
  • password Password de dicho usuario
  • ca_file Ruta del ca.crt que descargamos anteriormente
  • bkpvm Nombre de la maquina virtual que creara los backups, este nombre debe ser el nombre que se ve en el portal de administracion de oVirt
  • bckdir Directorio donde se almacenaran los archivos .qcow2
  • storage Dominio de almacenamiento donde se restaurara la imagen .qcow2, este nombre debe ser el nombre que se ve en el portal de administracion de oVirt
  • proxy Equipo que se utilizara como proxy para restaurar la imagen qcow2
  • proxyport Puerto de dicho proxy 54323 es el puerto por defecto del ovirt-image-io-proxy

Crear backup

Para crear backups de maquinas virtuales la sintaxis es la siguiente

python /opt/VirtBKP/backup_vm.py <archivo_conf> <nombre_vm_respaldar>

Por ejemplo para crear un backup de una VM de nombre webserver utilizando la configuracion cargada en el archivo default.conf

python /opt/VirtBKP/backup_vm.py default.conf webserver

Restaurar backup

Para restaurar un backup la sintaxis en la siguiente

python /opt/VirtBKP/upload_disk.py <archivo_conf> <archivo_qcow2>

El archivo qcow2 es el archivo que se creo durante la tarea de respaldo, por ejemplo si el archivo se encuentra en /mnt/webserver_2017-04-28-00h.qcow2

python upload_disk.py /mnt/webserver_2017-04-28-00h.qcow2

Porque NO usar particiones para Luns o discos virtuales exclusivos para datos en RHEL/CentOS/SL

Porque NO usar particiones para Luns o discos virtuales exclusivos para datos en RHEL/CentOS/SL

El problema al momento de querer extender un disco virtual o lun de datos es que por mas que el sistema operativo reconozca el tamaño nuevo del disco, al momento de querer utilizar ese espacio nuevo es necesario extender la particion, o de utlima crear una particion nueva. Esto requiere reinicios en caso de que el disco se este utilizando, el reinicio es para que el S.O. vuelva a leer la tabla de particiones.

La forma de evitar tener que reiniciar cada vez que querramos extender nuestra LUN o disco virtual es implementando LVM sobre el disco directo sin particion

Primero crearemos el Volume Group de forma directa sobre la LUN o disco virtual

En este ejemplo lo haremos con un disco virtual exclusivo para datos de 10GB que es el /dev/sdb

Lo primero que tenemos que hacer es verificar que el S.O. vea el disco

# fdisk -l /dev/sdb
 
Disk /dev/sdb: 10.7 GB, 10737418240 bytes, 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Verificamos que el disco este vacio

# dd if=/dev/sdb bs=512 count=2 |strings
2+0 registros leídos
2+0 registros escritos
1024 bytes (1,0 kB) copiados, 0,00250696 s, 408 kB/s

No nos muestra nada por lo tanto esta vacio

Formateamos el disco completo como Physical Volume

# pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created

Creamos un Volume Group

# vgcreate testvg /dev/sdb
  Volume group "testvg" successfully created

Luego creamos un Logical Volume de pruebas con 8G

# lvcreate -n testlv -L8G testvg
  Logical volume "testlv" created.

Creamos un FS XFS sobre el volumen y lo montamos en el /mnt

# mkfs.xfs /dev/testvg/testlv
# mount  /dev/testvg/testlv /mnt
# df -h /mnt/
S.ficheros                Tamaño Usados  Disp Uso% Montado en
/dev/mapper/testvg-testlv   8,0G    33M  8,0G   1% /mnt

Ahora ampliamos el disco desde la consola de administracion de VMWARE o el virtualizador que usemos (esto no lo voy a mostrar aca)

Es necesario re-escanear el disco desde el S.O. para que este vea el nuevo tamaño

Esto lo hacemos con el siguiente comando:

echo 1 > /sys/class/block/#dispositivo/device/rescan

Donde #dispositivo es el nombre de nuestro disco en cuestion, en este caso lo haremos sobre la sda.

echo 1 > /sys/class/block/sdb/device/rescan

Hecho esto el S.O. ya deberia reconocer el nuevo tamaño, por ende podemos ampliar nuestra particion

#  fdisk -l /dev/sdb
 
Disk /dev/sdb: 21.5 GB, 21474836480 bytes, 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Luego debemos extender el Physical Volume

# pvresize /dev/sdb
  Physical volume "/dev/sdb" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized
# vgs testvg
  VG     #PV #LV #SN Attr   VSize  VFree
  testvg   1   1   0 wz--n- 20,00g 12,00g

Con el comando vgs verificamos que el Volume Group reconocio el nuevo espacio. Luego podemos extender nuestro Logical Volume para que llegue a los 18G

# lvresize -L18G /dev/testvg/testlv
  Size of logical volume testvg/testlv changed from 8,00 GiB (2048 extents) to 18,00 GiB (4608 extents).
  Logical volume testlv successfully resized.

Con esto ya podemos extender nuestro FileSystem

# xfs_growfs /dev/testvg/testlv
meta-data=/dev/mapper/testvg-testlv isize=256    agcount=4, agsize=524288 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=2097152, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 2097152 to 4718592
 
 
# df -h /dev/testvg/testlv
S.ficheros                Tamaño Usados  Disp Uso% Montado en
/dev/mapper/testvg-testlv    18G    33M   18G   1% /mnt

Con esto evitamos la necesidad de reiniciar nuestros equipos para extender nuestros discos virtuales o LUNs

Uno de los puntos mas importantes es detectar si los discos contienen datos antes de formatearlos.

Detectar si un disco esta siendo utilizado

Para detectar si un disco esta siendo utilizado podemos utilizar el comando dd de la siguiente forma:

dd if=/dev/sdb bs=512 count=2 |strings
Si el disco esta vacio deberia mostrar algo parecido a lo siguiente

# dd if=/dev/sdb bs=512 count=2 |strings
2+0 registros leídos
2+0 registros escritos
1024 bytes (1,0 kB) copiados, 0,00250696 s, 408 kB/s

En caso que tenga LVM deberia de mostrar algo parecido a lo siguiente:

# dd if=/dev/sdb bs=512 count=2 | strings
2+0 records in
2+0 records out
LABELONE
LVM2 0016hxjXHBW8Bm1xLnQZoEBDoKzWi0x8IRG
1024 bytes (1.0 kB) copied, 7.9217e-05 s, 12.9 MB/s

Extender disco virtual creado con la opción Thick Provision Eager Zeroed VMWare 5.5

Extender disco virtual creado con la opción Thick Provision Eager Zeroed

Si tenemos un disco del tipo Thick Provision Eager Zeroed compartido entre 2 nodos y la extendemos a traves de la interfaz grafica la maquina virtual tendrá errores al levantar, errores como:

An error was received from the ESX host while powering on VM nodo1.
Failed to start the virtual machine.
Module DiskEarly power on failed.
Cannot open the disk '/vmfs/volumes/55788bcb-66e4405e-8d19-441ea15c3790/nodo1/nodo1_1.vmdk' or one of the snapshot disks it depends on.
Thin/TBZ/Sparse disks cannot be opened in multiwriter mode.
VMware ESX cannot open the virtual disk "/vmfs/volumes/55788bcb-66e4405e-8d19-441ea15c3790/nodo1/nodo1_1.vmdk" for clustering. Verify that the virtual disk was created using the thick option.

El problema radica en que cuando se extiende a traves de interfaz grafica el disco con el nuevo tamaño queda en formato Thick Provison Lazy Zeroed y dicho formato no soporta estar activo en varias maquinas virtuales

La forma correcta de hacerlo

La forma correcta de hacerlo es la siguiente:

  • Apagamos todos los nodos que accedan al disco compartido
  • Ingresamos por SSH a uno de los nodos esx que tenga acceso al DS
  • Extendemos el disco virtual con el comando vmkfstools

La sintaxis del comando vmkfstools para este caso es la siguiente:

vmkfstools -X <nuevo_tamaño> -d eagerzeroedthick <ruta_del_disco_virtual>

La <ruta_del_disco_virtual> normalmente seria la siguiente:
/vmfs/volumes/<Nombre_del_DS>/<nombrevm>/<archivo>.vmdk

Ej:
Si queremos extender un disco virtual hasta los 100GB, teniendo en cuenta los siguientes datos:

DataStore: VSP
Nombre de la maquina virtual: nodo1
Nombre del disco: nodo1.vmdk

El comando seria

vmkfstools -X 100G -d eagerzeroedthick /vmfs/volumes/VSP/nodo1/nodo1.vmdk

Luego podemos encender de vuelta todas las maquinas virtuales y las mismas ya deberian de ver el disco con el nuevo tamaño

Es muy importante que la extension se haga de la forma comentada, caso contrario las VM no encenderian y se tendrian que realizar varias tareas para recuperar los datos

Migrar discos RDM a VMFS VSphere 5.5

Migrar discos RDM a VMFS

En caso de tener un cluster con discos compartidos RDM, los cuales queremos migrar a VMFS lo podemos hacer sin tener tanto downtime.

Se deben seguir los siguientes pasos:

  • Apagar nodo inactivo y configurarlo para usar VMFS como disco compartido
  • Prender el nodo inactivo y luego hacer switch-over de los servicios al mismo, de manera a liberar el otro nodo
  • Apagar el otro nodo y configurarlo para usar VMFS como disco compartido, dejar el equipo apagado
  • Eliminar el disco RDM del nodo que quedo apagado.
  • Bajar los servicios en el asusisv-pm2, eliminar el disco RDM y eliminar el archivo de referencia.
  • Volver a agregar el disco RDM con compatibilidad Virtual
  • La SCSI Controller debe ser Paravirtual
  • Levantar los servicios
  • Migrar los discos RDM a discos sobre VMFS del tipo Thick Provision Eager Zero
  • Levantar el otro nodo y probar que todo es funcionando correctamente

En este caso tendremos el siguiente entorno:

Cantidad de nodos del Cluster: 2
Sistema Operativo de los nodos: CentOS 7.0 x86_64
Version del virtualizador: VMWARE esx5.5
Herramienta administrativa: vSphere Web Client
Servicio de Cluster: Pacemaker
Modo del Cluster: Activo/Pasivo
Nombres de host: asusisv-pm1 y asusisv-pm2
Los servicios se estan ejecutando en el asusisv-pm1

Preparar nodo inactivo.

Apagar nodo inactivo

Primero debemos apagar el nodo que este inactivo, en este caso el asusisv-pm2

[root@asusisv-pm2 ~]# poweroff
Connection to asusisv-pm2 closed by remote host.
Connection to asusisv-pm2 closed.
Configurar VM para usar VMFS como disco compartido

Cambiar el Bus Sharing Controladora SCSI

Una vez que apagamos el equipo debemos asegurarnos que las controladoras SCSI donde estaran los discos compartidos esten en modo virtual.
Vamos a "Edit VM setting" -> "SCSI Controller 1", debemos asegurarnos que este en modo Virtual, es decir "SCSI Bus Sharing = Virtual"

Agregar Parametros a la VM

Para utilizar discos sobre VMFS como compartidos entre 2 o mas VMs es necesario modificar ciertos parametros en cada VM, los parametros son los siguientes:

  • disk.locking = false
  • scsi1:0.sharing = multi-writer
  • scsi1:0.shared = true

En el caso de los ultimos 2 parametros se debe agregar por cada disco que querramos compartir, por ejemplo si queremos compartir el disco 4 de la controladora scsi 3, deberiamos agregar los siguientes parametros:

scsi3:4.sharing = multi-writer
scsi3:4.shared = true

Esta tarea la podemos ingresando a "Edit VM setting" -> "VM Options" -> "Advanced" -> "Edit Configuration"

Una vez en la ventana de configuracion de parametros hacemos click en "Add row" y ingresamos cada parametro.

En nuestro caso nuestra controladora SCSI es la numero 2 y usaremos el disco 0, es recomendable agregar mas entradas de las que necesitamos para en el futuro poder agregar discos virtuales sin problemas, debido a que es necesario que la VM este apagada para modificar o agregar estos parametros, en nuestro ejemplo agregaremos lo siguiente:

disk.locking=false
scsi1:0.sharing = multi-writer
scsi1:0.shared = true
scsi1:1.sharing = multi-writer
scsi1:1.shared = true
scsi1:2.sharing = multi-writer
scsi1:2.shared = true
scsi1:3.sharing = multi-writer
scsi1:3.shared = true

Luego le damos en "OK", esperamos a que aplique los cambios y procedemos a prender la VM.

Preparar nodo activo

Una vez que culminamos las configuraciones del nodo inactivo debemos hacer switch-over de los servicios de manera a poder apagar el nodo activo, en este caso el asusisv-pm1.

Apagamos el equipo

[root@asusisv-pm1 ~]# poweroff
Connection to asusisv-pm1 closed by remote host.
Connection to asusisv-pm1 closed.

Una vez que el equipo este apagado debemos realizar la misma tarea que se realizo con el otro nodo.

Configurar VM para usar VMFS como disco compartido

Cambiar el Bus Sharing Controladora SCSI

Una vez que apagamos el equipo debemos asegurarnos que la controladora SCSI donde estan los discos compartidos este en modo virtual

Vamos a "Edit VM setting" -> "SCSI Controller 1", debemos verificar que este en modo Virtual, es decir SCSI Bus Sharing = Virtual

Agregar Parametros a la VM

Esta tarea la podemos ingresando a "Edit VM setting" -> "VM Options" -> "Advanced" -> "Edit Configuration"

Una vez en la ventana de configuracion de parametros hacemos click en "Add row" y ingresamos cada parametro.

En nuestro caso nuestra controladora SCSI es la numero 2 y usaremos el disco 0, es recomendable agregar mas entradas de las que necesitamos para en el futuro poder agregar discos virtuales sin problemas, debido a que es necesario que la VM este apagada para modificar o agregar estos parametros, en nuestro ejemplo agregaremos lo siguiente (el orden de los parametros no afecta):

disk.locking=false
scsi1:0.sharing = multi-writer
scsi1:0.shared = true
scsi1:1.sharing = multi-writer
scsi1:1.shared = true
scsi1:2.sharing = multi-writer
scsi1:2.shared = true
scsi1:3.sharing = multi-writer
scsi1:3.shared = true

Luego le damos en "OK".

Luego debemos eliminar el disco RDM del equipo, sin eliminar el archivo de referencia, esperamos a que aplique los cambios dejamos apagada la VM.

Migrar de RDM a VMFS

Sacar y volver a agregar el disco RDM

Desde el vSphere Web Client debemos buscar nuestra VM, en este caso asusisv-pm2, hacemos click derecho sobre el nombre luego hacemos click en Edit Settings, luego eliminamos el disco RDM, eliminando el archivo de referencia del Datastore. Esto lo podemos hacer con la maquina encendida pero debemos asegurarnos de que ningun servicio acceda al disco.

Luego debemos volver a agregar el disco RDM pero con compatibilidad Virtual.

Vamos a New device -> RDM -> Add y seleccionamos la lun que deseamos migrar.

Elegimos la lun

Al agregar el RDM debemos asegurarnos de que el Compatibility Mode este en Virtual y que el SCSI Controller este en uno de los configurados en los pasos previos.

Migracion de datos

Luego volver a hacer click derecho sobre nuestra maquina virtual y hacemos click en Migrate.

En la ventana "Select Migration Type", debemos seleccionar "Change datastore", luego le damos Next

En la ventana de Select Datastore, hacemos click en Advanced >>. Luego en la columna disk format de nuestro disco RDM debemos cambiar a Thick Provision Eager Zero, en la columna de Storage debemos seleccionar el Datastore donde queremos guardar el disco compartido, el datastore debe ser diferente de donde estaba el archivo de referencia, caso contrario no hace nada.

Le damos Next y confirmamos la tarea. Una vez que termine la tarea podemos agregar el disco virtual al otro nodo y luego prenderlo

Agregar el disco ya migrado al otro nodo

Luego de culminar la migracion vamos al otro nodo que habia quedado apagado, le damos Edit settings, luego en New device, elegimos Existing disk, luego al hacer click en Add nos mostrara una ventana en la cual debemos navegar dentro del DataStore hasta encontrar el disco virtual.

Si no recordamos la ubicacion del disco virtual podemos fijarnos en la lista de eventos del nodo desde el cual lanzamos la migracion, en este caso el asusisv-pm2, vamos a la VM y hacemos click, luego en Monitor -> Events. En la tarea de migracion dice el nombre del datastore, el disco en este caso se encontrara en un directorio llamado asusisv-pm2 dentro de dicho datastore.

Al agregar el disco debemos asegurarnos de que este en la SCSI Controller que configuramos en los primeros pasos.

Luego aplicamos y prendemos la maquina virtual.

Se recomienda probar hacer switch-over para probar que los 2 nodos puedan acceder sin problemas al disco

Una vez que se culminaron todos estos pasos y de que hayamos verificado que todo funcione correctamente podemos despresentar la LUN que antes se usaba como RDM

Ampliar particiones en equipos CentOS/RHEL 5/6/7 sobre VMWARE

Ampliar particiones en equipos CentOS/RHEL 5/6/7 sobre VMWARE

Una vez que agrandamos el disco virtual desde la consola de administracion de VMWARE es necesario seguir un par de pasos para poder utilizar el espacio agregado

Re escanear el dispositivo desde el S.O.

Es necesario re-escanear el disco desde el S.O. para que este vea el nuevo tamaño
Esto lo hacemos con el siguiente comando:

 echo 1 > /sys/class/block/#dispositivo/device/rescan

Donde #dispositivo es el nombre de nuestro disco en cuestion, en este caso lo haremos sobre la sda.

echo 1 > /sys/class/block/sda/device/rescan

Hecho esto el S.O. ya deberia reconocer el nuevo tamaño, por ende podemos ampliar nuestra particion

Ampliar particion

Para ampliar la particion es necesario eliminar y volver a crear la particion en cuestion, lo que se debe tener en cuenta es que el bloque de inicio debe ser el mismo y el bloque final debe ser mayor, en caso de que el bloque de inicio sea diferente perderemos los datos, para esta tarea utilizamos el comando fdisk:

[root@server ~]# fdisk /dev/sda
 
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
 
Command (m for help): p
Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000a9e6f
   Device Boot      Start         End      Blocks   Id  System
 
/dev/sda1   *        2048     1026047      512000   83  Linux
/dev/sda2         1026048    41943039    20458496   8e  Linux LVM

Eliminamos la particion

Command (m for help): d
Partition number (1,2, default 2): 2
Partition 2 is deleted

Creamos de vuelta la particion teniendo en cuenta el bloque inicial y el final

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (2-4, default 2): 2
First sector (1026048-62914559, default 1026048): 1026048
Last sector, +sectors or +size{K,M,G} (1026048-62914559, default 62914559):[ENTER]
Using default value 62914559
Partition 2 of type Linux and of size 29.5 GiB is set

Cambiamos el tipo de particion para que quede de la misma manera

Command (m for help): t
Partition number (1,2, default 2): 2
Hex code (type L to list all codes): 8e
Changed type of partition 'Linux' to 'Linux LVM'

Imprimimos para comparar con la tabla de particiones inicial

Command (m for help): p
Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000a9e6f
   Device Boot      Start         End      Blocks   Id  System
 
/dev/sda1   *        2048     1026047      512000   83  Linux
/dev/sda2         1026048    62914559    30944256   8e  Linux LVM

Finalmente guardamos los cambios

Command (m for help): w
The partition table has been altered!
 
Calling ioctl() to re-read partition table.
WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table. The new table will be used at
the next reboot or after you run partprobe(8) or kpartx(8)
Syncing disks.

Si nos fijamos en el ejemplo anterior al volver a crear lo unico que varia es el bloque de inicio y el bloque.

Para que se reconozca el nuevo tamaño de la particion es necesario reinciar el equipo

reboot

Ampliar PV

Para que el volume group pueda utilizar el nuevo espacio es necesario redimensionar el pv, lo cual lo hacemos con el comando pvresize

pvresize  /dev/sda2
  Physical volume "/dev/sda2" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

Una vez que ejecutamos el pvresize ya podemos usar el nuevo espacio en el Volume Group

Crear usuarios locales en oVirt > 3.5

Crear usuarios locales en oVirt > 3.5

Gracias a la extension ovirt-aaa-jdbc podemos gestionar los usuarios locales del oVirt, dichos usuarios son almacenados en la base de datos del oVirt por lo tanto no requieren de una fuente externa de autenticacion.

Para crear un usuario lo podemos hacer con el comando ovirt-aaa-jdbc-tool, la sintaxis es la siguiente:

ovirt-aaa-jdbc-tool user add nombredelusuario

Por ejemplo para crear un usario stonith

# ovirt-aaa-jdbc-tool user add stonith
adding user stonith...
user added successfully
Note: by default created user cannot log in. see:
/usr/bin/ovirt-aaa-jdbc-tool user password-reset --help.

Con el comando anterior creamos el usuario pero todavia no lo podemos utilizar debido a que falta asignarle un password, la sintaxis para setear un password a un usuario es la siguiente:

/usr/bin/ovirt-aaa-jdbc-tool user  password-reset usuario --password=pass:newpassword --password-valid-to='AAAA-MM-DD HH:MM:ssZ'

Por ejemplo para asignar "12345678" como password para el usuario creado en el ejemplo anterior usaremos el siguiente comando:

# /usr/bin/ovirt-aaa-jdbc-tool user password-reset \
stonith --password=pass:12345678 \
--password-valid-to='2600-12-02 00:00:00Z'
 
updating user stonith...
user updated successfully

Debemos tener en cuenta la opcion --password-valid-to porque si no lo seteamos el toma la fecha actual, es decir al crear nuestro password ya no seria valido.

Una vez que creamos y que asignamos un password al usuario podemos asignarle permisos de la UI de oVirt

Solucionar error Probably resource factory threw an exception.: () oVirt/RHEV vdsm

Solucionar error Probably resource factory threw an exception.: () oVirt/RHEV vdsm

Si al tratar de realizar alguna tarea sobre nuestros discos virtuales, es decir:

  • snapshots
  • clonaciones
  • exportaciones
  • importaciones
  • storage live migration

En la lista de eventos del oVirt GUI se presenta el siguiente error:

Probably resource factory threw an exception.: ()

Y en los logs del vdsm /var/log/vdsm/vdsm.log del host que es SPM encontramos el siguiente mensaje:

OSError: [Errno 17] File exists: '/rhev/data-center/00000002-0002-0002-0002-00000000008b/e1f1947b-b04a-4a50-a22d-f65110516143/images/58693eb1-d498-480e-95e7-524e0a682410'
67acab09-4bfb-4f05-a4f6-a36b31e01743::WARNING::2016-04-03 14:16:45,951::resourceManager::594::Storage.ResourceManager::(registerResource) Resource factory failed to create resource 'e1f1947b-b04a-4a50-a22d-f65110516143_imageNS.58693eb1-d498-480e-95e7-524e0a682410'. Canceling request.
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/resourceManager.py", line 590, in registerResource
    obj = namespaceObj.factory.createResource(name, lockType)
  File "/usr/share/vdsm/storage/resourceFactories.py", line 193, in createResource
    lockType)
  File "/usr/share/vdsm/storage/resourceFactories.py", line 122, in __getResourceCandidatesList
    imgUUID=resourceName)
  File "/usr/share/vdsm/storage/image.py", line 189, in getChain
    srcVol = volclass(self.repoPath, sdUUID, imgUUID, uuidlist[0])
  File "/usr/share/vdsm/storage/blockVolume.py", line 80, in __init__
    volume.Volume.__init__(self, repoPath, sdUUID, imgUUID, volUUID)
  File "/usr/share/vdsm/storage/volume.py", line 181, in __init__
    self.validate()
  File "/usr/share/vdsm/storage/blockVolume.py", line 89, in validate
    volume.Volume.validate(self)
  File "/usr/share/vdsm/storage/volume.py", line 193, in validate
    self.validateImagePath()
  File "/usr/share/vdsm/storage/blockVolume.py", line 460, in validateImagePath
    raise se.ImagePathError(imageDir)
ImagePathError: Image path does not exist or cannot be accessed/created: (u'/rhev/data-center/00000002-0002-0002-0002-00000000008b/e1f1947b-b04a-4a50-a22d-f65110516143/images/58693eb1-d498-480e-95e7-524e0a682410',)

Posiblemente se deba a quedaron links simbolicos rotos en el directorio que apunta a los volumenes presentados al cluster /rhev/data-center/

La solucion para dicho problema es eliminar todos los link simbolicos que se encuentran "rotos", es decir que apuntar a una ruta inexistente, para hacer eso podemos usar el siguiente comando:

[root@virt3 ~]# for file in $(find /rhev/data-center/ -type l); do [ -h "$file" -a ! -e "$file" ] && rm -fvr "$file"; done;

Dicho comando debe ejecutarse en el host que esta como SPM, aunque es recomendable ejecutarlo en todos los hosts de manera a que cuando alguno asuma como SPM no se vuelva a presentar el problema.

Una vez que hecho esto podemos reitentar la tarea que habia fallado.