Virtualización con

VMware vSphere

eBook
por
José María González

José María González

info@jmgvirtualconsulting.com
http://www.jmgvirtualconsulting.com
@jmgconsulting
Capítulo 1. Primeros pasos en la certificación VMware vSphere™ VCP™ 3

Capítulo 2. Instalación vSphere™ ...................................................................... 7

Capítulo 3. Red en vSphere™ ............................................................................ 24

Capítulo 4. Almacenamiento en vSphere™ .................................................... 40

Capítulo 5. VMware vCenter Server ............................................................... 55

Capítulo 6. Máquinas Virtuales en vSphere™ ............................................... 70

Capítulo 7. Control de acceso en vSphere™ ................................................... 83

Capítulo 8. Gestión de recursos en vSphere™................................................ 92

Capítulo 9. Monitorización de recursos en vSphere™ ................................. 96

Capítulo 10. Funcionalidades Enterprise en vSphere™ ........................... 104

Gracias y Cierre .................................................................................................. 127

Capítulo 1. Primeros pasos en la certificación VMware vSphere™ VCP™

¿Por qué la virtualización es tan importante?

En 1998, VMware descubrió una tecnología 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 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

consumo de energía y la refrigeración en las salas de servidores mediante la
sustitución de servidores de aplicaciones individuales por máquinas 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.

Otros de los beneficios de la virtualización son:

Mejor uso del hardware del servidor mediante el despliegue de nuevos

servidores en máquinas virtuales, evitando añadir más servidores físicos
infrautilizados al centro de datos.

Reducir drásticamente el tiempo de aprovisionamiento de nuevos servidores

en máquinas virtuales, pasando a minutos en lugar de días o semanas
necesarias para aprovisionar un servidor físico.

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 ha 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 importante, la reducción
significativa de los costes energéticos y el impacto medio ambiental.
¿Cómo conseguir la certificación VCP™ ?

Para obtener la titulación VMware Certified Professional debes seguir tres

pasos muy sencillos:

1. Participar en un curso autorizado y oficial VMware para adquirir

experiencia. Este curso es impartido por un instructor oficial VMware, el cual
te enseñara las mejores prácticas en la instalación, configuración y gestión de
VMware vSphere™

Los cursos aceptados son:

VMware vSphere 6.x: Install, Configure and Manage v6

VMware vSphere 6: What´s New (Este curso es necesario solo para los
candidatos que ya tengan la certificación oficial VCP5)

2. Adquirir experiencia con los productos VMware. Aquellos profesionales

que no han tenido experiencia previa con los productos VMware, les
resultará más difícil pasar el examen VCP6™.

3. Inscribirse y aprobar el examen oficial. Para inscribirse en el examen VCP™

6 (VMware Certified Professional), has de darte de alta en VMware en la
siguiente dirección:

http://www.jmgvirtualconsulting.com/Formacion/VMware/VMware-
vSphere-ICM-Install-Configure-and-Manage-6

Para ver los cursos autorizados oficiales por VMware, donde se imparten los
cursos oficiales, puedes visitar la siguiente dirección web:

http://www.jmgvirtualconsulting.com/formacion

Algunas preguntas frecuentes sobre VMware™

VCP™

¿Cuál es la “Hoja de Ruta” para obtener la certificación VCP™ en vSphere™?

Hay cuatro caminos posibles para lograr la certificación VCP6™ en vSphere™

6.

1. Si eres nuevo en el mundo VMware:

 Asiste al curso oficial VMware vSphere™ 6: Install, Configure and

Manage.
  Aprueba el examen VCP6 en vSphere™ 6.

2. Si eres actualmente un VCP3 en VMware Infrastructure 3:

 Asiste al curso oficial VMware vSphere™ 6: Install, Configure and

Manage o al curso oficial What´s New 5 a 6.

3. Si eres actualmente un VCP4 en VMware ESX/ESXI 4.x:

 Asiste al curso oficial VMware vSphere™ 6: Install, Configure and

Manage

4. Si no eres VCP pero has asistido a uno de los cursos requeridos para la
certificación oficial VCP4™ (VMware Install, Configure and Manage):

 Asiste al curso VMware vSphere™ 5: What´s New 5.

 Aprueba el examen VCP™ en vSphere™ 4.x.
 Aprueba el examen VCP™ en vSphere™ 5.

Puedes ver los plazos y el “Last minute” en la siguiente URL:

http://www.jmgvirtualconsulting.com/formacion

¿Cómo puedo saber si el curso es oficial VMware?

Los cursos que no estén autorizados por VMware, no cumplen los requisitos
para la certificación VCP5 en vSphere™ 6. Asegúrate de asistir a un curso
oficial VMware confirmando que dicho curso aparece en la página web de
VMware:

http://mylearn.vmware.com/mgrreg/index.cfm

¿Realmente necesito asistir al curso oficial para poder obtener la certificación

VCP6™ en vSphere 6™?

El curso oficial VMware es un requisito obligatorio para la certificación.

VMware no hace ninguna excepción en este requisito.

¿Cómo me registro para el examen de certificación VCP6™ en vSphere 6™?

El examen VMware Certified Professional es administrado por Pearson VUE,

un centro autorizado externo. Pearson VUE tiene más de 3.500 centros de
exámenes autorizados en todo el mundo.

¿Cuántas preguntas hay en el examen VCP6™ de vSphere™ 6?

En el examen hay 125 preguntas tipo test. Tienes 90 minutos para responder
a todas las preguntas. En países donde el inglés no es el primer idioma, los
candidatos recibirán automáticamente 30 minutos adicionales. Necesitas
una puntuación de 300 o más para poder aprobar el examen, siendo 500 la
puntuación máxima.

¿Qué ocurre si suspendo el examen?

Podrás intentarlo de nuevo siempre que quieras, pero tendrás que esperar 7
días antes de intentarlo otra vez. Cada intento exige un nuevo pago para
cubrir el coste del examen.

¿Cómo puedo saber lo que abarca el examen VCP™6?

En la dirección web adjunta, podrás encontrar una guía oficial VMware

(VCP6 Exam Blueprint) sobre la materia que se cubre en el examen. Usa esta
guía como referencia para preparar el examen: (requiere login)

http://mylearn.vmware.com/portals/certification/

¿Hay alguna forma de practicar el examen antes de presentarse al examen oficial?

VMware ha puesto a disposición del público en general, una dirección web

donde puedes practicar antes de presentarte al examen oficial:

http://mylearn.vmware.com/mgrSurvey/assessLogin.cfm

Recuerda que las preguntas mostradas en este simulacro, solo son

meramente orientativas. No obstante, te servirán para saber si estás
preparado para presentarte al examen o, por el contrario, si necesitas
estudiar un poco más y retrasar la fecha del examen.
Capítulo 2. Instalación vSphere™

En esta primera sección verás una introducción a la virtualización y la

instalación de VMware vSphere™ ESXi, los mínimos y máximos tanto
soportados como certificados por VMware vSphere™ ESXi / vCenter
Server™, la nueva versión de vCenter Server Appliance™ para entornos
Linux, así como los mínimos y máximos para las máquinas virtuales en
vSphere™

¿Cómo es la virtualización con VMware vSphere™?

Los servidores y los desktops cada día son más potentes y el software de
virtualización de servidores ha demostrado, una vez más, ser una tecnología
indispensable para simplificar el centro de datos y dotarlo de inteligencia
propia.

En un entorno físico tradicional, el sistema operativo y el software asociado

se están ejecutando en un único servidor físico. Este modelo de una
aplicación por servidor puede llegar a ser, y de hecho lo es en muchos casos,
inflexible e ineficiente. Esta relación 1:1 precisamente es la que hace que
servidores de muchos centros de datos que estén infrautilizados, alcanzado
tan solo el uso de entre un 5 y un 10% de los recursos físicos de dichos
servidores.

Asimismo, el aprovisionamiento de servidores físicos en un centro de datos

es un proceso costoso en cuanto al tiempo necesario que se dedica a
aprovisionar un servidor físico. En un entorno no virtualizado has de dedicar
tiempo a comprar nuevo hardware, enrackar los servidores, instalar el
sistema operativo y las aplicaciones.

Con el software de virtualización de servidores podemos transformar

hardware en software. De esta forma, podemos ejecutar diferentes sistemas
operativos, como por ejemplo Windows, Linux, Solaris, incluso MS-DOS,
simultáneamente y en el mismo servidor físico. Así, cada contenedor, dotado
de su sistema operativo “Guest” o invitado, es llamado virtual machine
(máquina virtual en inglés) o VM como acrónimo.

Pero la virtualización de servidores, no es un software de simulación o

emulación, como el software de training de Cisco que simula un router de
Cisco para poder hacer prácticas, es un software de ejecución.

Veamos ya algunas de las diferencias importantes de esta nueva versión de

VMware vSphere con las versiones anteriores.

Primero, y quizás uno de los cambios más importantes en vSphere™ es que la

versión vSphere™ ESX ya no está disponible.

También, ahora con la nueva versión de ESXi™, es posible instalar la imagen

de un ESXi directamente en la memoria del host físico usando una nueva
funcionalidad llamada vSphere™ Auto Deploy ESXi, de la cual hablaremos
más adelante en este libro.

VMware vSphere™ incluye una nueva versión para su sistema de archivos

llamada VMFS-6 el cual, y a diferencia de las versiones anteriores, solo
incluye un block size de 1MB a la hora de formatear el datastore.

VMware vSphere™ Storage Appliance - de las siglas en inglés VSA - es otra

de las nuevas funcionalidades incluidas en la esta versión. Aunque
hablaremos de esta nueva funcionalidad más adelante, recordarte que el VSA
Manager ha de ser instalado en tu servidor de vCenter para que puedas
configurar esta nueva herramienta.

VMware vSphere™ ESXi Dump Collector te permitirá recoger todos los log
score dumps de tus servidores ESXi. Otra nueva funcionalidad en VMware
vSphere™.

Para poder ver el video tutorial de instalación de un servidor ESXi y muchos

más videos tutoriales, entra en nuestra página web dedicada en exclusiva al
contenido multimedia extra de este manual en
http://www.josemariagonzalez.es/curso-online-gratuito - podrás ver más de
100 videos gratis sobre virtualización con VMware vSphere.

Alternativamente, también puedes ver videos tutoriales de instalación y

configuración de VMware vSphere ESXi, así como manuales, artículos y posts
interesantes para preparar el examen de certificación oficial VCP™510 en la
página oficial del blog de virtualización y cloud computing en español en
http://www.josemariagonzalez.es/
¿Cómo es una máquina virtual en vSphere™?

Una máquina virtual en VMware vSphere™, es básicamente un conjunto de

ficheros planos y binarios los cuales conforman la máquina virtual (MV)
completa con su sistema operativo y aplicaciones incluidas. Los ficheros más
importantes que componen una máquina virtual son: el fichero de
configuración (.vmx), el fichero de disco virtual (.vmdk), el fichero BIOS de la
máquina virtual (.nvram) y el fichero de log (.log).

El tamaño del fichero swap de la máquina virtual (.vswp) es igual a la cantidad

de memoria RAM configurada en dicha máquina virtual. Recuerda que este
fichero se genera cuando la máquina virtual se arranca y se borra cuando se
apaga.

Con la nueva versión vSphere™ ESXi, el máximo número de discos virtuales

por host se ha aumentado a 2048 discos virtuales.

El tamaño máximo de un disco virtual que puedes configurar en una máquina

virtual es de 2TB menos 512Bytes (espacio necesario del overhead del disco
virtual).!
En cuanto a la memoria RAM asignada a las máquinas virtuales, ahora es
posible asignar hasta un 1TB de memoria RAM física de tu host, el cual es el
tamaño máximo que un host ESXi físico puede tener configurado.

Asimismo, es posible tener hasta un máximo de 512 máquinas virtuales por

servidor ESXi. El número máximo de adaptadores SCSI para una máquina
virtual es de cuatro por máquina virtual.

A cada máquina virtual le puedes conectar un controlador IDE máximo al cual

puedes conectar hasta 4 dispositivos IDE.

En cuanto a dispositivos xHCI USB se refiere, es posible conectar hasta 20

controladores USB por máquina virtual. Sin embargo, solo es posible
conectar un dispositivo USB 3.0 por máquina virtual. A fecha de publicación
de este libro, VMware vSphere™ ESXi 5 aun no soporta dispositivos USB 3.0
conectados directamente en el servidor. ESXi 6 ya soporta USB versión 3.0

Por último, puedes configurar hasta 128MB de memoria RAM destinada a la

memoria de video por máquina virtual. Asimismo, el máximo número de
vCPUs (virtual CPUs) por host ESXi es de 2048, siendo 25 el número máximo
de vCPUs por core. El número máximo de vCPUs que podrás asignar a tus
máquinas virtuales es de 32 vCPUs. Nota que para llegar a este número de
vCPUs también el sistema operativo tiene que soportarlo.

Si te estás preparando el examen oficial de certificación VCP™, asegúrate

bien que conoces los mínimos y máximos de una máquina virtual y prepárate
para poder responder preguntas tipo como:

¿Cuántos puertos serie, paralelo, CDROMs, floppies, NICs, puede llegar a tener
una máquina virtual?

Asimismo, recuerda que aunque una máquina virtual puede tener como
número máximo 10 tarjetas virtuales, solo podrás conectar cuatro tarjetas
máximo durante la creación de tus máquinas virtuales con el wizard de
creación de máquinas virtuales de vCenter Server.

VMware vSphere™ permite crear máquinas virtuales usando dos wizards:

Typical y Custom. Si seleccionas el método Typical, el wizard solo te pedirá el
nombre, DataStore para la máquina virtual, sistema operativo y el tamaño del
disco virtual, sin embargo no tendrás la opción de configurar otras opciones
como el número de vCPUs, la versión del hardware virtual, la cantidad de
memoria y un largo etcétera.

Por consiguiente, es una mejor práctica seleccionar la opción Custom para

poder personalizar de una forma más profunda la configuración hardware de
tus máquinas virtuales.
Aviso: Recuerda que una máquina virtual en vSphere™5 soporta hardware
virtual versión 8 y que este hardware virtual no es compatible con versiones
anteriores a vSphere™ 5. Por consiguiente, si quieres tener un entorno mixto,
ESX/ESXi 4.x y vSphere™ ESXi 5, has de dejar el hardware virtual de tus
máquinas virtuales con la versión 7 correspondiente a la versión 4 de
VMware vSphere™ ESX/ESXi 4. Para terminar con un dato más sobre las
máquinas virtuales y su configuración, el número máximo de virtual SCSI
targets por máquina virtual es de 60. La versión del hardware virtual en la
versión 6.0 es la 11!.

Para poder ver el video tutorial de instalación de una máquina virtual en un

servidor ESXi, entra en nuestra página web dedicada en exclusiva a los videos
tutoriales gratuitos de contenido multimedia de en:

http://www.josemariagonzalez.es/curso-online-gratuito

¿Cuál es la diferencia entre un software de virtualización basado en un

hipervisor y la virtualización basada en host?
La virtualización basada en hipervisor (también denominada Bare-Metal),
como por ejemplo vSphere™ ESXi, Microsoft HyperV o Citrix XenServer, está
instalada en un servidor físico sin la necesidad de que exista un sistema
operativo (Windows o Linux) instalado previamente.

No obstante, la virtualización basada en host, como por ejemplo VMware

Server, VMware Workstation o VMware Fusion, necesita previamente un
sistema operativo instalado, ya sea Microsoft Windows, Mac OS o Linux.

Hay varias razones por las que un cliente elegiría el software de

virtualización basado en hipervisor, como por ejemplo vSphere™ ESXi, en
lugar de un software de virtualización basado en host, como por ejemplo
VMware Server.

Primero, con el software de virtualización basado en hipervisor, es

posible actualizar las máquinas virtuales que se albergan en los servidores
físicos sin ningún tipo de downtime.

Segundo, es muy probable que la empresa ya esté virtualizando varios

servidores físicos y quiera tener la opción de tener una gestión centralizada.

Por último, un hipervisor baremetal siempre ofrece una mayor confiabilidad y

rendimiento al no precisar de un sistema operativo Host lo cual se elimina un
posible punto de fallo a nivel de hardware.

Aunque la virtualización basada en hipervisor ofrece un mayor rendimiento,

es la virtualización basada en host la que ofrece una compatibilidad con el
hardware mucho más amplia, es decir, si puedes instalar Windows o Linux en
tu servidor físico entonces podrás instalar la solución de virtualización
basada en host.

Por consiguiente, una de las mayores diferencias de la solución de

virtualización basada en hipervisor y la solución de virtualización basada en
host - aparte de las obvias ya mencionadas - , es que esta última tiende a
tener una lista de hardware certificado mucha más amplia.
Sin embargo, la virtualización basada en hipervisor tiene un mayor
rendimiento, mayor fiabilidad y estabilidad, mayor escalabilidad y mucha más
funcionalidad.

A diferencia de las versiones anteriores a VMware vSphere™ ESXi, solo las

variables, memoria reservada y memoria configurada (Reserved Memory y
Configured Memory) afectan ahora al incremento o reducción del memory
overhead, el cual es una “penalización” a nivel de la capa de memoria que
todos tenemos que pagar por el simple hecho de virtualizar nuestro servidor
físico. Esta penalización se mide en megas de memoria RAM y son megas de
memoria que dejamos de ver y de usar en nuestro servidor físico.

Como consecuencia de este “impuesto revolucionario” que existía por el

simple hecho de virtualizar nuestro servidor, VMware vSphere™ ESXi 5 usa
una nueva funcionalidad llamada VMX swap con la que es posible reducir el
memory overhead de tus máquinas virtuales.

Básicamente, con una nueva tecnología llamada VMX swap, el tamaño del
memory overhead se crea en un fichero swap con lo que este espacio de
memoria puede llegar a ser re-utilizado por el hipervisor. Esta técnica
posibilita un aumento en el ratio de consolidación de VMware vSphere™ 5
con respecto a versiones anteriores de VMware.

¿Cuáles son los nuevos prerrequisitos hardware en VMware vSphere™ ESXi?

A día de hoy, es posible instalar VMware vSphere™ ESXi en cualquier tipo de

servidor de nueva generación. Asimismo, la lista de compatibilidad de
hardware para VMware vSphere™ ESXi ha aumentado considerablemente
en esta última versión, debido principalmente, a que ESXI es la única versión
disponible en vSphere™.

Estos son los requerimientos de hardware mínimos para poder instalar

VMware vSphere™ ESXi 5:

Procesador: Solo CPUs de 64-bit x86, Intel o AMD, máximo 160 CPUs (cores
o hyperthreads).

Memoria: 2GB de RAM mínimo, 1TB máximo.

Red: Una o más tarjetas Gigabit Ethernet. Las tarjetas Ethernet de 10Gb
también están soportadas. El número máximo de tarjetas de 1Gb Ethernet
(tg3 de Broadcom) por servidor es de 32.

Controladora de disco: Controladora SCSI, controladora FC (Fibre Channel),

controladora iSCSI, controladora RAID interna, SAS y SATA.

Almacenamiento: disco SCSI, LUN (Logical Unit Number) FC, disco iSCSI o
RAID LUN con espacio disponible sin particionar.

Es posible instalar VMware vSphere™ ESXi 5 en una LUN de la SAN, método

conocido con el nombre de Boot from SAN (BFS). BFS está soportado en Fibre
Channel SAN, en iSCSI (iniciadores de software iSCSI y dependent hardware
iSCSI) y en FCoE - de las siglas en inglés Fibre Channel over Ethernet - para
aquellas cabinas de almacenamiento que estén incluidas en la matriz de
compatibilidad. VMware vSphere™ ESXi 5 puede configurarse con un
máximo de 256 LUNs de FC (Fibre Channel).

Recuerda que los dos requerimientos necesarios para poder hacer boot from
SAN son:

1. La BIOS de la HBA (Host Bus Adapter) debe estar habilitada.

2. Debes seleccionar la HBA con el número de slot PCI menor.

Aviso: Recuerda que si haces una actualización de ESX/ESXi 4.1 a VMware

vSphere™ ESXi 5, aquellos puertos no conocidos - no listados en la pestaña
security profile - que se hayan abierto con el comando de consola esxcfg-
firewall en tu servidor ESX/ESXi 4.x, no permanecerán abiertos después del
upgrade.

Asimismo, VMware vSphere™ ESXi 5 soporta un máximo de 8 dispositivos

PCI/PCIe en modo VMDirectPath passtrough. Sin embargo, una máquina
virtual no puede tener configurados más de dos dispositivos PCIx/PCIe
configurados como VMDirectPath.

Si usas iniciadores de software iSCSI para hacer BFS y tu administrador

deshabilita este iniciador de software iSCSI, el servidor ESXi 5 volverá
habilitar dicho iniciador la próxima vez que se reinicie el servidor para poder
hacer BFS.

Algunos aspectos importantes que deberías saber sobre la diferencias y

similitudes entre VMware vSphere™ ESX y ESXi

En VMware ESX y ESXi hay más similitudes que diferencias, aunque quizá, el
beneficio más importante de ESXi sobre ESX es que ESXi aumenta la
seguridad y la fiabilidad de nuestro hipervisor.

VMware ESXi 5 tiene mucho menos código (76MB de footprint) que

parchear y, por lo tanto, tiene una superficie de ataque mucho menor. La
versión ESX ha desaparecido como tal con el lanzamiento de la versión de
VMware vSphere 5.

La versión VMware vSphere™ ESXi 5 como la versión ESX comparten el

mismo VMkernel y VMM - de las siglas en ingles Virtual Machine Manager -,
aunque hay algunas connotaciones muy importantes a destacar:

1. Extensiones VMkernel: Mientras que en la versión clásica de VMware ESX

podías instalar agentes y drivers de empresas de terceras partes, en ESXi
solo se permite instalar extensiones en el VMkernel que hayan sido
previamente firmados digitalmente por VMware. Esta restricción ayuda
mucho a asegurar el entorno y mantener el código seguro en el VMkernel.
2. Muchos de los agentes y deamons que se ejecutaban en el Service Console
(COS) en la versión clásica del ESX, han sido convertidos y embebidos para
que se ejecuten directamente en el VMkernel del ESXi.

