Como añadir un disco virtual (.vmdk) a un Linux en caliente (sin reboot)

Muchas veces he añadido un disco a una maquina virtual(VM) Linux y he reiniciado para que lo reconociese. Pues, bien, tanto Linux como Windows son capaces de reconocerlo en caliente. En el caso de Windows es algo ya muy conocido (Administrador de discos, Refrescar y formatear...).

En el caso de Linux nos puede venir bien en los momentos en los que no podemos parar dicha VM ya sea por su criticidad o precisamente porque tenemos problemas en algún disco y necesitamos hacer backup en otro que acabamos de añadir.

(Este prodecimiento es para Red Hat 4, pero la mayoría de las distros funcionan de similar manera. De hecho no difiere del procedimiento de añadir un disco en caliente (que no formase un RAID) a un Linux Físico. Además es posible que otras distros lo faciliten):

Lo primero es añadir el disco desde el VIC o como normalmente lo hagamos.
Seguidamente podemos mirar /proc/scsi/scsi y ver los devices de nuestra VM: Los datos importantes son los que nos pone en la primera linea de cada elemento que aparece.
Por ejemplo: Host: scsi0 Channel: 00 Id: 00 Lun: 00

1. El primer numero es el numero de la controladora scsi. Ej: scsi0
2. El segundo es el canal
3. El tercero es ID del disco SCSI.
4. Y finalmente esta la LUN. (Sirve para fibra o iSCSI...)

Cuando hemos añadido con el VIC un disco a nuestro Linux, nos debemos fijar en el Virtual SCSI node (ej:SCSI 0:0 es la controladora 0 ID 0, SCSI 0:1 es la controladora 0 ID 1, etc,etc ) y en la controladora SCSI que es. Con esto ya tenemos los dos primeros numeros.

El numero que suele cambiar al añadir un disco es el ID del disco SCSI (1,2,3,4,5,6...) porque generalmente nuestras VMs tienen una sola controladora SCSI.

Una vez que tenemos el dato del disco que queremos que "vea", En la VM hay que hacer:

echo "scsi add-single-device" 0 0 1 0 > /proc/scsi/scsi

(Esto corresponde a SCSI0, Cahnnel=0, ID=1,LUN=0, que es lo típico cuando añades un segundo disco. Con esto le decimos al S.O. que reconozca el disco y lo ponga a sus revoluciones preparado para usarse, aunque los discos virtuales no giran...)

El proceso para quitar un disco en caliente (mirando que no tenga ningún proceso accediendo, claro), seria con el comando:

echo "scsi remove-single-device" 0 0 1 0 > /proc/scsi/scsi

SCSI Reservations y VMware

Cuando nos ponemos a trabajar con almacenamiento compartido mas tarde o mas temprano sale el termino SCSI reservations: Estas reservas sirven para asegurar el acceso exclusivo a recursos de disco cuando éstos recursos son accedidos por multiples hosts. Es algo que suele salir a la luz con VMware VMFS, Microsoft Cluster Server, etc...

Las SCSI Reservations son solamente usadas para operaciones específicas en las cuales se realizan cambios en los metadatos y son necesarias para prevenir que varios hosts puedan escribir concurrentemente evitando de esta manera la corrupción de datos.

Una vez que la operación es completada, la reserva es desbloqueada y las demás operaciones pueden continuar. Es obvio que es importante minimizar el numero concurrente y la duración de las operaciones que necesiten SCSI Reservations debido a que usan un lock exclusivo que al final lo que hace es serializar las operaciones. Cuando se realizan demasiadas reservations a la vez, tendremos errores de I/O porque el host que estaba intentando bloquear el recurso (la LUN, el fichero...) no puede puesto que otro host la habra bloquedao previamente. Cuando un host no puede realizar uns reservation porque hay otro host escribiendo, el primero continuará reintentandolo en intervalos de tiempo aleatorios hasta que lo logre, sin embargo, si se realizan demasidos intentos sin exito, la operacion fallará.

En el entorno de VI3, se vuelve importante el tema de las SCSI Reservations y es un factor a considerar a la hora de hacer el diseño de una arquitectura.
Algunos ejemplos de opreaciones asociadas a VI3 que requieran escrituras en los metadatos son:

• Crear o borrar un volumen VMFS
• Expandir un volumen VMFS(para mi usar extents esta prohibido)
• Encender o Apagar una VM
• Bloquear o liberar el lock de un archivo
• Crear o borrar un fichero
• Crear una plantilla
• Desplegar una VM de una plantilla
• Crear una nueva VM
• Realizar un VMotion
• Crecimiento de un archivo (Snapshot o un Virtual Disk Thin Provisioned)
• Hacer Rescans de VMFS, hacer vdf en console...
  

Lo normal en una infraestructura VI3 es que haya un numero residual de conflictos de SCSI Reservations.(Se ve en /var/log/vmkernel). Esto no nos debe preocupar porque tiene poca influencia en el rendimiento. Lo que si hay que evitar es tener demasiados problemas de SCSI Reservations porque además de afectar el rendimiento, puede hacer que algunas VMs se paren: En el caso de Linux, en muchos kernels, hace que la VM se ponga en Read Only (se soluciona cambiando un valor de timeout de mptisci.h: un RPM) y en el caso de Windows puede parar completamente la maquina.(Se soluciona cambiando un valor de timeout del disco del Registry: HKEY_LOCAL_MACHINE\System\CurrentCOntrolSet\Services\Disk\TimeOutValue)

Para mimimizar estos problemas deberemos intentar que se produzcan las menos operaciones posibles y si es posible que no ocurran simultaneamente en la medida de lo posible, es decir, una best practice seria Verificar que ninguna otra operacion de Reserva de SCSI esta ocurriendo a nivel de archivo, LUN o grupo de LUNs antes de proceder.
Algunas acciones para reducirlas son:

• Usar un punto central de administracion (Virtual Center) para ver qué operaciones se estan realizando y serializarlas en la medida de lo posible. (También las que se hacen por console)
  
• Mirar el estado de los Backups puesto que estos hacen uso de las SCSI Reservations.
  
• Limitar el numero de Snapshots activos.(Los snapshots crecen de 16MB en 16MB y cada vez que crecen usan SCSI Reservations)
• Intentar que las VMs no tengan los discos en más de dos LUNs puesto que una VMotion (operacion de VM) de una VM que tenga un disco en una LUN y otro en otra se dividira en cuatro operaciones a nivel de LUN.
  
• Intentar no realizar VMotion simultaneamente de dos VMs que residen en la misma LUN.
• Intentar solo realizar una migracion cold(VM apagada) por cada LUN en cada momento.
• Intantar no apagar o encender muchas VMs a la vez.(Esto es más por rendimiento que por SCSI reservatiosn pues solo dura 7 microsegundos el lock de reinicio)
• Limitar las creaciones y desplieges a una VM por LUN en cada momento.
• Usar un host en concreto para realizar despliegues siempre. De esta forma es facil limitar la creacion de templates, importaciones, despliegues...
  
• Usar un tamaño de LUN adecuado (<600gb)
• Usar solo un FileSystem en cada LUN
• No correr scripts que afecten a las LUNs (Backup, permisos) desde varior ESX a la vez y sobre las mismas LUNs.
  

Estas son algunas acciones para limitar dichas operaciones. Lo primero de todo es ver en nuestros logs si hay una buena cantidad de SCSI Reservations y ver si tenemos problemas de rendimiento. Posteriormente podemos aplicar alguna o todas de las recomendaciones anteriores.

Adjunto una Tabla en la que se ve el numero de operaciones por LUN que se podrian realizar corriendo un determinado riesgo: