ESXi

Instalar archivo VIB en ESXi

ESXi dispone de unos archivos de instalación especiales para cuando queremos agregar software o extensiones de terceros, por ejemplo.

¿Que es un archivo VIB?

VIB son las siglas de vSphere Installation Bundle. Se trata de un archivo con extensión VIB (a veces se entrega comprimido en un ZIP) que contiene:

  • Descriptor XML, con información referente a lo que vamos a instalar.
  • El driver o extensión propiamente
  • Una firma que sirve para validar el archivo.

Aunque podemos instalar un archivo VIB desde Update Manager, aqui vamos a ver como instalar un archivo VIB desde linea de comandos usando esxcli

Subimos el archivo vib al host en que queramos instalarlo

  • Si es la primera instalación del vib, utilizaremos el comando:
    • Si tenemos un VIB – esxcli software vib install -v “/tmp/NombreArchivo.vib”
    • Si tenemos un ZIP – esxcli software vib install -d “/tmp/NombreArchivo.zip”
  • Si vamos a actualizar un vib, utilizaremos el comando:
    • Si tenemos un VIB – esxcli software vib update -v “/tmp/NombreArchivo.vib”
    • Si tenemos un ZIP – esxcli software vib update -d “/tmp/NombreArchivo.zip”

En todos los casos las comillas son importantes.

Una vez se haya instalado el archivo vib, presta atención al mensaje del resultado ya que nos indicará si el host requiere un reboot para aplicar los cambios. Haz caso de lo que te dice 🙂

Si tenemos un host esxi con acceso a internet y queremos instalar los archivos VIB directamente desde la URL de descarga, puedes pasarlos como parámetro al -d

 

 

Error al agregar un Datastore NFS

Cuando nuestro entorno va creciendo podemos encontrarnos con un error al agregar un datastore NFS. El error en concreto es similar al que puedes ver en las capturas inferiores, donde podemos ver el error

NFS Mount failed: NFS has reached the maximum number of supported volumes. An unknown error has ocurred.

Error al agregar un Datastore NFS

Error al agregar un Datastore NFS.

Para resolver este error al agregar un datastore NFS, debemos saber que ESXi tiene unos valores de configuración que no siempre se corresponden con los máximos que soporta el entorno vSphere. Para el caso de este error, los hosts vienen preconfigurados para un máximo de 8 datastores NFS, aunque son capaces de soportar 256 datastores NFS por host ESXi 5.5

Ahora sí, vamos con la solución.

Resolver error NFS has reached the maximum number of supported volumes desde cliente vSphere Windows

Veremos la primera solución usando el cliente vSphere de Windows, válida para gente que use ESXi con o sin vCenter.

En el cliente vSphere de Windows, iremos al Host > Configuration > Software > Advanced Settings

Error al agregar un Datastore NFS

Dentro del árbol de configuración avanzada, vamos a NFS y buscamos la configuración de NFS.MaxVolumes. Por defecto está a 8. Increméntalo al valor que necesites. A continuación te pongo los valores máximos de volúmenes NFS que soporta cada versión de ESX-ESXi.

Valores para NFS.MaxVolumes

  • ESX3.x – 32 volúmenes NFS máximo.
  • ESX/ESXi 4.x – 64 volúmenes NFS máximo.
  • ESXi 5.0-5.5 – 256 volúmenes NFS máximo.

NFS has reached the maximum number of supported volumes

A continuación, sin cerrar las Advanced Settings, nos movemos a Net, justo encima de NFS, y configuramos los valores Net.TcpipHeapSizeNet.TcpipHeapMax. Configura los valores dependiendo de tu versión de ESXi:

Valores para Net.TcpipHeapSize

  • ESX 3.x – 30
  • ESX/ESXi 4.x – 32
  • ESXi 5.0-5.5 – 32

Valores para Net.TcpipHeapMax

  • ESX 3.x – 120
  • ESX/ESXi 4.x – 128
  • ESXi 5.0-5.1 – 128
  • ESXi 5.5 – 512

NFS has reached the maximum number of supported volumes

Tras aplicar estos 3 cambios de configuración es necesario reiniciar el host. Una vez lo hayamos reiniciado, podremos agregar los datastores NFS necesarios sin volver a ver el error NFS has reached the maximum number of supported volumes.

Resolver error con datastore NFS has reached the maximum number of supported volumes desde vSphere Web Client

Si utilizas vCenter para manejar tu entorno y no dispones del cliente vSphere para Windows, sigue estos pasos para resolver el error al agregar un Datastore NFS

Selecciona el Host y ve a Manage > Settings, Advanced System Settings. Utiliza el buscador para localizar la configuración avanzada NFS.MaxVolumes y cambia el valor a otro superior. Recuerda configurar un valor igual o inferior al máximo soportado por tu versión ESX/ESXi

Valores para NFS.MaxVolumes

  • ESX3.x – 32 volúmenes NFS máximo.
  • ESX/ESXi 4.x – 64 volúmenes NFS máximo.
  • ESXi 5.0-5.5 – 256 volúmenes NFS máximo.

NFS has reached the maximum number of supported volumes

A continuación, sin abandonar Advanced System Settings, vuelve a utilizar el buscador e introduce la palabra Heap. Edita los dos valores Net.TcpipHeapMax y Net.TcpipHeapSize

Valores para Net.TcpipHeapSize

  • ESX 3.x – 30
  • ESX/ESXi 4.x – 32
  • ESXi 5.0-5.5 – 32

Valores para Net.TcpipHeapMax

  • ESX 3.x – 120
  • ESX/ESXi 4.x – 128
  • ESXi 5.0-5.1 – 128
  • ESXi 5.5 – 512

NFS has reached the maximum number of supported volumes

Tras aplicar estos cambios recuerda que debes reiniciar el host para que se hagan efectivos. Una vez se haya reiniciado ya no volverás a ver el error NFS has reached the maximum number of supported volumes y podrás continuar expandiendo horizontes en tu almacenamiento 🙂

 

VMware tools para ESXi anidado

Ultimamente he reconstruido mi laboratorio vSphere y he vuelto a usar el método de ESXi anidado (nested ESXi). Es muy interesante disponer de VMware tools en nuestros hosts esxi virtualizados para poder hacer operaciones sencillas como apagar de forma ordenada los ESXi o poder ver las ips que tiene configuradas cada equipo, entre otras cosas.

Existe una versión de las VMware tools para ESXi que os dejo aquí

http://download3.vmware.com/software/vmw-tools/esxi_tools_for_guests/esx-tools-for-esxi-9.7.1-0.0.00000.i386.vib

Para instalarla seguiremos el siguiente procedimiento:

  1. Subimos por SCP el archivo a nuestro host ESXi al directorio /tmp/
  2. Entramos por ssh al host en cuestión
  3. Instalamos el .vib con el comando
    esxcli software vib install -f -v /tmp/esx-tools-for-esxi-9.7.1-0.0.00000.i386.vib

Si todo ha ido correctamente, podremos ver un mensaje como el siguiente:

Ahora, necesitamos reiniciar el host ESXi para que entren en funcionamiento las VMware tools para ESXi virtualizado. Aprovechando que estamos dentro de la shell, podemos hacerlo rápido con estos comandos

 Una vez haya reiniciado, tendrás que sacar el host del modo mantenimiento

Recuerda que estas instrucciones solo son válidas si estas virtualizando dentro de una máquina virtual un hipervisor ESXi. Eso se conoce como nested esxi o esxi anidado. Si no sabes lo que es esto, seguramente tu host ESXi no necesita ninguna clase de VMware tools.

Rendimiento de disco e IOPS en VMware

¿Qué son IOPS?

Las IOPS son el número de operaciones de entrada y salida que puede efectuar un dispositivo de almacenamiento (Input/output Operations Per Second). En los tiempos en que el almacenamiento no se compartía, se solía medir el rendimiento de los discos en base a 3 factores (que aún son importantes y vigentes):

  • Capacidad (medida en MB, GB, TB)
  • Tiempo de acceso (medido en ms)
  • Tasa de transferencia (medido en MB/s)

En entornos de almacenamiento compartido con mucha concurrencia de operaciones, podemos ver como las operaciones de disco suelen ser muchas, y de pequeño tamaño. Esto en la práctica, hace que los discos de una cabina de discos se pasen la mayor tiempo de un lado a otro realizando pequeñas operaciones continuamente.

Es este patrón pseudo aleatorio y de alta concurrencia el que obliga a tener muy presente las limitaciones y capacidades de un disco duro en las peores condiciones posibles. Estas peores condiciones posibles son:

  • Aleatoriedad (los datos se encuentran repartidos en puntos distantes del disco, en vez de secuencialmente).
  • Datos fríos (que no están en caché)

Medir los datos en las peores condiciones posibles

Alguien se preguntará por qué nos interesa medir la capacidad real de nuestro almacenamiento en las peores condiciones posibles. La respuesta, basada en la experiencia, es porque se darán esas peores condiciones en el peor momento.

Cuando uno se encuentra con una contención en el almacenamiento puede llevarse la desagradable sorpresa de que sus patrones de uso de disco no son optimizables y simplemente está ahogando su almacenamiento y provocando degradación de servicio. Quien haya comprado almacenamiento de gama empresarial sabe que suele tardar unas semanas en llegar desde que se hace el pedido, y hasta que se hace el pedido, pueden ser necesarias un par de semanas de RFP, RFQ, PO. Te aseguro que quieres saber cuales son tus limites para adelantarte a todas esas semanas de degradación de servicio.

También puedes enfrentarte a la creación de presupuestos de cara al año que viene y poder prever que vas a necesitar ampliar, ya que creces un 5% en necesidades de IOPS cada mes y actualmente en Octubre estás al 50%.

Medir IOPS en VMware

Tenemos varias formas de medir IOPS en VMware.

Medir IOPS en VMware usando Performance Graphs

En estos gráficos podemos observar un histórico de operaciones de lectura y escritura de nuestra máquina virtual o Datastore.

 

Si queremos medir las IOPS de una datastore, lo seleccionaremos, iremos a Monitor > Performance, View Performance, Time Range Realtime

iops en vmware

En esta gráfica podremos ver dibujadas las IOPS que generan las 10 máquinas virtuales con mayor actividad de disco del datastore, Existe una gráfica para las lecturas y otra para las escrituras.

En este datastore podemos comprobar como tenemos un

Si queremos medir las IOPS de una máquina virtual, la seleccionaremos, iremos a Monitor > Performance > Advanced, Chart Options y seleccionamos Average READ requests per second y Average WRITE requests per second

iops en vmware

En esta máquina virtual podemos ver un patrón de escritura casi constante

iops en vmware

El problema de utilizar el cliente, ya sea web o de Windows, para medir el rendimiento del almacenamiento, es que no se guarda durante más que 2 horas, el periodo de “Realtime”. Si queremos almacenar todos los datos de acceso a disco para visualizarlos posteriormente con los clientes viclient, debemos activar el modo de recolección de estadísticas de vCenter Stats Level 4. Eso es capaz de tumbar un vCenter con cierta facilidad y solo se recomienda para realizar debug durante periodos cortos de tiempo. QUEDAS AVISADO. Stats level 4 genera MUCHOS DATOS.

Medir IOPS en VMware por línea de comandos

Existen dos formas adicionales de medir las IOPS que generan las máquinas virtuales al datastore utilizando la línea de comandos accediendo por SSH al host donde se están ejecutando estas máquinas virtuales

esxtop

Mediante el uso del comando esxtop podemos obtener los datos en tiempo real de IOPS por máquina virtual. Para ello, accederemos al host que nos interesa monitorizar usando ssh y escribiremos:

 

Posteriormente, pulsaremos la “v” que nos llevará a las estadísticas de uso del disco virtual de las máquinas que se ejecutan en el host y podremos ver una lista similar a la siguiente:

iops en vmware

Esta es la explicación para cada columna:

  • GID – Group ID
  • VMNAME – Nombre de la máquina virtual en el inventario.
  • NVDISK – Número de discos duros virtuales que tiene conectados la máquina virtual.
  • CMDS/s – Número de comandos por segundo que está enviando a disco la máquina virtual. Es igual a la suma de lecturas y escrituras por segundo.
  • READS/s – Número de lecturas por segundo que envía la máquina virtual a sus discos duros virtuales.
  • WRITES/s – Número de escrituras por segundo que envía la máquina virtual a sus discos duros virtuales.
  • MBREAD/s – Megabytes/segundo que lee la máquina virtual de sus discos duros virtuales
  • MBWRTN/s – Megabytes/segundo que escribe la máquina virtual a sus discos duros virtuales.
  • LAT/rd – Latencia en milisegundos que tiene la máquina virtual en sus lecturas a los discos duros virtuales.
  • LAT/wr – Latencia en milisegundos que tiene la máquina virtual en sus escrituras a los discos duros virtuales.

Podemos exportar los datos de rendimiento de ESXTOP a CSV para analizarlos posteriormente mediante la siguiente línea de comandos

 

Los parámetros son los siguientes:

  • -b para ejecutar esxtop en modo batch
  • -a para guardar todos los parámetros posibles y poder analizarlos luego o realizar correlaciones si encontramos anomalías
  • -d tiempo entre cada toma de muestras. El mínimo es 2 segundos
  • -n número de ejecuciones de ESXTOP. Si seleccionamos 1800, estaremos tomando muestras de 1 hora, ya que se ejecuta cada 2 segundos

Finalmente, pasamos con un pipe los datos a GZIP para que los comprima y redirigimos la salida a un archivo. Posteriormente tendremos que sacar los datos del host usando scp, por ejemplo. Recuerda la ruta en la que ejecutas el comando para luego descargarte el CSV comprimido.

Para tratar estos datos puedes utilizar herramientas como

Monitorizar otros aspectos del rendimiento de disco en VMware

Monitorizar las IOPS en VMware usando vscsiStats

Una herramienta de línea de comandos muy potente que podemos utilizar para medir IOPS en VMware es vscsiStats. Esta herramienta permite analizar con detalle la carga de I/O de una máquina virtual que se ejecuta en un host concreto.  vscsiStats permite monitorizar los siguientes aspectos de una máquina virtual:

  • ioLength (el tamaño de las peticiones que realiza a disco la máquina virtual)
  • seekDistance (la distancia entre operaciones en el disco duro virtual, nos permite conocer la secuencialidad o aleatoriedad de las operaciones en disco)
  • outstandingIOs (se denominan outstanding IO aquellas operaciones que una máquina virtual envía al almacenamiento y que aún no se han realizado, se encuentran pendientes de ser ejecutadas en una cola)
  • latency (se denomina latencia al tiempo que tarda un dispositivo de almacenamiento en realizar una operación de disco. Se expresa en milisegundos)
  • interarrival (nos muestra el tiempo que pasa entre las peticiones de IO al disco, expresado en microsegundos. Puede servirnos para determinar si la máquina escribe/lee esporádicamente o de forma continuada)

Así pues, nuestra primera tarea será localizar la máquina virtual en concreto que queremos analizar y su host. Posteriormente nos conectaremos por SSH a dicho host y ejecutaremos

 

De esta forma podremos obtener el listado de máquinas virtuales que se ejecutan en este host.

iops en vmware

Para este ejemplo voy a elegir una máquina virtual particular que no sale en la captura de pantalla pero que sé que tiene actividad de disco y no está parada sin hacer I/O. Su worldGroupID es 14310484 y el handleID de su disco duro es 9087

Lo primero de todo, hemos de activar la recoleccion de estadísticas para esta máquina virtual. Para ello, se lo indicaremos a vscsiStats con el siguiente comando:

 

Ahora podremos comenzar a ver las estadísticas de IO de esta máquina virtual:

Medir la Latencia de disco

Obtendremos la latencia de disco usando el comando

 

latencia en vmware

En este caso podemos ver que en el corto intervalo de tiempo que lo he dejado recolectando estadísticas (unos pocos minutos), tenemos unos tiempos de respuesta de disco entre 0.5 y 5 milisegundos, siendo la media de 0,9 milisegundos.

Tamaño de I/O de la máquina virtual

Para analizar el comportamiento de nuestra máquina virtual en cuanto a tamaño de IO se refiere, usaremos el comando

 

tamaño de io en vmware

Aquí podemos ver que esta máquina virtual realiza operaciones principalmente con dos tamaños de IO, 4KB y 16KB. Esto puede ser nos útil para realizar planificaciones de tamaños de cluster/inodos y alinearlo con el almacenamiento en el que se soporta esta máquina virtual.

Comandos de disco encolados

Podemos medir los comandos que hay pendientes de ejecución en el almacenamiento utilizando la opción oustandingIOs

vmware outstandingIOs

En este caso podemos ver como la mayoría de comandos no se encolan y reciben el ack de forma inmediata. Sin embargo podemos ver como se llegan a acumular hasta 16 peticiones de IO pendientes de respuesta.

Distancia de busqueda en disco

Podremos ver la distancia entre los bloques accedidos en disco mediante el comando

uso de disco en vmware

La columna de la derecha indica el número de bloques lógicos que se ha tenido que desplazar la “cabeza del disco virtual” para efectuar las operaciones de IO de disco. Podemos ver que la cuarta parte de las veces ha sido 1, por lo que se trataba de una operación secuencial, aunque también hay presencia de 4503 y 3171 operaciones que han hecho saltar el disco hasta 33820641 bloques lógicos de distancia.

Esta máquina virtual que he elegido en concreto, es una “escritora”. Podemos verlo porque al venir desglosadas las estadísticas en Total / Lecturas / Escrituras, veremos que no lee prácticamente nunca.

almacenamiento vmware

Tiempo entre comandos

Podemos medir si una máquina virtual tiene patrones de IO en ráfagas o por el contrario más espaciados, utilizando la métrica del interarrival, que mide el tiempo que pasa entre la llegada de los comandos de I/O

caracterizar io vmware

Aqui podemos ver que la mayoría de comandos (como hemos visto antes, escrituras) que realiza esta máquina, son con un intervalo entre peticiones inferior a 0,1ms. Esto viene a ser escritura secuencial. Sin embargo, no se trata de una escritura contínua, ya que también tiene numerosos lapsos de tiempo superiores a 100 milisegundos en los que no realiza ninguna petición. Esta máquina escribe logs, en ráfagas según su buffer de escritura a disco sobrepasa un umbral. Por eso vemos que escribe ráfagas secuenciales, espera a que se llene el log de nuevo, vuelve a escribir…

Finalmente, detendremos la recolección de estadísticas para esta máquina virtual con el comando

 

WhiteBox ESXi

En la red podemos encontrar infinidad de artículos que hacen referencia a como montarte tu propia whitebox ESXi, pero hay pocos en español. En los siguientes artículos voy a hacer referencia a mi propia whitebox esxi.

¿Qué es una Whitebox ESXi?

En la comunidad virtual, se denomina whitebox esxi a un ordenador montado con componentes compatibles con ESXi pero que no son un sistema propiamente validado y presente en la HCL de VMware (Hardware compatibility list). El motivo de montar estos sistemas, principalmente, es crear un laboratorio de pruebas para practicar, aprender, o incluso el ahorro de dinero utilizando componentes menos caros o con un nivel de soporte inferior a servidores que pueden vender HP o Dell, por ejemplo.

En mi caso, he estado un tiempo utilizando mi propio equipo de sobremesa (Intel i7-4770S con 16GB de RAM y un pendrive USB) hasta que la cantidad de memoria ram ha sido insuficiente para todas las cosas que quería probar. Así pues, en Octubre de 2014 he decidido renovar la Whitebox ESXi y comprar nuevo hardware dedicado para ella.

Los componentes elegidos no son los más baratos. Ya he tenido anteriormente whitebox con componentes de escritorio y no quería verme limitado a los 32GB de RAM que ofrecen la mayoría de placas base de sobremesa. Además, quería gestion remota usando IPMI para poder colocar el equipo en un sitio apartado de la casa donde no moleste (en el salón).

Mi primera opción fue una placa base con Intel Avoton C2750. Tienen 8 cores, un bajísimo consumo y soportan hasta 64GB de RAM ECC. El problema es que el rendimiento es bajísimo y conseguir la placa es bastante complicado.

Finalmente he optado por los siguientes componentes:

Placa Supermicro X10SRi-F270€

  • Tamaño ATX. No quiero cajas gigantes por casa. Ya tengo una.
  • 2 puertos LAN gigabit Intel i350, con soporte directo de ESXi
  • 10 puertos SATA3. Les conectaré un par de SSD que tengo por casa y 3 discos SATA.
  • 2 puertos USB 3.0 traseros, por si me interesa algún día hacer algo con passthrough
  • Puerto USB 3.0 interno en el que se puede conectar un pendrive para arrancar el ESXi
  • 8 slots de memoria. Es el principal motivo por el que me decantado por la plataforma Xeon / LGA2011.
  • LAN dedicada para IPMI de Supermicro, una garantía de buen funcionamiento para manejarlo remotamente con Linux, como es mi caso. También sirve para encender, apagar y arrancar isos en remoto en el equipo.