3. La imagen del sistema en ESXi - system image - es una imagen bootable que
es cargada directamente en memoria física. El propio “installer” usa esa
misma imagen de sistema para copiar los ficheros en un disco local para
futuros arranques.

Debido a que la imagen del sistema es cargada en memoria, la versión ESXi

no necesita obligatoriamente de un disco local cuando este se está
ejecutando. Esto significa que el disco local podría fallar pero, sin embargo,
nuestro VMkernel continuaría ejecutándose.

4. La partición scratch. Es una partición de 4GB virtual y de tipo FAT (VFAT)

la cual es creada por defecto en el primer disco local del servidor ESXi, si tu
servidor tiene discos locales, claro. Si el servidor no tiene ningún disco local,
esta partición no existirá pero se “rediccionara” el directorio scratch a una
partición de tipo ramdisk llamada /tmp. Esto significa que el contenido de
esta partición scratch no “sobrevivirá” a un reinicio del servidor ESXi.

Por consiguiente, el servidor ESXi puede necesitar hasta 4GB de memoria

RAM para almacenar esta partición scratch.

5. Y por último, pero no por ello menos importante, tenemos la partición

bootbank. Esta partición contiene la imagen del sistema sobre un sistema de
archivos. Si hay un disco local al cual ESXi pueda escribir, este almacena dos
copias del bootbank. Pero ojo, solo una es montada en la estructura del
sistema de archivos del ESXi en el directorio /bootbank. La segunda copia se
usa únicamente durante actualizaciones para mantener una segunda copia
como backup en caso de problemas durante actualizaciones del sistema.

Por otro lado, en VMware vSphere™ ESXi 5 es posible hacer una instalación
de la imagen directamente en la memoria del servidor físico usando una
nueva funcionalidad llamada vSphere™ Auto Deploy ESXi Installation Option.

Con VMware vSphere™ Auto Deploy podrás acceder al fichero de instalación

desatendido (answer file) via CIFS, SFTP o HTTP.

VMware vSphere™ ESXi 5 soporta la designación de capacidad de disco

dinámicamente mediante una funcionalidad llamada vStorage Thin
Provisioning.

Ahora, con VMware vSphere™ ESXi es posible hacer una migración en

caliente con Storage vMotion de una máquina virtual que tiene snapshots.

VMFS-5 soporta un máximo de 9.000 discos virtuales por datastore. Solo

existe una única opción de tamaño de bloque para un datastore formateado
con la versión 5 de VMFS. Este block size es únicamente de 1MB y te permite
crear discos virtuales con un tamaño de hasta 2Gb.
Ahora en VMware vSphere™ ESXi 5 y VMFS-5 es posible tener hasta un
máximo de 4 ficheros swap por máquina virtual.

También ahora es posible con VMware vSphere™ ESXi 5 hacer un “unmount”

del datastore siempre y cuando se cumplan los tres requisitos siguientes:

1. El datastore no puede contener ninguna máquina virtual.

2. El datastore no puede ser usado por vSphere™ HA heartbeat.

3. El datatore no puede pertenecer a un datastore clúster.

VMware vSphere™ ESXi 5 soporta ahora hasta 3.000 máquinas virtuales por
clúster HA/DRS con independencia del número de servidores ESXi que hayas
configurado en tu clúster.

Por último, recuerda que VMFS-5 “solo” soporta 256 volúmenes o

datastores VMFS por servidor ESXi.

Aviso: Cuando actualizas VMFS-3 a la versión VMFS-5, la configuración del

block size de tu datastore VMFS-3 es heredara, es decir, si tu datastore
VMFS-3 fue configurado con un block size de 4MB, al actualizar a la versión
VMFS-5 el block size seguirá siendo de 4MB. Nota que el block size de un
datastore VMFS-5 no actualizado no puede ser distinto de 1MB.

Diferentes tipos de instalación en vSphere ESXi

VMware vSphere™ ESXi 5 solo es posible instalarlo en modo texto, a

diferencia de VMware ESX donde era posible instalarlo también en modo
gráfico.

Una nueva funcionalidad en VMware vSphere™ ESXi 5 llamada Image Builder

te permitirá hacer instalaciones personalizadas de tu ESXi así como asociar
actualizaciones del binario del ESXi a dicha personalización. Hablaremos del
Image Builder más adelante en este libro. Solo apuntar que el formato de los
paquetes que usa VMware vSphere™ ESXi Image Builder se llaman VIB - de
las siglas en inglés vSphere™ Installation Bundle.
Si usas la nueva funcionalidad llamada VMware Auto Deploy, recuerda que los
logs de tu servidor ESXi serán almacenados en memoria con lo que al
reinicializar tu servidor perderás estos logs por defecto. Para definir profiles
de imágenes para tus servidores ESXi con Auto Deploy tendrás que usar
cmdlet incluidos en el vSphere™ Power CLI image builder.

Es posible también actualizar servidores ESXi con la utilidad Enterprise

llamada VMware Update Manager (VUM), de la que hablaremos también en
este libro.

Una mejora practica antes de actualizar un servidor ESXi, es guardar la

configuración del servidor que vas actualizar con el siguiente comando de
vCLI: vicfg-cfgbackup –s

Aviso: Con VMware vSphere™ ESXi 5, el número total de caminos de FC

(Fiber Channel) por servidor se han aumentado hasta los 1.204. En VMware
vSphere™ ESXi 5 el máximo número de servidores conectados a volúmenes
VMFS es de 64 hosts por volumen VMFS.

Asimismo, el número máximo de datastores conectados a un Cluster

HA/DRS es de 32.

Tampoco es posible actualizar varios servidores ESXi en un clúster

simultáneamente, es decir, solo está permitido actualizar un servidor ESXi a
la vez dentro de tu clúster.

Datos importantes sobre el nuevo installer en vSphere™

Durante la instalación de vSphere™ ESXi, el installer de VMware, escanea no

solo los discos locales conectados al servidor físico ESXi, sino que también
hará un escaneo de los discos de tu SAN de FC y los mostrara si este tiene
acceso a ellos.

Por consiguiente, y para evitar la instalación del binario de ESXi en una de tus
LUNs de la SAN FC, recuerda esta “Best Practices” de VMware para evitar la
sobre escritura de una LUN: Establece o solicita al administrador SAN de tu
empresa un “LUN Masking” o mejor aún, si vas a instalar el binario en discos
locales, desconecta los cables de la SAN de tu servidor ESXi. Además, está
mejor práctica reduce el tiempo que necesita el installer de VMware en
buscar discos conectados al sistema.

Si estas instalando un servidor ESXi en un disco que ya contiene una versión

previa a la versión vSphere™ 5, el installer te da la opción de actualizar esa
versión.

Cuando configuras una cabina SAN de FC con vSphere™, asegúrate de seguir

las mejores recomendaciones:

1. Cada LUN debería contener solo un DataStore VMFS.

2. Cada LUN debería ser presentada a todos los servidores ESXi con el
mismo LUN ID.

Hay cuatro opciones o métodos para instalar la nueva versión de VMware

vSphere™ ESXi 5:

 Usando vSphere Auto Deploy

 Mediante una instalación via script

 Actualizando un servidor ya existente con VUM

 Haciendo una instalación interactiva como se muestra en la imagen

anterior.

Esta última opción es el método de instalación recomendado cuando has de

instalar un número pequeño de servidores VMware vSphere™ ESXi.

VMware vSphere™ 5 ha dejado de soportar máquinas virtuales de 32bit y

por consiguiente VMM de 32bits. Solo Virtual Machine Monitors de 64 bits
pueden ejecutar sistemas operativos de 32bits. Por consiguiente, el uso
exclusivo de un VMM de 64bits en vSphere™ 5 requiere instrucciones
específicas a nivel de CPU llamadas LAHF y SAHF las cuales no se
encuentran en arquitecturas de 32bit más antiguas. LAHF y SAHF solo están
soportados en vSphere™ 5.

Aviso: Una vez instalado, un servidor VMware vSphere™ ESXi 5 puede tener
hasta 256 LUNs FC (Fiber Channel) por servidor. Asimismo, el número
máximo del ID en FC es de 255 pues los IDs de FC empiezan por el número 0
y no por el número 1.
Sin embargo, el número máximo de caminos iSCSI que un servidor ESXi pues
ver es de 1.024.

Una instalación inicial de vSphere™ ESXi usa el formato GPT - de las siglas en
inglés GUID Particion Table en lugar del formato MBR - de las siglas en ingles
Master Boot Record - lo cual permite instalar ESXi en discos con un tamaño
superior a 2TB. No obstante, si actualizas de versión VMware ESX/ESXi 4.x a
ESXi 5 no se usara el formato GPT, sino que se mantendrá el formato MBR.

Aspectos importantes sobre la configuración y la seguridad de vSphere ESXi™

Ahora VMware vSphere™ ESXi incluye dos nuevas funcionalidades para

aumentar la seguridad del VMkernel:

1. Memory Hardening: El kernel del ESXi, aplicaciones user-mode y

ejecutables como drivers y librerías están localizadas en zonas de
memoria aleatorias para evitar que software del tipo troyanos
averigüen de una forma sencilla la localización de estas zonas de
memoria.

2. Kernel Module Integrity: Los módulos, drives y aplicaciones de ESXi

son “firmados” digitalmente para asegurar la integridad de estos una
vez que el VMkernel los carga en memoria.

Asimismo, a diferencia de las versiones VMware ESX 4.x, en VMware

vSphere™ ESXi 5 es posible hacer boot de tu servidor ESXi desde un disco
USB externo.

También, ahora es posible instalar tus servidores ESXi con la opción de

VMware Auto Deploy, sobre todo cuando tienes un número de host
importante que instalar. De esta forma, acelerarás la fase de instalación del
binario de ESXi y el despliegue de tus máquinas virtuales.

Si haces una actualización de la versión ESX 4.x a la versión ESXi 5 el

portgroup tipo Service Console (solo disponible en versiones ESX) será
borrado ya que en los servidores ESXi no existe un Service Console.
Asimismo, el portgroup de gestión en ESXi es llamado Management Port.
Recuerda antes de actualizar un servidor ESXi hacer una copia de seguridad
de su configuración con el comando vicfg-cfgbackup desde el vCli.

Desde el punto de vista de almacenamiento compartido SAN iSCSC, el

número máximo de LUNs iSCSI que puedes conectar a un servidor ESXi es de
256. Otro de los límites que han cambiado en esta nueva versión de VMware
vSphere™ ESXi 5 con respecto a las versiones anteriores, es que ahora es
posible tener arrancadas hasta 2.048 máquinas virtuales por volumen VMFS.

También, ahora es posible activar - y está soportado - el modo soporte (TSM -

de las siglas en inglés Tech Support Mode) de modo que podrás entrar vía
SSH a tu servidor ESXi. Puedes activar el modo TSM desde la DCUI (de las
siglas en inglés Direct Console User Interface) o con el vSphere Client a
través del panel Security Profile localizado dentro de la pestaña de
Configuration.

Una vez entres en la consola de tu servidor ESXi, via comando podrás ver los
logs de tu sistema, configurar las propiedades de los servicios de DNS, NTP,
arrancar máquinas virtuales, apagar servidores ESXi y un largo etcétera. Sin
embargo, una de las pocas tareas que no podrás hacer desde consola es la de
poner tu host ESXi en modo mantenimiento.

Para poder ver una guía de referencia de todos los comandos disponibles por
consola en la versión ESXi, te recomiendo que veas el episodio
correspondiente de nuestro canal de televisión web sobre la virtualización y
el cloud computing en español en la siguiente dirección:
http://youtube.com/blogvirtualizacion

Asimismo, con el fin de mejorar la seguridad del servidor ESXi, VMware ha

añadido un firewall embebido en el VMkernel. A diferencia de las versiones
anteriores, este firewall no está basado en IPtables de Linux.

Aviso: El máximo número de tarjetas HBA de FC soportadas por un servidor

ESXi es de ocho. También, el número máximo de CPUs lógicas por servidor
ESXi 5 ha aumentado a las 160 por host.

Si aún tienes servidores ESX en tu entorno virtual y necesitas aplicar parches

en el Service Console del ESX, debes de asegúrate de aplicar dichos parches
solo y únicamente cuando VMware haya hecho público las actualizaciones y
siempre que sea sugerido por personal autorizado de VMware o por el
equipo experto de VMware llamado VMware Security Advisories.

Para poder recibir alertas de seguridad sobre vulnerabilidades del software

de VMware, puedes suscribirte en esta dirección: www.vmware.com/security
Tipos de almacenamiento soportados en VMware vSphere™ ESXi versus
funcionalidad

En la tabla adjunta, se muestran los cinco tipos de almacenamiento

soportados en VMware vSphere™ ESXi 5, así como las diferentes
funcionalidades soportadas por cada tipo de almacenamiento.

Con relación a la conectividad iSCSI y su iniciador de software iSCSI, el

máximo número de iSCSI targets es de 265. Asimismo, no es posible crear
más de un NIC Teaming con el iniciador de software iSCSI con más de 8
vmnics (uplinks o tarjetas de red físicas disponibles en el servidor ESXi). Solo
es posible tener un número máximo de ocho caminos por LUN para los
volúmenes VMFS conectados via software o hardware iSCSI.

En cuanto al tamaño máximo de un volumen VMFS para la versión 3 (VMFS-

3) es de 2TB menos 512Bytes de espacio con un block size de 8MB. Sin
embargo, en VMFS versión 5 (VMFS-5) el tamaño del block size es de tan
solo 1MB, aunque es posible crear ficheros .vmdk con un tamaño máximo de
2TB. Recuerda que en VMFS versión 3 y con un block size de 1MB, el tamaño
de disco de la máquina virtual (.vmdk) no podrá superar los 256GB de
espacio en disco.

Asimismo, el tamaño máximo para un volumen RDM (de las siglas en inglés
Raw Device Mapping) en VMFS-5 es de 64TB, siempre y cuando uses la
funcionalidad de extenders a nivel VMFS, de la cual hablaremos más adelante
en este libro, y el modo de compatibilidad de este RDM sea físico. Sin
embargo, para un volumen RDM VFMS-5 en modo de compatibilidad virtual,
el tamaño máximo es de 2TB menos 512 bytes.

VMware vSphere™ ESXi 5 usa el protocolo NFS versión 3 para comunicarse

con cabinas de tipo NAS. Nota que aunque NFS también puede usar la
versión 4, esta no está soportada por VMware. En la versión VMware
vSphere™ ESXi 5, ahora es posible montar hasta 256 volúmenes NFS por
host.
VMware vSphere™ ESXi 6, ahora soporte NFS versión 4.1!.

Con relación a los ficheros swaps de las máquinas virtuales, el tamaño

máximo que puede alcanzar este tipo de ficheros es de 1TB por máquina
virtual, siempre y cuando, configures tu máquina virtual con 1TB de memoria
RAM.

Puedes ver más información sobre la configuración del block size en VMFS-
5 en nuestro curso online vmware gratutio:

http://www.josemariagonzalez.es/curso-online-gratuito

En cuanto al número máximo de targets que un servidor host puede ver con
un adaptador Broadcom 10GB iSCSI es de 128 targets. El número máximo
de tarjetas 1GB Ethernet Broadcom (bnx2) que un servidor host ESXi puede
tener es de 16.

Aviso: El número máximo de caminos por LUN de FC es de 32. Y si te pica la

curiosidad por saber cuál es el número máximo de ficheros que puedes tener
en un volumen VMFS-5, es de 130.690 ficheros, aunque me temo que muy
probablemente no alcances nunca ese límite. En VMFS-3 el máximo número
de ficheros era de 30.720 ficheros.

Diagnosticando un problema en vSphere

Para poder diagnosticar un problema con vSphere ESXi, necesitas exportar

los logs.

Desde el vSphere Client, selecciona File > Export > Export System Logs.
Ten en cuenta el tamaño requerido para almacenar estos logs, sobre todo si
cambias el nivel de lo que quieres que se logee en tu sistemas. Para ponértelo
en contexto, los logs pueden llegar a crecer hasta 9GB en una instalación de
10 ESXi y aproximadamente 100 máquinas virtuales con respecto al nivel
estándar de logeo.

También, y si no tienes configurado un servidor de vCenter, puedes

conectarte directamente a tu host ESXi y exportar los logs seleccionado la
opción, File > Export.
Capítulo 3. Red en vSphere™

La funcionalidad de red en una infraestructura virtual es de suma importancia.

Permite que las máquinas virtuales en un servidor VMware vSphere™
ESXi puedan comunicarse con otras máquinas físicas o máquinas virtuales en otros
servidores VMware vSphere™, mediante la configuración de los virtual switches.
También te permite comunicarte con el Management Network de los servidores
VMware vSphere™ para poder gestionarlos y con el VMkernel para poder
configurar vMotion y cabinas de almacenamiento basadas en protocolos NFS o
iSCSI.

En este capítulo te enseñaré a entender el propósito general de un virtual switch y

un distributed virtual switch, cómo configurarlos y conectar uplink ports, así como a
entender las diferentes configuraciones y políticas de seguridad que se pueden
definir a nivel de virtual switch, port group o ambas.

Diferentes tipos de port groups en vSphere™ ESXi

Un virtual switch estándar (VSS) tiene tres funciones principales:

1. Comunicar con máquinas virtuales dentro de un mismo servidor VMware ESXi o

con otras máquinas físicas o máquinas virtuales en otro servidor VMware ESXi,
para lo que utilizamos un Virtual Machine Port Group.
2. Comunicar con nuestro servidor ESXi via SSH (puerto 22) o vSphere Client,
para lo que utilizamos un Management Network Port.

3. Comunicar con el VMkernel y puertos IP de tipo VMotion, NFS e iSCSI, para lo

que utilizamos un VMkernel Port.

A diferencia de los switches físicos, no es posible conectar dos virtual switch juntos
mediante un ISL (InterSwitch Link Protocol), ni puedes mapear la misma tarjeta de
red a más de un virtual switch a la vez. Recuerda que sí es posible configurar un
virtual switch sin ninguna tarjeta de red, lo que es denominado como internal
switch only.

Cuando creas un NIC teaming (una o más tarjetas de red mapeadas a un virtual
switch para incrementar el ancho de banda o dotar de alta disponibilidad a la capa
de red), todas las tarjetas de red dentro del teaming pasan a ser activas por defecto.
Para crear virtual switches puedes usar el vSphere Client o, desde la consola del
servidor ESXi, puedes usar el comando: esxcfg-vswitch -a "nombre vswitch".

Si hay dos máquinas virtuales conectadas a dos virtual switches diferentes, el

tráfico entre dichas máquinas fluirá a través de las tarjetas físicas mapeadas a los
switches virtuales y entre servidores ESXi. Por el contrario, si varias máquinas
virtuales están conectadas al mismo VSS del mismo servidor ESXi, los paquetes no
salen por la red, sino que son transmitidos internamente en el servidor ESXi por el
VMkernel.

Para mejorar el rendimiento de red de las máquinas virtuales es posible mapear

más de una tarjeta física (uplink) al VSS.

Aviso: También es posible configurar switches distribuidos virtuales (Virtual

Distributed Switch). La configuración de los switches distribuidos (VDS) es
almacenada en el servidor vCenter a diferencia de los switches estándar, los cuales
almacenan la configuración en los servidores ESXi. Un Virtual Distributed Switch
no es más que un VSS que es compartido entre múltiples servidores VMware
vSphere™ ESXi. Los VDS solo están incluidos en la versión Enterprise Plus.

Port groups y el virtual switch estándar

En vSphere™ ESXi 5, el número máximo de puertos soportados para un VSS es de
4088. A este vSwitch, puedes conectar ninguno, uno o más de un uplink.

Recuerda que es posible cambiar el número de puertos en los VSS siempre que sea
necesario. Sin embargo, dicho cambio requiere un “reboot” del servidor ESXi para
que los cambios tengan efecto.

Los port groups de tipo Management Network, Virtual Machine y

VMkernel pueden todos ser configurados en un único VSS. Asimismo, sólo un
VLAN ID puede ser especificado por port group pero múltiples port groups pueden
especificar el mismo VLAN ID.

Es posible también garantizar un mínimo de servido o ancho de banda a todas y

cada una de tus máquinas virtuales. Para ello, puedes usar una técnica de gestión
de recursos llamada Traffic shapping, a nivel de port group, donde está incluida la
máquina virtual para aliviar problemas de congestión de red o garantizar un ancho
de banda determinado. Esta funcionalidad para los VSS te permite limitar el ancho
de banda desde la máquina virtual hacia afuera (outbound) pero no desde fuera
hacia la máquina virtual (inbound).

Si precisas tener que limitar el ancho de banda desde fuera hacia dentro y desde
dentro hacia afuera (outbound y inbound) tendrás que usar los switches
distribuidos (VDS). Recuerda que este switch distribuido se crea en el vCenter
Server, con lo que para usar VDS, aparte, debes de contar con una licencia de
vCenter.

Por defecto, y para los VSS, cuando creas un virtual switch por defecto es creado
con 120 puertos. Sin embargo, si utilizas la línea de comando y ejecutas
el comando “esxcfg-vswitch –l” verás que en realidad son 128 puertos.

Estos ocho puertos son puertos extra que usa el VMkernel internamente y que no
podemos usar desde la GUI. Estos ocho puertos extras solo pueden verse desde la
línea de comando en ESXi:
Aviso: Es posible que tengas la necesidad de limitar el ancho de banda en los
diferentes tipos de conexiones descritas anteriormente, y sobre todo, que tengas
que aliviar problemas de cuellos de botella en la capa de red. En capítulos
posteriores cubriremos algunas técnicas para aliviar cuellos de botella en los
diferentes componentes de vSphere 5.

Diferentes tipos de virtual switch en vSphere™

Cada virtual switch, es una representación lógica vía software de un switch físico de
capa dos. Los tres tipos de virtual switch que puedes crear en un servidor ESXi son
los siguientes:

1. Internal switch only. Este switch es usado únicamente para conectar, vía red, las
máquinas virtuales instaladas en el mismo servidor VMware ESXi, las cuales no
necesitan conexión con el mundo exterior.

2. Virtual switch con un adaptador de red. Este switch es usado para conectar, vía
red, máquinas virtuales, Management Network (gestión) y puertos VMkernel con el
mundo exterior, o dicho de otro modo, con otros servidores y máquinas virtuales
de nuestro entorno virtual.

3. Virtual switch con más de un adaptador de red. Este switch es usado para
conectar, vía red, máquinas virtuales, Management Network y puertos VMkernel con
el mundo exterior con una funcionalidad adicional, como es el balanceo de carga y
redundancia a fallos en los componentes de red.

Las políticas de seguridad y de traffic shaping son configuradas a nivel de port group
y vSwitch. Una configuración incorrecta del traffic shaping afectaría no sólo al
tráfico de las máquinas virtuales sino también al tráfico en general.
En vSphere™ ESXi, una tarjeta mapeada a un switch virtual puede ser configurada
para trasmitir y recibir tramas “Jumbo Frame”. El MTU (Maximum Transmision
Unit) de un ”Jumbo Frame” es de 9000. VMware ESXi también soporta “Jumbo
Frames”, tanto en los VSS como en los VDS.

Ahora, también es posible activar desde la GUI de los VSS el uso de los mismos. La
configuración de Jumbo Frames es considerada una mejor práctica para las redes
de tipo iSCSI, vMotion y Fault Tolerance.

Aviso: Los tres tipos de virtual switch pueden soportar hasta un total de 4088
puertos por switch virtual estándar.

Para los tres tipos de virtual switch, no existen colisiones de red en el tráfico
interno. Asimismo la dirección MAC de los adaptadores de red conectados a los
virtual switches no será usada en ningún momento de forma interna.

Las políticas de balanceo de carga en un VSS en vSphere™

En VMware vSphere™, el adaptador NIC físico conectado al primer puerto de

Management Network es denominado vmk0. El primer puerto de gestión definido
en nuestro servidor VMware ESXi es denominado "Management Network".

La configuración de las políticas de balanceo de carga en un NIC teaming y para un

VSS son tres:

 Route based on the originating virtual port ID

 Route based on source destination MAC hash

 Y Route based on IP hash

Sin embargo, las políticas de balanceo de carga para un NIC teaming en un VDS
incluye otra política adicional llamada Route Based on physical NIC load como
veremos más adelante.

Aviso: En una configuración de NIC teaming a nivel de VSS, es muy importante

activar la opción Notify Switches. Cuando configuras una política de NIC teaming en
un VSS y seleccionas la opción Notify Switches, el switch físico será alertado cuando
la localización de una tarjeta virtual cambia de puerto. Esto ocurre, por ejemplo,
cuando se hace una migración de una máquina virtual en caliente con vMotion.

Propiedades de los adaptadores de red en VMware ESXi

Para ver las propiedades de tus tarjetas de red, selecciona el servidor ESXi en el
panel inventario, luego en la pestaña Configuration, selecciona el enlace Networking
en la parte Hardware y luego Properties en el switch virtual que tiene conectado el
adaptador de red que quieres modificar.

Existe nueva tecnología en vSphere™ ESXi que puedes usar para incrementar el
throughput de tus máquinas virtuales es el Split RX como veremos más adelante.

Si estas usando adaptadores de red Gigabit Ethernet, es considerada una mejor

práctica dejar la velocidad y la configuración de dúplex en auto negotiate ya que el
auto negotiate es parte del estándar en redes Gigabit Ethernet.

Aviso: Para configurar NetQueue, y mejorar así el rendimiento de red de las

máquinas virtuales en un servidor ESXi, es necesario habilitarlo en el driver de la
tarjeta física y en las opciones avanzadas del VMkernel. Si el rendimiento de la
consola remota para una máquina virtual es lento, verifica la configuración (speed,
duplex) de la tarjeta física asignada al port group del switch virtual.

Los diferentes tipos de políticas de seguridad en vSphere

En los VSS, hay tres tipos diferentes de políticas de seguridad: Traffic shaping
Policy, NIC Teaming Policy y Security Policy. En un Virtual Distributed Switch,
aparte de estas tres políticas de seguridad, existe otra nueva, Port Blocking Policy.

Las políticas pueden ser definidas a nivel de virtual switch, las cuales se convertirían
también en las políticas por defecto para todos los port groups creados en dicho
virtual switch, o a nivel de port group.

Las políticas definidas a nivel de port group, siempre sobrescriben las políticas
definidas a nivel de virtual switch. Un vSwitch o vSwitch port group en "Promiscuous
Mode" permitirá que una máquina virtual pueda "escuchar" todo el tráfico
contenido en ese VSS y no solo el tráfico destinado para esta máquina virtual en
concreto.

Una mejor practica en la capa de red con vSphere™ es que antes de crear los
diferentes tipos de switches virtuales, protocolos de balanceo de carga, VLANs,
port groups y NIC teaming, hables con el administrador de tu red física sobre lo
que necesitas a nivel de red virtual.

Es muy corriente implementar IP hash a nivel de red virtual en entonos de

producción relativamente importantes para luego darse cuenta que no está
funcionando correctamente porque no se ha activado en el switch físico.

La configuración predeterminada en vSphere™, dentro de la política de seguridad

Security

La configuración predeterminada para la política de seguridad Security y para todos

los VSS es la siguiente:

Promiscuous Mode: Reject - Significa que el virtual switch no redireccionará

ninguna trama a otros puertos del switch (modo switch). Si Promiscuous Mode es
cambiado a Accept, el switch se comportaría como un HUB y redireccionará todas
las tramas entrantes y salientes a todos los puertos del virtual switch.

Esta configuración suele ser útil cuando "pinchamos" un sistema IDS (Intrusion
Detection System) o sniffer en un virtual switch para analizar todas las tramas de
dicho switch.

MAC Address Changes: Accept - Significa que el virtual switch no haría un drop de
la trama entrante si la dirección MAC de ésta no coincide con la dirección MAC de
la máquina virtual conectada en ese port group. Por defecto, esta opción se suele
cambiar a Reject para evitar ataques tipo MAC spoofing.

Forged Transmit: Accept - Significa que el virtual switch no haría un drop de la trama
saliente si la dirección MAC de ésta no coincide con la dirección MAC de la
máquina virtual guardada en el fichero de configuración (.vmx) de dicha máquina
virtual. Por defecto, esta opción se suele cambiar a Reject para evitar ataques tipo
MAC flooding y MAC spoofing.

En resumen, Forged Transmit permite a una máquina virtual transmitir paquetes

(outbound) que contienen una dirección MAC diferente a la que se ha definido en
esa máquina virtual.

Recuerda que las políticas de seguridad de red a nivel de VSS y port group son
Reject (Promiscuous Mode), Accept (MAC address Changes) y Accept (Forget
Transmit).

Aviso: No cambies la configuración por defecto de MAC Address Changes ni Forged

Transmits si tienes configurado en el virtual switch un clúster Microsoft NLB
(Network Load Balancing) en modo unicast.

Para ver más información sobre la configuración determinada con Microsoft NLB,
ver el KB número 1556 en la página de VMware: http://kb.vmware.com

Asimismo, cuando tengas que hacer una conversión P2V - de las siglas en inglés
Physical to Virtual - con el software de conversiones de VMware llamado
vConverter, asegúrate de configurar Allow Mac Adress Changes en Accept, si el
servidor físico que estas intentando convertir tiene software instalado que fue
licenciado usando la dirección MAC de su tarjeta física.

La configuración predeterminada, dentro de la política de seguridad de Traffic

Shaping

Esta política de seguridad de traffic shaping, para el vswitch y port group, está
desactivada por defecto. Con la opción network traffic shaping puedes limitar el
outbound peak bandwidth y el outbound average bandwidth.
Esta política de traffic shaping solo se aplica a las conexiones de dentro hacia fuera
(outbound), es decir, desde dentro del virtual switch hacia fuera del virtual switch.

No es posible definir una política de traffic shaping desde fuera del virtual switch
hacia dentro (inbound) en un VSS.

Una primera alternativa para limitar el tráfico de tipo inbound es la de usar algún
sistema externo de balanceo de carga o activar la opción de rate-limiting en tu
router físico.

La segunda alternativa la encontramos en los VDS. En los Virtual Distributed

Switches es posible definir el Traffic Shaping en ambas direcciones (Ingress -
inbound y Egress - outbound).

En vSphere™ hay dos formas de migrar una máquina virtual desde un vSwitch
estándar a un Virtual Distributed Switch.

La primera opción es seleccionando un dvPort group desde las propiedades de la

configuración de red de la máquina virtual, y la segunda, seleccionando la máquina
virtual desde la lista de máquinas virtuales cuando usas la opción "Migrate Virtual
Machine Networking".
Una nueva funcionalidad en los VDS de la versión ESXi 5 es la de habilitar la opción
de NetFlow. Esta opción te permitirá mandar tráfico de red desde un VDS a una
máquina virtual, la cual si tiene un software de análisis de red podrás hacer un
estudio muy exhaustivo de tu red de datos y del tipo de tráfico enviado por tu red.

Para terminar con las diferencias entre un VSS y un VDS, estas son las tres
funcionalidades más importantes que están disponibles en los VDS y no en VSS:

 NetFlow Monitoring

 Network I/O Control

 Egress Traffic Shapping

Cuando creas un dvPort group, el port binding dinámico (Dynamic Binding) se
asegura de asignar un puerto a la máquina virtual la primera vez que es encendida.

Recuerda que si usas un uplink que ya está previamente en uso en un VSS para
crear un VDS, las máquinas virtuales que estuvieran usando ese uplink perderán la
conectividad.

Aviso: Ten en cuenta que el Average Bandwidth y Peak Bandwidth son medidos en
Kbps, mientras que el Burst Size es medido en KB.

De la misma manera se mide en los Virtual Distributed Switch. Asimismo, recuerda

que el máximo número de VDS por servidor de vCenter es de 32.

Arquitectura de un Virtual Distributed Switch

Como he mencionado anteriormente, el VDS se crea en el servidor de vCenter y se

gestiona desde ese mismo servidor de vCenter.

Existen tres métodos a la hora de crear un port groups en un Virtual Distributed

Switch:

1. El adaptador de red con la configuración del port group puede ser asociado con
un port group existente en un Virtual Distributed Switch.
2. El port group también puede ser migrado desde un virtual switch estándar a un
VDS y viceversa.

3. Un adaptador de red con la configuración de un port group puede ser creado

durante la instalación de un Virtual Distributed Switch.

Una mejor practica de VMware es la de usar VDS en lugar de VSS ya que los
swithes distribuidos ofrecen algunas funcionalidades Enterprise que no están
incluidas en los VSS.

Naturalmente tendrás que evaluar el coste adicional asociado al uso de los VDS ya
que solo es posible configurar VDS si tienes la licencia Enterprise plus.

La configuración predeterminada en vSphere™, dentro de la política de seguridad de

NIC Teaming.

Para la política de seguridad de NIC Teaming, existen cuatro opciones en el

algoritmo de load balancing a seleccionar: route based on the originating virtual
port ID (por defecto), route based on ip hash (es necesario etherchannel), route
based on source MAC hash y explicit failover order. Recuerda que las políticas de
load balancing para el Virtual Distributed Switch son las mismas, más una extra
adicional.

Para habilitar el NIC teaming es necesario conectar más de una tarjeta de red física
a un único virtual switch o virtual distributed switch.

Si la opción "explicit failover order" no es elegida como algoritmo de balanceo de

carga en un virtual switch con múltiples uplinks (NIC teaming) y una de las tarjetas
físicas del teaming “se cae", el VMkernel verifica el contador "reported uptime" de
las otras NICs para asignar una NIC del teaming y proceder al failover.
Beacon Probing se usa en vSphere™ para detectar e identificar fallos en el enlace
upstream. Es muy útil en entornos Blade y en donde tenemos Spaning Three
Protocol activado en nuestra red física. De esta forma podremos detectar fallos de
red en los caminos alternativos.

En un VSS con un port group de tipo Management Netowrk y un port group tipo
VMkernel, y mapeas dos uplinks al VSS, es posible separar el tráfico de gestión y
del trafico VMkernel seleccionando la política de balanceo "Explict Failover order".

Asimismo, es posible ver más información sobre la configuración actual de los VSS
con el siguiente comando desde la consola de servidor ESXi:

Algunos máximos y mínimos importantes de red en VMware vSphere™ ESXi

Éstos son algunos de los máximos y mínimos en la capa de red para VMware
vSphere™ ESXi 5:

 256 es el número máximo de port groups ephemeral por vCenter.

 256 es el número máximo de port groups por switch virtual estándar (VSS de
las siglas en ingles virtual switch standard).

 5.000 es el número máximo de port groups estáticos por instancia de

vCenter.

 5.000 es el número máximo de puertos virtuales en switches distribuidos

por vCenter.

 4.088 es el número máximo de puertos de red en los VSS.

 350 es el número máximo de servidores ESXi 5 que puedes conectar por

VDS.

 32 es el número máximo de VDS por instancia de vCenter.

 4096 es el número máximo de puertos virtuales de red por host (VSS y

VDS).

 1.016 es el número máximo de puertos activos por host (VSS y VDS).

 24 es el número máximo de tarjetas de 1GB Ethernet (e1000e Intel PCI-e)

por host.

 32 es el número máximo de tarjetas de 1GB Ethernet (e1000e Intel PCI-x)

por host.

 24 es el número máximo de tarjetas de 10GB Ethernet (NetXen) por host.

 8 es el número máximo de tarjetas de 10GB (ixgbe) por host.

 4 es el número máximo de iniciadores de hardware iSCSI Broadcom de

10Gb por host.

 512 es el número máximo de máquinas virtuales por host.

Aviso: En cuanto a las diferentes tarjeterías de red y sus combinaciones, VMware

vSphere™ ESXi 5 soporta un máximo de seis tarjetas de 10GB y cuatro de 1GB en
un mismo host.
La importancia de VLANs en vSphere

La configuración de VLANs en un entorno virtual con vSphere mejora la seguridad

de nuestra solución de virtualización.

Para la implementación de VLANs, los servidores VMware ESXi usan una

metodología llamada port group policies. Para conectar una máquina virtual en un
virtual switch con una VLAN, debes usar el vSphere Client. Como vemos en la
imagen de arriba, la red VM Network es la que ha sido configurada con un VLAN
ID.

Si no configuras VLANs, las máquinas virtuales que estén mapeadas en cualquier

port group del virtual switch podrán ver todo el tráfico.
Capítulo 4. Almacenamiento en vSphere™

El almacenamiento es, sin duda, uno de los pilares más importantes de una solución
de virtualización. Es un componente crítico para poder dotar a nuestro entorno de
un plan de contingencia a fallos, alta disponibilidad y migración de máquinas
virtuales entre servidores VMware vSphere™ESXi.

Zoning, LUN Masking y el uso de VAAI en vSphere™

La configuración de la zona a nivel del fabric de fibra es un mecanismo muy usando

tanto para entornos físicos de SAN FC como para entornos virtualizados con una
red de SAN FC.

El Zoning se hace a nivel de switch de fibra para restringir las conexiones de los
servidores ESXi o servidores físicos a la cabina de datos y prevenir que otros
servidores destruyan los datos en los volúmenes.

LUN Masking se puede hacer en dos niveles: a nivel de procesadores de datos (en
Ingles SP - Storage Processors) y a nivel de servidor ESXi. Aunque, en la actualidad
el LUN Masking se suele hacer más a nivel de SP, también es posible hacerlo a nivel
de servidor ESXi sobre todo cuando usamos Boot From SAN(BFS).

Asimismo en los switches de FC de nueva generación también es posible hacer

LUN Masking.
BFS puede llegar a ser útil para configuraciones diskless en servidores tipo Blade.
Cuando estás haciendo BFS, la LUN FC desde donde arranque el servidor ESXi,
deberá ser solo visible para ese servidor. Los otros DataStores VMFS, deberían ser
visibles a todos los servidores ESXi.

Asegúrate siempre de que cambies tu configuración de la zona del fabric de FC o

las propiedades de las LUNs, hacer un rescan de tu fabric a nivel de centro de
datos. De esta forma te aseguras que todos los servidores tienen la última
configuración de tu SAN.

Desde VMware vSphere™ 4, aparecieron APIs por doquier, lo cual ha permitido

evolucionar el producto a nivel de almacenamiento con características muy
innovadoras. Una de las APIs más importantes, y que ya apareció en la versión 4.1,
es la vSphere APIs for Array Integration, también conocida por el acrónimo VAAI.

En consecuencia, una cabina con soporte VAAI para la nueva versión de VMware
vSphere™ ESXi tendrá un mayor rendimiento en las siguientes operaciones:

Write Same/Zero nos ayuda a eliminar I/O en tareas repetitivas y disminuir el

consumo de CPU, por ejemplo, la clonación masiva o el aprovisionamiento de
máquinas virtuales.

Fast/Full Copy nos permite realizar Storage vMotion sin tráfico en la red o las
HBAs, ya que lo realiza la cabina SAN. La duración de la migración disminuye en un
25%, según datos proporcionados por EMC.

Hardware Offloaded Locking es una gran funcionalidad. Hasta ahora las reservas
SCSI que se realizan sobre un datastore VMFS se realizan a nivel de LUN, por
tanto, en un momento dado, solo una máquina virtual puede acceder a la LUN en
algunas tareas, con Hardware Offloaded Locking el bloqueo se realiza a nivel de
bloque no de LUN. Esto nos permitirá aumentar el número de máquinas virtuales
por datastore en nuestros diseños y disminuirá el tiempo de creación de
datastores VMFS y NFS.

Thin Provisioning Stun evita que nos quedemos sin espacio en disco poniendo la
máquina virtual en pausa hasta que consigamos disco. Esta situación, puede llegar
a ocurrir si aprovisionamos en modo Thin y necesitamos más disco del que
tenemos.

VAAI está activado por defecto en vSphere™ ESXi 5 a partir de la licencia

Enterprise. Por supuesto, ni que decir tiene, la cabina de datos también tiene que
soportar VAAI.

Para terminar con VAAI, una cabina con soporte VAAI y con el uso de thin
provisioning ofrece la posibilidad de “reclamar” espacio cuando una máquina
virtual es migrada a un datastore diferente con Storage vMotion o cuando el disco
virtual es borrado.

Con el vSphere Client y desde la pestaña Storage Views podrás ver información
muy interesante relativa a tus datastores VMFS, como por ejemplo:

 El estado del algoritmo de multipathing para tus datastores

 El espacio usado en tus datastores

 Y un montón de otras cosas interesantes relativas a la configuración de tu

datastore
¿Cómo mostrar más información de los volúmenes o datastores en vSphere™?

Para obtener más información sobre los DataStores VMFS, como, por ejemplo, el
estado del Multipathing actual y el espacio usado, selecciona la pestaña Storage
Views.

El Runtime Name, para un dispositivo de almacenamiento en FC, equivale al

nombre de la ruta del dispositivo en formato vmhba:C:T:L, donde C es Controler, T
es Target y L es LUN.

El seudo name vmhba32 es el nombre que el VMkernel utiliza para los iniciadores
software iSCSI. Recuerda que tanto el adaptador de software iSCSI como el
adaptador dependent hardware iSCSI necesitan un port group tipo VMkernel para
ser configurados del todo.

Si usas una adaptador de tipo dependent hardware iSCSI para tu conexión iSCSI, es
posible que el rendimiento de las tarjetas de red asociadas con este adaptador
muestren muy poca actividad, incluso cuando el trafico via iSCSI es muy alto. Esto
es consecuencia directa de que el trafico iSCSI hace un bypass del trafico normal
de red y no se verá reportado por las herramientas internas de monitorización de
red del servidor ESXi (esxtop).

Asimismo, para obtener un mejor rendimiento iSCSI con adaptadores de tipo

dependent hardware iSCSI es una mejor práctica habilitar la opción de flow control.
Flow control está habilitado por defecto en todas las tarjetas de red en los
servidores ESXi 5. Es posible deshabilitar flow control. Puedes ver el KB 1013413
en el siguiente enlace para deshabilitarlo: http://kb.vmware.com/kb/1013413
Presentando LUNs FC a los servidores vSphere™

La buena noticia es que el módulo para el adaptador de fibra es reconocido por el

VMkernel durante la secuencia de arranque, con lo que si el Zoning está bien
configurado, no deberías de tener mayor problema en ver tus LUNs de FC.

Para acceder a las nuevas LUNs, no es necesario hacer un reboot del servidor ESXi.
Las nuevas LUNs serán descubiertas por los servidores ESXi siempre que se
realice un Rescan en cada servidor vSphere ESXi o desde el objeto de inventario
DataCenter.

Adicionalmente, cuando elimines un DataStore de un servidor ESXi, realiza un

Rescan en todos los servidores ESXi para actualizar los cambios. Desde la versión
vSphere™ 4.x, se incluye una opción de Rescan centralizado para buscar cambios en
la granja de SAN de todos los servidores ESXi incluidos en el mismo objeto de
inventario de tipo DataCenter.

QLA es el nombre corto del módulo del driver Linux para una HBA del proveedor
Qlogic.

LPFC es el nombre corto del módulo del driver Linux para una HBA del proveedor
Emulex.

Recuerda que las HBAs tiene un número identificativo único y global llamado
World Wide Nane, también conocido con el acrónimo WWN.

Como en la parte de configuración de red, es una mejor práctica que antes de

configurar la parte de SAN en tu entorno virtual, hables con tu administrador de
SAN sobre tus necesidades en cuanto a la capa de almacenamiento se refiere.

Algunos de los temas que deberías de tener claro y preguntar a tu administrador

de SAN antes de implementar el almacenamiento en tu entorno virtual incluyen lo
siguiente:

El tamaño necesario de tus LUNs

I/O bandwidth que requieren tus aplicaciones virtualizadas

El tamaño de la cache, zoning y LUN masking de tu fabric de SAN

La configuración del multipathing en ESXi, es decir, si es una cabina activa/activa,

