lunes, 15 de abril de 2019

Manejo de LVM en Linux


LVM

A un nivel macro LVM se basa en las siguientes estructuras

Volume Group (VG)
Es la estructura que agrupa uno o mas discos (PVs). El espacio disponible se usa para crear los logical volumes

Physical Volume (PV)
Es un disco, LUN o particion inicializada con una cabecera de datos de LVM

Logical Volume (LV)
Se conforman con el espacio disponible de los VGs, luego los LVs contendrán FSs o serán usados como RAW devices.

De forma sencilla el concepto es el siguiente, se agrupan los discos en un VG, el espacio utilizable del VG es la suma del espacio de cada uno de los discos, de esta forma se elimina la limitante del disco físico. Luego apartir del espacio libre del VG se generan los LVs

Inicializacion de un PV

Para poder controlar un disco mediante LVM primero se le deben crear una cabecera con estructuras de control mediante el comando pvcreate <caracter device special file>

#pvcreate /dev/rdisk/disk5
Physical volume "/dev/rdisk/disk5" has been successfully created.

Si el disco ya estuvo bajo control de LVM y tiene una cabecera LVM, el comando fallara, para poder reescribir la cabecera para poder reutilizar el disco se debe utilizar el flag -f

Creación de un VG

Cuando creamos un VG, el LVM divide a los discos que lo integran en porciones de igual tamaño llamadas physical extents, estas porciones conforman la mínima unidad de asignación de espacio en disco. Por default el tamaño de los PE es de 4MB. Ahora procedemos con la creación del VG, en este caso vamos a armar un vg con Layout 1.0, para ver como se realiza con layout 2.x hacer click aqui de todas formas aconsejo primero leer los conceptos de esta nota primero.

#mkdir /dev/vg01
#mknod /dev/vg01/group c 64 0x010000
#vgcreate /dev/vg01 /dev/disk/disk5
Volume group "/dev/vg01" has been successfully created.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

De esta forma tenemos creado nuestro nuevo vg. Antes de verificar

Para ver el estado del VG y sus características usamos el comando vgdisplay

#vgdisplay vg01
--- Volume groups ---
VG Name                     /dev/vg01
VG Write Access             read/write
VG Status                   available
Max LV                      255
Cur LV                      0
Open LV                     0
Max PV                      16
Cur PV                      1
Act PV                      1
Max PE per PV               1016
VGDA                        2
PE Size (Mbytes)            4
Total PE                    499
Alloc PE                    0
Free PE                     499
Total PVG                   0
Total Spare PVs             0
Total Spare PVs in use      0
VG Version                  1.0
VG Max Size                 65024m
VG Max Extents              16256

Parámetros de un VG

PE Size, es el tamaño del PE, por default de 4MB, se puede especificar con la opción -s del vgcreate.
Max PE per PV, que define la cantidad máxima de PE por disco, si en este caso solo puedo direccionar 4GBs por disco,si quisiera colocar un disco de mayor tamaño debería recrear el VG y especificar un tamaño adecuado de Max PE per PV se especifica con la opción -e del vgcreate.
Max LV, la cantidad máxima de LVs que puede alojar el VG, se especifica con la opción -l del vgcreate.
Max PV, la cantidad máxima de discos que puedo agregar al VG, se especifica con la opción -p del vgcreate.


Para ver el espacio libre que tengo en el VG multiplico el Tamaño del PE por la cantidad de PE libres, en este caso
4*499=1996MB

Creación de un LV

Así como los PV están compuestos de PE, los LV están compuestos de Logical extents (LE). Los LE están asociados a los PE, si el disco no tiene mirror un LE esta asociado a un PE, si tenemos mirroreado el LV un LE esta asociado a 2 PE uno de cada disco.

Para crear un LV corremos el comando lvcreate

#lvcreate -L 100 -n mylv vg01
Logical volume "/dev/vg01/mylv" has been successfully created with
character device "/dev/vg01/rmylv".
Logical volume "/dev/vg01/mylv" has been successfully extended.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

Donde -L es el tamaño en MB -n es el nombre del LV, si no se especifica se le asigna automaticamente un nombre y por ultimo se indica cual es el vg en donde se creara el LV

En este caso el tamaño de mi PE es de 16MB y quiero crear un LV de 100MB

#lvcreate -L 100 -n mylv vg01
Warning: rounding up logical volume size to extent boundary at size "112" MB.
Logical volume "/dev/vg01/mylv" has been successfully created with
character device "/dev/vg00/rmylv".
Logical volume "/dev/vg01/mylv" has been successfully extended.
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg01.conf

Como 100 no es multiplo de 16, el sistema redondea hacia arriba el tamaño especificado al multiplo de 16 mas cercano

Tambien se puede especificar el tamaño del lv en extents con la opción -l

Para ver el estado del LV y su configuración corremos el comando lvdisplay

#lvdisplay /dev/vg01/mylv
--- Logical volumes ---
LV Name                     /dev/vg01/mylv
VG Name                     /dev/vg01
LV Permission               read/write
LV Status                   available/syncd
Mirror copies               0
Consistency Recovery        MWC
Schedule                    parallel
LV Size (Mbytes)            100
Current LE                  25
Allocated PE                25
Stripes                     0
Stripe Size (Kbytes)        0
Bad block                   on
Allocation                  strict
IO Timeout (Seconds)        default

Creacion de un FS

#newfs -F vxfs -b 8192 /dev/vg01/rmylv
    version 7 layout
    102400 sectors, 12800 blocks of size 8192, log size 128 blocks
    largefiles supported

Una vez que se le dio formato al logical volume se puede montar el FS.

#mkdir /fs1
#mount /dev/vg01/mylv /fs1

Para verificar puedo correr el comando bdf

#bdf
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg00/lvol3     671744  396864  272848   59% /
/dev/vg00/lvol1    1081344  347656  728032   32% /stand
/dev/vg00/lvol8    4042752 1740360 2288608   43% /var
/dev/vg00/lvol5    4927488 2107168 2798360   43% /usr
/dev/vg00/lvol4     131072   30592   99824   23% /tmp
/dev/vg00/lvol7    5484544 3427176 2041376   63% /opt
/dev/vg00/lvol6     102400    5464   96184    5% /home
/dev/vg01/mylv      102400    2288   99344    2% /fs1

Para hacer persistente este cambio debo editar el archivo /etc/fstab

/dev/vg01/mylv /fs1 vxfs delaylog 0 2

donde el indico el LV que contiene el FS, el tipo de FS, opciones de montaje, campo reservado y el nro de secuencia en el que se hacer el chequeo de consistencia al inicio del equipo.

Con la incorporacion de OnlineJFS se puede redimensionar un FS en linea

Ampliación de un FS

