Es posible definir resource pools a nivel de servidor VMware ESX/ESXi o a nivel de clúster VMware DRS. Sin embargo, si a la hora de crear un clúster no seleccionas la opción Enable VMware DRS, la opción de New Resource Pool estará deshabilitada.

Para poder crear un New Resource Pool en un Clúster VMware DRS, asegúrate de habilitar la opción Enable VMware DRS durante la creación de tu clúster VMware o, en su defecto, puedes habilitar dicha opción después de la creación del clúster, seleccionando el clúster con el botón derecho del ratón y seleccionando Edit Settings. Después, haz clic en Enable VMware DRS.

Los resource pools creados a nivel VMware ESX/ESXi pueden ser heredados ( grafted ) e incluidos en un clúster vSphere VMware DRS, cuando incluyes un servidor ESX/ESXi con resource pools ya creados a nivel de host, a un clúster VMware DRS.

Sin embargo, la opción por defecto cuando añades un servidor ESX/ESXi a un cluster DRS es “Put all of this host´s virtual machines in the cluster´s root resource pool. Resource pools currently present on the host will be deleted”.

Para heredar los resources de tu servidor host ESX/ESXi a tu clúster DRS, asegúrate de seleccionar “Create a new resource pool for this host’s virtual machines and resource pools. This preserves the host’s current resource pool hierarchy”.

Los resource pools heredaros serán nombrados Grafted from + nombre del servidor VMware ESX/ESXi. Si posteriormente eliminas el servidor host ESX/ESXi de tu cluster DRS, los resource pools serán “retenidos”.

No obstante, si decides desactivar la opción DRS de tu cluster, perderás todos los resource pools de dicho cluster, previo aviso eso si, y tendrias que re-crearlos de nuevo.

Esto ha sido todo, hasta la próxima semana con un nuevo tip.

Después de 11 años haciendo exámenes de certificación en VMWare y más de 19 años en la industria de IT, hoy puedo confirmar con total rotundidez, que este es el examen más difícil que jamás he hecho.

Es tan difícil que, los 11 años de experiencia con productos VMware, cientos de proyectos de virtualización a mis espaldas – algunos de los proyectos en los que estuve involucrado hasta la “ceja” son dos de las granjas de VMWare mas grandes en EMEA ( Dell y BP ) , y todos los cursos oficiales de VMware Fast Track y VMware ICM que imparto y los ciento de estudiantes que formo mensualmente, no han sido suficientes para superar el examen.

Ciertamente estuve muy cerca, con un scoring de 268 – necesitas mínimo un score de 300 – de aprobar el examen pero el cansancio – mas de 2 horas y media de examen – y el que el día anterior no pude dormir mas que dos horas – el avión que me trajo desde Dublín a Madrid salió con mas de 5 horas de retraso -, hicieron mella en las mas que ya agotadas baterías humanas, aparte de que este examen no lo ha aprobado mucha gente.

Este es el primer examen oficial de VMware que suspendo, ciertamente me alegra saber que ha sido con el VMware Desing Exam VCP310 para conseguir la certificación VCDX.

El examen, en tres palabras: no me gusto. La primera parte, tuve que responder a 51 preguntas – algunas muy largas y con conceptos enrevesados y envenenados – y en otras el enunciado estaba mal – se nota que este examen esta aun en beta!.

En algunas de las preguntas tipo drag & drop, las respuestas podían ser arrastradas en múltiples casillas – según el enunciado – pero cuando arrastrabas un mismo icono dos veces en diferentes casillas no funcionaba, está seguro que la falle – como esperan que uno acierte semejante sinvergonzonería?

Con la segunda parte del examen, la cual es dibujar un diseño – nada del otro mundo -, tuve mas problemas intentando averiguar como funcionaba la GUI que con el diseño propio.

Moraleja, no me extraña que solo 20 personas en el mundo tenga esta certificación y que, según mis últimas informaciones, todos menos uno trabajan para VMWare. Creo que sería necesario saber las mejores prácticas internas de VMware si quieres tener, al menos, una remota posibilidad de aprobar este examen. Yo lo volveré a intentar próximamente……

En un servidor VMware vSphere ESX 4, si así lo estimas necesario, puedes cambiar el tamaño de la memoria destinada al Service Console.

Este cambio necesita un reinicio del servidor vSphere ESX 4 para que los cambios surjan efecto.

El cambio del tamaño de la memoria del Service Console afectara al fichero swap del Service Console. VMware recomienda asignar el doble del tamaño de la configuración de memoria del Servico Console para su partición swap.

El tamaño máximo del Service Console es de 800MB, por consiguiente la partición máxima para el swap del Service Console no pueden ser mayor de 1.600MB.

En este vídeo te enseñare como cambiar la configuración de memoria del Service Console y porque a veces es necesario hacer dicho cambio:

El wizard de la migración en caliente, VMware VMotion, valida los requerimientos del servidor origen y servidor destino así como los requerimientos de la maquina virtual que quieres migrar.

Una máquina virtual no puede ser migrada en caliente cuando:

• La MV tiene una conexión activa a un virtual switch de uso interno.
• La MV tiene una conexión activa a un CD o disquete.
• La MV tiene configurada una afinidad a una CPU.
• La MV forma parte de un clúster Microsoft.

El wizard de migración en caliente, VMware VMotion, produce un warning cuando:

• La MV tiene una conexión a un virtual switch de uso interno pero no está conectado.
• La MV tiene una conexión a un CD o disquete pero no está conectado.
• La MV tiene uno o más snapshots.
• El servidor VMware vSphere ESX/ESXi no ha recibido un guest OS heartbeat (probablemente las VMware tools no han sido instaladas o configuradas adecuadamente).

El wizard de migración en caliente, VMware VMotion, muestra un mensaje de error si la máquina virtual no puede ser migrada desde el servidor origen al servidor destino. Sin embargo, con un mensaje de error de tipo warning, la máquina virtual puede ser migrada con VMotion sin problemas.

Asimismo, los servidores involucrados en la migración, servidor origen y servidor destino, deben cumplir los siguientes requerimientos:

• Visibilidad de todas las LUNs (FC, iSCSI, NAS) usadas por la MV.
• Una red Gigabyte Ethernet dedicada al tráfico VMotion. (En una red 10/100 también funciona pero va muchoooo mas lento. No ostante, VMware solo soporta una red Gigabyte para el trafico VMotion.
• Acceso a la misma red Ethernet física.
• El nombre de los virtual switch debe ser igual en ambos Servidores ESX (incluyendo mayúsculas y minúsculas). En VMware vSphere ESX/ESXi versión 4 update1, si los virtual switches no son nombrados iguales, el wizard de migración en caliente VMotion produce un warning pero la migración puede continuar.
• CPUs compatibles o similares (misma familia CPU). VMotion también funciona, si el servidor origen tiene Hyperthreading activado pero no el servidor destino

Seguro que se me escapan algunos requerimientos de VMotion, con lo que si no ves aquí todos, o crees que falta alguno, por favor déjame tu comentario.

¿Hola que tal de nuevo?. Pido mis disculpas a José María y todos nuestros lectores por el retraso en mis POSTS ya que he tenido un ligero contratiempo a lo largo de este mes que me ha hecho ir más lento con vosotros de lo que yo quisiera.

Una vez explicado esto, quería haceros llegar algo que ya he probado y que me ha sorprendido por su funcionamiento con un programa de almacenamiento SAN como es Openfiler (Código Abierto). Como realizar un Cluster entre SAN con Openfiler para la redundancia de nuestras VMs?.

Mirando en varios Blogs y otros donde ponían como realizarlo (HOW to) os transmito paso a paso como realizarlo. Aunque cabe reseñar antes de empezar, que todo se basa en el protocolo DRDB, el cual es básicamente una replicación continua vía TCP/IP mediante nuestra red Ethernet.

Lo primero es descargar e instalar openfiler en las dos máquinas. Hay una imagen para x86 o para x86_64 según las máquinas de que dispongáis. Durante la instalación, haced las particiones idénticas en los dos servidores, y cuando reiniciéis, os tendréis que asegurar que no se montan las particiones que se van a replicar entre los dos servidores. En mi caso, hice el siguiente particionado:

• /dev/hda1 — /boot – 150MB
• /dev/hda2 — / — 10GB
• /dev/hda3 – swap – 1024MB
• /dev/hda5 – 512MB – Será donde guardemos los ficheros de config para el cluster.
• /dev/hda6 – 12,9 GB – Haremos un share SMB
• /dev/hda7 – 12,9 GB – La usaremos como target iSCSI para VMWare

Para que nos quede un poco mas claro, las particiones que replicaremos serán las de datos y la de configuración del cluster. Las de sistema no será necesario replicarlas ya que el sistema está instalado en ambos nodos. Aseguraos también de que los dos nodos resuelven correctamente el nombre del otro y opcionalmente, montad la autentificación por claves de ssh, para no tener que escribir el password cada vez que hagáis un scp.

DRBD

Montar drbd es bastante sencillo. Lo primero que tenéis que hacer es aseguraros de que las particiones estén vacías, ya que es muy probable que durante la instalación hayáis creado un sistema de ficheros sobre ellas. Si fuese así:

dd if=/dev/zero of=/dev/hdaX bs=1M count=1

Con esto borráis las particiones y las dejáis impolutas para que podáis empezar a replicar. Lo siguiente, editamos el fichero /etc/drbd.conf en el nodo 1. Ahí tendremos que especificar un par de opciones generales y los arrays que váis a crear:

Ejemplo del fichero de configuración.

Luego lo copiamos al nodo 2. Una vez tenemos el fichero de configuración podemos crear los arrays (esto hay que hacerlo en ambos nodos):

• drbdadm create-md cluster_metadata
• drbdadm create-md vg0drbd
• drbdadm create-md vg1drbd

Y arrancamos el servicio drbd en los dos nodos. Si miráis el fichero /proc/drbd, veréis que el estado de los discos es inconsistente y que ambos nodos estan como secundarios. Así que en el nodo 1 hacéis:

• drbdsetup /dev/drbd0 primary -o
• drbdsetup /dev/drbd1 primary -o
• drbdsetup /dev/drbd2 primary –o

Con esto hemos puesto al nodo 1 como primario en todas las particiones que gestiona drbd. Ahora si miráis el /proc/drbd, veréis como está replicando los datos. Ahora hay que añadir drbd al inicio del sistema y ya de paso, creamos el sistema de ficheros en la partición que nos guardará los ficheros de configuración del cluster.

• chkconfig –level 2345 drbd on (en ambos nodos)
• mkfs.ext3 /dev/drbd0 (en el nodo 1)

En este punto, con los arrays creados, nos referiremos siempre al los dispositivos drbd para I/O para cualquier operación con discos.
Siguiente, editamos el fichero /etc/lvm/lvm.conf y cambiamos el filtro de esto:

• filter = [ "a/.*/" ]

a esto:

• filter = [ "r|/dev/hda*|" ]

y procedemos a crear el physical volume sobre drbd1 (el otro sera sobre drbd2, ya que el 0 no será gestionado por lvm).

• pvcreate /dev/drbd1

En la siguiente parte, te contare la parte del heartbeat y de como terminar la configuración de drdb.

Hasta la próxima semana.

VMware proporciona una utilidad llamada VMware CPU bootable Utility, la cual puedes descargar desde la propia web de VMware.

Una vez que arranques tu servidor ESX/ESXi desde CDROM con dicha utilidad, podrás comprobar si tu servidor VMware ESX/ESXI soporta las funcionalidades SSE, SSE2, NX/ED, Hyperthreading, Intel VT (Virtual Technology), AMD-V

VMware VMotion no tiene en cuenta la diferencia en la velocidad del reloj de la CPU de tus servidores ESX/ESXi, ni la diferencia en la memoria de la cache L1, L2, ni la diferencia en el numero de cores o sockets.

Asimismo VMware VMotion no tiene en cuenta las diferencias de memoria RAM entre los servidores ESX/ESXI involucrados en la migración en caliente.

La única pega que le veo a esta utilidad es que has de apagar tu servidor ESX/ESXi para comprobar que opciones y funcionalidades tiene soportado tu servidor VMware ESX/ESXi.

Hola que tal?

Parece que nos hemos puesto de acuerdo en hablar del tema “Backup”. Pues vamos a ello.

Veeam Backup usa la técnica de Backup sintético, permitiendo tras efectuar un backup completo, efectuar backup tan sólo de los cambios incrementalmente. La técnica habitual que usan los productos similares es crear un fichero “grande” con el “full backup” para posteriormente ir creando ficheros “delta” con los cambios incrementales una vez vamos ejecutando el job.

Una vez alguien dijo “El problema no es el Backup, es el Restore”. Cuanta razón tenía, recuerdo cuando trabajaba con Mainframes y teníamos que “tirar” de cinta (si, aquellos armarios increíbles con cintas más grandes que los magnetófonos) y oía al técnico de sistemas “no lee, no restaura”. Un sudor frío pasaba por nuestra espalda hasta que al fin el milagro se producía y restauraba.

La premisa es la siguiente. Si vas a restaurar, estadísticamente lo que vas a buscar en primera instancia para cubrir el RTO es la última copia que hemos hecho. Si ésta es completa en lugar de sintética, siempre nos dará más facilidades (rapidez, consistencia, etc.)

Es por ello que Veeam usa la particularidad de copia “reverse” o decremental, por la cual, el primer backup completo nos creará el fichero principal pero cuando ejecute la primera incremental nos encontraremos con que el fichero perteneciente a la primera ejecución tiene sólo las diferencias, mientras que el último que hemos efectuado está “completo”.

Como trabaja Veeam? Curiosamente de una forma muy parecida a como gestiona los snapshots Datacore.

Tras la generación del fichero .vbk en la primera ejecución, cuando se ejecuta la primera copia incremental, Veeam actualiza los cambios que han habido en el sistema en explotación en el fichero .vbk, guardando todos los datos antiguos que han sido actualizados en un fichero .vrb para esta ocasión.

El fichero .vbk tendra como nombre de fichero el que le hemos asignado al hacer el job, mientras que el .vrb, además del nombre llevará concatenado el “timestamp” del dia y la hora en que se inició el job.

De esta forma podremos identificar los ficheros que tenemos en nuestros directorios ya que tendremos un fichero copia.vbk y tantos .vrb como rollbacks hayamos parametrizado, que se denominarán copiayyyy-mm-ddThhmmss.vrb.

Mecanismo parecido pasa con las réplicas, pero con diferencias, ya que una réplica en el fondo es una vm preparada para ponerse en marcha asap, entonces el fichero .vbk es substituido por el .vmdk de la VM, trabajando los vrb de igual forma que el Backup. Podéis obtener un resumen y más información en www.veammeup.com, blog que mantienen los chicos de ingeniería de Veeam de San Petersburgo, desde aquí un saludo.

Especial cuidado si estáis corto de espacio en el espacio smb que contiene estos ficheros y los movéis. A partir de la versión 4.0, Veeam Backup cuando editas el job, y en la ejecución del mismo hace ciertas verificaciones de la existencia de los ficheros destino. Hablaremos otro día de este tema y de como cumplir con las normas de seguridad y auditoría haciendo servir discos intercambiables y jobs alternados de copia.

Como anécdota, en orden interno VBK ha quedado como una acepción de “Hacer un Veeam Backup”, de esta forma, en slang podemos oír “el cliente VBKs tres servidores”

La próxima semana hablaremos de como efectuar un fine tuning de nuestro sistema detectando cuellos de botella y dimensionamientos no adecuados.

VMware vSphere tiene una manera muy “peculiar” de balancear el uso de ciclos de CPU física en un servidor VMware ESX/ESXi y pensé, a raíz de una discusión muy interesante iniciada por un usuario en los foros de VMware, que también te interesaría saber, mi querido lector, lo siguiente:

El VMware VMkernel dinámicamente “migra” las máquinas virtuales de CPU cada 20 milisegundos.

Para máquinas virtuales con múltiples CPU virtuales (vCPUs), el VMkernel intentara por todos los medios no poner más de un ciclo de ejecución de una misma máquina virtual en un mismo core. Sin embargo, con la tecnología hyperthreading habilitada, el scheduler del VMkernel tiene más CPUs que verificar.

El uso de la tecnología hyperthreading, permite convertir un core físico en dos – uno físico y otro lógico -, aunque esta tecnología no garantiza el doble de potencia para las máquinas virtuales, es decir, el escaldo no es lineal. Intel estima una mejora en el rendimiento de un 20%, aunque hay excepciones.

Hyperthreading suele estar deshabilitado en la BIOS del servidor físico. Mas cosas, las tareas del Service Console siempre son ejecutadas en la CPU con el ID número 0. El VMkernel nunca migrara ninguna tarea relacionada con el Service Console a otro core diferente.

Recuerda que en vSphere, una máquina virtual puede tener hasta un máximo de 8 vCPUs y ahora, el número de vCPUs puede ser impar. Aunque la máquina virtual puede usar tanto los cores físicos como los lógicos, el scheduler en VMkernel siempre intentara usar los cores físicos versus los lógicos, y siempre que hyperthreading este activado, obviamente.

Moraleja: un servidor vSphere con hyperthrering activado tendrá la capacidad de ejecutar mas threads simultáneos en paralelo (cpu fisica y cpu logica), por consiguiente, la teoría dice que el rendimiento de la infraestructura virtual seria mayor.

¡Hola! Aquí estoy de nuevo con vosotros para contaros alguna cosa nueva que creo os pueda interesar, y en el tema de hoy voy a volver a hacer hincapié un poco más si cabe en las diferencias técnicas entre VMware ESX y ESXi, para que a la hora de elegir uno u otro tengamos todavía un poquito más claro por cual decantarnos.

A parte del magnífico artículo de José María González y sus reseñas en otros artículos del Blog, me gustaría dejaros un poco más claro aquellas diferencias que no son tan obvias:

1. Así como en ESX y ESXi viene CDP (Cisco Descovery Protocol) activado por defecto, si veremos que sólo en ESX es posible configurar la información de la NIC física (VMNIC) y el nombre del HOST ESX a nuestros Switches CISCO.
2. JUMBO FRAMES así como en ESX y ESXi está soportado a nivel del Guest OS en los dos a nivel de Kernel TCP/IP sólo estará soportado por ESX y NO por ESXi.
3. NetQueue que es una tecnología pensada para entornos de Red de 10GB Ethernet estará soportada para ESX pero NO para ESXi
4. NETFLOW que es una tecnología que permite entre otras cosas la monitorización de la RED, detección de intrusión y prevención, análisis forenses de la RED,etc.. tiene de forma experimental soporte en ESX pero NO para ESXi.
5. También haré una reseña a que podemos controlar directamente vía CABLE SERIAL nuestros ESX pero NO nuestros ESXi.
6. ESXi tiene un SET de Harwarde Certificado más pequeño al ser un sistema independiente y no depender en (RHEL) del servicio de consola el cual provee de drivers para otro hardware.
7. No hay soporte en ESXi para BOOT from SAN. Aunque esto casi es de cajón ya que por su estructura lo veo innecesario pudiendo ir embebido en un( USB,SD) como ejemplo.
8. La tan escasa aportación de programas de terceros para copia de seguridad en ESXi, yaque este deberemos hacerlo desde nuestra CLI. Aquí si diremos que Veeam 4 si integra soporte de Backup no sólo para ESX sino también para nuestros ESXi.
9. Finalmente, VMware en cooperación con Melanox Technologies da soporte a INFINIBAND con sus HOST CHANNEL ADAPTERS para ESX pero NO para ESXi.

Con esto NO quiere decir que ESXi sea inferior para nada en nuestro entorno de producción o testeo a nuestros ESX ,pero sí debemos tener en cuenta esta serie de factores en caso de que vayamos, ó estemos interesados en utilizarlos.

Bueno aquí me despido de vosotros y aprovecho en este segundo POST en agradeceros como me habéis tratado desde que he comenzado en el BLOG y como no felicitaros a todos el año nuevo. Hasta la próxima.

En 1998, VMware descubrió una tecnóloga que fue considerada hasta entonces algo imposible de lograr, virtualizar la plataforma x86.

Esta solución fue una combinación de traducción binaria (binary translation ) y ejecución directa (direct execution) directamente en el procesador, lo que permitió que múltiples sistemas operativos “Guest” se pudiesen ejecutar a la vez en el mismo hardware físico, totalmente aislados unos de otros y con una “sobrecarga” en la capa virtualización relativamente pequeña.

El ahorro que decenas de miles de empresas han obtenido con el despliegue de esta tecnología, está impulsando, de una forma pronunciada y rápida, la adopción de de la tecnología de virtualización, desde el centro de datos hasta el escritorio.

Resolver el problema de la proliferación de servidores, la falta de espacio, el uso de energía y refrigeración en las salas de servidores mediante la sustitución de servidores de aplicaciones individuales con maquinas virtuales consolidadas en un número mucho menor de equipos físicos, son sólo algunos de los principales beneficios de la virtualización de servidores.

Asimismo, como la capacidad de procesamiento en los servidores ha aumentado de manera constante en los últimos años, y no cabe duda que seguirá aumentando, la virtualización a demostrado ser una tecnología muy potente para simplificar el despliegue de software y servicios, dotando al Centro de Datos de mucha más agilidad, flexibilidad y lo que quizás haya pasado desapercibido, pero no por ello es menos impórtate, la reducción significante de los costes energéticos y el impacto medio ambiental.

Este nuevo libro sobre VMware vSphere que lanzo al mercado de la virtualización de servidores en castellano, es una manual de virtualización VMware muy completo que pretende descubrirte los secretos y conceptos mas intrínsecos de VMware vSphere 4 y VMware vCenter Server 4 y sirve como ayuda indispensable para preparar y aprobar la certificación oficial VMware™ VCP™ 410 con garantías.

101 Secretos de VMware vSphere está disponible desde hoy en formato libro en este enlace y también está disponible en formato ebook (Disponible en formato PDF para Digital Editions) en este enlace y a un precio reducido.

Espero y deseo que te divierta la lectura de mi manual de virtualización VMware, tanto o mas como yo me divertí escribiéndolo para ti.