activa/pasiva o activa/activa con soporte ALUA.
Aviso: El número máximo de HBAs soportadas en vSphere™ ESXi 5 ha aumentado
de 8 tarjetas HBAs por host ESXi 5 a 16. Asimismo, el número máximo de targets
por HBA de FC es de 256.

¿Cómo se configura el iniciador software iSCSI en vSphere™?

Una SAN de tipo iSCSI consiste de una cabina de datos con conexiones tipo iSCSI
(red de 1Gb o 10Gb Ethernet) la cual contiene una o más LUNs así como SPs. La
comunicación entre el host ESXi y la cabina iSCSI se establece a través de una red
Ethernet de datos.

iSCSI usa el IQN (iSCSI Qualify Name), donde el primer número representa el año,
mes y la organización que registró el dominio: iqn.2006-
01.com.openfiler:volume.vmware. Este nombre IQN no puede superar los 255
caracteres.

Los servidores ESXi vienen configurados, por defecto, con un iniciador de software
iSCSI. Este iniciador iSCSI transmite comandos SCSI por una red de datos. El
target, es decir, la cabina de datos iSCSI, recibe estos comandos SCSI y el SP los
procesa.

Es posible tener múltiples iniciadores y targets en nuestra red iSCSI. Y a diferencia

en las versiones anteriores, en vSphere™ 5, el iniciador de software no viene
instalado por defecto. Puedes ver el video tutorial de la instalación del iniciador de
software iSCSI en vSphere™ ESXi en nuestro curso online gratuito de VMware
en: http://www.josemariagonzalez.es/curso-online-gratuito

VMware vSphere™ utiliza CHAP (Challenge Handshake Authentication Protocol)

para ofrecer lo que se denomina Initiator authentication. Es una buena práctica
aislar la red de gestión, de la red iSCSI y de la red donde están conectadas todas las
máquinas virtuales.
Debido al hecho de que las redes IPs que usan la tecnología iSCSI no encriptan los
datos trasmitidos, es aconsejable para configuraciones iSCSI, activar la
funcionalidad de CHAP que se incluye tanto en la cabina (target) como en el
iniciador de software iSCSI en el servidor ESXi.

Si configuras el servidor ESXi con la opción de CHAP para acceder a una LUN iSCSI
y después deshabilitas CHAP en el servidor, el acceso a las LUNs iSCSI no se verá
afectado hasta que no se reinicie el servidor ESX/ESXi o la cabina iSCSI. Puedes
activar el CHAP en la pestaña General después de seleccionar las propiedades del
iniciador de software iSCSI.

Aviso: No olvides abrir el puerto 3260 en el firewall del servidor ESXi. El protocolo
iSCSI utiliza este puerto para la comunicación entre la cabina iSCSI (Target) y el
servidor ESX (iSCSI initiator).

Descubriendo recursos NFS en servidores vSphere™

Aparte de la conectividad de FC e iSCSI, es posible dotar de almacenamiento NAS,
via NFS, a tus servidores ESXi. Estos servidores ESXi acceden al servidor NFS
mediante un port group de tipo VMkernel el cual se define a nivel de switch virtual.

Para crear un DataStore NFS en un servidor ESXi necesitas saber el nombre o IP

del servidor NFS, el nombre de la carpeta compartida en el servidor NFS y el
nombre del DataStore que quieres darle.

ESXi solo soporta la versión 3 de NFS sobre el protocolo TCP. Los servidores ESXi
ganan acceso exclusivo a las máquinas virtuales creadas sobre un DataStore NFS
usando un fichero especial de bloqueo llamado .lck-xxx. En la versión 6 de VMware
ESXi, ya es posible usar NFS versión 4.1!

También, es posible activar la opción CHAP para conexiones de tipo NFS. El

protocolo CHAP bidireccional solo está soportado para los iniciadores software
iSCSI. Con el CHAP bidireccional el target verifica el iniciador software y el
servidor verifica el target. El iniciador hardware iSCSI solo soporta CHAP
unidireccional, es decir, el target verifica al servidor host.

Aviso: El uso de la funcionalidad de usuario delegado que permite acceso a un

DataStore NFS no está soportado en ESX/ESXi 4.x. Las máquinas virtuales creadas
sobre DataStores NFS tienen formato thin, a diferencia de las máquinas virtuales
creadas sobre DataStores VMFS en FC, las cuales tienen un formato thick.

Configurando multipathing con iniciadores software iSCSI en vSphere™

En vSphere™ es posible configurar el algoritmo de multipathing que viene

embebido en el VMkernel del ESXi. La idea general de este algoritmo de
multipathing es ofrecer a tus servidores ESXi caminos alternativos en caso de caída
de un switch físico, una tarjeta de red o incluso un SP de tu cabina.

Asimismo, es posible usar las opciones de multipathing para poder dotar de un

mecanismo de balanceo de carga a nuestras LUNs de datos.
Es posible cambiar el Multipathing Pluging (MPP) para uno o más datastores
aunque es siempre una mejor práctica asegúrate que tipo de MPP soporta tu
cabina confirmándolo primero en el HCL – de las siglas en ingles Hardware
Compatibiliy List - de VMware.

Puedes ver el HCL de todas las capas en una solución de virtualización en el

siguiente enlace: http://www.vmware.com/go/HCL

Cuando se usa el Multipathing Plugings (MPPs) en vSphere™, el Pluggable Storage

Architecture (PSA) ejecuta las siguientes tareas:

1. Gestiona las colas de E/S de disco de la HBA (Host Bus Adapter).

2. Descubre y elimina rutas físicas.

3. Gestiona las colas de E/S de disco en el dispositivo lógico.

Cuando configuras multipathing con iniciadores software iSCSI, debes configurar

dos port groups tipo VMkernel. Después, mapea cada port group a un uplink diferente
sobre el mismo virtual switch y selecciona el algoritmo de multipathing Round
Robin.

La idea general es, después de seguir todos los pasos siguientes, tener al
menos dos caminos por LUN activos para que de esta manera podamos aumentar,
no solo la disponibilidad con VMware multipathing sino también, el ancho de banda
de E/S de nuestros datastores en vSphere™ ESXi.

A continuación, te resumo los pasos a seguir para crear una configuración

multipathing tanto para iSCSI como para conexiones NFS en tus servidores ESXi:

Paso 1: Configura un vSwitch y habilita el Jumbo Frames

Este paso (Jumbo Frames) tienes que hacerlo desde línea comando para la versión
ESX/ESXi 4.x pues en los vswitch estándares de esta versión no tienes la opción de
hacerlo desde la GUI (si está disponible en los vswitch distribuidos). Para la nueva
versión de vSphere™ ESXi 5 ya es posible activar el Jumbo Frames también desde
la GUI para los VSS.

esxcfg-vswitch –a vSwitch1 (crea un vSwitch llamado vSwitch1)

esxcfg-vswitch –m 9000 vSwitch2 (activa jumbo frame en el vSwitch1)

Paso 2: Añade los VMkernel Ports iSCSI

Aquí, dependerá de las tarjetas de red que tengas cableadas y de las controladoras
de disco que tengas en tu cabina.

Al menos, deberías de configurar dos VMkernel Ports con dos tarjetas de red para
tener, tanto balanceo de carga con RR (de las siglas en inglés Round Robin) como
mecanismo de balanceo de carga.
esxcfg-vswitch –A iSCSI1 vSwitch1 ( crea un VMkernel port llamado iSCSI1 )

esxcfg-vmknic –a –i 10.10.1.1 –n 255.255.255.0 –m 9000 iSCSI1 (asigna una ip,

subnet mask y jumbo frames al VMkernel port iSCSI1)

esxcfg-vswitch –A iSCSI2 vSwitch1 ( crea un VMkernel port llamado iSCSI2 )

esxcfg-vmknic –a –i 10.10.2.1 –n 255.255.255.0 –m 9000 iSCSI2 (asigna una ip,

subnet mask y jumbo frames al VMkernel port iSCSI2)

Paso 3: Asigna las tarjetas de red físicas al vSwitch1

Primero, asegúrate que tienes al menos dos tarjetas de red físicas sin asignar a otro
vswitch. Lo puedes ver con este comando esxcfg-nics –l.

esxcfg-vswitch –L vmnic3 vSwitch1 (Conecta la tarjeta vmnic3 al vSwitch1)

esxcfg-vswitch –L vmnic4 vSwitch1 (Conecta la tarjeta vmnic4 al vSwitch1)

Aquí viene lo bueno. Por defecto, cuando creas un team en un vswitch las dos
tarjetas en el team se convierten por defecto en activa/activa. Para que
el multipathing ESXi funcione con el iniciador de software iSCSI debes cambiar las
propiedades del multipathing. Lo explicaré en el siguiente paso.

Paso 4: Asocia los VMkernel Ports a las tarjetas de red físicas

Antes de seguir con este paso, teclea el siguiente comando:

esxcfg-vswitch –l

Deberías de ver algo así en tu vSwitch1:

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch1 64 7 64 9000
vmnic3,vmnic4
PortGroup Name VLAN ID Used Ports Uplinks
iSCSI2 0 1 vmnic3,vmnic4
iSCSI1 0 1 vmnic3,vmnic4

Aquí, puedes ver que las dos tarjetas están asociadas en los dos VMkernel Ports.
Esto es lo que tienes que cambiar con el siguiente comando.

esxcfg-vswitch –p iSCSI1 –N vmnic3 vSwitch1 (borra el vmnic3 del VMkernel port

iSCSI1)

esxcfg-vswitch –p iSCSI2 –N vmnic4 vSwitch1 (borra el vmnic2 del VMkernel port

iSCSI2)

Para verificar que has tecleado bien los comandos anteriores, vuelve a teclear este
comando para ver la salida:
esxcfg-vswitch –l

Deberías de ver algo así:

Switch Name Num Ports Used Ports Configured Ports MTU Uplinks
vSwitch1 64 7 64 9000
vmnic4,vmnic3
PortGroup Name VLAN ID Used Ports Uplinks
iSCSI2 0 1 vmnic4
iSCSI1 0 1 vmnic3

Paso 5: Habilita el iniciador de software iSCSI

Con el comando esxcfg-swiscsi –e habilitas el iniciador de software iSCSI.

Paso 6: Muy importante: Crear el Binding de los VMkernel Ports con el iniciador de
software iSCSI

Primero, confirma el seudo-name de tu iniciador de software iSCSI. Lo puedes ver

con este comando.

esxcfg-scsidevs –a

Deberías de ver algo así:

vmhba0 mptsas link-n/a sas.5001ec90e0ba7c00

(1:0.0) LSI Logic / Symbios Logic LSI1068E vmhba1 ata_piix link-n/a ide.vmhba1
(0:31.1) Intel Corporation 631xESB/632xESB IDE Controller
vmhba32 ata_piix link-n/a ide.vmhba32(0:31.1) Intel Corporation
631xESB/632xESB IDE Controller
vmhba33 iscsi_vmk link-n/a iscsi.vmhba33() Software iSCSI

En mi caso como ves, el seudo-name de mi iniciador software iSCSI es vmhba33

Segundo, determina el nombre exacto de los VMkernel ports de tus iniciadores
iSCSI. Lo puedes ver con este comando:

esxcfg-vmknic –l

Interface Port Group/DVPort IP Family IP Address

Netmask Broadcast MAC Address MTU TSO MSS
Enabled Type
vmk3 iSCSI1 IPv4 10.10.1.1
255.255.255.0 10.10.5.255 00:50:56:7b:d8:21 9000 65535 true
STATIC
vmk4 iSCSI2 IPv4 10.10.2.1
255.255.255.0 10.10.5.255 00:50:56:7e:ae:81 9000 65535 true

En mi caso, como ves en la salida anterior, es el vmk3 y el vmk4.

Una vez que conozcas cuál es el nombre del iniciador de software iSCSI (vmhba32)
y de los VMkernel ports (vmk3 y vmk4), ya puedes hacer el binding con el siguiente
comando:

esxcli swiscsi nic add –n vmk3 –d vmhba33 (crea el binding para el vmk3 VMkernel
port con el iniciador de software iSCSI vmhba33)

esxcli swiscsi nic add –n vmk4 –d vmhba33 (crea el binding para el vmk4 VMkernel
port con el iniciador de software iSCSI vmhba33)

Para verificar que se han creado bien los binding con los VMkernel ports y el
iniciador de software iSCSI, teclea el siguiente comando:

esxcli swiscsi nic list –d vmhba33

Deberías de ver que los dos VMkernel ports están incluidos en el iniciador de
software iSCSI.

Paso 7: Conecta la cabina iSCSI a tu entorno vSphere™ ESXi

 Entra en la sección Configuration -> Storage Adapters.

 Haz click en iSCSI Software Adapter and selecciona Properties.
 Haz clic en la pestaña Dynamic Discovery.
 Clic Add.

En la sección iSCSI Server box, asegúrate de poner la IP del grupo o el IP de tu cabina

iSCSI y selecciona Ok.

Recibirás un mensaje que te pide hacer un Rescan de todas las HBAs. Dile que
estás de acuerdo y en unos minutos deberías de ver tus LUNs si estas han sido
configuradas correctamente en tu cabina y los servidores VMware vSphere™
ESXi tienen acceso a las LUNs.

Aviso: Ahora para la versión vSphere™ ESXi 5 es posible hacer el mecanismo de

port binding desde la GUI.

Entendiendo el sistema de archivos VMFS en vSphere™

vSphere™ utiliza un sistema de archivos propietario de VMware llamado VMFS -
de las siglas en ingles Virtual Machine File System- como sistema de archivos, el
cual está optimizado para ejecutar múltiples máquinas virtuales como una carga de
trabajo única (workload).

Este sistema de archivos soporta journaling, está optimizado para albergar

máquinas virtuales y soporta funciones de clustering a nivel de sistema de archivos.
vSphere™ ofrece asignación dinámica del almacenamiento mediante la
funcionalidad vStorage Thin Provisioning. VMware soporta Thin Provisioning a
nivel de sistema de archivos en VMFS pero, además, tu cabina de datos debe
soportar Thin Provisioning.

Se pueden acceder a los volúmenes VMFS a través del nombre del volumen, por el
nombre del DataStore o la dirección física: vmhba0:0:1:1. Todas las particiones
VMFS y NFS son montadas bajo el directorio /vmfs/volumes en tus servidores
VMware vSphere™ ESXi.

EL número máximo de extenders (número de LUNs que podemos unir como si de

una sola LUN se tratara) para un DataStore VMFS es de 32. Por lo tanto, el tamaño
máximo de un volumen VMFS es de 64TB menos 16K (metadata).

Los volúmenes VMFS que pueden ser "desmontados" con el comando umount son
los DataStores VMFS montados y todos los volúmenes NFS. Cuando se elimina un
DataStore VMFS desde un servidor vSphere™ ESXi, este es eliminado en todos los
servidores vSphere™ ESXi que tuvieran conectividad con el DataStore. Por eso es
conveniente, siempre que se cambia o reconfigura el acceso a los discos, hacer un
scan del fabric de fibra.

Aviso: Las LUNs (FC e iSCSI) pueden ser formateadas en VMFS-3 con diferentes
tamaños en el block size: 1MB - 256GB, 2MB - 512GB, 4MB - 1024GB y 8MB -
2048GB. Por tanto, si formateas un volumen VMFS con un block size de 4MB, el
disco virtual no podrá superar el tamaño de 1TB (menos 512Bytes). A
continuación, te muestro la tabla de los block size y el tamaño de los ficheros en
VMFS-3:

Nuevo iniciador FCoE en vSphere

Ahora, en la nueva versión de vSphere™, es posible instalar un nuevo iniciador de

software FCoE. En el año 2007, Intel anunció el proyecto Open FCoE, con el
objetivo de dar soporte de FCoE sobre adaptadores Ethernet de 10Gb en el kernel
de Linux, sin necesidad de tener que usar tarjetas específicas de FC como ocurre
con las tarjetas CNAs - de las siglas en ingles Converged Network adapters -.

Actualmente, esta iniciativa ha conseguido el respaldo de Microsoft, Red Hat, SuSe

y ahora de VMware, además de estar soportada en los conmutadores Brocade y
Cisco, así como en los sistemas de almacenamiento de EMC y NetApp.

Open FCoE está soportado en vSphere™ 5 y solo hay que activarlo como si fuera
un iniciador iSCSI, o sea activamos el “software FCoE Adapter” en la configuración
de los Storage Adapters del host ESXi nos aparecerá un dispositivo vmhba (virtual)
que encapsulará el tráfico FC en un puerto VMkernel, sin la necesidad de tener que
comprar una tarjeta CNA.

Con Open FCoE podremos, en un futuro, utilizar cualquier adaptador que soporte
Open FCoE. Por ahora la lista está limitada a adaptadores Intel X520.

Si esta iniciativa avanza y llega a consolidarse, tendremos más opciones a la hora de

escoger tarjetas con soporte FCoE.

Como siempre, si la tecnología FCoE se estandariza veremos también unos precios

mucho más competitivos que los precios de hoy en día.
Entendiendo los diferentes algoritmos de failover en vSphere™ ESXi

Como he mencionado anteriormente, Multipathing es el proceso por el que el

kernel de VMware ESXi permite el acceso continuo a una LUN en la SAN cuando se
produce un fallo en algún componente hardware: SP, switch de fibra, HBA o un
cable de fibra. Es lo que denominamos failover.

En la actualidad, VMware ESXi 5 soporta failover a nivel de HBA, switch de fibra,

cable o incluso a nivel de procesador de datos de la cabina.

Existen en la actualidad tres algoritmos de failover en vSphere™ ESXi: MRU (Most

Recently Used), Fixed (prefered path) y RR (Round Robin), siendo este último más
bien un algoritmo de balanceo de carga que de failover.

El algoritmo MRU, es seleccionado por defecto por vSphere™ para las cabinas de
almacenamiento Activa/Pasiva mientras que Fixed es seleccionado para las cabinas
de tipo Activa/Activa.

La diferencia elemental de una cabina activa/activa versus una cabina activa/pasiva

es que en las primeras los dos procesadores de datos pueden ejecutar un I/O de
disco en la misma LUN.

Sin embargo, para las cabinas de tipo activa/pasiva solo un procesador de datos
puede hacer un I/O de disco. Esto no significa que en esta configuración haya un
procesador de datos en modo standby sin hacer ningún I/O de disco. Todo lo
contrario, lo que para una LUN un SP puede estar configurado como pasivo, para
otra LUN este mismo SP puede estar configurado como activo, con lo que los dos
SP están procesando I/Os pero no a la misma LUN. Esto cambia con el uso de
ALUA, que no es más que el proceso de convertir una cabina activa/pasiva en
“activa/activa” mediante la activación, y valga la redundancia, de la interface de
interconexión interna entre los dos SPs.

Aviso: Para incrementar el rendimiento de una máquina virtual, es posible cambiar

la política de multipathing de Fixed a Round Robin para cabinas de tipo
activa/activa.
Capítulo 5. VMware vCenter Server

Posiblemente vCenter Server sea considerado el componente más

importante de una infraestructura virtual en VMware vSphere™ ESXi. Es, por
tanto, el componente que permite gestionar, centralizadamente, múltiples
servidores VMware vSphere ESXi y máquinas virtuales.

El vCenter Server añade funcionalidad en áreas tales como alta

disponibilidad (VMware HA), balanceo de carga (VMware DRS), Fault
Tolerance (FT), actualización de componentes (Update Manager) y
conversiones de físico a virtual (VMware Converter).

Asimismo, en esta nueva versión y, por primera vez, tenemos la posibilidad

de desplegar el vCenter Server en formato appliance el cual está basado en
un sistema operativo Linux. Esto te permitirá seleccionar el tipo de
instalación del servidor de vCenter, ¿Servidor Linux o servidor Windows?

¿Qué es el VMware vCenter Server?

El servidor de vCenter actúa como un único punto de administración central

en nuestro entorno de vSphere™.

El software de vCenter Server consiste en multitudes de módulos y servicios

y es instalado en un servidor (virtual o físico) con el sistema operativo
soportado Windows.

A diferencia de las versiones anteriores, vSphere™ incluye una nueva versión

de vCenter Server en modo appliance para entornos con Linux. vCenter
Server ofrece las funcionalidades Enterprise, como por ejemplo, VMware
Distributed Resource Scheduler (DRS), VMware High Availability (HA),
VMware Fault Tolerance(FT), VMware vMotion y VMware Storage vMotion.

Una sola instancia de vCenter Server soporta un máximo de 1.000 hosts ESXi
y 15.000 máquinas virtuales registradas (10.000 máquinas virtuales
encendidas). Sin embargo, en el hipotético caso que necesitaras gestionar
más de 1.000 servidores ESXi o 10.000 máquinas virtuales, tendrías que
comprar otra licencia de vCenter y conectar estos sistemas de vCenter en lo
que se denomina un group en mode Linked.

El número máximo de servidores de vCenter Server (versión Windows) que

se pueden conectar juntos (modo Linked ) entre si es de diez. Sin embargo, la
versión Linux de vCenter, vCenter Server Appliance, no soporta aun esta
funcionalidad de modo Linked. vCenter Server también puede ser instalado
en Linked Mode, en caso de querer ver el estado del servidor de vCenter para
todos los servidores en el inventario.
Asimismo para poder desplegar este appliance en tu entorno virtual tendrás
que formatear el disco y asignar un mínimo de RAM requerida para que
arranque el appliance - Ver tabla de memoria RAM para el appliance más
abajo -.

Recuerda que no es posible conectar via Linked mode dos vCenter Servers
de versiones diferentes. Por ejemplo, vCenter 4.1 y vCenter 5.0 no se
pueden conectar usando la funcionalidad de Linked mode.

Los requerimientos mínimos para vCenter Server 5 son 2CPUs de 2Ghz de

64bits, 4GB de memoria RAM mínimo y 4GB de espacio en disco duro
mínimo. vCenter Server 5 ya no soporta las bases de datos Oracle 9i ni
Microsoft SQL Server 2000.

Asimismo, el número máximo de vCenter Server que se pueden conectar con

el vCenter Orchestrator es de diez. También, el número máximo de hosts
conectados a un vCenter Orchestrator es de 1.000.