Si es que hay espacio disponible en VG extendemos el tamaño del LV,

Verifico que haya espacio en el VG

#vgdisplay vg01 |egrep -e "PE Size" -e "Free PE"
PE Size (Mbytes)            4
Free PE                     474

Vemos que tenemos 1896MB disponibles en el VG. Ahora voy a extender mi LV de 100MBs a 250MBs

#lvextend -L 256 /dev/vg01/mylv
Logical volume "/dev/vg01/mylv" has been successfully extended.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
#lvdisplay  /dev/vg01/mylv
--- Logical volumes ---
LV Name                     /dev/vg01/mylv
VG Name                     /dev/vg01
LV Permission               read/write
LV Status                   available/syncd
Mirror copies               0
Consistency Recovery        MWC
Schedule                    parallel
LV Size (Mbytes)            256
Current LE                  64
Allocated PE                64
Stripes                     0
Stripe Size (Kbytes)        0
Bad block                   on
Allocation                  strict
IO Timeout (Seconds)        default

La salida del lvdisplay nos muestra reflejado el cambio en el LV, que pasa si corro un bdf ahora

#bdf /fs1
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg01/mylv      102400    2288   99344    2% /fs1

Vemos que el tamaño del FS no se incremento, para ello debo correr un fsadm

#fsadm -F vxfs -b 262144 /fs1
UX:vxfs fsadm: INFO: V-3-25942: /dev/vg01/rmylv size increased from 102400 sectors to 262144 sectors

El parámetro -F indica el tipo de FS, -b indica en bloques de 1K el nuevo tamaño al cual quiero extender el FS. Para verificar corro nuevamente bdf

#bdf /fs1
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg01/mylv      262144    2288  257840    1% /fs1

Reducir el tamaño de un FS en linea

El procedimiento es similar pero de manera inversa, primero se achica el FS y luego se reduce el LV. Siempre se recomienda tener un backup de los datos del FS antes de reducirlo.

Como ejemplo vamos a reducir el /fs1 a 128MBs

#fsadm -F vxfs -b 131072  /fs1
UX:vxfs fsadm: INFO: V-3-23586: /dev/vg01/rmylv is currently 262144 sectors - size will be reduced

Verificamos el FS con un bdf

#bdf /fs1
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg01/mylv      131072    2288  127792    2% /fs1

Reducimos el LV para recuperar el espacio al VG

#lvreduce -L 128 /dev/vg01/mylv
When a logical volume is reduced useful data might get lost;
do you really want the command to proceed (y/n) : y
Logical volume "/dev/vg01/mylv" has been successfully reduced.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

Se puede verificar el estado del lv como se hizo cuando se extendió con un lvdisplay

#lvdisplay /dev/vg01/mylv
--- Logical volumes ---
LV Name                     /dev/vg01/mylv
VG Name                     /dev/vg01
LV Permission               read/write
LV Status                   available/syncd
Mirror copies               0
Consistency Recovery        MWC
Schedule                    parallel
LV Size (Mbytes)            128
Current LE                  32
Allocated PE                32
Stripes                     0
Stripe Size (Kbytes)        0
Bad block                   on
Allocation                  strict
IO Timeout (Seconds)        default

Ampliacion sin OnlineJFS

Si no se posee OnlineJFS se puede extender un FS pero para ello necesitamos desmontarlo. En principio se extiende el LV como vimos antes, luego desmontamos el FS y por ultimo ejecutamos extendfs.

Ejemplo, extenderemos el /fs1 a 512MB

#lvextend -L 512 /dev/vg01/mylv
Logical volume "/dev/vg01/mylv" has been successfully extended.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
#umount /fs1
#extendfs /dev/vg01/rmylv
#mount /fs1
#bdf /fs1
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg01/mylv      524288    2304  517920    0% /fs1

Borrado de un LV

Si no necesitamos mas un LV y queremos recuperar su espacio, podemos removerlo. Primero es una buena norma tomarun backup de los datos que contiene, desmontarlo y luego removerlo.

#mount /fs1
#lvremove /dev/vg01/mylv
The logical volume "/dev/vg01/mylv" is not empty;
do you really want to delete the logical volume (y/n) : y
Logical volume "/dev/vg01/mylv" has been successfully removed.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

Borrado de un VG

Cuando no necesitemos mas un VG podemos borrarlo, existen dos maneras:
  • vgremove
  •  vgexport
Con vgremove, debemos primero remover todos los LV que existan en el VG

Con vgexport no es necesario borrar ningún LV del VG y corremos con la ventaja que si nos equivocamos y necesitamos recuperar el VG, solo debemos importarlo nuevamente. Específicamente cuando exportamos un VG preservamos la estructura de LVM de los discos este procedimiento quita la vinculacion de OS con el VG.

Para borrar el VG

Una vez borrados los LV corremos el vgremove

#vgremove vg01
Volume group "vg01" has been successfully removed.

Para exportar el VG

#vgchange -a n vg01
Volume group "vg01" has been successfully changed.
#vgexport vg01
vgexport: Volume group "vg01" has been successfully removed.

Si necesito volver a importar el vg corro lo siguiente

#vgimport vg01 /dev/disk/disk5
vgimport: Volume group "/dev/vg01" has been successfully created.
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating the volume group.
#vgchange -a y vg01
Activated volume group.
Volume group "vg01" has been successfully changed.

Si el VG tuviera FSs ya se podrían montar y usar.

Extender un VG

Cuando nos estamos quedando sin espacio en un VG podemos extenderlo agregándole otro PV, el comando a utilizar se llama vgextend, los pasos son identificar el nuevo disco, inicializarlo y agregarlo al VG

ioscan -fnNC disk
Class     I  H/W Path  Driver S/W State   H/W Type     Description
===================================================================
disk      2  64000/0xfa00/0x0  esdisk   CLAIMED     DEVICE       HP      Virtual NullDVD
                      /dev/disk/disk2   /dev/rdisk/disk2
disk      3  64000/0xfa00/0x1  esdisk   CLAIMED     DEVICE       HP      Virtual LvDisk
                      /dev/disk/disk3      /dev/disk/disk3_p2   /dev/rdisk/disk3     /dev/rdisk/disk3_p2
                      /dev/disk/disk3_p1   /dev/disk/disk3_p3   /dev/rdisk/disk3_p1  /dev/rdisk/disk3_p3
disk      5  64000/0xfa00/0x5  esdisk   CLAIMED     DEVICE       HP      Virtual LvDisk
                      /dev/disk/disk5   /dev/rdisk/disk5
disk      7  64000/0xfa00/0x6  esdisk   CLAIMED     DEVICE       HP      Virtual LvDisk
                      /dev/disk/disk7   /dev/rdisk/disk7

En este caso el disco nuevo es el disk7

