How to’s

Habilitando Nested ESX/ESXi en vCloud Director (appliance)

Que tal gente, el día de hoy les voy a mostrar como poder crear su ambiente de pruebas de vCloud Director 5.1 en unos cuantos minutos con soporte para nested ESXi, para esto estaremos utilizando el appliance virtual de vCD que pueden encontrar aquí

http://www.vmware.com/products/vcloud-director/overview.html

Necesitarán pedir una evaluación de vCD y esto les brindará la capacidad de poder descargar el appliance virtual:

Una vez descargada, solo es cuestión de importarla a nuestro ambiente, configurar las distintas variables del descriptor ovf/ova, la encendemos y ¡voilá!

Claramente este appliance tiene sus limitantes, entre las cuales se encuentran:

  • Solo una celula – No se pueden agregar appliances virtuales de vCD ni instalaciones de vCD como celulas extra a nuestro ambiente.
  • Dos vCenter Servers – Solo podemos registrar dos vCenters, para nuestro ambiente de laboratorio o incluso para realizar POCs esta perfecto debido que incluso podemos demostrar Elastic VDCs.
  • Hasta 10 Organizaciones – Solo podemos registrar/crear 10 org VDCs, desde mi perspectiva es incluso una cantidad alta para demostraciones o laboratorio.
  • Hasta 100 VMs – Acá siento que nos quedamos un poco cortos pero sabiendo utilizarlas sabiamente para nuestro lab podría darnos la capacidad necesaria.
  • Hasta 11GB en la Base de datos – la base de datos embebida puede almacenar hasta 11GB de información.

Ya cargada nuestro appliance la configuarmos y dejamos puesta a punta firmandonos en la consola web, estos pasos no los estaré tocando debido a que se trata de temas muy sencillos.

Vamos a confirmar que nuestros servidores ESXi son capaces de poder ejecutar VMs de ESX/ESXi de manera nested, para esto podemos confirmalo de manera muy sencilla, abrimos un browser y apuntamos a la dirección:

https://ipdenuestrohostesxi/mob/?moid=ha-host&doPath=capability

y vamos a buscar una capacidad que se llama

nestedHVSupported

En mi caso el valor es “true” por lo cual mis servidores soportan ESXi nested, en este caso son procesadores AMD lo cual demuestra que mis procesadores tienen AMD-V y RVI.

Con esto ya estamos seguros que podremos ejecutar VMs de ESXi en nuestros servidores ESXi físicos, para esto vamos a modificar la base de datos de Oracle embebida del appliance virtual para tener los sistemas operativos guest de ESX/ESXi por lo cual debemos abrir una sesión ssh a nuestro appliance virtual de vCD y vamos a realizar los siguientes pasos:

  • Exportar las variables de sistema de Oracle:

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe

export PATH=$ORACLE_HOME/bin:$PATH

export ORACLE_SID=XE

  • Conectarnos con sqlplus a nuestra base de datos de vCloud Director

sqlplus vcloud/VCloud@127.0.0.1/xe

  • Insertar la familia de Guest OS

INSERT INTO guest_osfamily (family,family_id) VALUES (‘VMware ESX/ESXi’,6);

Esto nos debe dar un resultado de “1 row created”

  • Insertar el sistema operativo guest ESXi 4

INSERT INTO guest_os_type (guestos_id,display_name, internal_name, family_id, is_supported, is_64bit, min_disk_gb, min_memory_mb, min_hw_version, supports_cpu_hotadd, supports_mem_hotadd, diskadapter_id, max_cpu_supported, is_personalization_enabled, is_personalization_auto, is_sysprep_supported, is_sysprep_os_packaged, cim_id, cim_version) VALUES (seq_config.NextVal,’ESXi 4.x’, ‘vmkernelGuest’, 6, 1, 1, 8, 3072, 7,1, 1, 4, 8, 0, 0, 0, 0, 107, 40);

nuevamente nos debe de dar como resultado la creación de un row

  • Insertar el sistema operativo guest ESXi 5

INSERT INTO guest_os_type (guestos_id,display_name, internal_name, family_id, is_supported, is_64bit, min_disk_gb, min_memory_mb, min_hw_version, supports_cpu_hotadd, supports_mem_hotadd, diskadapter_id, max_cpu_supported, is_personalization_enabled, is_personalization_auto, is_sysprep_supported, is_sysprep_os_packaged, cim_id, cim_version) VALUES (seq_config.NextVal, ‘ESXi 5.x’, ‘vmkernel5Guest’, 6, 1, 1, 8, 3072, 7,1, 1, 4, 8, 0, 0, 0, 0, 107, 50);