Aviso: El número máximo de máquinas virtuales que pueden conectarse al

vCenter Orchestrator es de 15.000.

Hay tres componentes adicionales al vCenter Server que pueden ser

añadidos al servidor de vCenter cuando sean necesarios:

 VMware vCenter ESXi Dump Collector

 VMware vSphere Web Client
 VMware vSphere Update Manager

vCenter Server requiere que la conectividad ODBC que se crea antes de

instalar el servidor de vCenter, sea de 64bits. Este ODBC para conectar la
base de datos con el vCenter, no es el mismo que el que se usa para conectar
tu vCenter con Update Manager. Además, la conectividad ODBC para el
servicio de Update Manager ha de ser de 32bits.

En VMware vSphere™ ESXi es posible usar VMware Update Manager -

hablaremos de este servicio más adelante en este libro - para hacer
actualizaciones del nuevo servidor vCenter Server Appliance. Recuerda que
para poder hacer estas actualizaciones, primero has de configurar el vCenter
Server Appliance para permitir actualizaciones desde la pestaña de update en
vCenter Server Appliance
Nuevas funcionalidades en vCenter Server.

Con independencia de la versión de vCenter que instales, Windows o el

appliance Linux, vCenter Server 5 instala, por defecto, los siguientes plug-ins:
VMware vCenter Storage Monitoring, VMware vCenter Service Status y
VMware vCenter Hardware Status, y uno nuevo en la versión 5 llamado Auto
Deploy.

Otra de las nuevas funcionalidades añadidas tanto en la versión vCenter

Server para Windows como para Linux, es el hecho de que no solo podemos
integrar nuestro vCenter en un dominio de directorio activo de Windows,
sino que también ahora esta soportado NIS.

Se necesita usar un sistema operativo de 64Bits, ya sea virtual,

físico,Windows o Linux, donde ejecutar vCenter Server 5.

VMware recomienda no instalar el servidor vCenter Server en un

controlador de dominio. En cuanto a la configuración IP,
también recomienda asignarle una dirección IP estática, o en su defecto,
registrar el servidor en un DNS si se usa DHCP.

Con vCenter Server podemos gestionar los siguientes servicios de una forma
centralizada: High Availability (HA), Distributed Resource Scheduler (DRS) y
Data Recovery.

VMware soporta vCenter Server en una máquina virtual. Los beneficios son
los siguientes: vCenter puede ser migrado con vMotion, es posible hacer un
backup usando vCenter Data Recovery y éste puede ser protegido con
VMware High Availability.
Los módulos VMware vCenter Update Manager, VMware vCenter Guided
Consolidation, VMware vCenter Convert, VMware Data Recovery, VMware
vCenter CapacityIQ, VMware AppSpeed Server y VMware Site Recovery
Mananger no están preinstalados cuando instalamos vCenter Server y, por
consiguiente, deben de ser instalados a posteriori.

A continuación vemos el plugin vCenter Service Status que verifica el estado

del servicio de vCenter Server. Este aspecto es muy interesante en una
configuración en modo Linked ya que es posible ver el estado de todos los
servicios de vCenter de sus respectivas instancias desde una sola consola.

Aviso: vCenter Server incluye una consola KVM (de las siglas en ingles
Keyboard, Video and Mouse) embebida en cada máquina virtual registrada en
el vCenter. El número máximo de sesiones concurrentes a la consola de una
máquina virtual es de 40.

Prerrequisitos hardware/software de vCenter Server 5

Requerimientos Hardware (Versión Windows):

 Procesador: 2 CPUs 64-bit 2.0GHz Intel o AMD x86.

 Memoria: 4GB RAM mínimo.
 Disco: 4GB recomendado.
  Red: Adaptador Ethernet (1 Gigabyte recomendado).

Requerimientos Software:

 Windows XP Pro 64-bit, SP2 y SP3

 Windows Server 2003 64-bit Standard, Enterprise y DataCenter, SP1
y SP2
 Windows Server 2008 64-bit Standard, Enterprise y DataCenter, SP2
 Windows Server 2008 R2 64-bit

Los requerimientos de procesador, memoria y disco serán más altos si la base

de datos de vCenter y Update Manager está instalada en el mismo sistema
virtual o físico.

Recuerda que el modo Linked aún no está soportado en la versión Linux

llamada vCenter Server Appliance.

Aviso: El número máximo de datastore que un vCenter puede ver es de 256.

Asimismo, el servicio de vCenter Server requiere un IP fijo y un nombre de
dominio interno registrado en tu servidor de DNS.

Quizás el componente más importante en vCenter es su base de datos.

vCenter Server 5 almacena todos los datos del inventario, estado de cada
máquina virtual y configuración de cada Servidor VMware vSphere™ ESXi, en
una base de datos relacional. Las bases de datos soportadas por vCenter
Server para Windows son las siguientes:

v Oracle
Ø Oracle 10g F2
Ø Oracle 11g
v IBM DB2 9.5 y 9.7
v Microsoft SQL
Ø SQL Server Server 2005 SP3 (recomendado SP4)
Ø SQL Server 2008 R2 Express*
Ø SQL Server 2008

*SQL Server 2008 R2 Express es solo recomendada en entornos pequeños

de hasta 5 hosts ESXi y 50 máquinas virtuales.

En cuanto a la versión Linux de vCenter Server se refiere, los requerimientos

de software son diferentes. No obstante, el usuario o administrador del
entorno virtual, no notará ninguna diferencia con el hecho de tener la versión
Windows o Linux de vCenter instalado en tu entorno.

El servicio de vCenter en modo appliance reduce el tiempo requerido para

instalar y configurar la versión de vCenter en Windows, ya que la versión
appliance para Linux viene pre-instalada.

Sin embargo, a nivel de base de datos el appliance aún no soporta SQL. A día
de publicación de este libro solo soporta Oracle y DB2 (express) como base
de datos.
vCenter Server virtual Appliance usa un kernel versión 2.6.32.29-03 de SuSe
Linux y estos son sus requerimientos:

Requerimientos Hardware (Versión Linux):

 Procesador: 2 CPUs 64-bit 2.0GHz Intel o AMD x86.

 Disco: 7GB RAM mínimo. Máximo 82GB
 Red: Adaptador Ethernet (1 Gigabyte recomendado).
 Memoria:
o De 1-10 hosts ESXi o 1-100 máquinas virtuales: 4GB mínimo
recomendado
o De 10-100 hosts ESXi o 100-1.000 máquinas virtuales: 8GB
mínimo recomendado.
o De 100-400 hosts ESXi o 1.000-4.000 máquinas virtules:13GB
mínimo recomendado.
o Para más de 400 hosts ESXi o 4.000 máquinas virtuales: 17GB
mínimo recomendado

Puedes ver el video tutorial de instalación y configuración del vCenter Server

Appliance en nuestro canal de YouTube dedicado en exclusiva a la
virtualización de sistemas en español:

El servicio vCenter Hardware Status Plug-in

Es posible monitorizar la "salud" del hardware del servidor físico ESXi. Si la

pestaña "Hardware Status" no está habilitada, comprueba que el plugin
"vCenter Hardware Status" esté habilitado.

Para hacerlo, selecciona plug-ins, Plug-in Manager. Con el botón derecho del
ratón selecciona enable.
Recuerda que para que la pestaña Hardware Status te dé más información
relativa al estado del hardware físico del servidor ESXi, el servicio "VMware
VirtualCenter Management Webservices" ha de estar arrancado.

vCenter Server y la configuración del directorio activo

Por defecto, si eliminas un usuario de tu directorio activo, el cual está

actualmente conectado al servidor de vCenter, el usuario permanecerá
conectado hasta 24 horas.
Puedes cambiar esta configuración modificando el valor de la casilla
Validation Period.

VMware vSphere vCenter Converter

VMware vSphere vCenter Converter es una herramienta gratuita que te

permitirá convertir tus máquinas físicas a máquinas virtuales e incluso sin
pérdida de servicio con las conversiones en caliente.

Es posible instalar este software en el mismo servidor de vCenter via plugin

o en modo standalone. Personalmente, prefiero la versión standalone ya que
para mi gusto ofrece una funcionalidad de logs mayor.

Para ejecutar el Converter instalado en modo plugin, selecciona uno de los

servidores ESXi donde quieras convertir una máquina física a virtual con el
botón derecho y selecciona Import Machine.

vCenter Converter, tanto la versión plugin como la versión standalone,

soporta imágenes de Symantec Ghost (.gho), Acronis True Image (.tib) ,
StorageCraft y máquinas virtuales tanto Windows como Linux de otros
productos de VMware, como por ejemplo VMware Workstation, VMware
GSX Server, VMware Fusion, VMware ESX, así como de otros proveedores
de software de virtualización, como por ejemplo, Microsoft HyperV,
Microsoft Virtual PC, Microsoft Virtual Server y Parallels Desktop.

vCenter Converter soporta conversiones de físico a virtual (P2V), de virtual a

virtual (V2V) y de imagen a virtual (I2V), pero aun no soporta conversiones
de virtual a físico (V2P). vConverter requiere tener los siguientes puertos
TCP abiertos: 139, 443, 445 y 902.

Aviso: Recuerda que vCenter Converter también se pude utilizar para

convertir máquinas virtuales de otras soluciones de virtualización, como por
ejemplo VMware Fusion, Microsoft Virtual Server, Microsoft Hyper-V y
Virtual PC, a formato VMware ESX/ESXi. Es lo que se denomina una
conversión de virtual a virtual o V2V.

vCenter Server en modo Linked Mode

Durante la instalación de vCenter Server, puedes elegir instalar vCenter en

modo "standalone" o “linked mode”. La primera instancia del vCenter ha de ser
instalada en modo standalone.

Siempre que se requiera o sea necesario, podemos cambiar el modo ( “Linked

Mode” o “standalone”) del vCenter Server.

La opción del modo “Linked mode” te permite gestionar todo tu entorno desde
un punto único central, con independencia a que vCenter server te conectes
con tu vSphere client.

No solamente este modo Linked te facilita la gestión desde una sola consola
en entornos grandes. A veces, no hay más remedio que configurar nuestros
servidores de vCenter en modo Linked.

Por ejemplo, cuando tienes que registrar más de 1.000 servidores ESXi o más
de 10.000 máquinas virtuales encendidas - este es el límite de una sola
instancia de vCenter Server 5 (versión Windows) -, necesitas modificar la
configuración de vCenter 5 y configurarlo en modo Linked Mode.

Por supuesto, está claro que necesitarás otra licencia de vCenter Server y
otra base de datos en el backend para poder emparejar las dos instancias, o
más, y superar el límite mencionado.
No es posible emparejar servidores de vCenter que no pertenezcan a un
domino. Por consiguiente, si quiere emparejar servidores de vCenter en
modo standalone, tendrás primero que incluirlos en un dominio. Los vCenters
que vas a emparejar pueden estar en dos dominios diferentes, como por
ejemplo, vmware.com y Microsoft.com. No obstante, asegúrate de configurar
una relación de confianza bi-direccional en los directorios activos de los dos
dominios para que puedan emparejarse.

Asimismo, el mode Linked se basa en gran medida en el servicio de DNS con lo

que has de asegurarte, antes de empezar el wizard de emparejamiento, que
tu servidor de DNS funciona correctamente.

Por otro lado, si tienes problemas al intentar conectar con tu servidor de

vCenter, verifica si el servicio de Windows de Virtual Center Server está
arrancado en la máquina virtual o física donde lo has instalado.

También, puede ocurrir en entornos con servidores ESX que si te quedas sin
espacio en la partición / (root), pueda causar disrupciones en la conectividad
de tu vCenter con el vSphere Client.

Para lanzar el wizard de emparejado, dentro del servidor de vCenter en

Windows, selecciona inicio > programas > vmware > vCenter Server Linked Mode
Configuration.

vCenter Server y las opciones de archivado desde la pestaña Maps

vCenter Server incluye una pestaña llamada Maps la cual puedes usar para
ver una instantánea de cómo está configurado tu entorno virtual. Esta opción
de Maps, te permite no solo exportar los mapas en diferentes formatos: JPG,
BMP, PNP, GIF, TIFF y EMF sino que ahora, en la versión vCenter Server 5,
podrás imprimirlos directamente a una impresora que tengas configurada en
tu servidor de vCenter.
Para exportar los mapas, selecciona File > Export > Export Maps. Después,
selecciona la extensión del formato de la imagen a exportar.

Desde el vCenter Maps, puedes ver otros recursos de tu entorno virtual

como por ejemplo DataStore y Host resources.

Recuerda que los iconos en los mapas son interactivos y basta con hacer un
clic con el botón derecho del ratón sobre el icono para ejecutar acciones.

El uso de los mapas también es muy interesante para comprobar si tus

máquinas virtuales son compatibles con vMotion.

En la imagen anterior, observamos que la máquina virtual con nombre AD no

puede ser migrada con vMotion al servidor ESXi2.demos.local porque no está
conectada a la red de producción, entre otras cosas.

¿Cómo añadir un servidor ESXi al inventario de vCenter Server?

Una vez que hayas instalado el servidor de vCenter (Windows o Linux) ya

podrás añadir tus servidores hosts ESXi al inventario para que estos puedan
ser gestionados y configurados.

Para añadirlos, previamente has de crear un objeto de inventario de tipo

DataCenter. Simplemente, selecciona con el botón derecho del ratón el
objeto inventario raíz - el objeto de inventario raíz del vCenter es el nombre
de red que le hayas dado a tu servidor de vCenter - y selecciona create
DataCenter.

Después de que hayas creado el objeto de inventario DataCenter,

selecciónalo este objeto con el botón derecho del ratón y elije Add Host

Luego, introduce los datos de tu servidor ESXi, nombre de host, usuario y

contraseña y selecciona siguiente.
Durante la inclusión de tu servidor ESXi al inventario de servidor de vCenter,
este enviará un agente de gestión al servidor ESXi llamado vpxa. Desde ese
momento, este agente será utilizado por el vCenter para gestionar tu
servidor ESXi.

Puede ser que no sea posible añadir un servidor ESXi al inventario y recibas
este error:

Entre las posibles razones es que haya algún problema de comunicación

entre el vCenter y el servidor ESXi o el agente de gestión del servidor ESXi
(hostd) no está funcionando correctamente.

Para asegúrate de que el agente ESXi está funcionando, entra en la consola y

ejecuta el siguiente comando:

~ # ps | grep hostd

2847 2847 hostd-worker hostd

2848 2847 hostd-poll hostd

2849 2847 hostd-worker hostd

2850 2847 hostd-worker hostd

2865 2865 nssquery /usr/libexec/hostd/nssquery

2866 2847 hostd-worker hostd

2873 2847 hostd-worker hostd

3044 3044 nssquery /usr/libexec/hostd/nssquery

3070 2847 hostd-vix-high- hostd

3071 2847 hostd-vix-poll hostd

3359 2847 hostd-hbr hostd

3360 2847 hostd-worker hostd

3361 2847 hostd-worker hostd

3362 2847 hostd-worker hostd

3475 2847 hostd-worker hostd

3476 2847 hostd-worker hostd

~#

Si este agente estuviera parado, puedes arrancarlo desde la consola DCUI de

tu servidor ESXi seleccionado F2 > Restart Management Network.

El plugin de vCenter para hacer backups de las máquinas virtuales, VMware

Data Recovery

VMware Data Recovery es un appliance basada en Linux la cual nos permite

hacer backup/restore de todas nuestras máquinas virtuales Linux o Windows,
incluso con las máquinas virtuales encendidas.

Te puedes descargar este appliance desde la página web de VMware,

siempre y cuando te hayas registrado o tengas un usuario válido. Una vez
descargado, la instalación en vCenter sigue el mismo proceso de instalación
de cualquier otro appliance basado en OVF - de las siglas en inglés Open
Virtualization Format -. Puedes ver un video tutorial de instalación de este
appliance en nuestro curso online gratuito en esta
direccion: http://www.josemariagonzalez.es/curso-online-gratuito

Aparte de este appliance, la cual es la parte servidor, has de instalar el

ejecutable VMwareDataRecoveryPlugin.msi en el sistema donde estas
ejecutando vSphere Client, el cual es la parte cliente.

Desde el menú Plugins, Manage Plugins puedes ver el Plugin Manager. Hay dos
pestañas de configuración, la pestaña Available y la pestaña Installed.

En la ventana Plugin Manager puedes hacer el "Download & install" de la parte

cliente del plugin. Sin embargo, el plugin no estará definitivamente instalado y
visible en vCenter hasta que éste no se habilite desde el Plugin Manager.

Recuerda que para usar y licenciar VMware Data Recovery has de tener
mínimo la licencia Essentials Plus.

Aviso: Para habilitar un plugin es necesario descargar e instalar el plugin

desde el servidor donde te estás conectando con el vSphere Client. Con el
Plugin Manager puedes habilitar un plugin y ver los plugins disponibles que no
están instalados.

Calculando el tamaño de la base de datos de vCenter

El tamaño de la base de datos de vCenter varía dependiendo del número de

servidores ESXi y de las máquinas virtuales que tengas registradas, pero por
cada 50 máquinas virtuales necesitarás, al menos, 700MB extra de espacio
en disco.
Desde la opción vCenter Server Setting > Statistics > Database Size puedes
crear simulacros cobre el tamaño necesario para la base de datos de tu
vCenter. Recuerda que esta opción es solo un simulacro y no cambia nada de
tu configuración.

Aviso: En la imagen anterior, la cantidad de espacio estimado es para una

base de datos SQL. Si vas a utilizar en tu entorno una base de datos con
Oracle, asegúrate de dividir por dos el valor mostrado con esta utilidad.
Capítulo 6. Máquinas Virtuales en vSphere™

Una de las formas más eficientes de desplegar máquinas virtuales es

mediante el uso y creación de plantillas (templates). Una vez que la plantilla
haya sido creada, podrás crear máquinas virtuales de una manera mucho más
rápida, automatizada y sin errores.

Otros métodos de creación de máquinas virtuales incluye la funcionalidad de

cloning, la importación de plantillas o incluso la creación de máquinas
virtuales desde una conversión de un servidor físico a virtual con el VMware
vConverter.

Los distintos ficheros que forman una máquina virtual

Una máquina virtual es un conjunto de ficheros en donde se ejecuta el

sistema operativo y las aplicaciones.

Los tres ficheros más importantes que forman una máquina virtual son: el
fichero BIOS(.nvram), el fichero de configuración (.vmx) y el fichero del disco
virtual (.vmdk).

Para poder acceder a la BIOS de una máquina virtual, presiona F2 cuando la

máquina virtual está arrancando o edita la configuración de la MV para forzar
que entre en la BIOS cuando se encienda.

Adicionalmente, los ficheros de snapshot de una máquina virtual son:

00000#-delta.vmdk, 00000#.vmdk y SnapshotNombre.vmsn.

Los ficheros con extensión .vmem corresponden a la memoria de la máquina

virtual mapeada a un fichero. Este fichero solo existe si la máquina virtual
está encendida o tiene un snapshot. Los ficheros con extensión .vmss
corresponden al fichero de una máquina virtual en modo suspendida.
El fichero VM_nombre-flat.vmdk es el que se tiene en cuenta a la hora de
determinar el tamaño apropiado para calcular el fichero de paginación en
Windows o la partición swap en sistemas Linux.

Si conviertes la máquina virtual a una plantilla, el fichero de configuración de

ésta (.vmx) es reemplazado por el fichero de configuración de una plantilla
(.vmtx).

Cuando una máquina virtual experimenta un fallo (BSOD o kernel panic en

Linux), el servidor ESXi crea un fichero core dump en el mismo directorio
donde reside el fichero de configuración de la máquina virtual. Asimismo, las
máquinas virtuales incluyen otro fichero llamado CBT - de las siglas en ingles
Change Block Tracking – el cual es usado por VMware Data Recovery para
saber cuáles son los bloques que han cambiado a nivel de máquina virtual
para solo hacer un backup de estos bloques modificados durante el último
backup.

Una mejor práctica en cuanto a la nomenclatura a usar en el nombre de las

máquinas virtuales, es intentar evitar usar caracteres especiales, como por
ejemplo, espacios.

Aviso: En vSphere™ 5 verás un segundo fichero swap con el nombre vmx-

<vm_name###>.vswp el cual contiene la cantidad de memoria overhead
reclamada por la máquina virtual. Este mecanismo ayuda a incrementar el
número del ratio de consolidación por servidor con respecto a versiones
anteriores.

Las VMware tools: ¿Qué son y cómo se instalan?

Otra muy buena práctica en cuanto a las máquinas virtuales se refiere, es la

instalación de las VMware Tools después de la instalación del sistema
operativo.
Las VMware tools se instalan como una aplicación más dentro de la máquina
virtual. Selecciona la máquina virtual desde el inventario, haz un clic derecho
con el ratón y selecciona Install/Upgrade VMware Tools.

Las VMware tools incluyen los siguientes drivers: SCSI, SVGA, ratón,
VMXNET 3 adaptador de red, Memory Control (ballooning), Filesystem Sync
y soporte para el servicio Windows: Volume Shadow Copy Services (VSS).

El driver de ballooning es también conocido como vmmemctl driver y su

principal misión es "reclamar" memoria no usada a las máquinas virtuales. La
máxima cantidad de memoria que el driver vmmemctl puede reclamar a una
MV es de un 65% de la memoria no reservada.

En vSphere™ 5, VMXNET 3, es el nombre del adaptador de red

"paravirtualizado" de alto rendimiento. Este adaptador solo está soportado
en máquinas virtuales con hardware virtual versión 8 (Las máquinas virtuales
en vSphere™ ESX/ESXi 4.x usan hardware virtual versión 7 y en vSphere™
ESXi 5 el hardware virtual es versión 8).

Asimismo, las VMware Tools mejoran el movimiento del ratón, la gestión de

la memoria y también permiten hacer shutdown de la máquina virtual desde el
menú de inventario del vCenter.

El máximo de memoria RAM que una máquina virtual puede tener

configurado en vSphere™ 5 es de 1TB. Una máquina virtual puede fallar al
encenderla, si la reserva de memoria asignada a esta máquina virtual no
puede ser garantizada por el VMkernel con lo que cuidado con hacer
reservas de memoria altas en tus máquinas virtuales.