#pvcreate /dev/rdisk/disk7
Physical volume "/dev/rdisk/disk7" has been successfully created.
#vgextend vg01 /dev/disk/disk7
Volume group "vg01" has been successfully extended.
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf

Para verificar y chequear el estado del VG corremos un vgdisplay

<root@test2:/dev>vgdisplay vg01
--- Volume groups ---
VG Name                     /dev/vg01
VG Write Access             read/write
VG Status                   available
Max LV                      255
Cur LV                      0
Open LV                     0
Max PV                      16
Cur PV                      2
Act PV                      2
Max PE per PV               1016
VGDA                        4
PE Size (Mbytes)            4
Total PE                    998
Alloc PE                    0
Free PE                     998
Total PVG                   0
Total Spare PVs             0
Total Spare PVs in use      0
VG Version                  1.0
VG Max Size                 65024m
VG Max Extents              16256

Aqui vemos que la tanto la cantidad de discos como el espacio libre ha aumentado.

Algunas cajas de disco pueden extender el tamaño de la LUN,  HP-UX 11v3 tiene la capacidad de notar ese cambio y reflejarlo en las estructuras de LVM.

Extension dinamica de una LUN (Dynamic LUN Expansion DLE)

Para esto primero necesitamos que nos agranden la LUN que estamos usando. Luego que nos hayan extendido la LUN corremos un vgmodify de la siguiente forma

 vgmodify -a -E /dev/vg01

HPUX IV Volume raid


En este articulo vamos a ver como interactuar con un RAID Hardware en un host HP-UX.  Este equipo presenta un disco fallado, lo que vamos hacer primero es ver los logs del kernel para obtener mas datos


#dmesg
 .....
boot device's HP-UX HW path is: 0.1.1.0.a0cf13e19130310.0

    System Console is on the Built-In Serial Interface
igelan0: INITIALIZING HP PCI-X 1000Base-T Dual-port Built-in at hardware path 0/1/2/0
igelan1: INITIALIZING HP PCI-X 1000Base-T Dual-port Built-in at hardware path 0/1/2/1
iether2: INITIALIZING HP A7012-60601 PCI/PCI-X 1000Base-T Dual-port Adapter at hardware path 0/2/1/0
iether3: INITIALIZING HP A7012-60601 PCI/PCI-X 1000Base-T Dual-port Adapter at hardware path 0/2/1/1
AF_INET socket/streams output daemon running, pid 48
afinet_prelink: module installed
Starting the STREAMS daemons-phase 1
LVM: Root VG activated
    Swap device table:  (start & size given in 512-byte blocks)
        entry 0 - major is 64, minor is 0x2; start = 0, size = 33521664
    Dump device table:  (start & size given in 1-Kbyte blocks)
        entry 0000000000000000 - major is 1, minor is 0x0; start = 2349920, size = 16760832
Create STCP device files
Starting the STREAMS daemons-phase 2
     $Revision: vmunix:    B.11.31_LR FLAVOR=perf
Memory Information:
    physical page size = 4096 bytes, logical page size = 4096 bytes
    Physical: 33533100 Kbytes, lockable: 25172052 Kbytes, available: 28646020 Kbytes

0/0/2/2.2 ms
64000/0x0/0x0.0x0 estp
64000/0x0/0x0.0x0.0x0 eslpt
255/1/0.0 tgt
255/1/0.0.0 sdisk
64000/0xfa00/0x3 esdisk
0/0/2/0.1 usbcomposite
0/0/2/0.1.0 hid
0/0/2/0.1.1 hid
....
SAS driver at 0/1/1/0 (/dev/sasd1) : RAID volume at SAS address 0x0a0cf13e19130310 is in a degraded state.
SAS driver at 0/1/1/0 (/dev/sasd1) : RAID volume at SAS address 0x0a0cf13e19130310 is in a degraded state.



En la salida vemos que nos esta alarmando que el volumen RAID esta en estado degradado, ahora que tenemos la confirmación por parte del sistema que el equipo tiene un problema vamos a revisar mas a fondo

Si bien ya tenemos el special file para comunicarnos con el driver del RAID, vamos a ver el estado del mismo via ioscan

# ioscan -fn|more
Class        I  H/W Path       Driver       S/W State   H/W Type     Description
=================================================================================
root         0                 root           CLAIMED     BUS_NEXUS
ioa          0  0              sba            CLAIMED     BUS_NEXUS    System Bus Adapter (4030)
ba           0  0/0            lba            CLAIMED     BUS_NEXUS    Local PCI-X Bus Adapter (122e)
tty          0  0/0/1/0        rmp3f01        CLAIMED     INTERFACE    PCI class(255,0) (103c1303)
tty          1  0/0/1/1        rmp3f01        CLAIMED     INTERFACE    PCI SimpleComm (103c1302)
tty          2  0/0/1/2        asio0          CLAIMED     INTERFACE    PCI Serial (103c1048)
                              /dev/diag/mux2  /dev/mux2       /dev/tty2p0
usb          0  0/0/2/0        hcd            CLAIMED     INTERFACE    NEC OHCI Controller
usbcomp      0  0/0/2/0.1      usbcomposite   CLAIMED     DEVICE       USB Composite Device
usbhid       0  0/0/2/0.1.0    hid            CLAIMED     DEVICE       USB HID Kbd(0)
                              /dev/hid/hid_000
usbhid       1  0/0/2/0.1.1    hid            CLAIMED     DEVICE       USB HID Pointer(1)
                              /dev/hid/hid_001
usb          1  0/0/2/1        hcd            CLAIMED     INTERFACE    NEC OHCI Controller
usb          2  0/0/2/2        ehci           CLAIMED     INTERFACE    NEC EHCI Controller
usbms        0  0/0/2/2.2      ms             CLAIMED     DEVICE       USB Mass Storage [0]
graphics     0  0/0/3/0        gvid_core      CLAIMED     INTERFACE    PCI Display (1002515e)
ba           1  0/1            lba            CLAIMED     BUS_NEXUS    Local PCI-X Bus Adapter (122e)
escsi_ctlr   1  0/1/1/0        sasd           CLAIMED     INTERFACE    HP  PCI/PCI-X SAS MPT Adapter
                              /dev/sasd1
ext_bus      2  0/1/1/0.0.0    sasd_vbus      CLAIMED     INTERFACE    SAS Device Interface
target      17  0/1/1/0.0.0.2  tgt            CLAIMED     DEVICE
disk         1  0/1/1/0.0.0.2.0           sdisk          CLAIMED     DEVICE       HP      IR Volume
                              /dev/dsk/c2t2d0     /dev/dsk/c2t2d0s2   /dev/rdsk/c2t2d0    /dev/rdsk/c2t2d0s2
                              /dev/dsk/c2t2d0s1   /dev/dsk/c2t2d0s3   /dev/rdsk/c2t2d0s1  /dev/rdsk/c2t2d0s3