Procesador Intel Xeon E5-2620 v3400€

  • 6 cores, 12 hilos con Hyperthreading.
  • Consumo moderado-bajo, 85W de TDP máximo.
  • Soporta VT-x, VT-d y AES-NI
  • IMPORTANTE: Si vas a comprar una placa, revisa bien el tipo de anclaje para disipador que lleva. Puedes ver como los agujeros para los tornillos de mi socket son rectangulares. Se denomina LGA2011 Narrow ILM. Hay otra variante denominada LGA2011 Square ILM. No todos los disipadores valen para todos los sockets 2011. Lo que si puedo decirte es que los disipadores Narrow ILM 2011 es compatible con placas Narrow ILM 2011 para Xeon v3, al igual que los Square ILM 2011 son compatibles con placas Square ILM 2011 para Xeon v3.

whitebox ESXi

4x 16GB Samsung DDR4 1.2v – 800€
No quería dejar el equipo sin opciones de ampliación de memoria. Así que he ido a por estos módulos de 16GB. Son lo que más disparado de precio me ha parecido, pero llevaba muchos meses queriendo comprar el equipo y no quería retrasarlo más.

whitebox ESXi

 

Fuente de alimentacion Cooler Master V550s60€
En las reviews que he visto, es la que mejor estabilidad de señal da, es muy eficiente (80 plus gold) y está dentro de lo que tenia pensado gastarme en la fuente de alimentación. Es semi modular por lo que puedo librarme de parte de los cables que no utilizo.

whitebox ESXi

 

Disipador Noctua NH-U12DX i460€
Es el tercer disipador Noctua que compro y estoy muy contento con el. Es silencioso y de los pocos compatibles con el anclaje LGA 2011 Narrow ILM.

Whitebox ESXi

Caja Bitfenix Comrade 35€

Es una caja de tamaño pequeño, media torre. Blanca, imprescindible para mis whiteboxes 🙂 El precio es muy contenido, 34€. Viene con un ventilador bastante ruidoso que pienso sustituir en un futuro no muy lejano. Además he tenido que tapar con plástico no conductor un par de apoyos que vienen para placas ATX, ya que no coincidian con la placa supermicro y no quiero cortocircuitos que puedan romper la placa base. Aqui dejo una foto de como lo he solventado.

whitebox ESXi

 

Switch TP Link – TL-SG108E – 32€

Se trata de un switch de 8 puertos gigabit, de bajo consumo. Tiene el cuerpo de metal, bastante sólido, no tiene ventilador y dispone de una serie de funciones propias de switches administrados.

VLANes en los puertos, LACP (trunking) entre puertos, limitación de ancho de banda… Todo se hace mediante una aplicación de Windows que puedo confirmar que funciona con WINE (para los usuarios de linux).

TL-SG108E(UN)1.0-A

Además, este equipo utilizará como almacenamiento un NAS QNAP TS-853 Pro, con 4 discos WD Red de 4TB y 1 SSD de 60GB para cache. También está en juego un UPS Cyberpower de 800VA.

El coste total del equipo es de 1667€. Como decía anteriormente, no está en el segmento económico de las white boxes. Sin embargo, creo que he encontrado un equipo bastante potente que me va a dar bastante jugo para probar cosas y preparar recertificaciones.

¿Cuanto consume una whitebox?

Tengo un medidor de consumo eléctrico en la toma de corriente en la que se enchufan los siguientes dispositivos:

  • TV Samsung 46″ (standby al medir)
  • Barra de sonido Samsung con SW activo (standby al medir).
  • Playstation 3 (standby al medir).
  • WhiteBox.
  • NAS QNAP TS-853.
  • Switch 8 puertos.

El consumo medido es de 95-105W con una VM funcionando en el QNAP y otra en la Whitebox. Me consta que el QNAP consume en torno a 30-40W el solito. Tomando como precio por kWh 0.15 centimos, tenerlo todo funcionando cuesta 10 euros al mes. Por supuesto no estará siempre funcionando, pero incluso en ese caso extremo, no es una barbaridad de dinero.

 

 

 

Eliminar alerta de SSH en VMware ESXi

En muchas ocasiones puede resultar interesante acceder a ESXi utilizando SSH. Sin embargo, la configuración por defecto hará que los hosts con SSH o ESXi Shell habilitado muestren un Warning diciendo:

Imagen de la alerta por ssh en ESXi utilizando el cliente tradicional

ssh for this host has been enabled

Imagen de la alerta por ssh en ESXi utilizando el cliente web

warning vmware esxi ssh

Podemos deshabilitar la alerta de ssh activo en ESXi de tres maneras:

Deshabilitar la alerta de ssh en ESXi usando el cliente tradicional de Windows

Para realizar esta operación, seleccionaremos el host que tiene la alarma e iremos a la pestaña configuration

Una vez allí, iremos a Advanced System Settings y buscamos el apartado UserVars.

Al final del todo, cambiaremos el valor de la propiedad UserVars.SuppressShellWarning a 1 y pulsaremos OK.

