VCAP-DCA

VCAP5-DCA Beta aprobado

Que tal gente, les comento que me hicieron saber el día de ayer que aprobé el examen beta de VCAP5-DCA, desde mi perspectiva no existe una gran diferencia con respecto al VCAP4-DCA, solo el tema de autodeploy. Les recomiendo seguir el blueprint y con eso ya estarán listos para presentar el examen 😉

Crear regla de SATP para identificar almacenamiento como SSD

Que tal gente, existen casos en los cuales un dispositivo de almacenamiento no sea detectado como de estado solido o SSD en ESXi 5, para estos casos tenemos la opción de crear reglas de SATP (Storage Array Type Plugin) con la opción de marcar dicho dispositivo como SSD en el momento que el stack de NMP lo reclama.

Una vez reclamado e identificado como SSD podemos habilitar Host Cache.

¿Como identifico un dispositivo de almacenamiento como SSD?

Primero identificamos nuestro dispositivo, para esto utilizamos esxcli:

esxcli storage nmp device list

En este caso estaré trabajando con un LUN presentado por un appliance virtual de Lefthand, que tiene el identificador “naa.6000eb31e698711c000000000000000c”

Podemos notar que dicho dispositivo es identificado como “non-ssd” desde el vSphere client:

En este caso tenemos que crear una nueva regla de SATP para que dicho dispositivo sea identificado como SSD, para esto estaremos utilizando esxcli nuevamente:

esxcli storage nmp satp rule add –satp VMW_SATP_DEFAULT_AA –device
naa.6000eb31e698711c000000000000000c –option=enable_ssd

Podemos notar que en el comando debemos especificar el SATP utilizado para dicho dispositivo, en este caso VMW_SATP_DEFAULT_AA, esta información la obtuvimos en el comando anterior, también podemos notar que se especifica el dispositivo que se verá afectado por esta nueva regla. Por último agregamos la opción para habilitar SSD.

Una vez hecho esto, solo es cuestión de verificar que nuestra regla haya sido creada con el siguiente comando, realizaremos un filtro de todas las reglas con un simple grep:

esxcli storage nmp satp rule list | grep enable_ssd

Reclamamos el dispositivo:

esxcli storage core claiming reclaim -d naa.6000eb31e698711c000000000000000c

Y podemos ver que ahora ya es detectado como SSD, es posible que se requiera un refresh del cliente para que el cambio se vea reflejado:

VCAP – Sección 7– seguridad para hosts ESX/ESXi

Que tal gente, después de algunas semanas difíciles, trabajo, problemas personales, etc. estoy de regreso para continuar con los temas del examen VCAP-DCA . En esta ocasión nos toca hablar sobre seguridad específicamente en el caso de nuestros hosts ESX/ESXi.

Identificar características de seguridad a nivel de switch virtual

Bueno aquí básicamente debemos conocer que políticas de seguridad tenemos disponibles:

  • Promiscuous mode- Con esta política definimos si el switch o portgroup que estemos modificando permitirá que las vms conectadas al mismo puedan capturar paquetes que no estén específicamente destinados para ellas, útil cuando necesitamos hacer sniffing de red.
  • MAC Address Changes – Con esta política definimos si permitirá la modificación de mac address desde el sistema operativo de dicha VM.
  • Forged Transmits – Con esta política definimos si se permite o no al sistema operativo de la vm crear paquetes con una mac address distinta a la suya.

Agregar/editar y remover usuarios/grupos en un host ESX

Tenemos 2 maneras de crear, remover y editar usuarios, desde la linea de comando o desde la interfaz gráfica:

  • vicfg-user – utilizando vSphere CLI / vMA podemos crear usuarios remotamente en nuestros hosts, aquí les dejo unos ejemplos:

vicfg-user –server esxi01.hispavirt.test.com –entity user –operation add –login soporte –password password

–entity user/group

–operation add/delete/list/modify

–login nombre de usuario