target      16  0/1/1/0.0.0.3  tgt            CLAIMED     DEVICE
disk         8  0/1/1/0.0.0.3.0           sdisk          CLAIMED     DEVICE       HP      IR Volume
                              /dev/dsk/c2t3d0   /dev/rdsk/c2t3d0


Vemos que el estado de la controladora esta en CLAIMED y ahora vamos a indagar en el estado del Internal RAID del sistema

# sasmgr get_info -D /dev/sasd1 -q raid

Fri Jan  8 10:20:50 2016

---------- LOGICAL DRIVE 5 ----------

Raid Level                                         : RAID 1
Volume sas address                                 : 0xb852a4c047edba
Device Special File                                : /dev/rdsk/c2t3d0
Raid State                                         : OPTIMAL
Raid Status Flag                                   : ENABLED
Raid Size                                          : 69618
Rebuild Rate                                       : 0.00 %
Rebuild Progress                                   : 100.00 %

Participating Physical Drive(s) :

SAS Address         Enc   Bay   Size(MB)      Type            State

0x5000c500176a2371   1     5    70007         SECONDARY       ONLINE
0x5000c5001764d9b1   1     6    70007         PRIMARY         ONLINE

---------- LOGICAL DRIVE 7 ----------

Raid Level                                         : RAID 1
Volume sas address                                 : 0xa0cf13e19130310
Device Special File                                : /dev/rdsk/c2t2d0
Raid State                                         : DEGRADED
Raid Status Flag                                   : ENABLED
Raid Size                                          : 69618
Rebuild Rate                                       : 0.00 %
Rebuild Progress                                   : 100.00 %

Participating Physical Drive(s) :

SAS Address         Enc   Bay   Size(MB)      Type            State

0x5000c5001764f35d   1     8    70007         PRIMARY         ONLINE
0x5000c5001764a169   1     7    70007         SECONDARY       FAILED

La salida del comando nos indica cual es el disco que presenta la falla y su ubicacion para identificarlo y cambiarlo

viernes, 3 de mayo de 2013

Usando Global File System y KVM - GFS2 + KVM

En esta nota vamos a compartir un disco entre 2 hosts a los cuales le vamos a instalar GFS2 para que puedan escribir de manera concurrente. Para realizar esta configuracion vamos a utilizar en una infraestructura virtual basada en KVM (ver nota anterior de KVM) para mas detalle o profundizar conceptos).

Vamos a dar por sentado que tenemos dos maquinas virtuales funcionando

# virsh list
 Id    Name                           State
----------------------------------------------------
 1     vmCentOS1                      running
 2     vmCentOS2                      running

Primero creamos el disco virtual a compartir

qemu-img create -f raw shared.raw 5G
Formatting 'shared.raw', fmt=raw size=5368709120 

Ahora ya creado vamos a presentarlos a ambas VMs
  
Entramos al virsh
# virsh 

Presentamos los devices 

virsh # attach-disk vmCentOS1 /VMs/shared.raw vdb --shareable
Disk attached successfully

virsh # attach-disk vmCentOS2 /VMs/shared.raw vdb --shareable
Disk attached successfully


Verificamos dentro de las VMs si se ve el disco nuevo

[root@vmCentos1 ~]# fdisk -l
...
Disk /dev/vdb: 5368 MB, 5368709120 bytes
16 heads, 63 sectors/track, 10402 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


[root@vmCentos2 ~]# fdisk -l
...
Disk /dev/vdb: 5368 MB, 5368709120 bytes
16 heads, 63 sectors/track, 10402 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Para poder utilizar GFS2 necesitamos instalar los siguientes paquetes, en caso de necesitar mas debido a dependencias yum las seleccionara automaticamente

# yum install lvm2-cluster gfs2-utils

Una vez instalado tendremos que realizar la configuracion del cluster y en especial el fencing, ya que si no esta presente servicio de clvmd no levantara.

El fencing es un mecanismo que se utiliza para aislar a los nodos que no estan respondiendo dentro del cluster, en particular el GFS2/CLVMD cuando detectan una falla en un host, ejecutan el metodo de fencing y detienen las operaciones de entrada/salida hasta que termine la operacion de fencing.
Para hacer fencing vamos a usar fence-virtd, el cual lo instalamos en el host

# yum install fence-virt fence-virtd fence-virtd-libvirt fence-virtd-multicast

En las VMs solo es necesario el paquete fence-virt.
Luego de instalar debemos crear el directorio /etc/cluster y configurar el servicio de fencing
# mkdir /etc/cluster

# fence_virtd -c
Module search path [/usr/lib64/fence-virt]:

Available backends:
    libvirt 0.1
Available listeners:
    multicast 1.1

Listener modules are responsible for accepting requests
from fencing clients.

Listener module [multicast]:

The multicast listener module is designed for use environments
where the guests and hosts may communicate over a network using
multicast.

The multicast address is the address that a client will use to
send fencing requests to fence_virtd.

Multicast IP Address [225.0.0.12]:

Using ipv4 as family.

Multicast IP Port [1229]:

Setting a preferred interface causes fence_virtd to listen only
on that interface.  Normally, it listens on the default network
interface.  In environments where the virtual machines are
using the host machine as a gateway, this *must* be set
(typically to virbr0).
Set to 'none' for no interface.

Interface [none]: virbr0

The key file is the shared key information which is used to
authenticate fencing requests.  The contents of this file must
be distributed to each physical host and virtual machine within
a cluster.

Key File [/etc/cluster/fence_xvm.key]:

Backend modules are responsible for routing requests to
the appropriate hypervisor or management layer.

Backend module [checkpoint]: libvirt

The libvirt backend module is designed for single desktops or
servers.  Do not use in environments where virtual machines
may be migrated between hosts.