warning vmware ssh

El cambio se hace efectivo inmediatamente y no requiere reinicio. El warning de SSH debería desaparecer del host ESXi a los pocos segundos.

Deshabilitar la alerta de ssh en ESXi usando el vSphere Web Client

Para deshabilitar la alerta de ssh en ESXi utilizando el cliente web de vSphere, seleccionaremos el host que presenta el warning e iremos a Manage > Settings

Una vez allí, en el apartado System, haremos click en Advanced System Settings y buscaremos UserVars.SuppressShellWarning. Pulsamos el botón de editar (el icono del lápiz) y pondremos el valor a 1.

warning esxi ssh

El cambio se aplica sobre la marcha y el warning de ssh debería desaparecer del host ESXi.

Deshabilitar la alerta de ssh en ESXi usando línea de comandos  (vim-cmd)

Para deshabilitar el warning de SSH activo en ESXi utilizando la línea de comandos, entraremos como root por ssh en el equipo (o usando ESXi shell) y ejecutaremos el siguiente comando

 

Podrás verificar que el comando se ha ejecutado correctamente si pasados unos segundos el warning de ssh desaparece de tu host ESXi.

Coredumps por red en ESXi

Si tenemos instalado ESXi en USB o SDCard, no se habrá creado una partición dedicada a almacenar los coredumps que pueden generarse cuando falla el sistema y verás un error similar a este en tus hosts
coredumps por red

En este caso es necesario configurar de forma manual un destino de estos volcados de información, que pueden contener datos vitales para el diagnóstico de un problema. En caso de abrir un ticket de soporte a VMware, nos solicitarán que les proporcionemos estos dumps si disponemos de ellos.

Para este procedimiento nos conectaremos por ssh al host y antes de nada, verificaremos que efectivamente el envio de coredumps por red está desactivado.

Bien, vamos a configurar la ip del colector de coredumps por red, que normalmente está en el mismo servidor que el vCenter. Si usas vCSA, dispones de un colector de coredumps incorporado también. El puerto por defecto es el 6500. Si dudas o encuentras que no es ese, durante la instalación, te lo pide.

Ahora habilitamos el envío con los datos que hemos configurado anteriormente.

Finalmente lanzamos una conexión al colector para validar que hay conectividad.

Si ahora ejecutamos el check, veremos que ya nos muestra “true” y la información del Dump Collector de destino, al que enviaremos nuestros coredumps por red.

Bloquear el acceso a vCenter con el cliente de Windows

La mejor forma de obligarse uno mismo a utilizar el cliente web, es bloquear el acceso a vCenter con el cliente de Windows tradicional. Para ello, deberemos editar un simple archivo en el servidor vCenter.

Bloquear el acceso a vCenter con el cliente de Windows si usas vCenter de Windows

Para bloquear el acceso a vCenter con el cliente de Windows deberemos editar el archivo

En el parámetro exactVersion, ponemos un valor que no coincida con ninguna versión de vCenter, por ejemplo 15.5.0

cliente tradicional vsphere
No hay que hacer más que guardar el archivo. Ni reiniciar vCenter ni nada. La siguiente vez que alguien intente conectar usando el cliente windows de vSphere, entrará en un bucle de actualización de cliente, ya que nunca conseguirá llegar a la versión inexistente que hemos especificado.
bloquear cliente tradicional vsphere
Avisad de estos cambios a los usuarios, pues cada descarga del cliente son bastantes megas de tráfico.

Bloquear el acceso a vCenter con el cliente de Windows si usas vCenter Server Appliance (VCSA)

Para bloquear el acceso a vCenter con el cliente de Windows deberemos editar el archivo

En el parámetro exactVersion, ponemos un valor que no coincida con ninguna versión de vCenter, por ejemplo 15.5.0

Con este cambio causaremos el mismo bucle de actualizaciones en el cliente de windows y jamás podrán conectarse.

Bloquear el acceso al host ESXi con el cliente de Windows si no tienes vCenter

Para bloquear el acceso a un host ESXi con el cliente de Windows, deberemos editar el archivo

Hay que cambiar el valor de exactVersion, igual que en los otros escenarios.

Al no disponer de vCenter, en este escenario tendrás que utilizar vcli, powercli, esxcli, etc.

Plantilla Debian 7 Wheezy en VMware ESXi 5.5

Personalizar las máquinas virtuales que usas como plantilla para tu entorno virtualizado es muy importante. Cada error que cometas en ellas, se verá multiplicado a posteriori con cada máquina virtual que despliegues a partir de la inicial. Esta es una lista de consejos que puedo dar para mejorar el rendimiento de tus máquinas virtuales y optimizar los recursos en VMware.

Bueno, esta es la forma en que yo personalizo mis plantillas de Debian 7 Wheezy en VMware:

Creación del template Debian 7 Wheezy en VMware ESXi

Especificaciones de hardware virtual para VM Debian 7

  • El template de VM que utilizo es 1GB RAM, 1vCPU y 10GB de disco duro.
  • Siempre activo la opción de añadir CPU y memoria en caliente (CPU/RAM Hot Add).
  • Para la red uso VMXNET3.
  • Como controladora de discos históricamente he usado LSI, pero últimamente estoy utilizando ya Paravirtual. Está soportada por kernels superiores a 2.6.33, justo el siguiente a Squeeze.
  • Elimino el Floppy tanto en la descripción de la máquina virtual como en la BIOS.

