ESXi

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.

Soporte para MAC addresses arbitrarias porfin en vSphere 5

Que tal gente, hace tiempo ya que escribí mi ultimo post, este día regreso para dejarles algo interesante que en muchos casos nos va a librar de dolores de cabeza. En versiones anteriores de VMware vSphere/VI no se podía configurar una mac address que saliera del rango permitido por VMware, se nos mostraba algo como esto:

Esta capacidad era algo que se buscaba estuviera disponible desde los tiempos de ESX 2x, cosa que hasta vSphere 5 se nos entregó, en la siguiente imagen podemos ver como al editar una VM con una MAC Address que esta fuera del rango esta no presenta problemas:

Como podemos ver esta mac address “00:34:0f:09:02:0b” esta fuera del rango permitido por VMware (00:50:56), incluso de aquellos rangos adquiridos por VMware ante la IANA:

Y es aun más interesante que esta mac address es automáticamente reconocida y utilizada en el sistema operativo:

Esta capacidad nos da una mayor flexibilidad en el momento de realizar conversiones P2V ya que podemos mantener la MAC address del sistema físico.

 

 

¿vNUMA?

Que tal gente, hace BASTANTE tiempo que no tenía oportunidad de escribir debido al trabajo y compromisos personales, pero estoy de vuelta y esta vez les voy a platicar de algo bastante interesante que se introdujo con vSphere 5.0 y ofrece una plataforma aun más escalable y capaz de virtualizar todo tipo de aplicaciones. Vamos a platicar un poco sobre vNUMA

Comencemos por entender lo básico:

¿Que es NUMA?

(Tomando un extracto de mi articulo “VCAP – Sección 3 – optimización de performance para vSphere”)

NUMA (non uniform memory access) un tipo de arquitectura en cuanto a la comunicación entre procesadores y memoria se refiere, a diferencia de arquitecturas anteriores cada procesador o grupo de procesadores  tienes  su propia memoria ram, a este grupo de memoria y procesadores se le llama “nodo numa”:

NODO NUMA

Cada nodo numa tiene un bus a través de cual se lleva a cabo la comunicación entre cpu y memoria a esto se le llama memoria local, pero también se puede acceder memoria de otros nodos que se le conoce como “foreign” o memoria remota claro que bajo un costo en cuanto al performance.

El algoritmo de numa en VMware se encarga de balancear las vms entre los nodos dependiendo de la carga que tiene el sistema, el nodo al que se asigna se le llama “home node” y este mismo algoritmo trata de asignar memoria en su mismo nodo numa para que esta memoria sea local.

¿Que es vNUMA?

En vSphere 5.0 se presenta la topología NUMA del sistema físico a las vms, permitiéndole a los sistemas operativos guest y las aplicaciones que son ejecutadas dentro de estas VMs el poder tomar decisiones y optimizaciones “numa-aware” y poder colocar los distintos threads en donde se podría entregar un mejor rendimiento.

vNUMA esta activado por defecto en todas aquellas VMs con 8 vCPUS en adelante (se puede modificar a través de la opción avanzada ” numa.vcpu.min “), en versiones anteriores de vSphere o VI las VMs creían que estaban siendo ejecutadas en un sistema UMA.

Con el aumento en la capacidad de vSphere 5.0 en cuanto a vCPUs y Memoria RAM que puede tener las VMs también aumenta la posibilidad que estas “Monster VMs” deban de ser servidas por varios nodos numa del sistema físico es por eso que poderle presentar al sistema operativo guest la topología es esencial para que el rendimiento también pueda escalar acorde.

En las siguientes imágenes (Extracto de la sesión VSP2884 del VMworld 2011) podemos ver con mayor claridad esto:

Sin vNUMA

Esta imagen nos muestra como las VMs trabajan sin vNUMA. Podemo ver que en la vista del sistema operativo guest (VM) se cree que se está trabajando en un sistema UMA, en este caso teniendo 4 vCPUs (cuadros rojos) los cuales al tener que ser procesados por el vmkernel son enviados a distintos nodos NUMA teniendo una localidad de memoria RAM mucho menor, 25%.

Con vNUMA