Con esto logramos agregar las versiones de ESXi que queramos tener para poderlos trabajar como VMs dentro de nuestra infraestructura de laboratorio

  • activar el esxvm a nivel de nuestros servidores, si estos fueron preparados por vCD se les agregará la linea (en el caso de ESXi 5.1) vhv.allow, en el archivo /etc/vmware/config para esto actualizamos nuestra base con la siguiente línea:

UPDATE config SET value=’true’ WHERE name=’extension.esxvm.enabled’;

  • Reiniciamos los servicios de vCloud Director

service vmware-vcd restart

Si ingresamos a vCloud director y creamos un nuevo vApp agregando una nueva máquina virtual podemos ver que ya tenemos disponible ESXi como VM:

identificar y reparar corrupción de archivos en la vSphere Storage appliance

Que tal gente, el día de hoy les voy a dar un ejemplo de como podemos reparar una corrupción o inconsistencia a nivel de archivos en la VSA de VMware.

Claramente este procedimiento no aplica en todos los casos y en el caso que aplicase recuerden que tiene que ser realizado por soporte de VMware.

En la siguiente imagen podemos notar que tengo un cluster de VSA de 3 nodos (3 hosts ESXi):

 

Como podemos ver se están presentando 3 distintos exports de almacenamiento:

  • VSADs-0 (online)
  • VSADs-1 (offline)
  • VSADs-2 (online)

El export “VSADs-1” esta fuera de línea, este está siendo presentado por la VSA-0:

Vamos a identificar cual es el problema, comenzamos por obtener la ip de dicha VSA, para esto abrimos una consola remota desde nuestro vSphere client a dicha VSA e ingresamos con las credenciales root/svapass:

Abro una sesión ssh a dicha a la VSA-0 que tiene la ip 192.168.4.31, y reviso el log “sva.log”:

 grep -i fsck /var/log/sva.log

Podemos notar que efectivamente tenemos una inconsistencia a nivel de archivos:

Solo es cuestión de ejecutar un File system check o fsck en dicho export, en este caso como podemos ver en la imagen es el export

“/dev/mapper/MemberVolume-194483e7-5c12-47e9-8f27-7a32a6a7ef1a”

Podemos ver en la imagen que tenemos un problema en el inode 12 del archivo “archivo_dummy”, con este simple fsck se puede arreglar dicho problema.

Reiniciamos la VSA-0 y esperamos a que los datos entre las VSAs sean sincronizados (en las tareas recientes) y debe de mostrarse “online” el datastore:

 

¿Como habilitar ssh para la VSA (vSphere Storage appliance)?

Que tal gente, el día de hoy les voy a pasar un tip de como activar el servicio de ssh en los appliances virtuales de VSA, esto claramente SOLO DEBE SER HECHO PARA MOTIVOS DE DEMOSTRACIÓN, ENTRENAMIENTO O EN APOYO DE SOPORTE VMWARE.

Para esto, solo debemos seguir los siguientes pasos:

Paso 1 -. Abrimos la consola de la VSA a la que queremos habilitar ssh:

Paso 2-. ingresamos las credenciales:

root/svapass

Paso 3-. Ingresamos el siguiente comando:

/usr/sbin/toggle_ssh enable

Con este comando ssh debe ser habilitado, aquí podemos ver que se crean las llaves de RSA, ahora solo es cuestión de verificar la conectividad

Con esto podemos obtener bastante información sobre nuestro cluster y poder realizar troubleshooting del mismo, en articulos siguientes estaré publicando algunos tips para poder obtener información del cluster, poder recuperar un cluster, etc.

Agregando dispositivos de Hardware no reconocidos para ESXi5

Que tal gente, me encuentro actualizando mi laboratorio recreando todos los vPods y agregando nuevas tecnologias por parte de VMware (mismas que estaré demostrando en posts). Y me di a la tarea de instalar un nuevo whitebox que anteriormente se utilizaba para algo no tan productivo (juegos??) sus caracteristicas son las siguientes:

  • CPU AMD Phenom x3 720 black edition @ 2.8 GHz
  • 8GB de RAM
  • MOBO MSI k9n SLi v2