Libvirt URI [qemu:///system]:

Configuration complete.

=== Begin Configuration ===
backends {
    libvirt {
        uri = "qemu:///system";
    }

}

listeners {
    multicast {
        interface = "virbr0";
        port = "1229";
        family = "ipv4";
        address = "225.0.0.12";
        key_file = "/etc/cluster/fence_xvm.key";
    }

}

fence_virtd {
    module_path = "/usr/lib64/fence-virt";
    backend = "libvirt";
    listener = "multicast";
}

=== End Configuration ===
Replace /etc/fence_virt.conf with the above [y/N]? y


Ahora creamos la key que usaremos


#  dd if=/dev/urandom of=/etc/cluster/fence_xvm.key bs=4k count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.00238924 s, 1.7 MB/s


Copiamos la key a ambos guests

# scp /etc/cluster/fence_xvm.key root@vmCentOS1:/etc/cluster/fence_xvm.key
# scp /etc/cluster/fence_xvm.key root@vmCentOS2:/etc/cluster/fence_xvm.key

Para validar que la configuracion funciona, corremos desde el host fisico la siguiente linea

# fence_xvm -o list
vmCentOS1            fd58626b-da91-a03f-9610-63cb4a3e0b2e on
vmCentOS2            c986740c-887a-6df1-2b3f-ecbf2d238563 on

Desde la VM, probamos tambien si la configuracion tuvo exito

[root@vmCentos1 ~]# fence_xvm -o list
vmCentOS1            fd58626b-da91-a03f-9610-63cb4a3e0b2e on
vmCentOS2            c986740c-887a-6df1-2b3f-ecbf2d238563 on

Desde la otra VM tambien lo probamos

[root@vmCentos2 ~]# fence_xvm -o list
vmCentOS1            fd58626b-da91-a03f-9610-63cb4a3e0b2e on
vmCentOS2            c986740c-887a-6df1-2b3f-ecbf2d238563 on

Ya aqui estamos en condiciones de poder hacer otro tipo de prueba como el reboot o el apagado de un nodo por medio del fencing

[root@vmCentos1 ~]# fence_xvm -o reboot -H vmCentOS2

Si todo se configuro correctamente, en este momento se debio haber reiniciado el vmCentOS2.
Ahora generaremos un template basico para nuestro cluster

<cluster name="cluster1" config_version="2">
   <cman two_node="1" expected_votes="1"/>
   <clusternodes>
     <clusternode name="vmCentOS1.domain" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="vmCentOS2.domain." nodeid="2">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>

     <fencedevice agent="fence_xvm" name="virtfence1" key_file="/etc/cluster/fence_xvm.key" multicast_address="225.0.0.12"/>
   </fencedevices>
   <rm>
   </rm>

 </cluster>

Con la configuracion creada podemos levantar y configurar el servicio de cluster 

[root@vmCentos1 cluster]# chkconfig cman on
[root@vmCentos2 cluster]# service cman start
Starting cluster:
   Checking if cluster has been disabled at boot...        [  OK  ]
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman...                                        [  OK  ]
   Waiting for quorum...                                   [  OK  ]
   Starting fenced...                                      [  OK  ]
   Starting dlm_controld...                                [  OK  ]
   Tuning DLM kernel config...                             [  OK  ]
   Starting gfs_controld...                                [  OK  ]
   Unfencing self...                                       [  OK  ]
   Joining fence domain...                                 [  OK  ]



Ahora copiamos el /etc/cluster/cluster.conf al otro nodo del cluster y levamtamos y configuramos el cman igual que en el vmCentOS1

En este momento podemos levantar el servicio de clvmd

[root@vmCentos1 ~]# service clvmd start
Starting clvmd: dlm: Using TCP for communications

Activating VG(s):   2 logical volume(s) in volume group "vg_vmcentos1" now active
  clvmd not running on node vmCentOS2.domain.
[  OK  ]



Corremos el mismo comando desde el nodo 2, en mi caso vmCentOS2 y ya finalmente estamos en condiciones de poder comartir el volumen.

Ahora pasamos a la configuracion de LVM, todos estos pasos son iguales a cuando trabajamos sin cluster, proximamante voy hacer una guia de LVM para Linux aunque es muy similar a lo que es HP-UX, de la cual si tengo una entrada en el blog

Primero creamos el physical volume 
[root@vmCentos1 ~]# pvcreate  /dev/vdb
  Physical volume "/dev/vdb" successfully created


Segundo creamos el volume group

[root@vmCentos1 ~]# vgcreate vgshared /dev/vdb
  Clustered volume group "vgshared" successfully created


Tercero creamos un logical volume

[root@vmCentos1 ~]# lvcreate -L 1024 -n lvol1 vgshared
  Logical volume "lvol1" created


Como ultimo paso nos resta darle formato al volumen, formato que sera gfs2, las opciones del comando son, 

-p tipo de lock, en este caso es un lock distribuido entre los nodos, 
-t  nombre de cluster seguido, el nombre del filesystem separado por :
-j la cantidad de journals a crear, que indica la cantidad de nodos que comparten el filesystem, en este caso configure 5 por un tema de escalabilidad.

[root@vmCentos1 ~]# mkfs.gfs2 -p lock_dlm -t cluster1:fsvgsharedlvol1 -j 5 /dev/vgshared/lvol1
This will destroy any data on /dev/vgshared/lvol1.
It appears to contain: symbolic link to `../dm-2'

Are you sure you want to proceed? [y/n] y

Device:                    /dev/vgshared/lvol1
Blocksize:                 4096
Device Size                1.00 GB (262144 blocks)
Filesystem Size:           1.00 GB (262142 blocks)
Journals:                  5
Resource Groups:           4
Locking Protocol:          "lock_dlm"
Lock Table:                "cluster1:fsvgsharedlvol1"
UUID:                      09053a2a-5a43-3c7d-d46a-919586c612b2


Corremos un vgscan en el nodo2 para importar la configuracion


Agregamos las entradas correspondientes en ambos /etc/fstabs

#
## FSs compartidos gfs2
#

/dev/mapper/vgshared-lvol1    /sharedfs    gfs2   defaults,acl    0 0


creamos el punto de montaje en ambos nodos

# mkdir /sharedfs

Montamos el filesystem, en este paso tendremos tambien que activar el servicio de gfs2 para que cuando reiniciemos las VMs estas monten automaticamente el FS que creamos, esta de mas decir que estas operaciones tambien se deben realizar en ambos nodos

# chkconfig gfs2 on
# mount /sharedfs
 

Verificamos que este montado

[root@vmCentos1 /]# df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg_vmcentos1-lv_root
                       9845280   2411808   6933352  26% /
tmpfs                   510208     28744    481464   6% /dev/shm
/dev/vda1               495844     55904    414340  12% /boot
/dev/mapper/vgshared-lvol1
                       1048400    661916    386484  64% /sharedfs

 

Corremos un mount -v para ver el tipo de filesystem

[root@vmCentos1 /]# mount -v
/dev/mapper/vg_vmcentos1-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/vda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
none on /sys/kernel/config type configfs (rw)
/dev/mapper/vgshared-lvol1 on /sharedfs type gfs2 (rw,seclabel,relatime,hostdata=jid=1,acl)


 Como prueba final vamos a escribir en nuestro FS desde los dos nodos, primero vamos a ver el contenido del /sharedfs

[root@vmCentos1 sharedfs]# ls -la
total 8
drwxr-xr-x.  2 root root 3864 May  3 12:13 .
dr-xr-xr-x. 27 root root 4096 May  3 11:51 ..

y

[root@vmCentos2 sharedfs]# ls -al
total 8
drwxr-xr-x.  2 root root 3864 May  3 12:13 .
dr-xr-xr-x. 27 root root 4096 May  3 11:50 ..
[root@vmCentos2 sharedfs]# 


Ahora vamos a escribir unos archivos 

Primero desde el vmCentos1

[root@vmCentos1 sharedfs]# echo hola > hola
 

Luego en el vmCentos2

[root@vmCentos2 sharedfs]# echo mundo > mundo

Verificamos desde ambos nodos

Desde el vmCentos1

[root@vmCentos1 sharedfs]# ls
hola  mundo


y luego desde el vmCentos2




[root@vmCentos2 sharedfs]# ls
hola  mundo



miércoles, 24 de abril de 2013

Usos del comando tar



En muchas ocasiones en las cuales tenemos que copiar contenidos de filesystems, preservando permisos, links archivos ocultos, etc. Justamente podemos utilizar el comando tar para este caso y lo mejor es que podemos hacerlo sin la necesidad de generar un archivo .tar intermedio facilitandonos de esta forma la copia.


Supongamos que queremos copiar toda una estructura de directorios a otro lado, por ejemplo de un filesystem a otro nuevo, solo tendremos que hacer lo siguiente


# cd /source
# tar cf - * | ( cd /target; tar xvfp -)


Tambien podemos usar el comando tar para copiar de un host a otro mediante SSH

# tar cvzf - /foo | ssh@target_host "cat  > /foo.tar.gz

lunes, 15 de abril de 2013

Linux virtualización - KVM

KVM (Kernel-based Virtual Machine), es una solución de virtualización basada en QEMU para la arquitectura x86 que utiliza las extensiones de virtualización de hardware, ya sean AMD-V (svm) o las de Intel-VT (vmx).
Requisitos

Como deciamos en el parrafo anterior, KVM utiliza extensiones de hardware para poder funcionar, con lo cual este sera nuestro único requisito para la instalación. Por lo general cualquier CPU moderno soporta estas características. De todas maneras, para verificar si nuestra CPU esta soportada por KVM  solo tenemos que correr los siguientes comandos

cat /proc/cpuinfo |grep svm (en el caso de tener un micro AMD) o
cat /proc/cpuinfo |grep vmx (en caso de tener Intel)

En caso de no encontrar ninguna extensión de vitrtualización, chequear si son soportadas por el CPU en la pagina del fabricante del micro y en caso afirmativo corroborar en el BIOS que estén activas.

Instalación

La máquina en la que estoy armando este tutorial tiene instalado un CentOS 6.4 64bits, dos procesadores Intel i7 1.2GHz, 8GBs de RAM y LVM con el suficiente espacio libre como para crear nuevos LVs que usaremos para alojar las imágenes ISO y las VMs

yum install kvm python-virtinst libvirt libvirt-python virt-manager \
virt-viewer libguestfs-tools

Creamos un FS de 12GBs para las ISO de instalación

# lvcreate -L 12G vg_pegasus2 -n lvol8
# mkdir /ISOs
# mkfs.ext4 -m 1 /dev/vg_pegasus2/lvol8

Y agregamos al fstab el FS que creamos

/dev/mapper/vg_pegasus2-lvol8 /ISOs                    ext4    defaults        1 2

Montamos el filesystem
# mount /ISOs

Creamos un FS de 80GBs para contener las VMs
# lvcreate -L 80G vg_pegasus2 -n lvol9
# mkdir /VMs
# mkfs.ext4 -m 1 /dev/vg_pegasus2/lvol9

Al igual que en el caso anterior agregamos la entrada al fstab

/dev/mapper/vg_pegasus2-lvol8 /ISOs                    ext4    defaults        1 2

y para chequear que hayamos echo bien el procedimiento montamos el FS

# mount /VMs

Verificamos con df -h

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_pegasus2-lvol1
                      5.0G  439M  4.5G   9% /
tmpfs                 849M  444K  849M   1% /dev/shm
/dev/sda1             485M   73M  388M  16% /boot
/dev/mapper/vg_pegasus2-lvol2
                      194M   47M  137M  26% /home
/dev/mapper/vg_pegasus2-lvol7
                      2.0G   68M  1.9G   4% /opt
/dev/mapper/vg_pegasus2-lvol3
                     1008M   35M  923M   4% /tmp
/dev/mapper/vg_pegasus2-lvol4
                      7.9G  1.8G  5.7G  24% /usr
/dev/mapper/vg_pegasus2-lvol6
                      2.0G   68M  1.9G   4% /usr/local
/dev/mapper/vg_pegasus2-lvol5
                       16G  333M   15G   3% /var
/dev/mapper/vg_pegasus2-lvol8
                       12G  4.4G  7.4G  37% /ISOs
/dev/mapper/vg_pegasus2-lvol9
                       78M  5.6M   72M   8% /VMs


Vemos que los dos últimos FSs son los que creamos, en este caso se ve que copie algunas ISOs al /ISOs

# ls -l /ISOs/
total 4353336
drwx------. 2 root root      16384 Feb 28 04:11 lost+found
-rwxr-xr-x. 1 root root 3729028147 Feb 28 04:33 SL-63-x86_64-2012-08-02-Install-DVD.iso
-rwxr-xr-x. 1 root root  728760320 Feb 28 04:09 SL-63-x86_64-2012-08-24-LiveCD.iso


Ya teniendo el software instalado, las ISOs y el lugar donde ubicaremos las VMs pasamos a la parte de configuración y creado de las VMs

Primeros pasos con KVM
Una vez configurado verificamos con el comando virsh.

El virsh es la interfase que se utiliza para administrar los entornos virtuales este comando nos permite modificar, apagar, prender, sacar snapshots y clonar VMs entre otras cosas. En particular el flag list nos muestra la información acerca de las maquinas virtuales (o dominios).

# virsh -c qemu:///system list
Id Name State
----------------------------------------------------


Una vez revisado que la instalación inicial de KVM fue exitosa procederemos a genera una VM de prueba

virt-install --connect qemu:///system -n vmCentOS1 -r 1024 --vcpus=1,maxvcpus=2 --os-type=linux --os-variant=rhel6 --disk path=/VMs/vmCentOS1-d1.dsk,size=12 -c /VMs/iso/CentOS-6.4-x86_64-bin-DVD1.iso --graphics vnc

Luego de ejecutar este comando nos encontraremos con la pantalla de instalacion de CentOS6, el template de instalacion que se realizara sera por default y se selecionaran los paquetes de server basico.


Ahora finalizada la instalación tendremos que rebootear la VM

Posterior al reboot, bootearemos por primera vez la VM

Luego de realizar la instalacion del CentOS, tendriamos la VM lista para utilizar

# virsh -c qemu:///system list
 Id    Name                           State
----------------------------------------------------
 3     vmCentOS1                      running


Configuracion de consola serie

Para poder entrar por consola de texto al host y evitarnos usar VNC y un entorno gráfico, debemos modificar las opciones de booteo del kernel del guest y habilitar el acceso vía serie, para hacer esto debemos editar el archivo /etc/grub.conf

Dentro de este archivo debemos agregar en la linea

...
kernel /vmlinuz-2.6.32-358.el6.x86_64 ro root=/dev/mapper/vg_walkure-lvol1 rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=vg_walkure/lvol1 SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet console=ttyS0
...

Para terminar la configuración se debe agregar un manejador de terminal para que atienda en el puerto serie virtual. Para hacer esto tenemos que agregar al /etc/inittab del guest la siguiente entrada
  
...
T0:S12345:respawn:/sbin/agetty ttyS0 115200
...

Para que el sistema tome la configuración realizada al inittab tendremos que recargarla usando el comando initcl

# initctl reload-configuration

Para editar estos archivos desde el host sin entrar al guest podemos hacer uso del comando virt-edit

# virt-edit vmCentOS1 /boot/grub/grub.conf
 
Ahora se esta en condiciones de conectarse a la consola de la VM en modo texto
# virsh -c qemu:///system console 3
Connected to domain vmCentOS1
Escape character is ^]

CentOS release 6.4 (Final)
Kernel 2.6.32-358.el6.x86_64 on an x86_64

vmCentos1 login:
 

o

# virsh -c qemu:///system console vmCentOS1
Connected to domain vmCentOS1
Escape character is ^]

CentOS release 6.4 (Final)
Kernel 2.6.32-358.el6.x86_64 on an x86_64

vmCentos1 login:


Administracion de VMs

Apagado

Podemos apagar una VM desde nuestro host corriendo
# virsh -c qemu:///system shutdown 3
Domain 3 is being shutdown

Este comando baja la VM en forma ordenada, desde la consola podemos observar como se bajan los servicios en la virtual
# virsh -c qemu:///system console 3
Connected to domain vmCentOS1
Escape character is ^]

vmCentos1 login:
CentOS release 6.4 (Final)
Kernel 2.6.32-358.el6.x86_64 on an x86_64

vmCentos1 login: Stopping certmonger: [  OK  ]
Stopping atd: [  OK  ]
Stopping cups: [  OK  ]
Stopping abrt daemon: [  OK  ]
Stopping sshd: [  OK  ]
Shutting down postfix: [  OK  ]
Stopping mcelog
Stopping crond: [  OK  ]
Stopping automount: [  OK  ]
Stopping acpi daemon: [  OK  ]
Stopping HAL daemon: [  OK  ]
Stopping block device availability: Deactivating block devices:
  [SKIP]: unmount of vg_vmcentos1-lv_swap (dm-1) mounted on [SWAP]
  [SKIP]: unmount of vg_vmcentos1-lv_root (dm-0) mounted on /
[  OK  ]
Stopping system message bus: [  OK  ]
Stopping rpcbind: [  OK  ]
Stopping auditd: [  OK  ]
Shutting down system logger: [  OK  ]
Shutting down loopback interface:  [  OK  ]
ip6tables: Flushing firewall rules: [  OK  ]
ip6tables: Setting chains to policy ACCEPT: filter [  OK  ]
ip6tables: Unloading modules: [  OK  ]
iptables: Flushing firewall rules: [  OK  ]
iptables: Setting chains to policy ACCEPT: filter [  OK  ]
iptables: Unloading modules: [  OK  ]
Stopping monitoring for VG vg_vmcentos1:   2 logical volume(s) in volume group "vg_vmcentos1" unmonitored
[  OK  ]
Sending all processes the TERM signal... [  OK  ]
Sending all processes the KILL signal... [  OK  ]
Saving random seed:  [  OK  ]
Syncing hardware clock to system time [  OK  ]
Turning off swap:  [  OK  ]
Turning off quotas:  [  OK  ]
Unmounting pipe file systems:  [  OK  ]
Unmounting file systems:  [  OK  ]
init: Re-executing /sbin/init
Halting system...
Power down.


Podemos verificar el estado de las VMs con el comando virsh -c qemu:///system list --all es importante especificar en este caso el flag --all ya que si lo omitimos no se listara la maquina

# virsh -c qemu:///system list --all
 Id    Name                           State
----------------------------------------------------
 -     vmCentOS1                      shut off


Prendido

Si quisieramos, levantar la maquina que hemos apagado, 

# virsh -c qemu:///system start vmCentOS1

Podemos borrar una VM con corriendo los siguientes comandos

# virsh -c qemu:///system list
 Id    Name                           State
----------------------------------------------------
 3     vmCentOS1                      running


# virsh destroy vmCentOS1
Domain vmCentOS1 destroyed


# virsh -c qemu:///system list
 Id    Name                           State
----------------------------------------------------

# virsh undefine vmCentOS1
Domain vmCentOS1 has been undefined


Clonado

Si la VM esta prendida primero debemos apagarla ya que si no la apagamos al querer clonarla nos dara el siguiente error

#  virt-clone --connect=qemu:///system -o vmCentOS1 -n vmCentOS2 -f /VMs/vmCentOS2.img
ERROR    Domain with devices to clone must be paused or shutoff.

Con lo cual como habiamos dicho debemos apagar la VM primero con el comando

# virsh -c qemu:///system shutdown vmCentOS1Domain vmCentOS1 is being shutdown

Verificamos que la operacion haya sido exitosa

# virsh list --all
 Id    Name                           State
----------------------------------------------------
 -     vmCentOS1                      shut off


Para comenzar el clonado corremos 

#  virt-clone --connect=qemu:///system -o vmCentOS1 -n vmCentOS2 -f /VMs/vmCentOS2.img
Cloning vmCentOS1-d1.dsk                                              56% [=================================                          ] 182 MB/s | 6.7 GB     00:29 ETA


La opcion -o indica la maquina origen, la maquina a la cual vamos a clonar, -n especifica el nombre de la nueva VM, -f es el full path al archivo de la nueva VM.

Al cabo de unos minutos la operacion terminara exitosamente con el siguiente mensaje

Clone 'vmCentOS2' created successfully.

Para verificar el estado de ambas maquinas corremos un virsh list --all

# virsh list --all
 Id    Name                           State
----------------------------------------------------
 -     vmCentOS1                      shut off
 -     vmCentOS2                      shut off
 

Para evitar problemas de red, nombres e ips duplicadas es conviente bootear la maquina en modo rescue o hacer un loopback device, en este caso como la VM esta creada con LVM vamos a utilizar el primer metodo

# virt-rescue vmCentOS2

Google, Inc.
Serial Graphics Adapter 12/07/11
SGABIOS $Id: sgabios.S 8 2010-04-22 00:03:40Z nlaredo $ (mockbuild@c6b18n1.dev.centos.org) Wed Dec  7 17:04:47 UTC 2011

.....
mdadm: No arrays found in config file or automatically
[    2.190404] device-mapper: uevent: version 1.0.3
[    2.191725] device-mapper: ioctl: 4.23.6-ioctl (2012-07-25) initialised: dm-devel@redhat.com
  Reading all physical volumes.  This may take a while...
  Found volume group "vg_vmcentos1" using metadata type lvm2
  2 logical volume(s) in volume group "vg_vmcentos1" now active

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

Welcome to virt-rescue, the libguestfs rescue shell.

Note: The contents of / are the rescue appliance.
You have to mount the guest's partitions under /sysroot
before you can examine them.

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
><rescue>


Ahora necesitamos saber como esta compuesto el layout de LVM con lo cual corremos el comando lvs

><rescue> lvs
  LV      VG           Attr      LSize Pool Origin Data%  Move Log Cpy%Sync Convert
  lv_root vg_vmcentos1 -wi-a---- 9.54g                                            
  lv_swap vg_vmcentos1 -wi-a---- 1.97g     


Para montar el root FS tenemos que hacer lo siguiente

><rescue> mount /dev/vg_vmcentos1/lv_root /sysroot
[   99.953289] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts:



Una vez montado realizamos las operaciones que necesitamos, en este caso vamos a borrar la configuracion de los devices del host original

><rescue> rm /sysroot/etc/udev/rules.d/70-persistent-net.rules 

Ahora en el proximo booteo la maquina levantara con la interfaz correcta.
Como la VM original estaba configurada con DHCP, no es necesario cambiar la IP.


Modificacion de la VM

Agregado de disco

 Para agregarle un vdisk al dominio virtual primero debemos crear el vdisk. En este caso el vdisk lo armamos con formato raw


# qemu-img create -f raw shared.raw 5G
Formatting 'shared.raw', fmt=raw size=5368709120



Ahora para agregarlo a nuestra VM lo hacemos desde la interface de virsh 


#virsh 
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit


virsh # attach-disk vmCentOS1 /VMs/shared.raw vdb --configure
Disk attached successfully


Desde la VM podemos ver el nuevo disco con el comando fdisk -l

# fdisk -l
...
Disk /dev/vdb: 5368 MB, 5368709120 bytes
16 heads, 63 sectors/track, 10402 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000


Ahora tenemos el disco listo para usar

Remocion de disco de la VM

Una vez que desmontamos, el filesystem, exportado el VG, en caso de estar usandolo, ya estariamos en condiciones de poder remover el vdisk de la VM.

# virsh detach-disk vmCentOS2 vdb
Disk detached successfully




Configuracion de red

La red por defecto que tendremos una vez instalado el KVM se llama justamente default, para ver la configuracion de esta correremos los sifguientes comandos,

virsh # net-list
Name                 State      Autostart     Persistent
--------------------------------------------------
default              active     yes           yes




De esta forma sabremos que la unica red definida es la default

Para obtener mas informacion acerca de la configuracion de la red lo mejor es correr un net-edit

virsh # net-edit default

Una vez que corremos el comando, nos aparece una pantalla del editor vi

<network>
  <name>default</name>
  <uuid>1cc2cd6d-ffa9-44cd-9c59-d04a455a4c4a</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <mac address='52:54:00:4C:C3:89'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
    </dhcp>
  </ip>
</network> 


Ahi podemos ver como esta configurada la red, el virtual switch, el modo en el cual trabaja, tenemos un DHCP y el rango de direcciones IP con el que trabaja

Si quisieramos asociar una IP a una MAC address, tendremos que hacer un net-edit y agregar la siguientes lineas que figuran en negrita

<network>
  <name>default</name>
  <uuid>1cc2cd6d-ffa9-44cd-9c59-d04a455a4c4a</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <mac address='52:54:00:4C:C3:89'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254' />
      <host mac='52:54:00:58:26:37' name='vmCentOS1.domain' ip='192.168.122.10' />
      <host mac='52:54:00:1A:37:FC' name='vmCentOS2.domain' ip='192.168.122.11' />

    </dhcp>
  </ip>
</network>

Luego para que el KVM tome la configuracion que establecimos haremos lo siguiente en el guest
# ps -ef |grep dnsmaq |grep -v grep
nobody    2715     1  0 08:41 ?        00:00:00 /usr/sbin/dnsmasq --strict-order --local=// --domain-needed --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --bind-interfaces --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override --dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile --addn-hosts=/var/lib/libvirt/dnsmasq/default.addnhosts
 

# kill -HUP 2715

El kill se lo damos al pid del proceso dnsmasq para que este recarge la configuracion. En el cliente hacemos un release de la IP y pediremos otra.
 
Snapshots

Para poder utilizar esta caracteristica el formato de la imagen tiene que ser qcow2, dado que el formato raw no lo soporta. Como las VMs que hemos creado son de tipo raw (que es el default) tendremos que convertirlas a qcow2 para poder utilizar este feature.


# qemu-img convert -O qcow2 vmCentOS1-d1.dsk vmCentOS1-d1.qcow2

Donde -O indica el formato de salida vmCentOS1-d1.dsk es el file original donde reside la VM en formato raw y vmCentOS1-d1.qcow2 es el archivo de salida.
Luego de unos minutos tendremos el nuevo archivo de salida.
# ls -ltr
total 7062000
drwx------. 2 root root       16384 Apr 12 20:07 lost+found
drwxr-xr-x. 2 root root        4096 Apr 15 13:55 iso
-rwxr-xr-x  1 qemu qemu 12884901888 Apr 17 08:08 vmCentOS2.img
-rwxr-xr-x  1 root root 12884901888 Apr 17 10:01 vmCentOS1-d1.dsk
-rw-r--r--  1 qemu qemu  2349793792 Apr 17 13:55 vmCentOS1-d1.qcow2


Paso siguiente sera borrar la definicion del vmCentOS1 e importar el nuevo contenedor.

# virsh undefine vmCentOS1
Domain vmCentOS1 has been undefined
# virt-install --connect qemu:///system -n vmCentOS1 -r 1024 --vcpus=1,maxvcpus=2 --os-type=linux --os-variant=rhel6 --disk path=/VMs/vmCentOS1-d1.qcow2,device=disk,format=qcow2 --graphics vnc --import


Chequeamos si la maquina levanto


# virsh undefine vmCentOS1
Domain vmCentOS1 has been undefined


Ahora estamos en condicion de poder tomar un snapshot del dominio vmCentOS1