En este caso podemos ver que nuevamente tenemos el sistema operativo guest con 4 vCPUs, y se le presenta la topología NUMA del sistema físico, permitiéndole así al sistema operativo guest tomar decisiones “numa-aware” y colocar los distintos threads en un mismo nodo obteniendo así una localidad de memoria del 100%.

Existe un whitepaper excelente que les invito a leer sobre el rendimiento de aplicaciones HPC virtualizadas utilizando vNUMA y como se puede obtener rendimiento muy cercano al nativo, ¿Estaremos contemplando el comienzo de HPC sobre VMware?:

http://labs.vmware.com/publications/performance-evaluation-of-hpc-benchmarks-on-vmwares-esxi-server

vSphere 5 – ¿Firewall en ESXi?

Que tal gente, continuando con las nuevas capacidades de vSphere 5 nos toca hablar de algo muy interesante, firewall para nuestros hosts ESXi.

En versiones anteriores de vSphere, ESX tenia un firewall basado en iptables para el Service console, debido a que en ESXi no se tiene este SC el sistema se encontraba vulnerable. Con vSphere 5 se agrega un firewall a ESXi el cual a diferencia del firewall de nuestra vieja arquitectura no esta basada en iptables.

Tenemos la opción de configurar este firewall desde el GUI de nuestro vSphere client de manera muy similar a la que se tenia para los servidores ESX:

Este firewall esta orientada a servicios y es de tipo stateless, lo cual significa que trabaja en capa 3 analizando la cabecera de los paquetes (al no tener memoria de paquetes anteriores son vulnerables a spoofing). Con este firewall nosotros podemos crear reglas basadas en IP/Mascara de subred.

Anteriormente nosotros teníamos la capacidad de configurar el firewall de nuestros hosts ESX desde la interfaz grafica, directamente en la consola o a través de vSphere CLI con esxcfg/vicfg-firewall. En vSphere 5 estos comandos ya no existen y se agrega esxcli network firewall.

Aquí les dejo un video de como se trabaja con el firewall desde el vSphere client y un ejemplo utilizando esxcli network firewall:

 

VCAP – Sección 5 – Implementar y mantener Host Profiles

Que tal gente continuando con la serie de VCAP-DCA nos toca hablar de Host Profiles, vamos a conocer en que nos apoyan y como configurarlos, también podremos ver cuáles son las limitaciones actuales.

¿Qué es un Host Profile?

Básicamente es una plantilla de configuraciones de red, almacenamiento, seguridad, etc. que nosotros creamos a partir de un host ESX/ESXi que tiene todos estos parámetros de manera ideal. Utilizando este profile podemos mantener la misma configuración a través de un gran número de hosts lo cual simplifica la administración del día a día.

Para poder utilizar esta capacidad necesitamos tener el licenciamiento enterprise plus.

Limitaciones

  • En el caso de contar con clusters basados en ESX y ESXi no podremos utilizar host profiles, debido a diferencias que existen entre los mismos, en este caso se recomienda crear clusters de ESX y clusters de ESXi para poder utilizar host profiles.
  • Solo podemos aplicar un profile por cluster.
  • No podemos incluir configuraciones de ISCSI.
  • No podemos incluir información de licenciamiento.
  • No podemos incluir configuraciones de multipathing.
  • No podemos incluir políticas de Distributed switches.

Utilizar el editor de perfiles para editar y/o deshabilitar políticas

Para crear un perfil de un host solo es cuestión de seleccionar nuestro host , click derecho sobre el mismo y Host Profile>Create Profile from Host…

Esto nos abrirá un wizard donde tendremos que ingresar el nombre del perfil y descripción del mismo, este host será tomado como referencia para el perfil creado.

Una vez creado este perfil o nuestros perfiles requeridos, podemos editarlos desde Home>management>Host Profiles.. , donde podremos seleccionar el perfil que necesitamos modificar click derecho sobre el y “Edit Profile…” , esto nos abrirá la ventana de edición:

En esta ventana podremos ver todas las políticas y configuraciones que se obtuvieron a partir del host de referencia agrupadas en “sub profiles”.

Crear sub-profiles