vicfg-user –server esxi01.hispavirt.test.com –entity user –operation delete –login soporte

Para agregar usuarios directamente desde la interfaz gráfica ingresamos con nuestro vSphere client y vamos al tab de “Local Users & Groups”, click derecho y “add”:

Si nosotros estamos utilizando ESX/ESXi 4.1 +, con nuestros servidores agregados a un dominio windows si quisiéramos agregar permisos a usuarios windows vamos a el tab de “permissions” y hacemos click derecho> Add Permission..

Personalizar la configuración de SSH para una mejor seguridad

Aquí básicamente es recordar que para utilizar ssh la mejor practica es siempre accesar con un usuario que no sea root y en el caso de requerir privilegios podemos realizar un SU.

Para habilitar el acceso de root en ESX:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=8375637

Habilitar o deshabilitar la verificación de certificados SSL

Existe un kb de VMware de como realizar esto, muy sencillo aquí les dejo el link:  KB Article: 4646606

Generar certificados de Hosts ESX/ESXi

En el momento de la instalación tanto ESX como ESXi generan sus propios certificados SSL, los cuales los podemos encontrar en  /etc/vmware/ssl, para regenerar estos certificados en el caso de haberlos borrado o haber cambiado el hostname seguimos los siguientes pasos:

  • ESXi: En la consola directa o DCUI, seleccionamos “reset system configuration”, con esto todos los parámetros modificados serán regresados a su estado default, reiniciamos el servidor y se crearan nuevos certificados ssl.

  • ESX: navegamos a la ruta donde se encuentran nuestros actuales certificados de ssl, y podemos ya sea borrar los certificados, o renombrarlos:

mv rui.crt orig.rui.crt

mv rui.key orig.rui.key

reiniciamos  el servicio de hostd:

service mgmt-vmware restart

y tendremos listos nuevos certificados.

Habilitar Lockdown mode para nuestros hosts ESXi

El modo “lockdown” previene que nos podamos loggear con el usuario root a través del vSphere client, PowerCLI, vMA, y demás.

Para habilitarlo tenemos la capacidad de realizarlo directamente en la consola o DCUI,  a través del vSphere client o vim-cmd:

  • DCUI:

  • vSphere client – seleccionamos nuestro host, hacemos click en configuration>security profile:

  • vim-cmd – vim-cmd -U dcui vimsvc/auth/lockdown_mode_enter

Remplazar certificados default por certificados de una autoridad de CA

Aquí les voy a dar un ejemplo de como crear certificados con OpenSSL y un CA de Windows 2003, vamos a seguir los siguientes pasos:

  • Paso 1-. navegamos a nuestra carpeta bin de OpenSSL
  • Paso 2-. creamos nuevos certificados

openssl req -new -nodes -out micert.csr -config openssl.cfg

En el paso donde les pregunta el “common name” aquí debemos ingresar el FQDN de nuestro vCenter o host ESX/ESXi para el cual sea este certificado.

En este punto ya tendremos creados 2 archivos en la carpeta bin de OpenSSL, micert.csr y privkey.pem.

  • Paso 3-. Abrimos un navegador y apuntamos a nuestro servidor CA, Https://myservidor/certsrv, seleccionamos “request a certificate” > “advanced certificate request” > “submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file”

Aquí  necesitamos abrir el archivo “micert.csr” que creamos anteriormente y se encuentra en la carpeta bin de OpenSSL, copiamos todo su contenido para después pegarlo en el campo de saved request:

Pegamos el contenido, y cambiamos el template a “web server” y hacemos click en “submit”

Una vez hecho esto, descargamos el certificado “base 64 encoded”

  • Paso 4-. Ya tenemos nuestro nuevo certificado, solo es cuestión de abrir nuevamente nuestra linea de comando, navegar a openssl\bin, y vamos a ejecutar el siguiente comando sobre nuestro nuevo certificado:

openssl x509 -in certnew.cer -out micert.cer