Instalacion de Debian 7 en VMware

Siempre utilizo la última iso de tipo netinst disponible en http://cdimage.debian.org/debian-cd/7.5.0/amd64/iso-cd/

Para la instalación creo un volumen LVM único en el que sitúo la partición root formateada con ext4. No creo particiones para swap ni nada. La explicación es sencilla, es más sencillo utilizar un archivo como swap y te da mayor flexibilidad a la hora de redimensionarlo. Además, en un entorno virtualizado con almacenamiento compartido, lo último que deseas es que tus máquinas virtuales swapeen.

LVM permite redimensionar el volumen en caliente, y mediante resize2fs podemos redimensionar el filesystem en caliente también.

Post Instalación de Debian 7 Wheezy en VMware

Crearemos un archivo de swap y le damos formato

Modificaremos el /etc/fstab para añadir el nuevo espacio de swap, así como ajustar algunos parámetros del filesystem que permitirán optimizar el rendimiento de disco de la máquina virtual linux.

Las opciones noatime y nodiratime evitan una escritura a disco cada vez que se accede a un fichero o directorio. Esto pueden ser bastantes escrituras que nos ahorramos. Desde el punto de vista de la seguridad puede ser un problema desconocer la fecha del último acceso a un directorio o fichero, consulta con tu equipo de seguridad si lo tienes.

Evitar errores LC_ALL

En algunas debian 7 recién instaladas me encuentro muchas veces con el siguiente error

Para solucionar esto, podemos añadir la siguiente línea a /etc/environment

Configurar el swappiness en Linux

El uso de memoria en los sistemas operativos modernos tiene dos características que pasan desapercibidas a mucha gente.
1. Intentan utilizar toda la memoria de que disponen como buffers y cache de disco
2. Intentan aparcar las páginas de memoria ram que no se utilizan en swap.

El punto dos quiere decir que si el kernel de nuestra VM Debian 7 detecta que tiene 300 megas de memoria que nadie utiliza, probablemente prefiera liberar ese trozo de memoria y volcar esas páginas de ram a swap, para recuperarlas de nuevo más adelante en caso de que sean necesarias.
Como siempre, en un almacenamiento compartido, las escrituras a disco son preciosas, y cuando tenemos en un mismo almacenamiento cientos de máquinas virtuales, cada ahorro cuenta.

Vamos a decirle al Kernel: “Prefiero que no copies páginas inactivas a disco para ahorrar IOPS en mi almacenamiento“. Esta tendencia se controla mediante un valor de sysctl llamado vm.swappiness. Por defecto en debian viene con valor 60, que es bastante alto. Yo personalmente lo pongo a 0, prefiero que el sistema swapee sólo cuando es estrictamente necesario. Poner a 0 el swappiness NO IMPLICA DESACTIVAR EL SWAP, tan solo limitas el swapeo a disco a situaciones de falta de memoria.

Para hacer este cambio efectivo de forma permanente, añadiremos la línea al archivo /etc/sysctl.conf

Configurar el IO Scheduler

Linux tiene, como es lógico, sus sistemas de gestion de IO, que priorizan como mejor le conviene el IO a disco. El problema es que los parámetros que toma en cuenta para priorizar ese IO a disco no tienen en cuenta las 300 VMs vecinas que acceden al mismo almacenamiento. Es por esto que considero mejor dejar a ESXi que se encargue él de priorizar el IO a disco, ya que tiene visibilidad del todo el conjunto. Por si tienes curiosidad, los schedulers de disco en Linux son NOOP, CFQ (Completely Fair Queueing), Anticipatory y Deadline, siendo por defecto en versiones modernas de Linux el scheduler CFQ. En nuestro caso, para desactivar esta priorización del IO, configuraremos el noop de la siguiente forma: [El ejemplo usa sda como dispositivo de disco]

Para hacer estos cambios efectivos de forma permanentemente, tendremos que configurar la opción elevator=noop en el arranque. La mejor forma es configurarlo en las opciones por defecto de grub, en el archivo /etc/default/grub

Tras hacer el cambio, actualizamos grub

Desactivar man-db y mlocate

Hay dos crones diarios que se ejecutan en cada VM que son man-db y mlocate. Mlocate crea y mantiene actualizada una base de datos de los archivos que hay en cada filesystem. Tampoco me compensa que se ejecute a diario. Para desactivarlo, le ponemos un “exit 0” al principio a los siguientes archivos

Desinstalar mpt-status

Muchas veces me he encontrado el syslog inundado de errores de mpt-status. Se trata de una utilidad que comprueba el estado de los raids hardware de determinadas controladoras. En una máquina virtual no tiene sentido controlar el estado del raid, ya que no tiene visibilidad de las controladoras del almacenamiento. Comprueba si lo tienes, y si es así, quítalo con

Cambiar las reglas de udev para los dispositivos de red
Cuando generamos una maquina virtual nueva, la MAC cambia. Esto puede generar situaciones como que te encuentres eth9 y cosas asi. Para evitar esto, borraremos:

Si quieres que estas reglas que asocian direccion mac de interfaz ethX no se generen jamas, deberás borrar /lib/udev/write_net_rules

Controlar la hora