Aquí más que crear yo lo veo como editar los sub perfiles, es decir, no podemos agregar un nuevo sub perfil sino editar las políticas que pertenecen al mismo, tenemos los siguientes sub-profiles:

  • Memory reservation – Aquí configuramos la cantidad de memoria que necesitamos asignar al Service console (solo aplica para ESX).

  • Storage – aquí configuramos nuestros datastores de NFS, ojo aquí no podemos configurar ningún parámetro de ISCSI ni políticas de multipathing.

  • Networking – en este subprofile tenemos la capacidad de editar que nics se estarán utilizando en cada vSwitch, duplex de las nics, portgroups, incluso configuración de Switches distribuidos.

  • Date and Time – Aquí podemos configurar el servidor de tiempo (NTP) y zona horaria que necesitemos.

  • Firewall – aquí configuramos las políticas de firewall, en este caso solo aplica para ESX.

  • Security – En este sub profile tenemos la capacidad de asignar los permisos de usuario.

  • Service – en este sub profile podemos configurar que servicios estarán iniciados como ssh, ntp, vpxa (vcenter), etc.

  • Advanced configuration option – en este sub profile podemos definir opciones avanzadas que seran aplicadas en los hosts a los cuales se les aplique el profile en cuestión.

  • User configuration – aquí definimos los usuarios que necesitamos tener en nuestros hosts.

  • User group configuration – aquí podemos definir grupos de usuarios.

  • Authentication Configuration – aquí definimos el dominio al que se deberán unir nuestros hosts y las credenciales para poderlo realizar.

Utilizar host profiles para configurar vDS

Honestamente esta de mas repetir algo que ya está bien documentado por VMware incluso con imágenes. Les sugiero echar un ojo a este documento a partir de la pagina 24 se describe perfectamente el procedimiento

http://vmware.com/files/pdf/vsphere-vnetwork-ds-migration-configuration-wp.pdf

 

Logs de Host profiles

todas las operaciones que realizamos las podemos encontrar en un log en la siguiente ruta:

C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs
Estos logs se llaman PyVmomiServer.log.#

 

Paso-a-paso – Dropbox & vSphere vMA

Que tal gente, hace un tiempo que no podía postear debido a que me encontraba fuera del país dictando un curso y que también estuve bastante ocupado estas ultimas semanas… pero estoy de vuelta , y esta vez les voy a dar el paso a paso de como integrar Dropbox a su vMA. Generalmente para los ambientes de VMware que administro utilizo la vSphere Management Assistant (vMA) para facilitarme tareas entre todos los hosts. Muchas veces me encuentro con el problema que solo tengo acceso a traves del vsphere client a la infraestructura remotamente por lo cual es un verdadero problema estar subiendo archivos.

Vamos a revisar los pasos para poder instalar Dropbox en nuestra vMA:

Paso 1-. Instalamos Dropbox en nuestra vMA

descargamos el source para 64 bits

wget -O dropbox.tar.gz "http://www.dropbox.com/download/?plat=lnx.x86_64"

extraemos el tar

tar -xvzf dropbox.tar.gz

y ejecutamos el daemon de dropbox

~/.dropbox-dist/dropboxd

Paso 2-. Una vez ejecutado el daemon de dropbox se nos mostrará un mensaje como el siguiente donde se nos da un link para registrar este cliente con una cuenta de dropbox ya creada:

Una vez registrado el cliente tenemos la capacidad de poder sicronizar carpetas locales con dicho cliente, aquí tengo un ejemplo de windows y mi cliente (vMA):

OPCIONAL

Si nosotros queremos que dropbox se ejecute cada vez que nuestra vMA se inicia, debemos seguir los siguientes pasos:

copiamos el contenido del script de initd que podemos encontrar en este link  FedoraStartup vamos a nuestra vMA y editamos un archivo llamado dropbox en la ruta /etc/init.d con vi y copiamos el contenido:

Editamos el archivo /etc/sysconfig/dropbox para agregar el usuario o usuarios que necesitamos que ejecuten dropbox:

Damos permisos a los archivos:

chmod 0755 /etc/init.d/dropbox
chmod 0644 /etc/sysconfig/dropbox
ls -l /etc/init.d/dropbox /etc/sysconfig/dropbox

Activamos el servicio de dropbox para los runlevels 3 y 5:

chkconfig dropbox on

Verificamos que efectivamente esta activado en dichos run levels:

chkconfig --list | egrep '3:on|5:on' | less