Con este ultimo paso ya tenemos listo nuestro certificado, en este caso creamos uno para el host vcenter.hispavirt.test.com, solo es cuestión de cambiar el “common name ” al host que se requiera. Para sustituir los certificados:

  • vCenter: navegamos a “C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL”, y copiamos los archivos “micert.cer” y “privkey.pem”, realizamos un backup de nuestros certificados actuales (rui.crt y rui.key). Paramos los servicios del vCenter, y renombramos los archivos recién copiados a:

micert.cer > rui.crt

privkey.pem > rui.key

  • ESXi – renombramos de igual manera los archivos micert.cer y privkey.pem, solo que esta vez vamos a utilizar vSphere Cli para copiar los archivos a nuestros hosts:

vifs –server <hostname> –username <username> –put rui.crt /host/ssl_cert
vifs –server <hostname> –username <username> –put rui.key /host/ssl_key


Configurar timeout de SSL

Tanto en ESX/ESXi, necesitamos editar el archivo llamado “config.xml” que encontramos en la ruta “/etc/vmware/hostd/” y modificamos el valor que requerimos, tenemos 2 tipos:

  • read timeout: es el valor en milisegundos para aquellas conexiones que ya completaron el handshake de SSL
  • handshake timeout: es el valor en milisegundos para aquellas conexiones que todavía no completan el handshake de SSL.

Para modificarlos, editamos el archivo “config.xml” e ingresamos las siguientes lineas:

  • read timeout – <readTimeoutMs>tiempoenms</readTimeoutMs>
  • handshake timeout – <handshakeTimeoutMs>tiempoenms</handshakeTimeoutMs>

Seguridad de Proxy web en hosts ESX/ESXi

Aquí vamos a necesitar modificar un archivo llamado proxy.xml que encontramos en la ruta /etc/vmware/hostd, en el cual podemos definir que puerto se estará utilizando, si se aceptan conexiones http, https, etc. les recomiendo leer la guia de configuración de esxi/esx para poder llevar a cabo esta tarea.

Politicas de passwords complejas

Les recomiendo leer los siguientes links para realizarlo:

En el caso de ESX, podemos utilizar esxcfg-auth , para definir días de validez de las passwords:

esxcfg-auth –maxpassdays=90 –minpassdays=30 –passwarnage=75

-maxpassdays – validez de hasta 90 días

-passwarnage – se nos mandará un warning de password a los 75 días

-minpassdays – la password deberá ser utilizada al menos 30 días

Identificar metodos para la seguridad a nivel de VM

Les recomiendo leer el draft del whitepaper “Security Hardening Guide” para vSphere 4.1:

http://communities.vmware.com/docs/DOC-14548

VCAP – Sección 6 – Configurar,administrar y analizar logs de vSphere

Que tal gente, vamos a continuar con los temas de preparación para el examen VCAP-DCA, vamos a hablar de los distintos logs que tenemos en vSphere, que información nos ofrece cada uno de estos y donde los podemos encontrar. También estaremos viendo como poder generar los “bundles” (conjuntos de logs con fines de soporte), logging centralizado,etc.

Identificar logs de vCenter y donde encontrarlos
Todos los logs del vCenter los podemos obtener directamente utilizando nuestro vSphere client, yendo directamente a administration>System Logs, donde podremos ver dichos logs y también exportarlos.

Todos estos logs se encuentran en la ruta %ALLUSERSPROFILE%\Application Data\VMware\VMware VirtualCenter\Logs, podemos encontrar 2 tipos de logs:

  • vpxd-xx.log – log operacional del vCenter.
  • vpxd-profiler-xx.log – en este log viene información de estadísticas del VOD (VMware Virtual Center Operational Dashboard).

Identificar logs de ESX/ESXi

Al igual que en el caso del vCenter, podemos obtener y ver los logs de nuestros hosts directamente con el vSphere client en Administration > System Logs