Podemos ver que es un equipo un poco chico, por lo cual lo consideré para ejecutar mis VMs de core, es decir, servicios de AD, DNS, DHCP, vCenter, Etc etc, Al tratarse de un lab no me importa mucho la redundancia y tolerancia  fallos.

Descargué la última versión de ESXi 5 Build 603296, y al instarlo el primer problema que se me presenta es que no se reconocieron mis discos, este tipo de problemas con controladoras SATA ya los había tenido en versiones anterioroes (VI3) y la solución es muy simple, solo cambiar el modo de la controladora de IDE a AHCI, lo cual funcionó y me reconocio el disco local en el momento de la instalación.

Todo iba perfecto hasta que en el momento que reinicio mi sistema puedo notar que el disco local no era reconocido para crear un datastore, cosa que me parecia algo raro ya que en el momento de la instalación lo reconoció y que el sistema operativo podia iniciar.Por lo cual decidi cargar el modulo de ahci manualmente desde ssh:

vmkload_mod ahci

Comando que cargó el modulo de kernel y con el cual pude ver mi disco local, todo iba bien en este punto, pero ¿Que pasaría en el momento de realizar un reincio? claramente esto no se iba a hacer de manera automática, por lo cual primero pense en editar el archivo de /etc/rc.local pero el problema podia no ser que el modulo no era cargado sino que no se reconocia el hardware. Por lo cual pense en otra alternativa que ya había utilizado previamente y es la de editar el archivo los archivos .map y crear mi propio oem.tgz cosa que funcionaba en versiones ESXi 3 y 4, pero en ESXi 5 es mucho más sencillo, ya que como podemos ver en la siguiente imagen:

En todos los vgz o ejecutivos que son cargados a memoria podemos encontrar uno llamado “sata-ahc.v00” donde al expandirlo pude ver lo siguiente:

Todo el layout que crea este archivo, o básicamente todos los archivos que a partir de este comprimido se colocan en el sistema de del hipervisor en memoria o visorfs. Aquí me llamo la atención el archivo ahci.map, donde si lo editamos podemos ver lo siguiente:

Se trata de los PCI IDs de los dispositivos que ese driver en especifico (AHCI) podría controlar, decidí investigar cual es el PCI ID de mi tarjeta SATA local, esto lo logramos de manera muy sencilla, con el siguiente comando:

lspci -v

Y se nos muestra información como la siguiente:

Aquí podemos ver que tenemos un dispositivo llamado:

000:000:10.0 SATA controller Mass storage controller: nVidia Corporation MCP65 AHCI Controller [vmhba2]

El cual tiene el siguiente PCI ID:

10de:044d

Teniendo esta información solo es cuestión de editar el archivo “achi.map” y agregar el PCI ID como dispositivo soportado por dicho driver:

Necesitamos re empaquetar todo el vgz que descomprimimos, para esto, utilizamos la utileria tar:

tar -cvf sata-ahc.tar etc/ usr/ (las carpetas etc y usr son aquellas que fueron descomprimidas a la carpeta “test” a partir del archivo sata-ahc.v00)

Una vez re empaquetado todo el contenido con la modificación del archivo .map donde agregamos el PCI ID de nuestro dispositivo vamos a convertir dicho tar a vgz, para esto utilizamos vmtar:

vmtar -c sata-ahc.tar -o sata-ach.v00

Y para finalizar copiamos el vgz a la carpeta /bootbank

cp sata-ach.v00 /bootbank

Con esto, al iniciarse el sistema y cargar todos sus ejecutivos o vgz al ramdisk y cargarse el modulo de ahci se reconocerá el PCI ID de nuestro dispositivo y se presentará:

RECUERDEN QUE ESTO NO ES SOPORTADO POR VMware, POR LO CUAL SOLO ESTA PENSADO PARA MOTIVOS DE DEMOSTRACIÓN O PARA SUS LABORATORIOS ¡NO PARA AMBIENTES PRODUCTIVOS! SIEMPRE DEBEMOS APEGARNOS AL HCL.

Stateless ESXi y VMware Auto Deploy – parte I

Que tal gente, el día de ayer echando un ojo en las comunidades pude ver una pregunta sobre ESXi y drivers, lo que me hizo recordar un post de william lam en su blog sobre como insertar drivers a un iso de ESXi utilizando el appliance Auto Deploy de una manera sencilla y rápida.. no como los antiguos métodos modificando nuestro oem.tgz.