Controlar la hora es CRITICO en entornos virtualizados. Has de asegurarte de que tienes ntpd instalado y una fuente de hora fiable y alcanzable a través de tus firewalls (o dentro de tu infraestructura si es posible)

Ultimamente hay muchos problemas de configuración de servidores NTPD desatendidos que son utilizados para realizar ataques DDoS aprovechando una mala configuración que permite enviarles queries del tipo monitor. Nosotros vamos a configurar el servidor para que solamente actúe como sincronizador de hora para esta máquina, es decir, cliente ntp.

En mi configuración le indico 3 ips de nuestra red local que contienen servidores NTP. También indico un nombre dns que podemos reconfigurar de forma sencilla por si hubiese que recurrir a otra ip sin necesidad de reconfigurar todos los NTP de la plataforma en un momento dado.

/etc/ntp.conf

Desactivar módulos que no vayas a usar

Para ahorrar recursos en nuestras máquinas virtuales y reducir posibles fuentes de problemas, podemos desactivar una serie de módulos innecesarios en un entorno virtualizado:

En este caso vemos que al desactivarlos ha avisado de que algunos no estaban cargados en memoria. No ocurre nada, es normal.

Instalar VMware tools

Instala siempre VMware tools en tus templates. Mantenlas actualizadas cuando actualices tus hipervisores. Las VMware tools son compatibles hacia atrás, asi que no te va a ocurrir nada malo por mantenerlas al día en tus plantillas y te ahorrará tiempo a posteriori.

Desactivar el driver de sync de las VMware tools

En mi experiencia, este driver puede provocar problemas serios al hacer snapshots en máquinas virtuales con mucho I/O a disco, cuando se recupera de un borrado de snapshot (situación que se da al hacer backup de las máquinas virtuales). Si tus máquinas virtuales no responden durante minutos al borrar un snapshot, prueba esto:

Edita /etc/vmware-tools/tools.conf y añade lo siguiente (Seguramente ese archivo no exista, créalo):

Maximiza el espacio en disco disponible

Por defecto, los filesystems en linux se reservan un 5% del espacio para que, en caso de llenarse, root pueda seguir disponiendo de algo de espacio. Si quieres apurar el espacio al máximo, puedes dejar este porcentaje en 1% o incluso 0%. Para ello puedes ejecutar:

Esto dejará la reserva en un 1% y habrás recuperado automáticamente un 4% de espacio para poder utilizarlo como prefieras.

Opcional: Reparte tus crones

Búscate una forma de repartir los crones, sobre todo los daily. Al principio no notarás nada, pero a la larga tendrás cientos de rotados de log que se ejecuten a la vez y tendrás un serio problema. Nosotros lo hacemos con puppet, haciendo que la hora de ejecución de ciertos crones sea hasta cierto punto pseudo aleatoria.

Opcional: Configurar vfs_cache_pressure

Linux mantiene en memoria una cache para los directorios y objetos del sistema de archivos. Podemos disminuir los accesos a disco si le decimos al kernel que procure mantener esta caché en memoria lo más posible. Se trata de un valor de configuración de sysctl y por defecto tiene un valor 100.

Si lo bajamos a 50, disminuiremos la tendencia a “olvidar” objetos de esta caché, con lo que se reducirán los accesos a disco.
sysctl vfs_cache_pressure=50

Haz tus pruebas y encuentra un valor óptimo para ti. Para probarlo, puedes hacer

time find / -type f

Posteriormente haz alguna operación con archivos grandes que fuerce al kernel a usar toda la ram posible para cachear ese archivo.

Repite el find. Cuando veas que sigue siendo inmediato, es el punto de equilibrio en el que conservas tus inodos en memoria. Nunca llegues a 0, o podrías verte en una situación de Out of Memory si tu sistema de archivos tiene muchos objetos.

Espero que este post te haya servido para mejorar el rendimiento de tu Debian 7 Wheezy en VMware ESXi.

Conectar hosts nuevos a almacenamiento

Conectar hosts nuevos a almacenamiento en VMware

Para conectar hosts nuevos a almacenamiento compartido en VMware, podemos hacerlo de dos formas. Añadir el almacenamiento al host, o añadir hosts al almacenamiento. La segunda forma es mucho mas conveniente cuando queremos añadir ese almacenamiento a varios hosts a la vez.

Ten presente que este método no sustituye la asignación de permisos en el almacenamiento, ya sea iSCSI/FC o NFS.

Para añadir hosts a un almacenamiento ya existente en vSphere, iremos a la pestaña de almacenamiento del menú principal en el vSphere Web Client y haremos click derecho encima, All vCenter Actions > Mount Datastore to Additional Host
Añadir almacenamiento en vmware

Seleccionamos los hosts a los que queremos añadir el almacenamiento (uno o varios) y pulsamos OK.

Añadir almacenamiento en vmware

El almacenamiento se añadirá a los hosts seleccionados.

Problemas al añadir almacenamiento NFS a hosts VMware

Si al añadir almacenamiento recibes el error en la tarea “Create NAS Datastore” en el que puedes leer “The mount request was denied by the NFS Server. Check that the export exists and that the client is permitted to mount it.

Lo más seguro es que necesites proporcionar permisos en el almacenamiento para las IPS del VMkernel destinado a tráfico de almacenamiento en tu nuevo host.