Usa Ctrl + Alt + Ins en lugar de Ctrl + Alt + Del para entrar en la consola de
una máquina virtual.

¿Qué es un vApps y cómo crearlo en vSphere™?

Un vApp en VMware es la entidad lógica constituida por una o varias
máquinas virtuales, que utilizan el formato OVF para especificar y encapsular
todos los componentes de una aplicación multinivel, así como las políticas y
niveles de servicio asociados a la misma.

El número máximo de caracteres que puedes usar para crear el nombre de un

vApp es de 80. Este tipo de contenedores es ideal para aplicaciones
multitiered donde tenemos aplicaciones o máquinas virtuales en el backend,
front-end y en el midle-tier. De esta forma, al agrupar las distintas máquinas
virtuales en un solo vApp podemos encenderlas, apagarlas y clonarlas con un
solo clic de ratón.

Los objetos que pueden ser incluidos en un vApp son los siguientes:

 Resource Pools
 Máquinas Virtuales
 vApps, es decir, un vApp dentro de otro vApp.

Para poder crear un vApp es necesario que se cumplan las siguientes

condiciones:

1. Debes habilitar la opción de DRS en el clúster, aunque también es posible

crear un vApp en un servidor ESXi en modo standalone

2. La versión del servidor debe ser ESX 3.x o superior.

3. Debes elegir una carpeta dentro de la vista "Virtual Machine and

Templates".

Una vez que hayas creado un vApp - usa el wizard de creación de vApps
( File > New > vApp) hay tres opciones en el IP Allocation Policy para un vApp:
Fixed, Transient y DHCP. Esto indica el mecanismo que tienen las máquinas
virtuales para ser configuradas con una IP de red.

Si las opciones de vApp están deshabilitadas en las propiedades de la

máquina virtual que forma parte de un vApp, no podrás editar el IP Allocation
Policy como vemos en la siguiente imagen.
Asimismo, dentro del vApp en la pestaña de configuración Start Order,
puedes seleccionar que máquina virtual arranca antes, cual es la secuencia de
arranque del vApp y el delay en segundos que quieres configurar entre el
arranque de las máquinas virtuales.

¿Qué son los clones y plantillas y cómo crearlas en vSphere™?

Un clone es una copia exacta de la máquina virtual (mismo SID, hostname,

dirección IP, etc) y es posible hacer dicho clone mientras la máquina virtual
está encendida. No obstante, la MAC virtual de la tarjeta virtual del clone es
diferente para evitar tener más de una máquina virtual con la misma MAC
virtual.
La opción Clone to Template, crea una plantilla de una máquina virtual ya
configurada. Esta máquina virtual es marcada como plantilla y no podrá ser
encendida hasta que la plantilla sea convertida en máquina virtual (Convert to
Virtual Machine). Si precisaras actualizar una plantilla (service pack, etc),
deberás convertir la plantilla a máquina virtual, actualizarla y posteriormente
convertirla de nuevo en plantilla.

Para poder cambiar la identidad de un clone o template desde vSphere

Client, es necesario usar Sysprep, una herramienta de Microsoft incluida en
el CD del sistema operativo (deploy.cab)

No obstante, has de copiar a mano los archivos de Sysprep en el directorio

"C:\Documents and Settings\All Users\Application Data\VMware\VMware
VirtualCenter\sysprep" del servidor de vCenter. Ahí deberás ubicar los
diferentes Sysprep según las versiones de Windows que indican los
diferentes subdirectorios que existan. En caso de no copiar los ficheros de
Sysprep, no podrás hacer ninguna parametrización de clones o plantillas.

Adicionalmente, si quieres personalizar una máquina virtual Linux, has de

instalar Perl en el sistema operativo Guest.

La opción, Convert to Template, convierte una máquina virtual en plantilla. La

máquina virtual debe estar apagada. El uso de plantillas ofrece varios
beneficios fundamentales: usan menos espacio en disco y éstas no pueden
ser modificadas hasta que no se conviertan a máquinas virtuales. De igual
forma, se asegura un despliegue rápido y sin esfuerzo de las máquinas
virtuales a la vez que se estandarizan las mismas.

Cuando creas un clone o template de una máquina virtual que tiene discos
RDM en formato "Physical Compatibility Mode", la máquina virtual
resultante crea el disco RDM pero cambia el formato a "Virtual Compatibility
Mode". Recuerda que es posible hacer clones y templates de máquinas
virtuales con discos RDM.

La característica fundamental de un disco RAW en modo "Physical

Compatibility mode" es que permite al sistema operativo "Guest" acceder al
hardware directamente sin que el VMkernel haga ninguna traducción binaria
de las instrucciones.

Dos de los grandes beneficios de un disco RDM en modo virtual es que

podrás usar las funcionalidades de cloning y plantillas.

Aviso: Las máquinas virtuales que usan discos FC RDM te permitirán usar
software de clustering, agentes de gestión SAN y software SCSI dentro de la
misma máquina virtual.

El tamaño máximo de un RDM soportado en VMware vSphere™ 5 y en modo

físico es de 64TB. Las máquinas virtuales en un DataCenter pueden ser
clonadas a otro diferente, pero no pueden ser migradas con vMotion.
¿Cómo habilito o deshabilito la opción de logging en la máquina virtual?

Es posible habilitar o deshabilitar la opción de logging para un número

determinado de máquinas virtuales. Edita las propiedades de la máquina
virtual desde el vSphere Client, bajo Options, selecciona Advance y después
General.

Por defecto, la opción de logging para las máquinas virtuales está activada.
Una de las posibles razones por la que quizás quieras desactivar esta opción,
podría ser el poder maximizar el espacio disponible en los DataStores. No
confundas la opción de login con la de logging.

Hay seis archivos de log que siempre se mantienen archivados para todas y
cada una de máquinas virtuales existentes en tu entorno. Por ejemplo, de -
1.log a -6.log son los ficheros logs de las máquinas virtuales que se crearán
por primera vez cuando se cree una máquina virtual.

La próxima vez que un archivo de log sea creado, por ejemplo, cuando una
máquina virtual es apagada o encendida, ocurre lo siguiente:

 Los ficheros de -2.log a -7.log son mantenidos y el fichero -1.log es

borrado.

 Después, los ficheros -3.log a -8.log son mantenidos y así

sucesivamente.
Mejoras en la funcionalidad de vMotion en vSphere™

vSphere™ ESXi 5 permite desplegar máquinas virtuales entre diferente

centros de datos. También te permite clonar una máquina virtual desde un
centro de datos a otro.

Asimismo, es posible desplegar una máquina virtual desde una plantilla

localizada en un centro a otro centro de datos diferente.

Por ejemplo, podrías clonar una máquina virtual Windows desde el centro de
datos Data Center A al Data Center B. Sin embargo, no es posible migrar en
caliente una máquina virtual con VMotion desde un centro de datos a otro. El
error que se muestra en el vSphere Client es: "The input arguments had
entities that did not belong to the same datacenter".

Una de las mejoras de vMotion en la nueva versión de vSphere™ ESXi 5 es el

hecho de poder crear diferentes vmknics y agruparlas en un mismo VSS para
poder incrementar la velocidad de las migraciones en caliente.

Asimismo, VMware vSphere™ ESXi 5 incluye Metro vMotion. Ahora, con

Metro vMotion, no sólo tendrás un mejor rendimiento de tus migraciones en
redes con una latencia muy alta, sino que también, el RTT - de las siglas en
ingles round trip time - ha aumentado de cinco a diez milisegundos.

Antes de la versión vSphere™ 5.0, vMotion sólo soportaba

redes con latencia de ida y vuelta de hasta cinco milisegundos. Con Metro
vMotion y VMware vSphere 5.0, podrás migrar en caliente tus máquinas
virtuales cuando el host de origen y el host destino tienen una
latencia superior a 5 milisegundos.
Por supuesto, la mala noticia es que para poder disfrutar de Metro vMotion
necesitas, al menos, licencia Enterprise plus.

Configurando el Power Management en las máquinas virtuales

Las opciones de Power Management te permiten especificar como responde

una máquina virtual cuando el sistema operativo Guest es puesto en standby.

Estas opciones están disponibles para todas las máquinas virtuales. No

obstante, la opción de Wake on LAN (WOL) solo está soportado para
sistemas operativos Windows y en alguno sistemas operativos Linux y no
está disponible en las tarjetas virtuales que utilicen el driver Vlance, es decir,
aquellas máquinas virtuales en las que las VMware tools no están instaladas
en el SO Guest. Otra razón importante para instalar las VMware Tools.
Migraciones vMotion con ¿High Priority o Low Priority?

Hay dos requerimientos fundamentales para poder hacer migraciones con

VMware:

1. Los dos servidores vSphere™ ESXi 5 involucrados en la migración tienen

que estar conectados via red Ethernet Gigabyte.

2. Las máquinas virtuales deben tener acceso a las mismas subredes en los
host vSphere™ origen y destino.

VMware vMotion permite mover una máquina virtual desde un servidor ESXi
a otro. Una migración en frío (cold migration), mueve una máquina virtual
apagada y permite reubicar su disco virtual en otro DataStore. La migración
en frio (es decir con la máquina virtual apagada) pueden ejecutarse entre
CPUs de distintos fabricantes, Intel y AMD. Para migraciones con VMware
vMotion en caliente, las CPUs han de ser compatibles dentro de la misma
familia de procesador y del mismo fabricante.

Las migraciones en caliente (hot migration) pueden fallar cuando activamos

el soporte VMI Paravirtualización en la máquina virtual del host ESXi origen y
el host destino no tiene soporte para VMI Paravirtualizacion. Por cierto, no te
cuento que es VMI paravirtualización pues VMware lo ha desactivado en
esta nueva versión.

Recuerda que la migración en caliente, mueve la máquina virtual de un

servidor ESXi a otro pero no mueve su disco virtual.

Una migración con High Priority (Reserve CPU for Optimal VMotion
performance) reserva recursos en el host destino, por tanto, la migración
puede que no se ejecute si el host destino no tiene recursos suficientes.
Una migración con Low Priority (Perform with available CPU resources) no
reserva recursos en el host destino, por tanto, migraciones con low priority
siempre se ejecutan con éxito, aunque es posible que el proceso de migración
sea más largo.

Recuerda que el número máximo de migraciones en caliente con vMotion,

para una red de 1Gb/s, es de 4 migraciones simultáneas. Sin embargo, para
una red de 10Gb/s, el número de migraciones simultáneas con vMotion sube
hasta 8.

Asimismo, el número máximo de migraciones simultáneas con vMotion por

datastore es de 128.

Una máquina virtual que esté usando VMDirectPatch I/O no puede ser
migrada con vMotion. VMotion soporta máquinas virtuales con discos RDM
(Raw Device Mapping) en compatibilidad física así como discos en modo thick
o thin.

Dicho sea de paso, el disco de una máquina virtual puede ser convertido de
thick a thin mientras que la máquina virtual está encendida y usando Storage
vMotion. Asimismo, la misma máquina virtual puede ser "inflada" de thin a
thick, pero solo mientras la máquina virtual está apagada usando la opción de
inflate como muestro en la siguiente imagen:

Aumentando el rendimiento de las máquinas virtuales con Storage VMotion

Una manera de optimizar el Storage para aumentar el rendimiento de las
máquinas virtuales es a través de Storage vMotion.

En el ejemplo anterior, si la LUN de la izquierda se convierte en un cuello de

botella, todo lo que tienes que hacer es crear una nueva LUN VMFS y mover
las máquinas virtuales – en caliente - a la nueva LUN. La LUN origen y LUN
destino pueden tener una configuración RAID diferente.
Capítulo 7. Control de acceso en vSphere™

El control de acceso en vCenter Server y ESXi permite controlar el acceso a los

recursos y máquinas virtuales en un entorno virtual con múltiples usuarios de una
manera mucho más flexible y dinámica.

¿Cómo son los premisos en vSphere™?

El modelo de seguridad de vCenter (user/group, role y privilegios) y VMware

vSphere ESXi difiere del modelo tradicional de otros sistemas operativos, como
por ejemplo Windows o Linux.

En VMware vSphere™, el sistema de control de acceso permite al administrador de

vCenter definir accesos y privilegios a todos y cada uno de los objetos de
inventario visibles en vCenter.

Este sistema de control de acceso es definido de la siguiente manera:

Privilegio: La posibilidad de ejecutar ciertas acciones en vCenter como por

ejemplo, encender una máquina virtual, crear una alarma, crear un clúster y
etcétera.

Role: Es un conjunto de privilegios y una forma de agrupar todos los privilegios

individuales en una sola entidad.

Objeto: Se refiere al objeto de inventario, Resource Pool, máquina virtual,

DataCenter, carpeta, en donde se aplican los permisos.

Usuario o grupo: Se refiere al usuario o grupo que puede ejecutar una acción
determinada.
La combinación de un role, un usuario o grupo más el objeto representan los
permisos en VMware vSphere™.

Los roles predefinidos en VMware vSphere ESXi son: No Access, Read-only y

Administrator. Asimismo, si en tu entorno cuentas con VMware vCenter este
tendrá los siguientes roles definidos por defecto: Virtual Machine Power User,
Virtual Machine User, Resource Pool Administrator,VMware Consolidated Backup
User, Datastore consumer, Network consumer.

Es posible definir nuevos roles a nivel de host ESXi, aunque no es una mejor
práctica ya que estos roles creados a nivel de host no se propagan al servidor
vCenter Server por lo que es recomendable crear nuevos roles en el servidor de
vCenter. El role del vCenter Server, Virtual Machine Administrator, tiene por
defecto, privilegios de performance.

Asimismo, el role predefinido a nivel de vCenter llamado administratror puede

hacer cualquier tarea en cualquier objeto del inventario de los servidores ESXi.

Orden de prioridad de los permisos en vSphere™

Los permisos son asignados a los objetos de inventario (DataCenter, clúster,

Servidor ESX/ESXi, Resource Pool, Máquina Virtual) del vCenter, mediante la
asociación de un usuario o grupo con un role.

Si un usuario es miembro de múltiples grupos con diferentes permisos en

diferentes objetos, los permisos se "suman".

Recuerda que cuando asignes permisos directamente a un servidor vSphere ESXi,

no podrás asignar permisos en carpetas y virtual machines.

Los permisos definidos explícitamente a un usuario en un objeto, tienen

preferencia sobre los permisos definidos a un grupo sobre el mismo objeto.
Un Resource Pool Administrator puede mover un Resource Pool y modificar
permisos dentro de su Resource Pool.

Un Datacenter Administrator puede crear Resources Pools y añadir hosts al

inventario.

El role No Access, permite a un administrador eliminar los permisos en un objeto

que de otra forma se hubiesen propagado.

El role Administrator, predefinido en vCenter Server, es el único que puede asignar

permisos a los usuarios. Los dos únicos usuarios asignados a este role son el
usuario root y el usuario vpxuser.

Asimismo los permisos aplicados directamente a un objeto del inventario,

sobrescriben los permisos heredados (Propagate to Child Objetcs).

Si un usuario o grupo pertenece a un role en vCenter Server y el role es borrado, los

usuarios o grupos asignados a ese role no tendrán permisos en vCenter.

Aviso: Si quieres restringir la posibilidad que un administrador pueda instalar plug-

ins con vSphere Client, debes modificar los permisos de dicho administrador y
eliminar el permiso Register Extension privilege.

Clonando roles en VMware vSphere™

En vSphere™, es posible clonar los roles preestablecidos. Pero, ¿cuál es el objetivo

de clonar un role? Bien, los roles pre-establecidos cumplen su misión en el 99% de
los entornos de los clientes. No obstante, hay veces en los que hay que crear un
nivel de granularidad, a nivel de permisos, más concreto y preciso.

Por consiguiente, una mejor practica es la de no cambiar los privilegios en los roles
existentes, sino, crear un clone de ese role, renómbralo con el nombre que más se
ajusta a nuestro entorno y después cambiar los privilegios que sean necesarios en
este role clonado.

Cuando clonas un role, el nuevo contendrá los mismos privilegios que el role
original. Asimismo, el role clonado no incluirá ningún usuario o grupos del original.
Otra de las mejores prácticas, en cuanto al uso de roles y usuarios se refiere, es la
de no usar el usuario de Windows Administrator para gestionar la infraestructura
vSphere. Es conveniente crear un usuario y asignar este usuario el role
Administrator.

Si el servidor donde instalamos vCenter es parte de un dominio de Windows, el

grupo del directorio activo Domain Admins es incluido en el role Administrator en el
objeto raíz Host & Clusters.

Es también una mejor práctica instalar el servidor de vCenter en un servidor que

se parte de un dominio para poder hacer así uso de los usuarios y grupos de este
dominio.

Entendiendo el significado del usuario vpxuser

Los usuarios del servidor ESXi, root y vpxuser, son asignados al role Administrator a
nivel del servidor ESXi.

El usuario vpxuser es una copia exacta del usuario root y el motivo de la existencia
de este usuario es permitirte cambiar la contraseña de root desde el vSphere
Client sin perder la conexión con el vCenter.

El usuario vpxuser no tiene ningún derecho (login, shell). Es muy buena práctica no
modificar las propiedades de este usuario ya que podríamos, involuntariamente,
alterar el buen funcionamiento del servicio de logon en el host ESXi.

Este usuario vpxuser se crea al añadir el servidor ESX/ESXi al inventario del

vCenter.

Aviso: Si modificas las propiedades de este usuario, que dicho sea de paso no es
una mejor práctica, es muy probable que no puedas gestionar tu servidor ESXi
desde el vCenter. Para poder corregir esta situación, sigue los siguientes pasos.

1. Desregistra y borra tu servidor ESXi del inventario de vCenter

 2. Conéctate directamente con el vSphere Client a tu servidor ESXi

3. Borra el usuario vpxuser

4. Vuelve a conectar y añadir tu servidor ESXi al inventario de vCenter

Configurando el Firewall en vSphere™ ESXi

En la versión ESXi, la red de gestión (Management Network) está protegida por un

firewall orientado a servicios el cual puede ser configurado usando vSphere Client
o vía comando desde la consola del Shell de ESXi (esxcli network firewal).

Con el comando esxcli network firewal podrás abrir desde consola uno o varios
puertos del firewall de tu servidor vSphere ESXi 5.

~ # esxcli network firewall

Usage: esxcli network firewall {cmd} [cmd options]

Available Namespaces:

ruleset Commands to list and update firewall ruleset configuration

Available Commands:

get Get the firewall status.

load Load firewall module and rulesets configuration.

refresh Load ruleset configuration for firewall.

set Set firewall enabled status and default action.

unload Allow unload firewall module.

~ # esxcli network firewall get

Default Action: DROP

Enabled: true

Loaded: true

~#

Aviso: El firewall del servidor vSphere™ ESXi ya no está basado en Linux IP Tables.
En su lugar, se han definido reglas y puertos por cada servicio. De esta forma ,
ahora es posible especificar el IP o el rango de IPs que quieres permitir o denegar
un servicio en concreto.

La pestaña de services dentro de las propiedades del firewall, te permitirán ver el

nombre y el estado del servicio, es decir, si esta arrancado o parado.
Puedes configurar un servidor para que arranque con el host, para que arranque
manualmente o que arranque automáticamente si otros puertos están abiertos o
cerrados.

El firewall en ESXi está configurado, por defecto, con seguridad alta, bloqueando
todo el tráfico de entrada y salida que no es necesario para el correcto
funcionamiento de vSphere y sus plugins.

Habilitando y deshabilitando el Lockdown mode en vSphere™

Lockdown mode deshabilita todos los accesos directos a los hosts ESXi. De esta
forma solo será posible acceder a tu servidor ESXi desde el vSphere Client
conectándose al vCenter.

Por defecto, no existe ningún usuario local en los hosts ESXi con lo que si quieres
crear un usuario local en tu servidor ESXi asegúrate de hacerlo antes de activar el
Lockdown mode ya que después de estar activado no podrás crear usuarios
locales.

¿Cómo podemos activar Lockdown Mode?

1. Desde la DCUI
2. Al añadir el host para ser gestionado por vCenter Server

3. Desde vCenter Server haciendo clic sobre host > Configuration > Security Profile

Integrando ESXi con el directorio activo

Aunque las tareas diarias de administración y gestión de un entorno virtual con

vSphere™ se realizan generalmente desde el vSphere Client conectándose
directamente al vCenter, en ciertas ocasiones puede que sea necesario acceder
directamente a los servidores ESXi. Por ejemplo, cuando queremos acceder
directamente a los logs locales de un servidor ESXi o para hacer un backup local de
dicho servidor.
En este caso, es una mejor práctica configurar tus servidores ESXi para que se
unan a un dominio del directorio activo para que los usuarios que necesiten tener
acceso local tengan que identificarse contra un directorio centralizado (AD).

La ventaja de este modelo es que tú, como administrador, puedes seguir usando los
usuarios o grupos de tu directorio activo o NIS para conceder acceso local a tus
servidores ESXi. Este modelo es más seguro y fácil de implementar que el tener
que crear cuentas independientes locales por cada uno de tus servidores ESXi.

Por supuesto, una vez que integres tu servidor ESXi con tu directorio activo o
servidor NIS, podrás seguir teniendo la posibilidad de crear usuarios o grupos
locales a nivel de ESXi.

Para añadir tu servidor ESXi a tu directorio activo selecciona la pestaña de

Configuration > Authentication Services

Una vez dentro de este menú básicamente tienes que introducir los datos de tu
domino (nombre, usuario y passowrd) y seleccionar Join Domain

Aviso: ESXi 5 automáticamente concede acceso de administrador al grupo del

directorio activo llamado “ESX Admins” lo cual permite la creación de otros grupos
de administradores globales.
Capítulo 8. Gestión de recursos en vSphere™

Los Resource pools permiten asignar CPU y memoria dinámicamente. El clúster

VMware DRS ofrece una herramienta extraordinaria para la gestión de recursos
de una forma mucho más centralizada.

El uso de resource pools, límites, reservas y shares es considerado por VMware

