Vmware vSphere

Capítulo 1: Primeros pasos en la certificación VMware vSphere™
VCP550™

¿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.
Este libro pretende descubrirte todos los secretos en la instalación, configuración y gestión de
VMware vSphere™ 5 y, de paso, prepararte para la certificación de VMware VCP510.
¿Cómo conseguir la certificación VCP™ 510?
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™ 5.x
Los cursos aceptados son:
VMware vSphere 5.x: Install, Configure and Manage v5.x
VMware vSphere 5: What´s New (Este curso es necesario solo para los candidatos que
ya han pasado la certificación VCP4)

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 VCP™
510.

3. Inscribirse y aprobar el examen oficial. Para inscribirse en el examen VCP™ 5 (VMware
Certified Professional), has de darte de alta en VMware en la siguiente dirección:
http://mylearn.vmware.com/mgrReg/plan.cfm?plan=45082&ui=www_cert
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 VCP5™ en vSphere™ 5.
1. Si eres nuevo en el mundo VMware:
 Asiste al curso oficial VMware vSphere™ 5: Install, Configure and Manage.
 Aprueba el examen VCP510 en vSphere™ 5.
2. Si eres actualmente un VCP3 en VMware Infrastructure 3:
 Asiste al curso oficial VMware vSphere™ 5: Install, Configure and Manage o al curso oficial
What´s New 5.
 Aprueba el examen VCP510 en vSphere™ 5. Esta opción, solo estará disponible hasta el
29 de Febrero del 2012.
3. Si eres actualmente un VCP4 en VMware ESX/ESXI 4.x:
 Aunque no hay ninguna limitación imporante, es importante destacar que si estará limitado
en cuanto al tiempo transcurrido desde que hiciste el curso de formación hasta cuando
quieras presentarte al examen VCP510™ en vSphere™ 5. La ultima fecha que me ha dado
VMware es febrero del año 2012.
 Asiste al curso oficial VMware vSphere™ 5: What´s New 5.
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™ 5. 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
VCP5™ en vSphere 5™?
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 VCP510™ en vSphere 5™?
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 VCP510™ de vSphere™ 5?
En el examen hay 85 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™510?
En la dirección web adjunta, podrás encontrar una guía oficial VMware (VCP5 Exam
Blueprint) sobre la materia que se cubre en el examen. Usa esta guía como referencia para
preparar el examen:
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™ 5.x
En esta primera sección verás una introducción a la virtualización y la instalación de VMware
vSphere™ ESXi 5.x, los mínimos y máximos tanto soportados como certificados por VMware
vSphere™ ESXi 5/ vCenter Server™ 5.x, 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™ 5.x
¿Cómo es la virtualización con VMware vSphere™ 5.x?

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™ 5 es que la versión
vSphere™ ESX ya no está disponible.
También, ahora con la nueva versión de ESXi™ 5, es posible instalar la imagen de un ESXi 5
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™ 5 incluye una nueva versión para su sistema de archivos llamada VMFS-5
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™ 5.
Para poder ver el video tutorial de instalación de un servidor ESXi 5 y muchos más videos
tutoriales, entra en nuestra página web dedicada en exclusiva al contenido multimedia extra de
este libro en http://www.josemariagonzalez.es/video-tutoriales/formacion-vsphere-5
Alternativamente, también puedes ver videos tutoriales de instalación y configuración de
VMware vSphere ESXi 5, 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™ 5?

Una máquina virtual en VMware vSphere™ 5, 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 5, 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.
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 estas usando este libro para prepararte el examen oficial de certificación VCP™510,
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 5.
VMware vSphere™ 5 permite crear máquinas virtuales usando dos
wizards: Typical yCustom. 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.
Para poder ver el video tutorial de instalación de una máquina virtual en un servidor ESXi 5,
entra en nuestra página web dedicada en exclusiva a los videos tutoriales de contenido
multimedia de este libro en
http://www.josemariagonzalez.es/video-tutoriales/formacion-vsphere-5
Alternativamente, también puedes ver los videos tutoriales de instalación y configuración de
VMware vSphere ESXi 5 para preparar el examen de certificación oficial VCP™510 en la
página web oficial de YouTube en:
http://www.youtube.com/blogvirtualizacion
¿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.
Para ver más información sobre los tres factores más importantes a la hora de elegir un
hipervisor para el software de virtualización entra en este
enlace:http://www.jmgvirtualconsulting.com/
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 5?
A día de hoy, es posible instalar VMware vSphere™ ESXi 5 en cualquier tipo de servidor de
nueva generación. Asimismo, la lista de compatibilidad de hardware para VMware vSphere™
ESXi 5 ha aumentado considerablemente en esta última versión, debido principalmente, a que
ESXI es la única versión disponible en vSphere™ 5.
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 5
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 5 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 5

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™ 5