Para ESX tenemos los siguientes logs:

  • logs de vmkernel – aquí se guarda toda la información relacionada con el kernel, lo encontramos en /var/log/vmkernel.log
  • logs de vmkwarning – aquí se guarda todos los eventos que estan marcados con “warning” en el log de vmkernel, lo encontramos en /var/log/vmkwarning.log
  • logs de vmksummary – en este log encontramos información del uptime y downtime, lo encontramos en /var/log/vmksummary.log
  • log de hostd – aquí podemos ver información del agente de management de ESX (mgmt-vmware), lo encontramos en /var/log/vmware/hostd.log
  • log de messages – aquí encontramos información de la actividad que se ha tenido en el service console, lo encontramos en /var/log/messages
  • log del agente de vCenter (vpxa) – este log solo lo tendremos cuando el host pertenece a un vCenter, lo podemos encontrar en /var/log/vmware/vmware/vpx/vpxa.log
  • logs de HA (aam) – estos logs  solo los vamos a encontrar en el momento que nuestro host pertenezca a un cluster de HA, podemos encontrarlo en /var/log/vmware/
  • logs de SW ISCSI – lo encontramos en /var/log/vmkiscsid.log
  • logs de de Sysboot – aquí podemos encontrar todos los mensajes de información de boot de nuestro sistema, lo encontramos en /var/log/boot-logs/sysboot.log

Para ESXi tenemos los siguientes logs:

En este caso los logs cambian un poco debido a la pérdida del service console:

  • logs de vmkernel,vmkwarning y hostd –  los encontramos en el log /var/log/messages
  • logs específicos de hostd – los encontramos en /var/log/vmware/hostd.log
  • logs del agente de vCenter – los encontramos en /var/log/vmware/vmware/vpx/vpxa.log
  • logs de sysboot – los encontramos en /var/log/sysboot.log
  • logs de HA (aam) – estos logs  solo los vamos a encontrar en el momento que nuestro host pertenezca a un cluster de HA, podemos encontrarlo en /var/log/vmware/

Generar bundles de logs de vCenter y ESX/ESXi

Para generar el bundle de diagnostico de algún host ESX/ESXi lo podemos realizar desde el vSphere client, vamos a administration>System Logs y “Export System Logs”


Para generar el bundle de logs del vCenter, debemos ir a menu inicio>todos los programas>VMware>Generat vCenter Server log bundle

Utilizar vicfg-syslog para configurar el log centralizado de nuestros hosts ESX/ESXi

Les recomiendo leer mi post “Esxi Tips – 01 – direccionar nuestros logs a un servidor Syslog” aquí podrán encontrar un ejemplo y pasos de como configurarlo.

Configurar vMA como syslog

Con el appliance vMA (vSphere management assistant) viene incluido el vilogger con el cual tenemos la capacidad de extraer logs de nuestros hosts, para configurarlo seguimos estos pasos:

Paso 1-. Ingresamos a nuestra vMA y agregamos el host con vifp e ingresamos las credenciales de root de dicho servidor.

sudo vifp addserver esxi01.hispavirt.test.com

Paso 2-. Verificamos que efectivamente fue agregado dicho servidor a nuestra lista de vifp

vifp listservers

Paso 3-. Habilitamos vilogger para dicho host:

vilogger enable –server esxi01.hispavirt.test.com –numrotation 20 –maxfilesize 10 –collectionperiod 10

–numrotation número de logs a guardar cuando se llega al número configurado se borrará el más antiguo.

–maxfilesize tamaño máximo en MB  para los logs, el default es de 5 MB.

–collectionperiod es el intervalo en segundos en el cual se estarán colectando los logs de dicho host.

¿Cómo puedo ver los logs dentro de la vMA?

Todos los logs de hosts que hayamos configurado para ser obtenidos por nuestra vMA serán almacenados en /var/log/vmware/<FQDNoIP>, ruta que podemos modificar en el archivo /etc/vmware/vMA/vMA.conf.