una mejor práctica para garantizar el uso de los recursos que las máquinas
virtuales requieren. Asimismo, es muy recomendable garantizar a cada usuario los
permisos necesarios, y no más de los necesarios, para que puedan cumplir con su
obligación, que no es otra que la administración del entorno virtual.

¿Qué es un Resource Pool con memoria reservada?

Un resource pool es una abstracción lógica (contenedor) el cual permite asignar

recursos de CPU y memoria de forma más dinámica y eficiente. Por tanto, los
recursos de un servidor ESXi o un clúster DRS pueden ser divididos y asignados
más eficientemente.

Los beneficios de un resource pool son los siguientes:

1. Facilidad de delegación y control de acceso.

2. Separación de los recursos del hardware.

Los resource pools pueden ser creados a nivel de servidor ESXi o clúster VMware
DRS, pudiendo ser editados y modificados dinámicamente.

El indicador amarillo durante el ajuste de los recursos en un resource pool, muestra

la cantidad recomendada para ese recurso.

El memory overhead de las máquinas virtuales también consume memoria en el

resource pool y, por lo tanto, esta memoria es incluida en la reserva del resource pool.
Aunque VMware recomienda el uso y las buenas prácticas dentro de los resource
pool, no es aconsejable crear una jerarquía de más de tres resource pools. La
profundidad máxima de esta jerarquía en los resource pools es de 8. Esto crearía
un nivel de “burocracia” excesivo en cuanto al control de acceso se refiere.

Aviso: El número máximo de resource pools por host es de 1.600

Cambiando los recursos desde el Resource Allocation

Puesto que todas las máquinas virtuales acceden directamente a los recursos
físicos, estas no sabrán qué hacer cuando todas las máquinas virtuales estén
accediendo a los mismos recursos, es decir, cuando haya contención en tu sistema.

Por consiguiente, vSphere™ incluye un mecanismo para controlar que máquina

virtual accede a que recursos y por cuanto tiempo y prioridad.

Cuando la memoria o la CPU de un servidor ESXi está en overcommitted, es decir,

las máquinas virtuales están configuradas con más memoria y ciclos de reloj de
CPU de lo que dispone físicamente el servidor ESXi, necesitamos tener un
mecanismo para garantizar los accesos.

Es aquí donde entran los conceptos de Shares, Limits y Reservation.

Limit: Es el valor consumido de ciclos de reloj de CPU o memoria física del servidor
ESXi del cual no es posible pasarse.

Reservation: Este valor es definido en Mhz para CPU y MB para memoria RAM y
representa un valor que debe estar disponible cuando la máquina virtual se
enciende.

Shares: Es un valor que especifica la prioridad relativa o la importancia de acceso de

una máquina virtual a un recurso determinado. Los shares compiten entre el límite
y la reserva.

Por consiguiente, con estos tres parámetros podemos definir SLAs - de las siglas en
inglés Sevice Level Agreement - para todas y cada una de nuestras máquinas
virtuales. Los shares, limits y reservation también están disponibles a nivel de
resource pool.

Nota que cuando no hay contención entre máquinas virtuales, el cambio de la

configuración de los shares no tiene ningún efecto. No obstante, cuando hay
contención entre dos máquinas virtuales a nivel de CPU y defines unos shares más
altos a una máquina virtual, estarás dando una prioridad más alta a esta máquina
virtual sobre la otra.

Es posible cambiar el valor de los shares de CPU y la reserva de memoria desde la

pestaña Resource Allocation a nivel de Cluster o a nivel de host ESXi cuando este
no está configurado en un clúster.

Asimismo, también es posible modificar en "caliente" la reserva de CPU y el tipo de

reserva, Fixed o Expandible.

Cuando una máquina virtual, con la configuración en shares de memoria en custom,

es añadida a un resource pool, es posible que recibas un warning que indica que la
máquina virtual obtendrá un porcentaje muy alto del total de los shares para la
memoria. Cambia la configuración de los shares de custom a high, medium o low
para evitar este warning.

Cuando añades un servidor vSphere™ ESXi a un clúster y la opción de DRS no está

habilitada, los resource pools que estaban en el servidor vSphere ESX/ESXi son
eliminados. Asimismo, si creas un clúster sin la opción de DRS, no podrás crear
resource pools a nivel de clúster.

Cambio dinámico de los Resource Pools

Es posible incluir más de una máquina virtual en un mismo resource pool. En este
caso, todas las máquinas virtuales del resource pool competirán por los mismos
recursos físicos especificados en el resource pool.

En el caso de que el resource pool no haya sido configurado con la opción

Explandable Reservation, el rendimiento de las máquinas virtuales puede llegar a
verse afectado.
Para incrementar el rendimiento de alguna máquina crítica que este dentro de
dicho resource pool, puedes aumentar el límite de CPU del mismo. Los resource pools
que están en un mismo nivel son llamados Sibling Pools.

¿Qué tamaño deberían tener mis LUNs de almacenamiento?

VMware tiene dos métodos bien diferenciados a la hora de configurar el tamaño

correcto para las LUNs de almacenamiento. El método predictivo o el método
adaptivo.

El método adaptivo utiliza menos LUNs pero LUNs más grandes mientras que el
método predictivo, utiliza varias LUNs con diferentes tipos de RAID para
adaptarse mejor a las características de E/S de las diferentes aplicaciones.

Una buena práctica a la hora de configurar las LUNs, es crear LUNs de unos
800GB de tamaño y añadir entre 15-20 máquinas virtuales comprobando el
rendimiento.

Pero puede ser que cuando vas a añadir la máquina virtual número 5 se crea un
cuello de botella a nivel de LUN. Por eso es muy importante que antes de añadir
una nueva máquina virtual a una LUN, monitorices a nivel de E/S el delay de dicha
LUN. Si el rendimiento aun es óptimo, mete otra máquina virtual y vuelve a
monitorizar el rendimiento. Si el rendimiento sigue siendo bueno, sigue metiendo
más máquinas virtuales.

Cuando detectes que el rendimiento no es bueno, y antes de que se genere un

cuello de botella en tu LUN, crea otro datastore y empieza a meter nuevas
máquinas virtuales en tu nueva LUN y vuelve a empezar con el proceso descrito.
Capítulo 9. Monitorización de recursos en vSphere™

VMware VMkernel trabaja proactivamente para evitar contención en los recursos

físicos del servidor ESX/ESXi. No obstante, para maximizar el rendimiento, es
necesario analizar y monitorizar constantemente nuestra infraestructura
vSphere.

El proceso de escrituras desde las máquinas virtuales al disco compartido

Cuando una máquina virtual quiere hacer una operación de E/S al disco FC
compartido de la cabina de almacenamiento, el VMkernel ejecuta las siguientes
tareas:

1 - El archivo correspondiente a la máquina virtual es localizado en el DataStore

VMFS.

2 - La solicitud de los bloques en el disco virtual es asignada a los bloques en el

disco físico apropiado.
3 -La solicitud modificada de E/S es enviada desde el driver del controlador de
disco duro de la máquina virtual a la tarjeta física HBA.

Es impórtate entender este proceso para poder monitorizar bien todos los
elementos o capas involucradas durante una operación de escritura.
El uso de iniciadores hardware iSCSI descarga al VMkernel de dos tareas
principales:
1. La encapsulación de PDU (Protocolo Data Unit ) iSCSI en paquetes TCP/IP

2. La encapsulación de solicitudes I/O de disco en iSCSI PDU.

Cuando usas el software de multipathing con el iniciador software iSCSI, debes

conectar – port binding - el iniciador software iSCSI con el VMkernel port vía
comando (esxcli) o ahora también lo puedes hacer desde la GUI en la versión
ESXi.

Configurando el tamaño correcto de la memoria en las MVs

El valor máximo recomendado de memoria que se muestra cuando se está

configurando una máquina virtual representa el umbral por encima del cual la
memoria física del host es insuficiente para ejecutar la máquina virtual con un
rendimiento óptimo.

El tamaño de la partición swap de la máquina virtual (.vswp) será igual al tamaño

de la memoria física seleccionada cuando se configura la máquina virtual.

En nuestro caso, el tamaño de nuestro fichero swap sería de 1GB, al asignarle

1GB de memoria RAM a la máquina virtual durante su creación. Esta regla es
diferente cuando se asignan reservas a las máquinas virtuales. Por ejemplo, si
creas una máquina virtual con un 1GB de memoria RAM y creas una reserva de
350MB, el tamaño del fichero swap será de 1GB menos 350MB, es decir,
650MB.

VMware VMkernel detecta las páginas de memoria que son idénticas en todas las
máquinas virtuales y asigna estas páginas a la misma dirección de memoria física,
con el consiguiente ahorro potencial de memoria física. Esta técnica es
denominada Transparent Memory Page Sharing (TMPS).

VMware VMkernel trata las páginas de memoria compartidas como páginas de

memoria COW (Copy on write), lo que significa que son páginas de solo lectura
cuando son compartidas y páginas privadas cuando una de las máquinas virtuales
hace algún cambio.

TMPS está siempre activada, a menos que se deshabilite manualmente

modificando el fichero de configuración de la máquina virtual (.vmx).

Asimismo, Transparent Memory Page Sharing es la técnica de conservación de

memoria con un impacto menor que otras técnicas, como pueden ser el
ballooning o swaping, por cuanto permite eliminar páginas de memoria
duplicadas ubicadas en diferentes máquinas virtuales.

No confundas TMPS con el Memory Balloon Driver, el cual permite reubicar

memoria no usada de una máquina virtual a otra. Las técnicas de conservación de
memoria con Transparent Memory Page Sharing y RAM Overcommit, permiten
asegurarse la eliminación de copias de páginas de memoria redundadas entre
máquinas virtuales.

Una de las nuevas funcionalidades en la versión ESXi 5, en cuanto a la

optimización de memoria se refiere, es el llamado Memory Compression.
Esta técnica es también transparente al sistema operativo guest y mucho más
rápido, comparado con el proceso de paging a nivel de máquina virtual.

Con Memory Compression cada página de memoria considerada para ser

paginada a disco, es comprimida y almacenada en una cache de compresión a
nivel de máquina virtual. En el ejemplo del diagrama anterior, la página de
memoria A y B son comprimidas de 4K a 2K en la cache de la máquina virtual.

vSphere y la funcionalidad VMDirectPath I/O

En vSphere ESXi 5 es posible dedicar en exclusiva una tarjeta HBA, de red o

incluso un disco USB conectado directamente en el servidor ESXi a una máquina
virtual

Para configurar VMDirectPath debes seleccionar la pestaña de Configuration >

Advanced Settings

Un icono verde indica que el dispositivo está habilitado y activo. Un icono naranja
indica que el estado del dispositivo ha cambiado y el servidor host debe ser
reiniciado antes de que el dispositivo pueda ser utilizado por la máquina virtual.

Una vez asignado el hardware a la máquina virtual, este no podrá ser gestionado
por el servidor ESXi. La versión anterior ESX/ESXi 4.1 ya soportaba dispositivos
USB en modo passthrought. Para más información sobre la configuración de USB
en modo passthrought revisa el KB1022290.

Puedes conectar hasta dos dispositivos passthrought a una máquina virtual y solo
pueden ser tarjetas de red o tarjetas HBAs de fibra para la conexión a la SAN.
Detectando cuellos de botella en el componente disco

Una máquina virtual puede tener un cuello de botella a nivel de E/S de disco si el
contador SCSI queue length es alto.

Puedes ver en uno de nuestros videos tutoriales de formación gratuitos los dos
contadores importantes a monitorizar para ver si hay un cuello de botella a nivel
de disco. También aprenderás a ver como se monitorizan estos
contadores: http://www.josemariagonzalez.es/curso-online-gratuito

Una aplicación en una máquina virtual puede experimentar un rendimiento

pobre, aunque la máquina virtual tenga memoria disponible, ya que puede no
tener memoria física disponible. El número máximo de vCPUs con el que puedes
configurar una máquina virtual es ahora de 32.

Para mejorar el rendimiento de una máquina virtual ejecuta los siguientes pasos:

1. Deshabilita dispositivos no usados como puertos COM, floppies o CD-ROM.

2. Optimiza la máquina virtual como si fuera una máquina física.

3. Pon máquinas virtuales con requerimientos similares en el mismo servidor

vSphere ESX/ESXi.
Detectando cuellos de botella en el componente vCPU

VMware recomienda mirar el indicador CPU Ready para determinar si la máquina

virtual tiene un cuello de botella en el componente CPU.

Si el contador de uso de la CPU está al 100% y el contador de CPU Ready está

entre un 5-10% durante un periodo largo de tiempo, es muy probable que la
máquina virtual tenga un cuello de botella a nivel de CPU. Un incremento en el
número de shares de CPU es muy posible que beneficie a una máquina virtual
que esté saturada en cuando a CPU.

Puedes ver un video tutorial en nuestro curso online gratuito dedicado en

exclusiva a la virtualización de sistemas, sobre como monitorizar la capa de CPU
en tu entorno virtual para saber si hay un cuello de botella a nivel de
CPU: http://www.josemariagonzalez.es/curso-online-gratuito

Aviso: Para mejorar el rendimiento de la máquina virtual, o bien creas una

afinidad de CPU en la máquina virtual para que esta se ejecute solo en una CPU
física, lo cual no es una mejor practica porque entre otras cosas pierdes vMotion
o haces una reserva de la CPU física en exclusiva para la máquina virtual en
cuestión.
Monitorizando Thin Provisioning con alarmas

Haz clic con el botón derecho sobre la LUN que quieres monitorizar y selecciona
Add Alarm.

Crea una alarma para el DataStore que quieres monitorizar, selecciona el

contador "DataStore Disk Overallocation" y determina el porcentaje apropiado.
Después, desde la pestaña de Actions, crea una acción que envíe una notificación
vía email al administrador.

Aviso: Puedes convertir un disco de máquina virtual de thin a thick con la opción
inflate con la máquina virtual apagada.

Asimismo, también puedes convertir un disco de thin a thick cuando haces una
migración con Storage vMotion y seleccionas cambiar el tipo de disco a Thick.

El uso del New Task Wizard en vSphere

Con el nuevo New Task Wizard ahora es posible crear y programar las siguientes
tareas: Create a snapshot of a virtual machine, Enter a host in Maintanance Mode,
Create a virtual machine template, Migrate a virtual machine with vMotion, etc.

Para automatizar estas alarmas, selecciona Home, Management, Scheduled tasks y

haz clic en New.

Por defecto, vCenter crea 55 alarmas pre-definidas sobre el objeto inventario

raíz. Estas alarmas son de solo lectura, excepto cuando editas las alarmas desde el
objeto inventario donde fueron definidas. En ese caso podrás modificar las
alarmas pre creadas.

Configurando vCenter Server para enviar notificaciones por email

Dentro del servidor de vCenter, selecciona Administration en la barra del menú de

opciones y elige vCenter Server Settings. Después selecciona la opción Mail.

Escribe la dirección IP de tu servidor SMTP centralizado. Debes de configurar

tanto el servidor de SMTP como la dirección email desde donde se van a mandar
los correos. Asimismo, tu servidor vCenter tiene que tener instalado un agente
relay de SMTP para poder mandar las notificaciones vía email.

Aviso: Para configurar las notificaciones SMTP, el cliente vSphere debe estar
conectado al servidor vCenter.
Capítulo 10. Funcionalidades Enterprise en vSphere™

En este módulo te explicare los servidos Enterprise más importantes de

VMware para todo aquel administrador que quiera dotar a su infraestructura
virtual de la protección necesaria contra la pérdida de datos (Data Recovery),
protegerse contra la caída de los sistemas ESXi (VMware HA), y en definitiva
configurar el centro de datos flexible y dinámico del futuro (VMware DRS y
VMware DPM).

¿Cómo mover las máquinas virtuales de host con vMotion o de disco con
Storage vMotion?

Con vSphere no solo es posible migrar las máquinas virtuales de servidor

ESXi con la funcionalidad de vMotion, sino que también es posible mover sus
discos virtuales asociados de datastore.

Para migrar una máquina virtual, selecciona esta desde el inventario con el
botón derecho del rato y selecciona Migrate

La imagen anterior muestra el wizard de migraciones de máquinas virtuales.

Cuando selecciona la opción Change host estas usando vMotion y cuando
selecciones Change datastore lo que estas usando es Storage vMotion.

También es posible hacer un vMotion y un Storage vMotion a la vez pero la

máquina virtual tendrá que estar apagada.
La idea de usar Storage vMotion es para mover máquinas virtuales entre
diferentes DataStores NFS, iSCSI y FC. Uno de los beneficios más grandes de
Storage vMotion es el hecho de poder mover un disco virtual de una máquina
virtual de un DataStore a otro con menos latencia y comprobar el
rendimiento de la máquina virtual en el nuevo DataStore.

También es posible migrar una máquina virtual con Storage vMotion con los
discos suspendidos. Storage VMotion no puede usarse en máquinas virtuales
con NPIV activado.

Los discos Raw Device Mapping en compatibilidad física están soportados

por vMotion y VMware HA.

Asimismo, vMotion está soportado en una máquina virtual con la opción

NPIV (N-Port ID Virtualization) habilitada, pero no cuando esta máquina
virtual tiene múltiples discos virtuales en diferentes DataStores. NPIV no
está soportado en máquina virtual con Fault Tolerance habilitado, otro de los
servicios Enterprise que cubriremos más adelante en este libro.

Una migración con vMotion no incurre en ningún downtime para la máquina

virtual. Recuerda que vMotion es requerido en un clúster DRS/HA.

Es posible que los hosts ESXi involucrados en una migración en caliente con
vMotion no sean compatibles. Cuando veas una cruz roja, desde la pestaña
Maps, en un servidor vSphere ESX/ESXi de un clúster DRS/HA, significará
que este servidor no es compatible con VMotion.

En cuanto a los requerimientos de vMotion, una máquina virtual no puede

ser migrada cuando:

1. 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 afinidad a una CPU.

 La MV forma parte de un clúster Microsoft.

El wizard de vMotion produce un aviso 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 ESXi no ha recibido un guest OS heartbeat (probablemente

las VMware tools no han sido instaladas, configuradas
adecuadamente, o el servido de VMware tools está parado).
Recuerda que si recibes un mensaje de error, la máquina virtual no podrá ser
migrada. Sin embargo, con un mensaje tipo warning, puede ser migrada con
vMotion sin problemas.

Por último, recuerda que los servidores ESXi involucrados en la migración

deben tener:

 Visibilidad de todas las LUNs (FC, iSCSI o NAS) usadas por la MV.

 Una red Gigabyte Ethernet dedicada al tráfico vMotion.

 Acceso a la misma red Ethernet física.

 CPUs compatibles o similares (misma familia CPU). vMotion también

funciona si el servidor origen tiene Hyperthreading activado pero no
el servidor destino.

A diferencia de VMware ESX 3.x, el nombre de los switches virtuales

configurados para transferir el tráfico generado por vMotion, no tiene por
qué ser configurados con el mismo nombre.

Aviso: El número máximo de migraciones simultaneas con Storage vMotion

en VMware vSphere™ ESXi es de 8 por datastore.

Asimismo, no podrás migrar una máquina virtual con Storage vMotion si esta
máquina virtual tiene snapshots activos y el disco virtual de dicha máquina
virtual ha sido configurado como independent non-presistent. También es
posible usar la funcionalidad de Storage vMotion para asegurarte que una
vez hayas renombrado tus máquinas virtuales, este nombre también será
actualizado a nivel de datastore.
El número máximo de migraciones concurrentes con Storage vMotion por
host es de 2.

vSphere Data Recovery

vSphere Data Recovery está incluido en la versión vSphere Essentials Plus.

Es una herramienta para hacer backups y restores a disco de tus máquinas
virtuales el cual se integra con vCenter Server. Es por lo que necesitas la
existencia de vCenter Server para poder usar e instalar este appliance de
VMware.

vSphere Data Recovery utiliza el API VSS(Microsoft Volume Shadow Copy

Services) para los backups en Windows Vista 32bit, Windows Server 2003
32bit y Windows Server 2008 32bit. Windows XP no está soportado en Data
Recovery.

vSphere Data Recovery también soporta servidores ESX 3.5.x. No obstante,

el backup de máquinas virtuales hospedadas en servidores ESX 3.5 suelen
tardar más que en vSphere ESX 4.x. y ESXi 5. El motivo es que ESX 3.5 no
soporta la nueva funcionalidad en vSphere llamada changed-block tracking.

Para instalar vSphere Data Recovery has de bajarte el appliance desde la web
de VMware, instalarlo en un Servidor ESXi gestionado por vCenter e instalar
el plugin cliente en el vSphere Client.

El número de tareas máximo de backup o restore que Data Recovery soporta

es de 8 tareas simultáneas.
vSphere Data Recovery soporta nuevas funcionalidades como backup a disco
y deduplicación por consiguiente hay que asignar un disco al appliance de
Data Recovery para hacer los backups.

Este disco puede llegar a tener un tamaño de hasta 1TB para discos de FC y
de 500GB para discos compartidos via CIFS. El motivo es que si usas
tamaños más grandes, según VMware, el rendimiento disminuye
considerablemente.

Opciones de Clustering para las máquinas virtuales

Es posible clasterizar las aplicaciones dentro de las máquinas virtuales con

software de clustering de terceros. El único software de clustering para las
máquinas virtuales soportado en vSphere es el software de clustering de
Microsoft Windows.

Asimismo, existen tres opciones a la hora de clusterizar tus máquinas

virtuales con el software de clustering de Microsoft.

La primera opción es clúster in-a-box, el cual te permite protegerte contra

fallos de usuario, aplicación y sistema operativo.

Aviso: Recuerda que el Bus Sharing para el disco SCSI 0 (c:) es = None y el
Bus Sharing para el disco SCSI 1 (quorum) es = Virtual. Los discos RDM solo
están soportados en modo virtual.

La segunda opción es clúster entre hosts ESXi, el cual te protege contra fallos
de usuario, aplicaciones, sistemas operativos y hardware.