Primero quiero dejar en claro cual es el concepto de “Stateless” y también de “Stateful”, para esto necesitamos conocer un poco más a fondo la arquitectura de ESXi:

El vmkernel de ESXi utiliza un sistema de archivos que reside totalmente en memoria RAM, a este sistema de archivos se le conoce como visorfs, el cual esta constituido por una serie de comprimidos .gz o vgz ( vmtar) que son cargados a la memoria RAM en el momento que se realiza el boot del sistema. Podemos comprobar que el visorfs esta montado en sistema con un simple:

mount

En la primera fase  el bootloader mboot c32 se encarga de cargar  los paquetes conocidos como Executives, que son los siguientes:

  • tboot.gz – este paquete verifica la integridad del sistema utilizando un componente de hardware conocido como Trusted Platform module, esto nos permite verificar integridad de la información cargada por el vmkernel, para poder prevenir malware y código malicioso. Esto se logra mediante el uso de una clave RSA que viene incluida en dicho modulo de hardware (TPM) con la cual se firman digitalmente los módulos y código del vmkernel para poder identificar modificaciones si es que llegaran a existir.
  • vmkboot.gz (también conocido como b.z)- este paquete prepara la memoria para el paquete vmkernel.gz.
  • vmkernel.gz (también conocido como k.z , vmk.gz.) – Inicializa todos los subsistemas y la memoria. En este proceso se incluye el inicio del filesystem visorfs, este es almacenado en /bootbank.

Una vez cargados estos paquetes a la RAM (ramdisk) se procede a cargar los paquetes que se les llama “tardisks” los cuales constituyen el la estructura básica del sistema, algunos de ellos son guardados en /bootbank :

  • a.z
  • c.z
  • cimstg.tgz
  • license.tgz
  • m.z
  • oem.tgz
  • pkgdb.tgz
  • s.z
  • state.tgz

Por /bootbank debemos de entender a la partición FAT16 donde residen los comprimidos llamados “executives” y los “tar disks”, existen 2 /bootbanks, uno con la versión actual de ESXi y otra con la versión pasada. Esto se tiene pensado para que en el caso que se tenga una falla con la versión actual (en el caso de haber sido actualizada) se pueda carga una versión anterior.

Bueno y a todo esto ….

¿Cual es la diferencia entre un sistema Stateless y Stateful?

En los “Tardisks” podemos encontrar uno llamado “state.tgz”, este tar disk guardan los archivos de sistema que deberán persistir entre reinicios (generalmente los que residen en /etc)  marcados como “sticky” o el atributo “T”, estos archivos los podemos ver con un simple

ls -lah

Cada hora un script (/sbin/auto-backup.sh) se encarga de respaldar aquellos archivos que han cambiado y que forman parte del state.tgz, los archivos modificados se pueden identificar por .# ,este respaldo se realiza al disco local creando un nuevo “local.tgz” que a su vez reside dentro de un nuevo state.tgz  dentro de la partición /bootbank. Por lo cual la siguiente vez que se inicie el sistema se leerán los archivos contenidos en dicho state.tgz.

Entonces básicamente aquí tenemos la diferencia:

  • Stateless – un sistema que no tiene un medio de booteo local (discos o LUN) . Por lo cual no se podrá realizar el respaldo de aquellos archivos de sistema que se modificaron, en el momento de reinicio se perderán todos los cambios debido a que todo reside en RAM

  • Stateful – un sistema que tiene discos locales (discos o LUN) se le conoce como stateful, debido a que aquellos archivos que se modifiquen persistirán a un reinicio, en este caso el script de respaldo podrá crear un nuevo state.tgz dentro de la partición bootbank cada vez que se modifiquen archivos.

¿En que me puede ayudar VMware Auto Deploy?

Este appliance está basado en otro appliance muy conocido de VMware, vMA. Nos permite hacer un deploy  rápido de servidores ESXi, este appliance tiene servicios de DHCP,  TFTP , HTTP, un repositorio de imágenes, etc.

Básicamente este appliance se encarga de darles información de red y parámetros de booteo. Lo interesante aquí es que tenemos la capacidad de configurar nuestros hosts utilizando un vCenter y Host profiles, todo de manera automatizada. El proceso se ilustra en esta imagen:

En los siguientes posts de esta serie les estaré mostrando con ejemplos como configurar y utilizar este appliance.