Durante la instalación de vSphere™ ESXi 5, 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 elinstaller 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 5.
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 hasta256 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ésGUID Particion Table en lugar del formato MBR - de las siglas en
ingles Master BootRecord - lo cual permite instalar ESXi 5 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™ 5

Ahora VMware vSphere™ ESXi 5 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 tipoService
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 Profilelocalizado 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 5.0, te recomiendo que veas el episodio número 31 de nuestro canal de
televisión web sobre la virtualización y el cloud computing en español en la siguiente dirección:
http://www.virtualizacion.tv
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: http://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.
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
canal oficial de YouTube: VMware vSphere 5.0 en entornos SAN iSCS
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ímiteJ. En
VMFS-3 el máximo número de ficheros era de 30.720 ficheros.
Diagnosticando un problema en vSphere 5
Para poder diagnosticar un problema con vSphere ESXi 5, 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.






Ayer aprendimos lo básico de la certificación oficial VMware y vimos los dos primeros
capítulos.

Hoy veremos los dos próximos capítulos, la red y el almacenamiento:

Hasta mañana,
Jose Maria Gonzalez
CEO and Founder de www.jmgvirtualconsulting.com

Capítulo 3: Red en vSphere™ 5.
La funcionalidad de red en una infraestructura virtual es de suma importancia. Permite que las
máquinas virtuales en un servidor VMware vSphere™ ESXi 5 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™ 5 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
undistributed 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 5

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 de4088. 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 5:

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™ 5

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 5 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
groupy 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 5, 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 5 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 switchesno será usada en
ningún momento de forma interna.
Las políticas de balanceo de carga en un VSS en vSphere™ 5

En VMware vSphere™ 5, el adaptador NIC físico conectado al primer puerto deManagement
Network es denominado vmk0. El primer puerto de gestión definido en nuestro servidor
VMware ESXi 5 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 5

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 5 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™ 5 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™ 5, 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 aAccept, 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
tramasaliente 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 sonReject (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 elKB
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 eloutbound 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™ 5 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
deNetFlow. 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 enKbps,
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 unport
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™ 5, 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 sourceMAC hash y explicit
failover order. Recuerda que las políticas de load balancingpara 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
enlaceupstream. 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 tipoVMkernel, 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 5

É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 5

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 switchcon 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™ 5.
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™ 5

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 elLUN 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™ 5?

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 tipodependent
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 5™

La buena noticia es que el módulo para el adaptador de fibra es reconocido por
elVMkernel 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 Rescanen
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 proveedorQlogic.
LPFC es el nombre corto del módulo del driver Linux para una HBA del proveedorEmulex.
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™ 5?

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 un video tutorial de nuestro canal de YouTube llamado:VMware vSphere 5.0 en
entornos SAN iSCSI
VMware vSphere™ 5 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™ 5

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.
También, es posible activar la opción CHAP para conexiones de tipo NFS. El protocoloCHAP
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™ 5

En vSphere™ 5 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™ 5, 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 dosport
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 5.
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 5
 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™ 5ESXi 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™ 5

vSphere™ 5 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™ 5 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 5
Ahora, en la nueva versión de vSphere™ 5, 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 5

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..
Hola,

Ayer vimos la parte de red y de almacenamiento. Hoy vermos el servidor de vCenter y las
máquinas virtuales

Hasta mañana y espero que sigas disfrutando de este curso gratuito de VMware vSphere en
cinco días!

Jose Maria Gonzalez
CEO y Fundador de www.jmgvirtualconsulting.com

P.S. Si te gustaría aprender mucho mas sobre vmware en mucho menos tiempo, ahora tienes
acceso a nuestro curso online VMware vSphere 5.5 Avanzado a un precio reducido!




Capítulo 5: VMware vCenter Server 5

https://www.youtube.com/watch?v=Dgz_G8wwqI4

Posiblemente vCenter Server sea considerado el componente más importante de una
infraestructura virtual en VMware vSphere™ ESXi 5. 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™ 5.
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™ 5 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 5 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 5 - 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 5.

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án instaladas 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:
 De 1-10 hosts ESXi o 1-100 máquinas virtuales: 4GB mínimo recomendado
 De 10-100 hosts ESXi o 100-1.000 máquinas virtuales: 8GB mínimo recomendado.
 De 100-400 hosts ESXi o 1.000-4.000 máquinas virtules:13GB mínimo recomendado.
 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 5?
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
hacerbackup/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 canal oficial de YouTube: ¿Cómo instalar VMware Data
Recovery?
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 Managerpuedes 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™ 5
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™ 5?

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 yDHCP. 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™ 5?

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™ 5

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 soporteVMI
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 athin 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.