Aviso: Recuerda que en esta configuración el Bus Sharing para el disco SCSI 0
es = None y el Bus Sharing para el disco SCSI 1 es = Físico. Los discos RDM
están soportados tanto en modo virtual o físico.
La tercera opción es clúster entre máquina física ESXi y máquina virtual, la
cual te permite una solución de redundancia N+1 de bajo coste. En esta
configuración es posible que el failover del clúster falle si usas el driver
STORport Miniport.

Aviso: Recuerda que en esta configuración el Bus Sharing para el disco SCSI 0
es = None y el Bus Sharing para el disco SCSI 1 es = Físico. En esta
configuración, los discos RDM solo están soportados en modo físico.

Si usas Windows Server 2003 en un clúster Microsoft MSCS asegúrate que

la tarjeta virtual en las máquinas virtuales es de tipo "Flexible".

Si usas Windows Server 2008 en un clúster Microsoft MSCS asegúrate que

el adaptador virtual SCSI en las máquinas virtuales es un "LSI Logic SAS"

Cuando creas un clúster Microsoft MSCS entre dos servidores ESXi 5, el

disco de la máquina virtual donde residirá el disco quorum del clúster, debe
ser un disco RDM en compatibilidad físico o virtual.

Personalmente, no veo la necesidad de clusterizar las máquinas virtuales con

un software de terceros, en este caso de Microsoft, ya que los servicios de
alta disponibilidad en VMware, como HA y FT, nos ofrecen un RTO - de las
siglas en ingles Recovery Time Objective – muy bueno y con una
configuración mucho más simple y flexible.

No obstante, si tu aplicación requiere un RTO de menos de 5 minutos y

requiere una configuración de más de una vCPU, no tendrás otra alternativa
que clusterizar estas máquinas virtuales con el software de clustering de
Microsoft para ofreces ese RTO.

VMware Fault Tolerance (FT)

VMware FT es otro de los servicios Enterprise en VMware. A diferencia de
VMware HA, donde la máquina virtual tiene un downtime mínimo, una
máquina virtual protegida con FT tiene un downtime de cero (menos 14
milisegundos en una red de 1Gb).

Solo hardware de última generación soporta la funcionalidad Fault

Tolerance en VMware. Asegúrate de verificar con tu proveedor de hardware
que este tiene soporte para FT.

VMware Fault Tolerance usa la tecnología de VMware vLockstep y no

soporta discos thin en las máquinas virtuales.

Cuando activas Fault Tolerance en una máquina virtual, esta no puede tener
más de una CPU virtual (VMware SMP).

VMware Fault Tolerant y las políticas de no-afinidad y afinidad del clúster

DRS

Gracias a las políticas de no-afinidad en un clúster DRS, una o más máquinas

virtuales nunca podrán estar localizadas en un mismo servidor ESXi. También
es posible crear políticas de afinidad, es decir, que una o más máquinas
virtuales siempre residan en un mismo servidor ESXi.

Un ejemplo típico de una policía de no-afinidad sería el caso de dos

controladores de domino. Como veremos más adelante, cuando activamos
VMware DRS, este migrara automáticamente las máquinas virtuales de host
ESXi para balancear la carga. Yo le llamo el vMotion con celebro. Pero NO
queremos tener una situación en donde los dos controladores de dominio se
migran automáticamente a un servidor ESXi y que esta falla.
Si claro, VMware HA levantara las dos máquinas virtuales automáticamente -
si lo tienes configurado - pero estarás unos minutos sin ningún controlador
de dominio, y no querrás que esto pase, ¿verdad?

Aviso: No obstante, dada una máquina virtual en modo VMware Fault

Tolerant, puede suceder que tanto la copia primaria como la copia secundaria
residan en el mismo host ESX/ESXi.

Este caso solo puede darse cuando la máquina virtual en modo Fault Tolerant
está apagada. Para poder activar FT es necesario previamente tener HA
configurado.

Fault Tolerance y el panel Summary

Desde el panel Summary, puedes ver el estado de la funcionalidad Fault

Tolerance, active o Not Protected.

Para verificar si una máquina virtual está protegida con Fault Tolerance,
selecciona la máquina virtual y la pestaña Summary.

Si la máquina virtual reporta el estado "Not Protected" es un indicativo de

que la funcionalidad de Fault Tolerance está deshabilitada o que la copia
primaria está funcionando sin una copia secundaria, con lo que estarías en un
escenario de máquina virtual no protegida.

Cuando a la máquina virtual con la opción FT (Fault Tolerance) habilitada y

dentro de un clúster DRS/HA, se le habilita la opción Host Monitoring y la
primera copia de la máquina falla, una segunda copia (mirror) de dicha
máquina virtual no será creada. Por lo tanto, dicha máquina virtual no tendrá
una configuración redundante.

Una de las formas más sencillas de probar si FT está funcionando en tu

entorno es hacer que falle la máquina virtual primaria para ver si la
secundaria toma el testigo.
El número máximo de discos virtuales que una máquina virtual puede tener
cuando se protege con Fault Tolerance es de 16 virtual disk.

Asimismo, no es posible proteger más de 4 máquinas virtuales con FT por

servidor ESXi.

Otra de las limitaciones en VMware FT es el hecho de que no podrás asignar

más de 64GB de memoria RAM a una máquina virtual protegida con FT.

VMware High Availability Services (HA)

El servicio de VMware HA en vSphere™ ESXi 5 ha sido completamente

rediseñado. Ahora, los nodos en el clúster o son Master o Slave, a diferencia
de versiones anteriores donde había nodos primarios y secundarios.

VMware HA puede reiniciar automáticamente las máquinas virtuales de un

servidor ESX/ESXi que haya fallado debido a un problema de hardware del
servidor.

No obstante, es posible que una máquina virtual no se reinicie en otro

servidor ESX/ESXi del clúster HA en el caso de que haya sido configurada con
una prioridad baja (low priority) o que el admission control haya sido
configurado.

Recuerda que debe haber suficientes recursos en el clúster HA, basados en la

reserva de CPU y memoria, para poder reiniciar las máquinas virtuales.

Si al arrancar una máquina virtual en clúster VMware HA recibes el error

"insufficient resources exist for HA", no tienes suficientes recursos físicos
para arrancar más máquinas virtuales. Para poder resolver este problema,
puedes cambiar la configuración de VMware HA y seleccionar la opción
"Allow virtual machines to be powered on even if they violate HA availability
constraints" o añadir otro servidor ESX/ESXi al clúster. Desactivar el control
de admisión en VMware HA no es una mejor práctica.
Un clúster VMware HA puede llegar a tener la máxima configuración
siguiente:

 El número máximo de servidores ESXi permitidos por un clúster

VMware HA es de 32 nodos.

 El número máximo de máquinas virtuales por host que puedes

proteger con HA es de 512, con independencia del número de host
que tengas configurados en el clúster HA.

 El número máximo de máquinas virtuales por clúster que puedes

proteger con HA es de 3.000

Activando vSphere VMware HA/DRS

Antes de configurar VMware HA, verifica que todas las máquinas virtuales
pueden ejecutarse en los nodos que vayan a formar el clúster. Recuerda que
el acceso a recursos comunes como LUNs y redes virtuales es vital para que
VMware HA funcione correctamente.

Para crear un clúster con la opción de HA, selecciona el objeto de inventario

datacenter con el botón derecho del ratón y selecciona create new clúster. En
la imagen anterior se muestra el wizard de creación de un clúster. Para activa
la parte de HA del clúster solo tienes que marcar la opción Turn on VMware
HA. Es una muy buena práctica tener HA y DRS activados juntos. DRS se
activa de la misma forma que activamos VMware HA.

VMware HA solo reiniciará las máquinas virtuales en otro servidor vSphere

ESXi cuando uno de los servidores del clúster se aísla de la red o un host falla.
Recuerda que para que VMware HA funcione perfectamente, todos los
servidores vSphere ESX/ESXi en el clúster deben tener acceso a los
DataStores compartidos por todos los servidores ESX/ESXi.

Asegúrate que tu servidor DNS funciona perfectamente y que puedes hacer

ping por nombre corto, FQDN, alias y dirección IP desde todos los servidores
ESX/ESXi y desde el vCenter, así como al default gateway.

VMware HA instala un agente en cada servidor ESXi el cual monitoriza el

host ESXi así como las VMware tools en todas y cada una de las máquinas
virtuales registradas. Asimismo, y opcionalmente, este agente también puede
ser configurado para monitorizar los heartbeats de las aplicaciones que están
corriendo en las máquinas virtuales.

Cuando un servidor vSphere ESXi es puesto en modo mantenimiento en un

clúster HA/DRS, las máquinas virtuales se migrarán automáticamente a otros
servidores vSphere ESXi, siempre que el clúster esté configurado en fully
automated. Si el clúster está configurado en partially automated, el
administrador de vCenter deberá mover las máquinas virtuales
manualmente. Recuerda los tres niveles de automatización para un clúster
DRS: Manual, Partially Automated y Fully automated.
Los niveles de automatización en VMware DRS se definen en base a dos
valores: dónde se va a arrancar la máquina virtual cuando esté apagada, y
dónde se va a mover (vMotion) la máquina virtual cuando esté encendida
(balanceo dinámico o DRS).

En un clúster DRS, con la configuración fully automated, si deseas que una

máquina virtual no se migre a otro servidor vSphere ESX/ESXi, has de
cambiar las opciones de la máquina virtual a Partially Automated.

La diferencia entre partially automated y fully automated en un clúster DRS es

que un clúster con la opción fully automated migra las máquinas virtuales para
optimizar el uso de los recursos.

En la sección, Virtual Machine Options, puedes cambiar el nivel de

automatización por máquina virtual.

La diferencia entre default (Partially Automated) y Disable, es que con

Disabled el clúster DRS no genera ninguna recomendación para esa máquina
virtual en particular. Por consiguiente, esta máquina virtual nunca sería
migrada automáticamente con VMware DRS (vMotion).

Aviso: En una configuración DRS con solo dos servidores ESXi, es posible que
un servidor ESXi esté usando el 100% de los recursos (memoria y CPU)
mientras que el otro servidor esté mucho más libre. Este es un caso típico de
que no existen recursos suficientes para ejecutar una migración en caliente
con vMotion o que las CPUs de los host en el clúster son incompatibles con
vMotion.
Cambiando el orden de prioridad en el arranque de mis máquinas virtuales en
VMware HA

Edita los Settings de VMware HA y selecciona Virtual Machine Options. En mi

ejemplo, para la máquina virtual llamada DC1, he cambiado VM Restart
Priority a High. Esto significa que la máquina virtual DC1 arrancará antes que
la máquina Windows (VM Restart Priority Medium).

Aviso: Recuerda que los settings a nivel de máquina virtual sobrescriben los
settings definidos a nivel de clúster.

Cuando estableces VM Restart Priority a Disabled, como en la máquina virtual

llamada W2k mi ejemplo, le estás indicando al clúster VMware HA que, en
caso de fallo hardware en uno de los nodos, no reinicie dicha máquina virtual.
Recuerda las 4 opciones disponibles en la opción VM Restart Priority en
VMware HA: Disabled, low, Medium y High
Configurando la parte de red en VMware HA

Es recomendable tener dos tarjetas de red para el control del latido del
clúster (heartbeat). Asimismo, los uplinks vmnic0 y vmnic1 en mi ejemplo,
deberían estar conectados a switches físicos diferentes para estar protegidos
también contra fallos en la capa de red física.

La forma en la que vSphere VMware HA calcula el "failover capacity", cuando

se activa HA con la primera política de control de admisión (host failures
clúster tolerates), es usando el valor más alto de las reservas de memoria y
CPU de las máquinas virtuales de un clúster. Recuerda que debe haber
recursos suficientes en el clúster (memoria y CPU) para poder acometer un
failover.

Un clúster VMware DRS/HA mostrará un estado rojo si el número del

contador "failover capacity" es menor que el número "configured capacity".

Aviso: Recuerda que el valor por defecto de Isolation Response es de leave

power on, es decir, en caso de aislamiento de uno de los nodos del clúster
(perdida del heartbeat), las máquinas virtuales se dejaran encendidas.

Restart Priority e Isolation Response son configuraciones a nivel de clúster. Esta

configuración puede ser modificada también a nivel de máquina virtual.
Si una máquina virtual en un clúster DRS está teniendo problemas de
rendimiento, deberás incrementar los shares de CPU de dicha MV a High o
incrementar sus reservas de CPU.

Distributed Power Management (DPM)

Distributed Power Management es otro de los servicios Enterprise que se

puede activar cuando creamos un clúster HA/DRS.

La idea de DPM es tener el centro de datos del futuro en el cual los

servidores ESXi se apagan cuando no se necesitan y se enciende cuando se
les necesitan.

Puedes ver un video tutorial de DPM en acción en nuestro blog de

virtualización y cloud computing en español en la siguiente dirección web:
http://www.josemariagonzalez.es

DPM usa Wake-on-LAN (WOL), IPMI (Intelligent Platform Management

Interface) o las tarjetas de gestión remota iLO de HP para poner el host
ESX/ESXi en modo standby y volver a encenderlo cuando el clúster DRS lo
necesite.

DPM está deshabilitado por defecto cuando se crea un clúster DRS.Si lo

activas, asegúrate de que las tarjetas de red dedicadas a vMotion soporten
WOL pues es por esta red por donde se envían los paquetes “mágicos” de
para poner un host en modo standby o para sacarlo de ese modo cuando sea
necesario.

Quizás DPM tenga más sentido en entornos grandes pues es donde más
dinero en energía y refrigeración puedes ahorrar.
No obstante, en clientes pequeños (4 servidores ESXi) donde hemos
configurado DPM, estamos ahorrando alrededor u unos 1.200 euros al año,
lo suficiente para comprarte otra licencia de VMware Essentiasl!

Verificando la configuración del host con Host Profiles

La opción de Host Profiles es otra de las funcionalidades Enterprise que todo

centro de datos virtualizado de cierta envergadura debería tener
configurado por la cantidad de trabajo que este puede ahorrar al
administrador.

Básicamente con host profile podemos capturar la configuración de un host

ESXi 5 específico y duplicar dicha configuración a otro host o clúster con el
consiguiente ahorro en la fase de post-configuración de todos tus servidores
ESXi.

La funcionalidad de host profile también te permite comprobar que la

configuración de los host ESXi 5, en tu centro de datos, siguen las mejores
prácticas y están configuradas acorde con el baseline del administrador.

Host Profiles es el método recomendado por VMware para configurar

servidores ESXi cuando han sido instalados con VMware Auto Deploy.

Para poder aplicar una configuración con host profile a un servidor ESXi este
tiene que ser puesto primero en modo mantenimiento (maintenance mode)

Cuando un servidor ESXi 5 es puesto en modo maintenance mode, ninguna

máquina virtual puede ser encendida en ese servidor o migrada al mismo con
DRS o manualmente con vMotion.
Aviso: La ejecución de Host profile puede fallar cuando el host no ha sido
puesto en modo mantenimiento o es un servidor ESX 3.x ya que la
funcionalidad de host profile solo está disponible a partir de las versiones
ESX/ESXi 3.5

VMware vCenter Site Recovery Manager

Vmware vCenter Site Recovey Manager (SRM) te permite configurar un plan

de contingencias para que, en el caso que el centro de datos primario (Site A)
fallase, puedas levantar los servicios en un emplazamiento remoto (Site B).

VMware vCenter Site Recovery Manager requiere tener licencias válidas

para los servidores VMware ESX/ESXi y una licencia en cada site para
VMware vCenter Server.

La idea de SRM es protegerte contra caídas de sites mediante la creación de

planes de contingencias ante fallos completos del centro de datos. El área de
BC/DR - de las siglas en ingles Business Continuity/Desaster Recovery - es
bastante amplio como para cubrirlo en este libro. Es por lo que la
configuración, instalación y gestión de SRM la tenemos documentada en otro
libro totalmente separado.

Puedes recibir una copia gratuitamente de la versión ebook del libro:

Administrado Site Recovery Manager 4.0 en español al registrarte en
nuestro blog de virtualización y cloud computing en español en la siguiente
dirección: http://www.josemariagonzalez.es/2009/10/19/vmware-site-
recovery-manager-10-en-espanol-capitulo-10-la-recuperacin-del-site-
sin-vmware-srm.html
VMware Update Manager (VUM)

Con vCenter Update Manager, en combinación con VMware DRS, es posible

actualizar el hardware virtual de las máquinas virtuales, las VMware tools,
parchear las appliances y actualizar los servidores ESXi de una forma
automatizada (VMware Orchestator), flexible y sin ningún downtime.

VUM visto desde el servidor de vCenter

Para instalar VUM, debes de instalar la parte servidor en el mismo servidor

donde tienes ya instalado vCenter Server (para entornos pequeños) o en
otro servidor independiente al vCenter (entornos grandes). El binario está en
el mismo DVD que el vCenter Server.
Una vez que lo hayas instalados, podrás actualizar los siguientes objetos:
ESXi, Virtual Appliances, VMware Tools y hardware virtual.

En vSphere 5 ya no es posible actualizar máquinas virtuales pues VMware ha

decidido retirar esta posibilidad. Posiblemente, el motivo haya sido el poco
uso de los clientes.

Los niveles de severidad válidos en vCenter Update Manager para los

servidores hosts ESXi son: Critical, Security y General.

vCenter Update Manager incluye las siguientes baselines para las máquinas
virtuales : VMware Tools Upgrade to Match Host, VM hardware Upgrade to
Match Host y VA Upgrade to Laster. Y para los servidores ESXi son: Critical
Host Patches y Non-Critical Host Patches
Recuerda que no importa el número de servidores vSphere ESXi que tengas
en un clúster, solo podrás actualizar uno cada vez con vCenter Update
Manager.

Aviso: El número máximo de máquinas virtuales que VMware Update

Manager (VUM) puede escanear por instancia de vCenter Server es de
10.000.

Asimismo, el número máximo de VMware Tools que puedes actualizar por

servidor VUM es de 75 así como virtual machine hardware scans por
servidor de VUM.

Algo impórtate a destacar, es quizás el hecho de que no es posible actualizar

las VMware tools por servidor ESXi, sin usar el servidor VUM, de más de 24
máquinas virtuales a la vez.

Recuerda que no podrás actualizar con VUM el hardware virtual de tus

máquinas virtuales en servidores legacy, es decir, de servidores hosts que no
sean ESXi 5.

Por último, los puertos que VMware Update Manager usa son: 8084, 9084,
9087.

VMware vSphere™ Storage DRS

Probablemente una de las nuevas funcionalidades de la nueva versión

vSphere™ 5 que más interés ha despertado en los usuarios, administradores
y público en general es VMware Storage DRS.
Si ya conoces el concepto y la funcionalidad de Storage vMotion, entender
esta nueva característica te resultara muy sencillo.

Básicamente, Storage DRS te permite automáticamente seleccionar la LUN

más adecuada para el funcionamiento de tus máquinas virtuales. Este
avanzado mecanismo de balanceo a nivel de LUNs, también permite evitar
cuellos de botella y problemas derivados por la falta de espacio en disco.

Antes, y sin Storage DRS, manualmente tenías que seleccionar el datastore

que pensabas tenía una latencia menor para albergar tus máquinas virtuales.
Asimismo, tenías que, manualmente, seleccionar el datasotre correcto para
que tus máquinas virtuales no tuvieran ningún tipo de conflicto en cuando al
almacenamiento se refiere.

Ahora, y con Storage DRS, automáticamente el sistema arrancara tus

máquinas virtuales en aquellas LUNs con más espacio y menos latencia en
cuanto a E/S.

Antes de activar SDRS (Storage DRS) has de crear un grupo de datastores

llamado datastore clúster. Un datasotre clúster con SDRS activado
balanceará los discos de tus máquinas virtuales (.vmdk) de la misma forma
que un clúster DRS balancea las máquinas virtuales con vMotion.

Para crear un datastore clúster, selecciona el objeto de inventario de tu

vCenter con el botón derecho del ratón y selecciona New DataStore Cluster.

Puedes configurar, como en VMware DRS, tu datastore clúster en modo

manual o completamente automático. Quizás lo más importante a la hora de
configurar tu datastore clúster es seleccionar unos buenos Thresholds de
configuración de E/S en tus LUNs. Esta configuración de los thresholds
permitirá a SDRS hacer las recomendaciones necesarias de migraciones.

En mi ejemplo, me he creado un datastore clúster con una latencia de I/O

mínima de 15 milisegundos. Si mis máquinas virtuales sufrieran una latencia
de E/S superior a los 15 milisegundos, SDRS migraría la máquina virtual con
Storage vMotion a otro datasotre del clúster que ofrezca el mínimo de
latencia configurado.

De esta forma podrás crear SLAs - de las siglas en inglés Service Level
Agreetment - para todas y cada una de tus máquinas virtuales de una forma
rápida, sencilla y automatizada. Sin lugar a dudas, Storage Distribute
Resource Scheduler es una de las funcionalidades del centro de datos del
futuro el cual es virtual, flexible, dinámico y “plug & play”.
 Gracias y Cierre

Me gustaría darte las gracias personalmente por haber visitado nuestro blog
virtualización & Cloud Computing y haberte suscrito a este eBook sobre
virtualización con VMware vSphere.

Me gustaría poder obsequiarte con un descuento del 50% en todos nuestros

video cursos online en nuestra web:
Virtualización con VMware aplicada al mundo empresarial.

Ademas, si te gustan las emociones fuertes y ya tienes un "elevado" nivel de

administración de VMware vSphere, me gustaría obsequiarte mi curso
online avanzado VMware vSphere con un 33% de descuento!

En los enlaces que te adjunto arriba en este correo tendrás toda la

información de ambos cursos online VMware. Introduce este codigo para
conseguir tu 50% de descuento: helpme

Muchas gracias y nos vemos online!. Y recuerda, estamos disponibles para

cualquier duda, pregunta o sugerencia que tengas en este correo electrónico:

info@josemariagonzalez.es

Jose Maria Gonzalez

CEO & Founder
www.jmgvirtualconsulting.com
Virtualización con
VMware vSphere

eBook
por
José María González

José María González

info@jmgvirtualconsulting.com
http://www.jmgvirtualconsulting.com
@jmgconsulting