VMware Por VExperts

#VMwarePorvExperts www.vmwareporvexperts.
org
¡Descarga gratuita
sin registro!
El Libro de VMware
VMware
por vExperts
por Bloggers
Versión 1.0
14 Bloggers unidos por un Proyecto solidario.

Todo el dinero recaudado gracias a nuestros Sponsors va
a ser donado a dos causas solidarias.
Miguel Angel Alonso • Xavier Caballé • Patricio Cerda • Federico Cinalli • Jorge de la Cruz •
Xavier Genestos • Hector Herrero • Ricard Ibáñez • Gorka Izquierdo • Leandro Ariel Leonhardt
• Miquel Mariano • Daniel Romero • Ariel Sánchez • Raúl Unzué
Prólogo por Duncan Epping
VMware por vExperts
© 2019 - Autores libro
Reservados todos los derechos. Esta publicación está protegida por las leyes de propiedad intelectual.
No se permite distribuir ni parcialmente, ni totalmente, la publicación a través de cualquier medio,

soporte, sin autorización expresa de los autores.
Todas las marcas, nombres propios, que aparecen en el libro son marcas registradas de sus respectivos
propietarios, siendo su utilización realizada exclusivamente a modo de referencia.
Los autores del libro no se hacen responsables de los problemas que pueda causar en su infraestructura,
siendo responsabilidad de los administradores de sistemas realizar las copias de seguridad, planes de
contingencia y laboratorio de pruebas previo antes de aplicar cualquier cambio en los servidores de
producción.
#VMwarePorvExperts 3
Los vExperts
Miguel Ángel Alonso
Hola, me llamo Miquel Ángel Alonso y soy Consultor y Arquitecto en soluciones de virtualización y
Cloud Computing en JMG VirtualConsulting.
En lo profesional, cuento con unos 15 años de experiencia en el ámbito de sistemas y en los últimos
años 10 me centré en la virtualización y automatización del datacenter y en estos últimos 5 en Cloud
Computing, HCI y SDN. También me encanta la docencia y trabajo dando cursos como instructor de
VMware VCI desde el año 2011:
• Diseño, implementación y administración de grandes entornos VMware vSphere

• Instalación, configuración y administración de almacenamiento EMC, DELL y NETAPP
• Instalación, configuración y administración de NUTANIX (NPP)
• Instalación, configuración y administración de vCloud Director, AWS y NSX para entornos Cloud.
• Disaster Recovery con VMware SRM y Veeam Backup & Replication.
• Experto en VDI con VMware Horizon Suite
• Soy VMWARE vExpert 2015,2016,2017,2019 y VMWARE vExpert 2018 NSX
Blog http://www.josemariagonzalez.es/author/miguel-angel-alonso-pomar
Twitter @miguelaalonso
Iinkedin https://www.linkedin.com/in/miguel-angel-alonso-5a54a730/
Agradecimientos
La verdad es que tengo muchos y no sabría por dónde empezar con lo que lo haré de uno en uno para
no olvidarme de ninguno.
Quiero dar las gracias a José María González y mi empresa JMG VirtualConsulting por darme la
continua posibilidad de aprender en estos 10 últimos años y el tiempo para realizar el libro.
A Fede, Hector, Leo y demás Bloggers que han escrito el libro, por su dedicación, sus buenas intenciones
y maravillosos conocimientos.
¡¡Y cómo no!! Y de manera muy especial a mi suegra que tiene por desgracia la enfermedad de
Alzheimer y que es uno si no el más importante de los motivos por el cual me he sentido más atraído a
escribir este libro y poder ayudar a todos aquellos que están inmersos en tan mala experiencia.
Y por último pero no menos importante a mi mujer e hijo por estar siempre a mi lado en los buenos y
malos momentos…. ¡¡¡Mil Gracias!!!
Xavier Caballé
Mi nombre es Xavier Caballé, soy administrador de sistemas informáticos desde hace más de veinte
años. Mi trabajo está orientado al soporte técnico, mantenimiento e instalación de infraestructuras de
red.
Entre mis labores habituales, se encuentran la administración y mantenimiento de

entornos basados en un dominio de Active Directory, y todos los servicios asociados a él. Como
pueden ser, los servidores DNS, DHCP, servicios de impresión, directivas de grupo, y los servidores
de ficheros.
También me dedico a la instalación y gestión de servidores de correo electrónico basados en Microsoft

Exchange server o Office 365 con Exchange OnLine.
En la actualidad, una gran parte de mi tiempo laboral lo consume la configuración y administración de

entornos de VMWare.
Tampoco podemos olvidar la gestión y programación de tareas de copia de seguridad con distintos
productos de backup. Como pueden ser, VEEAM, ARCServe o BackupExec.
Soporte técnico de Hardware de servidores y dispositivos de almacenamiento de grandes marcas

como HP, DELL, IBM, Fujitsu.
En lo personal, dedico gran parte de mi tiempo libre a la fotografía paisajística y estar al aire libre con
mi familia. También soy el autor de un blog dedicado a la tecnología de la información http://www.
pantallazos.es y del canal de YouTube https://www.youtube.com/c/pantallazoses
Agradecimientos
En primer lugar, me gustaría agradecer de a Fede, Héctor, y Xavi la oportunidad que me han brindado
ofreciéndome poder colaborar en este proyecto solidario. Ha sido una aventura muy enriquecedora.
También, me gustaría agradecer a mi mujer y mi hija, a las que tantas horas he robado, para poder
dedicarlas al proyecto de pantallazos.es. Sin ellas, nada sería posible.
Por último, me gustaría decir que todos los que escribimos un blog o simplemente compartimos algún
conocimiento por Internet, lo hacemos llevados por un impulso de querer aportar algo al resto de la
comunidad.
La gran mayoría de nosotros, la única recompensa que conseguimos después de invertir un gran
número de horas a la creación de nuevo contenido, es el sentimiento de haber hecho algo bueno para
otra persona a la que ni siquiera conoces.
En alguna ocasión, nuestro trabajo nos permite sentir el agradecimiento de alguien a quien has ayudado
y este alguien siente la necesidad de escribir un comentario positivo o un agradecimiento. En estas
contadas ocasiones, el sentimiento de alegría es muy grande.
Con todo esto me gustaría agradecer también, a todos los patrocinadores que se han unido al proyecto
y también a los que se unirán en el futuro. Por el inmenso orgullo que nos han hecho sentir, a todos
los coautores del libro, al permitirnos ayudar a las dos ONG’s seleccionadas de una forma que ha
superado con creces la mejor de nuestras expectativas.
Patricio Cerda
Hola, mi nombre es Patricio Cerda, y actualmente trabajo como consultor independiente tanto en
Europa como para Latinoamérica.
Comencé mi carrera profesional por allá por el año 2001, cuando comencé trabajando como
desarrollador por poco más de 1 año. Luego de pasar algunos años deambulando por muchas ramas
de la informática, incluyendo unos años trabajando con soluciones de seguridad (Firewalls, IDS/IPS),
así como también con soluciones Microsoft (AD, Exchange y Sharepoint), finalmente me encontré
un día haciendo pruebas con VMware Server 1, creando mi primera máquina virtual para simular
un entorno de producción. Era el año 2006 y sin saberlo comenzaba mi aventura en el mundo de la
virtualización.
Muchos años han pasado desde aquello, y en el camino me he ido especializando en múltiples
soluciones y tecnologías, comenzando con soluciones VMware como NSX, Virtual SAN y vRealize
Suite, asi como de otros fabricantes como Veeam, Nutanix, Brocade y Dell EMC. Durante este proceso
además me convertí en instructor oficial VMware (VCI) el año 2014, para 3 años más tarde convertirme
también en instructor oficial Veeam (VMCT).
Creo profundamente en compartir mis experiencias y conocimientos con la comunidad, para poder así
retribuir lo que la comunidad me ha aportado en mi formación profesional. Pensando en eso es que
comencé con mi blog el año 2009, y también esto fue lo que me llevó a dar el paso de convertirme en
instructor.
Además de la tecnología, soy un aficionado a la fotografía, hobbie que adopté luego de que mi labor
como consultor me llevara a visitar múltiples países. Ahora tomo cada uno de estos viajes como una
oportunidad para recorrer nuevas ciudades y poder así retratarlas con mi cámara.
Me pueden encontrar en mi blog y en redes sociales:
• Blog: https://patriciocerda.com
• Twitter: https://twitter.com/patote83
• LinkedIn: https://www.linkedin.com/in/prcerda/
• Instagram: https://www.instagram.com/patricio.rcc/
Agradecimientos
En primer lugar, agradecer a Federico Cinalli por permitirme ser parte de este proyecto. Cuando Fede
nos propuso la idea de escribir este libro, no dude ni un instante en sumarme a este esfuerzo conjunto,
el cual además de ser un aporte a la comunidad, nos permite llevar a cabo una labor solidaria.
Un agradecimiento especial además a Dagoberto Araya, amigo desde mis tiempos de Universidad.
El me abrió la puerta a una enorme oportunidad profesional 11 años atrás, que finalmente me ha
permitido llegar a donde estoy ahora.
Agradecer a mi familia, a mi madre y a mis amigos. Casi todos ellos están a miles de kilómetros de
distancia, pero son mi constante apoyo y un pilar fundamental en mi vida. La distancia no disminuye
ni un centímetro el amor que siento por ellos.
Finalmente agradecer a los sponsors que han creído en este proyecto, y en el espíritu solidario del
mismo. Gracias a todos los lectores de este libro, espero que lo disfruten!!!
Federico Cinalli
Soy instructor oficial de VMware dictando cursos oficiales para los clientes de la propia compañía en
la zona de EMEA como instructor externo.
Formo parte del equipo de Cloud Solutions Architects de Adistec para las divisiones AEC (Adistec
Enterprise Cloud) y APS (Adistec Professional Services).
Participo en proyectos de diseño, sizing, implementaciones y health checks para soluciones de

vSphere, vSAN y la Suite vRealize en Europa, Oriente Medio y América.
Suelo colaborar con sesiones en vBrownBag, VMUG’s y presentaciones de diferente tipo tanto para
fabricantes como, sobre todo, para la comunidad.
Cuando el tiempo me lo permite encuentro la paz trabajando con madera y elaborando cerveza
artesanal.
Cuento actualmente con las certificaciones VCIX6-DCA, VCAP5-DCA, VCAP5-DCD, VCP6-CMA,

VCP6-NV, VCP7-DT, VCI L2 y el reconocimiento VMware vExpert desde el año 2014.
Agradecimientos
Quiero agradecer ante todo, y de forma muy especial, a mis 13 compañeros, ya que sin ellos no
hubiera sido posible este proyecto. Cada uno de ellos robó tiempo a su familia para colaborar de forma
totalmente desinteresada con este proyecto.
Como no podía ser de otra manera también quiero agradecer a mi propia familia, mi mujer y mis dos
hijas, la comprensión y paciencia infinita que permitieron que dedicara muchas horas a este proyecto.
Por último y no menos importante quiero agradecer a los sponsors. Entre los autores del libro y los
sponsors estamos ayudando a dos nobles causas benéficas, además de compartir de forma gratuita
un gran contenido para muchos lectores en su propio idioma.
Quiero dedicar este libro a mi mujer Roxana y a mis hijas Chiara y Olivia a quienes amo profundamente.
Jorge de la Cruz
Mi nombre es Jorge de la Cruz, actualmente trabajo como Systems Engineer para la empresa Veeam,
en Reino Unido, mi experiencia en la informática se remonta al año 2005, donde comencé como
Administrador de Sistemas para un ciber-café, posteriormente desarrollé medio año en Java para
Vector Software y comencé pasado este tiempo en el mundo de la consultoría de sistemas.
Recuerdo todavía cómo fue mi primera incursión con VMware ESX 3.0 y VirtualCenter 2.0, y el posterior
3.5 y las increíbles novedades presentadas en vSphere 4.0. Comencé desplegando un single-node
con almacenamiento en una HP MSA y ese entorno escaló a múltiples VNX con cientos de VMs
ofreciendo servicio de Hosting.
Una de las experiencias más bonitas que tengo de mi tiempo como consultor fue en Anadat Consulting,
para los que nos lo conozcáis Anadat es una empresa ubicada en Rivas-Vaciamadrid. Anadat Consulting
ofrece todo tipo de servicios de virtualización, consultoría de sistemas, despliegues de entornos,
Hiperconvergencia, Software-Defined Datacenter, y mucho más. Una empresa que me formó como
profesional, y en la que tuve la oportunidad de conocer a muchos profesionales del sector, entre ellos
Christiam, Óscar, Marcos, Héctor, Bernardo, etc.
Me uní posteriormente a la solución open source de correo electrónico y colaboración, Zimbra, donde
estuve cuatro años creando contenido de todo tipo, Wikis (https://wiki.zimbra.com), blogs (https://blog.
zimbra.com/author/jcruz) e incluso tuve la suerte de dirigir la estrategia de Product Marketing y Product
Management.
Mis competencias profesionales se basan alrededor de la virtualización de centro de datos, esto es

desde la Infraestructura como es Compute, Storage y Networking, hasta la capa de virtualización y
abstracción del Hardware, pasando por monitorización usando herramientas open source y comerciales
y seguridad incluyendo Cisco, SonicWall, FortiGate y PaloAlto.
Actualmente escribo desde hace muchos años en https://jorgedelacruz.es donde tengo la suerte de
contar con unos 3000 lectores cada día, más datos y formas de contactarme:
• Blog: https://jorgedelacruz.es
• Twitter: https://twitter.com/jorgedlcruz
• Linkedin: https://www.linkedin.com/in/jorgedelacruzmingo/
• YouTube: https://www.youtube.com/user/jorgedlcruz23
• Email: Jorge.delacruz@jorgedelacruz.es
• Teléfono: +1 202 738 4705
Agradecimientos
No puedo dejar de agradecer a mi mujer Irina y mi hija Victoria el tiempo que no dedico a ellas porque lo
dedico a seguir aprendiendo, trabajar o crear contenido, incluido este libro. Al lado de todos nosotros,
tenemos muchas personas que nos entregan todo sin pedirnos nada a cambio, mis humildes capítulos
se los dedico a ellas.
También agradecer a Federico Cinalli dejarme participar en el proyecto, y por supuesto a todos los
profesionales que han participado en este libro, yo ya me he leído sus capítulos y es lo mejor que he
leído sobre VMware en toda mi vida.
Por último, agradecer a todos los patrocinadores que han contribuido al proyecto para las causas
solidarias de CEAFA y Banani.
Xavier Genestós
• Administrador de sistemas: Entornos Microsoft, GNU/Linux, VMware, entre otros. (Año 2001 hasta
la actualidad).
• Formador IT: Cursos prácticos sobre VMware, Active Directory, Exchange, GPOs, Linux, etc. (Año
2006 hasta la actualidad).
• Escritor de libros de IT: 12 libros publicados: (Año 2012 hasta la actualidad).
WS2012LABS - Windows Server 2012

EX2013ADM - Exchange Server 2013
WFS - Windows File Server
GPOIT - Group Policy Objects para administradores de IT
ADIT - Active Directory para administradores de IT
LinuXe - Linux para empresas
VBESXi - Veeam Backup sobre ESXi
EX2016ADM - Exchange Server 2016
RDSIT - Remote Desktop Services para administradores de IT
WIN10IT – Windows 10 para administradores de IT
• Blogger en https://www.SYSADMIT.com: (Año 2013 hasta la actualidad)
Enlaces
Blog:
https://www.sysadmit.com
Linkedin:
https://es.linkedin.com/in/xaviergenestos
Grupo SYSADMIT en Linkedin:
https://www.linkedin.com/groups/8550757
Twitter:
https://twitter.com/sysadmit
Agradecimientos
Quería aprovechar este fragmento para agradecer al resto de bloggers su gran trabajo y dedicación
en este proyecto, también a la familia y amigos por su apoyo y por supuesto a todos los que habéis
decidido dedicar vuestro tiempo a leer esta publicación conjunta: ¡Seguro que os gustará!
Héctor Herrero
¡Hola! Soy Héctor Herrero, un bilbaíno pura cepa. Tengo 37 años y desde los 19 años en este sector
dando guerra. Actualmente trabajo y soy responsable de Open Services IT, una empresa orientada a los
servicios TIC especializados, donde mimamos y cuidamos de nuestros clientes, ahí realizo proyectos,
consultorías o formaciones entre otros.
Aunque seguramente alguno que otro igual me conoce del Blog Bujarra.com, que desde hace la tira de
años voy escribiendo manuales y How To’s de todo con lo que he ido descubriendo. Ya lo sabéis, me
encantan las Raspberry Pi, por todo lo que nos pueden aportar en el negocio y en el hogar, haciéndolo
todo más inteligente.
Un apasionado de las tecnologías, últimamente con más profundidad en el mundo de la monitorización

con Centreon, Grafana, NagVis o Stack de ELK entre otros. Como sabéis otro de los pilares es la
virtualización, tanto de infraestructuras con productos de VMware cómo virtualización de aplicaciones
y escritorios con la familia de Citrix. Heredero del mundo Microsoft, donde he vencido batallas desde
Windows NT o migraciones de Exchange hasta hoy Office 365.
Mentalidad Open,
Compañía: www.openservices.eus
Blog: www.bujarra.com
Twitter: @nheobug
Linked In: https://www.linkedin.com/in/hectorherrero/
Agradecimientos
Quería agradecer a cada autor de este libro el poner su granito, el tiempo que ha dedicado para
que hayamos podido obtener la gran recompensa de asegurarnos la finalización del hospital en Mali.
Gracias a todos los que habéis donado y por supuesto a las ONGs que llevan a cabo el trabajo que
los demás no hacemos.
Y por supuesto dedicarle mis capítulos a mi txabala Seila y mi recién hijo, Leo. ¡Gracias por vuestra
paciencia y amor!
¡Compartir y ser felices!
Ricard Ibáñez
Administrador de sistemas y especialista en soluciones VMware y Microsoft con más de 10 años de
experiencia.
Apasionado de mi familia, a la cual, le intento dedicar todo mi tiempo libre, menos las horas de escribir
el capítulo de este libro.
Me encanta la tecnología desde que tengo memoria y, sobre todo, los gadgets que simplifican la vida
o a veces hasta me la complican.
Llevo en el mundo tecnológico, hace ya más de 10 años. He pasado por casi todas las fases IT, desde
dar soporte Helpdesk a usuarios, dar soporte avanzado a departamentos de IT de clientes, diseñar e
implementar soluciones tecnológicas VMware, Microsoft y Veeam, entre otras, para clientes de ámbito
nacional. También he ejercido de profesor de tecnologías Microsoft y VMware, e incluso, he tenido
que pelearme con presupuestos y gestión del departamento IT. Este camino, me ha dado mucha
perspectiva de mi profesión e intento aplicar todo lo aprendido en mi día a día, además de seguir
aprendiendo de los que me rodean.
Soy Blogger hace más de 7 años, escribiendo sobre todo tipo de tecnologías de una manera muy
práctica, documentando procesos que simplifiquen las tareas a los administradores de sistemas y he
sido recompensado con cuatro estrellitas vExpert 16/17/18/19.
Blog: www.cenabit.com
Twitter @ricardibanez
LinkedIn: Ricard Ibáñez
Dedicatoria/Agradecimientos
Desde el primer momento que me propusieron colaborar con la escritura de un capítulo, para un
libro puramente técnico, el cual tenía tantos y tan buenos colaboradores, no pasó ni 1 segundo que
ya quería empezar a escribir y aún era más motivador saber que colaborar con este libro, ayudaba
directamente en proyectos solidarios.
Este libro, no existiría sin Xavi, Héctor y Fede, los cuales han conseguido motivar a 14 cracks de IT
para sacar adelante el proyecto y agradecer a todos y cada uno de estos cracks por dedicar este
tiempo, que lo tenemos que robar de otras tareas, normalmente familiares.
También agradecer a todos los Sponsors del libro, los cuales han conseguido más de 25.000€ para los
proyectos solidarios con los que colaboramos, que es la base de este proyecto.
Le dedico esta pequeña porción de conocimiento a mi familia por aguantar ausencias en los momentos
críticos de mi profesión y a todos los lectores interesados en aprender cada día.
Gorka Izquierdo
Hola, soy Gorka Izquierdo Bizkarrondo y trabajo el en Dpto. de Datacenter en vSolutions-SomosCloud.
Aparte de la tecnología que es una de mis pasiones, me gusta aprovechar los fines de semanas para ir
a mi pueblo a dar vueltas por el monte y de paso volar un Drone que tengo, un Phantom 3 Advanced,
volarlo entre las montañas y el rio Irati del Pirineo Navarro es uno de mis mejores momentos, hace que
por un momento desconecte de todo el estrés producido durante la semana.
Antes de meterme en el mundo de la tecnología pase 12 años trabajando por diferentes empresas
del sector del metal, donde trabaje como soldador, prensista, operario en cadenas de producción,
haciendo remolques de camión etc. Hasta que un día tuve la oportunidad de empezar a estudiar un
área totalmente desconocida para mí, la informática (a veces me arrepiento de esto).
Todos estos años en un continuo autoaprendizaje he sacado las siguientes certificaciones:
LPIC-1 y LPIC-2, MCSA Microsoft Windows Server 2003, MCP Server 2012 ,VCP5-DCV, VCP6-DCV,
VCP6.5-DCV de VMware, VMCE de Veeam Backup , ITIL v3
Y donde gracias a escribir en un blog he recibido los siguientes galardones:
• VMware vExpert, por cuatro años seguidos

• Veeam Vanguard en el año 2016
Me podéis seguir en mi blog https://aprendiendoavirtualizar.com

Linkedin https://www.linkedin.com/in/gorkaizquierdobizkarrondo/
Twitter https://twitter.com/vGorkon
Facebook https://www.facebook.com/aprendiendoavirtualizar/
Agradecimientos
Sin duda, a la primera persona que mas quiero dar las gracias es a Fede por todo lo que ha hecho
y se ha movido, también a Héctor y Xavier Genestós porque junto a Fede tuvieron la idea de este
gran proyecto con fines solidarios y en el que no dude en ningún momento en poder aportar mis
conocimientos, gracias por contar y confiar en mí, por eso he intentado hacer lo mejor posible mi
trabajo y espero que haber dado la talla.
Agradecer a los Sponsors su ayuda y donaciones, sin ellos este proyecto no hubiese sido posible.
Gracias a sus donaciones, muchas personas podrán mejorar su calidad de vida.
Gracias a mi mujer y mi hija por la paciencia y por no haberme echado de casa, gracias a todos mis
compañeros de este proyecto por el duro trabajo y haberlo dado todo y un poco más. Por último, dar
las gracias a vSolutions-SomosCloud por su ayuda desinteresada.
Leandro Ariel Leonhardt
Hola, mi nombre es Leandro Ariel Leonhardt, me encanta la informática y la música electrónica, en mis
ratos libres, desconecto de la rutina y del mundo virtual “haciendo/mezclando” música.
Desempeño la función de ingeniero/consultor de sistemas en una gran empresa, Sothis.
Ex instructor oficial de VMware, impartí más de 30 cursos en casi dos años, desde la instalación
y configuración de centro de datos virtuales, virtualización del almacenamiento, optimización &
escalabilidad, resolución de problemas y gestión de recuperación de desastres, cursos oficiales tales
como VMware Virtual SAN, Optimize & Scale, ICM, Fast Track, What’s New, Troubleshooting & Site
Recovery Manager.
Autor de los cursos en Udemy: Nutanix y VMware vSAN
Algunas de mis certificaciones y acreditaciones:
Ex VMware VCI, VCAP-DCA, VCP-DCV & VCP-NV. Nutanix NPP 5.0 & 4.5, NSEC, NSES, NSEN
& Nutanix Technology Champions (NTC) 2017/2018. Nombrado vExpert Pro y vExpert por VMware
desde el año 2013, vExpert vSAN 2019/18/17/16 & vExpert Cloud 2017.
Más información sobre mi trayectoria en: http://www.leandroleonhardt.com y en el blog: https://www.

blogvmware.com
Twitter: https://twitter.com/leonhardtla
Linkedin: https://www.linkedin.com/in/leonhardtla/
Dedicatoria/Agradecimientos
En primer lugar, quiero agradecer a mi mujer y a mi hijo, por apoyarme no sólo en este proyecto, en
todo lo que me propongo.
A mi familia, padres y hermanos, muy orgullos de mi por colaborar con este proyecto caritativo.
A mis compañeros/amigos de profesión, Juan Vicente, Mario, Diego, Nacho’s, Sean, por compartir sus
conocimientos y aprender de los mejores, día a día.
Agradezco a todos los autores del libro, por la profesionalidad, por el tiempo y esfuerzo que hicimos en
sacar este proyecto adelante, con la ilusión de ayudar a mucha gente, tanto en lo económico (ONG)
como en lo profesional, para la comunidad.
Por último, a todos los patrocinadores, que hicieron posible progresar con los objetivos de las ONG
gracias al dinero recaudado.
Miquel Mariano
Hola, me llamo Miquel Mariano Ramis y soy Consultor TI en Ncora
Aparte de la tecnología, me encanta el deporte al aire libre. Aunque viva en una isla como Mallorca, soy
mas de montaña que de playa, así que es fácil encontrarme por el monte haciendo MTB, corriendo o
simplemente practicando algo de senderismo.
En lo profesional, cuento con mas de 10 años de experiencia en el ámbito de sistemas y en los

últimos años he centrado mi trayectoria profesional especializándome en todo lo relacionado con la
virtualización y automatización del datacenter:
• Diseño, implementación y administración de grandes entornos VMware vSphere

• Instalación, configuración y administración de almacenamiento Hitachi HUS, VSP Gx00, EMC
VNXe, IBM Storwize, QNAP
• Instalación, configuración y administración de SAN con Brocade FC Switches
• Amplios conocimientos en protocolos de almacenamiento: iSCSI, FC, NFS, SMB/CIFS
• Instalación, configuración y administración de servidores Dell PowerEdge, HP Proliant, Hitachi
Compute Blade
• Disaster Recovery, Veeam Backup & Replication y continuidad de negocio
• Análisis de carga de trabajo, performance y dimensionamiento de máquinas virtuales
• Automatización con Ansible, scripting con PowerCLI, bash, …
• Monitorización con PRTG Network Monitor
He tenido la suerte de poder sacarme algunas certificaciones de VMWare y en estos últimos 4 años,
VMWare me ha nombrado #vExpert
Agradecimientos
En primer lugar, quiero agradecer profundamente a los mentores de este proyecto Fede, Héctor y
Xavi. Sin ellos nada de esto hubiera sido posible. Agradecer que pensaran en mí para contribuir en el
contenido y agradecer a todos los blogguers implicados en el proyecto, su dedicación y esfuerzo para
crear contenido de calidad y cumplir los plazos que nos marcamos desde el inicio.
En segundo lugar, quiero hacer un agradecimiento especial a mi actual empresa, www.ncora.com, sin
ellos nunca hubiera tenido la oportunidad de crecer tanto a nivel profesional y nunca hubiera estado en
las quinielas para participar en este libro.
En tercer lugar, a mi familia. Al final ellas, mi mujer y mi hija han sido las grandes afectadas y las que
han visto mermadas sus horas de dedicación en beneficio del proyecto.
Y para finalizar, como no, a todos los sponsors que han creído en el proyecto desde el minuto 0 y a
todos los lectores que han decidido dedicar su tiempo en leer nuestro libro.
¡Gracias a todos!
Daniel Romero
Hola, soy Daniel Romero Sánchez y actualmente trabajo como CTO en ilusia®
A nivel profesional llevo más de catorce años dedicados al sector TI. Comencé mi andadura profesional
como administrador de sistemas centrándome en el mundo de la monitorización, entendiendo las
arquitecturas de sistemas y desarrollando scripts para monitorizalas.
Con el paso de los años comienza mi pasión sobre el mundo de la virtualización y el cloud computing,
de ahí mi especialización en VMware, AWS o OpenStack.
Durante casi toda mi carrera he tenido siempre claro que no hay que realizar tareas repetitivas. Y como
siempre he tenido bastante curiosidad por el desarrollo, he creado decenas de scripts para automatizar
despliegues y tareas, liberando a los equipos de desarrollo de labores fuera de su alcance.
Estar en continuo contacto con la programación me ha llevado a aprender como diseñar arquitecturas
de aplicaciones ya sean monolíticas o basadas en microservicios.
Ahora gestiono a un equipo de TI, a la vez que superviso la infraestructura, políticas de seguridad o
nuevas tecnologías adaptables a nuestros servicios.
Me considero una persona autodidacta que no puede parar de conocer cómo funcionan las tecnologías
emergentes. Todos mis conocimientos los plasmo en el blog www.dbigcloud.com.
BLOG: www.dbigcloud.com
Twitter: @drsromero
Linkedin: Daniel Romero
Dedicatoria / Agradecimientos
Llegar hasta aquí no ha sido fácil, han sido muchos años de formación y trabajo, pero no estaría
escribiendo estas líneas si no hubiese sido por mi hermano que fue quien me abrió las puertas de este
mundillo. ¡Gracias!
He tenido siempre la suerte de rodearme de gente que me ha aportado conocimiento. A todas y todos
con los que he trabajado, compartido charlas, momentos e incluso discusiones, gracias. Algunas y
algunos me habéis ayudado a entender mejor esta profesión, otras y otros me habéis enseñado a
escribir un poco mejor e incluso animarme a seguir haciéndolo. Sinceramente muchísimas gracias.
También quiero agradecer a todas y todos los bloggers que comparten su conocimiento y tiempo de
forma desinteresada, en especial a todos los que han hecho posible este proyecto. Por último, a los
patrocinadores que han puesto su granito de arena aportando recursos a las causas solidarias de
CEAFA y Banani.
Ariel Sánchez Mora
Soy costarricense, viviendo actualmente en EEUU. Soy ingeniero electrónico pero mi pasión es la
tecnología de información y especialmente VMware.
Tengo certificaciones como VCIX-DCV y VCP-NV, y he sido aceptado como vExpert desde el 2015.
Participo en las subespecialidades de vExpert NSX y PRO. Trabajo actualmente como Senior Technical
Account Manager para VMware. Algún día, tendré el VCDX!
Soy miembro de @vBrownBag así como host de @vBrownBagLATAM. He presentado en VMworld

y en múltiples grupos locales de VMUG en los EE.UU., y ayudo a @pghvmug como miembro de su
comité.
Mi twitter es @arielsanchezmor y ahí me encanta interactuar con otros miembros de la comunidad. Te

pido que hagas una cuenta y te nos unas.
Agradecimientos
Agradezco a los valientes co-autores de este libro, que desde el momento que se les ofreció, no
dudaron en participar. De ellos, quiero recalcar que Federico Cinalli es un ángel que camina entre
nosotros, tiene paciencia infinita y siempre nos alentó a dar lo mejor de cada uno. Cuando sea grande
quiero ser como él; @FCinalliP es su Twitter.
Agradezco también a los sponsors que están hoy, y los que vendrán en siguientes publicaciones. Esta
es una situación donde todos ganan y podemos hacer aún más.
También agradezco a cada lector, porque van a crear la siguiente versión de este documento - hay
varios más expertos latinos que querrán participar. Cada vez que ayudas a alguien por internet o en
un VMUG en tu idioma, estas ayudado a que todos los que hablamos español mejoremos. Somos una
comunidad unida, lo veo cada VMworld.
Finalmente, agradezco a Dios por esta vida tan linda.
Al escribir este libro en español recordaba comúnmente la ortografía y gramática que me enseñaron
mis padres Dennis y Glenda, y mi tía Zuray, que es filóloga. Estoy seguro que ellos tres van a ayudarme
a encontrar varias mejoras, y los amo por ello.
Todo lo que hago es para mi esposa Amy. Te amo.
Raúl Unzué
Hola, soy Raúl Unzué Pulido. Administrador de sistemas desde hace casi 20 años, y ahora puedo
decir, co-autor de un “libro”. jeje!!
A nivel profesional me he especializado en virtualización, pero lo que realmente me atrae es poder

trabajar con cualquier tecnología.
Los últimos 10 años diseño y ejecuto proyectos tanto en empresas privadas como en entidades
gubernamentales. Ayudo con todo el proceso (diseño comunicaciones, soluciones de backup, hardening
infraestructura,…) hasta la entrega del proyecto al cliente final.
VMware vExpert desde el año 2013 por el blog “El Blog de Negu” del cual me siento muy orgulloso.
Aunque he trabajado muchos años con VMware, en la actualidad también me he especializado en

otras tecnologías de virtualización como las soluciones Citrix(más de 10 años de experiencia), Hyper-V
o Containers
Actualmente, soy Analista de sistemas e Infraestructuras IT. Disfruto siendo la “navaja Suiza”,
gestionando proyectos en clientes de diferentes tamaños.
En lo personal, me gusta la montaña, viajar, el deporte, la música y estar con mi familia haciendo las
dos primeras.
https://www.maquinasvirtuales.eu
TWITTER: @elblogdenegu
LINKEDIN: https://www.linkedin.com/in/raúl-unzué-pulido-b11a4b48/
Dedicatoria / Agradecimientos
Difícil saber a quién agradecer algo como un libro, para alguien que no se considera escritor.
Pero tanto este proyecto como el blog, no podrían ser posibles sin la ayuda de mi familia, que aguanta
mis largas noches en vela, y en este caso, los fines de semana creando el contenido, la web, los labs...
También se lo dedico a mi padre, que estoy seguro, habría estado orgulloso.
A Roberto Orayen por ser unos de mis mentores todos estos años, y ayudarme con sus anotaciones.
Y gracias a Héctor, Fede y Xavi, porque desde el primer momento que nos conocimos tuve la sensación
que algo grande iba a llegar. Gracias por invitarme a participar.
“Si aquello que entregas nació de corazón, allí donde lo deposites será bien recibido”
VMware por vExperts
Este libro es producto de mucho tiempo y esfuerzo por parte de 14 Bloggers de habla hispana. El
objetivo principal fue regalar un libro a toda la comunidad hispanohablante que pueda ser leído en
lengua materna, basado en el Software Defined Data Center de VMware y productos relacionados.
Evidentemente no es un libro convencional como los escritos por uno, dos o hasta tres autores. En
estas páginas vas a encontrar diferentes estilos y formas de transmitir conocimientos como cada uno
de los autores está acostumbrado a hacer en su propio Blog.
Este libro trata además de la comunidad, de compartir, de aportar sin pedir nada a cambio y de colaborar
con los que más necesitan.
Por estos motivos es que decidimos que el libro sea electrónico y gratuito con el fin de que en cualquier
lugar del mundo alguien pueda descargarlo sin importar su ubicación geográfica y sus recursos
económicos.
También subimos la apuesta involucrando a varios Sponsors para ayudar a dos causas sociales a las
que, feliz y orgullosamente, podemos decir que hemos sido capaces de poder recaudar más de 27.000
€.
Esta es la primera versión del libro y esperamos con ansias recibir tu feedback constructivo a través
de Twitter con el hashtag #VMwarePorvExperts, Linkedin o email para poder mejorar en las próximas
versiones, las cuales contarán seguramente con una mayor cantidad de autores de habla Hispana.
Finalmente, después de muchísimo esfuerzo y con toda la ilusión del mundo deseamos que disfrutes
del libro, que lo leas y lo vuelvas a leer, que lo compartas, lo recomiendes a un amigo o amiga, que te
ayude en tu día a día a mejorar, tal vez a prosperar y que te prepares para la próxima edición que será,
sin lugar a dudas, mejor que esta.
AMAFESTIVAL. CASA DE MATERNIDAD DE BANANI, MALI, ÁFRICA.
El presente proyecto nació en el año 2008. Varias personas, entre ellas un abogado de derechos
humanos, Martí Cànaves, realizaron un viaje por el llamado País Dogón, lugar situado en el corazón
de Mali, África.
Después de convivir en distintas zonas se estableció una relación especial con el poblado de Bananí,
este pequeño lugar tiene una población estimada entre 3.000 y 5.000 habitantes, la mayoría niños, y
el propio Consejo de Ancianos pidió a estos viajeros ayuda. Para ellos era fundamental y una cuestión
de supervivencia de su cultura poder tener un centro de salud y maternidad, ya que los hospitales
más cercanos se encuentran a varios km y el acceso hasta allí es muy difícil, hay que caminar por
un terreno muy abrupto, una falla llena de piedras, pendientes y dificultades. El problema se agrava
cuando alguna persona tiene problemas de movilidad o en embarazos de riesgo, habituales sobre todo
por problemas de desnutrición y hambruna; en consecuencia muchas mujeres no llegan al hospital y
pierden el feto o mueren.
De esta manera nació AMAFESTIVAL, se creó una asociación sin ánimo de lucro en Pollença,
Mallorca, Asociación Amics de Cala Carbó, y se organizó un festival de carácter anual de acción
social y cultural dedicado a las mujeres. A lo largo de estos años se han celebrado distintas ediciones
en Mallorca, Tarragona, Almería y Cantabria. Además de festivales, y con el objetivo de recaudar
fondos, se han hecho todo tipo de actos culturales, exposiciones, mercados, participación en otros
eventos, merchandising, y sobre todo aportaciones económicas personales de miembros y personas
cercanas a la mencionada Asociación. El nombre de Ama se decidió por considerar que amar es la
mejor herramienta contra cualquier tipo de violencia y para hacer un homenaje a la mujer y denunciar
la violencia machista, grave lacra que azota nuestras sociedades.
Nuestros objetivos son:
• Promover la participación de la sociedad para que todas aquellas personas que quieran lanzar un
mensaje a favor del amor, el respeto y la comunicación entre los seres humanos, puedan hacerlo
conjuntamente.
• Reivindicar y aportar ejemplos de la importantísima contribución de las mujeres a la sociedad.
• Provocar la reflexión entorno al maltrato machista y promover todo tipo de acciones para acabar
con ella.
El fin principal de Amafestival es construir la Casa de Maternidad del poblado de Banani y otro proyecto
paralelo a favor de la eliminación de prácticas rituales de escisión genital femenina con el máximo
respeto hacia la diversidad cultural, así como proteger una cultura milenaria en riesgo de desaparición.
Desde su comienzo y hasta el día de hoy se han realizado distintas prospecciones médico-sanitarias
en la zona, de salud buco dental, de riesgos asociados a la escisión genital femenina, diseño
arquitectónico, etapas, costes, construcción de un pozo, corte de piedra, fundición,… estando en la
actualidad en un estado avanzado de construcción.
Todo el trabajo se ha realizado directamente con el poblado, sin intermediarios y ellos están totalmente
involucrados en el proyecto, participando y dirigiendo cada fase.
Ama es un proyecto homenaje a la mujer, para su empoderamiento y donde se busca la igualdad

entre los géneros; un proyecto de desarrollo comunitario, basado en construir un centro de maternidad
digno, de calidad, con durabilidad, que mejore su vida y además aumente su autoestima.
Muchas gracias a todos los colaboradores que están haciendo que esta necesidad deje de ser una
utopía para convertirse en una realidad. Un mundo mejor es necesario.
Si quieren colaborar pueden hacerlo:
Colonya - Caixa de Pollensa

IBAN ES98-2056-0008-2241-0200-0083
Beneficiario: Asociació Amics de Cala Carbó
Enlaces:
www.amafestival.org
https://www.facebook.com/amafestivalbanani/
Patrocinadores
GOLD
SILVER
BRONZE
Prólogo por Duncan Epping
Prólogo
When Federico contacted me in February and asked me if I would be willing to write a foreword for
a book my immediate response was: YES. I always applaud community efforts, and as this book is
written by 14 bloggers from Spain and Latin America it even felt more special. Some of you may not
know this, but the very first book I wrote was a collaboration between six bloggers. I know how much
work is involved, and it may sound like things will be easier when you are producing content with more
people, but it is the opposite. A lot of coordination needs to happen to ensure everyone sticks to the
same standards and delivers the same quality of work. Challenging, yet awesome.
If that wasn’t enough to convince me, Federico mentioned that the idea behind this project was to get
the book sponsored and donate all proceeds to charity. I think this is very noble, and I appreciate the
fact that people in our community try to help when and where ever they can. How could I say no? I hope
the book will be a huge success and the authors raise a significant amount for the Banani Project (a
children’s hospital in the Dogon Country) and the CEAFA Alzheimer’s organization.
The book covers many different topics, and personally I view it as the perfect introduction to all different
aspects of the software-define data center by the world’s top experts. It all begins with VMware vSphere
and then takes you in to the trenches of software-defined storage (vSAN) and software-defined
networking (NSX). That is not where it ends, the book also covers monitoring, automation and even
VMware Cloud on AWS and various types of workloads like containers and Horizon View.
I believe that the book demonstrates how the world of IT has changed in the past 10 years, but also
what will be on your list of projects to complete in the upcoming years. Some of you may have already
seen the light and have adopted software defined networking or storage, some of you may have dipped
their toes in the cloud native ocena, reality is that most of you reading this book are still on your journey
towards the software-define data center.
The question which then rises is what the most challenging aspect will be on this journey? I believe
that the most challenging aspect is going to be the transformation which is required from a people and
process point of view. Books like these will prepare you for the technical aspect of the transformation,
but as an IT team, as a company, crucial steps will need to be made to allow you to take advantage of
the flexibility and agility a software-defined data center offers. Do your change process for instance align
with this new way of deploying workloads? Is your organization structure ready for this level of integration
between infrastructure components? In other words, how often do you talk to the storage administrators
or the network administrators? Or are you the virtualization, network and storage administrator? Either
way, this book is a great starting point for your journey towards the software-defined data center.
Enjoy the 1000+ pages of content, and if you have the opportunity please consider donating to charity
on behalf of the authors. They have spent a lot of time and effort on writing this book, their reward is the
satisfaction of #GivingBack to the community.
Duncan Epping
Chief Technologist @ VMware
Blogger @ Yellow-Bricks.com
Índice de capítulos
Capítulo 1 - Introducción (Xavier Genestós).......................................................................................25
Capítulo 2 - vCenter, ESXi’s y VMs (Gorka Izquierdo)........................................................................44
Capítulo 3 - Instalación, Configuración y Actualización (Xavier Caballé)..........................................149
Capítulo 4 - Redes en vSphere (Miguel Ángel Alonso).....................................................................222
Capítulo 5 - NSX (Miguel Ángel Alonso)...........................................................................................251
Capítulo 6 - Almacenamiento en vSphere (Leandro Ariel Leonhardt)...............................................282
Capítulo 7 - vSAN (Federico Cinalli).................................................................................................302
Capítulo 8 - Alta Disponibilidad (Leandro Ariel Leonhardt)................................................................360
Capítulo 9 - Backup y Réplicas (Patricio Cerda)...............................................................................399
Capítulo 10 - Monitorización de vSphere (Jorge de la Cruz)............................................................489
Capítulo 11 - Monitorización con Centreon (Héctor Herrero)............................................................544
Capítulo 12 - VDI con Horizon View (Ricard Ibáñez)........................................................................612
Capítulo 13 - Citrix en vSphere (Héctor Herrero)..............................................................................721
Capítulo 14 - vRealize Orchestrator (Federico Cinalli)......................................................................770
Capítulo 15 - PowerCLI (Miquel Mariano).........................................................................................807
Capítulo 16 - vRealize Automation (Federico Cinalli)........................................................................844
Capítulo 17 - Automatizando vSphere con Ansible (Miquel Mariano)...............................................894
Capítulo 18 - vSphere y Containers (Raúl Unzué)............................................................................932
Capítulo 19 - VMware Code - API (Daniel Romero)..........................................................................987
Capítulo 20 - VMware Cloud on AWS (Jorge de la Cruz)................................................................1009
Capítulo 21 - Consejos para equipos que administran VMware (Ariel Sánchez Mora)..................1049
Capítulo 1
Introducción
Xavier Genestós
Capítulo 1 - Introducción Xavier Genestós
1. Introducción
1.1 ¿Qué es la virtualización?
La virtualización establece una capa de abstracción entre el hardware y el sistema operativo de una
máquina virtual.
Esta capa de abstracción permite disponer de varios equipos virtuales dentro de un equipo físico.
La capa de abstracción entre el hardware y el sistema operativo de una máquina virtual nos la
proporciona el hipervisor.
El equipo donde se instala el hipervisor se le llama: host, mientras que el sistema operativo de la
máquina virtual, se le denominará: guest.
El sistema operativo de una máquina virtual (guest) verá el hardware presentado por el hipervisor.
El hardware presentado por el hipervisor (host) a las máquinas virtuales (guests) no será igual al
hardware físico.
Las máquinas vituales (guests) verán lo que configuremos en el hipervisor (host).
Será el hipervisor el que regulará los recursos demandados por las máquinas virtuales.
1.2 Tipos de hipervisor
Podríamos dividir los hipervisores en dos grandes tipos, los hipervisores de tipo 1 y los de tipo 2.
Tipos de hipervisor
Tipo 1 Tipo 2
Fuente de la foto: https://es.wikipedia.org/wiki/Hipervisor
Vemos las diferencias entre ambos tipos de hipervisor:
Tipo1:
• Se instala directamente en el hardware físico.
• El hipervisor debe detectar los distintos elementos del hardware físico como las tarjetas de red, la
controladora de disco, etc..
• El rendimiento es superior a los hipervisores de tipo 2.
• Es el tipo de hipervisor adecuado para un entorno de producción.
• Ejemplos: VMware ESXi, Citrix XenServer, Microsoft Hyper-V.
Tipo2:
• Se instala en un equipo con un sistema operativo ya instalado en el hardware físico.
• El hipervisor debe ser compatible con el sistema operativo instalado en el hardware físico.
• El rendimiento es inferior a los hipervisores de tipo 1.
• Es el tipo de hipervisor adecuado para un entorno de laboratorio.
• Ejemplos: VMware Workstation, VMware Player, Virtualbox.
1.3 Extensiones CPU
Cuando aparece por primera vez la virtualización en el mercado, las CPU no estaban diseñadas para
ello.
En 2005 y 2006, Intel, en sus nuevos modelos de CPU añade extensiones de virtualización a la
arquitectura de sus CPUs y le llama: Intel VT (Intel Virtualization Technology), mientras que AMD hace
lo propio y le llama: AMD-V (AMD Virtualization).
El soporte para la virtualización: Intel VT o AMD-V puede activarse o desactivarse en la BIOS del
sistema.
Más adelante, se introduce Intel VT-x y AMD-V-x, que permite al hipervisor iniciar máquinas virtuales
con sistemas operativos de 64bits.
En CPUs Intel, podemos verificar si VT-x está activado utilizando: “Intel® Processor Identification
Utility”.
https://downloadcenter.intel.com/product/5982/Intel-Processor-Identification-Utility
Vista de la herramienta para Windows donde podemos ver si está activado Intel VT-x:
A día de hoy es imprescindible que estén habilitadas las extensiones de VT en la BIOS del sistema
para instalar un hipervisor.
1.4 Servidores virtuales VS servidores físicos
Trabajar con servidores virtuales en vez de servidores físicos, nos permitirá:
• Ahorro y mayor utilización de los recursos físicos
Al compartir los distintos recursos de hardware: CPUs, RAM, red, entre distintas máquinas virtuales
conseguiremos que no hayan servidores con muy poca carga y otros con mucha carga, por tanto
necesitaremos menos recursos físicos para ofrecer los mismos servicios.
También ahorraremos espacio y energía. Ya no necesitamos para cada servidor un hardware

dedicado. Al compartir el hardware, se requieren menos servidores físicos, por tanto, menos
espacio y menos consumo de energía.
• Copias de seguridad y recuperación de desastres
Las copias de seguridad pueden realizarse utilizando el hipervisor y se pueden respaldar máquinas
virtuales sea cual sea el estado del sistema operativo de su interior.
Podemos hacer copias de seguridad de máquinas virtuales apagadas, que se estén reiniciando en
el momento de la copia, de cualquier sistema operativo.
El respaldo de todos los datos se simplifica notablemente.
Por otro lado, está la recuperación. La recuperación al no depender del hardware físico se simplifica
notablemente y el tiempo se reduce.
Este hecho, también abre la puerta a disponer de planes de recuperación de desastres mucho más
simples, rápidos y fiables.
• Provisionado mucho más rápido
Provisionar una máquina virtual e instalar el sistema operativo es mucho más rápido que provisionar
un servidor físico e instarle el sistema operativo.
También tenemos herramientas como la clonación de máquinas virtuales que nos reducen el
tiempo de provisionado.
• Administración más rápida
Mover una máquina virtual, iniciarla, apagarla, todas estas operaciones son mucho más rápidas
si trabajamos con máquinas virtuales. La administración también se centraliza. El reinicio de las
máquinas es más rápido.
• Alta disponibilidad
Se ofrecen ciertas herramientas que nos ofrecen la posibilidad de ofrecer alta disponibilidad a nivel
de servicio como la puesta en marcha automática de una máquina virtual en otro host caso de
caída o la réplica de máquinas virtuales.
1.5 VMware Compatibility Guide
Como hemos visto en un punto anterior, VMware ESXi es un hipervisor de tipo 1 y por tanto se instalara
directamente en el hardware, sin instalar un sistema operativo previo.
El hardware sobre el cual instalaremos VMware ESXi ha de ser compatible.
Es por este motivo que hemos de verificar la compatibilidad del hardware antes de instalar.
Dependiendo de la versión de VMware ESXi a instalar, funcionará o no en un hardware.
La lista de compatibilidad va variando y un hardware donde funcionaba VMware ESXi 6.5, puede que
no funcione con VMware ESXi 6.7.
La URL para verificar la compatibilidad es la siguiente:
https://www.vmware.com/resources/compatibility/search.php
Vista web VMware Compatibility Guide
Además de de verificar si el hardware es compatible con la versión de VMware ESXi que vamos
a instalar, también podemos ver para cada versión de VMware ESXi, los sistemas operativos que
podemos instalar por cada máquina virtual, así como la compatibilidad con otros productos de VMware.
1.6 FAQ básico sobre la virtualización
1. Tengo máquinas físicas que acceden a dispositivos USB. ¿Las puedo virtualizar?
Existe opción de configurar “USB passthrough”.
Con “USB passthrough” podemos mapear un dispositivo USB físico conectado a un host a una
máquina virtual.
Con esta opción tendremos el problema que si movemos la máquina virtual de host perderemos la
visibilidad con el dispositivo.
También hay hardware físico que permite pasar de USB a Ethernet y así hacer visible el dispositivo
USB por la red.
Es importante tener en cuenta que es necesario realizar las pruebas antes de realizar cambios en
producción.
2. ¿Puedo utilizar los snapshots (instantáneas) como método de copias de seguridad?
No. Los snapshots no son copias de seguridad.
Los discos correspondientes a los snapshots se guardan en la misma ubicación donde están
situados los discos de la máquina virtual.
Cuando una VM está funcionando con un snapshot, requiere igualmente de los discos VMDK
originales.
El rendimiento de una VM con un snapshot es menor si la VM tiene algún snapshot.
Se recomienda utilizar los snapshots de forma que la VM esté funcionando con un snapshot el
mínimo tiempo posible.
3. No puedo instalar ESXi en un servidor físico. ¿Cómo resuelvo el problema?
Algunos errores típicos en la instalación de ESXi son:
• El hardware donde estas instalando VMware ESXi no está certificado por VMware: Revisa que
exista una correspondencia entre el servidor físico y la versión de ESXi que quieres instalar en:
“VMware Compatibility Guide”
• Revisa en la BIOS del servidor físico que tengas habilitado el VT en las opciones de CPU.
• Revisa que tengas acceso al storage donde quieres instalar VMware ESXi, por ejemplo, si se
trata de un RAID en storage local, tendrás que crear el volumen virtual primero antes de instalar.
4. ¿Existe perdida de rendimiento al virtualizar un servidor físico?
Sí, pero la pérdida a día de hoy, en hipervisores de tipo 1 es muy pequeña.
En hipervisores de tipo 2, la perdida de rendimiento es mucho mayor que los hipervisores de tipo 1.
La clave para evitar problemas de rendimiento es dimensionar correctamente la infraestructura

virtual.
5. Tengo Windows Server instalado en un equipo físico: ¿Puedo conservar la licencia si lo virtualizo?
Depende del tipo de licencia.
Si disponemos licencia OEM o ROK y la hemos adquirido asociada a un servidor físico que
pretendemos virtualizar a otro servidor físico donde está instalado el hipervisor, no podremos
hacerlo a nivel legal, sí a nivel técnico.
Las licencias OEM o ROK van asociadas a un hardware físico.
Podemos utilizar licencias OEM o ROK en entornos virtuales siempre y cuando las adquiramos de
forma conjunta con el host donde tenemos instalado el hipervisor.
Existen licencias de Microsoft que no van asociadas a la compra de un hardware físico como las
licencias por volumen, en este caso podemos pasar de físico a virtual a nivel técnico y legal.
6. No puedo instalar Windows Server ROK en una máquina virtual.
El problema al instalar puede ocurrir debido al aislamiento que por defecto aplica el hipervisor a las
máquinas virtuales.
El hipervisor “esconde” cierta información ubicada en la BIOS física del servidor donde se encuentra
instalado VMware ESXi.
Cuando iniciamos una instalación de Windows Server con una licencia ROK, el instalador va a
buscar en la BIOS del sistema si el equipo es DELL, HPE, etc...
Una ISO de Windows Server con licencia ROK subministrado por DELL, solo podrá ser instalado
en un servidor DELL.
Si el instalador, no puede realizar la verificación, aparece un error.
Aquí la solución:
https://www.sysadmit.com/2018/09/VMware-instalar-windows-server-rok.html
7. Licenciamiento Microsoft de Windows Server: ¿Existe un ahorro si licenciamos máquinas virtuales

en vez de máquinas físicas?
Sí.
Por cada edición “Standard” se pueden licenciar dos máquinas virtuales.
Por cada edición “Datacenter” se pueden licenciar infinitas máquinas virtuales por cada socket de
CPU físico del hipervisor.
8. El hardware de una máquina virtual no corresponde con el hardware del host físico donde está
instalado el hipervisor. ¿Es correcto?
Sí. El hipervisor muestra a las VMs hardware que no existe físicamente.
Vista parcial de un administrador de dispositivos de Windows (devmgmt.msc) de una máquina

virtual (guest): Aquí podemos ver cómo el modelo de la VGA y NIC del equipo donde está instalado
el hipervisor (host) no corresponden con los modelos de VGA y NIC que hay en una máquina
virtual.
Vista parcial de un administrador de dispositivos de Windows (devmgmt.msc)
9. ¿Qué son las VMware Tools?
Las VMware Tools son los drivers que se instalan en las máquinas virtuales (guest).
Además instalan un servicio para que el hipervisor pueda comunicar con las mismas y reciba un
feedback de los recursos que les va ofreciendo.
Vista asistente para la instalación VMware Tools en Windows
10. ¿Qué es un DataStore?
Un DataStore es donde se guardan los ficheros relacionados con cada máquina virtual.
Los DataStores pueden ser presentados por NAS (almacenamiento de ficheros) o por SAN
(almacenamiento por bloques).
En el caso SAN, el sistema de ficheros utilizando será VMFS.
Diagrama conceptual: Ejemplo de VMs y datastores
Fuente imagen: https://www.vmware.com/pdf/vi_architecture_wp.pdf
11. ¿Qué es Virtual Center?
Virtual Center es una herramienta para administrar varios hosts VMware ESXi y así poder realizar
ciertas operaciones.
Por ejemplo, utilizando Virtual Center, podremos mover máquinas virtuales en caliente utilizado la
tecnología vMotion si el licenciamiento adquirido nos lo permite.
Hasta la versión 6.7, es posible instalar Virtual Center sobre sistemas operativos Windows o bien
también es posible deplegar un appliance virtual llamado: VCSA (vCenter Server Appliance).
12. ¿Qué es la hardware version?
La “hardware version” de una máquina virtual indica las características de hardware virtual
compatibles de la máquina virtual.
Las características de hardware virtual incluyen la BIOS y EFI, ranuras PCI virtuales disponibles,
número máximo de CPU, memoria RAM máxima entre otros.
13. En una VM: ¿Se permite añadir o quitar hardware virtual en caliente?
Sí, es posible añadir hardware virtual de una VM siempre y cuando cumplamos los siguientes
requisitos:
• La hardware version mínima admitida es la: 7
• La funcionalidad no es compatible si la VM está siendo replicada con Fault Tolerance.
• Solo encontraremos la funcionalidad en la edición Enterprise Plus de vSphere.
• No puedes quitar hardware en caliente, solo añadir. Por ejemplo: Para quitar RAM en caliente,
será necesario detener la VM.
• El sistema operativo debe permitir añadir hardware en caliente. En el caso de Windows Server,
se permite a partir de Windows Server 2003.
14. ¿Qué es un cluster?
Un cluster es una agrupación de hosts VMware ESXi.
Cuando se agrega un host a un clúster, los recursos del host se convierten en parte de los recursos
del clúster.
El clúster gestiona los recursos de todos los hosts dentro de él.
Los clústeres habilitan las funcionalidades de: vSphere High Availability (HA) y vSphere Distributed
Resource Scheduler (DRS).
15. ¿Qué es un resource pool?
Un resource pool, permite limitar el uso de CPU y memoria RAM para las VMs que definamos.
16. ¿Que es un snapshot?
Realizar un snapshot de una máquina virtual significa guardar el estado de la máquina virtual para
que en el futuro poder retroceder el estado de la misma al punto donde se ha realizado el snapshot.
Un snapshot no es un backup, ya que una máquina virtual que funciona con un snapshot requiere
los ficheros del estado anterior para poder funcionar.
1.7 VMware historia y sus productos
La compañía VMware fue fundada en 1998 y en su segundo año de vida, en 1999 lanzó su primer
producto: VMware Workstation y en 2001 lanzo VMware GSX Server y VMware ESX.
En 2003 introdujo la tecnología vMotion y Virtual Center para administrar los hosts de forma centralizada.
Se introduce el soporte para 64 bits en 2004.
A partir de aquí, son muchas las adquisiciones que va realizando VMware y son muchos los productos
que va lanzando.
1.7.1 Productos básicos entorno de laboratorio

Todos ellos son hipervisores de tipo 2.
• VMware Workstation: Software de pago. Aplicación para sistemas operativos Windows o Linux
que permite crear, iniciar máquinas virtuales.
• VMware Fusion: Software de pago. Igual que VMware Workstation pero para sistemas operativos
MacOSX.
• VMware Player: Software gratuito. Permite la ejecución, de máquinas virtuales creadas con
VMware Workstation. La nomenclatura player, es vigente hasta la versión 7 del producto y pasa a
llamarse: VMware Workstation Player, siendo un producto de pago, solo será gratuito en entornos
educativos o para uso particular. Más información, en este enlace:
https://www.sysadmit.com/2017/07/VMware-player-vs-workstation-diferencias.html
Hemos de verificar la compatibilidad de cada versión de Workstation, Fusion o Player con la versión
del sistema operativo donde vamos a instalar el producto (host).
También la compatibilidad de los sistemas operativos guest se amplia con cada nueva versión.
Por ejemplo, la compatibilidad con sistemas operativos guest: Windows Server 2019 se introduce con
la versión de VMware Workstation: 15.0.2
1.7.2 Productos básicos entorno de producción

• VMware GSX // VMware Server: Software gratuito. Su nombre inicial era VMware GSX Server y
en 2006 pasa a llamarse VMware Server 1.0. Se lanza la versión 2 de VMware Server y el producto
queda discontinuado en 2011. Es un hipervisor de tipo 2.
Uno de los problemas de este hipervisor es que al ser de tipo 2, el rendimiento para entornos
productivos no era muy bueno.
• VMware ESX // VMware ESXi: Software de pago, todo y que existe una licencia gratuita con
limitaciones.
Es un hipervisor de tipo 1, por tanto debe instalarse directamente en el hardware físico.
El hardware físico debe ser compatible con la versión de hipervisor instalada.
En un inicio existía la versión ESX (Elastic Sky X), disponía un kernel propio: VMKernel y era
administrado por un sistema operativo llamado Service Console.
Más adelante, en la versión 3 de ESX, VMware lanza ESXi (Elastic Sky X Integrated), se elimina la
service console y se integra todo en uno: el kernel y la administración.
Es con ESXi, aparece la Direct Console User Interface (DCUI) para administrar el servidor y la
instalación de ESXi es mucho más rápida que la instalación de ESX.
Igualmente, el administrador, puede elegir si instalar ESX o ESXi hasta la versión 5, que solo queda
ESXi.
• VMware Virtual Center: Software de pago. Permite añadir varios hosts ESXi y así poder realizar
distintas operaciones entre ellos, por ejemplo, mover máquinas virtuales entre los host ESXi, entre
otros.
• VMware Converter: Software gratuito. Permite convertir máquinas físicas a virtuales y también
permite convertir distintos formatos de máquinas virtuales: de Hyper-V a ESXi, de VMware
Workstation a ESXi, etc..
1.7.3 Productos avanzados

Todos los productos listados a continuación son de pago:
• VMware Horizon View: Permite crear y administrar un entorno VDI (Virtual Desktop Infrastructure).
• VMware vRealize: Suite de productos que, complementados con vSphere, vSAN y NSX, son la
base del Software Defined Datacenter de VMware.
• VMware NSX: Virtualización del networking.
• VMware vSAN: Solución de almacenamiento distribuido, orientado a objetos y embebido en

VMware ESXi.
• VMware Site Recovery Manager: Permite automatizar la recuperación de las máquinas virtuales
en otro entono mediante reglas configurables.
1.8 ESXi: Tecnologías básicas
En este punto enumeraremos y realizaremos una descripción de distintas tecnologías disponibles en

el hipervisor de tipo 1: VMware ESXi.
En otros puntos del libro, se explicarán los requisitos técnicos de cada tecnología y su correcta
configuración.
Es conveniente entender las distintas tecnologías disponibles de cara al licenciamiento, es importante

no sobrelicenciar, es decir, no elegir ediciones que tengan más funcionalidades que las necesitemos.
Todas estas tecnologías, al ser necesaria la interacción entre más de un host VMware ESXi, requieren
de Virtual Center.
1.8.1 vMotion
Existen tres tipos de vMotion: vMotion, svMotion y evMotion.
Todos los tipos tienen en común:
• No se produce reinicio de la VM.
• La pérdida de conectividad es mínima o inexistente.
• No se necesita que las VMs estén dentro de un Clúster, excepto si se requiere activar EVC para
vMotion.
• No tiene nada que ver con el servicio HA (High Availability).
• Es buena idea dedicar un segmento de red para este tipo de tráfico.
• Requiere Virtual Center para poder realizar el proceso.
A- vMotion
• Mover VMs de host ESXi sin ser detenidas (en caliente).
• Los ficheros de las VMs no se mueven. Los ficheros de las VMs residen y se mantienen en un
storage compartido accesible entre origen y destino.
B- sVMotion (Storage vMotion)
• Mueve los ficheros de las VMs entre storages compartidos en caliente.
• Los storage compartidos deben poderse ver entre origen y destino.
• No se permite mover de DAS (Direct Attached Storage) a DAS.
C- evMotion (enhanced vMotion):
• Se introduce en ESXi 5.1.
• Permite mover una VM de host y de storage a la vez, en caliente.
• Se permite mover de DAS (Direct Attached Storage) a DAS: Sin visibilidad directa del storage en
el host ESXi destino.
1.8.2 HA (High Availability)

A - HA
• HA permite que si cae un host, sus VMs pasan a iniciarse en otro host.
• La VM sufre un “PowerOff no ordenado” y un PowerOn.
• Actúa siempre y cuando hayan recursos disponibles para levantar las VM.
• Requiere Virtual Center.
• Requiere Storage compartido.
• Requiere que las VM estén dentro de un clúster.
• No usa VMotion.
B- HA proactivo
• Introducido a partir de ESXi 6.5.
• Es capaz de leer los sensores de hardware del host ESXi y actúa según la configuración que
realicemos.
• Por ejemplo, fallo de una fuente de alimentación de un host con doble fuente de alimentación
redundada, vMotion de todas las VMs a otro host ESXi.
• Se requiere que el hardware físico del host VMware ESXi sea compatible con el HA proactivo.
1.8.3 FT (Fault Tolerance)

• FT consiste en una réplica de una VM en otro host: Cuando cae el host con la VM protegida con FT
entra en marcha la VM que estaba siendo replicada. “Un RAID-1” de una VM.
• No se produce reboot de la VM (a diferencia de HA).
1.8.4 DRS (Distributed Resource Scheduler)

A- DRS
• DRS consiste en una monitorización del uso de recursos (CPU/RAM) de las máquinas virtuales de
un clúster y de la reubicación (vMotion) de las máquinas virtuales en otros hosts. La idea es repartir
la carga de CPU/RAM entre los distintos hosts de forma automática.
B- Storage DRS
• La idea de Storage DRS es la misma que con el DRS tradicional (CPU/RAM) pero a nivel de
datastore, de esta forma se reparte la carga de storage entre datastores.
1.9 Licenciamiento VMware: Características generales
Para verificar el licenciamiento se recomienda consultar la web de VMware y así revisar los distintos
cambios que VMware efectúa.
En este apartado veremos distintos conceptos básicos sobre el licenciamiento que funcionan de la
misma manera en todas las versiones del producto:
1. Existe una versión de ESXi gratuita (ESXi Free).
La versión gratuita de ESXi, si repasamos las limitaciones que tiene, veremos que no es apta para
entornos de producción ya que por ejemplo, no dispone de las Vsphere APIs para el backup a nivel
de hipervisor, ni tampoco permite añadir el host a un Virtual Center, por tanto no podremos utilizar
vMotion, HA, etc…
Podemos ver las limitaciones de ESXi gratuito aquí:
https://www.sysadmit.com/2016/03/VMware-esxi-gratuito-limitaciones.html
A nivel conceptual, para licenciar VMware ESXi, hemos de tener en cuenta lo siguiente:
2. Licenciar todos los sockets de todos host
Es necesario licenciar todos los sockets de todos los host con VMware ESXi instalado. El coste
de licenciar un host VMware ESXi con 1 socket es inferior a licenciar un host VMware ESXi con 2
sockets.
3. No se licencia por RAM instalada en los host
No hay límites a nivel de licenciamiento para RAM, o cores: El coste de licenciar un host VMware
ESXi con 128GB de RAM es el mismo que con 256GB de RAM.
4. No se licencia por número de VMs
No hay límites a nivel de licenciamiento para máquinas virtuales: El coste de licenciar un host VMware
ESXi con 20 VMs es el mismo que con 100 VMs. Cuidado, después tenemos el licenciamiento a
nivel de sistema operativo de cada VM, por ejemplo, si vamos a instalar VMs con Windows Server,
deberemos adquirir licenciamiento Microsoft.
5. Virtual Center se licencia por separado
Virtual Center (VC) se licencia a parte, sin embargo hay Kits que lo incorporan. Un Kit es la suma
de cierta edición de ESXi y Virtual Center.
6. Versión de evaluación
Al instalar un host VMware ESXi este se licenciará de forma automática en modo de evaluación.
El modo evaluación permite usar todas las funcionalidades del producto durante 60 días. Los
días solo cuentan si tenemos los hosts ESXi encendidos. Cuando estamos instalando un sistema
productivo, es importante licenciar después de instalar, de esta forma evitamos dejarnos ningún
host ESXi funcionando en modo evaluación.
7. Evita sobrelicenciar
Revisa las tecnologías que necesitas y elige la edición adecuada.
Algunos ejemplos:
Tecnología A partir de la edición

vMotion Essentials Plus
sVMotion/evMotion Standard
HA (High Availability) Essentials Plus
Proactive HA (Proactive High Availability) Enterprise Plus
FT (Fault Tolerance) Standard
DRS (Distributed Resource Scheduler) Enterprise Plus
Storage DRS (Storage Distributed Resource Scheduler) Enterprise Plus
1.10 ESXi y VCenter: Herramientas GUI de administración
Para administrar un solo host VMware ESXi, no utilizaremos Virtual Center, en cambio cuando
dispongamos de mas de un host VMware ESXi y queramos realizar operaciones que interactuen entre
ellos, necesitaremos Virtual Center.
Las herramientas para administrar un solo host VMware ESXi o bien Virtual Center, varian segun la
versión utilizada.
• Para administrar un host VMware ESXi:
La forma mas sencilla de ver la herramienta o herramientas disponibles que podemos utilizar
cuando disponemos de un host VMware ESXi, es situando la dirección IP en navegador web.
Dependiendo de la versión de VMware ESXi, tendremos una serie de herramientas u otras

disponibles.
Algunos ejemplos:
VMware ESXi 6.0 Update 2:
Si accedemos vía web a la dirección IP del host VMware ESXi, veremos que se permite: “vSphere
Client for Windows” o bien “Vmware Host Client” (administración web basada en HTML5).
VMware ESXi 6.5 y 6.7:
Nos aparecerá directamente el formulario para iniciar sesión en “Vmware Host Client”, siendo este
el único método de administración posible.
• Para administrar Virtual Center:
De la misma forma que cuando disponemos de un host VMware ESXi, disponemos de varias
herramientas que varian con el transcurso de las versiones, ocurre de la misma forma cuando
disponemos de Virtual Center.
En las primeras versiones, Virtual Center era administrable vía “vSphere Client for Windows”.
Es la versión 6.0 de Virtual Center, la última que permite la conexión con “vSphere Client for
Windows”.
Es en la versión 6.5 donde se introduce una alternativa en HTML5 a la versión web basada en
Flash.
Capítulo 2
vCenter, ESXi’s y VMs
Gorka Izquierdo
Capítulo 2 - vCenter, ESXi’s y VMs Gorka Izquierdo
Conceptos de VMware
Antes de empezar a administrar y gestionar una infraestructura VMware es muy importante tener
claros una serie conceptos y nomenclaturas, por lo menos las más utilizadas.
vCenter: Seguramente el componente más importante, es el servidor de VMware que gestiona de

forma centralizada todos los Hosts y sus recursos. Aporta tecnologías como vMotion, svMotion, HA,
FT, DRS y demás que únicamente funcionan sobre un vCenter Server.
VCSA: vCenter Server Appliance, es la versión Linux de vCenter
Plugin vCenter: aplicación que se integra con la consola de gestión del servidor de vCenter Server.
Existen cientos de plugins que permiten gestionar ciertas funcionalidades de forma centralizada desde
el vCenter
Cluster: Conjunto de dos o más Hosts ESXi que funcionan en grupo para proporcionar sistemas de
Alta Disponibilidad y tolerancia a fallos.
Datastore: Almacenamiento de un Host ESXi de VMware para almacenar Máquinas Virtuales, Plantillas
e ISOs. Utiliza el sistema de archivos VMFS (Virtual Machine File System), los Datatores pueden en
NFS y VMFS
Host ESXi: Hypervisor propietario de VMware que se ejecuta en un servidor físico.
High Availability (HA): Sistema de Alta Disponibilidad que agrupa en un clúster de Hosts ESXi
Máquinas Virtuales y en caso de error o caída de un Host ESXi las Máquinas Virtuales se reinician en
el otro.
VMFS: Virtual Machine File System, sistema de archivos propietario de VMware, optimizado para
clustering (para que dos o más host ESXi accedan al mismo sistema de ficheros concurrentemente sin
que se corrompa el sistema de ficheros.
NFS: Network File System, sistema de fichero de red, en VMware permite las versiones NFS v3 y NFS
4.1
ISCSI: Protocolo de almacenamiento vía eed Ethernet (encapsula información SCSI sobre tramas
Ethernet).
Máquina virtual: Una máquina virtual es un software que simula un hardware de un equipo físico y
está compuesta por un conjunto de archivos: Configuración, discos, etc..
vSwitch Standard: Switch virtual que se crea a nivel de Host ESXi para ofrecer conectividad de red a
los host ESXi y las máquinas virtuales.
vSwitch Distribuido: Switch Virtual que se establece en el vCenter y donde la configuración se

propaga por todos los host ESXi asociados con el vSwitch. Dispone de ventajas adicionales sobre los
switches Standard.
Portgroup: puerto lógico de un vSwitch.
Snapshot: Un Snapshot es un una “foto” que conserva el estado y los datos de la Máquina Virtual en
el momento que crea el Snapshot.
Clon: Copia exacta de una máquina virtual
DRS: Distributed Resource Scheduler, utilidad que equilibra las cargas de trabajo con los recursos
disponibles en un entorno virtualizado.
Plantilla: Imagen maestra de una Máquina Virtual.
Update Manager: Herramienta que permite la administración centralizada y automatizada de parches

y versiones para VMware vSphere.
vMotion: Utilidad que permite mover en caliente una máquina virtual encendida a otro Host ESXi.
Storage vMotion: Utilidad que permite mover en caliente las máquinas virtuales y los ficheros que la
componen entre Datastores.
vSphere Web Client: Versión web basada en Flash de vSphere Client.
vSphere Client HTML5: Versión web basada en HTML5 de vSphere Client.
DCUI: Direct Console User Interface, consola de gestión del host ESXi.
Pool de recursos: Utilidad que permite asignar y reservar recursos a Máquinas Virtuales.
Virtual Appliance: Máquina virtual empaquetada y preparada para importar y desplegar en el

inventario. Utiliza formato. OVA y OVF. Más información:https://www.sysadmit.com/2013/12/vmware-
formatos-ova-y-ovf.html
1. Instalación de Licencias de vCenter y ESXi
Cuando disponemos de un solo host VMware ESXi, podemos administrarlo de forma directa vía web a
partir de la versión ESXi 6.0 Update 2.
En versiones anteriores, la administración se realizaba utilizando un cliente de Windows.
Para instalar un host VMware ESXi, podemos verlo en el capítulo 3 de este libro:
“Instalación y configuración de vCenter y ESXi”
Cuando disponemos de más de un host VMware ESXi y queremos realizar ciertas acciones entre los
distintos hosts VMware ESXi, necesitaremos Virtual Center, por ejemplo: mover máquinas virtuales
entre los distintos hosts.
Virtual Center solo tiene sentido cuando disponemos de más de un host VMware ESXi.
Virtual Center es una herramienta de administración, por tanto, en caso de caída, las máquinas virtuales
de los hosts VMware ESXi, seguirán funcionando con normalidad.
Con la versión 6.7 se permite desplegar virtual Center en forma de appliance virtual y en forma máquina
virtual de Windows (En la próxima versión no incluirá vCenter Server para Windows https://blogs.
vmware.com/vsphere/2017/08/farewell-vcenter-server-windows.html).
El acceso a vCenter Server Appliance (VCSA) para administrar las máquinas virtuales se realiza vía
web, utilizando el vSphere Client HTML5 o el cada vez más en desuso vSphere Web Client (Flash),
que se elminará completamente en la siguiente versión.
Por defecto, cuando realizamos la primera instalación del vCenter Server Appliance y de los ESXi
disponemos de un periodo de prueba de 60 días, pasado este tiempo si no instalamos las licencias
correspondientes, los hosts ESXi se desconectarán, las máquinas apagadas ya no se podrán encender
y las VMs encendidas, seguirán en ese estado hasta que se apaguen, una vez apagadas tampoco se
podrán encender.
Una vez adquiridas las licencias las tendremos que instalar, para eso nos conectaremos vía vSphere
Client HTML5 a nuestro vCenter e iremos a la pestaña Administración del menú principal.
Nos dirigimos al apartado: “Licencias” y le damos a “Agregar nuevas licencias”. Las licencias las
podemos descargar una vez compradas y habiendo creado una cuenta en VMware.
Escribimos las claves de licencias tanto las de vCenter como las de ESXi en diferentes líneas.
Es importante tener en cuenta que el número de serie para licenciar un host VMware ESXi es distinto
al número de serie de un Virtual Center.
Editamos los nombres de las licencias y les ponemos uno descriptivo.
Finalizamos el asistente de instalación de licencias.
Una vez instaladas las licencias nos quedará asignarlas a su correspondiente producto.
Empezaremos por el vCenter Server Appliance, vamos a la pestaña Activos --- Asignar licencia.
Seleccionamos la licencia y aceptamos.
Ahora asignaremos la licencia a los Host ESXi seleccionándolos todos a la vez.
Asignamos la licencia a los ESXi.
Terminada la asignación de licencias comprobaremos que todo está correcto viendo las instancias y
las CPU en uso. También podremos ver en el menú inferior las características según el tipo de licencia
que hayamos adquirido.
2. Autenticación e integración con Directorio Activo
Los orígenes de identidad te permiten adjuntar uno o más dominios a vCenter Single Sign-On. Un
dominio al final no es más que un repositorio de usuarios y grupos que el servidor de inicio de sesión
de vCenter usa para la autenticación de usuarios. La integración con directorio Activo y un dominio
Windows por ejemplo, nos puede ser muy útil para que determinados usuarios de un grupo, puedan
administrar la infraestructura o parte de ella, con ciertos roles y permisos.
2.1 Que es un origen de identidad

Un origen de identidad es un conjunto de datos de usuarios y grupos, estos datos de usuario y grupos
se almacenan en el directorio activo, OpenLDAP o localmente en el sistema operativo de la máquina
donde está instalado vCenter Single Sign-On.
Cuando haces la primera instalación, la instancia de vCenter Single Sign-On tiene el origen de identidad
del sistema operativo local como vsphere.local, este es un dominio interno.
2.2 Tipos de Orígenes de Identidad

• vCenter Single Sign-On: Cuando instalamos vCenter Single Sign-On, el origen de identidad por
defecto es el dominio vsphere.local (se le puede cambiar el nombre en la instalación), el usuario
con máximos privilegios que nos crea por defecto es el de administrator@vsphere.local.. Este
usuario se utiliza para acceder al vSphere Client y es el de mayores privilegios.
• Directorio Activo (autenticación integrada de Windows), vCenter Single Sign-On te permite

configurar con un dominio de Directorio activo como origen de identidad y utilizar usuario y grupos
de este.
• Directorio Activo como LDAP: Se utiliza para compatibilidad de versiones antiguas
• Open LDAP: Opción para configurar un origen de identidad con LDAP
• Sistema operativo local del Servidor SSO: Se muestra como LocalOS y no está disponible
en instalaciones de vCenter con varias instancias ya que es un origen de identidad del sistema
operativo local. El usuario root pertenece este origen de identidad.
2.3 Configurar integración con Directorio Activo

Si queremos utilizar los usuarios de nuestro domino Windows para administrar y gestionar los objetos
del vCenter, necesitaremos integrarlo con el Directorio Activo.
Importante:
• VCSA debe tener conectividad con alguno de los controladores de dominio (DC) que tenemos en
la infraestructura.
• El cliente DNS de VCSA apuntar a alguno de los servidores DNS de Active Directory.
Para poder ejecutar este procedimiento, necesitaremos hacer login con el usuario administrator@
vsphere.local en el vSphere Client.
Para ello vamos a Menú ---- Administración
Hacemos clic en configuración --- Orígenes de identidad --- Agregar origen de identidad. Si nos fijamos,
veremos los orígenes de identidad que tenemos actualmente y que se crearon al hacer la instalación.
Si no lo hemos unido el vCenter a ningún dominio previamente, nos saldrá este mensaje, por lo que
primero tendremos que unirlo al dominio.
Para eso vamos a la pestaña Dominio de Active Directory, seleccionaremos el vCenter y haremos clic
en Unirse a AD.
Nos pedirá rellenar unos campos,
• Dominio
• Unidad organizativa (opcional)
• Nombre de usuario
• Contraseña
Añadidos estos datos, hacemos clic en unirse, nos pedirá reiniciar para que se apliquen los cambios.
Reiniciado el vCenter podremos continuar con el paso de Agregar origen de identidad.
Seleccionamos el tipo de origen de identidad que será Active Directory (autenticación integrada de
Windows), nombre del dominio y seleccionamos la opción de usar cuenta de equipo. Clic en Agregar.
Una vez agregado, veremos nuestro dominio de Windows junto a los otros.
A partir de aquí, ya podremos comenzar a jugar con los permisos y los usuarios de Directorio Activo,
podemos añadir usuario y grupos, darles los permisos o roles que veamos convenientes. Por ejemplo,
añadiendo al usuario administrador del dominio y dándole permisos solo de lectura de toda la
infraestructura y objetos del vCenter.
Para eso no posicionamos en el primero objeto del inventario que es el vCenter ---- permisos ---- clic
en el “+”
Seleccionamos el dominio, usuario administrador de este domino y en función le diremos que solo de
lectura. Aceptamos.
Una vez añadido, lo veremos en la lista.
Si queremos configurar la autenticación de Active Directory y disponemos de versiones de Virtual

Center anteriores a la 6.7 o bien queremos realizar el procedimiento vía PowerCLI, podemos utilizar
el siguiente enlace:
https://www.sysadmit.com/2016/05/vmware-anadir-esxi-al-dominio-de-active-directory.html
A continuación, instalaremos el completo de autenticación mejorada, el complemento de autenticación

mejorada de VMware ofrece autenticación integrada en Windows y funcionalidad de tarjeta inteligente
basada en Windows.
Descargamos el complemento de autenticación mejorada el instalamos este plugin.
Comenzará el asistente de instalación.
Y una vez instalado este plugin pasaremos a instalar el plug-in de servicio, que comenzará la instalación
una vez acabado el anterior.
Una vez instalado, marcaremos el check y le diremos conectar.
Desmarcamos el check “Always ask before allowing this site” para que no nos pregunte siempre y
hacemos clic en “Allow”.
Accederemos automáticamente al vSphere Client HTML5 y si intentamos encender, apagar la VM,

moverla o cualquier otra operación, no nos dará opción al tener solo permisos de lectura con el usuario
administrador del dominio.
3. Roles y permisos
En infraestructuras administradas por más de un administrador de sistemas, puede que nos interese
configurar roles y permisos.
Hay una serie de mejores y buenas prácticas de roles y permisos para mejorar la seguridad y la
administración de un entorno de vCenter Server.
VMware recomienda una serie de buenas prácticas con los roles y permisos:
• Cuando sea posible, asignar un rol a un grupo en lugar de a usuarios individuales, nos facilitará la
administración.
• Asignar permisos solo sobre los objetos donde lo necesiten, y asignar privilegios solo a los usuarios
o grupos necesarios. Usar la cantidad mínima de permisos para que sea más fácil de entender y
administrar.
• Usar carpetas para agrupar objetos, por ejemplo, crear una carpeta para máquinas virtuales según
S.O, otra carpeta para plantillas, otra según servicios que tenga la máquina virtual… de esta manera
la asignación de permisos será más fácil de administrar.
• No asignar un permiso restrictivo a un grupo, puede que en ese grupo haya un usuario administrador
y luego tenga problemas de permisos.
• Tener cuidado al agregar un permiso a los objetos raíz de vCenter Server, se puede dar demasiados
permisos.
• Cuidado con habilitar la propagación cuando asigne permisos a un objeto. Por ejemplo, si damos
permiso sobre una carpeta con varias VMs y añadimos otra nueva, tendremos que tener en cuenta
que se propagarán los permisos e igual no nos interesa que se tengan sobre esa nueva VM.
Todo ya dependerá de lo que quieras complicarte o el nivel de seguridad que quieras tener.
Para ver o configurar un nuevo Rol, vamos a Menú ---- Funciones, ahí veremos los roles que vienen
configurados por defecto. Como ejemplo vamos a clonar uno nuevo haciendo clic en el símbolo
después del signo “+”
Como buena práctica, es bueno no modificar los que vienen por defecto, de ahí el que se utilice la
clonación.
Como información, si hacemos clic en cualquiera de los Roles, podremos ver la descripción, el uso y
los privilegios.
Una vez clonado el Rol, pasaremos a editarlo a nuestro gusto y según necesidades.
En este ejercicio he clonado el Rol solo lectura, porque solo quiero que tengan permisos de lectura
para toda la jerarquía, menos para una función, encender una máquina virtual.
Editamos el Rol y en el menú de la izquierda, nos movemos hasta donde pone “Máquina Virtual”, la
seleccionamos y a la derecha nos mostrará todos los privilegios posibles. Como el Rol que hemos
clonado era solo de lectura, todos estos privilegios vendrán sin marcar.
Como solo queremos que pueda encender máquinas virtuales para esta prueba, seleccionamos el
privilegio de Máquina Virtual Encender.
Editamos el nombre y la descripción del Rol por uno con más sentido.
Pasamos a la práctica, queremos que un grupo del domino con el Rol que hemos clonado, pueda
encender las máquinas virtuales de determinada carpeta. Así que seleccionando la carpeta vamos a la
pestaña Permisos y hacemos clic en el signo “+”.
Seleccionamos de que dominio añadiremos los usuarios o grupos, y buscaremos un grupo del dominio
de Windows llamado Admin_vCenter, este grupo lo hemos creado anteriormente desde la consola de
usuarios y equipos de Directorio Activo de nuestro controlador de dominio, este grupo tiene 2 usuarios,
user01 y user02. Para terminar, marcamos el check de propagar a objetos secundarios ya que, si no
lo marcamos, no veríamos lo que hay de carpeta para abajo, aceptar.
Lo añadimos y cerramos sesión con el usuario que estamos.
Accedemos con el usuario user01 y podremos comprobar que no veremos nada en la pantalla principal,
esto lógicamente es porque no tenemos permisos para estos objetos.
Para eso vamos al icono de Máquinas Virtuales y plantillas, donde solamente veremos la carpeta de la
que tenemos permisos, si nos fijamos la carpeta de plantillas no la vemos, pues es porque no tenemos
permisos.
Si damos botón derecho sobre una Máquina Virtual veremos que solo nos deja encender
Una vez encendida, si intentamos apagar, suspender, reiniciar… veremos que no podremos hacerlo
al carecer de permisos necesarios. Como podéis ver podemos jugar bastante con roles y permisos y
podemos ajustar bastante el tema de seguridad, ya que en muchos sitios no utilizan estas ventajosas
características y siempre van por lo fácil y no seguro.
4. Introducción de Biblioteca de Contenido
Las bibliotecas de contenido son unos objetos que se utilizan para guardar plantillas de máquinas
virtuales, de vApp y otros tipos de archivos como imágenes ISO, de forma más centralizada, todo este
contenido se almacena en el Datastore. Unas de las ventajas de las bibliotecas de contenido es que
pueden compartir entre otras instancias de vCenter de la misma o diferente ubicación.
4.1 Tipos de Biblioteca de contenido

4.1.1 Biblioteca Local
La biblioteca local solo se usa para almacenar objetos en una única instancia de vCenter, aunque
podemos publicarla para que los usuarios de otras instancias de vCenter se puedan suscribir a ella.
4.1.2 Biblioteca suscrita

Las bibliotecas suscritas se originan de otras bibliotecas publicadas, se pueden crear en la misma
instancia o en otra diferente, este tipo de biblioteca se sincroniza automáticamente con la biblioteca de
origen para garantizar que el contenido este actualizado.
4.2 Creación de una biblioteca de Contenido

Para crear una biblioteca de contenido vamos a la pestaña menú --- Bibliotecas de contenido
Se abrirá el asistente donde rellenaremos los siguientes campos tales como nombre, notas y
seleccionaremos el vCenter donde queremos instalar la Biblioteca de contenido, de haber varios
utilizaremos el desplegable.
Seleccionaremos el tipo de Biblioteca de contenido local, sin publicar externamente.
Seleccionaremos el Datastore donde irá la ubicación de almacenamiento para el contenido de la

Biblioteca
Para finalizar revisaremos la configuración por si queremos cambiar algún parámetro.
Una vez creada la Biblioteca de contenido y dándole con el botón derecho sobre este, podremos
seleccionar varias opciones, tales como importar elemento, editar configuración, editar notas, cambiar
nombre, añadir etiquetas y eliminar.
Seleccionaremos importar elemento para empezar a cargar ISOS. Seleccionamos archivo local y le
damos a CARGAR ARCHIVO para subir nuestra primera ISO, si vemos conveniente podemos añadir
una descripción en el campo notas y finalizaremos dándole a importar.
Una vez subidas las ISOS que vayamos a utilizar, podremos usarlas para crear las máquinas virtuales.
Vamos a editar configuración y en Unidad de CD/DVD le diremos que añada la ISO desde Archivo ISO
de biblioteca de contenido.
Y Seleccionamos la ISO y aceptamos. Llegados hasta aquí ya será cuestión de crear una máquina
virtual, iniciar la VM con la ISO de Gparted para administrar discos y/o particiones o cualquiera de las
funciones que tengan el resto de ISOS de la Biblioteca.
Otro de los usos que podemos dar a la biblioteca de contenido es la de almacenar plantillas clonando
una máquina virtual como plantilla de biblioteca. Botón derecho sobre la máquina virtual --- Clonar
como plantilla en biblioteca.
Comenzará el asistente donde la diremos la información básica, hay 2 tipos de plantilla.
• Plantilla de máquina Virtual
• Plantilla OVF
Estos 2 tipos de plantillas tienen sus pros y sus contras, pero actualmente la que mejores opciones da
es la Plantilla OVF, de lo que explicaré más adelante.
Seleccionamos OVF, ponemos un nombre a la plantilla y añadimos una descripción al campo notas.
Creada la plantilla podemos desplegamos desde el clúster una nueva máquina virtual, botón derecho
Nueva máquina virtual.
Seleccionamos Implementar desde plantilla y siguiente.
Al haber creado anteriormente la plantilla con formato OVF, nos aparecerá en la biblioteca de contenido
a la hora de seleccionar una plantilla, no así cuando la hacemos en formato de plantilla de máquina
virtual. Seguimos el proceso completando los pasos que nos pide el asistente hasta terminar.
También una de las diferencias entre una plantilla en formato OVF o plantilla de máquina virtual, es las
diferentes opciones que te da. Si nos fijamos las opciones que nos da con una plantilla de máquina
virtual son las de crear nueva máquina virtual desde plantilla, editar notas, cambiar nombre, etiquetas
y eliminar.
En cambio, una plantilla en formato OVF nos ofrece una mayor variedad de opciones, desde crear una
nueva máquina virtual hasta actualizarla, exportarla, Clonar, editar notas, cambiar nombre, etiquetas
y eliminar.
5. Update Manager
Update Manager es la herramienta que permite la administración centralizada y automatizada de

parches y versiones para VMware vSphere, donde ofrece soporte para hosts ESXi, máquinas virtuales
y virtual appliances.
Con VMware Update Manager, se pueden realizar las siguientes tareas:
• Actualizar y parchear los hosts ESXi.
• Instalar y actualizar software de terceros en los hosts.
• Actualizar las VMware Tools y el Hardware virtual de las máquinas virtuales y los virtual appliances.
Hay una serie de condiciones de Update Manager a tener en cuenta:
• Para que VMware Update Manager pueda funcionar es necesaria conectividad con VMware
vCenter Server.
• Cada instalación de Update Manager debe estar asociada y registrada con una única instancia de
vCenter Server.
• Puede usar Update Manager con vCenter Server que se ejecuta en Windows o con vCenter Server
Appliance
• El módulo de Update Manager consta de un componente de servidor y de un componente de

cliente.
• El Update Manager se incluye como un servicio en el vCenter Server Appliance
• En un servidor vCenter con Windows, el componente se puede instalar en el mismo servidor de

vCenter o en uno diferente.
5.1 Actualizar hosts ESXi con Update Manager

Pasaremos a la práctica actualizando los hosts ESXi con Update Manager. Si nos fijamos en la imagen
el host ESXi es la versión 6.7.0, 8169922 y la ISO que vamos a descargar es para la v6.7.0, 10302608.
La ISO descargaremos desde la Web de VMware con la cuenta que tengamos, y si no la tenemos, la
creamos.
NOTA: Un punto a tener en cuenta es que, dependiendo de la marca de servidor como HP, DELL …
tendremos que descargar la ISO personalizada de estos. Esto no quiere decir que no podamos hacer
la instalación con la ISO de VMware, pero lo recomendado es hacerlo con la ISO correspondiente del
fabricante si el modelo de hardware es muy reciente.
El método que vamos a utilizar es subiendo la ISO de VMware ESXi 6.7 Update 1 que hemos
descargado, para eso iremos a Menú --- Update Manager
Dentro de Update Manager vamos a imágenes ESXi --- Importar, seleccionamos la ISO de VMware
ESXi y una vez que le damos a importar, comenzará a subir la ISO.
Una vez que termina de subir podremos visualizarla y seguido crearemos una Nueva Línea Base
Comenzará el asistente de creación de nueva línea de Base, ponemos nombre y descripción.
En el campo contenido, nos marcará automáticamente el tipo de contenido, que es “Actualización”
Seleccionamos la ISO que acabamos de subir y siguiente.
Comprobaremos que todo está correctamente y finalizar.
Ahora asociaremos la línea de Base a los Host ESXi, podemos hacerlo también por Clúster, pero solo
para 2 host ESXi lo voy a hacer uno por uno.
Asociamos la línea de base al Host ESXi.
Y le haremos clic en Corregir.
Aceptamos el Eula.
Y confirmamos el proceso con “Corregir”.
Comenzará el proceso y veremos cómo va aplicando la actualización, el proceso funciona de esta

manera: hace vMotion de las VMs a otro host, pone el host en modo mantenimiento, aplicar la
actualización, reinicia y lo saca del modo mantenimiento.
Finalizado el proceso de actualización, comprobaremos la versión del hypervisor ESXi en el panel de

la derecha.
Update Manager también nos permite el poder actualizar las VMware tools. Si nos dirigimos a
Actualizaciones --- VMware Tools, veremos el estado de las VMware Tools. Para rescan en qué estado
están, haremos clic en Examinar ahora.
Terminado el rescan, podremos ver si tenemos alguna actualización disponible o si están instaladas o
no.
Podemos programar la actualización de las VMware Tools, o en su defecto decirle que las instale la
próxima vez que se encienda la Máquina Virtual.
Podemos hacer lo mismo con la actualización del Hardware de Máquina Virtual.
Dentro del menú, está la parte Hardware de máquina virtual, donde si le damos a examinar ahora, no
hará un rescan y nos dirá el estado del Hardware Virtual de las Máquinas Virtuales.
Haciendo clic en Actualizar para coincidir con el host es una de las diferentes maneras que podemos
actualizar el Hardware Virtual de una Máquina Virtual.
Seleccionamos la máquina virtual a actualizar y le hacemos clic en Actualizar para coincidir con el host.
6. Actualización de vCSA 6.7
Desde que salió por primera vez el vCenter versión Linux appliance hemos podido comprobar lo fácil
que es actualizar sin tener que pasar por todo tipo de sufrimientos.
Existen 2 tipos de actualización:
• Descargando los parches desde un repositorio de VMware
• Descargando una iso con todos los parches acumulativos desde la web de VMware https://
my.vmware.com/group/vmware/patch#search
Recordar que estos procedimientos de actualización son para actualizar con parches de la misma
versión, es decir, solo podremos actualizar desde la primera versión de la 6.7 hasta la última de esta
misma. Por ejemplo, para actualizar de la reléase 6.5 a la 6.7 tendremos que hacer una Actualización
con la ISO de instalación.
6.1 Descargando los parches desde un repositorio de VMware

Por defecto la URL del repositorio está configurada, pero si por lo que sea no nos funciona se puede
modificar y poner una que si funcione.
Para eso vamos al menú de Actualizar y le damos a configurar
Podemos cambiar varios parámetros como:
• Buscar actualizaciones automáticamente.
• Usar el repositorio predeterminado
• Usar repositorio personalizado.
Pero lo dejaremos con la configuración predeterminada del repositorio.
6.2 Descargando una ISO con todos los parches acumulativos desde la
web de VMware
Este es el segundo método, seleccionando la versión y descargamos la ISO con los parches desde la
web VMware https://my.vmware.com/group/vmware/patch#search. Una vez descargado mapeamos la
ISO en la VM de vCSA desde el vSphere Client.
Descargada y añadida la ISO a la VM de vCSA, en comprobar actualizaciones, seleccionaremos

“comprobar CD-ROM”. Más información:
https://aprendiendoavirtualizar.com/actualizar-vcsa-v6-7-desde-iso/
Pero como vamos a utilizar el procedimiento más rápido, fácil y cómodo, seleccionamos comprobar
CD-ROM y URL, para que por defecto nos descargue e instale los últimos parches necesarios
Una vez que termina la búsqueda dependiendo del tiempo que lleve sin actualizar nos mostrará la
revisión actual y las anteriores. Al ser las actualizaciones acumulativas, bastará con que actualicemos
con la versión más actual.
Iniciaremos el proceso de actualización dándole a “Realizar copias intermedias e instalar”
Aceptamos los términos de licencia de usuario final y siguiente.
Lógicamente antes actualizar se supone que hemos hecho una copia de seguridad de la configuración
el vCSA, un Snapshot o una copia de seguridad de la VM con una aplicación de terceros.
Comienza el proceso de actualización.
Finalizado el proceso, comprobamos viendo el Numero de compilación.
7. Backups programados de vCSA 6.7
Con la llegada de VMware vSphere 6.5, VMware incluyó la característica de poder realizar una Copia
de Seguridad de nuestro vCenter Server Appliance, más conocido como vCSA.
¿De qué datos podemos hacer Copia de Seguridad? Del inventario, la configuración y opcionalmente
las estadísticas y los eventos.
Con esta nueva característica, podemos hacer Copias de Seguridad programadas y/o Copias de
Seguridad aleatorios e independientes.
7.1 Copia de Seguridad programada

Para poder configurar las Copias de Seguridad programadas, vamos a “configurar”,
Se abrirá la ventana de configuración de Copia de Seguridad, donde rellenaremos los siguientes

campos:
• Ubicación de la copia: protocolo://ruta_de_destino
• Credenciales del servidor de Copia de Seguridad: usuario y contraseña
• Programación: periodicidad
• Cifrar copia de Seguridad (opcional): contraseña
• Cantidad de Copias de Seguridad que se conservaran: sin límite o “x” últimas copias
• Por último, de que datos hacer la copia, inventario y configuración que ya viene marcado por
defecto y como opcional, eventos y estadísticas
Una vez configurada la Copia de Seguridad Programada, nos mostrará la tarea en el panel y se
ejecutará según la programación configurada.
Una vez ejecutada y finalizada la copia de seguridad, el registro de esta tarea se verá en la ventana
de Actividad.
7.2 Copia de Seguridad Manual

Podemos hacer una copia de Seguridad esporádica, bastará con que pinchemos en “Realizar copia
de seguridad ahora”
y rellenemos los mismos campos que el Backups programado.
NOTA: La tarea de Copia de Seguridad no se queda guardada.
8. Usuarios, Roles y permisos en Host ESXi
En ESXi, podemos crear usuarios y asignarles Roles para otorgarles permisos a diversos objetos
como una máquina virtual o un Host ESXi. Los permisos dan a los usuarios el derecho de realizar
actividades específicas por el rol en el cual se le asigna el rol.
Si el host ESXi está administrado por un vCenter, no es recomendable crear y asignar roles y permisos
en el host ESXi, ya que se puede crear mucha confusión o conflictos con los administrados por el
vCenter, Esto sería más lógico para un host ESXi Standalone. Lo que sí es recomendable y buena
práctica, es crear otro usuario administrador como el de root para poder administrar el ESXi y no utilizar
este último.
Nos conectamos al Host ESXi a través del VMware Host Client https://ip_o_fqdn
Para crear un usuario local en el host ESXi vamos a administrar --- Seguridad y usuarios --- usuarios,
hacemos clic en agregar usuario.
Le ponemos un nombre de usuario, una Descripción (opcional) y una contraseña.
Seguido vamos a Funciones y hacemos clic en Agregar función. Por defecto vienen ya varias funciones
o Roles creados por defecto y que no se pueden editar.
Como yo quiero crear una Función más personalizada seleccionaré una serie de privilegios. Cuando
nos aparecen los privilegios, seleccionaremos el que nos interese, por ejemplo, seleccionaré el de
VirtualMachine.
Al hacer clic sobre ese privilegio, nos aparecerán otros, selecciono el de State, y dentro del privilegio
State, están los privilegios sobre Snapshots. Selecciono el de crear Snapshot y el de remover Snapshot.
Le ponemos un nombre a la función creada.
Una vez creado el usuario y la función, vamos a dar permisos al objeto, en este caso es el Host ESXi,
botón derecho sobre el ESXi --- permisos.
Hacemos clic sobre Administrar permisos y desde los desplegables seleccionamos el usuario y la
función creada y hacemos clic en Agregar usuario.
Entramos al ESXi con el nuevo usuario creado y veremos como no tenemos la opción de reiniciar o
apagar la VM.
En cambio, nos dejará crear un Snapshot, pero no nos dejará revertirlo, tal como le hemos indicado al
crear la nueva función.
9. Poner un host ESXi en modo mantenimiento, reinicio

y apagado
Un host se pone en modo de mantenimiento cuando se deben realizar tareas de mantenimiento en

él, por ejemplo, para cambiar una controladora, disco … El host entra en este modo o sale de él solo
mediante la solicitud del administrador y de modo manual, el objetivo del modo mantenimiento es el de
un apagado ordenado. El modo mantenimiento también se utiliza en VMware Update Manager, pero
de modo automático.
Las máquinas virtuales que se están ejecutando en un host ESXi y que va a entrar en modo mantenimiento
deberán migrarse a otro host manualmente o si tienes DRS automáticamente. El Host ESXi se quedará
entrando en modo mantenimiento mientras no se hayan migrado las máquinas virtuales a otro host
ESXi o en caso de haber un solo host ESXi hasta que se apaguen las máquinas virtuales. Tampoco se
podrán migrar Máquinas virtuales a este Host ESXi, ni se podrán encender.
9.1 Poner Host ESXi en modo mantenimiento

Vamos a verlo mejor en la práctica. Para poder poner un Host ESXi en modo mantenimiento clic con el
botón derecho sobre el host --- modo mantenimiento --- Entrar en modo mantenimiento.
Nos avisará que el modo manteamiento no finaliza hasta que todas las VMs que están encendidas se
migren a otro host o se apaguen, aceptamos.
Al aceptar ya nos muestra una advertencia y nos dice bien claro que hay una o más máquinas virtuales
encendidas en los hosts y que no continuará hasta que se migre o se apague. Aceptamos para continuar.
Si nos fijamos en la imagen, ha entrado en modo mantenimiento, pero la barra de progreso se queda
en un 2%, además, si intentamos encender una de las VMs apagadas, no nos dará la opción.
Así que necesitaremos apagar o migrar la VMs para que el modo mantenimiento pueda continuar.
Una vez apagada la VM, el modo mantenimiento continua, por lo que ya podemos reiniciar o apagar
el Host ordenadamente.
Para apagar o reiniciar es necesario poner un motivo o escribir algo.
10. Servicios y Firewall de Host ESXi
10.1 Servicios
En un Host ESXi existen una serie de servicios predeterminados, algunos, por defecto vienen iniciados
y otros parados, podemos cambiar el estado de estos servicios según necesidad, pero con mucho
cuidado ya que pueden afectar a la seguridad del host, no habilitar un servicio a no ser que sea
realmente necesario.
En una instalación predeterminada vienen instalados los servicios de la siguiente imagen. Podemos
añadir más instalando un .vib, que es un paquete de software que se instala en un Host ESXi, entre
otras cosa contiene drivers, firmwares…
Servicios predeterminados
Los servicios de un Host ESXi se pueden modificar desde el VMware host Client o desde el vSphere
Client HTML5. Si queremos iniciar o parar un servicio como por ejemplo el de SSH, haremos clic con
el botón derecho sobre este y detener.
Automáticamente si estamos conectados a una sesión SSH, esta sesión se parará o si queremos
iniciar una nueva, nos rechazará la conexión.
10.2 Firewall
Desde el VMware Host Client también podemos configurar las reglas del Firewall, nos permite abrir
y cerrar puertos para cada servicio o como por ejemplo admitir la conexión SSH desde ciertas IPs.
Además de poder configurar vía web, podemos configurar las reglas del Firewall desde la línea de
comandos con ESXCLI.
Para configurar el Firewall, vamos a Reglas de Firewall --- Redes, nos mostrará todas las reglas
disponibles.
Si queremos editar la regla del Firewall Servidor SSH, haremos clic sobre ella y editar configuración,
en la ventana de configuración, seleccionaremos la opción de “Solo permitir conexiones de las redes
siguientes” y le pondremos una IP, un rango de red, IPv4 o IPv6.
Si estamos conectados al Host ESXi con una sesión SSH y le cambiamos la regla del Firewall para que
solo se pueda conectar de otra con diferente rango.
Automáticamente nos tirará de la sesión.
Configurar el Firewall y los servicios, también lo podemos hacer desde la interfaz vSphere Client
HTML5.
11. Archivos y componentes de una Máquina Virtual
11.1 Archivos de una máquina virtual

Una máquina virtual es un software que simula el hardware un equipo físico, está compuesta por un
conjunto de archivos de configuración y tienen una serie de dispositivos virtuales que funcionan como
los de un equipo físico.
Una máquina virtual se compone de varios archivos, entre los más importantes está el de configuración
(vmx), el de disco virtual (-flat.vmdk), el de configuración de NVRAM (nvram) y el de registro (log)
• .vmx Archivo de configuración de la máquina virtual
• .vmxf Archivo de configuración de la máquina virtual adicional
• .vmdk Archivo de características del disco virtual
• -flat.vmdk Archivo de datos del disco virtual
• .nvram Archivo de configuración de la BIOS o EFI de la máquina virtual
• .vmsd Archivo de Snapshot de la máquina virtual.
• .vmsn Archivo de datos de Snapshot de la máquina virtual
• .vswp Archivo de intercambio de la máquina virtual
• .vmss Archivo de suspensión de la máquina virtual
• .log Archivos de registro de la máquina virtual.
• .vmtx Archivo de plantilla, reemplaza el archivo .vmx al convertir la Máquina virtual

en plantilla.
Ejemplo de composición de una máquina virtual desde la shell.
Vista desde vSphere Client.
11.2 Componentes de una máquina virtual

Las máquinas virtuales disponen de un sistema operativo, las VMware Tools que se instalan como
un componente casi imprescindible, recursos virtuales y Hardware virtual. Estos componentes se
administran del mismo modo que los de un equipo físico.
Sistema operativo: un sistema operativo invitado que se instala igual que un equipo físico, puede ser
Windows, Linux….
VMware Tools: VMware Tools es un conjunto de utilidades que mejora el rendimiento y la administración
del sistema operativo invitado de la máquina virtual. Incluye los controladores de dispositivos y otro
software que es esencial para la máquina virtual.
Dispositivos de Hardware: como en un equipo físico, los dispositivos de hardware como CPU, RAM,
Disco… de una máquina virtual cumplen la misma función. Podemos añadir o quitar según necesidades.
Hardware virtual: Al crear o actualizar una máquina virtual existente, se usa la funcionalidad de
compatibilidad de máquinas virtuales para seleccionar las versiones de host ESXi en las que puede
ejecutarse la máquina virtual. La configuración de compatibilidad determina el hardware virtual
disponible para la máquina virtual, que corresponde al Hardware físico disponible en el host. El
Hardware virtual incluye BIOS y EFI, las ranuras de PCI virtuales disponibles, la cantidad máxima de
CPU, la configuración máxima de memoria y otras características.
12. Administrar Máquinas Virtuales
12.1 Creación de una Máquina Virtual

Hay muchas maneras de crear una máquina virtual, pero la más conocida y fácil de implementar es a
través del asistente de nueva máquina virtual. Este asistente lo podemos iniciar haciendo clic con el
botón derecho desde la parte Clúster, desde un Host ESXi, desde el DataCenter, carpeta etc etc.
En tipo de creación seleccionaremos Crear una nueva máquina virtual, siguiente.
En nombre y carpeta escribiremos un nombre único para la máquina virtual y seleccionaremos una
carpeta como ubicación.
Seleccionaremos el recurso informático, en este caso un host ESXi, si tenemos configurado DRS,
el mismo nos seleccionará el ESXi que mejor este de recursos. Si hubiese algún problema de
compatibilidad nos mostraría una alerta en el panel inferior.
Seleccionamos el almacenamiento, lo mismo que en el paso anterior, Si hubiese algún problema de

compatibilidad nos mostraría una alerta en el panel inferior.
En seleccionar compatibilidad seleccionamos la última, ya que todos nuestros ESXi son ESXi 6.7 y
superior. De tener en vuestro DataCenter algún ESXi con una versión inferior, no la creéis con una
versión superior que pueda luego daros problemas hacer pasarlo a un host ESXi con versión inferior.
Seleccionamos la familia del sistema operativo invitado (Linux) y la versión del sistema operativo
invitado (CentOS 7 – 64 bits). Es importante seleccionar correctamente el sistema operativo invitado ya
que influye en los dispositivos compatibles, al seleccionar un sistema operativo invitado, se selecciona
la BIOS o EFI de forma predeterminada, según el firmware que admita el sistema operativo.
Al seleccionar la familia y versión del sistema operativo nos deja unos valores por defecto acordes
al seleccionado, pero si queremos cambiar algún parámetro como por ejemplo el disco o la RAM
podemos hacerlo en este paso o una vez finalizado el asistente. También podemos añadir la ISO de
instalación del sistema operativo.
Al final del asistente siempre queda el paso del resumen de todos los pasos del asistente, que viene
muy bien para repasar y cambiar algo que hayas podido hacer mal en algún paso.
Finalizada la creación de la Máquina virtual podemos iniciarla, pero yo recomiendo utilizar la Remote
Console, ya que funciona muy bien y te deja editar las opciones de la Máquina Virtual.
Se abrirá la Remote Console y haremos clic en el triángulo verde para iniciar la máquina virtual.
Como hemos tenemos la ISO montada comenzara la instalación del sistema operativo invitado.
Una vez terminada la instalación del sistema operativo invitado, nos quedará instalar las VMware Tools
para su correcto funcionamiento. Si no lo instaláis os lo recordará con un aviso de color amarillo.
En las máquinas virtuales con sistemas operativos Linux, VMware recomienda que usemos e instalemos
las open-vm-tools en vez de las suyas nativas. Para instalar las open-vm-tools, nos conectamos por un
cliente SSH o directamente desde la Remote Console e instalamos con yum install open-vm-tools, si
es en Ubuntu o derivados utilizaremos apt-get.
Una vez instaladas las VMware Tools, el warning desaparecerá y comprobaremos que estén
funcionando correctamente.
En el siguiente en enlace podemos ver cómo crear una Máquina Virtual y optimizarla al máximo.
https://www.jorgedelacruz.es/2014/05/06/crear-una-vm-y-optimizarla-al-maximo/
12.2 Clonar una Máquina Virtual Existente

Cuando clonamos una Máquina virtual lo que hacemos es una copia exacta de la VM original, la nueva
VM tendrá el mismo software instalado, mismo hardware virtual y misma configuración internamente
en el sistema operativo invitado.
Normalmente hacemos un clon cuando queremos hacer una serie pruebas y no queremos o podemos
utilizar la VM original, por posibles tiempos de parada o simplemente por no romperla.
Para crear un clon hacemos clic derecho sobre la VM que queremos clonar --- Clonar --- Clonar a
Máquina Virtual.
Comienza el asistente y seleccionamos la ubicación y el nombre de la VM. Un dato a tener en cuenta

es que el nombre que le pongamos influirá en el nombre de la carpeta y los archivos de la Máquina
virtual.
Seleccionamos el recurso informático que son el o los Host ESXi, también podemos seleccionar el
Clúster si tenemos DRS activado, el mismo nos ubicará la VM en cualquiera de los Host ESXi.
Seleccionamos el almacenamiento, un Datastore con espacio suficiente. En la opción de configurar

por disco, podemos cambiar el formato de disco de thin a thick y viceversa.
En las opciones de clonación podemos personalizar el sistema operativo, personalizar el Hardware

virtual o encender la Máquina Virtual tras la creación, esta última no es recomendable que podría crear
conflictos con la VM original.
Resumen por si queremos echar el último vistazo y finalizamos
En el inventario veremos la nueva Máquina Virtual creada.
12.3 Clonar Máquina Virtual a Plantilla

Una Máquina Virtual la podemos clonar para hacer una plantilla. Las plantillas son copias maestras de
las máquinas virtuales y las podemos utilizar para desplegar muevas Máquinas Virtuales, las plantillas
nos pueden ahorrar mucho trabajo. Algo muy común es, crear una VM desde la plantilla, instalar o
actualizar el software que tenga y volver a clonar esa VM a plantilla, de esta manera podemos guardar
versiones de plantillas.
Clic derecho sobre la VM que queremos clonar ---- Clonar a plantilla.
El asistente de Clonar a plantilla no varía mucho respecto al de Clonar Máquina Virtual, lo único que
no tiene es el paso de seleccionar recurso informático.
También está la Opción de Clonar como plantilla de biblioteca de contenido, pero esto ya lo expliqué
en el Capítulo “Biblioteca de Contenido”
Una vez finalizado iremos a Máquinas Virtuales y plantillas del inventario y veremos la nueva plantilla
creada.
12.4 Nueva Máquina Virtual desde esta Plantilla

El crear una nueva máquina virtual desde una plantilla, es crear una Máquina Virtual igual que la
plantilla, donde el software, hardware virtual y demás que se configuraron en el momento de crear la
plantilla serán los mismos.
Desde Máquinas Virtuales y plantillas, clic derecho sobre la plantilla --- Nueva máquina Virtual desde
esta plantilla
Igual que los demás procedimientos y sin variar mucho, Nombre de la Máquina Virtual y ubicación,
selección de recurso informático, selección de almacenamiento y finalizar.
12.5 Clonar Plantilla a Plantilla

También está la opción de Clonar una plantilla en otra plantilla, quizá nos interese tener una plantilla
maestra y las demás para nuestras pruebas.
El procedimiento igual que los demás, clic derecho sobre la plantilla --- Clonar a plantilla.
El asistente igual, nombre y ubicación, recurso informático y almacenamiento. Ya tenemos la plantilla

clonada.
12.6 Convertir Plantilla en Máquina Virtual

Esta la opción de convertir en Máquina virtual una plantilla, clic derecho sobre la plantilla --- Convertir
en Máquina Virtual.
En el asistente a lo único que nos da opción es a cambiar el recurso informático, que el almacenamiento,
nombre y ubicación, son los mismos que tenía cuando era plantilla.
13. Crear, eliminar, restaurar y administrar Snapshots
13.1 Que es un Snapshot

Un Snapshot es una llamémosle “foto” que conserva el estado y los datos de la Máquina Virtual en el
momento que crea el Snapshot. Los Snapshots son muy útiles cuando necesitas volver a un estado
anterior, por ejemplo, cuando quieres aplicar un parche de Windows y no sabes cómo le va a afectar,
lo correcto y recomendado es hacer un Snapshot y aplicar el parche, de esta forma, si falla en unos
segundos podemos volver atrás a un punto que la máquina virtual funcionaba correctamente.
Hay que dejar muy claro, que un Snapshot no es un Backup y que es solo útil a corto plazo, imaginar
lo que se perdería de datos revirtiendo un Snapshot un mes atrás, esto lo comento por hay gente que
todavía lo piensa. Además, VMware, recomienda no tener un Snapshot 24/48 horas, tener en cuenta
que un Snapshot puede crecer mucho en este tiempo dependiendo del tipo de operaciones que esté
haciendo internamente el Sistema operativo invitado.
13.2 Limitaciones y recomendaciones de las Snapshots

• Los Snapshot no son Backups, si la Máquina virtual se corrompe a nivel de los archivos que la
componen (vmdk, vmx...) los Snapshots que tenga no te valdrán para nada.
• No se pueden hacer Snapshots de discos RDM físicos y Sistemas operativos que tengan un disco
a través de un iniciador iSCSI
• No se puede hacer Snapshots de discos independientes.
• Los dispositivos PCI de vSphere DirectPath I/O no son compatibles con los Snapshots.
• VMware solo permite 32 Snapshots por máquina virtual. A más Snapshots concurrentes más
escrituras en disco simultaneas por cada byte que escribas en la máquina virtual, esto puede
ralentizar muchísimo la máquina virtual y añadir mucha carga extra a las cabinas o disco de
almacenamiento, lo que afectaría al resto de máquinas virtuales.
13.3 Crear un Snapshot

Crear un Snapshot no tiene ningún misterio, pero en algún momento sí que puede afectar el proceso de
creación o borrado del Snapshot a la Máquina Virtual “congelando” durante algún segundo el sistema
operativo invitado.
Seleccionamos la Máquina Virtual de la que queremos hacer el Snapshot, clic derecho ---- Snapshots
---- Crear Snapshot.
Le ponemos nombre y una descripción (opcional, pero muy recomendado).
Podemos seleccionar una de las 2 opciones o ninguna,
Snapshots creados con memoria
Viene marcada por defecto y cuando comienza el proceso de creación del Snapshot, captura el estado
de la memoria de la Máquina Virtual en un momento preciso.
Snapshots en modo inactivo
Las VMware Tools ponen en modo inactivo al sistema de ficheros de la Máquina Virtual. Ponerlo
en modo inactivo se garantiza que el disco de la Snapshot se quede en un estado coherente de los
sistemas de ficheros invitados.
Sin marcar ninguna de las opciones
El proceso de creación del Snapshot es mucho más rápido, pero al revertir el Snapshot, nos
encontraremos con el estado de la máquina virtual apagada.
13.4 Archivos de los Snapshots.

Cuando creas un Snapshot te genera una serie ficheros dentro de la carpeta de la Máquina Virtual.
Archivos de base de datos
Es el archivo con extensión. vmsd, que contiene la información del Snapshot, el archivo contiene las
relaciones entre los Snapshots y los discos secundarios de los Snapshots.
Archivo de memoria
Es el archivo con extensión .vmsn que incluye el estado activo de la máquina virtual, y pertenece a
los Snapshots creadas con memoria, permite revertir el Snapshot a un estado con la máquina virtual
encendida. Se genera un fichero vmsn cada vez que se crea un Snapshot.
Archivos de disco delta
El disco delta es la diferencia entre el estado actual del disco virtual VMDK y el estado que tenía en el
momento de crear el Snapshot, cuando se crea el Snapshot el sistema operativo deja de escribir datos
en él y crea el disco delta para continuar escribiendo los datos en él, el fichero tiene una extensión
vmdk, que para diferenciarlo del primario utiliza la siguiente sintaxis vm_name-000001.vmdk.
13.5 Restaurar Snapshots

Cuando se restaura un Snapshot, la memoria de la máquina virtual, los discos, configuración … vuelven
al estado en el que se encontraba en el momento que se hizo la Snapshot, se perderían los datos entre
el estado actual y el momento de la creación del Snapshot
Desde el administrador de Snapshots podemos ver toda la jerarquía de Snapshots para ver a cuál nos
interesa revertir. Es muy importante poner un nombre y una descripción cuando creamos el Snapshot,
el poner test1, test2 , prueba3 y todos estos nombres pueden llevarnos a confusión y a ejecutar una
restauración errónea.
Podemos revertir el Snapshot directamente desde la Máquina virtual, clic derecho --- Revertir al último
Snapshot, restauraría un nivel hacia arriba desde la posición Usted está aquí. Si nos fijamos en la
imagen anterior iríamos al Snapshot llamado “cambio de credenciales”.
Con la opción Revertir A dentro del administrador de Snapshots podemos seleccionar cualquiera de
los Snapshots de la jerarquía.
Vamos a probar, seleccionamos la Snapshot y revertir A
Se ha hecho un viaje en el tiempo y nos hemos ido al momento de la creación del primer Snapshot.
Ahora realizaremos otro Snapshot desde el punto en el que nos encontramos.
Al crear un nuevo Snapshot a partir del primer punto al que hemos revertido, nos generará una nueva
rama del árbol de Snapshots.
13.6 Eliminar Snapshots

Al eliminar una o todos los Snapshots, estas se quitan del Administrador de Snapshots. Los archivos
del Snapshot se consolidan y escriben en el disco de Snapshot primario, seguido, se combinan con el
disco base de la máquina virtual.
Atención al eliminar un Snapshot que lleve mucho tiempo y que hay crecido bastante, puede que en el
momento de eliminar el Snapshot y consolidar los discos, el sistema operativo invitado se pueda ver
afectado en lo que a rendimiento se refiere.
Podemos eliminar los Snapshots de uno en uno o todas de golpe, con las opciones de Eliminar.
Y Eliminar todo.
13.7 Consolidar Snapshots

El consolidar Snapshots lo que hacer es buscar los discos delta de la Máquina virtual y combinarlos sin
perder la dependencia de datos.
Si nos fijamos en los eventos, cuando eliminamos los Snapshots, comienza un proceso de consolidación
de discos.
Este proceso puede que en alguna ocasión no funcione correctamente y al eliminar los Snapshots
nos deje algún disco delta sin combinar. Cuando ocurre esto, en el vCenter puede que nos aparezca
un warning avisándonos que los discos necesitan consolidación. Cuando nos ocurra esto tenemos la
opción de consolidar manualmente.
Clic derecho sobre la Máquina Virtual --- Snapshots --- Consolidar.
Si esto no funciona, sería cuestión de investigar un poco más a fondo y probar otras vías para
solucionarlo.
14. VMware Remote Console y consola Web
Desde el vSphere Client y el VMware Host Client podemos acceder a las Máquinas Virtuales mediante
una serie de consolas.
14.1 Consola Web

La consola Web con todos los respetos, no vale prácticamente para nada, quizá para hacer login si
tienes un password sin símbolos, ya que el teclado español no está disponible e intentar introducir un
password pude ser un dolor.
14.2 VMware Remote Console

La Remote Console es una consola que funciona de maravilla. Es una aplicación independiente que
tenemos que descargar e instalar. Con esta consola podemos instalar el sistema operativo invitado,
configurar el hardware virtual…
Para instalar la Remote Console, hacemos clic sobre la admiración que está a la derecha de “iniciar
Remote Console”, y en el bocadillo, le damos a descargar.
Nos redirigirá a la web de VMware, donde necesitaremos una cuenta activa en VMware para descargarlo.
Una vez descargada, la instalamos, siguiente, siguiente.
Una vez instalada, la ejecutamos, desde la consola podemos actualizar o instalar las VMware tools,
mapear ISOS, reiniciar etc
Una opción interesante es la de poder conectar una ISO desde el cliente del que nos conectamos a la
consola, de esta manera evitar subir ISOS al Datastore o a la Biblioteca de contenido.
Desde el menú donde está el nombre de usuario con el que hemos hecho login, podemos cambiar la
preferencia de la consola de la Máquina Virtual. Hacemos clic en Change VM Console Preference.
Y nos saltará la ventana de configuración de preferencia de consola, no hace falta que repita que
utilicéis la VMware Remote Console.
También podemos usar la Consola Web y la Remote console desde VMware host Client del ESXi.
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 3
Instalación, Configuración y
Actualización
Xavier Caballé
Capítulo 3 - Instalación, Configuración y Actualización Xavier Caballé
Instalación, Configuración y Actualización

Bienvenidos al capítulo de instalación, configuración y actualización de un entorno de virtualización de
VMware.
En este capítulo encontrareis toda la información necesaria para poder realizar una instalación básica
de un entorno de virtualización basado en tecnologías VMware.
El entorno más básico que nos permitirá aprovechar todas las ventajas que nos proporciona la
virtualización sistemas operativos usando VMware como por ejemplo él VMware High Availability,
deberá estar formado por un mínimo de dos servidores físicos y un servidor de vCenter.
El servidor de vCenter de nuestro entorno, puede ser desplegado en dos formatos distintos. En forma
de máquina virtual, ya sea usando un equipo Microsoft Windows o directamente un servidor virtual
Appliance, o podemos utilizar un servidor físico que tenga un sistema operativo Windows instalado.
Veremos paso a paso como desplegar nuestro entorno y configurar la información básica de cada uno
de los sistemas que lo componen, como puede ser, Nombres, direcciones IP, DNS, etc..
1. Consideraciones previas a la instalación o actualización

de un host
Antes de empezar la instalación o actualización de un servidor host de VMware es de obligado

cumplimiento comprobar que el hardware de nuestro servidor físico es 100% compatible con la nueva
versión de VMware vSphere que pretendemos desplegar.
Si nuestro entorno ya dispone de otros servidores host en producción, también es una buena práctica
comprobar que la nueva versión de VMware que desplegaremos en el nuevo servidor, sea actualizable
a todos host que actualmente se encuentran productivos en nuestro entorno.
También, tenemos que verificar que todos los host son compatibles entre sí con alguno de los modos
de Enhaced vMotion Capability (EVC). Si no pudiéramos configurar EVC por incompatibilidad de
alguno de los servidores, sería imposible usar vMotion.
Usando Enhanced vMotion Compatibility, eliminaremos todos los problemas de compatibilidad

que pueda haber entre las CPU de nuestros servidores que pertenezcan a distintas generaciones de
procesador, cuando usamos la tecnología vMotion.
EVC configurará de forma automática los distintos procesadores de nuestros servidores host usando
las tecnologías Intel FlexMigration o AMD-V Extended Migration, dependiendo de cada fabricante,
para que estas sean compatibles entre sí.
Después de activar EVC en un clúster de vCenter Server, todos los hosts que lo componen estarán
configurados para presentar idénticas características de procesador, de este modo, lograremos
garantizar la compatibilidad entre las distintas CPU de nuestros host cuando usamos vMotion.
Para realizar las comprobaciones, usaremos la herramienta VMware Matrix Compatibility Guide.
Podéis ver unos ejemplos de uso en los enlaces que mostramos a continuación.
VMware EVC: Entornos que tienen servidores con distintos modelos de CPU.
https://www.pantallazos.es/2016/10/vmware-evc-entornos-con-distintos-cpu.html
VMware Enhanced vMotion Compatibility: Activar EVC.
https://www.pantallazos.es/2017/02/VMware-Enhanced-vMotion-Compatibility-Activar-EVC.html
2. Instalar un nuevo servidor host
El proceso de instalación de un nuevo servidor ESXi, no varía mucho en cualquiera de las versiones
de VMware vSphere que pretendamos instalar, de hecho podríamos decir que es exactamente igual.
Para instalar un nuevo servidor host, en primer lugar, deberemos descargar la imagen ISO del producto
de la página oficial de VMware.
En la página de descargas de VMware encontraremos disponibles imágenes personalizadas para

servidores de marcas como pueden ser HP, Lenovo, Fujitsu, CISCO y Hitachi.
Otros fabricantes como DELL, por ejemplo, nos ofrecerán sus imágenes de instalación personalizadas
directamente desde su propia página web oficial.
Una vez descargado el archivo ISO que corresponda a la versión del producto que queremos instalar
tendremos que montar la imagen en nuestro servidor, ya sea pasándola a un soporte USB o CD y
usando el soporte que hayamos elegido directamente en nuestro servidor o, otra posibilidad sería
usar la tarjeta ILO de HP o la iDRAC de DELL por ejemplo, para montar la imagen ISO del sistema
operativo hypervisor directamente a nuestro hardware.
Una vez montado el soporte de instalación de VMware, arrancaremos desde la imagen y aparecerá
el Boot Menú del instalador, seleccionaremos la primera opción mostrará la versión del producto que
hemos elegido instalar terminará con la palabra Installer.
Hecho esto, empezará el proceso de carga de la instalación del producto, en nuestro laboratorio
instalaremos la versión 6.7.0.
En primer lugar, nos aparecerá la pantalla de bienvenida del asistente de instalación.
Pulsaremos la tecla Enter del teclado conectado al servidor para continuar con el asistente de
instalación del producto, y seguidamente, deberemos aceptar la End User License Agreement o
EULA pulsando la tecla F11.
Seguidamente entraremos en materia, el asistente nos pedirá que seleccionemos el dispositivo de

disco en el que deseamos instalar nuestro sistema operativo.
En nuestro laboratorio de ejemplo disponemos de un volumen de disco de 40 GB para poder realizar

la instalación, lo seleccionaremos y presionaremos una vez más la tecla Enter.
Hemos de prestar la máxima atención a este punto si tuviéramos un volumen SAN conectado a nuestro
host o si servidor dispone de algún otro volumen de disco local además del destinado a la instalación
del hypervisor. Si no seleccionamos el volumen de disco correcto destinado a la instalación, podríamos
tener perdida de datos.
Seguidamente, el asistente de instalación del producto nos hará definir el idioma de nuestro teclado.
Escogeremos el que más se adecue a nuestras necesidades y presionaremos Enter para continuar.
Terminaremos la configuración del instalador, asignando una contraseña segura al nuevo usuario Root
de nuestro nuevo servidor VMware vSphere.
ESXi aplicará por defecto los requisitos de contraseña para el acceso desde la interfaz de usuario de
la consola directa, ESXi Shell, SSH o VMware host client.
Cuando creemos la nueva contraseña deberemos incluir una combinación de como mínimo tres de las
cuatro clases distintas de caracteres que mostramos a continuación:
• Letras en minúscula.
• Letras en mayúscula.
• Números.
• Caracteres especiales (como por ejemplo el guion bajo (_), el guion (-), el asterisco (*),
símbolo más (+))
De forma predeterminada, la longitud de la contraseña debe tener más de 7 caracteres y menos de 40.
Las contraseñas no pueden contener una palabra de diccionario o parte de una palabra de diccionario.
Una vez tengamos configuradas todas las opciones, para proceder con la instalación del nuevo
producto, deberemos confirmar pulsando la tecla F11 de nuestro teclado.
Una vez hayamos presionado la tecla F11 en nuestro teclado, el asistente lanzará automáticamente la
instalación. Deberemos esperar pacientemente a su culminación, al terminar el proceso de instalación,
aparecerá una nueva ventana donde se nos informará del éxito de la nueva instalación, y también, de
la necesidad de reiniciar el nuevo host VMware vSphere ESXi. Presionaremos por última vez la tecla
Enter para reiniciar el servidor.
Arrancaremos por primera vez nuestro host ESXi y podremos comenzar con las tareas de configuración
del nuevo servidor.
VIDEO - VMware ESXi 6.7.0: Instalar un nuevo servidor host.
https://www.youtube.com/watch?v=P9su4iSv7mU
VMware ESXi 6.7.0: Instalar un nuevo servidor host.
https://www.pantallazos.es/2019/01/vmware-esxi-6-instalar-host.html
3. Configurar Management Network
Adaptadores de red.
Una vez tengamos instalado el nuevo sistema operativo hypervisor en el hardware que hayamos
escogido, el paso siguiente será la configuración básica del producto. A continuación, vamos a
configurar algunas opciones de la Management Network en el nuevo servidor host VMware ESXi.
La red de administración o Management Network es la red que usaremos para gestionar nuestros
host. La usaremos para conectar a los servidores de VMware vCenter o para gestionar directamente
los servidores host ESXi. Al designar una red de administración específica, podremos aislar las
conexiones a los recursos de vSphere de la red pública.
A continuación veremos cómo usar el menú System Customization (Modo texto) de nuestro host,
para agregar varios adaptadores de red a nuestra Management Network y así conseguir redundar la
red de administración del servidor host.
Todos los menús que encontrareis a continuación pertenecen a la versión 6.5.0 de VMware vSphere
ESXi pero son prácticamente iguales para todas las versiones disponibles del producto.
Cuando iniciamos un servidor VMware ESXi vSphere, la pantalla de la consola que tengamos
conectada físicamente a nuestro servidor host nos mostrará la imagen que tenemos a continuación.
En ella aparecerá información básica del sistema como pude ser, la versión de VMware ESXi y release
del vmKernel que tenemos instalados, la CPU física instalada en nuestro host, la memoria RAM física
disponible o parámetros de configuración de red configurados.
Para empezar la configuración, pulsaremos la tecla F2 de nuestro teclado. De este modo, accederemos
a la opción llamada <F2> Customize System/View Logs.
Nos aparecerá una ventana emergente, donde nos solicitará las credenciales de acceso a nuestro
servidor. Introduciremos las credenciales de acceso de nuestro usuario root y, seguidamente,
pulsaremos la tecla Enter.
En el menú de la pantalla System Customitzation, usaremos las flechas del teclado conectado a
nuestro servidor host para descender a la opción del menú lateral llamada, Configure Management
Network.
El aspecto de la pantalla cambiará y nos aparecerá un nuevo menú con las opciones de configuración
de la red de administración (Management Network).
Para configurar los adaptadores físicos asignados a la red de administración, seleccionaremos la

primera de las opciones de menú de la sección Configure Management Network, llamada Network
Adapters.
Aparecerá una pequeña ventana emergente, donde podremos seleccionar usando el teclado conectado
a nuestro servidor, los adaptadores que formarán parte del grupo de Management Network.
De este modo, podremos redundar la conexión de administración de nuestros servidores.
Finalizada la configuración, pulsaremos la tecla Enter de nuestro teclado para guardar los cambios y
cerrar la ventana de configuración de los adaptadores de red.
VMware 6.5.0: Configure Management Network - Adaptadores de red.
https://www.pantallazos.es/2018/03/vmware-6-configure-management-network-adaptadores-red.html
4. Configuración IPv4
A continuación tendremos que configurar la dirección IPv4 de nuestro nuevo servidor host VMware
vSphere ESXi.
En este apartado veremos cómo usar el menú Customize System (Modo texto) de nuestro host para
configurar opciones como IP, mascara de red y puerta de enlace, en el grupo de tarjetas de red que
componen la Management Network.
En la pantalla System Customitzation usaremos de las flechas de nuestro teclado para descender a
la opción del menú lateral llamada Configure Management Network.
El aspecto de la pantalla cambiará y nos aparecerá un nuevo menú con las opciones de Configuración
de la red de administración (Management Network).
Para configurar de dirección IPv4 asignada a la red de administración, seleccionaremos la tercera de

las opciones del menú que aparecerá en la sección Configure Management Network, llamada IPv4
Configuration.
Aparecerá una pequeña ventana emergente llamada IPv4 Configuration, donde podremos configurar
todas las opciones de red de nuestra tarjeta de red.
• Dirección IPv4.
• Mascara de subred.
• Puerta de enlace.
Finalizada la configuración pulsaremos la tecla Enter de nuestro teclado para guardar los cambios y
cerrar la ventana de configuración de la IPv4 de los adaptadores de red.
VMware 6.5.0: Configure Management Network - Configuración IPv4.
https://www.pantallazos.es/2018/03/vmware-6-configure-management-network-ipv4.html
5. Configuración de los servidores de nombres (DNS)
A continuación veremos configurar los servidores de nombres (DNS) usando el menú Customize
System (Modo texto) de nuestro.
de la red de Administración (Management Network).
Para configurar los servidores de DNS de la red de administración de nuestro host, seleccionaremos
la quinta de las opciones de menú de la sección Configure Management Network, llamada DNS
Configuration.
Aparecerá una pequeña ventana emergente llamada DNS Configuration, donde podremos introducir
las direcciones IP de los servidores de nombres de nuestra red.
También nos permitirá asignar un nombre a nuestro servidor host.
VMware 6.5.0: Configure Management Network - Configuración DNS.
https://www.pantallazos.es/2018/03/vmware-6-configure-management-network-configuracion-dns.
html
6. Configuración IPv6
Por ultimo vamos a descubrir como configurar la dirección IPv6 en un host VMware vSphere ESXi.
Por defecto IPv6 estará activado en la instalación de un nuevo host de VMware, si nuestro entorno no
dispone de direccionamiento IPv6 es una buena práctica deshabilitar el apartado de IPv6 Configuration
de nuestro host.
de la red de Administración (Management Network).
Para configurar de dirección IPv6 asignada a la red de administración, seleccionaremos la cuarta de

las opciones de menú de la sección Configure Management Network, llamada IPv6 Configuration.
Aparecerá una pequeña ventana emergente llamada IPv6 Configuration, donde podremos configurar
las opciones de nuestra tarjeta de red.
Podemos elegir entre tres opciones:
• Deshabilitar IPv6.
• Configurar IPv6 usando un servidor de DHCP.
• Configurar IPv6 de forma manual.
Finalizada la configuración pulsaremos la tecla Enter de nuestro teclado para guardar los cambios y
cerrar la ventana de configuración de los adaptadores de red.
Terminada la configuración presionaremos la tecla Esc de nuestro teclado para salir del menú Configure
Management Network.
Nos aparecerá una última ventana emergente para que confirmemos todos los cambios que hemos
realizado durante la configuración de las tarjetas de red de nuestro host VMware ESXi vSphere.
Si hemos realizado cambios en la red de administración del host. La aplicación de estos cambios
puede ocasionar una breve interrupción de la red, desconectar el software de administración remota y
afectar la ejecución de máquinas virtuales. En caso de que hayamos habilitado o deshabilitado IPv6 el
reinicio de nuestro servidor host será necesario.
Confirmaremos que todo es correcto pulsando la tecla Y y nuestro servidor host reiniciará.
Una vez termine el reinicio del servidor aparecerá el menú principal System Customization donde
podremos comprobar todos los cambios ya aplicados.
Pulsaremos una vez más la tecla Esc en el teclado de nuestro host para volver a la pantalla de
bienvenida de VMware ESXi vSphere.
VMware 6.5.0: Configure Management Network - Configuración IPv6.
https://www.pantallazos.es/2018/03/vmware-6-configure-management-network-ipv6.html
VIDEO - VMware 6.5.0: Configure Management Network.
https://youtu.be/fLXc7eocmPY
7. Actualizar un servidor host VMware vSphere ESXi
En este capítulo veremos, como actualizar un servidor host VMware vSphere ESXi.
En nuestro ejemplo, actualizaremos un servidor que se encuentra en producción con la versión ESXi
6.0.0 a la versión ESXi 6.7.0, pero el procedimiento es básicamente una tarea similar para todas las
versiones del producto.
Para actualizar un nuevo servidor host, en primer lugar, deberemos descargar la imagen ISO de la
nueva versión de ESXi, compatible con el hardware de nuestro equipo, a la que queremos actualizar
nuestro servidor.
Recortemos que antes de empezar la actualización de un servidor host de VMware comprobaremos

que el hardware de nuestro servidor es 100% compatible con la versión de VMware vSphere que
pretendemos desplegar.
Como hemos comentado en el apartado de la instalación de un nuevo servidor host, podremos descargar
imágenes personalizadas para servidores de marcas como pueden ser HP, Lenovo, Fujitsu, CISCO,
Hitachi o DELL. Una vez descargado el soporte de instalación de VMware lo montaremos en nuestro
hardware para empezar la actualización del producto.
Seguidamente, tenemos que mover todas las máquinas virtuales, que dependen del servidor Host
que queremos actualizar, a otro Host de nuestra granja de VMware. Si solo disponemos de un único
servidor VMware vSphere ESXi tendremos que parar las máquinas virtuales.
Una vez hayamos movido o apagado todas las máquinas virtuales que dependen del host que queremos
actualizar, montaremos el soporte de instalación de VMware vSphere y arrancaremos desde la imagen.
Aparecerá el Boot Menú del instalador, en el que seleccionaremos la primera opción. Especificará la
versión del producto que hemos elegido para actualizar terminará con la palabra Installer.
Hecho esto, empezará el proceso de carga de la instalación del producto, en nuestro laboratorio
instalaremos la versión 6.7.0.
En primer lugar, aparecerá la pantalla de bienvenida del asistente de instalación. Pulsaremos la tecla
Enter del teclado conectado al servidor para continuar con el asistente de instalación del producto, y
seguidamente, deberemos aceptar la End User License Agreement o EULA pulsando la tecla F11.
A continuación, el asistente de actualización nos permitirá seleccionar el disco duro, donde tenemos
instalado actualmente el sistema operativo del hypervisor,
En nuestro laboratorio de ejemplo disponemos de un volumen de disco de 40 GB en el cual tenemos

instalado el antiguo sistema operativo de VMware, lo seleccionaremos y presionaremos una vez más
la tecla Enter.
Hemos de prestar la máxima atención a este punto si tuviéramos un volumen SAN conectado a nuestro
host o si servidor dispone de algún otro volumen de disco local además del disco del sistema operativo
del hypervisor. Si no seleccionamos el volumen de disco correcto, podríamos tener perdida de datos.
Seguidamente, aparecerá una nueva ventana emergente que nos permitirá decidir que queremos
hacer con el volumen VMFS existente. Seleccionaremos la primera de las opciones llamada Upgrade
ESXi, preserve VMFS datastore, de este modo, solo actualizaremos el operativo sin cambiar ninguna
configuración y no perderemos ningún dato.
La última sección del asistente de actualización de VMware ESXi será la confirmación de las selecciones
realizadas durante el asistente. Confirmaremos, que queremos proceder a realizar el Upgrade de la
versión de VMware vSphere ESXi 6.0.0 a la versión ESXi 6.7.0, para ello, presionaremos F11.
Esperaremos a que termine de actualizar el sistema operativo.
Terminada la actualización de nuestro sistema operativo hypervisor, reiniciaremos el servidor ESXi.
Cuando el servidor arranque, comprobaremos que hemos actualizado a la nueva versión de ESXi.
VMware ESXi 6.7.0: Actualizar un servidor host de la versión 6.0.0.
https://www.pantallazos.es/2019/01/vmware-esxi-6-actualizar-servidor-host.html
VIDEO - VMware ESXi 6.7.0: Actualizar un servidor host de la versión 6.0.0.
https://youtu.be/E1pDfRaeiio
8. Introducción vCenter Server
VMware vCenter Server nos permitirá gestionar nuestro entorno de vSphere desde una única consola
centralizada. Desplegaremos un servidor de vCenter en entornos de virtualización con más de un host
ESXi, no tiene sentido asumir el consumo de recursos que el despliegue de un vCenter supone si solo
tenemos un único host en nuestro entorno.
Hay alguna función, como por ejemplo la creación de plantillas a partir de una máquina virtual, que
solo podremos usar desde un servidor de vCenter. En estos casos también estaremos obligados a
desplegar vCenter Server.
Podremos optar varios tipos distintos de instalación para el mismo producto. Podremos elegir entre
instalar un servidor Windows y desplegar el instalador de vCenter en el sistema operativo de
Microsoft o también podemos usar el Appliance virtual empaquetado y optimizado por VMware, que
nos facilitará en gran medida la instalación y mantenimiento del producto.
En las últimas versiones del producto, el cliente de vSphere está basado en HTML5 y nos permitirá
gestionar todas las funciones de desde cualquier navegador de internet.
También, nos permitirá asignar funciones a distintos tipos de usuario dependiendo de las tareas
concretas que tengan que realizar en nuestra consola de gestión.
Desde la consola de vCenter Server dispondremos de visibilidad y control de todas nuestras máquinas
virtuales, servidores host y almacenes de datos.
vCenter nos permitirá usar API’s de servicios web para conseguir integrar nuestro servidor con otros
productos de gestión de sistemas existentes en nuestra red.
Podremos usar vCenter server para realizar tareas como vMotion, Snapshot que simplificarán en
gran medida el mantenimiento de nuestros servidores, o simplemente proteger nuestro entorno y todos
sus servicios usando la alta disponibilidad nativa y conseguir un Tiempo objetivo de recuperación
(RTO) inferior a los 10 minutos.
9. Instalación de un nuevo servidor vCenter Appliance
9.1 Stage 1 Deploy vCenter Appliance
El capítulo que empezamos a continuación, está dedicado a la instalación y configuración de un nuevo

servidor de vCenter Appliance de la versión 6.7.0.
Antes de empezar con el proceso de despliegue del producto, vamos a ver algunas de las novedades
de las que disfrutaremos usando un servidor de vCenter Server de la versión 6.5.0 en adelante.
En el propio instalador de vCenter Server Appliance, tiene varias herramientas incorporadas que nos
permitirán actualizar o realizar una migración desde un servidor vCenter antiguo a una versión más
moderna del producto.
La herramienta de migración, presenta varias mejoras con respecto a la versión que se suministraba
con la versión 6.0.0 Update 2. Gracias a estas mejoras de la herramienta de migración, nos permitirá
realizar una selección granular de todos los datos que queremos que sean migrados al nuevo vCenter
server.
• Configuration.
• Configuration, events, and tasks.
• Configuration, events, tasks, and performance metrics.
VMware Update Manager o VUM ahora formará parte de vCenter Server Appliance. Si ya hemos
migrado a vCenter Server Appliance de la versión 6.0, el proceso de actualización, migrará nuestras
VUM baselines y las actualizaciones al nuevo servidor vCenter Server Appliance. Durante el
proceso de migración, los datos de configuración, inventario y alarmas de vCenter se moverán de
forma predeterminada.
Otra característica de vCenter Server Appliance es la mejora de las capacidades de administración de

dispositivos. La nueva interfaz de usuario ahora muestra estadísticas de red, base de datos, espacio en
disco, estado de salud, además, de estadísticas de CPU y memoria. Lo que disminuye la dependencia
del uso de una interfaz de línea de comandos para la motorización y tareas operacionales.
vCenter Server 6.5.0 tiene una nueva solución nativa de alta disponibilidad que está disponible
exclusivamente para vCenter Server Appliance. Esta solución consiste en tener varios nodos activos,
pasivos y Witness que son clonados a partir del servidor vCenter original. Creando una solución de
failover HA cuando se pierde uno de los nodos por completo. Cuando configuramos una solución de
alta disponibilidad desde nuestro servidor de vCenter y este cae, toda la solución funcionará aun con
la pérdida del servidor de vCenter.
Otra nueva característica de vCenter Server es la copia de seguridad y restauración integrada en

vCenter Server Appliance. Esta nueva funcionalidad out-of-the-box permite a los clientes hacer
copias de seguridad del servidor vCenter y Platform Services Controller directamente desde Virtual
Appliance Management Infrastructure (VAMI) o API.
Con vCenter, también tenemos una versión del cliente vSphere basado en HTML5 que se ejecuta
junto con vSphere Web Client.
VSphere Client está integrado en vCenter Server tanto para Windows como con el virtual Appliance
y está habilitado de forma predeterminada, pero todavía no tiene todas las características completas.
En primer lugar vamos a descargar la imagen ISO desde la página oficial de VMware. Encontraremos
que el instalador estará disponible para realizar el despliegue del nuevo Appliance desde sistemas
operativos Windows.
Una vez hayamos descargado la imagen en nuestro equipo, ejecutaremos el instalador. En nuestro
laboratorio ejecutaremos el instalador para Windows que se encuentra en la carpeta:
[CD/DVD]:\VCSA-UI-INSTALLER\WIN32\INSTALLER.EXE
Aparecerá una nueva ventana llamada vCenter Server Appliance 6.7 Installer, en ella pulsaremos
la opción Install.
Descubriremos en el menú principal que también tenemos disponibles las opciones que anteriormente
hemos mencionado, para poder realizar una actualización de un antiguo servidor de vCenter o para
migrar un antiguo servidor de virtual center a una nueva máquina virtual Appliance.
La primera ventana del asistente será la Introduction, donde nos describirá el proceso de instalación
del producto.
El proceso total de despliegue estará formado por dos escenarios, el primero será el despliegue o
Deploy de nuestro nuevo vCenter Appliance y el segundo escenario será el Setup o configuración
del mismo. Seguidamente presionaremos el el botón Next para comenzar el Stage 1 o despliegue del
nuevo Appliance. Pulsaremos el botón Next para continuar.
Seguidamente, nos encontraremos en la sección llamada End user License Agreement. En

ella deberemos aceptar la End User License Agreement o EULA de VMware y, a continuación,
presionaremos el botón Next para continuar con el asistente.
En la siguiente sección del asistente de instalación llamada Select Deployment Type, tendremos dos
modos disponibles para realizar la instalación:
• vCenter Server With Embedded Platform Services Controller: instalará Platform Services
Controller dentro de la propia máquina virtual de VMware vCenter Server Appliance. Es la opción
recomendada para entornos pequeños con solo un único servidor de vCenter.
• vCenter Server With External Platform Services Controller. Instalará un servidor de vCenter
en un equipo y Platform Services Controller en un Appliance virtual separado. Esta opción
nos permitirá controlar varios servidores de vCenter Server desde un mismo punto. Nos permitirá
crear una instalación distribuida de nuestro entorno. Es la opción recomendada para entornos
grandes con más de un servidor de vCenter.
Una vez hayamos elegido el modo para nuestro despliegue pulsaremos el botón Next para avanzar
en el asistente.
Seguidamente, nos encoraremos en la ventana llamada Appliance deployment target, en esta nueva
sección deberemos rellenar el formulario con los datos de uno de nuestros servidores host ESXi, será
el servidor host donde queremos desplegar nuestro nuevo vCenter Appliance.
• Dirección IP o FQDN de nuestro servidor host.
• Puerto HTTPS.
• Nombre de usuario.
• Contraseña de acceso.
Una vez hayamos cumplimentado todo el formulario, pulsaremos el botón Next para avanzar a la
siguiente sección del asistente de despliegue de vCenter Appliance.
La siguiente sección será Set up appliance VM, en ella vamos a definir el nombre de la nueva máquina
virtual y la contraseña que queremos asignar en el usuario root del servidor de virtual center.
La nueva contraseña definida en este formulario la usaremos para poder realizar las tareas de gestión
desde la UI.
La ruta para acceder a la consola de gestión será la siguiente:
https://IP_o_FQDN:5480
Una vez hayamos pulsado el botón Next, nos encoraremos en la sección Select deployment
size. Donde, mediante unos sencillos menús desplegables, conseguiremos definir el tamaño de
infraestructura que soportará nuestro nuevo servidor de virtual center.
Para seleccionar el tamaño del vCenter Appliance, tendremos que tener en cuenta cuántas máquinas
virtuales y servidores host ESXi tendrá que gestionar. En nuestro laboratorio, hemos seleccionado la
opción minúscula o Tiny, ya que en nuestro entorno solo tenemos dos servidores host y menos de 100
Dependiendo de nuestras selecciones, el tamaño de los recursos necesarios para nuestro nuevo
servidor de vCenter variará.
No tener No tener Default Large X-Large

Número
más más VM Memoria Storage Storage Storage
de vCPUs
hosts de de Size Size Size
Entorno
10 100 2 10 GB 250 GB 775 GB 1650 GB
Tiny
Entorno
100 1.000 3 16 GB 290 GB 820 GB 1700 GB
Small
Entorno
400 4.000 4 24 GB 425 GB 925 GB 1805 GB
Medium
Entorno
1.000 10.000 16 32 GB 640 GB 990 GB 1870 GB
Large
Entorno
2.000 35.000 24 49 GB 980 GB 1030 GB 1910 GB
X-Large
La siguiente sección del asistente será Select datastore, en ella tendremos que seleccionar un
Datastore con espacio suficiente para albergar nuestro nuevo servidor de vCenter Appliance 6.7.
Una vez seleccionado, presionaremos una vez más el botón de siguiente para avanzar en el asistente
de despliegue del producto.
Llegaremos a la sección llamada Configure Network settings, donde configuraremos los ajustes de
red de nuestro nuevo servidor de vCenter.
Los parámetros a cumplimentar del formulario serán los siguientes:
• Network: Seleccionaremos la red virtual donde queremos conectar nuestro nuevo servidor de
vCenter.
• IP Version: IPv4 o IPv6.
• IP Assignment: Tipo de asignación de direcciones IP estática o Dinámica.
• System Name: Nombre FQDN de nuestro nuevo servidor de vCenter.
• IP address: Direción IP que asignaremos de forma estática a nuestro nuevo servidor de vCenter.
• Subnet mask o prefix lenght: Máscara de red asignada a nuestro nuevo servidor de vCenter.
• Defaut Gateway: Puerta de enlace de nuestra infraestructura de red.
• DNS Servers: Servidores de nombres de nuestra infraestructura de red.
Es muy recomendable que nos aseguremos que la configuración de nuestro servidor de nombres sea
correcta.
Debemos asegurarnos de tener previamente configuradas las entradas de DNS correspondientes a

nuestro nuevo servidor de virtual center. De no ser así, las configuraremos antes de avanzar más en el
asistente de despliegue, si no, corremos el riesgo que la segunda parte del asistente llamada Stage 2
Setup vCenter Server Appliance falle en el inicio de su ejecución.
Después de presionar el botón siguiente, nos encontraremos en la sección Ready to complete stage
1, comprobaremos en el resumen y si todas las configuraciones realizadas durante el asistente son
correctas, seguidamente podremos presionar Finish.
El proceso de despliegue tardará más o menos, dependiendo de los recursos disponibles en nuestro
host ESXi, en nuestro laboratorio tardó unos veinte minutos en finalizar.
Una vez terminado el despliegue de la nueva máquina virtual, podremos acceder a la gestión de la
misma usando puerto 5480.
La ruta para acceder a la consola de gestión será la siguiente:
https://IP_o_FQDN:5480
También, podremos presionar el botón Continue y acceder a la segunda fase del asistente Stage 2
Setup vCenter Server Appliance.
9.2 Stage 2 Setup vCenter Server Appliance
Seguidamente, aparecerá una nueva ventana emergente con el asistente de Stage 2 Setup vCenter
Server Appliance, el cual nos dará acceso a la configuración de nuestro nuevo vCenter Appliance.
Pulsaremos el botón next para saltar la ventana llamada Introduction.
Nos encontraremos en la sección Appliance configuration, dónde se nos permitirá seleccionar la

configuración de nuestros servidores de tiempo NTP. En nuestro laboratorio, hemos seleccionado que
queremos sincronizar los servicios de tiempo con el propio servidor host de ESXi.
También, podremos habilitar o deshabilitar el acceso SSH, para las futuras configuraciones.
Seguidamente, nos aparecerá la sección llamada SSO Configuration, dónde encontraremos un

formulario que nos permitirá configurar un nuevo dominio de Single Sign-on. En nuestro laboratorio,
hemos dejado las opciones de dominio que vienen sugeridas por defecto:
• SSO domain name.
• SSO User name
• SSO Password.
• Confirm password.
• Site Name.
Podéis configurar cada una de estas opciones, con los parámetros que más se adecuen a vuestras
necesidades empresariales. Pulsaremos nuevamente el botón siguiente para continuar.
La contraseña predeterminada del administrador de vCenter Single Sign-On, administrator@

vsphere.local, se especifica en la directiva de contraseñas de vCenter Single Sign-On. De manera
predeterminada, esta contraseña debe cumplir con los siguientes requisitos:
• Tener al menos ocho caracteres
• Tener al menos un carácter en minúscula
• Tener al menos un carácter numérico
• Tener al menos un carácter especial
La contraseña de este usuario no puede superar los 20 caracteres. A partir de vSphere 6.0, se permiten
caracteres que no son ASCII. Los administradores pueden cambiar la directiva de contraseñas
predeterminada.
La siguiente sección será Configure CEIP, el programa Customer Experience Improvement

Program o CEIP de VMware facilita información que ayudará a VMware a mejorar sus productos y
servicios, a solucionar problemas y también a asesorará sobre la mejor forma de implementar y utilizar
sus productos.
Podremos seleccionar si queremos unirnos al programa de mejora de VMware, o por lo contrario,

queremos desactivar CEIP.
La última sección del Stage 2 Setup vCenter Server Appliance 6.7 será Ready to complete, si todos
los parámetros que hemos configurado durante el asistente son correctos, estaremos en disposición
de presionar Finish para configurar nuestra nueva máquina virtual de vmware vCenter Appliace 6.7.
El proceso de configuración tardará unos diez minutos. Una vez haya completado el proceso, ya
podremos tener acceso a nuestro vCenter Web client.
vSphere Web Client:
https://IP_o_FQDN:443/vsphere-client
Appliance Getting Started Page:
https://IP_o_FQDN:443/
Podremos ver que tenemos acceso al cliente usando HTML5.
10. Instalación vCenter para Windows
En primer lugar vamos a descargar la imagen ISO desde la página oficial de VMware, el instalador
estará disponible para realizar diferentes tipos de despliegue. Como puede ser, el VMware vCenter
Server Appliance, el caso que hemos visto en el apartado anterior y para instalar en un sistema
operativo Microsoft Windows que es la opción que veremos a continuación.
Cuando optamos por la instalación de vCenter Server para Windows, hemos de tener en cuenta que
la versión de Windows que instalada en el servidor que pretendemos usar, sea compatible con los
requisitos mínimos necesarios de vCenter Server.
Una vez hayamos descargado el archivo comprimido con el software para realizar la instalación en
nuestro equipo, ejecutaremos el instalador. En nuestro laboratorio ejecutaremos el instalador para
Windows que se encuentra en la carpeta:
[CD/DVD]:\autorun.EXE
En primer lugar, aparecerá la pantalla de bienvenida del asistente de instalación de vCenter Server
para Windows. Presionaremos el botón llamado Next> para continuar con el asistente de instalación
del producto, y seguidamente, deberemos aceptar la End User License Agreement o EULA y pulsar
nuevamente Next> para comenzar con la configuración.
En la siguiente sección del asistente de instalación llamada Select Deployment Type, tendremos dos
modos disponibles para realizar la instalación:
• Instalar vCenter Appliance con el Platfrom Services Controller o PSC en un mismo servidor.
• Instalar vCenter Appliance solamente, y desplegar un Appliance independiente con los
Platform Services Controller.
Una vez hayamos elegido el modo para nuestro despliegue pulsaremos el botón Next> para avanzar
en el asistente.
La siguiente sección del asistente de instalación de vCenter server se llamará System Network
Name.
Escribiremos el nombre del servidor que usaremos para administrar el sistema local. El nombre del
servidor que especifiquemos se codificará en el certificado SSL del nuevo servidor de vCenter para
que todos los componentes puedan comunicarse entre sí utilizando el nombre del servidor.
Tenemos que usar un fully-qualified domain name (FQDM), pero si el servidor de nombres (DNS)
de nuestra organización no está disponible, podemos escribir una dirección IP estática en lugar de un
nombre (FQDM).
Seguidamente, nos aparecerá la sección llamada SSO Configuration, dónde encontraremos un

formulario que nos permitirá configurar un nuevo dominio de Single Sign-on.
• SSO domain name.
• SSO User name
• SSO Password.
• Site Name.
Podéis configurar cada una de estas opciones, con los parámetros que más se adecuen a vuestras
necesidades empresariales. Pulsaremos nuevamente el botón siguiente para continuar.
La contraseña predeterminada del administrador de vCenter Single Sign-On, se especifica en la

directiva de contraseñas de vCenter Single Sign-On. De manera predeterminada, esta contraseña
deberá cumplir con los siguientes requisitos:
• Tener al menos ocho caracteres
• Tener al menos un carácter en minúscula
• Tener al menos un carácter numérico
• Tener al menos un carácter especial
La contraseña de este usuario no puede superar los 20 caracteres. A partir de la versión vSphere
6.0, se permiten caracteres que no son ASCII. Los administradores pueden cambiar la directiva de
contraseñas predeterminada según sus necesidades particulares.
A continuación tendremos que definir la cuenta de usuario con la que se van a iniciar los servicios de
nuestro servidor de vCenter.
Por defecto los servicios de vCenter arrancaran con la cuenta de sistema local de Windows, si
queremos iniciar los servicios de vCenter con otra cuenta cambiaremos el botón selector a la opción
llamada Especificar una cuenta de usuario de servicio y definiremos el nombre de usuario y la
contraseña que deseemos.
vCenter Server requiere una base de datos para almacenar los datos del servidor.
Cada instancia de vCenter Server debe disponer de su propia base de datos. En un entorno con hasta
20 hosts y 200 máquinas virtuales, podemos usar la base de datos de VMware Postgres que viene
incluida con la instalación vCenter. Podremos instalar este tipo de base de datos, durante el proceso
del asistente de instalación del producto.
Una instalación más grande requiere una base de datos externa al servidor de vCenter que sea
compatible con el tamaño de nuestro entorno.
vPostgres se basa en la base de datos de código abierto llamada PostgreSQL. En la versión de

vCenter Server 6.0 se incluyó la versión de base de datos PostgreSQL 9.3 y, a medida que vCenter
Server aumentaba su versión, también se ha actualizado la versión de PostgreSQL.
PostgreSQL, es posiblemente el sistema de gestión de bases de datos relacionales de código abierto

más potente que existe y admite múltiples plataformas, como pueden ser, Windows, SUSE Linux
Enterprise Server y Red Hat, HPUX y UNIX, por ejemplo.
VMware ha mejorado el rendimiento de la base de datos en comparación con PostgreSQL estándar.
Las bases de datos PostgreSQL precisan de un mantenimiento periódico para conseguir recuperar el
espacio en disco perdido a causa los datos eliminados, actualización de las estadísticas usadas por el
planificador de consultas de PostgreSQL o proteger la base de datos contra la pérdida de información.
VMware ha configurado el proceso de mantenimiento de forma automática para que se ejecuten de

forma desatendida en nuestro servidor de vCenter.
El registro de escritura, permite que se realicen copias de seguridad sin tener que detener la base de
datos de vCenter. El registro de escritura, registra todos los cambios realizados en los archivos de la
base de datos y se puede usar para restaurar la coherencia de la base de datos.
Este mecanismo es lo que permite que se realicen copias de seguridad sin preocuparse por la
corrupción o el apagado de los servicios. Esto también hace que no sea necesario realizar una copia
de seguridad manual de vPostgres.
Una vez hayamos pulsado el botón siguiente, nos encontraremos en la sección dedicada a la
configuración de los puertos de red. Podremos personalizar los puertos comunes, Pataform Services
Controller y finalmente los puertos para el servidor de vCenter.
Por defecto los puertos son:
Common Ports
Http port: 80
Https port: 443
Syslog Service Port: 514
Syslog Service TLS Port: 1514
Pataform Services Controller
Secure Token Service Port: 7444
vCenter Server Ports
Auto Deploy Management Port: 6502
Auto Deploy Service Port: 6502
ESXi Dump Collector Port: 6500
ESXi Heartbeat Port: 902
vSphere web Client Port 9443
Finalizaremos la configuración basada en el asistente estableciendo la ruta de nuestro disco duro

local, donde queremos ubicar los directorios de instalación del producto.
La última sección del asistente será Ready to Install, si todos los parámetros que hemos configurado
durante el asistente son correctos, estaremos en disposición de presionar Install para empezar el
proceso de instalación de vCenter server.
Finalizado el proceso de instalación de vCenter server, pulsaremos el botón llamado Launch vSphere
Web Client.
Aparecerá la nueva ventana de inicio de vSphere Web Client, Podremos ver que tenemos acceso
usando HTML5.
11. Actualizar ESXi 5.X a 6.X usando VMware Sphere

Update Manager
Otra forma que existe para realizar la actualización de un servidor host es usar VMware Sphere
Update Manager, a continuación vamos a ver el proceso a seguir para realizar una actualización de
un host ESXi usando VMware Sphere Update Manager, en esta ocasión actualizaremos un host de
la versión 5.5 a la versión 6.0.
Usaremos el proceso de actualización mediante VMware Sphere Update Manager cuando tenemos
que actualizar un gran número de host y pretendemos realizar actualizaciones de host de manera
simultánea.
Con VMware vSphere Update Manager, podemos automatizar la gestión de parches y a la vez,
conseguiremos eliminar la tediosa tarea de tener que realizar un seguimiento de las actualizaciones
para la posterior aplicación, de forma manual de las mismas, en todos servidores hosts y máquinas
virtuales de nuestra infraestructura de virtualización.
VMware vSphere Update Manager realiza una comparación del estado actual de los servidores host
con los parámetros de referencia y, posteriormente, aplica las actualizaciones garantizando el estado
actual.
Con el panel centralizado de vSphere Update Manager tendremos una visibilidad general del estado de
las actualizaciones en toda nuestra la infraestructura virtual. Además, podremos agendar y programar
la instalación de las nuevas actualizaciones en nuestros equipos.
También podremos definir paquetes de actualizaciones que se descargarán directamente desde la

página web de VMware.
Durante el proceso de aplicación manual de las actualizaciones, sin usar vSphere Update Manager,
pueden aparecer problemas de compatibilidad que nos obligarán a tomar decisiones para su solución.
Con el uso de VMware vSphere Update Manager, conseguiremos disminuir los errores producidos
por problemas de compatibilidad detectándolos antes de que estos se produzcan, de este modo, no
perderemos tiempo restaurando versiones anteriores del producto o revisando información técnica de
VMware para la solución de problemas.
VMware vSphere Update Manager funciona junto con vSphere Distributed Resource Scheduler
(DRS), de éste modo permitirá la aplicación de las actualizaciones, sin interrupción en los hosts en el
momento de reparar un clúster.
También usará DRS, para poner nuestros servidores hosts en modo de mantenimiento y nos permitirá
migrar en directo las máquinas virtuales a otros servidores hosts durante el proceso de actualización.
Moverá de forma automática, todas las máquinas virtuales a otros hosts que se encuentren conectados
a nuestra infraestructura durante la aplicación de las actualizaciones y, posteriormente, devolverá las
máquinas virtuales a su ubicación original al finalizar el proceso.
12. Instalación del PlugIn de VMware Sphere Update

Manager en un servidor vCenter Server Appliance
A continuación, vamos a ver el proceso de instalación de VMWare Sphere Update Manager en un

servidor Virtual Center Server Appliance 6.0.
Durante la instalación de un nuevo servidor de vCenter, de la versión Appliance 6.0, no tendremos la

posibilidad de instalar el VMware Sphere Update Manager.
Como observareis en la imagen siguiente, no tenemos disponible la sección Update manager en

nuestros servidores host ni en nuestro vCenter Server Appliance.
Para poder instalar el PlugIn de Sphere Update Manager en nuestro vCenter Server Appliance,
tendremos que hacerlo directamente desde el soporte de instalación de vCenter server de Windows.
Si tuviéramos un servidor de virtual Center de windows, podremos instalar sPhere Update Manager
fácilmente al terminar de la instalación de nuestro servidor de vCenter, pero en el caso de tener un
servidor vCenter Appliance el procedimiento se nos complicará un poco más.
El primer paso será, descargar de la página web oficial de VMware la imagen del instalador de VMware
vCenter Server, en nuestro laboratorio será la 6.0 Update 2 para Windows.
Una vez tengamos descargada nuestra imagen, montaremos el DVD y ejecutaremos el instalador.
En la ventana principal de menú del instalador de VMware vCrenter, buscaremos en el menú lateral
izquierdo la sección vSphere Update Manager y pulsaremos la opción Servidor.
Seleccionaremos la opción, Usar Microsoft SQL Server 2012 Express como la base de datos
integrada y seguidamente pulsaremos el botón Instalar.
Esperaremos pacientemente a que se instalen todos los servicios de la base de datos de SQL Server
2012, al finalizar la instalación de la base de datos, de forma automática, aparecerá la ventana inicial
de VMWare Update Manager, donde nos permitirá seleccionare el idioma del asistente.
Una vez iniciado el asistente de instalación de VMWare vSphere Update Manager, nos encontraremos
con la ventana de bienvenida, que saltaremos presionando el botón Siguiente.
Seguidamente nos encontraremos en la ventana del contrato de licencia, aceptaremos los términos de
la licencia y, de nuevo, pulsaremos el botón Siguiente.
En la ventana Información de soporte técnico, aparecerá seleccionada por defecto la opción, Descargue
actualizaciones de orígenes predeterminados inmediatamente después de la instalación. Por el
momento desmarcaremos ésta opción, con el fin de revisar los orígenes antes de realizar ninguna
descarga. Presionaremos por tercera vez el botón Siguiente.
Nos encontraremos en la ventana llamada Información de vCenter Server, donde deberemos

introducir todos los datos que necesitará el asistente para establecer la conexión con nuestro servidor
de vCenter Server Appliance, terminada la introducción de las credenciales pulsaremos nuevamente
el botón Siguiente para continuar con el asistente.
En la sección llamada Configuración de puertos de VMware vSphere Updare Manager, no cambiaremos

nada dejando todas las opciones por defecto y presionaremos nuevamente Siguiente.
Dejaremos también tal cual, la configuración las carpetas de instalación del producto que viene
preconfigurada por defecto y seguidamente, aceptaremos la advertencia que nos aparecerá en una
nueva ventana emergente, referente espacio disponible en la unidad de disco. Esta advertencia solo
aparecerá si estamos instalando el producto en una unidad con menos de 120GB.
El espacio libre de la unidad seleccionada es inferior a 120GB. Utilice el estimador de tamaño de

VMware vSphere Update Manager a fin de asegurarse contar con espacio libre suficiente para
el sistema de la implementación. Encontrará el estimador de tamaño para todas las versiones
principales en
http://www.vmware.com/support/pubs/vum_pubs.html
Llegados a este punto, presionaremos el botón Instalar para proceder a la instalación. Solo nos faltará
esperar pacientemente a que termine el proceso, al finalizar la instalación, cerraremos el asistente
pulsando el botón Finalizar.
Abriremos la consola de nuestro servidor de vCenter Server Appliance y, en el menú superior de la

ventana, accederemos a la sección Complementos.
Aparecerá una nueva ventana emergente llamada, Administrador de complementos. Moveremos la

barra de desplazamiento hacia abajo hasta encontrar la Extensión de VMware vSphere Update
Manager, pulsaremos encima del enlace Descargar e instalar... para desencadenar el proceso de
instalación del complemento.
Nos aparecerá una ventana emergente, preguntándonos si queremos ejecutar el archivo de instalación
de VMware vSphere Update Manager Client, aceptaremos la ejecución pulsando el botón Ejecutar.
En la ventana inicial del asistente de instalación VMware vSphere Update Manager Client podremos
seleccionar el idioma del asistente que más nos interese y seguidamente presionaremos el botón
Aceptar.
El procedimiento de instalación posterior es muy sencillo y no tiene ninguna opción que podamos
variar, básicamente es ir pulsando el botón Siguiente hasta finalizar la instalación.
La única opción que nos permitirá variar, será la aceptación del contrato de licencia para el usuario
final, que deberemos aceptar.
Finalizado el asistente, nos aparecerá una nueva ventana emergente con la típica advertencia de
seguridad del certificado de nuestro servidor de vCenter Appliance.
Un certificado SSL que no es de confianza está instalado en “vCenter” y no se puede garantizar

la comunicación segura. En función de su directiva de seguridad, es posible que este problema
no suponga una preocupación relativa a la seguridad. Es posible que necesite instalar un
certificado SSL de confianza en el servidor para evitar que aparezca esta advertencia.
El certificado recibido desde “vCenter” se emitió para “VMware default certificate”. No se

puede garantizar la comunicación segura con “vCenter”. Asegúrese de que el nombre de
dominio completo en el certificado coincida con la dirección del servidor al que está intentando
conectarse.
Haga clic en Omitir para continuar utilizando el certificado SSL actual.
Presionaremos el botón Omitir, para usar el certificado actual y continuar. Comprobaremos que
la extensión de VMware vSphere Update Manager se ha instalado y habilitado con normalidad,
cerraremos la ventana del Administrador de complementos haciendo uso del botón Cerrar, situado en
la parte inferior derecha de la ventana.
También podemos verificar, que habrá aparecido una nueva sección en nuestro servidor de vCenter
llamada Update Manager.
vCenter Server Appliance 6.0: Instalación VMWare Sphere Update Manager - Parte 1
https://www.pantallazos.es/2016/06/instalacion-vmware-sphere-update-Manager-parte1.html
vCenter Server Appliance 6.0: Instalación VMWare Sphere Update Manager - Parte 2
https://www.pantallazos.es/2016/06/instalacion-vmware-sphere-update-Manager-parte2.html
Una vez tengamos instalado el PlugIn de Sphere Update Manager en nuestro vCenter Server
Appliance estaremos en disposición de poder actualizar nuestros servidores host.
En primer lugar, descargaremos la imagen del hypervisor de VMware de la página oficial del fabricante.
Como en los casos anteriores hemos de tener en cuenta, que tendremos disponibles imágenes
personalizadas para nuestros servidores de marca HP, DELL, LENOVO, etc...
Estableceremos una conexión con el servidor de VMware vCenter que esté gestionando el host que
queremos actualizar. Una vez tengamos abierta la consola de vCenter seleccionaremos en el árbol
de menú lateral, situado en la parte izquierda de la ventana, el servidor host que queremos actualizar.
En nuestro ejemplo, el servidor físico ya no tiene máquinas virtuales que dependen de él. Es una
buena práctica vaciar el servidor antes de la actualización, de este modo agilizaremos el proceso de
actualización del sistema operativo del host.
Habiendo seleccionado el servidor host, accederemos a la sección Update Manager, situada en el

menú superior, en ella, buscaremos el enlace llamado Vista de Administrador.
Una vez estemos en la ventana de Administrador de Update Manager para..., buscaremos en el

menú superior de la ventana, la sección llamada Imágenes ESXi. Seguidamente, accederemos a la
sección y pulsaremos en el enlace llamado Importar Imagen ESXi...
Nos aparecerá una nueva ventana emergente mostrándonos el inicio del asistente para Importar
imagen ESXi. En la sección llamada Seleccionar imagen ESXi, pulsaremos el botón Examinar...
situado en el centro de la ventana.
Seleccionaremos la imagen que hemos descargado de la página oficial de VMware en los pasos
anteriores, y pulsaremos el botón Abrir.
Una vez tengamos seleccionada la imagen del sistema operativo al que queremos actualizar nuestro
servidor host, presionaremos el botón Siguiente, situado en la parte inferior derecha de la ventana.
Nos aparecerá una nueva ventana emergente con la típica advertencia de seguridad del certificado de
nuestro servidor de virtual center.
Un certificado SSL que no es de confianza está instalado en “vCenter” y no se puede garantizar
la comunicación segura. En función de su directiva de seguridad, es posible que este problema

no suponga una preocupación relativa a la seguridad. Es posible que necesite instalar un
certificado SSL de confianza en el servidor para evitar que aparezca esta advertencia.
El certificado recibido desde “vCenter” se emitió para “VMware default certificate”. No se

puede garantizar la comunicación segura con “vCenter”. Asegúrese de que el nombre de
dominio completo en el certificado coincida con la dirección del servidor al que está intentando
conectarse.
Pulsaremos el botón Omitir, y esperaremos pacientemente a que la totalidad de la imagen, haya

subido a nuestro servidor.
Una vez terminado el proceso de carga de la imagen ISO de la nueva versión de VMware ESXi, en
nuestro laboratorio se trata de la versión 6.0 Update 2, avanzaremos en el asistente presionando
nuevamente el botón Siguiente.
La siguiente sección del asistente será Nombre de la línea base, donde procederemos a crear una
nueva línea base. Asignaremos un nombre para poder identificar la nueva línea base en los pasos
posteriores del proceso de actualización y si queremos también nos permitirá introducir una breve
descripción.
Hecho esto, terminaremos el asistente presionando el botón Finalizar.
Terminado el asistente, comprobaremos que tenemos disponible la nueva imagen del sistema operativo
al que queremos actualizar nuestro servidor host en la sección de Imágenes ESXi importadas de
nuestro VMware Sphere Update Manager.
Una vez tengamos importado nuestro nuevo soporte destinado a la actualización en la consola de
VMware Sphere Update Manager, procederemos a actualizar o corregir nuestro servidor.
En nuestro ejemplo, tenemos instalado un servidor VMware ESXi 5.5.0 Build 1331820, y pretendemos
actualizar el sistema operativo a la versión VMware ESXi 6.0.0 Build 3620759.
Abriremos nuestro cliente de vSphere y estableceremos una conexión con nuestro servidor de virtual
center, una vez tengamos establecida la conexión, seleccionaremos el servidor host que queremos
actualizar.
Nos dirigiremos al menú superior de la división derecha de la ventana y accederemos nuevamente a

la sección Update Manager.
Seguidamente, asociaremos nuestra recién creada línea base usando el enlace llamado Asociar...
Nos aparecerá una nueva ventana emergente llamada Asociar línea base o grupo, en ella,
seleccionaremos la línea base que hemos creado en los pasos anteriores y presionaremos el botón
Aceptar.
La ventana llamada Asociar línea base o grupo se cerrará y nos devolverá a la ventana de Update
Manager donde podremos comprobar que todas nuestras selecciones han sido actualizadas, solo nos
faltará presionar el botón Corregir.
Aparecerá la ventana inicial del asistente para Corregir, en la sección Selección de correcciones
verificaremos que todas las selecciones que vienen configuradas por defecto, son correctas y se
adecuen a la actualización que deseamos aplicar.
Si todo es correcto, pulsaremos el botón Siguiente para pasar a la siguiente sección del asistente.
En la sección del Contrato de licencia de usuario final, solo tendremos que aceptar los términos y el
contrato de licencia y, nuevamente presionaremos en el botón Siguiente para continuar.
Seguidamente, nos aparecerá una advertencia, avisándonos que después de la actualización de

nuestro sistema operativo, no será posible la vuelta atrás a la versión origen.
En caso de una actualización de la versión ESXi 5.x a la versión ESXi 6.x, terminado el proceso de
actualización no podremos revertir los cambios realizados a la instancia anterior de la versión ESXi
5.x.
Si quisiéramos omitir las advertencias sobre dispositivos de hardware no compatibles y almacenes

de datos de VMFS que ya no se admiten, activaremos el cuadro selector situado en la parte inferior
de la ventana. Debemos tener en cuenta las implicaciones que supone omitir estas advertencias.
En ciertas ocasiones, al omitir las advertencias sobre dispositivos de hardware no compatibles

y almacenes de datos de VMFS que ya no se admiten, podríamos crear entornos de instables o
directamente desembocar ante la imposibilidad de arrancar el host que hemos actualizado.
Seleccionadas las opciones necesarias, presionaremos el botón Siguiente del asistente para continuar.
La siguiente sección será la denominada Programar, donde podremos especificar en qué momento
exacto es cuando queremos actualizar nuestro servidor host.
En nuestro laboratorio, especificaremos que queremos lanzar el proceso de actualización

Inmediatamente. Hecho esto, pulsaremos el botón Siguiente para pasar a la próxima sección del
asistente.
Antes de proceder a la corrección de los servidores host, los ESXi deberán entrar en modo
mantenimiento y todas las máquinas virtuales que dependan del servidor host afectado, deberán ser
movidos o apagados.
En la sección Opciones de corrección de hosts podremos elegir como deben actuar los servidores
host con las máquinas virtuales que hospeden, en el momento que tengan que entrar en el modo de
mantenimiento.
Nos permitirá elegir las opciones de energía de cada una las máquinas virtuales que se encuentren
encendidas en el host objetivo de la actualización. Podemos elegir entre las opciones siguientes:
• Apagar máquinas virtuales.
• Suspender máquinas virtuales.
• No cambiar el estado de energía de la VM.
Por defecto, tendremos seleccionada la opción No cambiar el estado de energía de la VM, no

cambiaremos a ninguna otra de las opciones y presionaremos el botón Siguiente para continuar.
Teniendo seleccionada la opción No cambiar el estado de energía de la VM, en caso de que hayamos
olvidado de migrar alguna máquina virtual, el proceso se detendrá y esperará a que la migremos o la
apaguemos.
La siguiente sección será Opciones de corrección de hosts, en esta sección, hemos de tener
en cuenta que el host objetivo de la actualización no puede pertenecer a un clúster activo de High
Abailability, Distributed Power Manaement o Fault Tolerance. Por lo que deberemos sacar el
servidor físico del clúster del que depende, o marcar en esta sección las opciones necesarias para que
los servicios sean deshabilitados.
También podríamos configurar cuántos hosts se podrán actualizar de forma simultánea durante la
tarea de corrección. Pulsaremos el botón Siguiente para continuar.
En la sección Listo para finalizar, comprobaremos que todas las selecciones realizadas durante
el asistente son correctas y presionaremos el botón Finalizar para terminar el asistente y lanzar el
proceso de actualización.
La actualización pondrá nuestro host en modo mantenimiento sin problemas, ya que hemos movido
todas las máquinas virtuales con anterioridad. Solo tendremos que esperar a que todo el proceso
termine.
Si accedemos a la vista de la consola de nuestro host. Comprobaremos, que el proceso de Upgrade

avanza sin problemas, al término de la actualización, nos advertirá que es necesario actualizar también
las licencias de nuestro servidor host para equipararlas a la nueva versión del producto, presionaremos
la tecla Enter de nuestro teclado para reiniciar el servidor.
Solo deberemos esperar a que arranque nuestro servidor host, para poder comprobar que todo está
en orden y correctamente configurado.
VMware Sphere Update Manager: Actualizar Host ESXi - Parte 1
https://www.pantallazos.es/2016/06/actualizar-host-esxi-Update-Manager-parte1.html
VMware Sphere Update Manager: Actualizar Host ESXi - Parte 2
https://www.pantallazos.es/2016/06/actualizar-host-esxi-Update-Manager-parte2.html
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 4
Redes en vSphere
Capítulo 4 - Redes en vSphere Miguel Ángel Alonso
Introducción
Uno de los aspectos clave en un centro de datos es sin lugar a dudas las redes y comunicaciones que
hacen posible que nuestras aplicaciones y sistemas puedan operar entre ellos ofreciéndonos un sinfín
de posibilidades y servicios a nuestras empresas o clientes.
En este capítulo voy a daros los conceptos clave para conseguir poder realizar la interconexión a
nivel de redes de nuestras Máquinas Virtuales (VMs) o contenedores (Dockers) entre ellos bajo
redes internas LAN (Local área Network) o hacia red de área extensa WAN (Wide área Network) e
Internet dentro del mundo de VMware vSphere.
Partiremos de un pequeño repaso y breve resumen con el que pretendo darte una ligera introducción
al concepto de networking informático, seguiremos con la información detallada y en profundidad pero
muy clara de los diferentes dispositivos que vSphere nos da para poder comunicar nos a través de
la red LAN o Internet y finalmente como colofón del capítulo os daré nociones muy interesantes de
como abordar un diseño generalista de una empresa (tipo) con un caso simulado para dar un enfoque
más práctico con lo que tendremos una visión muy completa desde el principio hasta el final de como
las redes deben de ser estructuradas e integradas en una infraestructura de VMware vSphere para
el correcto funcionamiento de nuestras Máquinas Virtuales o contenedores.
1. Networking (Redes y su concepto)
A grandes rasgos y después de buscar por internet para intentar conseguir encontrar el concepto
más claro posible se podría decir que bajo el nombre de Networking identificamos las soluciones
de electrónica de red que se encargan de aportar a la red de datos corporativa la calidad, control y
seguridad que precisan las comunicaciones de datos que circulan por ella.
El valor de una red de datos corporativa viene dado por el nivel de servicios que podemos ofrecer sobre
la misma con las máximas garantías de calidad. Las soluciones de networking son capaces de dar
respuesta a los requerimientos de estas aplicaciones de valor, en aspectos tales como conmutación,
acceso, ancho de banda, monitorización, redundancia… La electrónica de red es, por tanto, un elemento
importante en redes de datos tradicionales, pero totalmente crítico en redes de datos multiservicio. Su
diseño, implantación y mantenimiento pasan a ser, por tanto, fundamentales.
2. Dispositivos de red
Los equipos informáticos descritos necesitan de una determinada tecnología que forme la red en
cuestión. Según las necesidades se deben seleccionar los elementos adecuados para poder completar
el sistema. Por ejemplo, si queremos unir los equipos de una oficina entre ellos debemos conectarlos
por medio de un conmutador (Switch) si además hay uno o varios portátiles con tarjetas de red Wi-
Fi debemos conectar un punto de acceso inalámbrico para que recoja sus señales y pueda enviarles
las que les correspondan, a su vez el punto de acceso estará conectado al conmutador por un cable.
Si todos ellos deben disponer de acceso a Internet, se interconectarán por medio de un router, que
podría ser ADSL, ethernet sobre fibra óptica, etc.
Los elementos de la electrónica de red más habituales son:
Conmutador de red (Switch), Capa 2
Imagen de redestelematicas.com
Enrutador (Router) Capa 3
3. Protocolos de red
Existen diversos protocolos, estándares y modelos que determinan el funcionamiento general de las
redes. Destacan el modelo OSI y el TCP/IP. Cada modelo estructura el funcionamiento de una red de
manera distinta. El modelo OSI cuenta con siete capas muy definidas y con funciones diferenciadas; el
TCP/IP con cuatro capas diferenciadas pero que combinan las funciones existentes en las siete capas
del modelo OSI. Los protocolos están repartidos por las diferentes capas, pero no están definidos como
parte del modelo en sí sino como entidades diferentes de normativas internacionales, de modo que el
modelo OSI no puede ser considerado una arquitectura de red, y de hecho es sólo una abstracción
teórica.
Como podéis ver en la imagen de arriba podemos ver el modelo lógico de las siete capas del modelo
OSI para poder entenderlas mejor.
En los próximos apartados veremos como VMware ha conseguido mediante switches virtuales que
emulan a la perfección la mayoría de las funcionalidades de un Switch físico para poder trabajar en
capa 2 y conectar todas nuestras máquinas virtuales entre ellas y recibir o enviar tráfico hacia o desde
Internet.
4. Redes en vSphere
4.1 Switches Virtuales
VMware nos da una serie de dispositivos llamados switches virtuales que más adelante vamos a
clasificar en dos tipos claramente diferenciados, standard y distribuidos.
Los conmutadores (switches) virtuales proporcionan la conectividad entre las máquinas virtuales dentro
de un mismo host (ESXi) o entre hosts diferentes. Los conmutadores virtuales o switches también
admiten el acceso a la red de VMkernel para la gestión de los hosts, vSphere vMotion, iSCSI y NFS.
4.2 Componentes de un Switch Virtual
Un conmutador virtual tiene tres tipos de conexión (redes) específicos:
• Redes de máquinas virtuales (Virtual Machine Network). Estos serían equivalentes a las
conexión o tráficos de las máquinas virtuales entre ellas o hacia Internet. Exclusivamente tráfico
• Puerto VMkernel: para almacenamiento por IP, Migraciones en caliente de Vms con vSphere
vMotion, tolerancia a fallos (Fault Tolerance) de VMware vSphere, vSAN, VMware vSphere®
Replication ™ y la red de administración ESXi o Management Network. En definitiva, tráfico de
VMware para características específicas como las ya mencionadas en estas líneas.
• Puertos de enlace ascendente o UPLINKs los cuales son una representación de las NIC físicas
de nuestros hosts ESXi que son los que conectan con nuestra circuitería externa de red (Física).
imagen de blog.aodbc.es
Diferentes tipos de redes pueden coexistir bajo el mismo Switch o pueden hacerlo separándolas entre
diferentes switches tal y como os muestro en el gráfico de abajo.
Imagen de VMware
Aquí debería de decir que, de cara al diseño, mientras la opción de arriba no necesita tener tantos
uplinks físicos, pero si puede adolecer de un ancho de banda más limitado respecto a la opción de
abajo. Eso sí, la opción de abajo nos va a consumir muchos más UPLINKs (NIC físicas) por host
teniendo en cuenta que VMware da soporte a un máximo de 12 NIC por ESXi no deberemos de
rebasar nunca este número para así cumplir con las mejores prácticas de rendimiento y gestión del
hipervisor (ESXi).
En la siguiente imagen puedes ver cómo se ven los switches virtuales de vSphere representados
desde la consola de gestión de VMware WebClient (Flash) el cual va a desaparecer en vSphere 7.0 o
vSphere Client (HTML5) que será la consola que se quede con nosotros definitivamente.
5. VLANs (802.1Q)
Como no podía ser de otra manera el uso de etiquetado con VLANs es casi una necesidad imperiosa
para la segmentación del tráfico de todas las redes que llegan a nuestro entorno virtualizado de VMware
y sus hipervisores, por ende VMware nos facilita este etiquetado y segmentación de la red con la cual
vamos a añadir una capa de seguridad adicional a nuestro entorno de networking, eliminación de una
gran parte del tráfico broadcast y finalmente la eliminación de la necesidad de usar una NIC por
tráfico para segmentar (una idea inviable en la mayoría de los casos).
Como puedes ver una VLAN es casi un mecanismo imprescindible y más en entornos virtualizados
donde un gran número de redes conviven en los hosts de VMware (ESXi).
5.1 Tipos de VLAN Tagging en vSphere
VMware nos da 3 tipos de etiquetado para trabajar con las VLAN.
• Virtual switch tagging (VST): este es el modo de etiquetado más utilizado en infraestructuras
VMware, nuestros switches virtuales se encargan de hacer el etiquetado de los paquetes. Nosotros
definimos portgroups (redes o tráficos) para nuestras máquinas virtuales y definimos un tag de
vlan para cada uno de ellos, solo es cuestión de conectar nuestras VMs a los portgroups indicados
según las vlans que requieran cada uno de ellos.
• External switch tagging (EST): el etiquetado de los paquetes se realiza una vez que llega al
puerto del switch físico.
• Virtual machine guest tagging (VGT): el etiquetado de los paquetes con el número de VLAN es
realizado por el sistema operativo, con esto logramos quitar la limitación que tenemos en cuanto a
número de VLANs. Tenemos que tener en cuenta el hecho de un mayor consumo de CPU debido a
el etiquetado de paquetes dentro del sistema operativo del cliente. Por defecto solo las VMXNET3
están preparadas para ello. E1000 y E1000e pueden trabajar añadiendo el software de Intel dentro
del sistema operativo para poder etiquetar en el adaptador virtual de la VM.
Esta opción es muy utilizada cuando hay software para esnifar tráfico (SNIFFER) y hacer debbuging
de este. Ej: Wireshark
5.2 Cómo configurar las VLAN en vSphere
Para terminar finalmente con las VLAN hay que tener en cuenta 2 cosas fundamentales:
• Deberemos de configurar en nuestros switches físicos todas las VLANs que queremos ver desde
nuestro entorno virtual. Debemos tener en cuenta que las VLANs son finitas y son etiquetadas
desde el 0 a la 4094 inclusive, lo que hace un total de 4095 posibles VLAN. La VLAN 0 está por
defecto en todos los portgroups y significa que no hay VLAN etiquetada.
• Poner los puertos físicos de nuestros switches en modo TRUNK para que estas (VLAN) sean
vistas desde cualquier NIC de los ESXi y así poder etiquetarlas dentro nuestros switches virtuales
o máquinas virtuales si así lo estimamos oportuno.
Ejemplo de etiquetado de la VLAN 154 en el portgroup llamado Test (VLAN)
6. Tipos de switches virtuales en VMware
Una red virtual admite los siguientes tipos de switches virtuales:
• Switch estándar:
La configuración del Switch virtual se realiza única y exclusivamente a nivel de un solo host (ESXi).
Con lo que hay que crear todos los portgroups (tráficos), vlans y demás configuraciones de manera
repetida e individualizada de ESXi en ESXi.
• Switch distribuidos:
La configuración de un Switch virtual está configurado para un centro de datos completo. La

configuración se realiza a nivel de vCENTER y no de host.
Esquema Swich standard VS stwich distribuido
7. Políticas y configuración de un SWITCH en vSphere
Hay tres grandes políticas dentro de un Switch en VMware:
• Políticas de seguridad
• Políticas de conformación del tráfico (Traffic Shaping)
• Políticas de balanceo y alta disponibilidad (FailOver)
7.1 Políticas de seguridad
Modo promiscuo: Permite que un switch virtual o grupo de puertos reenvíe todo el tráfico
independientemente del destino.
MAC Address Change: Acepta o rechaza el tráfico entrante cuando el invitado (VM o appliance)
modifica la dirección MAC.
Forged Transmit: Acepta o rechaza el tráfico saliente cuando el invitado (VM o appliance) modifica la
dirección MAC.
Un ejemplo del uso de Forged Transmit o MAC Address Change puede ser el uso de ESXi Nested
o anidados para propósitos de laboratorios. Este tipo de ESXI es representado en formato de máquina
virtual y nunca deben ser usados para fines de producción ya que VMware no les da ningún soporte.
7.2 Políticas de configuración del tráfico (Traffic Shaping)
La configuración del tráfico (Traffic Shaping) de red es un mecanismo para limitar el consumo de una
máquina virtual del ancho de banda disponible.
• La configuración del tráfico está deshabilitada por defecto.
• En un Switch Standard, la configuración del tráfico controla solo el tráfico saliente, es decir, el
tráfico que viaja desde las máquinas virtuales al Switch virtual y hacia la red física.
• Los parámetros se aplican a cada NIC virtual de las VM en el Switch Standard.
Esta política se aplica a nivel de portgroup (red o tráfico) dentro de un Switch standard o distribuido.
Los 3 mecanismos que se usan para controlar el tráfico son:
• Average Bandwith (MEDIA)
• Peak Bandwith (Pico Máximo)
• Burst SIZE (Tamaño de la ráfaga)
Valores predefinidos por defecto en cada portgroup.
¡¡¡Ojo!!! Porque la modificación que se realice aquí afectará a todas las máquinas virtuales que estén
conectadas a dicho portgroup.
7.3 Políticas de balanceo y alta disponibilidad
Como puedes observar en esta última política podemos ver cuatro parámetros importantes que se
pueden configurar para ayudar en la mejor manera de ayudar al tráfico a fluir (balanceo) o recuperarse
en caso de problemas (FailOver)
7.4 Balanceo de Carga (Load Balancing)
Tenemos tres posibilidades de configuración para el balanceo del tráfico:
7.4.1 Route based on originating virtual port

Esta política está basada en el algoritmo de balanceo ROUND ROBIN donde se distribuyen las
peticiones entre las NIC físicas de los ESXi cada vez que una máquina virtual envía o recibe tráfico,
pero no necesariamente el ancho de banda.
7.4.2 Mac Hash

Esta política asocia el tráfico de una máquina virtual a la dirección MAC de una de las NIC físicas del
ESXi yendo por esta cada vez que haga peticiones. Su algoritmo es muy liviano, pero muy efectivo
en el ahorro de recursos liberando al kernel del ESXi de procesos laboriosos de balanceo del tráfico.
7.4.3 IP Hash
Esta última política tiene dos características que la diferencian y mucho de las anteriores. La primera
es que el tráfico de una máquina virtual puede ir o volver por más de una NIC física del ESXi con el más
que considerable aumento de rendimiento de las máquinas virtuales si estas son capaces de poder
usarlo. Y sí, cuando digo esto es porque no todas las máquinas virtuales disponen de aplicaciones
instaladas que sean capaces de enviar y recibir tráfico por más de un camino (NIC Física). Un ejemplo
claro de aplicación capaz de aprovechar esta política de balanceo es un servidor Web o de base de
datos.
La segunda característica que la hace diferente es que deberemos de realizar configuraciones extra en
los switches físicos activando tecnología de LAG (agregación de enlaces) tal y como pueda ser Cisco
Etherchannel para ponerte un ejemplo.
7.5 Detección de fallos de red (Network failure detection)
En esta configuración nos encontramos con las opciones Link Status Only y Beacon Probing las
cuales tienen como naturaleza de trabajo el poder detectar fallos, como desconexiones de cables
y errores de alimentación eléctrica del Switch físico en nuestra red física.
En el caso de Beacon Probing este envía y escucha sus propios paquetes de test en todas las NIC
físicas del equipo. En un UPLINK en Teaming, los paquetes se enviarán a través de cada NIC física.
• VMware recomienda tres o más NIC físicas en Teaming
• VMware no recomienda múltiples conexiones físicas de NIC al mismo Switch físico
Imagen de VMware
7.6 Notificación de Switches (Notify Switch)
El objetivo de esta configuración es el envío de frames (tramas) para asegurarse de que los switches
físicos en la red conozcan la ubicación de las máquinas virtuales. Un Switch físico realiza este
aprendizaje al observar cada trama entrante y tomar nota del campo denominado Dirección MAC de
origen. Basándose en esa información, los switches crean tablas con asignaciones entre las direcciones
MAC y el puerto del Switch donde se puede encontrar esta dirección.
Hay al menos tres ocasiones diferentes en las que el ESXi envía estos mensajes:
1. Cuando una máquina virtual sea encendida, el host ESXi se asegurará de que la red esté al tanto
de esta nueva máquina virtual y su dirección MAC, así como de su ubicación física (puerto del
switch).
2. Cuando vMotion mueva una Máquina Virtual a otro host, será muy importante notificar rápidamente
a la red física la nueva ubicación del servidor virtual.
3. Si una NIC física en el host pierde la conexión, pero tuvimos al menos dos VMNIC (NIC Físicas)
como UPLINKs en el vSwitch, todo el tráfico de las máquinas virtuales se “moverá” a la interfaz
restante. También en esta situación, el host ESXi debe informar muy rápidamente a la red del
nuevo UPLINK correcto para llegar a la VM.
Nota: Por defecto está habilitado y solo se recomienda deshabilitar lo en el caso de que haya
máquinas virtuales con NLB en modo Unicast. Esto se puede resolver dedicando dos NIC físicas
para las máquinas con NLB en Unicast para no afectar al resto de máquinas virtuales o dedicar
ESXi a este tipo de máquinas con NLB Unicast.
7.7 Failback
Donde tenemos 2 opciones claras:
Si o No (Yes or NO)
Si: El tráfico está fijado sobre una NIC física, pero si esta NIC cae el tráfico es redirigido a otra NIC
hasta que la predefinida se recupera de nuevo.
NO: a diferencia de la anterior el tráfico conmuta en caso de fallo, pero no hay NIC predefinida con lo
que el tráfico no volverá a la NIC anterior hasta que haya un nuevo caso de error.
8. Protocolos de descubrimiento
vSphere admite los siguientes protocolos de descubrimiento:
• Cisco Discovery Protocol (CDP)
• Link Layer Discovery Protocol (LLDP)
CDP está disponible para los Switches Standard de vSphere y distribuidos conectados a los switches
físicos de Cisco.
LLDP es un protocolo independiente del proveedor que está disponible solo para switches distribuidos.
8.1 Modos de operación de los protocolos de descubrimiento:
• Escucha (listen): Se recibe información de los switches físicos.
• Publicación (Advertise): la información se envía a los switches físicos.
• Ambos (Both): La información se envía y recibe desde y hacia los switches físicos.
9. Switches Distribuidos
La configuración de un Switch virtual está configurado para un centro de datos completo. La

configuración se realiza a nivel de vCENTER. y no a nivel de ESXi con lo cual todos los ESXi suscritos
a este switches son susceptibles de recibir los cambios de un único punto de manera mucho más
rápida y segura evitando tener que hacer cambios eternizados en entornos grandes con muchos ESXi.
Se pueden conectar hasta 2.000 hosts (al mismo switch distribuido (vSphere 6.7).
La configuración es consistente en todos los hosts adjuntos al switch.
Los hosts deben tener una licencia Enterprise Plus o pertenecer a un clúster vSAN.
Ambos tipos de switches son elásticos: los puertos se crean y eliminan automáticamente.
9.1 Funcionalidades Switch standard vs distribuido
Imagen de cloudpathsala.com
Como puedes cuando queremos tener funcionalidades avanzadas como PVLANs, NetFlow o Port
Mirroring entre otros deberemos de rascarnos el bolsillo e irnos a la licencia Enterprise Plus donde
podremos hacer uso de los switches distribuidos.
Además, en la tecnología VMware NSX (hipervisor de redes de VMware) en el que hablaremos en otro
capítulo necesita trabajar con switches distribuidos de manera obligatoria.
9.2 Funcionalidades TOP de un Switch distribuido
• PVLAN: Tecnología que permite una doble encapsulación dentro de una VLAN y que es muy
utilizada en las DMZ para proteger a las Máquinas Virtuales de ataques externos. Existen 3 tipos:
Promiscuas, Communites y Aisladas.
• NetFlow: Tecnología que permite redirigir el tráfico de uno o varios portgroup de un Switch
distribuido (dvs) a un servidor de NetFlow para recopilar información de como se está haciendo
uso de la red mediante gráficos de columnas o tipo tarta. Quien y qué está emitiendo o recibiendo
por esas redes.
• Port Mirroring: Tecnología que permite redirigir el tráfico (en tiempo real) a otra máquina virtual
o dispositivo con capacidad para esnifar ese tráfico y replicarlo pudiendo de esta manera como
ejemplo poder cortar y analizar un ataque.
• Política de balanceo NIC Load Base Teaming: esta política a diferencia de las políticas mostradas
durante el capítulo de Switch estándar (véase pagina 12) es la única que es capaz de equilibrar
la carga a nivel de ancho de banda por todos los puertos. Esta política actúa como el llenado
de una vasija y al llegar al 75% del ancho de banda de la NIC redirige las peticiones a otra NIC
realizando la misma acción de manera sucesiva. Como veis la gran diferencia con Route based
on originating virtual port es que no se balancean peticiones sino ancho de banda.
• NIOC (Netwotk I/O Control): Tecnología que nos va a permitir categorizar y priorizar los tráficos
de nuestra empresa basándonos en el SLA de nuestra empresa y cuando tengamos contención en
nuestra red dando prioridad a ciertos tráficos por encima de otros. Hay dos mecanismos que nos
permitirán realizar dichas acciones como son los SHARES (valor numérico) que se le puede dar a
un tráfico de nuestro entorno como pueda ser Virtual Machines, vMotion, Faul Tolerance, vSAN,
etc. Contra mayor sea ese valor mayor es la prioridad de acceso al tráfico y actuará como un policía
en caso de contención parando y dejando pasar ese tráfico para cumplir con el SLA determinado.
La otra opción de priorización o categorización del tráfico viene dada por dos mecanismos de calidad
de servicio como son QoS (tráfico en capa 2) o DSCP (tráfico en capa 3) el cual dentro de un tráfico
como el de máquinas virtuales podemos dar prioridad como ejemplo al video antes que, al audio,
etc.….
Además, podremos crear normas de marcaje, permitir o bloquear el tráfico basado en las etiquetas
(tags) de calidad de servicio.
10. Caso práctico
Una empresa desea crear un entorno virtualizado aprovechando todas las características principales
de redes de VMware tal y como es vMotion además de migrar todas sus redes incluyendo el acceso
al almacenamiento y a la vez cumpliendo con las mejores prácticas de VMware.
Esta empresa comprende las siguientes redes:
• Compras, Ventas y RRHH cada una segmentada por una VLAN (17,18 y 19 respectivamente) para
tener la mayor seguridad entre ellas.
• Además, al crear su nuevo entorno de virtualización han comprado una cabina iSCSI para albergar
todas sus máquinas virtuales.
• Y por supuesto quieren aprovechar las ventajas de la virtualización y poder migrar las máquinas
virtuales entre los ESXi sin parada de servicio.
Dado este escenario os mostraré los pasos esenciales para crear vuestro entorno de manera visual y
clara cumpliendo con todas las premisas anteriormente nombradas.
10.1 Primer paso (creación de redes de producción)
Lo primero que haremos es crear en cada uno de nuestros ESXi las mismas redes (muy importante)
ya que tecnologías como vMotion, Fault Tolerance o DRS necesitan encontrar en origen y destino de
la máquina virtual las mismas redes para su correcto funcionamiento.
Aquí podemos ver los 4 pasos necesarios para crear una nueva red.
Aquí elegiremos la opción marcada para crear tráfico de máquinas virtuales
En este paso seleccionamos sobre que switch deseamos crear la red de Compras (Switch0).
Y finalmente damos el nombre “Compras” y la VLAN “17”.
Repetiremos los mismos pasos anteriores para crearnos la red de Ventas y RRHH con sus respectivas
VLAN. Por supuesto esto deberá ser realizado en cada ESXi de nuestro entorno. Aunque la parte física
no se vea se deben de tener configuradas las VLANs en el o los switches físicos y activada la opción
TRUNK en los puertos físicos.
Ejemplo de Trunking por cada puerto del switch.
10.2 Segundo paso (creación de redes de almacenamiento)
En este paso os mostraré como crear las redes necesarias y sus pasos para conectar a una cabina
iSCSI cumpliendo las mejores prácticas de VMware.
Seleccionamos la opción VMKernel para cualquier tráfico de VMware que no sea de máquina virtual.
En este caso tráfico iSCSI a cabina de almacenamiento.
Se le da un nombre descriptivo y no se marca ninguna opción ya que es tráfico iSCSI, esto valdría de
igual manera para NFS o FCoE.
Se le da un direccionamiento IP que esté dentro del rango de la cabina iSCSI
Finalmente os muestro 2 VMKernel iSCSI y dos NIC Físicas para conseguir tener alta disponibilidad y
balanceo de tráfico hasta la cabina de almacenamiento. Todo esto que da más detallado en el capítulo
de almacenamiento de VMware.
10.3 Tercer paso (creación de las redes de vMotion)
Seleccionamos VMKernel desde Añadir red (Add Networking) ya que es tráfico de VMware y no de
máquina virtual la red de vMotion.
Le damos un nombre descriptivo y marcamos la opción de vMotion para que esta red sea utilizada para
la migración en caliente de máquinas virtuales de ESXi a ESXi.
Una IP y mascara de una red que se vea de manera interna entre todos los ESXi. Una red privada y
aislada de las demás.
Y finalmente así quedará la red de vMotion que deberemos crear en cada ESXi dando una IP del
mismo rango como pudiera ser la 192.168.40.102 para el ESXi02 y así sucesivamente.
Llegados a este punto deberíamos tener una red funcional y preparada para poner en marcha nuestro
entorno de virtualización cubriendo el almacenamiento de nuestras máquinas virtuales, su tráfico LAN
e Internet y la migración en caliente entre hosts (ESXi).
En el siguiente capítulo y siguiendo con el mundo de las redes en VMware pasaremos a ver VMware
NSX (hipervisor de redes) con el cual se lleva al mundo de redes virtuales a otro nivel superior y que
os mostraré de la menara más sencilla de entender.
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 5
NSX
Capítulo 5 - NSX Miguel Ángel Alonso
Introducción
En este capítulo voy a daros los conceptos clave para conseguir poder realizar la interconexión a nivel
de redes de nuestras Máquinas Virtuales (VMs) dentro de un entorno de vSphere con NSX y además
os mostraré durante todo este capítulo cómo empezar a trabajar con NSX con un paso a paso de todos
sus componentes y defiendo cómo funcionan y su orden de instalación. Esta solución de VMware tiene
una gran inclinación por su naturaleza a trabajar con entornos Multi-tenant (multiples propietarios)
como son los entornos de Cloud Computing y más en particular en Iaas (Infraestructura como servicio)
ofreciendo una solución de auto aprovisionamiento para los usuarios finales en la nube combinándola
con vCloud Director; otras soluciones como vSphere y vRealize Automation se integran también de
manera ideal con NSX.
Partiremos de un pequeño repaso y breve resumen con el que pretendo darte una ligera introducción
al concepto de hipervisor de redes, seguiremos con la información detallada y en profundidad pero
muy clara de los diferentes dispositivos que NSX nos da para poder comunicar nos a través de la red
LAN o Internet y finalmente como colofón del capítulo os daré nociones muy interesantes de cómo
abordar un diseño generalista de una empresa (tipo) con un caso simulado para dar un enfoque más
práctico con lo que tendremos una visión muy completa desde el principio hasta el final de como
las redes deben de ser estructuradas e integradas en una infraestructura de VMware NSX para el
correcto funcionamiento de nuestras Máquinas Virtuales.
1. ¿Qué es NSX-V?
NSX es una plataforma de virtualización de red que le permite implementar una amplia gama de
servicios lógicos de red.
Imagen de VMware
Esta solución está integrada dentro de la solución SDDC de VMware (Centro de datos definido por
software) donde la creación de las redes se realizará por software creando switches (vxlan) como
switches distribuidos y routers como máquinas virtuales y que permitirá la creación de switching,
routing y firewalling con micro-segmentación para separar cada uno de nuestros entornos por
clientes o secciones dando salida hacia o desde internet e interconexión entre ellas sin necesidad de
dedicar hardware específico por cada cliente como pudiera ser un Router, Switch, balanceador, etc….
Y además, todo manejado desde una única consola e integrado con las soluciones más importantes
de creación de máquinas virtuales como son VMware vSphere y vCloud Director. También se integra
perfectamente con la solución de automatización vRealize Automation Center para de manera
programática crear entornos de NSX con diferentes hipervisores y sus redes integradas en minutos u
horas y listos para trabajar en producción.
2. ¿Cómo trabaja NSX-V?
Trabaja aprovechando el hardware que existe dentro de nuestros centros de datos. Los hosts ESXi, los
switches virtuales y los switches distribuidos se ejecutan en el hardware.
VMware NSX gestiona los datos en todos los switches virtuales:
Imagen de VMware
3. Funciones principales de VMware NSX-V
• Conmutación lógica: Nivel 2 sobre nivel 3, desvinculada de la red física.
• Enrutamiento lógico: Enrutamiento entre redes virtuales sin abandonar el host.
• Cortafuegos lógico: Cortafuegos distribuido, kernel integrado y un alto rendimiento (20 GBps de
backplane de comunicación entre los ESXi)
• Balanceador de carga lógico: Balanceo de carga de las aplicaciones por medio de software.
• Red privada virtual (VPN) lógica: VPN para el acceso remoto y de sitio a sitio por medio de
software. VPN Ipsec, L2VPN y VPN SSL.
• VMware NSX API: API basada en REST que puede integrarse en cualquier plataforma de gestión
de la cloud.
• Ecosistema de partners (Integración con los partners de seguridad y networking más importante
del mercado) TrendMicro, Bitdefender, Kaspersky, F5, Palo Alto, etc….
4. Instalación y requisitos de VMware NSX-V
4.1 Requisitos relativos al sistema de gestión y al navegador:
• Un navegador web compatible:
• Internet Explorer.
• Mozilla Firefox.
• Google Chrome.
• vSphere Web Client.
• Tener activadas las cookies en el navegador utilizado para las tareas de gestión.
4.2 Requisitos del entorno:
• Configuración de DNS correcta para los hosts ESXi añadidos por nombre.
• Permisos de usuario para añadir y encender máquinas virtuales.
• Permisos para añadir archivos al datastore de las máquinas virtuales.
Hay varios elementos necesarios para hacer funcionar NSX pero hay un elemento principal desde el
cual además se debe empezar la integración. Se ofrece en formato de Appliance virtual (OVA) y su
nombre es NSX Manager.
Su gestión se realiza vía WEB:
En este ejemplo puede verse el apartado de integración con vSphere para poder gestionar todo el
entorno de NSX-V finalmente desde el cliente WEB de vCenter.
Plugin de NSX-V registrado en el cliente WEB de Flash aunque trabaja también perfectamente con el
cliente HTML5 desde la versión 6.7 Update 1 de vSphere o 6.5 U2 tal y como puedes observar en
la siguiente imagen.
5. Protocolo y funcionamiento de Transporte de NSX-V
5.1 ¿Qué es VXLAN y VTEP y cómo funcionan?
Imagen de VMware
Un Virtual Tunnel End Point (VTEP) es una entidad que encapsula una trama Ethernet en una trama
de VXLAN, o que des encapsula una trama VXLAN y reenvía la trama Ethernet interna. Este viene
representado como un VMkernel en el Switch Distribuido y abarca a todos los ESXi que tengamos
dentro de los cluster de las Zonas de Transporte.
Un proxy VTEP es un VTEP que reenvía el tráfico de VXLAN a su segmento local recibido desde otro
VTEP situado en un segmento remoto.
Una zona de transporte define los miembros o los VTEP de la red overlay VXLAN:
• Puede incluir hosts ESXi de diferentes cluster de VMware vSphere.
• Un cluster puede formar parte de múltiples zonas de transporte.
Un identificador de red de VXLAN (VNI) es un número de 24 bits que se añade a la trama de VXLAN:
• El VNI identifica de forma única el segmento al que pertenece la trama Ethernet interna actuando
de una manera muy parecida a como lo haría una VLAN.
• En una misma zona de transporte pueden existir varios VNI.
• VMware NSX for vSphere empieza por el VNI 5000.
5.2 Modos de replicación de VXLAN en NSX for vSphere
Existen tres modos de replicación del tráfico: dos de ellos se basan en VMware NSX Controller,
mientras que el tercero se basa en el plano de datos.
• El modo unicast lleva a cabo la replicación completa por medio de unicast.
• El modo híbrido consiste en una replicación local gracias a la red física, y en una replicación
remota por medio de unicast.
• El modo de multicast requiere IGMP para una topología de capa 2 y enrutamiento de multicast
para una topología de capa 3.
Todos los modos requieren, como mínimo, una MTU de 1600 bytes.
5.3 Replicación VXLAN (Plano de Control)
En los modos de unicast e híbrido, la instancia de NSX Controller selecciona un VTEP en cada uno
de los segmentos remotos de su tabla de asignación de VTEP como proxy. Esta selección se realiza
por VNI (equilibra la carga entre los VTEP que actúan como proxy).
• En el modo unicast, este proxy se denomina Unicast Tunnel End Point (UTEP).
• En el modo híbrido, este proxy se denomina Multicast Tunnel End Point (MTEP).
• Esta lista de proxies UTEP o MTEP se sincroniza con todos los VTEP.
Si un UTEP o un MTEP abandona un VNI, la instancia de NSX Controller selecciona un nuevo proxy
en el segmento y actualiza los VTEP participantes:
• Informe de VTEP
• Fallo de VTEP
Dibujo de los VTEP XYZ en cada cluster para el trasporte de las VXLAN y sus encapsulado y
desencapsulado.
6. Planos de trabajo de NSX-V
Imagen de VMware
• Plano de Gestión: Único punto de configuración y API basada en REST e interfaz de usuario.
Plano de control: Gestiona las redes lógicas, estado de tiempo de ejecución, no forma parte de la
ruta de datos y es por supuesto el protocolo del plano de control.
• Plano de datos: NSX Virtual Switch, Edge de red distribuida (DLR) tráfico este-oeste,
rendimiento de velocidad de línea, NSX Edge Gateway, Plano de datos para el tráfico norte-sur
(Internet o WAN), Enrutamiento, servicios avanzados y finalmente la Seguridad del Switch.
7. Elementos principales de NSX-V
7.1 NSX Manager (Plano de Gestión):
Principal elemento de configuración en NSX-V el cual nos proporciona:
• Proporciona la IU (interfaz de usuario) de gestión y NSX API.
• Instala el User World Agent, la VXLAN, el enrutamiento distribuido y los módulos del kernel del
cortafuegos distribuido.
• Configura los hosts a través de un bus de mensajes.
• Genera certificados para garantizar las comunicaciones del plano de control.
• Configura el cluster de NSX Controller a través de una API basada en REST.
7.2 NSX Controller (Plano de Control):
• Distribución de VXLAN e información sobre la red de enrutamiento lógico a los hosts ESXi. Info de
las tablas de MAC, ARP y VTEP (esta última es del encapsulado de VXLAN)
• Agrupación en clusters para ofrecer escalabilidad horizontal y alta disponibilidad.
• Distribución de la carga de trabajo dentro de un cluster de NSX Controller.
• Eliminación de la dependencia del enrutamiento de multicast y de PIM en la red física.
• Supresión del tráfico broadcast de ARP en las redes VXLAN.
Los nodos de NSX Controller se implementan como máquinas virtuales.
Cada máquina virtual consume 4 vCPU y 4 GB de RAM.
Se recomienda utilizar un cluster de NSX Controller con tres nodos para disponer de HA (protocolo
Paxos)
Los hosts ESXi y las máquinas virtuales obtienen del router lógico (VM) de NSX-V la información de
la red y la envían al NSX Controller a través del User World Agent (UWA).
Imagen de VMware
7.3 UWA User World Agent (Plano de Control):
El User World Agent tiene las siguientes características:
• Se ejecuta como un demonio de servicios denominado netcpa.
• Utiliza SSL para comunicarse con NSX Controller en el plano de control.
• Ejerce como mediador entre NSX Controller y los módulos del kernel del hipervisor, excepto el
cortafuegos distribuido.
• Recupera información de NSX Manager a través del Message Bus Agent.
Los módulos del kernel del cortafuegos distribuido se comunican directamente con NSX
Manager a través del demonio de servicios vsfwd.
8. Orden de instalación de VMware NSX-V
Imagen de VMware
8.1 Instalando NSX Manager
Descargamos la OVA de NSX Manager desde VMware y la implementamos en vSphere.
8.2 Configurando NSX Manager
Apuntando a la IP o FQDN de NSX Manager con nuestro navegador y por https con el usuario admin
y el password introducido durante la importación de la appliance entraremos en la parte del registro
con vCenter para gestionar NSX desde el cliente WEB mediante un plugin.
8.3 Gestión de NSX desde vSphere (WebClient)
8.3.1 Instalación de los Controllers

Una vez registrado y desde el cliente web de Flash o HTML5 si estamos en versiones 6.5 Ux o 6.7
Ux podremos empezar a configurar la creación de los Controllers. En un entorno de producción el
número ideal para montar un cluster de Controllers son tres y no más.
8.3.2 Instalación de los módulos de kernel de NSX (Switching, Routing y Firewall)

Una vez tenemos los controllers corriendo y en verde (OK) el siguiente paso es instalar los paquetes
de firewall, switching y routing en cada ESXi de nuestro/s cluster/s desde la pestaña Host Preparation.
Desde aquí se instalarán los paquetes en los ESXi y se le dará un Pool de IPs para que NSX cree los
VTEP en cada uno de los ESXI.
8.3.3 Creación del rango de VNI para las VXLAN

En este paso vamos a dar un rango de identificadores (VNI) para ser consumidos por las VXLAN los
cuales actúan como los números o identificadores de una VLAN.
En la captura puede verse un rango de IP MULTICAST que solo son necesarios si se va a implementar
vCloud Director.
vSphere trabajará en modo UNICAST si se usa con NSX para segmentar las redes o crear Zonas de
Transporte.
8.3.4 Creación de las Zonas de Transporte

Este es último y definitivo paso para la instalación total de NSX y poder trabajar con este en nuestro
entorno. Se trata de la creación de la zona o zonas de transporte que queremos dentro de nuestro
entorno. La zona mínima debe corresponder a un solo Cluster. Se puede abracar más de un cluster
para crear diferentes zonas de transporte y luego utilizarlas en función de cómo deseemos que nuestras
redes abarquen el entorno del que disponemos.
9. Preparando una Red y su Routing (Switch y Router

Lógicos)
En los siguientes pasos y tras terminar el apartado de instalación, preparación y actualizaciones de

NSX pasamos a crear Switches lógicos (VXLANs) y Edges (Routers).
Recuerda que en NSX siempre la instalación empieza de arriba abajo y de izquierda a derecha desde
el Dashboard de NSX para resultar lo más intuitivo y fácil posible durante su integración.
9.1 Logical Switches

Aquí se configuran las redes (VXLANs) que actúan como segmentos de una VLAN para conectar
nuestras máquina virtuales.
Estos son los pasos para crear un switch lógico o los que necesitemos para finalmente conectarlos a
un router si se necesita enrutar el tráfico de los switches lógicos.
Estos se ven representados como un switch distribuido dentro de nuestro entorno de vSphere
9.2 NSX Edges (Routing)
Dividos en dos clases de router bien diferenciadas.
ESG (Edge Services Gateway) como tráfico Norte-Sur (hacia o desde internet).
DLR (Distributed Logical Router) como routers tráfico Este-Oeste.
En las siguientes imágenes voy a mostraros el paso a paso de la creación de un router. En este
ejemplo será un DLR al cual le conectaré el switch lógico creado anteriormente y llamado Compras.
Aquí se le da un nombre descriptivo y se decide sobre la posibilidad de poner en Alta disponibilidad el

router DLR. Esta opción duplicaría el router en un modo activo-pasivo para soportar la caída del DLR
principal.
En este paso introduciremos el password del usuario admin para poder gestionar por el SHELL o SSH
el router DLR.
Ejecutamos la opción dos de añadir un Edge Appliance VM y en la captura siguiente veréis los datos
necesarios para crear dic ha VM como representación del router.
Aquí se ven los datos necesarios donde crear el DLR con VM que se puede claramente en el paso 3
tal y como son el esxi, datastore, etc..
Elegimos la opción de añadir una red al router y darle un direccionamiento en formato CIDR y Gateway.
Aquí se puede ver la red 172.10.10.0/24 y su Gateway 172.10.10.1 para conectar las VMs de este
switch lógico a esta red y Gateway si queremos enrutar con otras patas del switch más adelante si es
necesario.
Finalmente nos pedirá el Gateway y la red sobre la que iré este Gateway para enrutar las patas que
vayamos añadiendo al router.
Finalmente, y una vez creado el DLR podemos entrar en este desde el panel de Edges en NSX
con doble click y configurar las opciones que os muestro en la captura de arriba. Con esto quedaría
montado nuestro primer router y switch lógico de nuestro quedando solo el hecho de conectar nuestras
máquinas virtuales en el switch lógico o segmento VXLAN.
Diagrama final de una infraestructura de Edges, DLR y Switches Lógicos
Imagen de lostdomain
10. ¿Qué es NSX-T y en qué casos debemos implementarlo?
NSX-T (Transformers) está diseñado para abordar muchos de los casos de uso para los que no se
diseñó NSX-V, como los multihipervisores. NSX-T es una pila SDN con reconocimiento de múltiples
hipervisores que se ha traído para vSphere, KVM, OpenStack, Kubernetes y Docker.
Está diseñado para abordar los marcos de aplicaciones emergentes y las arquitecturas que tienen
puntos de conexión heterogéneos entre los ya indicados. Uno de los principales casos de uso de
NSX-T es con contenedores. En la virtualización actual, estamos viendo que más y más aplicaciones
se ejecutan en entornos fuera de las máquinas virtuales.
También es importante considerar la compatibilidad con múltiples hipervisores el hecho de que NSX-T
se ha desacoplado de VMware vCenter Server. NSX-T es una solución independiente para entornos
con vCenter y vSphere, pero también puede admitir KVM, nube pública, contenedores (DOCKERS)
y también se puede integrar con soluciones como Red Hat OpenShift, Pivotal y otros.
Uno de los principales cambios en el enfoque que verás al comparar los dos productos es que NSX-T
está más centrado en dar funcionalidades en busca de dar servicios de red en la nube.
También permite a las organizaciones más flexibilidad en la elección de la solución que mejor se
adapte a su caso de uso, ya sea que incluya hipervisores, contenedores, bare-metal y nubes públicas.
VMware NSX-T se integra con la plataforma VMware Photon , que es el sistema operativo propietario
de VMware y que desarrolló desde cero desde el cual soluciones como vCenter o los NSX-Controller
de NSX-V llevan integrados como S.O.
NSX-T también contiene el complemento de interfaz de red de contenedores (CNI) de NSX-T que
permitirá a los desarrolladores configurar la conectividad de red para las aplicaciones de contenedores
(Dockers) y que nos ayudarán a entregar la infraestructura como un servicio.
10.1 Cambios en la arquitectura
Curiosamente, con NSX-T VMware ha pasado de la encapsulación basada en VXLAN que es utilizada
por NSX-V, y ha adoptado la nueva encapsulación “Geneve”. Esta diferencia en arquitectura hace que
NSX-T y NSX-V sean incompatibles en este momento.
¿Cuál es la posición del modo de Encapsulación estándar de GENEVE en contraposición a VXLAN

cuando especialmente hay una gran cantidad de dispositivos de hardware en el mercado que soportan
VXLAN?
Geneve es una encapsulación recién acuñada Co-escrita por VMware, Microsoft, Red Hat e Intel.
Geneve combina lo mejor de los protocolos de encapsulación actuales como VXLAN, STT y NVGRE
en un único protocolo. Mucho se ha aprendido de los protocolos de virtualización de red actuales y
como NSX ha madurado, la necesidad de ir más lejos con el protocolo de encapsulación extensible
ha salido a la luz. Geneve permite insertar metadatos como campos TLV que se pueden utilizar para
nuevas funciones según sea necesario.
Otros cambios en la arquitectura de NSX-T a tener en cuenta:
• Los controladores NSX-T Manager y NSX-T se pueden implementar como máquinas virtuales en
ESXi o KVM
• No es estrictamente necesario el uso de vCenter
• Hay un nuevo (hostswitch) que se utiliza para el soporte de multi-hypervisores. Esta es una
variante de VMware vSwitch y Open Virtual Switch para KVM
• Utiliza la encapsulación de Geneve, el MTU de 1600 todavía se recomienda para el encabezado

de encapsulación
• Cambios de enrutamiento: NSX-T utiliza el enrutamiento optimizado de última generación que está
basado en varios niveles con separación lógica entre el enrutador del proveedor (Tier0 router) y la
función de enrutador del Tenant (TIER1 router)
• Interfaz estándar de HTML5 para configuración y gestión
10.2 En resumen
VMware NSX está evolucionando sin duda, especialmente con la introducción de VMware NSX-T.
VMware está demostrando su compromiso con la plataforma de NSX que se mueve más allá de los
entornos de vSphere e incluye KVM, OpenStack y varias nubes públicas. Este desacoplamiento
de vSphere ciertamente atraerá a otros a la siempre popular plataforma de virtualización de red de
VMware.
11. ¿Cómo monitorizar NSX?
11.1 vRealize Operations Management Pack para NSX para vSphere
Amplía la monitorización de contenido en las áreas del centro de datos virtual (VDC) y Redes.
Este paquete para vROPS (vRealize Operations Manager) es una herramienta extraordinaria para la
monitorización de nuestro entorno basado en NSX y nos ofrece como más destacadas las siguientes
características:
• Visibilidad de todos los servicios de red de NSX implementados en cada clúster de vSphere,
incluido NSX Manager, Los Controllers de NSX y los servicios del plano de datos de NSX, como
son el switch lógico, routers (Edge o DLR), firewalls, etc. Se utilizan varios widgets predefinidos
para representar los servicios de NSX.
• Visibilidad de los hosts de vSphere en las zonas de transporte de NSX, en o entre varios clústeres
de vSphere, para ver el la movilidad y los intervalos de enrutamiento.
• Busca y navega por las funciones para obtener el estado de las operaciones de los objetos de NSX
implementados.
• Búsqueda del origen de las dependencias y relaciones entre las redes lógicas y físicas para alertar
de problemas y su resolución buscando su causa raíz. Esta característica incluye la detección y
alerta de la configuración de NSX, conectividad y problemas de salud (Health). Todas las alertas se
consolidan en la interfaz de alertas de un vRealize Operations (vROPs).
• Actúa como una extensión del motor de análisis y riesgos de vRealize Operations con la inclusión
de indicadores clave de rendimiento y salud en los objetos de VMware NSX.
• Nos da la posibilidad de dibujar topologías de red lógicas de extremo a extremo entre dos máquinas
virtuales seleccionadas. Los objetos de NSX ayudan a proporcionar visibilidad en la conectividad
lógica. Esta vista nos va a ayudar a aislar los problemas en la red lógica o física.
• Capacidades avanzadas de resolución de problemas, como comprobar la conectividad entre dos

VTEP (Virtual Tunnel End Point) ejecutando un ping entre dos hosts.
• Plantillas de informes para generar informes de los objetos de NSX for vSphere.
11.2 vRealize Network Insight (vRNI)
Es sin duda alguna mi herramienta favorita de monitorización de NSX, vRNI es un producto para la
entrega de operaciones inteligentes en un entorno de red definido por software SDN (especialmente
NSX). En resumen, es un vRealize Operations pero solo para entornos SDN. Con la ayuda de este
producto puedes optimizar el rendimiento y la disponibilidad de la red con visibilidad y análisis en redes
virtuales y físicas.
Proporciona planificación y recomendaciones para implementar la seguridad de la microsegmentación

en tu entorno dándote una visibilidad e idea muy concisas de como hacerlo, además de vistas operativas
para administrar y escalar rápidamente y con confianza la implementación de VMware NSX.
Video en español para conocer de primera mano las principales funcionalidades de la herramienta.
https://www.youtube.com/watch?v=D9tElYASNjU&feature=youtu.be
Llegados a este punto solo queda que con la orientación dada en este capítulo podamos afrontar sin
temor la implementación de la tecnología de NSX en nuestro entorno buscando un siguiente nivel
de networking y seguridad en nuetsros centro de datos para así estar a la altura de los nuevos retos
que nos van a venir en los próximos años y en un futuro que ya está aquí nada mas dar la vuelta a la
esquina.
Capítulo 6
Almacenamiento en vSphere
Capítulo 6 - Almacenamiento en vSphere Leandro Ariel Leonhardt
1. Introducción al almacenamiento
Los almacenes de datos, dicho también “datastores”, son contenedores lógicos que puede utilizar
espacio de disco de un dispositivo físico (cabina de disco - Storage) para poder almacenar máquinas
virtuales, ficheros, ISOs, etc. VMware ofrece varios mecanismos de protección y optimización a nivel
de VMFS (sistema de archivos de VMware), sin embargo, la configuración, el nivel de RAID y la
tecnología que usemos en el Storage, influye mucho en diseño y performance de la infraestructura.
VMware vSphere es compatible con cuatro tipos de sistemas de archivos: VMFS, NFS, vSAN y vSphere
Virtual Volumes.
1.1 Tipos de almacenamiento y tecnología
Dependiendo del tipo de almacenamiento y configuración, podemos crear LUNs con VMFS u optar
por un formato de sistema de archivos que se comparte mediante el protocolo NFS, en algunos casos,
ambos sistemas de archivos en un mismo entorno vSphere.
Los hosts ESXi del entorno vSphere son compatibles con varias tecnologías de almacenamiento:
• DAS: almacenamiento interno o externo conectado a los hosts mediante una conexión directa en
lugar de una conexión de red. El almacenamiento es presentado a los hosts ESXi como VMFS.
• Fibra: protocolo de transporte de alta velocidad que se utiliza para SAN. Un switch (core) interconecta
varios nodos ESXi con visibilidad al almacenamiento para crear la estructura de una red de fibra. El
almacenamiento es presentado a los hosts ESXi como VMFS y/o NFS.
• FCoE: el tráfico se encapsula sobre Ethernet (FCoE). Estas tramas FCoE convergen con otros
tipos de tráfico de la red Ethernet. El almacenamiento es presentado a los hosts ESXi como VMFS
y/o NFS.
• iSCSI: protocolo de transporte SCSI que permite el acceso a dispositivos de almacenamiento y

al cableado en redes TCP/IP estándar. El almacenamiento es presentado a los hosts ESXi como
VMFS.
• NAS: almacenamiento compartido en redes TCP/IP estándar a nivel del sistema de archivos.
El almacenamiento NAS se utiliza para montar datastores de tipo NFS. El almacenamiento es
presentado a los hosts ESXi como NFS.
1.2 Introducción a VMFS6
VMFS (Virtual Machine File System) es el sistema de archivos propietario de VMware que permite el
acceso simultáneo de múltiples nodos ESXi para leer y escribir de manera simultánea.
Puede ampliarse de manera dinámica, usa tamaño de bloques de 1 MB y 512 MB, adecuado para
almacenar archivos de discos virtuales grandes. Para archivos pequeños, el tamaño de bloque
secundario es de 8 KB.
VMFS es un sistema de archivo de clúster, lo que posibilita el uso de otras características de VMware
como:
• Migración de máquinas virtuales en caliente desde un host ESXi a otro sin tiempo de inactividad.
• Reinicio de máquinas virtuales (vSphere High Availability) en otros hosts ESXi si se produce un
fallo en el host.
• Clúster de máquinas virtuales corriendo en diferentes servidores físicos, etc.
Un volumen VMFS puede ampliarse dinámicamente sin interrupción y sin evacuación de datos
(máquinas virtuales, templates, iSO, etc). Este proceso tiene dos fases, ampliar el datastore desde la
propia cabina de disco y crecer el espacio en VMware (Increase) desde vSphere Web Client.
Para incrementar un volumen, nos dirigimos al datastore (previamente crecemos la LUN desde el
storage y hacemos un rescan de storage a nivel de clúster VMware) y en configure podemos observar
la capacidad total, el espacio aprovisionado y el espacio libre, en este ejemplo, pasaremos de tener 1
TB de capacidad a 1,5 TB:
Ahora seleccionamos la LUN (debemos de asegurarnos de que es la LUN que crecimos desde el
Storage, para ello podemos ver el WWN tanto desde el Storage como desde VMware):
Seguimos el asistente y observamos que el espacio disponible para crecer es de 512 GB:
Continuamos y verificamos que la información es correcta:
Al finalizar el asistente, podemos ver que el almacenamiento ha incrementado su capacidad y pasó de

disponer 1 TB a 1,5 TB:
Otra manera de ampliar, pero no recomendada, sería juntando dos o más datastores VMFS con
diferentes WWN (es el mismo asistente que acabamos de ver), se puede “concatenar” hasta 32
volúmenes, pero no es nada recomendado, un problema a nivel de almacenamiento sobre esos
volúmenes, podría provocar la pérdida de toda la información.
El volumen VMFS, también conocido como LUN (Logical Unit Number), no puede superar los 62 TB,
es decir, ampliando desde el almacenamiento o concatenando LUNs, no debe de superar los 62 TB
soportados por VMware.
Otra característica de VMFS es que proporciona bloqueo distribuido a nivel de bloque para garantizar
que una máquina virtual no se encienda en varios servidores a la vez. En caso de fallo en el servidor
ESXi, se libera el bloqueo para que pueda encenderse/reiniciarse en otro host.
1.3 Factores a tener en cuenta
Para lograr un buen rendimiento, debemos de considerar:
• Tamaño de la LUN: un datastore “grande” permite gestionar menos volúmenes VMFS, proporciona
más flexibilidad para crecer o ampliar los discos virtuales sin necesidad de expandir la LUN y más
flexibilidad para crear nuevas máquinas virtuales.
• Ancho de banda (HBA): tarjetas de red a 1 GB o 10 GB para tráfico iSCSI, o FC de 8/16 Gb o más.
• IOPS capaz de gestionar la cabina (dependerá de la cabina, tipo de discos, nivel de raid, cache, si
deduplica y comprime, etc).
• Zoning y Enmascaramiento (LUN MASK), usar una zonificación de un solo iniciador o una
zonificación de un solo iniciador y un solo target.
• Asignación de LUN para todos los hosts de un clúster, es decir, que todos los hosts de un clúster
vean la misma cantidad de datastores.
• Cabinas de discos activas-activas, o activas-pasivas (acceso a las controladores de manera

consecutiva o secuencial).
1.4 Compatibilidad con las tecnologías de VMware
Compatibilidad Compatibilidad Compatibilidad Compatibilidad Compatibilidad

Protocolo
con BFS con vMotion con HA con DRS con disco RAW
Fibra √ √ √ √ √
FCoE √ √ √ √ √
iSCSI √ √ √ √ √
NFS √ √ √
DAS * √ √
Virtual Volumes √ √ √
vSAN √ √ √
* Si la conexión DAS se realiza con almacenamiento externo, será compatible también con vMotion,
alta disponibilidad y DRS.
1.5 Creación de un volumen VMFS
Una vez que hayamos creado el volumen en la cabina de almacenamiento, o en caso de que sea
DAS, un disco local, nos posicionamos sobre host o clúster y con botón derecho —> Storage —> New
Datastore:
Elegimos un nombre para el datastore, una buena práctica es usar el mismo nombre que se estableció
en la cabina de disco.
Como se puede apreciar en la imagen, vemos que identificador (Name), el LUN ID (56), la capacidad
(100 GB), si soporta aceleración por hardware (VAAI) y el tipo de disco, Flash.
Elegimos la versión, VMFS 6 o VMFS 5, en este ejemplo, VMFS 6:
En la siguiente vista, sí utilizaremos los 100 GB, el tamaño de bloque y el Space Reclamation Priority
(nuevo en VMFS6), relacionado con la recuperación de bloques en los datastores creados como “thin
provisioning”.
1.6 Introducción a vSphere Storage APis Array Integration
Antes de terminar esta breve introducción a VMFS, me gustaría comentaros la funcionalidad del VAAI,
básicamente, el VAAI lo que hace es “descargar” cargas de trabajos de los ESXi (CPU, red, memoria,
etc), para que lo ejecutara directamente la propia cabina.
Para saber si tu almacenamiento soporta funcionalidades de VAAI, te puedes conectar a un host ESXi
y ejecutas: esxcli storage core device list.
Como puedes apreciar en esa imagen, VAAI Status está soportado, pero el VAAI tiene cuatro
características: ATS, Clone, Zero y Delete.
Para desglosar las funcionalidades del VAAI y averiguar si el almacenamiento con el que estamos
trabajando soporta esas 4 funcionalidades mencionadas, ejecutamos: esxcli storage core device vaai
status get.
Como puedes ver en ese ejemplo, el almacenamiento que sirve volúmenes a VMware soporta las
cuatro funcionalidades del VAAI:
ATS: todo lo referente al metadato del sistema de archivo, power on, power of de VMs, vMotion,
snapshots. etc.
Clone Status: Cuando se realiza “clones” desde VMware, clone de máquinas virtuales o despliegues
desde plantillas, en lugar de hacer el trabajo el kernel de ESXi, VMware le pasa los comandos APis a
la cabina y es la cabina quien realiza el proceso de clonado.
Zero Status: Para la creación de discos virtuales en thick, en lugar de procesar el hipervisor la creación
de discos thick, ESXi pasa las “instrucciones” APis a la cabina y es la cabina quien crea el disco en
thick, quitándole trabajo al ESXi y optimizando los recursos.
Delete Status: Aquí es cuando entra VMFS6 y le saca mayor partido, ya que en versión VMFS 5,
teníamos que ejecutar este proceso a mano o mediante un software de terceros. Si tenemos soportada
esta funcionalidad a nivel de VAAI y trabajamos con VMFS6, el autoreclaim de bloques que se liberan
desde los sistemas operativos, serán recuperados automáticamente para los volúmenes thin.
1.7 Algoritmos de Multipathing
Tal como he mencionado en “factores a tener en cuenta”, existen cabinas de discos que permiten el
acceso a sus controladores (SP) de forma Activo-Activo o Activo-Pasivo.
De nada nos valdría tener un almacenamiento Activo-Activo y que solo pudiéramos acceder a las
controladoras para el acceso a las LUN por un único HBA o adaptador.
VMware ofrece mecanismos nativos de selección de rutas, equilibrio de carga y de conmutación por
error.
Hay fabricantes que ofrecen sus propios algoritmos de balanceos, proporcionan un rendimiento y
detección de fallos diseñado específicamente para su almacenamiento.
La mayoría de los fabricantes no lo ofrecen, por que los mecanismos nativos de VMware son suficiente
y altamente eficientes para dotar de alta disponibilidad y rendimiento al entorno:
• Round Robin (RR): el host usa un algoritmo de selección de ruta que alterna entre todas las rutas
disponibles. Además de la conmutación por error, la política Round Robin permite el equilibrio de
carga entre las rutas (I/O) simultáneo.
• Fixed: el host siempre utiliza la ruta preferida al disco en caso de que esté disponible. Si el host no
puede acceder al disco mediante la ruta preferida, prueba las rutas alternativas. Esta política es la
predeterminada para los dispositivos de almacenamiento activo-activo.
• Most Recently Used (MRU): el host utiliza la última ruta al disco hasta que deja de estar disponible.
Es decir, el host no cambia a otra ruta hasta que esta deja de estar disponible. Cuando esto ocurre,
se realiza una conmutación por error a una ruta nueva. Cuando la ruta original vuelve a estar
disponible, el host no conmuta a la ruta original. MRU es la política predeterminada y obligatoria
para los dispositivos de almacenamiento activo-pasivo.
Antes de aplicar una política, asegúrate con el fabricante o leyendo la documentación del modelo del
almacenamiento, que soporta Round Robin, Fixed o MRU.
2. Introducción al almacenamiento NFS
2.1 Acerca de NFS
NFS es un protocolo de uso compartido de archivos que usan los hosts ESXi para comunicarse con
un dispositivo NAS.
Al igual que en VMFS, NFS ofrece también la posibilidad de guardar archivos, plantillas e imágenes
ISO de máquinas virtuales, lo que permite migrar máquinas virtuales entre host con la característica
de vMotion.
Los hosts ESXi no utilizan el protocolo “Network Lock Manager”, que es el protocolo estándar para
permitir el bloqueo de archivos en los archivos NFS montados. VMware tiene su propio protocolo de
bloqueo. Los bloqueos NFS se realizan creando archivos de bloqueo en el servidor NFS. Los archivos
de bloqueo reciben el nombre .lck-fileid, donde fileid es el valor del campo fileid. Cuando se crea un
archivo de bloqueo, se envía una actualización periódica al archivo de bloqueo para informar a los
demás hosts ESXi de que el bloqueo sigue activo.
Inicialmente VMware vSphere sólo admitía NFS versión 3, pero a partir de vSphere 6.0 empezó a dar
soporte a la versión 4.1.
2.2 Sobre NFS v4.1 en vSphere
El soporte de NFS 4.1 en vSphere 6 permitió superar varias limitaciones de la versión 3, las cuales
mencionaremos a continuación.
Es posible usar ambas versiones, pero sin mezclar los protocolos, es decir, si creamos un recurso
compartido con v4.1, debemos de montar ese recurso en todos los servidores con la misma versión.
NFS v4.1 proporciona las siguientes mejoras frente a NFS v3:
• Multipathing nativo y trunking de sesión: NFS v4.1 proporciona multipathing nativo para servidores
que admiten trunking de sesión (múltiples direcciones IPs para acceso a recursos NFS).
• Autenticación Kerberos: NFS v4.1 introduce la autenticación Kerberos además del método
tradicional AUTH_SYS utilizado por NFS v3.
• Bloqueo de archivos integrado mejorado.
• Recuperación de errores mejorada para atenuar la caída del servidor y la conectividad.
• Menos sobre carga en el protocolo, lo que mejora la eficiencia y el rendimiento.
• Controles de errores mejorado ya que se realiza desde el servidor.
Las principales “diferencias” entre NFS 3 y NFS 4.1 son:
NFS v3 NFS v4.1

Multipath gestionado por ESXi Multipath y trunk nativo
Autenticación AUTH_SYS (raíz) Autenticación por Kerberos (opcional)
Bloqueo de archivo por VMware Bloqueo de archivo integrado
Control de errores en el cliente Control de errores en el servidor
2.3 Requisitos de un datastore NFS
Si trabajamos sobre TCP/IP, es imprescindible crear un puerto de tipo VMkernel dedicado

específicamente para este tráfico.
Para obtener el máximo rendimiento y mayor seguridad, debemos separar la red NFS de la red iSCSI
(tráficos independientes).
Para crear un datastore NFS desde vSphere Web Client debemos introducir la siguiente información:
• Versión NFS: v3 o v4.1
• Nombre del datastore (recomendado usar el mismo que se proporcionó en el NAS/Storage).
• Nombre o dirección IP del servidor NFS.
• Carpeta del servidor NFS, por ejemplo /vols/vol0/librovExpert-01
• Servidores en los que se montará el recurso NFS.
• Si el sistema de archivos NFS se debe montar en modo de solo lectura.
• Parámetros de autenticación.
2.4 Montaje de un volumen NFS en vSphere
Una vez que hayamos realizado la configuración oportuna en el NAS/Storage (creación del recurso
compartido, lista de servidores que podrán montar, permisos del recurso, etc.) debemos de montar el
recurso compartido en los hosts ESXi a los que se les permitió desde el NAS/Storage.
Sobre el hosts o Clúster VMware, botón derecho, New Datastore —> seleccionamos “NFS”
Ahora elegimos el tipo de versión NFS, en mi ejemplo, v4.1
Ahora introducimos el nombre del datastore, el “folder” que no más que el recurso compartido
configurado desde el NAS/Storage y el servidor NFS desde donde servimos el recurso.
Tal como ya comentamos, en NFS 4.1 es posible usar kerberos como método de autenticación, en este
ejemplo, dejaré la opción por defecto.
En el paso 5, seleccionamos los hosts a los que le presentaremos el NFS (esta opción aparece por que
hice botón derecho —> New Datastore a nivel de clúster).
Por último, confirmamos que la información introducida durante el asistente es correcta y finalizamos.
Si los datos introducidos en el asistente, así como la configuración de la cabina es correcta, tendremos
un datastore NFS listo para alojar máquinas virtuales, template, ISOs, etc.
2.5 Factores a tener en cuenta (kerberos con NFS)
Debemos de tener en cuenta el UID y el GID de los archivos:
• En NFS v3, UID y GID son los del usuario raíz.
• Debemos crear una cuenta en Active Directory para el acceso de NFS v4.1, activar el cifrado AES
de Kerberos y que la contraseña nunca expire.
• Configurar que el almacenamiento o NAS utilicen Kerberos.
• Si usamos Kerberos, que siempre sobre NFS v4.1, sobre todo para evitar errores de permisos en
ficheros creados en NFS v3.
Debemos utilizar el mismo usuario de Active Directory en todos los hosts ESXi/recursos NFS v4.1:
• vSphere vMotion podría fallar si los hosts autenticados con dominio (requisito obligatorio de
kerberos) usan cuentas de usuario diferentes, para evitar esto, podemos utilizar “host profile”.
• Para que la autenticación de Kerberos se efectúe correctamente, debemos asegurarnos que la

hora está sincronizada (usar el mismo servidor NTP para toda la infraestructura).
Kerberos debe estar configurado en los servidores NFS y en los hosts ESXi antes de crear un datastore
NFS.
2.6 Compatibilidad con las tecnologías de VMware
A continuación, podemos ver diferentes tecnologías de VMware y la compatibilidad de cada una de

ellas con las diferentes versiones de NFS soportadas por vSphere.
Tecnologías VMware NFS v3 NFS v4.1

vSphere vMotion y vSphere Storage vMotion Si Si
vSphere HA Si Si
vSphere Fault Tolerance Si Si
vSphere DRS y vSphere DPM Si Si
Stateless ESXi y Host Profile Si Si
vSphere Storage DRS y Storage I/O control Si No
Site Recovery Manager Si No
vSphere Virtual Volumes Si No
2.7 Recomendaciones para trabajar con NFS
• Lo primero, configurar que el almacenamiento o NAS permita un solo protocolo NFS.
• Para montar el mismo recurso compartido NFS en todos los hosts ESXi, utilizar una única versión,
NFS v3 o NFS v4.1.
• Si montamos un datastore con la versión 3 y en otro host con la versión 4.1, podría provocar que
las máquinas virtuales, template o ISOs se dañen.
H O S T E D P R I VAT E C L O U D
El camino más
rápido al cloud
OVH le ofrece la posibilidad de tener su propio Hosted Private Cloud: una infraestructura dedicada y físicamente
aislada para obtener un rendimiento óptimo. Su escalabilidad permite abarcar todas las necesidades empresariales,
desde las más básicas hasta las más avanzadas, disfrutando de todas las ventajas del alojamiento on-premises sin
una gran inversión de capital. Al estar administrada por OVH, usted podrá centrarse en la gestión de su negocio.
S O F T WA R E H A R D WA R E RED
Integración completa Acceso inmediato a una Red mundial de fibra óptica
en su sistema informático, infraestructura dedicada con ancho de banda
con vCenter y vSphere basada en los últimos garantizado, tráfico ilimitado
as a service. procesadores de Intel. y sin costes ocultos.
Lo mejor de la tecnología VMware

Construido sobre la misma plataforma que usted utiliza
actualmente en sus instalaciones, incluyendo vSphere, vCenter,
NSX y vSAN.
Basado en la tecnología Software-Defined Datacenter de VMware.
Con los mejores servicios que ya conoce, más la nueva opción
para desplegar entornos híbridos Hybrid Cloud Extension (HCX).
OVH.COM
PROMOVIENDO TU
TRANSFORMACIÓN
DIGITAL
Capítulo 7
vSAN
Federico Cinalli
Capítulo 7 - vSAN Federico Cinalli
1. Introducción y Casos de Uso
VMware presentó Virtual SAN (vSAN de aquí en adelante) durante el VMworld de 2013 (En USA)
aunque el GA recién estuvo disponible en Marzo de 2014 a partir de vSphere 5.5 U1.
Si bien en aquella época todavía no hablábamos de hiperconvergencia, sí que comenzábamos a hacer

referencia al Centro de Datos definido por Software mientras que NSX 6.0, en su primera versión, hacía
su presentación en Octubre de 2013 y comenzaba a patear el tablero de la virtualización de redes. En
aquellos meses estaba naciendo el tándem vSAN-NSX que sería la base, junto con vSphere, sobre la
que se sostiene el SDDC de VMware.
vSAN aporta una robusta solución de Almacenamiento definido por Software utilizando discos locales,
embebida en el Hypervisor, sin dependencia de ninguna pieza de Hardware en concreto ni ninguna
máquina virtual por Host.
Es un producto complementario a vSphere que, al igual que HA o DRS, se configura a nivel de

Cluster y se administra principalmente con vSphere Client aunque también es posible gestionarlo con
herramientas como PowerCLI, vRealize Orchestrator o incluso a través de API.
Las diferentes opciones de protección, capacidad y rendimiento se definen a nivel de objeto utilizando
las políticas de almacenamiento de Máquinas Virtuales en vCenter.
De la mano de vSphere 6.0 llegó también vSAN 6, siempre alineándose con la versión del Hypervisor.
El aporte más significativo fue la introducción de vSAN All Flash, lo que permitía comenzar a considerar
el producto como un serio candidato para dar soporte de almacenamiento a aplicaciones críticas.
Los primeros casos de uso de vSAN fueron entornos de VDI con la Suite Horizon, siendo el Cluster
Híbrido el uso más común. No obstante, a medida que VMware actualizaba vSphere hacía lo propio
con vSAN añadiendo más funcionalidades como la deduplicación y compresión, Stretched Cluster,
Encriptación y UNMAP entre otras. Según se libera una nueva versión de vSAN disponemos de una
plataforma cada vez más madura y estable si cabe, lo que permite ser considerado hoy en día, sin
lugar a dudas, como una gran solución de Almacenamiento definido por Software para aplicaciones
críticas.
Hoy en día, debido al descenso en los precios de los discos SSD e incluso NVMe, la gran mayoría de
los nuevos Clusters de vSAN son All-Flash permitiendo dar soporte a prácticamente cualquier tipo de
carga de trabajo.
Si bien es cierto que vSAN encaja a la perfección en infraestructuras HCI, no estamos hablando de una
solución exclusiva para ese tipo de hardware como sí lo son otros tipos de almacenamiento definidos
por software del mercado.
Es posible ver vSAN funcionando en producción sobre los servidores clásicos de 2U’s aportando una
capacidad importante de espacio disponible a la vez que aporta una escalabilidad tremenda en cuanto
a capacidad de almacenamiento.
En los datacenters en los que se despliega un Cluster de Management también vemos cada día más y
más Clusters de vSAN permitiendo un aislamiento en cuanto a capacidad, rendimiento y disponibilidad
respecto al almacenamiento utilizado para producción.
Existen no obstante determinadas aplicaciones o sistemas que tal vez no sean el ideal para vSAN
como pueden ser las soluciones de gestión documental que requieren grandes cantidades de
almacenamiento.
Debido a requerimientos de licencias podemos ver clusters de bases de datos desplegadas en hosts
físicos que necesiten acceso a un almacenamiento compartido. Si bien vSAN ofrece la posibilidad
de compartir LUNs a través de iSCSI para dar servicio a esos requerimientos no lo solemos ver en
producción, al menos todavía.
Por último, debemos aclarar que todos los conceptos que cubriremos en este capítulo están basados
en la versión 6.7 de vSAN.
2. Conceptos de vSAN
El sistema de almacenamiento definido por software de VMware es extremadamente simple de

implementar y administrar. No obstante, para comprender de forma correcta cómo es la configuración
y administración necesitamos aprender ciertos conceptos y componentes claves en vSAN.
Es posible trabajar con dos tipos de Clusters de vSAN diferentes en cuanto a los tipos de disco y
sus funcionalidades. Por un lado disponemos de vSAN Cluster Híbrido, y por el otro vSAN All-Flash.
Veamos una tabla comparativa.
Característica vSAN Híbrido vSAN All Flash

Discos Capacidad Mecánicos (SAS-SATA) SSD – NVMe
Discos Caché SSD – NVMe SSD – NVMe
70% Lectura
Uso Caché 100% Escritura*
30% Escritura
Deduplicación y Compresión No soportado Soportado (vSAN Enterprise)
Operaciones lectura Primero Caché Principalmente capacidad
Recursos Red vSAN 1Gbps – 10Gbps** 10Gbps o superior
RAID 5/6 No soportado Soportado
*También da servicio de lectura antes que se produzca el movimiento de los datos desde los discos de
caché a los de capacidad, operación conocida como destage.
**Recomendado
Veamos a continuación las diferentes formas de desplegar vSAN en un Cluster.
Cluster de vSAN Clásico

Éste es el vSAN Clásico que requiere un mínimo de 3 Nodos. Si bien técnicamente es posible configurar
un Cluster de vSAN con hasta 30 Nodos (incluso más), no es muy común ver estas cantidades de
Hosts en producción.
Con independencia del tipo de Cluster de vSAN y el número de Nodos, siempre tendremos un único
vSAN Datastore por Cluster y los únicos Hosts que tendrán acceso a ese Datastore serán los miembros
del propio Cluster de vSAN.
Cluster de vSAN de 3 Nodos

También llamado vSAN ROBO para oficinas remotas, es un Cluster de vSAN compuesto por dos Nodos
que replican los componentes entre sí. El Witness Host es normalmente una máquina virtual (también
puede ser un Host físico) que se despliega en otro sitio y almacena únicamente los componentes de
Witness.
Los Clusters de vSAN de 2 Nodos pueden ser configurados en el mismo Site o en diferentes sites y
funcionar de forma similar a los Stretched Clusters.
vSAN Stretched Cluster

El concepto de Sites para vSAN Stretched Cluster es algo especial ya que se trata de dos centros de
datos remotos (o dos edificios) que puedan ser conectados con 10Gbps y una latencia máxima (round
trip) de 5 milisegundos. Merece la pena comenzar aclarando este concepto de Site debido a que estos
requerimientos pueden estar fuera del alcance de múltiples organizaciones con más de un Site.
Es factible describir un Site de Stretched Cluster como un Campus o simplemente dos ubicaciones
físicas diferentes que cumplan con los requerimientos expuestos anteriormente.
El objetivo de un vSAN Stretched Cluster es crear una protección de objetos entre Sites replicando el
método de protección local.
Esquema vSAN Stretched Cluster
Hardware soportado en vSAN

Si hay una parte importante a cumplir en vSAN, ésa es la compatibilidad y el uso del Hardware validado
para vSAN. Además del Host y las interfaces de Red que se validan como siempre en la HCL de
vSphere, las controladoras RAID y los Discos son de obligada verificación en la lista de compatibilidad
de Hardware para vSAN.
Aunque no solamente el Hardware sino que también el Firmware y los drivers deben estar validados
para esos componentes y su correspondiente versión de vSAN.
Existen 3 formas diferentes de seleccionar el Hardware a utilizar según vemos a continuación.
vSAN Hosts compatibles

También conocidos en inglés como Built your own (o móntelo usted mismo) son Hosts de diferentes
marcas que no son vSAN Ready Nodes aunque la totalidad de sus componentes están soportados
para vSAN.
vSAN Ready Nodes

Tal vez la forma más simple de implementar vSAN es utilizando los Ready Nodes para vSAN. Estamos
hablando de un Hardware pre-validado en diferentes modelos, configuraciones variadas según
necesidades y provistos por múltiples fabricantes como Dell, Fujitsu, Lenovo, Intel, etc.
Están disponibles los modelos HY para Clusters Híbridos y los AF para los Clusters All-Flash.
Tanto los discos como las controladoras están pre-validados para vSAN y ofrecen diferentes
combinaciones de CPU, RAM y Capacidad. Algunos fabricantes ofrecen más flexibilidad que otros.
Intel vSAN Ready Node de Adistec
Dell EMC vXRail

Por último tenemos la opción de elegir este sistema listo para usar (pre-instalado) y con un soporte
único tanto para Software como para Hardware aunque también es cierto que es la opción de mayor
costo y tal vez menor flexibilidad en cuanto a modificaciones de la configuración y, especialmente,
escalabilidad de recursos.
Solución HCI de Dell EMC
La Red de vSAN
Evidentemente un elemento crítico es la Red de vSAN a través de la cual no solo se utiliza para servir
los bloques de datos, sino que también es la plataforma sobre la que viajan los componentes en sus
replicaciones, resincronizaciones, balanceos y operaciones internas entre los componentes de vSAN.
Como mencionamos anteriormente, en el caso de un Cluster de vSAN Híbrido es posible utilizar

interfaces de 1GbE, aunque la recomendación es el uso de interfaces de 10GbE. Cuando se trata de
un Cluster All-Flash de vSAN el requerimiento mínimo es una red de 10GbE aunque poco a poco ya
se ven redes de 25Gbps o incluso superiores. Se dice que los interfaces de 25Gbps son los nuevos
10Gbps.
Naturalmente que para evitar un punto único de fallo aprovisionaremos dos interfaces que trabajaran
con el Port Group de VMkernel de vSAN. La configuración es muy simple, como vemos en el siguiente
esquema, un VMKernel con dos Uplinks de los cuales uno estará Activo y el otro en StandBy.
Esquema simple de la Red de vSAN
No sería correcto afirmar que existe una única forma de configurar la red de vSAN aunque el esquema
anterior muestra la opción más común.
Todo siempre depende de la cantidad y calidad de recursos de que dispongamos y de la configuración

de red del resto de los servicios.
Veamos una lista de opciones y sus recomendaciones.
Jumbo Frames: Si es posible, habilitar.
EtherChannel o LACP: Normalmente se habilita cuando el resto de los servicios ya está trabajando el
agrupado de puertos y el área de networking tiene experiencia previa.
Virtual Switch Standard o Distribuido? Distribuido siempre que sea posible. vSAN incluye licencia
de vDS sin importar si nuestro vSphere es Standard.
NIOC (Network IO Control): Habilitarlo y configurarlo. Es la mejor forma establecer la prioridad del
tráfico de vSAN. Esto lo consideraremos “obligatorio” cuando estamos compartiendo interfaces de
10GbE o superiores para múltiples tipos de tráfico.
QoS (Quality of Service): En un mundo perfecto también habilitaríamos QoS salvo que utilicemos
switches físicos exclusivos para el tráfico de vSAN, lo cual no suele ser muy común.
Política de balanceo: Al configurar un Uplink en Activo y otro en StandBy no hace falta definir ninguna
política de balanceo.
Existe un gran documento oficial de VMware que podemos utilizar como guía para la configuración de
los servicios de red en vSAN:
Documento de Diseño de red en vSAN (174 páginas)
Objetos de Máquinas virtuales

Una Máquina Virtual está compuesta por diferentes ficheros de configuración, logs, swap, discos
virtuales y discos delta entre otros.
vSAN gestiona las políticas de capacidad, alta disponibilidad y rendimiento en base a objetos de
máquina virtual. Veamos a continuación cuáles son esos objetos.
VM home namespace: Este objeto es la carpeta de la VM con los ficheros de bios, vmx, nvram, hlog
y vmsd.
Disco Virtual: Por cada disco virtual que tenga la máquina vSAN gestionará un objeto de tipo disco
vmdk.
VM SWAP: El fichero de swap tendrá un tamaño igual a la cantidad de RAM asignada a la VM menos
la reserva.
Disco Delta: Una máquina con Snapshots tiene un disco delta por cada disco virtual y cada Snapshot
disponible.
VM memory: Cada vez que creamos un snapshot y preservamos el estado de la memoria tendremos
almacenado un fichero .vmem que, en vSAN, es otro objeto.
Máquina Virtual y Objetos que la componen
Grupos de Discos
Según explicamos anteriormente cada máquina virtual está compuesta por Objetos. Una vez asignada
la política correspondiente a cada Objeto, vSAN se encarga de crear los Componentes. Si bien los
Componentes se almacenan en el Datastore de vSAN, en realidad ese Datastore está compuesto por
Grupos de Discos o Disk Groups.
Un Host puede tener un Grupo de Discos, hasta un máximo de 5 Grupos de Discos o incluso ninguno.
La buena práctica es aprovisionar cada Host del Cluster de vSAN con 2 Grupos de Disco.
Cluster de vSAN con 2 Disk Groups en cada Host
Los Grupos de Disco deben disponer de un único disco para Caché, el cual será siempre SSD con
independencia del tipo de Cluster de vSAN, y al menos un disco de Capacidad.
El número mínimo de discos de Capacidad por Grupo de Discos es uno, mientras que el número
máximo de discos de Capacidad son 7.
Los discos de Capacidad en un Cluster de vSAN Híbrido son del tipo mecánicos (SAS o SATA) y los
discos de Capacidad en un Cluster de vSAN All-Flash son siempre SSD.
En una infraestructura hiperconvergente (HCI) normalmente cada Host dispone de 6 slots para discos.
A continuación, vemos 3 ejemplos diferentes de cómo se podrían configurar los Disk Groups en un
Host HCI.
3 Ejemplos de configuración de Disk Groups en HCI
Importante: Únicamente los discos de capacidad son los que aportan el Almacenamiento utilizable
(capacidad) en el Datastore de vSAN.
Datastore de vSAN alimentado por los discos de Capacidad
3. Servicios de Arquitectura de vSAN
vSAN es una solución que se configura y trabaja a nivel de Cluster aunque los servicios almacenamiento,
al igual que vSphere HA, puede continuar operativos aún con el servicio de vCenter caído.
La información que vamos a cubrir a continuación no es crítica desde el punto de vista operativa en sí
misma, pero sí muy importante si pretendemos comprender cómo funciona vSAN a nivel de arquitectura
e incluso nos ayudará a interpretar mejor los Logs en un proceso de resolución de problemas al
reconocer los nombres de los servicios de las diferentes capas funcionales de vSAN.
En el momento en que habilitamos vSAN en un Cluster, los Hosts que son miembros del mismo
comienzan a instalar y configurar los servicios de arquitectura. Los servicios son CMMDS, CLOM,
DOM y LSOM.
CMMDS: El servicio de Cluster Monitoring Member and Directory Service es el encargado de almacenar
y gestionar la base de datos de los servicios de Directorio en vSAN. Todos los objetos, componentes y
recursos están indexados en la base de datos que se almacena en memoria en cada uno de los Hosts
que son miembros del Cluster. Cada Host del Cluster tendrá su rol para dar servicio a CMMDS, los
cuales pueden ser Master, Backup o Agent. Existirá un único Master, un único Backup y el resto de los
nodos del Cluster funcionarán como Agent.
CLOM: El acrónimo CLOM proviene de Cluster Level Object Manager y es un servicio clave en vSAN
al definir la viabilidad en la creación de objetos, la mejor ubicación posible siguiendo las políticas
asignadas y la distribución más equitativa posible de los objetos entre Fault Domains, Hosts y Disk
Groups.
CLOM gestiona además la recreación y actualización de objetos luego de un fallo. El servicio CLOM no
utiliza la red y se comunica únicamente con las instancias locales de CMMDS y DOM.
DOM: Distributed Object Manager es el nombre del servicio que funciona como nexo entre CLOM y
LSOM. Cada instancia de CLOM se comunica con su instancia local de DOM para enviar la orden de
creación, actualización y/o modificación de los componentes. Cada instancia de DOM gestionará las
peticiones con su servicio local LSOM a quien le enviará esas peticiones recibidas por CLOM. Para
las tareas a ejecutarse en Hosts diferentes, DOM tendrá que comunicarse con la instancia de DOM de
los otros Hosts del Cluster para hacer llegar esas peticiones, las cuales se reenviarán a sus servicios
LSOM locales.
DOM también gestiona lo que se conoce como DOM Client y DOM Owner. El Client será quien se
encargue del envío de operaciones de entrada/salida en nombre de cada VM. Por cada objeto de
vSAN hay un Owner y es quien gestiona lo más parecido a un bloqueo en los accesos a esos objetos
y entrega las rutas a la ubicación de los componentes.
LSOM: El Log Structured Object Manager es el único servicio que trabaja con los discos de los Hosts.
Gestiona tanto los discos de Caché como también los de capacidad y se hace cargo de las tareas
de Destage para mover los datos desde los discos de Caché hacia los de Capacidad. Cuando están
habilitados los servicios de Deduplicación y Compresión se encarga de deduplicar (al momento del
destage) y de comprimir, siempre y cuando sea posible comprimir un bloque de 4K en 2K o menos.
Si el Cluster de vSAN tiene habilitado el servicio de encriptación entonces será LSOM quien se
encargue de encriptar los datos.
Y como si fuera poco también identificará y reportará cualquier tipo de fallo en los discos físicos de los
Disk Groups así como también monitorizará el espacio consumido en cada uno de los discos.
Servicios de arquitectura de vSAN
4. Configuración de un Cluster de vSAN
La configuración de un Cluster de vSAN es una tarea realmente simple. Una vez validado el Hardware
y definido el Diseño, es solo cosa de unos cuantos clicks.
Ante todo debemos recordar y destacar que vSAN es una solución embebida en el Hypervisor, de ahí
que el título de este apartado comience con Configuración en lugar de Instalación.
Repasemos los requerimientos de vSAN:

• Hardware validado (incluyendo Firmwares y Drivers)
• vCenter Server
• vSphere HA
• Port Group de VMKernel en cada Host
• Un Disk Group por Host (al menos los 3 primeros Hosts)
• Licencia de vSAN
Si bien no es un requerimiento, es altamente recomendable que se considere una consistencia en los

Hosts en cuanto a recursos de cómputo y discos locales.
¿Creamos un Cluster de vSAN? Ahí vamos!!!
Paso 1: Creación del Cluster

Para crear y configurar el Cluster de vSAN los servicios de HA deben estar deshabilitados, aunque una
vez finalizado el asistente inicial debemos habilitarlos ya que es un requerimiento.
Al marcar la opción de vSAN y hacer click en Ok, al cabo de unos pocos segundos tendremos los
servicios básicos de vSAN habilitados en el Cluster.
Creando el Cluster de vSAN
A partir de vSphere 6.7 (vSAN 6.7) disponemos del asistente quickstart. El asistente es opcional y nos
permitirá configurar la totalidad de los servicios de vSAN en el Cluster.
A continuación, veremos una configuración sin utilizar el quickstart.
Cluster quickstart en vSphere Client
Paso 2: Configuración de servicios adicionales y parámetros

Si tenemos pensado habilitar los servicios de Deduplicación y Compresión o bien si nuestro diseño
requiere la encriptación del Datastore de vSAN, se recomienda habilitar todas estas opciones antes de
agregar los Hosts o bien antes de crear o migrar máquinas al Datastore de vSAN.
Esta recomendación es debido a que los Disk Groups requerirán un formato especial para cada caso
y es preferible aplicar ese formato cuando no existen todavía componentes.
En nuestro caso habilitaremos Deduplicación y Compresión. Además, dejaremos habilitada la opción

Thin Swap para ahorrar espacio al aplicar el formato Thin Provisioning a los ficheros de Swap. También
habilitamos el Performance Service que nos proveerá de métricas muy útiles que utilizaremos para
monitorizar nuestro Cluster.
(Hablaremos de la opción Site Read Locality en el apartado de Stretched Cluster)
Opciones generales del Cluster de vSAN
Paso 3: Agregar los Hosts y validar configuración

Al agregar los Hosts al Cluster veremos que se crea el vSAN Datastore aunque, al no haber definido
todavía los Disk Groups, su capacidad será de 0 bytes.
Una vez que los Hosts estén agregados al Cluster sería muy bueno esperar un par de minutos y
consultar por primera vez el vSAN Health con el objetivo de verificar que la conectividad de Red está
funcionando correctamente.
vSAN Health con configuraciones de Red validadas
En el vSAN Health deberíamos verificar también que las controladoras de discos, firmwares y drivers
están validados. Es posible que tengamos que hacer una actualización o incluso un downgrade de
algún driver. Es el momento de dejar todo a punto (pintar todo de verde!) según lo que requiere el
vSAN Health antes de continuar.
Esto es especialmente importante si no queremos tener problemas a la hora de llamar al soporte de

VMware, ya que comenzarán revisando qué tan verde está nuestro vSAN Health.
Una vez que todo está validado es momento de proceder con la creación de los Disk Groups y hacer
que el vSAN Datastore comience a sumar capacidad disponible.
Paso 4: Creando los Disk Groups

Este proceso es muy simple, solo tenemos que ir Host por Host y seleccionar los discos que serán
parte de cada Disk Group según el Diseño.
Si seleccionamos el Cluster, Configuración y en vSAN hacemos click en Disk Management podremos

configurar los Disk Groups de cada Host.
Configuración de Disk Groups en el Cluster
Creando un Disk Group en un Host
Ejecutamos el mismo proceso en cada uno de los Hosts del Cluster. El tiempo que requerirá la creación
de cada Disk Group dependerá de la cantidad de discos y su capacidad, pero hablamos de solo unos
pocos minutos.
Una vez finalizada la creación del último Disk Group ya podemos confirmar que nuestro Datastore de
vSAN dispone de capacidad utilizable.
En este punto ya estamos listos para migrar máquinas o bien crear nuevas sobre nuestro flamante
Datastore de vSAN. ¿Fácil verdad?
5. Políticas de vSAN
Mencionamos varias veces que vSAN se gestiona a través de las Políticas. En realidad, lo que
gestionamos a través de las políticas de vSAN son los objetos de máquina virtual y, una vez asignada
una política, esos objetos están representados en los Disk Groups de los Hosts como Componentes.
A veces son llamados Réplica Components (normalmente en mirroring), otras Data Components (en
Erasure coding) o incluso simplemente Componentes.
Los niveles de tolerancia a fallos en Almacenamiento, consumo de espacio, nivel de RAID y rendimiento
van a depender de la combinación de reglas que definamos en la política asignada al Objeto. O
diciéndolo de otra forma, las reglas de una política van a impactar en el consumo, rendimiento y
tolerancia a fallos.
Por ejemplo, si seleccionamos RAID 1 consumiremos más espacio que con RAID 5, pero a nivel de
rendimiento será mejor RAID 1 debido a que no es necesario el cálculo de paridad.
También existen reglas dentro de las Políticas que permiten crear reserva de espacio en disco, lo cual
supone un mayor consumo de espacio.
Máquinas, Objetos, Políticas y Componentes
vSAN dispone de varias reglas de Políticas en su versión 6.7. Particularmente en la versión 6.7 tenemos
que tener en cuenta que las reglas se verán diferentes (bastante diferentes) al utilizar vSphere Web
Client o vSphere Client.
Política vSAN con RAID 1 en vSphere Web Client
Política vSAN con RAID 1 en vSphere Client
La recomendación es utilizar vSphere Client ya que será el único cliente en las próximas versiones,
por lo cual en este capítulo utilizaremos ese cliente para revisar las reglas. Veamos cómo funciona y
en qué caso aplica cada regla.
Site disaster tolerance: Si configuramos vSAN Stretched Cluster utilizaremos esta regla en la política
de vSAN para asignar a los objetos de las máquinas virtuales que queremos brindar protección entre
sites. La opción es “Dual site mirroring (stretched cluster)”.
Las otras opciones nos permiten definir protección a nivel de Fault Domains y también seleccionar un
Site de preferencia para los componentes de máquinas en caso que no exista una protección entre
sites. A esto se le aplica el “Site Read Locality” y debe estar configurado a nivel de Cluster de vSAN,
en opciones avanzadas.
Configuración de tolerancia a fallos entre Sites
Fallos a Tolerar (antes PFTT): Como su nombre lo indica es el número de fallos que vamos a tolerar.
Cualquier tipo de error que impacte en el acceso al componente contará como un fallo, incluyendo la
puesta en mantenimiento de un Host.
Las opciones disponibles nos permiten configurar la regla para no disponer de redundancia (RAID 0),
protección contra un fallo (RAID 1 y RAID 5), tolerancia de dos fallos (RAID 1 o RAID 6) y soporte para
protección ante tres fallos (RAID 1).
Las opciones de Mirroring con protección contra dos fallos tendrán 3 réplicas y las que toleren hasta
tres fallos contarán con 4 réplicas.
Definiendo la tolerancia a fallos
Número de componentes por disco: opción por defecto 1 y un máximo de 12, aplica únicamente
en vSAN Híbrido con el objetivo de distribuir los componentes entre múltiples discos y de esa forma
obtener un mayor número de IOPS.
Número de discos en los que se distribuirá el componente
Límite de IOPS por objeto: El valor por defecto es 0 (sin límite). Este valor podría aplicar para crear
una especie de “Tiers virtuales” definiendo 2 o más niveles de rendimiento a través de estos límites.
vSAN considera un IOP(s) a una petición de hasta 32K. Si hubiera una petición de 64K entonces sería
considerado como 2 IOPS.
¿Y si hubiese 4 peticiones de 4K? vSAN las gestionará como 4 IOPS diferentes.
Configuración del límite de IOPS
Reserva de espacio por objeto: por defecto se utiliza thin provisioning, lo que supone que no hay
ningún tipo de reserva. Existe la posibilidad de reservar el espacio en el vSAN Datastore para una parte
o incluso la totalidad del componente (25% - 50% - 75% - Thick provisioning). Esta regla cambiará el
formato thin provisioning del objeto a un thick provisioning lazy zeroed (sin inicializar los bloques) lo
cual incrementará el consumo del Datastore de vSAN producto de la capacidad reservada.
Formato y reserva de espacio para objeto
TIP: Evitar a toda costa crear una reserva de espacio en la política de vSAN por defecto. No vamos a
querer ver el resultado, sobre todo si ya estamos en producción ;-)
Reserva de Flash Read Cache: esta reserva aplica únicamente a vSAN Híbrido y se utiliza para
asignar/reservar una determinada capacidad del objeto para ser almacenada en los discos de caché
del Disk Group con el fin de mejorar el ratio de acierto en caché.
Deshabilitar el Object Checksum: por defecto se le aplica el proceso de validación de escritura a

cada dato que se escribe. Existen algunas aplicaciones, normalmente bases de datos, que realizan
su propio checksum. Es en esos casos cuando definimos la política con esta regla para “deshabilitar”
el Object Checksum con el fin de mejorar el rendimiento evitando una doble comprobación, aunque la
diferencia puede llegar a ser apenas perceptible.
Vale aclarar que no se recomienda deshabilitar el Object Checksum.
Reglas avanzadas en política de vSAN
Forzar el aprovisionamiento: cuando creamos una nueva máquina virtual y/o algún objeto en vSAN,
el servicio CLOM validará que ese objeto estará en modo “compliance” según la política asignada.
Si por algún motivo no disponemos de la mínima cantidad de recursos (por ejemplo, un Host en
mantenimiento) el proceso de creación del objeto no continuará debido a la regla por defecto.
Si queremos forzar la creación de esos objetos por más que el estado sea “non compliance” entonces
configuraremos la regla para que la opción Force Provisioning sea “Yes”.
Regla de vSAN para forzar el aprovisionamiento
Comparando métodos de protección

La siguiente tabla es una excelente comparativa de las diferentes opciones a utilizar para tolerar fallos
con sus correspondientes métodos.
Componentes Objetos Erasure Coding Mínimo de

Fallos a tolerar Protección
Replica/Data Witness vs Mirror Hosts
0 RAID 0 1 0 - 3
1 RAID 1 2 1* - 3
1 RAID 5 4 0 33% menos 4
2 RAID 1 3 2* - 5
2 RAID 6 6 0 50% menos 6
3 RAID 1 4 3* - 7
Tabla comparativa de opciones y métodos de protección
*El número de objetos Witness se crea automáticamente dependiendo de varios factores como número
y tamaño de objetos, número de hosts y opciones en las reglas de la política.
Gestión de Políticas de vSAN

Una vez diseñado, implementado y validado el primer Cluster de vSAN pasamos a la configuración de
las políticas. A través de las políticas de vSAN definiremos aspectos tan importantes como la protección
ante fallos, el consumo del espacio en disco, rendimiento y otros aspectos que nos permiten adaptar
los servicios de almacenamiento a las diferentes cargas de trabajo a nivel de objeto de máquina virtual.
Una vez definidas esas políticas, las cuales se crean a nivel de vCenter, es hora de mover máquinas
al Cluster de vSAN. Da igual si vamos a crear máquinas nuevas o si estamos migrando máquinas
existentes al Datastore de vSAN, siempre tendremos que asignar una política.
Asignación de política en nueva máquina virtual
Todo objeto de máquina virtual que esté almacenado en un Datastore de vSAN deberá tener asignada
su política correspondiente. Por cada Cluster de vSAN tendremos una política por defecto.
La recomendación es NO modificar la política de vSAN por defecto.
Siempre podemos crear una nueva política con las reglas que necesitemos.
Ahora la pregunta es, una vez que tenemos máquinas y políticas, ¿cuáles son las opciones de gestión?
La respuesta es bien simple. Las políticas se pueden modificar según necesitemos y también es posible
cambiar (reasignar) una política a alguno o a todos los objetos de una máquina virtual. Veamos los dos
casos.
Cambiando una política a los objetos de una máquina virtual

Por diferentes motivos tal vez necesitemos cambiar una política a uno o todos los objetos de una
máquina virtual. A continuación, veremos una captura de una VM con todos los objetos trabajando con
la política de vSAN por defecto.
Visualizando la política de una VM
Objetos de máquina virtual con la política de vSAN por defecto
Para cambiar la política a los objetos de una VM simplemente tenemos que seleccionar la VM en el
inventario de vCenter con el botón contextual, VM Policies y Edit VM Storage Policies.
Editando las políticas de una VM en vSAN
En la ventana de edición de políticas de almacenamiento tendremos disponible la opción de configurar

una política por disco (Aunque el nombre correcto debería ser objeto. Te perdonamos VMware ;-).
Asignando una política por objeto de máquina
Una vez que asignamos una política diferente veremos el impacto en los cambios. En este caso hemos
cambiado RAID 1 por RAID 5 con su correspondiente ahorro en el consumo de almacenamiento.
Impacto en la reasignación de política
Al cambiar la política debemos tener en cuenta el potencial impacto que generará el cambio. Un
impacto podría ser el mayor consumo de espacio, ya sea temporal o permanente. Y otro impacto serán
las operaciones de I/O al necesitar (no siempre) recrear un componente.
Máquina con nuevos componentes en RAID 5
Cambiando reglas en Política de vSAN

Otra opción de cambios en políticas asignadas a una o varias VMs es la de editar/cambiar una política
de vSAN que ya esté asignada a uno o múltiples objetos de máquinas virtuales.
En este punto tenemos que ser muy conscientes del impacto que podemos generar.
Existen múltiples cambios en políticas que requieren la recreación de componentes.
Cambios en políticas que requieren recreación de componentes:

• Cambio de RAID 1 a RAID 5
• Cambio número de objetos por componente (disk stripes per object)
• Reserva de espacio en objeto
• Cambio o asignación de reserva en Flash Read Cache
Como hemos podido observar existe un número importante de cambios que requieren la recreación de
componentes. Esos cambios van a generar operaciones adicionales de I/O, consumo de caché, tráfico
de red y consumo de espacio adicional de disco mientras se ejecutan los cambios.
Por lo tanto, debemos ser conscientes del impacto a generar, sobre todo cuando estamos cambiando
reglas en una política asignada a objetos de múltiples máquinas virtuales.
Para cambiar una regla en una política de vSAN simplemente tenemos que seleccionar la política en
Policies and Profiles/VM Storage Policies y hacer clic en Editar o Edit Settings. Una vez aplicados los
cambios en la política y finalizado el asistente veremos una ventana como la siguiente:
Solicitud de confirmación de aplicación de cambios en política
Como hemos visto disponemos de dos opciones. Una es aplicar los cambios inmediatamente,
generando el impacto que hemos comentado en todos los objetos afectados al mismo tiempo.
La otra opción sería seleccionar que queremos aplicar los cambios de forma manual más adelante.
Esto podemos hacerlo máquina por máquina o, en caso que tengamos un número considerable de
máquinas en el inventario, considerar el uso de PowerCLI para seleccionar las VMs y aplicar los
cambios de forma gradual.
Al seleccionar la opción de aplicar los cambios más adelante, podremos visualizar la lista de VMs con
objetos pendientes de aplicar los cambios. El estado de compliance de la máquina será “Out of Date”.
Política pendiente de asignar en VM
Y en caso de desear aplicar los cambios en la política de forma manual solo tendremos que seleccionar
la máquina, Configure y hacer clic en Reaplicar política (Reapply VM Storage Policy).
Compliance Out of Date
Por último, recordar que las políticas pueden ser cambiadas y editadas por más que las máquinas
estén encendidas. El impacto será mayor o menor dependiendo tanto de los recursos disponibles
como también de la cantidad y tamaño de componentes a recrear.
Se recomienda antes de aplicar un cambio de política verificar si el Cluster está recreando o poniendo
al día componentes. Aprenderemos cómo hacer esto más adelante.
6. Stretched Cluster, 2 Node Cluster y Fault Domains
Con la versión 6.0 de vSAN llegaba All-Flash para entrar de lleno a dar servicios para aplicaciones
críticas con una cantidad industrial de IOPS. La misma versión 6.0 nos traía otra novedad con el
nombre de Fault Domains (o dominios de fallo) en el que podemos crear grupos de Hosts, distribuidos
en diferentes racks, con el objetivo de incrementar la disponibilidad en caso de fallo general a nivel de
rack.
Por otra parte la versión 6.1 presentó vSAN Stretched Cluster para incrementar la disponibilidad entre
dos ubicaciones diferentes en donde estarán grupos de Hosts replicando objetos entre sí.
A partir de la misma versión de vSAN (6.1) nos permite además cubrir las necesidades de otro caso
de uso como lo son oficinas remotas en donde 2 Hosts comparten almacenamiento y ofrecen alta
disponibilidad.
vSAN Fault Domains

El objetivo de Fault Domains es distribuir las réplicas de componentes a través de Disk Groups de
Hosts que estén en diferentes zonas, o dominios de fallo.
Como mencionábamos anteriormente el principal caso de uso es la protección ante fallos generales
a nivel de rack. No obstante también es posible aplicar esta misma protección dentro de un mismo
rack para minimizar el impacto en una situación potencial de más de un Host que compartan el mismo
chasis.
La configuración de Fault Domains es francamente simple. Únicamente necesitamos definir los objetos
lógicos de cada Fault Domain y asociar el o los Hosts a cada FD.
Creación de Fault Domain en Cluster
La cantidad mínima de Fault Domains va a estar asociada al tipo de protección a aplicar en las políticas
del Cluster. Por ejemplo, si aplicaremos una política con una regla que define una protección que utiliza
RAID 5, entonces necesitaremos 4 Fault Domains. Para RAID 6, 6 Dominios de fallo serán necesarios.
Una vez creados los Fault Domains los componentes se distribuirán automáticamente a través de los
Disk Groups de cada Host en cada FD según la política aplicada.
Vista de Cluster con Fault Domain configurado
4 Dominios de fallo con Componentes distribuidos
Por último, debemos comentar que únicamente es posible configurar Fault Domains siempre y cuando
no hayamos habilitado Stretched Cluster o 2 Node Cluster debido a que estas dos soluciones utilizan
ya de por sí el concepto de Fault Domains.
Stretched Clusters
Cuando se trata de incrementar la disponibilidad de las aplicaciones, ya sea a nivel de Computo, Red
o Almacenamiento, los objetivos se alinean con la simplicidad y los requerimientos con la fiabilidad.
vSAN Stretched Cluster aporta simplicidad, fiabilidad y resiliencia.
Un Stretched Cluster de vSAN puede escalar hasta 15 Hosts por sitio y, a través de las políticas de
vSAN, es posible seleccionar las máquinas con sus objetos a los que queremos aportar protección.
Comencemos con la lista de requerimientos.
Requerimientos de vSAN Stretched Cluster:
• Mínimo de 1 Host por Site
• Máximo de 15 Hosts por Site*
• Witness Host en un tercer Site (normalmente es un virtual appliance)
• Conectividad de 10 Gbps entre el Site Primario y el Secundario en capa 2
• Latencia máxima de 5ms Roundtrip entre el Site Primario y el Secundario
• Conectividad de 2 Mbps por cada 1000 objetos entre los Sites de Datos y el Witness Host
• Latencia máxima de 100ms (o superior en algunos casos) entre los Sites de Datos y el Witness
Host
• Licencia vSAN Enterprise
*Es posible trabajar con un número superior de Hosts por Site en VMC on AWS.
En base a los requerimientos podemos ver que el concepto de “Site” puede ser algo relativo. Conectar
2 Sites que estén separados por varios kilómetros y cumplir con el requerimiento de no más de 5
milisegundos de latencia puede ser algo complicado. O al menos la factura de la fibra será cuanto
menos elevada.
Esto hace que tal vez reconsideremos el concepto de Site y lo traslademos a algo como Campus,
Edificio o diferentes ubicaciones físicas que permitan cumplir con los requerimientos.
Respecto a los requerimientos del tercer Site para el Witness, también llamado Witness Site, claramente
son más relajados. Incluso cada día más y más empresas utilizan recursos de Cloud Publica para
hostear sus Witness Hosts.
El Witness Host puede ser un Host físico o bien un virtual Appliance que podemos descargar en
formato OVA.
Veamos todos los pasos para configurar un Cluster de vSAN en Stretched Cluster.
1. Despliegue de Appliance
Una vez descargado el OVA del Witness Appliance procedemos con el despliegue. La versión del OVA
debe ser la misma que la de los Hosts del Cluster.
Desplegando Witness Appliance
Las opciones son las normales de cualquier Appliance.
Desplegando Witness Appliance
Debemos seleccionar el tamaño de la VM del Witness Host. Eso dependerá de la cantidad de máquinas
a proteger como podemos apreciar en la siguiente captura.
Definiendo el tamaño del Witness Host
Y otra parte importante es la asignación de redes. Como podemos ver en la siguiente captura, existen
dos redes. Una es para los servicios de Management, al igual que un ESXi tenemos que conectar a la
misma red de vCenter y Hosts, aunque en este caso podría ser una conexión tanto de capa 2 como
de capa 3, es decir, enrutada.
Asignando redes a los servicios del Appliance
Una vez que finalizamos con el asistente del Appliance tendremos una máquina virtual como cualquier
otra. La diferencia es que esta VM es un ESXi virtualizado o, como suele decirse, en modo nested.
vSAN Witness desplegado
Importante: La máquina virtual del vSAN Appliance deberá operar sobre un Host que no forme parte
de un Cluster de vSAN.
2. Configuración del Appliance
La siguiente tarea será encender el Witness Host y configurar los servicios de red. Al igual que con
cualquier otro ESXi necesitaremos definir un registro DNS de tipo A y otro PTR asociado a la IP que le
asignaremos.
Como hemos mencionado, esa IP será la dirección de Management del Witness Host y el vCenter
tendrá que ser capaz de resolver el hostname como también llegar a la dirección IP asignada.
Witness Host con Management configurado
3. Agregando el Witness Host al inventario
El ESXi virtual que da servicio al Witness Host tiene que estar agregado al inventario del mismo
vCenter que da servicio al Cluster de vSAN.
Podremos ver que el Host virtual se diferencia del resto al utilizar un color azul claro o celeste.
Witness Host en el Inventario de vCenter
4. Configuración del servicio Stretched Cluster
Llegados a este punto ya hemos cumplido con los requerimientos previos a la configuración. Siempre
y cuando no tengamos configurado ningún Fault Domain, podremos hacer click en el botón Configure
para comenzar con el asistente de configuración.
El asistente es muy simple como veremos a continuación.
Cluster de vSAN listo para configurar el servicio Stretched Cluster
Lo primero será definir los Hosts que funcionarán en el Site preferido y los que operarán en el Site
secundario.
Asignando Hosts a cada Site
Lo siguiente es seleccionar el Witness Appliance que tenemos disponible en el inventario de nuestro

vCenter.
Vale aclarar que un Witness Appliance únicamente podrá dar servicio a un Stretched Cluster en
particular.
Asignando el Witness Host al Cluster
Como parte de la configuración del Stretched Cluster es necesario crear un Disk Group en el Witness
Host.
El Witness Host almacenará los componentes Witness de los objetos pertenecientes a las máquinas
protegidas con Stretched Cluster.
Creando el Disk Group en el Witness Host
Y una vez que visualizamos el resumen de la configuración, al hacer click en finalizar comenzará el
proceso de creación o conversión de nuestro vSAN a Stretched Cluster.
Si estamos ejecutando el Quickstart entonces creará el Cluster como Stretched. Y si nuestro Cluster ya
está operando con los servicios de vSAN, se convertirá el servicio para que opere en modo Stretched
Cluster.
Habilitando los servicios de Stretched Cluster
Una vez finalizado el proceso ya podremos ver cómo queda el servicio Stretched Cluster en la consola
de vSphere Client.
Vista de la consola de vSAN Stretched Cluster
A partir de ahora simplemente tendremos que asignar la política correspondiente a los objetos de las
máquinas que queremos proteger a nivel de Site.
Políticas de vSAN para definir protección a nivel de Site
En las políticas podemos ver varias opciones, las cuales explicaremos a continuación.
None – standard cluster: No protegemos los objetos con Stretched Cluster.
None – standard cluster with nested fault domains: Utilizaremos Fault Domain para protección,
aunque tampoco a nivel de Site.
Dual site mirroring (stretched Cluster): Se protegerán los objetos de la máquina a través de Sites
pero no definimos ningún Site en particular. Dependerá de la carga de cada Site o bien de las reglas
de DRS si es que las configuramos.
None – keep data on Preferred (stretched cluster): No se protegen los objetos de la máquina con
Stretched Cluster pero preferimos que los componentes se almacenen en los Disk Groups de los Hosts
pertenecientes al Site Preferred.
None – keep data on Non-preferred (stretched cluster): No se protegen los objetos de la máquina
con Stretched Cluster pero preferimos que los componentes se almacenen en los Disk Groups de los
Hosts pertenecientes al Site Non-preferred.
None – stretched cluster: No se protegen los objetos de la máquina con Stretched Cluster y el propio
Cluster, en base al espacio disponible, seleccionará el Site con menor consumo para balancear la
carga y que los componentes residan en los Disk Groups del Site seleccionado.
Site Read Locality: esta opción está disponible a partir de vSAN 6.7 y la podemos habilitar o deshabilitar
seleccionando el Cluster, en Configuración, Servicios y Opciones Avanzadas.
El objetivo es consumir un menor ancho de banda entre los Sites al ejecutar las operaciones de lectura
únicamente en los Disk Groups del Site en donde se está ejecutando la VM (recursos de computo).
Reglas DRS afinidad VM-Host: otra configuración muy común es la creación de grupos de Máquina
y Hosts para definir una afinidad. Al aplicar estas reglas de DRS, las máquinas funcionarán,
preferiblemente, los recursos de cómputo del grupo de Hosts del Site preferido o no-preferido, según
hayamos configurado la regla.
Esta es otra forma de acercar las máquinas a consumidores de recursos localizados en un Site concreto
y también en cierta forma a balancear la carga.
Clusters de 2 Nodos
Habiendo cubierto ya los servicios de Stretched Cluster únicamente nos quedaría explicar la diferencia
entre 2 Node Cluster y Stretched Cluster.
Los Clusters de 2 Nodos no tienen por qué operar en Sites diferentes. Está soportado un Stretched
Cluster de 2 Nodos y también un mini-cluster de 2 Nodos de vSAN que funcionen en el mismo Site.
Cluster ROBO de 2 Nodos
La configuración es prácticamente igual debido a que seguimos necesitando un Witness Host y la

configuración es en la misma ubicación del vSphere Client.
En cuanto a reglas, si estamos trabajando con un Cluster de 2 Nodos sin Stretched, la única política
de protección que podemos aplicar es RAID 1 y, al igual que en SC, los Witness components se
almacenarán en el Witness Host.
Cluster de 2 Nodos en modo Stretched
Una opción muy interesante que está únicamente disponible en los Clusters de 2 Nodos que operan en
el mismo sitio es que podemos utilizar un cable cruzado para conectar las vmnics que dan servicio a
los puertos VMKernel de vSAN. Esto nos evita tener que invertir en un Switch de 10Gbps por ejemplo.
Cuántos litros de cerveza podríamos comprar con lo que ahorramos en dos Switches de 10Gbps?
Y la última diferencia considerable es la licencia. Existe un paquete de licencias para Clusters de 2

Nodos que se llama ROBO, aunque no aplica a Stretched Cluster.
No obstante, también es posible licenciar un Cluster de 2 Nodos, con o sin Stretched, utilizando el
licenciamiento normal de vSAN que aplica a nivel de procesador físico o socket.
7. Componentes y fallos en vSAN
En este apartado revisaremos los diferentes tipos de fallos y cómo afectan a los componentes.
Dependiendo el tipo de fallo, los componentes se mostrarán en un estado u otro, así como también las
acciones a ejecutar por parte de vSAN pueden ser variadas.
Comencemos con los diferentes estados en que puede estar un componente:
Active: El componente está funcionando correctamente.
Absent: No hay acceso al componente y vSAN no sabe qué ocurrió. Puede deberse a un fallo de red,
un host caído, fallo de disco o un host en mantenimiento. El sistema esperará 60 minutos hasta que se
recupere el error y una vez pasado ese tiempo, en caso que el componente continúe en modo Absent,
vSAN recreará el componente de forma automática.
Degraded: El estado degradado indica que vSAN confirma un fallo, probablemente en uno de los discos
o incluso en la controladora. De forma inmediata comenzará el proceso de recreación de componente.
Reconfiguring: Ése será el estado del componente mientras se está aplicando una reconfiguración
debido a un cambio en una política que requiere aplicar cambios en los componentes.
A la hora de trabajar con un cluster de vSAN lo primero que debemos comprender es cómo el Cluster
entiende y gestiona los fallos.
Muy probablemente sepamos que si el Host está en modo mantenimiento no será capaz de proveer
servicios de cómputo a máquinas virtuales. De la misma forma, en un Cluster de vSAN, un Host
en modo mantenimiento no proveerá servicios de Almacenamiento. Veremos más adelante cómo
gestionar las operaciones en un Cluster de vSAN pero centremos la atención ahora mismo en ver
cómo impactan en los componentes los diferentes tipos de errores y/o operaciones.
Fallo Estado Componente Alcance fallo Recreación

Todos los componentes
Host en Mantenimiento Absent A partir de los 60 minutos
del Host
Host Absent A partir de los 60 minutos
del Host
Red (Host aislado) Absent A partir de los 60 minutos
del Host
Controladora Degraded Todos los discos del Host Inmediatamente
Disco Caché Degraded Disk Group Inmediatamente
Disco Capacidad (sin
Degraded Componentes en disco Inmediatamente
deduplicación)
Disco Capacidad (con
Degraded Disk Group Inmediatamente
deduplicación)
Tabla comparativa de fallos y estados
Recreación automática a partir de los 60 minutos
El servicio CLOM gestiona lo que se conoce como CLOM repair delay. Cada vez que un componente
está en modo Absent el servicio CLOM da un margen para que el componente se recupere o vuelva a la
vida sin más. Debemos tener en cuenta que hay veces que existen pequeños fallos de comunicación o
bien un reinicio de un Host (controlado o no) hará que un componente esté en modo Absent. Para evitar
la recreación completa del componente y su correspondiente impacto en consumo de recursos, vSAN
gestiona el CLOM repair delay. El valor de ese parámetro son 60 minutos por defecto y confirmamos
que es posible cambiarlo.
En Opciones avanzadas del Cluster es posible modificar el valor de Object Repair Timer
Si pasados los 60 minutos el componente sigue en modo Absent, CLOM se encargará de recrear
automáticamente todos los componentes que hagan falta para mantener los Objetos en modo compliant.
También puede darse el caso que, pasados unos minutos sin llegar a 60, el recurso con el fallo se
recupera. En ese caso tendremos un componente desactualizado y será CLOM quien se encargue de
comenzar con el proceso de actualización o resincronización, también automáticamente.
Absent o Degraded?
Dependerá del tipo de fallo si el estado de un componente es Absent o Degraded. Existen casos de fallos
de Hardware que dejan el disco en Absent cuando en realidad tiene un fallo total. Por otra parte cuando
el Host tiene la certeza de un fallo en un disco o controladora, normalmente pone los componentes en
modo Degraded y es ahí cuando la recreación de los componentes comienza inmediatamente.
Fallo en discos de Caché
El producirse un fallo en un disco de Caché el impacto inmediato es que perderemos el Disk Group
entero. Esto es así debido a que el disco de caché aporta rendimiento y resiliencia en cuanto a
operaciones de escritura.
Existirán casos en que un disco pueda recuperarse y tal vez el Disk Group vuelva a la vida (con los
componentes desactualizados) pero en la gran mayoría de los casos tendremos que reemplazar el
disco y recrear el Disk Group nuevamente.
Fallo en disco de Capacidad sin deduplicación y compresión habilitada
Otro fallo potencial puede producirse en un disco de capacidad. Si la deduplicación y compresión no

está habilitada en el Cluster de vSAN, entonces el fallo únicamente impactará en los componentes que
estuvieran almacenados en el disco en cuestión.
Una vez más, si el Host tiene la certeza del fallo del disco, los componentes pasarán a un estado
Degraded con su correspondiente recreación de componentes de forma inmediata.
Y si el Host desconoce el estado del disco con fallos o bien alguien decide retirar el disco físico para
pasarle un plumero, los componentes pasarán a un estado Absent y comenzará la cuenta regresiva de
los minutos definidos en el CLOM repair delay.
Fallo en disco de Capacidad con deduplicación y compresión habilitada
Si el Host identifica un fallo en un disco de capacidad y el servicio de deduplicación y compresión está

habilitado en el Cluster de vSAN, todo el Disk Group fallará. Esto es así debido a que tanto el disco de
caché como todos los discos de capacidad del Disk Group comparten el mismo hash para trabajar con
la deduplicación y compresión lo cual genera una dependencia de unos con otros.
En caso de pérdida del Disk Group todos los componentes del mismo se recrearán automáticamente.
Evidentemente la recreación dependerá de la existencia de recursos disponibles.
8. Mantenimiento en Clusters de vSAN
Existen múltiples situaciones en que necesitamos poner un Host en modo mantenimiento, reiniciarlo o
incluso mantenerlo apagado durante un período de tiempo determinado.
A partir de que un Host forma parte de un Cluster de vSAN aportando recursos de almacenamiento las
diferentes operaciones que hemos mencionado deben gestionarse con mucho cuidado, incluso con
criterio.
Cambia el concepto y la forma de gestionar ciertas tareas debido a que un Host en modo mantenimiento,
al igual que ocurre con los recursos de cómputo, no proveerá servicios de almacenamiento.
A continuación, aprenderemos las opciones disponibles cuando ponemos un Host en modo

mantenimiento.
En este punto debemos recordar que, si ponemos un Host en modo mantenimiento y no migramos los
datos, aquellos componentes que permanezcan en el Disk Group pasarán a estar en modo Absent, lo
que supone un fallo, aunque se trate de una operación controlada.
Dependerá de las reglas de tolerancia a fallos que una máquina continúe operativa, aún en modo non-
compliant, luego de poner el Host en modo mantenimiento.
Las tres opciones disponibles son:
• Asegurar accesibilidad (Ensure accesibility) -por defecto-
• Migrar todos los datos (Full data migration)
• No migrar datos (No data migration)
Asegurar accesibilidad
Es la opción por defecto cuando ponemos un Host de vSAN en modo mantenimiento.
El Host identificará todos los componentes que pertenezcan a objetos que no podrían continuar
trabajando en caso de poner el Host en modo mantenimiento.
Esos objetos se recrearán en Disk Groups de Hosts diferentes para mantener la diponibilidad, siempre
y cuando existan recursos disponibles en el Cluster siguiendo las reglas de la política aplicada a los
objetos.
Opción asegurar disponibilidad
Esta opción nos permite agilizar la puesta del Host en mantenimiento a costa de asumir el riesgo de
tener objetos de máquinas en modo non-compliant.
En caso que el Host no esté nuevamente operativo pasados 60 minutos, todos los componentes que
estaban en estado Absent se recrearán automáticamente en otros Disk Groups del Cluster.
Migrar todos los datos
Al seleccionar esta opción la totalidad de los componentes serán recreados en los Disk Groups de
otros Hosts. Evidentemente el impacto que genera esta acción dependerá de la cantidad y tamaño de
los componentes, pero seguramente generaremos un impacto considerable en las operaciones de I/O.
Esta opción es la que tenemos que elegir cuando un Host estará más de una hora en modo mantenimiento
o bien cuando retiraremos el Host del Cluster.
Migración completa en Host en mantenimiento
No migrar los datos
Esta última opción la utilizamos normalmente cuando tenemos la total certeza de que todas las
máquinas y sus objetos tienen una política que, al menos, tolerará un fallo. De esta forma todas las
máquinas con sus objetos continuarán estando operativos. Evidentemente esta opción no consumirá
recursos de red ni de disco al no recrear ningún componente.
Al igual que en la opción Asegurar accesibilidad, si no ponemos en producción el Host en menos de

60 minutos, los componentes en estado Absent se recrearán automáticamente en otros Disk Groups
del Cluster.
No migrar los datos en Host en mantenimiento
Debajo de la opción No data migration podremos ver el número de objetos que no continuarán en
modo compliant.
9. Monitorización de vSAN
La gestión del Cluster de vSAN se caracteriza por la simplicidad de su día a día. La creación, edición
y asignación de Políticas es una parte importante en la vida de un Cluster de vSAN, aunque la verdad
es que los cambios en las Políticas no tendrían por qué ser muy frecuentes.
También las operaciones de mantenimiento de los Hosts requieren su atención, así como también
un posible recambio de componentes de Hardware con fallos como pueden ser un disco de Caché,
Capacidad o incluso una controladora.
La monitorización de un Cluster de vSAN es clave para mantener una infraestructura operativa y

minimizar situaciones desagradables que pueden ser evitadas. Además, tener controlada tanto la
capacidad (consumida y disponible) como también el rendimiento es parte del día a día de un buen
administrador de vSphere.
Existen múltiples herramientas que podremos utilizar para monitorizar nuestros Clusters de vSAN las
cuales analizaremos a continuación.
Herramientas disponibles para monitorizar Clusters de vSAN
• vSphere Client
• Ruby vSphere Console
• ESXCLI
• vRealize Operations Manager (vSAN Management Pack)
• vRealize Log Insight (vSAN Content Pack)
• PowerCLI
vSphere Client
Esta herramienta es, sin lugar a dudas, la más apropiada a la hora de monitorizar un Cluster de vSAN.
Gracias al vSAN Health Check seremos capaces de identificar cualquier tipo de fallo sea en el nivel
que sea. Incluso no importa si disponemos del stack completo de VMware en el cual disponemos de
soluciones como vRealize Operations Manager y Log Insight. vSphere nos proporcionará de forma
simple todo lo que necesitamos en un mismo sitio.
La información provista por vSAN Health Check está organizada por capas como son los Objetos, la
Red, el Hardware, etc,
Vista de vSAN Health Check en vSphere Client
Evidentemente la perfección no existe y debemos identificar los límites de este health check. La versión
gráfica opera sobre vCenter, por lo cual tenemos una dependencia con este servicio. La buena noticia
es que seremos capaces de obtener la misma información por línea de comandos e incluso a través
de un único Host, pero esto lo veremos más adelante en ESXCLI.
Tampoco seremos capaces de organizar vistas personalizadas o crear reportes. Ése trabajo se
lo dejamos al especialista vRealize Operations Manager, al igual que con la gestión de Logs no
encontraremos mejor socio que Log Insight.
Por último, cabe destacar que en cada nueva versión de vSAN vemos más y más novedades y mejoras
en el vSAN Health Check.
Ruby vSphere Console
Para los amantes del command line tenemos todo un Ruby vSphere Console que nos proveerá de
información de todos los Clusters de vSAN que tengamos en la instancia de vCenter en que ejecutamos
la herramienta.
Esta utilidad funciona directamente en vCenter por lo cual, al igual que con vSphere Client, tenemos
la dependencia del servicio de vCenter y el límite de los Clusters administrados por la instancia en
cuestión.
Listado de comandos de Ruby vSphere Console
Podremos movernos entre la estructura del inventario y objetos con los simples comandos ls y cd. Esta
herramienta es ideal cuando queremos obtener información de un objeto en particular, aunque también
es posible hacerlo con ESXCLI. Con el fin de simplificar las largas rutas de los objetos es posible crear
marks que son como accesos directos a objetos en particular.
ESXCLI
Cuando se trata de obtener información del Host y del Cluster por línea de comandos encontraremos
a un gran aliado en la familia de comandos ESXCLI VSAN.
Lo primero que debemos destacar es la gran facilidad de uso. Simplemente debemos comenzar tirando
el comando esxcli vsan y veremos las opciones a continuación.
Lista de opciones del esxcli vsan namespace
Existen comandos que aplican únicamente dentro del ámbito de un Host, y también otros como esxcli
vsan cluster get que devuelve información del Host y del Cluster.
Información de Cluster con esxcli vsan cluster get
Lo más interesante de todo esto es que, a través del comando esxcli vsan health cluster list Obtendremos
la misma información que en vSAN Health, incluso si la instancia de vCenter está caída.
vRealize Operations Manager
¿Seríamos capaces de salir a conducir nuestro coche sin indicadores de los niveles de líquidos, ni el
indicador de velocidad ni tampoco el de temperatura? ¿No verdad? “¿Cómo era capaz de trabajar con
mi entorno de vSphere sin vROps?” es lo que se preguntan los administradores que disponen de la
herramienta y, además, aprendieron a utilizarla.
Vista del Dashboard vSAN Capacity Overview
Los Management Packs de vROps nos permiten extender los sistemas a monitorizar agregando
Dashboards, Views, Reports, etc.
Si bien el vSAN Management Pack (gratuito) es decente y provee buena información, al tratarse de
dos de los productos más populares de VMware se podría haber trabajado con algo más de alegría
aportando más heatmaps y jugando con métricas clave.
vSAN Operations Overview en vROps
Algo a destacar es que utilizando vRealize Operations Manager el alcance de la monitorización no

se limita a un vCenter sino a todas las instancias que tengamos configuradas en los adaptadores.
Por lo tanto, seremos capaces de tener vistas de absolutamente todos los Clusters de vSAN de la
organización. ¿No está mal verdad?
vRealize Log Insight
Cuando se trata de almacenar, indexar y gestionar Logs en un Datacenter no hay dudas que el producto
debe ser de primer nivel. Más que nada debido a que cuando necesitamos trabajar con Logs es que,
generalmente, buscamos resolver un problema y no queremos que la propia herramienta sea otro
problema en sí misma.
Los Content Pack de Log Insight identifican los Logs clave y proveen Dashboards con los indicadores
más importantes y de forma gráfica.
Dashboards de vSAN en Log Insight
Ya sean problemas de hardware, rendimiento o algún objeto lógico de vSAN será tremendamente fácil
trabajar con los Logs de todos los Hosts del Cluster.
Y por último destacar que, al igual que con vROps, Log Insight nos permitirá gestionar los Logs de forma
centralizada de múltiples instancias de Clusters de vSAN ya sea del mismo vCenter o de múltiples
vCenters sin importar la ubicación física de los Datacenters.
PowerCLI
Otra versátil herramienta de línea de comandos que crece de forma exponencial en cada nueva
versión. A la hora de obtener información del estado de configuración u operativo de un Cluster de
vSAN también seremos capaces de utilizar PowerCLI. Especialmente para los administradores con
una buena base de Powershell.
Lista de comandos Get-vSAN en PowerCLI
Si ya de por sí el potencial que ofrece PowerCLI es inmenso, no olvidemos que podemos integrar
vRealize Orchestrator con vCenter, y agregar un Endpoint de PowerCLI en vRO. Esto nos permitiría
utilizar un botón contextual a nivel de Cluster de vSAN con una opción para que nos envíe determinada
información por mail sin movernos del entorno gráfico. ¿Interesante verdad?
10. Top 10 comandos vSAN
En este pequeño apartado destacaremos los 10 comandos más útiles para tener a mano a la hora de
necesitar información y resolver problemas en nuestros Clusters de vSAN.
La gran mayoría de la información que obtendremos con los comandos que veremos a continuación
también la tenemos disponible en el vSAN Health. No obstante, existen muchas situaciones en las
cuales necesitaremos utilizar línea de comandos por lo que mejor estar preparado.
Algunos comandos pertenecen al espacio de nombres ESXCLI VSAN y otros son comandos de Ruby
vSphere Console.
1. esxcli vsan cluster get
Este simple comando nos ayuda a identificar si hay algún host que, debido a un fallo como una partición
de red, no está operativo en el Cluster de vSAN.
Revisando el estado del Host y del Cluster
2. vsan.whatif_host_failures -s ~cluster
A través de la consola de Ruby podemos comprobar con este comando qué ocurriría si el Host con
mayor cantidad de almacenamiento ocupado tuviera una caída.
En el resultado esperamos ver que no tendremos problemas de capacidad, ni que el límite máximo de
objetos esté comprometido y que los objetos continuarán activos a pesar del fallo.
Verificando la disponibilidad de recursos
3. esxcli vsan health cluster list
Mencionamos varias veces que el vSAN Health es el mejor recurso, con diferencia, para obtener
información de qué es lo que está ocurriendo en el Cluster.
La limitación es que dependemos de vCenter, esto es así debido a que visualizamos vSAN Health en
el vSphere Client.
Con este comando podemos ver exactamente lo mismo que en el vSAN Health pero desde la línea de
comandos de un Host. Incluso funcionará con el servicio de vCenter no operativo.
vSAN Health en línea de comandos
4. vsan.vm_object_info ~vm
Este comando de Ruby vSphere Console nos entrega información detallada de un objeto en concreto.
Tendremos acceso a información como el estado de salud, la política que se le aplica, el número de
componentes y sus correspondientes estados.
5. esxcli vsan debug object health summary get
Pocos comandos serán tan útiles como este a la hora de necesitar obtener información del estado de
salud de todos los objetos.
El objetivo es ver la totalidad de objetos en modo healthy y el resto de los estados en 0.
Visualizando el estado de los objetos
6. vsan.cluster_info ~cluster
Este simple comando nos entrega información detallada de cada uno de los Hosts con sus
correspondientes estados y la información de sus recursos de almacenamiento.
Es un gran resumen que en más de una vez nos ayudará a identificar algún problema.
Resumen de Hosts, Cluster y Almacenamiento
7. esxcli vsan debug resync summary get
Una buena práctica antes de poner un Host en modo mantenimiento es verificar si hay operaciones de
recreación o resincronización de componentes.
Este comando será nuestro mejor amigo a la hora de verificar, a través de línea de comandos, si
existen ese tipo de operaciones en el Cluster.
Confirmando operaciones de resincronización
8. esxcli vsan debug vmdk list
Otro de los comandos infaltables para situaciones incómodas. Este comando nos entregará la lista de
los objetos de discos virtuales, incluyendo ficheros swap, que pertenecen a las máquinas virtuales.
Seremos capaces de ver la ruta, la carpeta (para identificar a qué VM pertenece el objeto) y también
el estado de salud.
Verificando el estado de salud de objetos vmdk
9. esxcli vsan debug disk overview
No debe existir una forma más simple de listar todos los discos físicos, de capacidad y caché, de todos
los Hosts del Cluster junto con su estado de salud.
No solamente veremos los discos, sino que también veremos la capacidad total y el espacio utilizado.
Listado de discos físicos del Cluster
10. esxcli vsan debug evacuation precheck -e localhost
Otra forma de verificar qué ocurriría en el hipotético caso de puesta en mantenimiento o fallo de un
Host.
En este caso el comando realiza el análisis del Host local en el que estamos ejecutando el comando y
nos indica el resultado de cada una de las operaciones que podemos seleccionar al poner un Host en
modo mantenimiento.
Analisis precheck antes de poner un Host en mantenimiento
11. Resumen de buenas prácticas en vSAN
¿Qué mejor manera de cerrar el capítulo de vSAN que con un resumen de las mejores prácticas?
Evidentemente se podría escribir mucho más sobre las buenas prácticas y su correspondiente detalle
e incluso de vSAN en general, pero al fin y al cabo éste no es un libro de vSAN, sino tan solo un
capítulo llamado “vSAN” dentro de un libro de SDDC de VMware.
Quién sabe si al final nos animamos y escribimos un libro enterito de vSAN, como corresponde, en
Español… ;-)
Buenas prácticas en vSAN:
• 2 o más Disk Groups por Host
• 2 o más Controladoras de disco por Host
• QoS y Jumbo frames en la red de vSAN
• LACP (si está previamente configurado en la red). Alinear la configuración del switch físico con la
política LACP en el Virtual Switch Distribuido
• 1 Cluster de vSAN, 1 VMKernel, 1 vLan
• Utilizar controladoras de disco en modo Passthrough
• Configurar el Caché de las controladoras de disco en 100% para lectura
• ¿Compartimos vmnics? Utilizar NIOC en vDS. Configurar valores altos de Shares para el tráfico de
vSAN. Considerar definir una reserva para vSAN
• Alinear los discos de Caché, el Endurance y la Capacidad en base a las cargas de trabajo esperadas
(Escritura, Lectura o uso Mixto intensivo)
• Desplegar Hosts con configuración homogénea (CPU, RAM, Red y Discos)
• Setear la BIOS para permitir que la gestión de la alimentación del Host sea controlada por el
sistema operativo (el ESXi)
• Utilizar múltiples Políticas de vSAN según los requerimientos
• Verificar que las controladoras provean un valor alto de queue depth para mejorar el rendimiento
• Considerar el uso de dispositivos NVMe y/o Intel Optane para alto rendimiento
• Considerar la implementación de vmnics de 25Gbps en la red de vSAN
ADISTEC VSAN READY NODE
Adistec presenta su solución de

vSAN Ready Node validada por VMware.
Modelos pre-conﬁgurados por nuestro equipo de Ingeniería en conjunto con Intel y VMware
utilizando como base la última Arquitectura de procesadores Intel Xeon Scalable (Purley)
y VMware VSAN 6.7.
Buscamos entregar una solución llave en mano que ayudará a sus clientes a modernizar sus
recursos de cómputo y almacenamiento, utilizando tecnología Hiperconvergente con VMware
VSAN. Disponibles en dos modelos: All Flash e Híbrido, lo que le permite cubrir una amplia
gama de necesidades y diferentes
tipos de cargas de trabajo.
Ayude a sus clientes a migrar a un modelo de Software Deﬁned Storage (SDS) usando la última
tecnología de Intel y VMware, sumado a la experiencia de Adistec.
www.adistec.com
Capítulo 8
Alta Disponibilidad
Capítulo 8 - Alta Disponibilidad Leandro Ariel Leonhardt
1. Introducción a vSphere HA
Unas de las funcionalidades “estrella” de VMware es la vSphere HA (alta disponibilidad). La mayoría

de las empresas disponen de servicios críticos, servidores de nóminas, servidores web, servidores de
ficheros/impresión, servidores de bases de datos, etc. cuya parada no programada, ocasiona pérdidas
a la compañía.
VMware vSphere permite reducir tiempos de inactividad, por que proporciona niveles de protección en
todos los niveles, por ejemplo, a nivel de componente (hardware), dotando de alta disponibilidad a la
red con teaming de tarjetas o múltiples rutas de adaptadores de entrada y salida, a nivel de servidor/
sistema con VMware HA, migraciones de máquinas virtuales en caliente con vMotion, Storage vMotion
y Storage DRS (Distributed Resource Scheduler) para el almacenamiento, replicación a nivel de datos
(máquinas virtuales), vSphere Replication o VMware vSphere SRM (Site Recovery Manager) para
recuperación ante un desastre.
vSphere HA utiliza varios hosts ESXi de un clúster vSphere para proteger a las máquinas virtuales,
proporciona una rápida recuperación de las interrupciones, sea por un fallo de hardware o del sistema.
Los niveles de protección de HA se basan en estos cuatro principios:
• Protección cuando falla un hosts ESXi: vSphere HA reinicia automáticamente las máquinas
virtuales en otro host del clúster.
• Protege de fallos de acceso al almacenamiento: permite la recuperación automatizada de

las máquinas virtuales afectadas. Con la protección de componentes de las máquinas virtuales
(VMCP), las máquinas virtuales afectadas se reinician en otros hosts que siguen teniendo acceso
al almacenamiento.
• Protege de los fallos de en las aplicaciones: supervisa con un software específico, las aplicaciones
que corren en la máquina virtuales, si se detecta un problema o parada de servicio, realiza una
acción (reinicio del servicio, reinicio de la máquina virtual), etc.
• Protección de las máquinas virtuales en caso de aislamiento de red: en caso de aislamiento

de la red de gestión del host o red vSAN, junto a la perdida del almacenamiento, HA reinicia las
máquinas virtuales en otros hosts del Clúster.
2. Componentes de vSphere HA
Para entender el funcionamiento de vSphere HA, es importante conocer su arquitectura. La arquitectura

de vSphere HA está compuesta por tres componentes fundamentales:
• FDM
• HOSTD
• vCenter
El primero y probablemente el componente más importante es el denominado FDM (Fault Domain

Manager), más comúnmente llamado, “agente HA”.
El agente FDM es encargado de muchas tareas, como la comunicación de los recursos de los hosts,
estado de las máquinas virtuales “protegidas/no protegidas” y la comunicación de los demás agentes
FDM de los hosts que forman el Clúster. Este agente también gestiona el mecanismo de heartbeat,
ubicación de las máquinas virtuales, reinicio de las máquinas virtuales, etc.
vSphere HA está compuesto por un único Log, lo que permite realizar un troubleshooting más simple y
rápido, toda la información respecto a vSphere HA se almacena en un fichero llamando fmd.log (/var/
log/fdm.log)
HOSTD Agent
El agente FDM habla directamente con el agente HOSTD y vCenter. El agente HOSTD es responsable
de otras muchas tareas, como del encendido de las máquinas virtuales (powering on). Si este agente
tiene algún problema, no participará de ningún proceso de HA. El agente FDM se basa de la información
que le brinda el agente HOSTD acerca de las máquinas virtuales registradas en los hosts, y, gestiona
a las máquinas virtuales usando las APIs del agente HOSTD.
En resumidas cuentas, el agente FDM depende del agente HOSTD y si el HOSTD no está operativo,
FDM detiene todas las funciones y se espera a que el HOSTD esté nuevamente operativo.
vCenter
vCenter es el core de un Clúster vSphere, responsable de:
• Desplegar y configurar los agentes de HA
• La comunicación de los cambios del Clúster
• Protección de las máquinas virtuales
vCenter es responsable de “empujar” el agente FDM hacia el ESXi cuando corresponda. También
es responsable de la comunicación de los cambios de configuración en el Clúster cuando un host es
elegido como “Master”. Trataremos el concepto de “master/slave” más adelante.
El algoritmo de HA de VMware aprovecha de vCenter para recuperar información del Clúster y del
estado de las máquinas virtuales, mostrando un icono “protegido” junto a cada máquina virtual.
Si vCenter Server no está disponible, el Clúster de vSphere HA funcionaría igualmente y ante un

de fallo de hardware, en el host, los agentes FDM reiniciarían las máquinas virtuales en otros hosts
disponibles, en ese caso, vCenter no se daría cuenta de los cambios del Clúster hasta no volver a un
estado normal.
vCenter Server también permite configurar prioridades de reinicios, es preferible que primero se levanten
las máquinas más críticas y seguidamente las menos críticas, esto también va a asegurarnos que en
caso de que no haya recursos suficientes pare encender todas las máquinas virtuales afectadas, que
las más críticas puedan encenderse, esto es una configura-ción manual que realiza el administrador
de la infraestructura.
3. Conceptos Fundamentales
Para profundizar más el funcionamiento de alta disponibilidad en vSphere, debemos de centrarnos en

los conceptos fundamentales para comprender:
• Master / Slave
• Heartbeating
• Red aislada vs red particionada
• Protección de máquina virtual
• Protección de componentes
Hablemos del Master y Slave
Cuando se habilita HA en un Clúster vSphere, vCenter se encarga de desplegar los agentes FDM en
cada host que forman un Clúster, de todos los hosts, uno es considerado “Master” y los demás son
denominado “Slave”.
Para determinar que host será el Master (principal), el sistema, de manera automática, determina que
host tiene más acceso a los Datastores (LUNs), si uno de los host tiene presentado más Datastores
que los demás, entonces ese host es denominado “Master”.
En la mayoría de los entornos, todos los hosts miembros de un Clúster tienen acceso a la misma
cantidad de Datastores, por lo que es difícil decir quién será denominado Master, en esa situación,
entra un segundo mecanismo basado en objeto que se hace llamar “MOID” (Manage Objet ID), basado
en el ID de un host.
Para que entendáis bien en qué consiste el MOID, pondré un ejemplo:
Imaginad que un host recibe aleatoriamente el ID host-99 y otro recibe el host-100, en ese caso, el
Master será el host-99 por qué el primer número “host-99” es mayor que el “host-100”. Si los primeros
números ID coinciden con el número 9, entonces se procede a comparar con el segundo, el mayor será
elegido como Master, Ej: “host-99” y “host-97”, en este caso, se comparan nos números de la segunda
posición, el “host-99” será el master debido a que 9 es mayor que 7.
Ese proceso de elección de “Master” dura 15 segundos mas o menos, y se inicia cuando se da algunas
de estar circunstancias:
• Se activa vSphere HA en un Clúster
• El host principal (Master) detecta un fallo del sistema debido a uno de los siguientes factores:
– El host “principal” se pone en modo de mantenimiento.
– vSphere HA se ha reconfigurado.
• Los hosts esclavos no pueden comunicarse con el host principal debido a un problema de red.
La comunicación de los hosts y vCenter se realiza por la red de gestión “Management Net-work” y la
función del host “principal” es informar a vCenter Server del estado del Clúster, de los agentes FDM de
cada host, de la disponibilidad de las máquinas virtuales y del estado / informes del Clúster.
vCenter Server indica al agente de vSphere HA las máquinas virtuales que debe proteger, el agente
conoce los cambios de estado a través del agente HOSTD y vCenter Server se informa de eso a través
del proceso vpxa.
El host principal supervisa el estado de los hosts esclavos y en caso de fallo, en algún host esclavo, el
host principal se hace cargo de “arrancar” las máquinas virtuales en el host principal, es recomendado
activar DRS para un equilibrio de carga en los hosts.
Cuando se activa HA a nivel de Clúster, vCenter empuja los agentes a cada ESXi, pero además,
algunos Datastores compartidos son elegidos como mecanismo de heartbeat, en un datastore VMFS,
se crea una carpeta oculta llamada vSphere-HA, dentro existe un fichero (protectedlist) legible sólo
para el agente FDM con un listado de todas las máquinas protegidas en los host ESXi.
Para un volumen NFS, existe un archivo de bloqueo.
Los hosts esclavos supervisan el estado de las máquinas virtuales que se ejecutan localmente y envían
los cambios de estado al host principal. También supervisan el estado del host principal.
vSphere HA se configura, se gestiona y se supervisa por medio de vCenter Server. El proceso vpxd
que corre dentro de vCenter Server, se encarga de mantener los datos de configuración del clúster, así
como de informar al agente maestro de los cambios en la configuración del clúster.
Cualquier cambio a nivel de Clúster, el maestro informa a los “esclavos” para que se guarden una copia
de la configuración en local.
Las máquinas virtuales de un Clúster con HA quedan automáticamente protegidas cuando encienden.
El Master consulta el estado de los hosts por la red de gestión, el Master es el único que envía
heartbeating (latidos de corazón) por las dos tarjetas de red físicas, los “slaves” solo envían heartbeating
por una de ellas, en el caso de que falle, enviarán por la otra.
Si el host esclavo no responde durante el periodo de tiempo predefinido, el host principal lo declara
como inaccesible, que puede ser parcial (solo si pierde el acceso a la red) o total, si tampoco se llega
al almacenamiento de ese host.
vSphere HA intenta reiniciar las máquinas virtuales solamente en una de las siguientes situaciones:
• Ha fallado un host (no hay heartbeat de red, ni ping, ni heartbeat de datastore).
• Un host ha quedado aislado y la respuesta al aislamiento del host configurado en el clúster es

Power off o Shut down (estas opciones las define el administrador a nivel de Clúster).
3.1 Escenarios de fallos para vSphere High Availability:
• Fallo de un host Master
• Fallo del host Slave
• Fallo de la red (aislamiento de hosts)
• Fallo de acceso al Storage:
• Protección de componentes de la máquina virtual (VMCP)
- All Paths Down (APD, todos los accesos perdidos al almacenamiento)
- Permanent Device Lost (PDL, Pérdida permanente de dispositivo).
3.2 ¿Qué sucede cuando falla un host Master/principal?
Puede ocurrir que el host tenga un fallo de hardware o que el administrador de la infraestructura ponga
el host en modo mantenimiento, en ese caso, los agentes FDM de los Slaves hablan entre ellos para
elegir un nuevo Master, el proceso dura unos15 segundos aproximadamente y se tienen en cuenta las
dos consideraciones que mencionamos, el host que más datastore vea, ese es el candidato a ser el
nuevo Master, si no, mediante el ID de los hosts (MOID).
El nuevo host principal lee el fichero “protectedlist” de cada datastore heartbeat y determina cuáles de
ellas están protegidas por vSphere HA y deben reiniciarse (power on - si fue por fallo de hardware).
El agente HA activa un proceso antes de declarar que un host está aislado. “s” corresponde a segundos:
T0s - Aislamiento del host (master)
T0s - El master intenta hacer ping a su dirección de aislamiento
T5s - El master se declara el mismo como “aislado”
T25s - El maestro “desencadena” la respuesta de aislamiento (Response for Host Isolation)
Los esclavos declaran un nuevo “Master”
3.3 ¿Qué sucede cuando falla un host Slave/esclavo?
El Master debe averiguar si el fallo del host Slave es parcial o total, recordar que un host está
parcialmente afectado sólo cuando no emite heartbeat por la red de gestión o no llega a sus direcciones
de aislamiento (configuración avanzada en Clúster). En ese caso, se tomará la decisión que establezca
el administrador.
Si el master no llega a hacer ping a la gestión del host, ni tampoco recibe heartbeat de datastore,
entonces el Master lo “declara” como fallo total y se procede al reinicio de todas las máquinas virtuales.
El agente HA activa un proceso antes de declarar que un host está aislado. “s” corresponde a segundos:
T0s - No llega a su dirección de aislamiento: Aislamiento del host (esclavo)
T10s - El esclavo entra en “estado de elección”
T25s - El esclavo se elige el mismo como maestro
T25s - El esclavo hace ping a su gateway “direcciones de aislamiento”
T30s - El esclavo se declara aislado
T60s - El esclavo “desencadena” la respuesta de aislamiento (Response for Host Isolation)
3.4 ¿Qué sucede cuando falla una aplicación?
Para poder “supervisar” aplicaciones, el requisito fundamental es que estén las VMware Tools
ejecutándose en la máquina virtual, de esa manera, cuando una aplicación falla, VMware puede
realizar acciones previamente configuradas por el administrador de la plataforma, por ejemplo, intentar
levantar el servicio equis veces, reiniciar la máquina virtual (en el mismo host), enviar una notificación,
etc.
La supervisión de aplicaciones requiere un agente de supervisión de terceros diseñado especialmente

para esta tarea, entre los mas conocidos/utilizados, el de Symantec.
4. Protección de una máquina virtual (VMCP)
En vSphere 6.0 se introduce una nueva característica como parte de vSphere HA llamada VM Component
Protection (VMCP). Esta característica protege las máquinas virtuales de los eventos relacionados con
el almacenamiento, específicamente en los incidentes de pérdida de dispositivo permanente (PDL) y
All Paths Down (APD).
Seguramente si has sufrido un problema de almacenamiento (poco frecuentes) antes de vSphere 6,

habrás notado que las máquinas virtuales se quedaban como “inaccesibles”, no respondían, era muy
complicado gestionar esa situación, ni desde las líneas de comandos (esxcli).
Los problemas de conectividad vienen provocados por:
• Fallo de la red o Switch
• Mala configuración del almacenamiento
• Corte eléctrico
Cuando se produce un fallo de accesibilidad al almacenamiento, el host ESXi afectado deja de poder
acceder, vSphere HA responde a un fallo de este tipo, que puede generar una alarma de envero o
hasta el reinicio de la máquina virtual a otro host.
Por defecto, APD se espera 140 segundos cuando se pierden todos los caminos al Datastore, VMCP
esperará un período de tiempo adicional antes de tomar medidas contra las máquinas virtuales
afectadas. El período de espera es de 3 minutos. En otras palabras, VMCP esperará 5m: 20s antes
de actuar contra las máquinas virtuales. La suma del tiempo de espera de APD y el retraso para la
conmutación por error de VM también se conoce como tiempo de espera de VMCP.
Esta característica (VMCP) sólo está disponible para Clústers con vSphere 6.0 o superior.
5. Opciones de un clúster HA
5.1 Features and Responses
En este apartado tenemos el check de “Enable Host Monitoring”, en el caso de realizar un

mantenimiento sobre los switches de gestión, es posible evitar situaciones de “aislamiento” de host,
deshabilitando esa característica.
¿Qué hace vSphere HA cuando falla un host (Host Failure Response) Restart VMs o Disable?
Si falla un servidor ESXi, lo lógico es que haga una conmutación, para que todas las máquinas virtuales
que corrían en ese host, se reinicien (Restart VMs) en el resto de hosts del clúster. La opción “Disable”
se utiliza para cuando aplicaciones que corren dentro de las máquinas virtuales están licenciadas por
host físico (poco común), por lo tanto, si falla el host, aunque la máquina virtual se reinicie en otro host,
no funcionará por la que licencia es por host físico.
Por defecto, todas máquinas virtuales del clúster HA tienen como prioridad “Medium”, es recomendado
identificar cuáles son los servidores más críticos de nuestra infraestructura, la prioridad que
establezcamos sobre la máquina (High, Medium o Low) decide que máquinas virtuales se encenderán
primero, el “Power on” se hace de manera secuencial y en bloques de máquinas virtuales. Se puede
dar el caso que máquinas virtuales con prioridad baja no se enciendan por qué no hay recursos
suficientes en el clúster.
¿Qué hace vSphere HA cuando se produce aislamiento de host (Response for Host Isolation)
Disable, Power off and restart VMs o Shutdown and restart VMs?
Al existir un segundo mecanismo (heartbeat de datastore), una buena práctica es que vSphere HA no
haga nada, puesto que sólo se ha perdido la red de gestión, las máquinas virtuales tienen acceso al
resto de la red y al almacenamiento.
En un Clúster de vSphere HA con vSAN, se recomienda “Power off and restart VMs”, porque el
heartbeating se ejecuta por la red de vSAN.
¿Qué hace vSphere HA cuando se produce Datastore with PDL o Datastore with APD?
También conocido como VMCP, VMware recomienda para estos casos, hacer un “Power off and restart
VMs” (con agresividad conservativa o agresiva), puesto que sí perdemos el almacenamiento, las
máquinas virtuales sufren un crash.
¿Qué hace vSphere HA cuando falla una aplicación (VM Monitoring) Disable, VM Monitoring Only, VM
and Application Monitoring?
He visto muchos clústers con la opción por defecto (Disable), sin embargo, a mí me gusta la opción de
reiniciar, si una máquina virtual se “cuelga”, no estará dando servicio de ninguna manera.
Imaginad que un sistema Windows o Linux se cuelga, VMware HA (agente FDM y HOSTD) no reciben
heartbeat de esa máquina virtual por las VMware Tools (requisito para esta característica), tampoco
observa actividad en disco, en esa situación, considera que esa máquina virtual está colgada y realiza
una acción, no hacer nada (Disable), o reiniciar (VM Monitoring Only).
Es muy importante que sepáis que, antes de reiniciar, VMware saca una captura de pantalla con el
error y lo deja dentro de la carpeta de la máquina virtual con el nombre de la máquina virtual .png, por
esa razón prefiero configurar que la máquina virtual se reinicie.
Para la opción de “VM and Application Monitoring”, sólo funcionará si se integra con una herramienta
adicionar/externa como ya comentamos en otra sección.
5.2 Admission control
El control de admisión es una política utilizada por vSphere HA para garantizar la capacidad de
conmutación por error dentro de un clúster. Cuanto más restrictivos seamos, menos máquinas virtuales
pondrá correr dentro del clúster.
Como consultor, he visto muchos entornos con “Admission Control” deshabitado, para así poder correr
más máquinas de lo que realmente se puede garantizar encender en caso de haber un fallo en el host.
Es decir, cuando Admission Control está deshabitado, el algoritmo de HA no calcula si hay suficientes
recursos para todas las máquinas del clúster, sin embargo, si está habilitado, vSphere HA calcula y te
garantiza que, ante un evento de conmutación, todas las máquinas virtuales harán un Power on.
5.3 Heartbeat datastore
VMware recomienda tener al menos dos Datastore para ello, aunque podemos seleccionar manualmente
los Datastores que nosotros queramos.
Automatically select datastores accessible from the hosts: (Opción por defecto), VMware escoge
aleatoriamente y los “marca” como datastores de heartbeat.
Use datastores only from the specified list: El administrator de la plataforma elige manualmente cuáles
se usarán.
Use datastores from the specified list and complement automatically if needed: El administrator de la
plataforma elige manualmente cuál se usará como heartbeat, VMware HA podrá marcar otro más en
caso de necesitar.
5.4 Advanced options
Podemos configurar opciones avanzadas que afectan el comportamiento de un clúster de vSphere HA,
como añadir más de una dirección de aislamiento, un máximo de 10, (das.isolationaddress), Ejemplo;
das.isolationaddress1 = xxx.xxx.xxx.xxx das.isolationaddress2 = xxx.xxx.xxx.xxx esta condición va
acompañada de das.usedefaultisolationaddress = false para que no usar una única dirección como
heartbeat.
También, si sólo tenemos un único datastore en el clúster, veremos un Warning que se requiere
al menos dos, se puede “forzar” que solo tengamos uno ignorando esa advertencia con (das.
ignoreInsufficientHbDatastore = True)
Son solo algunos ejemplos, pero existen muchas opciones avanzadas, configurable según la necesidad
y servicios del cliente.
6. Monitorización de vSphere HA
La vista “SUMMARY” se encuentra en Clúster / Monitor / vSphere HA, en este apartado tenemos el
Summary, que nos permite conocer el estado general del Clúster, quién es el Master, host conectados
al master, agentes vSphere con problemas, host con fallos, problemas de Network (management),
máquinas virtuales protegidas o no, etc. Esta vista nos aporta una visión global por Clúster y resulta
muy útil para los administradores de la infraestructura.
En Heartbeat podemos observar él o los datastores que están haciendo de Heartbeat, como buena
práctica, VMware recomienda al menos tener dos.
Si existe alguna mala configuración, podemos verlo en “Configuration Issue”, por ejemplo, unos de los
datastores que hacen de Hearbeat no es visible por todos los nodos del Clúster.
Para situación APD o PDL, tenemos un apartado específico para ello, “Datastore under APD or PDL”.
7. Proactive HA
Con la llega de la versión de vSphere 6.5, VMware introdujo una nueva característica, VMware HA
ahora también detecta condiciones de hardware en los ESXi y permite evacuar las máquinas virtuales
antes de que se produzca un problema de hardware, evitando interrupciones en las máquinas virtuales
gracias a esta funcionalidad. Proactive HA trabaja en conjunto con los proveedores monitorizando el
estado de salud de los componentes de hardware como la memoria, los ventiladores y las fuentes de
alimentación.
Esta función, evita de forma proactiva el tiempo de inactividad de la máquina virtual al detectar posible
fallos en algún componente de hardware y según la configuración que realicemos, el host ESXi se
pondrá en modo cuarentena (equilibra el rendimiento y la disponibilidad, evitando el uso del host
parcialmente degradado siempre que el rendimiento de la máquina virtual no se vea afectado) o, en
modo mantenimiento (asegurándose de la evacuación total de máquinas virtuales en ese host).
DRS debe estar habilitado en el clúster para hacer uso de Proactive HA.
Proactive HA puede responder a diferente tipo de fallos, actualmente hay cinco eventos:
• Memoria
• Storage
• Network
• Ventiladores (Fan)
• Fuente de alimentación
7.1 Configuración de Proactive HA
Nos posicionamos sobre el Clúster / Configure / Services / vSphere HA
En primer lugar, debemos de habilitarlo:
En este apartado podemos configurar el nivel de automatización y remediación.
En “Automation Level” existen dos modos, el modo manual y el modo automático:
• Manual: vCenter Server sugerirá las recomendaciones de migración para máquinas virtuales en el
host “degradado”, pero la migración de máquinas es realizada por el administrador.
• Automatizado: las máquinas virtuales se migrarán de forma automática a otro host saludable y el
host degradado ingresará según la acción de remediación seleccionada (cuarentena o en modo
mantenimiento).
En el apartado “Remediation” encontramos tres niveles, mixto, modo cuarentena o modo mantenimiento:
La selección del “modo de cuarentena” o de “mantenimiento” aplicará la misma respuesta para fallas
moderadas y graves. La selección del modo “mixto” aplicará el modo de cuarentena para moderados
y el modo de mantenimiento para fallos graves.
Por último, en “Providers” se pueden añadir campos de fallos específicos del proveedor de hardware.
Si queremos que las máquinas virtuales se migren automáticamente (evacuar el host) ante una alerta
de hardware detectado a través de los sensores de hardware, debemos de:
1. Habilitar Proactive HA
2. Establecer “Automated” en el apartado de Automation Level
3. Habilitar vSphere HA y DRS
8. Buenas prácticas/consideraciones de diseño
Para evitar aislamientos de hosts, es recomendado:
• Implementar redes de heartbeat redundantes (dos tarjetas de red físicas conectado al mismo
vSwitch de gestión (red de management) o Port Group para vSwitch Distribuido.
• Implementar direcciones de aislamiento redundantes (Advanced Options - das.isolationaddress).
En caso de producirse aislamiento de host, un buen diseño (teaming de tarjetas de red de gestión, más
de una dirección de aislamiento, etc) permite a vSphere HA determinar si el host aislado sigue activo
o no.
Un máximo de 64 host por clúster HA y hasta 8000 máquinas virtuales por clúster/máquinas protegidas.
A nivel de almacenamiento, un datastore por FC para que el mecanismo de heartbeating sea

independiente a la red de gestión, para iSCSI, separar físicamente la red de almacenamiento de la red
de gestión (un vSwitch independiente, así como el VMkernel).
Si trabajamos con un clúster vSAN + HA, configurar la acción de “Power off and restart VMs” cuando
se produce un evento de aislamiento de host, porque el heartbeating se ejecuta por la red de vSAN.
9. DRS - Distributed Resource Scheduler
Distributed Resource Scheduler es una funcionalidad de VMware, controlada y gestionada desde el

vCenter Server, es como el cerebro de una infraestructura virtual, tiene la capacidad de balancear las
cargas de trabajo para evitar que un host se vea saturado ya sea por demanda de CPU, memoria o
red.
DRS se habilita a nivel de clúster, necesita que la red de vMotion esté configurado en todos los hosts
que forman el clúster para poder “migrar” máquinas virtuales y equilibrar las cargas de todos los hosts,
para ello, los hosts deben tener almacenamiento compartido, DRS es compatible con VMFS, NFS,
vSAN y VVOL.
DRS tiene en cuenta la saturación en la red, es decir, antes de migrar una máquina virtual a un host,
también observa el tráfico de red para balancear la carga de CPU y RAM del clúster, si un host está
saturado a nivel de red, las máquinas virtuales se migrarán a otros hosts del clúster.
9.1 Configuración de vSphere DRS: Nivel de automatización
Cómo se puede apreciar en la imagen, tenemos diferentes apartados para configurar: DRS Automation,
Additional Options, Power Management y Advanced Options.
A nivel de automatización, tenemos tres niveles:
• Manual: cuando DRS se encuentra en modo manual, DRS va a recomendar migrar máquinas
virtuales para equilibrar la carga, pero NUNCA migrará de manera automática, ese movimiento
tendrá que hacerlo el administrador. Si encendemos una máquina virtual, DRS muestra una lista
de host del cluster para que elijamos en que servidor encender la VM.
• Partially automated: cuando DRS se encuentra en modo parcialmente automatizado, DRS va a

recomendar migrar máquinas virtuales para equilibrar la carga, pero NUNCA migrará de manera
automática, ese movimiento tendrá que hacerlo el administrador, la diferencia con respecto al
nivel de automatización “Manual” radica en la ubicación de la VM de manera automática cuando
encendemos, reubicándola en el host con menos “carga”.
• Fully automated: cuando un clúster está pasando por mementos de estrés, DRS migrará las
máquinas virtuales de manera automática y sin intervención del administrador para balancear la
carga del entorno y evitar problemas de rendimiento, a demás, si se encienden máquinas virtuales,
automáticamente los reubicará en los hosts con menos carga.
Estos niveles de automatización tienen diferentes niveles de “agresividad” (Migration Threshold),

siendo el nivel 1 el más “moderado” y el nivel 5 el más “agresivo”:
• Nivel 1: vCenter Server solo aplica las recomendaciones necesarias para satisfacer las limitaciones
del clúster, como las reglas de afinidad y al establecer el host en modo mantenimiento.
• Nivel 2: vCenter Server aplica las recomendaciones que pueden suponer una mejora importante en
el equilibrio de carga del clúster.
• Nivel 3 (predeterminado): vCenter Server aplica las recomendaciones que pueden suponer una
mejora perceptible en el equilibrio de carga del clúster.
• Nivel 4: vCenter Server aplica las recomendaciones que pueden suponer incluso una mejora
moderada en el equilibrio de carga del clúster.
• Nivel 5: aplica todas las recomendaciones. vCenter Server aplica las recomendaciones que pueden
suponer la más ligera mejora en el equilibrio de carga del clúster.
Un nivel muy agresivo podría suponer muchos movimientos de vMotion, algunas aplicaciones son
susceptibles a migrar y muchos movimientos de máquinas virtuales, podrían afectar la red, por defecto,
VMware recomienda el nivel 3, el predeterminado.
VMware incorporó “Predective DRS”, que hace que sea más inteligente, porque se integra con
vRealize Operations Manager (vROPS), vROPS realiza cálculos nocturnos de algoritmos específicos
para balancear la carga de trabajo antes de que el entorno o las máquinas virtuales se vean afectadas.
9.2 Configuración de clúster DRS: automatización a nivel de VM
La configuración de DRS es a nivel de clúster, pero es posible “sobre-escribir” la configuración a

nivel de máquina virtual, y tiene todo su sentido, por que tal como mencioné un poco más arriba,
hay aplicaciones que son sensibles a migrarse con vMotion o que simplemente, el fabricante de la
aplicación no valide el soporte a vMotion (Oracle Mildelware, F5), etc.
Para sobre-escribir la configuración a nivel de máquina virtual, seleccionamos el clúster —> Configure
—> VM Overrides, en ejemplo de la imagen, el clúster está en modo modo manual (no se aprecia en
esta imagen) pero la máquina virtual está en “Partially Automated”.
9.3 Configuración de clúster DRS: afinidad de la máquina virtual
Esta opción hace referencia a VM/Host Rules, para poder aplicar afinidad o anti afinidad de máquinas
virtuales, por ejemplo, imaginad que tenéis dos servidores DNS corriendo en un clúster, y sin darnos
cuenta, ambos servidores DNS corren en el mismo host, si ese host tiene un problema, perderíamos
servicio de DNS, o tenemos un servidor web, un front-end y back-end, servidores de dominios, etc.
La afinidad puede ser máquinas virtuales corriendo juntas o separadas, máquinas virtuales corriendo
o no en un host o grupo de host (afinidad y anti afinidad).
Las reglas de máquinas las crearemos en VM/Host Rule (“Keep Virtual Machines Together” y “Separate
Virtual Machines”):
Si vamos ha usar las reglas “Virtual Machines to Hosts” o “Virtual Machines to Virtual Machines”,
debemos de definir previamente en el apartado VM/Host Groups creando los grupos (tipos) de “VM
Group” y “Host Group”.
Definido las reglas, éstas pueden ser “preferentes” u “obligatorias”, para las “preferentes” (Should
run on hosts in group), si el host o grupo de host está disponible, las máquinas virtuales correrán en
esos host, si no lo están, podrán correr en otros host, sin embargo, si la regla es “obligatoria” y el host
o grupo de host no está disponible, vCenter Server con HA, no harán “power on” de esas máquinas
virtuales en otros hosts por que la regla ha sido creado como obligatoria (Must run on hosts in group).
Si creamos más de una regla de afinidad de VM-Host, las reglas no se clasifican, sino que se aplican
por igual. Por ejemplo, una máquina virtual que pertenece a dos grupos DRS, cada uno de los cuales
pertenece a una regla requerida diferente, puede ejecutarse solo en los hosts que pertenecen a ambos
grupos DRS del host representados en las reglas.
Cuando dos reglas de afinidad de VM-Host entran en conflicto, la mas antigua tiene prioridad y la
regla más nueva quedará deshabilitada. DRS solo intenta satisfacer las reglas habilitadas y las reglas
deshabilitadas se ignoran.
Por ejemplo, sí creamos una regla de separar máquinas virtuales, por ejemplo: (CiscoISE02 y
CiscoISE03), y otra regla de “mantener máquinas virtuales juntas”, ésta última regla se creará, pero
permanecerá deshabilitada porque se contradicen.
Cuando habilitamos DRS, las funcionalidades de “Pool de recursos” y vAPP estarán disponibles, pero
cuidado, sí en algún momento deshabilitamos DRS y tienes pool de recursos y/o vAPPs, éstas se
borran. Es posible hacer un Snapshot del Pool para “recuperar” en caso de pérdida.
Algo que me gustaría dejar claro es que DRS no es una funcionalidad de vSphere ESXi, forma parte,
pero no lo es, por lo tanto, si el vCenter Server no está operativo, las reglas podrían no respetarse
hasta que el servidor vCenter esté nuevamente operativo, si las reglas se están infringiendo y vCenter
Server vuelve a estar operativo, migrará las máquinas virtuales o grupos de máquinas virtuales para
hacer cumplir las reglas que hayamos definido a nivel de clúster.
Las reglas de DRS se guardan en la base de datos del servidor vCenter Server.
Las reglas DRS no se replican entre vCenter linkados, así que a la hora de hacer un recovery, hay
que tener en cuenta en crear las mismas reglas en el CPD pasivo con las máquinas virtuales de los
“placesholder”.
Tener en cuenta que si usáis TAGS, al hacer un salto de CPD, tampoco se guardan, así que os
aconsejo tirar de PowerCLI/PowerShell para hacer un export y un import de TAGS ;)
9.4 Visualización del clúster DRS
Al seleccionar el clúster / Monitor / vSphere DRS veremos seis apartados, resulta útil por que podemos
tener una visión global de lo que pasa o ha pasado en el clúster DRS:
En el apartado “Recommendations” encontraremos las recomendaciones del clúster para los niveles
de automatización “manual” o “parcial”, por en esos niveles de automatización, DRS nunca mueve las
máquinas virtuales automáticamente.
En “Faults” encontraremos los fallos del clúster DRS, la razón y el objeto afectado, posibles vMotion
fallidos.
El “History” nos proporciona fecha y hora que se produjo un evento de vMotion, como el detalle de
máquinas virtuales movidas de un host a otro, nos puede resultar útil para troubleshooting e informes.
Las demás visualizaciones como “CPU Utilization”, “Memory Utilization” y “Network Utilization” nos
aportan información sobre la distribución de recursos o mejor dicho, el consumo de los recursos
de cada hosts del clúster, así, si tenemos el clúster en modo manual o parcialmente automatizado,
sabremos si el balanceo que estamos haciendo es equivalente para todos los hosts del clúster.
Al igual que sucede con vSphere HA, un host en modo mantenimiento, no forma parte del clúster de
recursos hasta que salga del modo mantenimiento. Cuando un host está en modo mantenimiento,
ninguna máquina virtual podrá “correr” dentro de él.
9.5 vSphere HA y vSphere DRS
Tal como hemos comentado a lo largo de estos módulos, vSphere HA es un agente (FDM) que corre
dentro de casa servidor ESXi, sin embargo, DRS es una característica de vCenter Server, el servidor
vCenter Server se encarga del cumplimiento de las reglas de afinidad de máquinas virtuales o hosts.
vSphere HA y vSphere DRS pueden y deberían trabajar juntos, son complementarios, aun así, existen
motivos de por qué, vSphere HA no sea capaz de hacer “power on” de máquinas virtuales con DRS:
1. Aunque esto es más de vSphere HA, si el control de admisión no está habilitado, es posible que
ciertas máquinas virtuales no se enciendan en el resto del host del clúster por que no hay recursos
suficientes libres para todas.
2. Existen reglas de afinidad o anti-afinidad que impiden que las máquinas virtuales “corran” en otros
hosts del clúster.
3. A nivel de clúster existen suficientes recursos, pero los recursos están fragmentados entre varios
hosts. En estos casos, vSphere HA utiliza a vSphere DRS para “equilibrar y desfragmentar” él
clúster mediante vMotion e intentar hacer “power on” en el resto de hosts.
10. Fault Tolerance
Fault Tolerance (FT) posiblemente es unas de las características más asombrosas de VMware, permite
recuperar un servidor virtual ante un fallo de host/datastore, sin pérdida de datos, sin interrupción de
servicio (cero downtime) y sin pérdida de conectividad TCP.
FT siempre ha estado muy limitado, sólo podíamos habilitar esta característica a máquinas virtuales con
1 vCPU (entre otras limitaciones), impedía habilitar esta funcionalidad a la mayoría de los servidores
mas críticos de la empresa.
En vSphere 6.x, VMware dejó de utilizar la tecnología vLockstep que impedía usar más de un vCPU
en FT para poder llegar a más clientes y servicios críticos.
Imagen de www.patriciocerda.com
La máquina virtual protegida recibe el nombre de máquina virtual principal. La máquina virtual duplicada,
es conocida como máquina virtual secundaria, al habilitar FT, se crea la secundaria y se ejecuta en otro
host. La ejecución de la máquina virtual secundaria es idéntica a la de la máquina virtual principal. La
máquina virtual secundaria puede tomar el control en cualquier momento sin interrupción, con lo que
proporciona protección con tolerancia a fallos.
10.1 Características y limitaciones de Fault Tolerance
• Compatible con cualquier aplicación y sistema operativo.
• Admite máquinas virtuales con hasta 4 vCPU y 64 GB de memoria RAM.
• No más de 4 máquinas virtuales con FT por host, pero no más de 8 vCPU asignados para FT por
host.
• Compatible con vMotion en la máquina principal y en la secundaria.
• FT crea una copia de todos los discos y archivos de la máquina virtual (principal).
• Comprobación mediante puntos de control para sincronizar el vCPU entre la máquina virtual
principal y secundaria.
• Admite diferentes tipos de discos, thin, thick, etc.
• Compatible con DRS.
• Compatible con vSAN.
• HA y vMotion deben de estar configurado en el clúster.
• La máquina virtual principal y secundaria, nunca residen en el mismo host.
• Fault Tolerance ahora es compatible con Site Recovery Manger v8.1.
Os recomiendo validar que el CPU/Servidor está en matriz con VMware para trabajar con FT: https://
www.vmware.com/resources/compatibility/search.php
• Intel Sandy Bridge o posterior.
• AMD Bulldozer o posterior.
10.2 Configuración de la red
Antes de activar Fault Tolerance en una máquina virtual, debemos crear una red de tipo vmkernel, se
recomienda que sea un tráfico específico para ello y que la red sea 10 Gb.
Para trabajar con teaming de tarjetas de red, se recomienda crear dos vmkernel y editar la configuración
para que sea activo/pasivo en un vmkernel y en el otro, lo inverso, la misma configuración que se
realiza para disponer de “vMotion acelerado”.
Ejemplo de teaming (cruzado) en un host:
VMkernel-FT-01
vmnic8 —> Activo
vmnic9 —> Pasivo
VMkernel-FT-02
vmnic9 —> Activo
vmnic8 —> Pasivo
10.3 Activación de Fault Tolerance en una máquina virtual
Cuando activamos FT en una máquina virtual, VMware FT crea dos máquinas virtuales completa. Cada
máquina virtual tiene su propio archivo de configuración .vmx y sus archivos .vmdk. Estas máquinas
virtuales pueden estar en datastores distintos.
Los archivos de la máquina virtual pueden colocarse en el mismo datastore, sin embargo, VMware
recomienda colocar estos archivos en datastores independientes para una mayor disponibilidad.
Imagen de www.awerty.net
Para activar FT, desde vSphere Web Client, botón derecho sobre la máquina virtual y en opciones de
Fault Tolerance, lo activamos:
Desde el menú Fault Tolerance también podéis “apagar” Fault Tolerance, suspender, reanudar, migrar
la máquina virtual secundaria a otro host, hacer un Test Failover y test de reinicio de la secundaria.
Si cumplimos los requisitos de compatibilidad de CPU, existe la red de vMotion y la red de Fault
Tolerance, al activarlo, el icono de la máquina virtual se hace azul.
vSphere Fault Tolerance incluye archivos compartidos, estos archivos deben almacenarse en un
datastore compartido por todos los hosts del clúster:
• shared.vmft evita el cambio del UUID.
• .ftgeneration para disociación en casos de desconexión entre los hosts principal y secundario.
Además, vCenter Server aplica una “reserva” del total de la memoria virtual configurada en la máquina
virtual. Mientras FT esté configurado en la máquina virtual, no se puede modificar la reserva de
memoria, el tamaño, el límite, el número de vCPU ni los recursos compartidos. Tampoco se pueden
añadir ni eliminar discos de la máquina virtual.
En caso de querer cambiar estos parámetros, debemos de “apagar” FT en la VM (Turno off Fault
tolerance), aplicar los cambios y volver a habilitar FT en la máquina virtual.
10.4 vSphere Fault Tolerance con vSphere HA y vSphere DRS
Fault tolerance es compatible con vSphere HA y vSphere DRS. Cuando DRS está habilitado, DRS
elege el mejor host con menos carga para la máquina virtual secundaria. Si el host falla o se pierde
el acceso al datastore donde reside la máquina virtual primaria, FT entrará en acción y vSphere HA
arrancará la máquina virtual en otro host y reconocerá que se trata de una máquina con la característica
de FT. Se recomienda activar FT en un entorno que al menos tenga tres hosts, para poder levantar la
máquina virtual secundaria en el tercer host en caso de fallo.
HERRAMIENTA
GRATUITA
NUEVO Veeam Backup & Replication

Community Edition
La herramienta de backup y recuperación GRATUITA
imprescindible para cualquier carga de trabajo
El NUEVO Veeam Backup & Replication Community Además de proteger 10 VMs, Veeam Backup &
Edition es el software de backup GRATUITO Replication Community Edition proporciona backups
imprescindible para VMware, Hyper-V y Nutanix y migración de VMs GRATUITAS e ILIMITADAS
AHV, además de para servidores físicos Microsoft manuales para más VMs, además de la 10 definidas,
y Linux, estaciones de trabajo e instancias. que también quiera proteger. Sin necesidad
Use el NUEVO Veeam Backup & Replication de desplegar agentes, consigue una solución flexible
Community Edition para proteger hasta 10 VMs, y fiable para hacer backup de VM GRATIS para l
o una combinación de VMs, instancias cloud, a gestión diaria de sus cargas de trabajo.
servidores físicos o estaciones de trabajo. Puede
proteger parte de su entorno, su laboratorio Descargar ahora en http://vee.am/vbr-free
doméstico, o usarlo para llevar a cabo migraciones
sin coste alguno.
La edición Community es:

• Potente: Experimente las funcionalidades de backup
completo, recuperación y replicación ofrecidas por
la edición Standard de Veeam Backup & Replication
• Sencillo: Descargue y empiece a proteger
en cuestión de minutos con cualquier hardware
o almacenamiento que ya posea
• Fiable: Configure y olvídese, con la seguridad
de que sus datos estarán protegidos y disponibles,
cuándo y dónde los necesite — It Just Works.
• GRATIS PARA SIEMPRE
NOTA: Community Edition funciona con más

de 10 instancias, ofreciendo backup manual
para un número ILIMITADO de VMs.
Capítulo 9
Backup y Réplicas
Patricio Cerda
Capítulo 9 - Backup y Réplicas Patricio Cerda
1. Introducción
La tecnología evoluciona continuamente, así como evolucionan las necesidades de los clientes.
Pasamos de tener Centros de Datos con múltiples servidores físicos, donde los servicios y aplicaciones
se encontraban amarrados al hardware, a tener una infraestructura virtualizada que nos provee de
abstracción de hardware, elasticidad en el uso de recursos, mayor movilidad y disponibilidad, entre
otras ventajas.
La virtualización de servidores solucionó mucho de los problemas que enfrentábamos en los Centros
de Datos tradicionales, pero también abrió las puertas a una nueva revolución tecnológica: el Cloud
Computing. La famosa “nube” nos permitió proveer de portales de auto-servicio, donde los clientes/
usuarios podían provisionar sus propios servicios, aplicaciones o simplemente máquinas virtuales, de
una manera rápida y sencilla gracias a la automatización provista por las soluciones de Cloud.
La adopción de soluciones de Cloud se vio acelerada además por el cambio de paradigma que significó
el concepto de Centro de Datos Definido por Software (SDDC por sus siglas en ingles), donde la
virtualización ya no estaba limitada simplemente a virtualizar servidores, sino que nos permitía además
virtualizar cada aspecto de los centros de datos, incluyendo el provisionamiento de servicios de red
y de almacenamiento. El SDDC nos permitió contar con un nivel de automatización mucho más
profundo, facilitando la adopción de la Cloud.
Como vemos, la evolución de los Centros de Datos es continua, y seguirá evolucionando sin duda.
Pero a pesar de esta evolución continua, hay algo que ha permanecido constante en el tiempo: La
necesidad de proteger la información almacenada en el Centro de Datos.
En la actualidad, las compañías consideran que casi todos sus servicios/aplicaciones son críticas
para el negocio, por lo que la supervivencia de la compañía yace justamente en poder asegurar
la disponibilidad de dichos servicios/aplicaciones. Es bueno destacar este concepto, donde lo que
necesitamos proteger finalmente no serán meramente datos, sino que lo que realmente necesitamos
proteger son las aplicaciones, los servicios que hacen posible que una compañía siga operando y
creciendo en el tiempo.
IMPORTANTE: El concepto clave que debemos recordar no es el respaldo de datos, sino la

disponibilidad de las aplicaciones/servicios.
Así como la tecnología en los Centros de Datos ha evolucionado, es imperativo que las soluciones
de protección de datos evolucionen también. Las soluciones de respaldo que se utilizaban años
atrás son inútiles en un Centro de Datos moderno, y no son capaces de adaptarse a los continuos
cambios y al continuo crecimiento que se presenta en un entorno de Cloud, el cual por su naturaleza
es altamente dinámico. Las soluciones “Legacy” no son capaces de proveernos de la disponibilidad
continua requerida por las aplicaciones y servicios actuales, con RTOs y RPOs de menos de 15 minutos.
Para proteger nuestros servicios en un ambiente virtualizado o de Cloud, deberemos entonces contar
con una herramienta adecuada. En este aspecto podemos mencionar:
• Veeam Backup and Replication
• Nakivo Backup and Replication
• Vembu VMBackup
• Dell EMC Avamar
• HPE Data Protector.
No solo las soluciones de protección de datos han evolucionado, finalmente éstas son solo herramientas.
También han evolucionado las buenas prácticas a la hora de proteger la información contenida en el
Centro de Datos.
En este capítulo hablaremos sobre protección de datos en el Centro de Datos moderno, específicamente
sobre cómo asegurar la continuidad de las aplicaciones y servicios de una compañía. Aquí
incluiremos además algunos Conceptos Claves y Buenas Prácticas recomendadas para las soluciones
de protección de datos previamente mencionadas.
Más adelante además describiremos de manera sencilla todo el proceso de diseño e implementación
de Veeam Backup and Replication, y como usar Veeam ONE y otras herramientas para ayudarnos en
este proceso.
1.1 Conceptos Clave
1.1.1 Recovery Point Objective (RPO): Punto objetivo de recuperación en español

RPO es el punto en el tiempo en el cual los datos deben ser recuperados luego de una falla. En
palabras simples equivale a la cantidad de datos que estoy dispuesto a sacrificar ante una falla.
Por ejemplo: Un RPO de 24 horas significa que protegeremos los datos cada 24 horas, como podría
ser la ejecución de un respaldo cada día a las 10 PM. ¿Qué significa esto? Que si nuestro último
respaldo fue ejecutado ayer a las 10 PM, y hoy se ha producido una falla a las 9:45 PM, deberemos
recuperar los datos desde el ultimo respaldo disponible (ayer a las 10 PM), lo cual implica que todos
los cambios que se han producido desde ese último respaldo, hasta el momento de la falla, están
irremediablemente perdidos.
El RPO no depende directamente de la solución de protección de datos que utilicemos (aunque puede
estar limitado por ésta), sino que depende de las necesidades del negocio. Perfectamente podríamos
tener algunas aplicaciones protegidas con RPOs de 24 horas, mientras que otras aplicaciones más
críticas podrían tener un RPO de solo minutos, o incluso protección continua si así lo permite la solución
de protección de datos utilizada.
IMPORTANTE: El RPO finalmente dependerá del presupuesto del que dispone el cliente, entendiendo
que un RPO más bajo, implica necesariamente invertir más dinero en una solución e infraestructura
adecuados para alcanzar este RPO.
1.1.2 Recovery Time Objective (RTO): Tiempo objetivo de recuperación en español

RTO es básicamente el tiempo máximo dentro del cual un servicio o aplicación debe ser restaurado
luego de una falla.
El RTO podría ser de minutos, horas o incluso de días dependiendo de qué tan crítico es el servicio
que ha fallado. Las soluciones de protección de datos cuentan con distintas técnicas de recuperación
que permiten restaurar los datos requeridos en periodos de tiempo muy breves y con distintos niveles
de granularidad.
Al igual que el RPO, el RTO también dependerá del presupuesto disponible para este proyecto. Un
RTO más bajo (minutos) implica una inversión considerablemente más alta que un RTO de varios días.
1.1.3 Business Continuity: Continuidad de Negocios en español

Business Continuity se refiere a la capacidad de una organización o compañía para planificar e
implementar los procesos y medidas necesarias para reanudar las operaciones normales del negocio
después de un desastre o cualquier evento que afecte la continuidad del negocio.
En cualquier plan de continuidad de negocios el foco es el negocio mismo, y debe estar diseñado para
reducir posibles bajadas de servicio al mínimo, e idealmente evitar cualquier interrupción, permitiendo
ofrecer un uptime de 24/7.
1.1.4 Disaster Recovery: Recuperación ante desastres en español

Concepto similar a Business Continuity, pero en este caso, un plan de Disaster Recovery estará centrado
en la tecnología y datos involucrados en la recuperación de los servicios luego de una interrupción de
los mismos. Un plan de Disaster Recovery es básicamente un conjunto de procedimientos donde el
objetivo es recuperar los datos y lograr que la infraestructura TI vuelva a operar con normalidad luego
de un desastre.
Mientras antes una organización recupere sus sistemas de un desastre, más rápido dicha organización
podrá reanudar sus operaciones normales de negocio. Es por esto que usualmente Disaster Recovery
se considera como un componente clave en el diseño del plan de Business Continuity.
NOTA: En algunos casos, el término “Backup/Respaldo” es usado erróneamente como un sustituto al

termino Disaster Recovery. Sin embargo, debemos tener en cuenta que un plan de Disaster Recovery
no está limitado al uso de una solución de Backup, sino que ésta es simplemente un componente
tecnológico en un proceso de recuperación mucho más extenso. Los respaldos son parte integral
de un plan de Disaster Recovery (DRP), pero no puede ser considerado como el único componente
del mismo.
1.1.5 Regla 3-2-1

Muchos expertos aconsejan que, para poder construir una solución de protección de datos sólida, y así
contar con un plan de Disaster Recovery exitoso, se debe seguir la regla 3-2-1.
¿Y que significa esta regla 3-2-1? Pues muy fácil:
• 3: Se debe contar con al menos 3 copias de los datos
• Primera copia serían los datos originales en producción.
• Segunda copia sería un backup primario.
• Tercera copia sería un backup secondario.
• 2: Se debe utilizar al menos dos tipos diferentes de almacenamiento para guardar las copias de los
datos. Podemos utilizar, por ejemplo:
• Discos locales y Cloud
• Almacenamiento vía FC y respaldos en Cintas
• Almacenamiento vía NFS y respaldos sobre appliance de Deduplicación.
• 1: Al menos una de las copias debiera permanecer fuera del sitio principal, por ejemplo:
• En la Cloud
• Respaldo secundario en un sitio remoto.
• Respaldo en cintas las cuales luego son transportadas a una ubicación segura o bóveda
externa.
Siguiendo esta regla, si un desastre ocurre afectando los datos de producción y además los respaldos
locales, aun podemos contar con los respaldos que tenemos en una ubicación remota para llevar a
cabo la recuperación.
1.2 Buenas Prácticas para Disaster Recovery
1.2.1 Definir el alcance y dependencias

Actualmente la gran mayoría de aplicaciones y servicios críticos del negocio se ejecutan dentro de una
VM. Aquí podemos encontrar VMs ejecutando diversos servicios como bases de datos, servicios web,
ERPs, CRMs, servicios de correo y mensajería, entre otros.
Claramente no todas las aplicaciones/servicios serán consideradas críticas para el negocio, teniendo
en cuenta además que tendremos un número importante de VMs ejecutando aplicaciones que se
encuentran en etapa de desarrollo, pruebas o QA. En este sentido es importante que se identifiquen
los servicios críticos del negocio, así como la o las VMs utilizadas para soportar dichos servicios. Este
proceso debe incluir además cualquier dependencia requerida para el correcto funcionamiento de los
servicios o aplicaciones que intentamos proteger. Por ejemplo, si deseamos proteger un servicio de
correo provisto por MS Exchange, debemos procurar además proteger el servicio de directorio (Active
Directory) del cual Exchange depende directamente.
Al identificar los servicios y aplicaciones que se ejecutan en cada VM, podemos proceder con una
priorización de estas últimas, de manera de proteger con mayor prioridad las VMs que hospeden los
servicios más críticos de la compañía y que requerirán RPOs y RTOs más bajos.
En este mismo proceso podemos excluir VMs que no ofrezcan servicios críticos del negocio, o que
simplemente no ofrezcan ningún servicio que se encuentre actualmente en producción, lo cual nos
permite reducir el uso de recursos en la solución de respaldo.
1.2.2 Definir los requerimientos de conectividad

Un punto crítico para cualquier solución de Respaldo serán los recursos de red disponibles, tanto para
conexión local o remota.
Para realizar respaldos locales, el uso de ancho de banda dependerá de la conexión utilizada
para obtener los datos de las VMs desde el hipervisor, así como de los distintos componentes de
arquitectura de la solución de respaldo. Por ejemplo, si entre el Hipervisor y el Repositorio tendremos
un componente intermedio como un Proxy, debemos considerar también el ancho de banda requerido
para enviar los datos desde el Proxy hasta el repositorio.
1.2.3 Definir los requerimientos de RTO y RPO

Ya previamente definimos ambos conceptos. Ahora lo que necesitamos es poder definir los
requerimientos del cliente respecto a ambos.
El RTO y RPO estará basado finalmente en una decisión de negocio, y estará limitado muchas veces
por las restricciones de presupuesto impuestas por el cliente. Con las soluciones de Backup existentes
actualmente, podemos conseguir RTOs y RPOs por debajo de los 15 minutos, pero para conseguir
dichos tiempos deberemos diseñar una solución que cuente con la performance y capacidad adecuada,
lo cual suele significar una mayor inversión en hardware y licencias.
Debemos considerar además que el RTO y RPO no será necesariamente el mismo para todas las
VMs. Usualmente tendremos RTOs y RPOs más agresivos para las VMs que contengas servicios y
aplicaciones críticos para el negocio, mientras que servicios menos críticos podrían considerar un RTO
y RPO más alto.
1.2.4 Consistencia de los respaldos

Un punto importante al momento de seleccionar y diseñar la solución de Respaldo a utilizar, es la
posibilidad de asegurar la consistencia de los respaldos, específicamente la consistencia a nivel de
aplicaciones y/o a nivel de sistema de archivos.
La mayoría de las soluciones de respaldo para VMware están basadas en Snapshots de las VMs,
no obstante, esto no es suficiente ya que, si bien asegura la consistencia a nivel de disco virtual, no
asegura la consistencia a nivel de aplicaciones y/o de sistema de archivos.
Para lograr dicho nivel de consistencia, se requiere de un nivel de integración mayor con el sistema
operativo y las aplicaciones, lo cual en el caso de sistemas operativos Windows, se traduce en
integración con Microsoft VSS.
Debido a esto, la solución seleccionada debe ser capaz de proveer este nivel de integración con VSS,
así como también de proveer funcionalidades de integración similares para sistemas operativos que
no cuenten con VSS (Linux o versiones más antiguas de Windows).
2. Diseño y Dimensionamiento de la Infraestructura
Ya que hemos cubierto una serie de conceptos y buenas prácticas asociadas a soluciones de respaldo
y de Disaster Recovery, ahora nos enfocaremos en el diseño y dimensionamiento específico para
Veeam Backup and Replication, incluyendo una serie de buenas prácticas específicas para esta
solución.
Probablemente uno de los puntos más importantes para asegurar el correcto funcionamiento de
cualquier solución, es contar con un buen diseño que permita cumplir con los requerimientos del
cliente, así como también un dimensionamiento apropiado para asegurar que no tendremos problemas
inesperados de capacidad y/o de performance.
A continuación, mencionaremos cada uno de los componentes de la arquitectura de Veeam Backup

and Replication, y sus recomendaciones de diseño y dimensionamiento.
2.1 Veeam Backup Server
El “cerebro” de la solución, el cual provee la interfaz única de configuración y administración de todos

los componentes de la infraestructura de respaldos. Coordina tareas, controla la ejecución de los
Jobs que han sido programados, y controla también la asignación de recursos para cada tarea, entre
otras responsabilidades.
2.1.1 Recomendaciones de diseño

• Veeam Backup Server debe ser instalado sobre un servidor basado en Windows Server. Se
recomienda utilizar la versión más reciente de Windows Server, para evitar problemas de
compatibilidad al realizar restauración de archivos con Instant File Leverl Recovery (IFLR).
• Es posible instalar Veeam Backup Server sobre una máquina virtual o en un servidor físico, siendo
ambas opciones soportadas por Veeam. Yo siempre recomiendo el uso de máquina virtual, ya
que me permite aprovechar las ventajas propias de la virtualización, como la independencia del
hardware, la movilidad con vMotion, portabilidad, alta disponibilidad, etc.
• En caso de tener dos Centros de Datos en modalidad Activo-Standby, se recomienda desplegar

Veeam Backup Server en el sitio Standby. Esto permite que en caso de una falla completa del
Centro de Datos principal (Activo), contemos en todo momento con acceso a la interfaz de Veeam
Backup Server para el proceso de Failover y/o restauración.
• En caso de tener dos o más Centros de Datos, donde todos sean utilizados por servicios/aplicaciones
críticas para el negocio, Veeam Backup Server puede ser deplegado en cualquiera de los Centro
de Datos. En caso de utilizar una máquina virtual para Veeam Backup Server, se recomienda
replicarla…. ¡¡¡Con Veeam Backup and Replication!!!
2.1.2 Guías de dimensionamiento

Muchas veces el dimensionamiento de Veeam Backup Server no se considera como algo critico al ser
un componente de administración, no obstante, es sumamente importante dimensionar adecuadamente
este componente, para asegurar que todos los Jobs puedan ser ejecutados adecuadamente según la
configuración presente.
• Se requiere un mínimo de 2 cores de CPU y 8GB de RAM.
• Por cada 10 Jobs concurrentes se requieren 1 core y 4GB de RAM. En este punto se vuelve
importante mantener un número reducido de Jobs, evitando por ejemplo tener 1 máquina virtual
por Job, lo cual obligaría a aumentar enormemente los recursos requerido por Veeam Backup
Server para gestionar todos los Jobs concurrentes que decidamos crear.
• 40 GB en disco
• En caso de habilitar la opción de Indexación de archivos:
• 100MB por cada millón de archivos sobre sistemas operativos Windows.
• 50MB por cada millón de archivos sobre sistemas operativos Linux.
2.2 Veeam Proxy Server
El “Músculo” de la solución. Un Proxy Server es un componente que se ubica entre un origen y un

destino de datos. De esta manera, es el Proxy Server el encargado de obtener los datos que deseamos
proteger, por ejemplo, obteniendo los datos de una VM desde un host ESXi, para luego enviarlos a un
destino, por ejemplo a un Repositorio de respaldos.
Es el Proxy Server el encargado de procesar los Job de Respaldo o Replicación, incluyendo la

aplicación de los algoritmos de Deduplicación y Compresión nativos de Veeam. Del mismo modo, si
hemos habilitado la opción de Encriptación de los respaldos, será el Proxy Server el encargado del
proceso de Encriptación de los datos.
2.2.1 Recomendaciones de diseño

• Un Proxy Server utiliza un servidor con Windows Server (no hay opción de uso de Linux), y debe
ser además un servidor dedicado para esta función.
• Un Proxy Server puede ser un servidor físico o una máquina virtual en caso de que vayamos a
respaldar máquinas virtuales sobre VMware. En caso de utilizar Hyper-V, el Proxy Server debe ser
obligatoriamente un servidor físico.
• Se recomienda desplegar al menos dos Proxy Servers, de manera de tener redundancia para este
rol.
• Se recomienda además desplegar al menos un Proxy Server adicional para tareas de Restauración.
Pónganse en el peor caso, en que todos los Proxy Servers están trabajando en la ejecución de los
respaldos diarios, y en ese momento requieren llevar a cabo una restauración de una máquina virtual.
Si todos los Proxy Servers están ocupados con los respaldos, deberán cancelar uno de estos respaldos,
o esperar a que finalicen para proceder con la restauración.
En cuanto a los Modos de Transporte (VMware), se cuenta con las siguientes recomendaciones:
• Direct Storage Access es la opción más recomendada, siendo la segunda opción el modo Virtual
Appliance (Hot-Add) dejando al modo Network (NBD) como última opción.
• Direct SAN Access es el modo recomendado si las máquinas virtuales se encuentran almacenadas
en una cabina de almacenamiento con conexión iSCSI o Fiber Channel. En este caso el Proxy
Server debe ser obligatoriamente un servidor físico, con acceso a la cabina de almacenamiento
productiva, por lo que se debe haber realizado también el proceso de LUN Masking y Zonificación
apropiados.
• Direct NFS Access es el modo recomendado si las máquinas virtuales se encuentran almacenadas
en una NAS, utilizando Datastores NFS. En este caso el Proxy Server puede ser un servidor Físico
o Virtual.
• Virtual Appliance (Hot-Add) es el modo recomendado para ambientes altamente dinámicos, donde
el número de Datastores varía constantemente. Es el segundo modo recomendado en caso que el
modo Direct Storage Access no esté disponible.
• Virtual Appliance (Hot-Add) es el modo recomendado para plataformas que utilicen Virtual SAN
(vSAN), así como también cuando se utilicen Datastores locales.
• Virtual Appliance (Hot-Add) no es recomendado cuando las máquinas virtuales se encuentran

almacenadas en un Datastore NFS. En ese caso se recomienda el uso del modo Direct NFS
Access o el modo Network (NBD)
• Modo Network (NBD) es solo recomendado como última opción, en caso de que los modos
anteriores no estén disponibles o hayan fallado. El modo Network no es recomendado cuando la
conectividad de red es de solo 1Gbps, donde la performance es extremadamente pobre.
Direct Storage
Almacenamiento Virtual Appliance Network Mode
Access
Proxy físico con acceso
SAN Fibre Channel Proxy Virtual en Proxy físico o virtual
directo a la SAN
(FC) ejecución sobre conectado a los
mediante FC.
un host ESXi, con hosts ESXi mediante
Proxy físico o virtual conexión al dispositivo la interface de
SAN iSCSI con acceso directo a la de almacenamiento. Management.
SAN mediante iSCSI.
Proxy físico o virtual
Storage NFS con acceso al Storage No recomendado
via NFS.
Almacenamiento Proxy Virtual en cada
No soportado
Local host ESXi.

2.2.2 Guía de dimensionamiento

El dimensionamiento del Proxy Server es crucial, ya que este componente será el encargado de
ejecutar efectivamente los respaldos, replicaciones y también restauraciones. Un dimensionamiento
inadecuado impactará negativamente la ejecución de los Jobs, y podrían darse el caso de que no
puedan completar la ejecución de todos los Jobs en la ventana de respaldo impuesta por el cliente.
• Se requiere un mínimo de 2 GB de RAM + 500MB adicionales por cada tarea concurrente. No

obstante, estos valores son mínimos y solo debieran utilizarse en casos extremos.
• La recomendación es utilizar 1 core de CPU y 2GB de RAM por cada tarea concurrente. Tener
en consideración que una tarea concurrente es el proceso de respaldar, replicar o restaurar un
disco virtual. Por ejemplo, si desean respaldar una máquina virtual con 2 discos virtuales, el Proxy
ejecutará 2 tareas para proceder con el respaldo.
• Por ejemplo, si se desea ejecutar 60 tareas concurrentes, se necesitarán 60 cores de CPU y 120GB
en RAM. Esta capacidad de procesamiento puede ser dividida en múltiples Proxy Server sobre
los cuales Veeam balanceará la carga de manera automática. Esto permitirá además contar con
mayor disponibilidad del servicio, ya que si un Proxy Server falla, aún quedan otros para continuar
con la ejecución de los Job.
• Se recomienda además desplegar al menos 1 Proxy Server adicional para tareas de restauración
(explicado anteriormente). Este proxy podría ser virtual, utilizando el modo de transporte Virtual
Appliance (Hot-Add).
2.3 Veeam Backup Repository
Cuando hablamos de repositorio, hablamos simplemente de una ubicación donde Veeam Backup
and Replication almacenará los archivos de respaldo. Técnicamente hablando, un Repositorio es
simplemente una “carpeta” en un dispositivo de almacenamiento.
En una infraestructura con Veeam Backup and Replication podemos implementar múltiples tipos de
repositorio, considerando que Veeam es totalmente agnóstico con el tipo de almacenamiento utilizado
para almacenar los respaldos, pudiendo por ejemplo utilizar:
• Servidores con discos locales
• Almacenamiento sobre cabina iSCSI o Fiber Channel
• Carpeta compartida vía NFS o CIFS
• Appliance de Deduplicación
Aquí un comparativo de los tipos de almacenamiento que pueden ser utilizados como Repositorio.
Tipo de Repositorio Tipo de Almacenamiento Procesamiento de Datos

Disco local, Almacenamiento El servicio Veeam data mover
conectado directamente, o es desplegado cuando el
Servidor Windows
LUNs conectadas vía iSCSI o servidor es añadido a Veeam
FC. Backup Server.
Disco local, Almacenamiento El servicio Veeam data mover

conectado directamente, LUNs service es desplegado cuando
Servidor Linux
conectadas vía iSCSI o FC, o se ejecuta un Job que utilice
shares NFS. dicho Repositorio.
La transferencia de datos es
llevada a cabo mediante el
CIFS (SMB) share Share CIFS (SMB)
servicio Veeam Data Mover en
el Gateway Server (Windows)
La transferencia de datos es
• EMC Data Domain llevada a cabo mediante el
servicio Veeam Data Mover en
Appliance de Deduplicación • ExaGrid
el Gateway Server (Windows),
• HPE StoreOnce o directamente en el caso del
appliance Exagrid.
Un Job de Respaldo puede utilizar un único Repositorio para almacenar los archivos de respaldo, a la
vez que un Repositorio puede ser utilizado por múltiples Jobs. Como alternativa tenemos también el
uso de Scale-Out Backup Repository (SOBR).
SOBR es básicamente una funcionalidad que permite agrupar múltiples Repositorios (pudiendo
ser de distinto tipo) en una única unidad lógica. De esta manera, podemos configurar un Job de
Respaldo para enviar los archivos a esta unidad lógica o Scale-Out Backup Repository, y será Veeam
quien decida en que repositorio especifico serán almacenados los archivos, y también decidirá si todos
los archivos de la cadena de respaldo utilizarán un único repositorio o si los respaldos incrementales
utilizaran un repositorio distinto al respaldo Full.
NOTA: SI quiere saber más de Scale Out Backup Repository puede obtener mayor información en el
siguiente link: https://goo.gl/qGBiUu
2.3.1 Recomendaciones de Diseño

Siendo Veeam totalmente agnóstico respecto al tipo de almacenamiento que pueden utilizarse
para almacenar los archivos de respaldo, existen algunas recomendaciones que debemos tener en
consideración:
• El Repositorio de respaldo contendrá información esencial de la compañía y que será utilizada en

caso de que se produzca alguna emergencia. Debido a esto, el almacenamiento utilizado debe ser
suficientemente robusto, con elementos redundantes que permitan asegurar que los Respaldos
siempre estarán disponibles en caso de ser necesario. Aquí no valen esas NAS tipo IOMEGA o
similar, que son muy buenas para ambientes de laboratorio o para archivos personales, pero que
no proveen la robustez requerida en un entorno corporativo.
• ¡¡¡La capacidad no lo es todo!!! También debemos asegurarnos de que el almacenamiento elegido

nos permita realizar operaciones de lectura y escritura a una velocidad adecuada, que nos permita
cumplir con las ventanas de respaldo impuestas por el cliente, así como también con los tiempos
de recuperación (RTO). No sirve de mucho si compramos una cabina de almacenamiento solo
con discos SATA de 8TB, que nos dará una muy alta capacidad en un espacio físico reducido y a
bajo costo, si luego la ejecución de los respaldos (y más crítico aun, de las restauraciones) será
dolorosamente lento.
• El almacenamiento debiera ser escalable, de manera de poder ir escalando en el tiempo a medida
que la compañía va creciendo, y con ésta también va creciendo la información a proteger.
• Podemos utilizar una estrategia de almacenamiento en capas (Tiers), donde por ejemplo los
respaldos más recientes (los últimos 7 días) utilicen una cabina de almacenamiento de alta
performance, pero que no requiere de una gran capacidad.
Al mismo tiempo, podríamos contar con una segunda cabina de almacenamiento de mucho mayor
capacidad, pero con una performance más restringida, lo que nos permitiría almacenar respaldos por
un periodo más extenso, de meses o años (archiving), sin incurrir en altos costos de almacenamiento.
2.3.2 Guía de dimensionamiento

El dimensionamiento de los Repositorios tiene dos partes. En primer lugar, debemos dimensionar
adecuadamente el Veeam Backup Repository Server, lo cual muchas veces no se toma en cuenta ya
que nos enfocamos directamente en la capacidad de almacenamiento.
• Mínimo recomendado 2 cores de CPU para el sistema operativo.
• Se recomienda además 1 core de CPU por cada Job concurrente.
• Finalmente se recomiendan 4GB de ram por cada core de CPU.
NOTA: Estos mismos requerimientos aplican en caso de utilizar un Gateway Server para montar
carpetas compartidas CIFS o Appliances de deduplcación.
Luego viene la parte más crítica, que es el dimensionamiento de la capacidad requerida en los
Repositorios de respaldo. Debemos considerar que existen muchos factores que van a tener un
impacto en este dimensionamiento, y que deben ser considerados a la hora de realizar los cálculos:
• Tamaño total de las VM a ser respaldadas.
• Frecuencia de los respaldos (diario, semanal, mensual, etc.). La frecuencia de los respaldos depende
directamente del RPO que haya solicitado el cliente, y tendrá un impacto en el dimensionamiento,
así como también en los costos asociados al proyecto.
• Periodo de retención de los respaldos (días, meses, años, etc.). Esto también es un requerimiento
del negocio, por lo que debemos tener claro que a más retención, mayor capacidad será requerida,
y mayor será el costo del proyecto.
• Qué tipo de Respaldo se llevará a cabo: Incremental, Reverse Incremental o Forever Forward
Incremental. Esta decisión afectará la capacidad de almacenamiento requerida, y también tendrá
un impacto en la performance de lectura/escritura del Repositorio de Respaldo.
NOTA: Si desean ver una explicación más detallada respecto al impacto en la performance de cada tipo
de respaldo, pueden obtenerla desde el siguiente link: https://goo.gl/5R6DoB. También a continuación
una pequeña tabla con la comparación de cada tipo de respaldo.
Método de Backup Impacto en el Repositorio I/O

Active full 1 write I/O
Forever Forward incremental 3 I/O (1 I/O read + 2 I/O write)
Forward incremental 1 write I/O
Reverse incremental 3 I/O (1 I/O read + 2 I/O write)
Synthetic full 2 I/O (1 I/O read + 1 I/O write)

Synthetic full with transform to rollbacks 4 I/O (2 I/O read + 2 I/O write)
Existen otros factores que debemos considerar también a la hora de dimensionar la capacidad
requerida para Repositorio:
• Tasa de Cambio: Básicamente necesitamos saber cuántos datos nuevos son creados, o cuantos
datos son modificados en un periodo de tiempo. Esta información es esencial para poder calcular el
tamaño de los respaldos incrementales. Por ejemplo, si deseamos hacer respaldos incrementales
diarios, con un Full periódico (semanal o mensual), necesitamos saber cuántos datos son creados/
modificados durante esas 24 horas que tenemos de RPO en un respaldo diario.
Pero ¿cómo calculamos esto? Bueno, basado en múltiples implementaciones, en general se

considera apropiado considerar una tasa de cambio diaria de entre 5% y 10%, siendo 10%
considerado generalmente como un valor conservador con el que estaríamos seguros de no
quedarnos cortos en el cálculo de capacidad. Si desean tener un número más preciso, podrían
utilizar Veeam ONE, el cual cuenta con un reporte llamado “VM Change Rate Estimation”, el cual
nos entrega con detalle la tasa de cambio de las VMs.
• Ahorro por Compresión y/o Deduplicación: Veeam cuenta con algoritmos nativos de compresión
y deduplicación que vienen habilitados por defecto. Entre ambos se puede conseguir una reducción
de un 2:1 (50%) en el tamaño de los archivos de respaldo. Esto quiere decir que, si las VM
consumen 10TB de capacidad de almacenamiento, un respaldo Full requeriría aproximadamente
5TB de capacidad.
Este ahorro puede ser incluso mayor, pero depende mucho en el tipo de información a respaldar,
por lo que en general se recomienda utilizar una tasa de ahorro conservadora de 50%.
Este Ahorro también puede variar si utilizamos un Appliance de Dedupliación, los cuales cuentan
con algoritmos de deduplicación mucho más avanzados que proveen una tasa de ahorro mucho
mayor, que puede incluso llegar hasta el 95% (según las especificaciones de ciertos Appliances).
IMPORTANTE: Si se decide utilizar Scale-Out Backup Repository (SOBR), esto activará otra
funcionalidad llamada Per-VM Backup File, lo cual reduce enormemente la capacidad de deduplicación
de Veeam, por lo que el ahorro provisto por la Deduplicación nativa provista por Veeam prácticamente
desaparece.
Ahora con toda esta información, debemos realizar el dimensionamiento, para lo cual podemos
proceder de manera manual, usando calculadora o Excel para los cálculos, o podemos apoyarnos en
algunas herramientas ya existentes.
• Aquí les recomiendo utilizar “The Restore Point Simulator” de Timothy Dewin, System Engineer de
Veeam: http://rps.dewin.me
• Otro simulador mucho más completo es el que ha publicado Hannes Kasparick, también empleado
de Veeam, pero éste aún se encuentra en construcción, por lo que podrían presentarse algunos
fallos de momento: http://sizer.kasparick.com
NOTA: Los Partners de Veeam tienen acceso a una herramienta similar en el portal Veeam ProPartner.
EJEMPLO 1
Veamos un ejemplo práctico:
• Deseamos respaldar 50TB de datos.
• Deseamos respaldos diarios, con un Full semanal.
• Deseamos 15 días de retención.
• Utilizaremos una tasa de cambios estándar de 5%.
• Utilizaremos una tasa de reducción conservadora de 50%
• El respaldo Full semanal puede ser Active Full o Synthetic Full
Una vez ingresados todos los datos, simplemente le damos click al botón Simulate, y veremos la
capacidad requerida para el Repositorio según los requerimientos antes expuestos.
Como podemos ver, en este caso hemos de requerir aproximadamente 110TB de capacidad de
almacenamiento para poder cumplir con todos los requerimientos solicitados por el cliente.
NOTA: Si quieren ver en detalle el funcionamiento de cada método de respaldo con Veeam, pueden ir
al siguiente link: https://goo.gl/cdkimx
EJEMPLO 2
Veamos una pequeña variación del ejemplo anterior. En este caso mantendremos la retención de
15 días, pero eliminaremos el respaldo Full semanal, por lo que utilizaremos el método de respaldo
Forever Forward Incremental. Recuerden que cada método de respaldo tiene sus pros y sus contras,
específicamente en lo que se refiere a capacidad de almacenamiento y a la performance (IOPS).
Como podemos ver, la capacidad requerida se ha reducido de 110TB a aproximadamente 56TB. Esto
es simplemente porque ya no se requiere llevar a cabo un respaldo Full Semanal.
A pesar de lo anterior, donde logramos un ahorro importante en la capacidad de almacenamiento, no

debemos olvidar que el método Forever Forward Incremental genera una cantidad de operaciones de
lectura/escritura mucho mayor que el método de respaldo Incremental con Full periódicos, por lo que
deberemos considerar una cabina de almacenamiento con una performance acorde a esta necesidad.
3. Instalación de Veeam Backup and Replication
Ya que hemos completado la etapa de diseño y dimensionamiento, llega la hora de implementar

Veeam Backup and Replication. A continuación, iremos detallando los pasos de instalación para los
componentes principales, así como los pre-requisitos para una instalación exitosa.
3.1 Instalar Veeam Backup Server
3.1.1 Requisitos previos

Hardware
• CPU: Procesador x86-64, se recomienda un mínimo de 4 cores. Revisar el apartado de

dimensionamiento en el capítulo anterior.
• Memoria: Mínimo recomendado 8GB de RAM. Revisar el apartado de dimensionamiento en el

capítulo anterior.
• Almacenamiento: 5GB para la instalación del producto, más 4.5GB para la instalación de .NET
Framework 4.6. Revisar el apartado de dimensionamiento en el capítulo anterior.
• Network: Al menos una conexión de 1Gbps o más rápida.
Software
1. Sistemas operativos soportados para la instalación:
• Microsoft Windows Server 2019
• Microsoft Windows Server 2012 R2
• Microsoft Windows Server 2008 R2 SP1
• Microsoft Windows Server 2008 SP2
• Microsoft Windows 10
• Microsoft Windows 8.x
• Microsoft Windows 7 SP1
2. Microsoft .NET Framework 4.6
3. Microsoft Windows Installer 4.5
4. Microsoft SQL Server Management Objects
5. Microsoft SQL Server System CLR Types
6. Microsoft Report Viewer Redistributable 2015
7. Microsoft Universal C Runtime
NOTA: Durante la instalación, el asistente verificará si todos los pre-requisitos de software se cumplen
en el servidor donde se está instalando Veeam Backup and Replication. Si parte del software requerido
no se encuentra instalado, el asistente ofrecerá instalar dicho software faltante automáticamente.
Base de Datos
• Microsoft SQL Server 2017
• Microsoft SQL Server 2016 (Microsoft SQL Server 2016 SP1 Express Edition is included in the
setup)*
• Microsoft SQL Server 2012 (Microsoft SQL Server 2012 SP4 Express Edition is included in the
setup)**
• Microsoft SQL Server 2008 R2
NOTA: Se soportan instancias SQL locales o remotas, incluyendo versiones Express y Completas de
SQL Server.
IMPORTANTE: SQL Express está soportado por Veeam Backup and Replication, pero se recomienda
para escenarios con un máximo de 500 máquinas virtuales a proteger.
SQL Express SQL Standard / Enterprise

Unico socket de CPU Yes* Yes
Multiples sockets de CPU No Yes
Numero de VMs. <=500 >500
Tamaño de la Base de Datos < 10 GB =>10 GB
Jobs Concurrentes <=25 Minimo: 2 CPU cores y 4 GB RAM
3.1.2 Procedimiento de instalación

La instalación de Veeam Backup Server es un proceso bastante sencillo, el cual revisaremos a
continuación. Debemos destacar además que Veeam Backup Server es el único servidor donde
debemos llevar a cabo la instalación de Veeam Backup and Replication. Los demás roles como Proxy,
Repository Server, Mount Server, WAN Accelerator y otros, solo requieren el despliegue de algunos
componentes de software que son desplegados directamente desde el Veeam Backup Server cuando
le asignamos un rol a uno de los servidores registrados. Revisaremos ese proceso durante esta sección
de instalación.
Hay que asegurarse de:
• Cumplir con todos los requerimientos de software y hardware antes mencionados.
• Cuenta de usuario con los privilegios necesarios para llevar a cabo la instalación.
• Conectividad con otros componentes de la infraestructura Veeam.
• Si se va a utilizar una instancia dedicada de SQL Server, esta debe ser instalada previamente antes
de proceder con la instalación.
A continuación, el proceso de instalación:
1. Descargar la última versión de la imagen de instalación de Veeam Backup and Replication desde
el sitio de Veeam.
2. Montar la imagen de instalación en el servidor donde se planea instalar Veeam Backup and
Replication.
3. Despues que se ha montado la imagen, Autorun iniciará el asistente con las opciones de instalación.
Si Autorun no está disponible o se encuentra deshabilitado, ejecutar el archivo “Setup.exe” desde
la imagen.
4. En la sección Veeam Backup and Replication, hacer click en Install
5. Leer y aceptar los acuerdos de licencia.
6. En el paso “Provide License” se debe especificar la licencia de Veeam que se desea instalar. Aquí
existen tres opciones:
a. Utilizar la licencia que haya adquirido el cliente.
b. Utilizar una licencia de evaluación, la cual es enviada al descargar la imagen.
c. No utilizar licencia, en cuyo caso Veeam Backup and Replication se instalará en modo
Community Edition.
7. Hacer click en Browse y luego seleccionar el archivo de licencia.
8. En el paso “Program Feature” se deben seleccionar los componentes que el asistente instalará en
el servidor, y seleccionar la carpeta de instalación. El asistente instalará por defecto los siguientes
componentes:
a. Veeam Backup & Replication
b. Veeam Backup Catalog (componente responsible de almacenar los datos de indices de los
archivos de las VM respaldadas)
c. Veeam Backup & Replication Console
9. El asistente también instalará los siguientes componentes en segundo plano. Aquí no tenemos la
opción de NO instalarlos. Estos componentes no requieren licencia adicional.
a. Veeam Explorer for Microsoft Active Directory
b. Veeam Explorer for Microsoft Exchange
c. Veeam Explorer for Oracle
d. Veeam Explorer for Microsoft SQL Server
e. Veeam Explorer for Microsoft SharePoint
10. Debemos seleccionar también la carpeta de instalación. Podemos dejar el directorio por defecto
(C:\Program Files\Veeam\Backup and Replication\), o seleccionar un directorio personalizado.
11. En el paso System Configuration Check, el asistente verificará si todos los pre-requisitos de
software se encuentran instalados en la máquina. Si alguno de los componentes de software
requeridos no se encuentra instalado, el asistente ofrecerá instalarlo automáticamente.
12. Se pueden instalar los componentes faltantes de manera automática o manual.
a. Para instalar los componentes faltantes automáticamente, hacer click en Install. El asistente
no interrumpirá el proceso de instalación, e instalará los componentes faltantes durante la
sesión de instalación ya existente.
b. Para instalar los componentes manualmente:
i. Hacer click en Cancel y salir del asistente.
ii. Instalar y habilitar los componentes necesarios manualmente.
iii. Iniciar el asistente nuevamente. Y en el paso System Configuration Check hacer click
en Re-run y repetir la verificación.
13. Si todos los componentes requeridos ya se encuentran instalados, el asistente de instalación de

Veeam saltará el paso System Configuration Check.
14. En el paso Default Configuration, se puede elegir instalar Veeam con los parámetros de instalación
por defecto o especificar parámetros personalizados de instalación. Si se elige una instalación
personalizada, se deberán especificar los siguientes parámetros:
a. Cuenta de servicio: Por defecto se utiliza la cuenta LOCAL SYSTEM (recomendado), pero
es posible utilizar una cuenta a elección.
b. Instancia SQL: Es posible instalar SQL Express como parte de la instalación de Veeam
Backup Server, o utilizar una instancia de SQL Server previamente instalada, ya sea local o
remota.
c. Especificar puertos de servicio o utilizar los puertos por defecto.
d. Especificar la ubicación de instalación para vPowerNFS y para el catálogo (en caso de

utilizar indexación de archivos).
15. Ya con todos los parámetros definidos, podemos comenzar con la instalación dando click a la
opción “Install”.
3.2 Configuración Inicial de Veeam Backup
Una vez tenemos instalado Veeam Backup Server, podemos proceder con la configuración inicial, la
cual incluye entre otros las siguientes operaciones:
• Integración con uno o más hipervisores
• Registrar servidores para roles adicionales de Veeam Backup.
• Configuración/habilitación de Configuration Backup para proteger la configuración de Veeam

Backup.
• Habilitar las notificaciones por e-mail.
3.2.1 Integración con Hipervisores

Una vez completada la instalación de Veeam Backup Server, podemos proceder con la integración de
Veeam con VMware y/o Hyper-V.
Si planeamos proteger VMs sobre vSphere utilizando Jobs de Respaldo y/o Replicación, además de
llevar a cabo cualquier tarea de restauración y/o failback, es necesario en primer lugar registrar la
plataforma vSphere en la infraestructura de respaldo.
Es posible añadir hosts ESXi individuales, así como también instancias de vCenter Server. La
recomendación siempre es preferir la integración mediante vCenter Server, de esta forma si mueven
VMs de un host a otro con vMotion, no será necesario reconfigurar los Jobs de Backup o Replica, ya
que Veeam será capaz de reconocer esta migración, y actualizará los Jobs con dicho cambio, para
luego seguir funcionando de la manera usual.
Para poder registrar una instancia de vCenter Server dentro de Veeam Backup Server debemos seguir
los siguientes pasos:
1. En la vista Backup Infrastructure, hacer click derecho sobre Managed Server y seleccionar “Add
Server”. A continuación, hacer click en VMware vSphere > vSphere.
2. A continuación, debemos ingresar el FQDN o la dirección IP de la instancia vCenter Server. La

recomendación es preferir el uso de FQDN.
3. El siguiente paso del asistente nos permite especificar las credenciales requeridas para conectarnos
con vCenter Server así como el puerto requerido para la comunicación entre Veeam y vCenter
Server.
a. Desde la lista de credenciales, seleccionar una cuenta que tenga privilegios de administración
en vCenter Server. Si no han configurado previamente ninguna credencial con dichos privilegios,
pueden configurar una nueva credencial haciendo click en “Manage Accounts” o en “Add”.
b. Por defecto Veeam utiliza el puerto 443 para comunicarse con vCenter Server y con los hosts
ESXi. En caso de que vCenter Server esté utilizando un puerto distinto al puerto por defecto,
debemos ingresar dicho puerto en este paso.
4. En el último paso debemos verificar que estén todos los parámetros en orden y luego dar click en
Finish.
Una vez finalizado el registro de vCenter Server, tendremos visibilidad a todas las VMs del inventario
de vCenter Server, las cuales luego serán incluidas en uno o más Jobs de Backup, Backup Copy o
Replicación.
3.2.2 Registrar servidores para Proxy o Repositorio

Para poder habilitar el rol de Proxy, Repository Server, Mount Server, Gateway Server y WAN Accelerator,
etc, es necesario previamente haber registrado uno o más servidores Windows en la consola de Veeam
Backup Server. En el caso de Repository Server, también es posible registrar servidores Linux.
1. En la consola de Veeam Backup Server nos dirigimos a la sección “Backup Infrastructure” en el

menú de navegación izquierdo.
2. En el panel de inventario ir a la sección “Managed Servers” y hacer click en la opción “Add Server”.
Aquí debemos seleccionar la opción “Microsoft Windows”.
3. Ingresar el FQDN o dirección IP del servidor que deseamos registrar. La recomendación es utilizar
FQDN. Aquí también podemos proveer una descripción del servidor. Luego hacemos click en Next.
4. El siguiente paso es indicar credenciales con privilegios de administración sobre este servidor.
Podemos utilizar credenciales configuradas previamente (en caso de utilizar la misma credencial
para varios servidores), o podemos añadir nuevas credenciales haciendo click en “Add“ o
en“Manage accounts”.
5. A continuación, en la sección “Review”, revisamos que este todo en orden y hacemos click en
Apply.
6. El asistente procederá a instalar los componentes necesarios sobre el servidor Windows,

específicamente dos servicios:
a. Veeam Installer Service
b. Veeam Data Mover Service.
7. Hacemos click en Finish, con lo cual habremos completado el registro.
Ya que tenemos uno o más servidores registrados en Veeam Backup Server, podremos utilizarlos para
diversos roles, como el rol de Proxy Server, Repository Server, entre otros.
3.2.3 Habilitación de Configuration Backup

Toda la configuración de Veeam Backup Server es almacenada en la base de datos SQL Server
utilizada por la instalación de Veeam. Esta configuración incluye:
• Integración con hipervisores
• Registro de servidores Windows y Linux
• Configuración de Backup Proxy
• Configuración de Repositorios
• Configuración de Jobs (Backup, Backup Copy, Replication, SureBackup, etc.)
• Credenciales de usuario.
• Entre otros.
Es esencial proteger esta información en caso de que un desastre provoque la pérdida del Veeam
Backup Server. Si no contamos con un respaldo de esta configuración, nos veremos obligados a
proceder con una instalación nueva de Veeam Backup & Replication, completamente desde cero.
Para proteger la configuración, podríamos simplemente respaldar la base de datos SQL utilizada por
Veeam Backup Server, pero su recuperación sería un poco menos simple en comparación al uso de
Configuration Backup.
Configuration Backup es un Job de respaldo que permite a Veeam recoger todos los datos de
configuración desde la base de datos, y almacenarlos en un conjunto de archivos XML, los cuales
luego serán archivados en un archivo de respaldo con extensión .BCO. Este Job, como cualquier otro
puede ser ejecutado regularmente de manera automática. Es posible seleccionar cuando el Job se
ejecuta y con qué periodicidad, además de elegir el repositorio donde el Configuration Backup será
almacenado, asi como también definir los parámetros de retención.
IMPORTANTE: Por defecto, los archivos de respaldo creados por el job de Configuration Backup son
almacenados en el Default Backup Repositorio, el cual se encuentra ubicado en el mismo Veeam Backup
Server. No se recomienda en ningún caso que este respaldo quede almacenado en el mismo Veeam
Backup Server que intentamos proteger, por lo que uno de los primeros cambios en la configuración
que debiéramos llevar a cabo, es seleccionar un Repositorio de respaldo diferente, idealmente que se
encuentre ubicado en una ubicación remota.
Para realizar cambios en el Configuration Backup debemos seguir los siguientes pasos:
1. Desde el menú principal de Veeam Backup Server seleccionar Configuration Backup.
2. Asegurarse que la opción Enable configuration backup to the following repository se encuentre
habilitada.
3. Desde la lista Backup repository, elegir el repositorio donde deseamos almacenar el respaldo.
Asegurarse de utilizar un repositorio que no esté ubicado en el mismo Veeam Backup Server.
4. En el campo Restore points to keep, especificamos los puntos de restauración que queremos
mantener en el repositorio (retención). Valor por defecto: 10.
5. Si hacemos click en Schedule podremos modificar el día, la hora, y la frecuencia en que se llevará
a cabo este respaldo.
6. Se recomienda además activar la opción Encrypt Configuration Backup. Esta opción permite
encriptar el respaldo, lo cual a su vez permite que el respaldo incluya todas las credenciales de
usuario utilizadas en la configuración de Veeam, además de las contraseñas asociadas a cada una
de estas credenciales de usuario.
IMPORTANTE: En caso de olvidar la clave de encriptación, la única manera de desencriptar el respaldo

sería mediante el uso de Veeam Enterprise Manager. En caso de que Veeam Enterprise Manager no
haya sido desplegado ANTES de encriptar los respaldos, entonces no habrá forma de desencriptar
dichos respaldos si no se cuenta con la clave de encriptación.
3.2.4 Habilitar Notificaciones por E-mail
1. Desde el menú principal de Veeam Backup Server seleccionar Options. En la siguiente ventana
nos dirigimos al tab “E-Mail Settings”.
2. Aquí podemos habilitar o deshabilitar las notificaciones.
3. En casi de habilitarlas, deberemos especificar:
a. SMTP Server el cual será utilizado para el envío de notificaciones por e-mail. En caso de que el
servidor SMTP requiera autenticación, dichos parámetros los podemos especificar haciendo click en
Advanced.
b. Luego seleccionamos un remitente y un destinatario para las notificaciones.
c. Finalmente definimos un asunto que irá en cada e-mail de notificación enviado por Veeam Backup
and Replication.
4. Luego debemos especificar qué tipo de notificaciones deseamos recibir.
a. En general se recomienda NO habilitar la opción “Notify on success” a menos que sea requerido,
ya que esto generará mucha notifacion por correo, cada vez que un Job finalice exitosamente.
b. La opción “Supress notifications until the last retry” se recomienda dejarla habilitada para reducir
el número de notificaciones recibidas en caso de que un Job falle total o parcialmente, para luego
finalizar exitosamente al segundo o tercer intento (según lo configurado en el Job, respecto a los re-
intentos).
3.3 Veeam Proxy Server
Recordemos, como mencionamos previamente, que el rol de Proxy Server es el de ser el “Músculo”
de la solución. Un Proxy Server es un componente que se ubica entre un origen y un destino de datos.
De esta manera, es el Proxy Server el encargado de obtener los datos que deseamos proteger, por
ejemplo, obteniendo los datos de una VM desde un host ESXi, para luego enviarlos a un destino, por
ejemplo a un Repositorio de respaldos.

Hardware
• CPU: Procesador x86-64, se recomienda un mínimo de 2 Cores. Revisar el apartado de

dimensionamiento en el capítulo anterior para calcular los recursos requeridos según la cantidad
de tareas concurrentes.

capítulo anterior para calcular los recursos requeridos según la cantidad de tareas concurrentes.
• Almacenamiento: 300MB.
• Network: Al menos una conexión de 1Gbps o más rápida para respaldo y replicación local.
Software
• Sistemas operativos soportados para la instalación:
• Microsoft Windows Server 2016 (including versions 1709, 1803)
• Microsoft Windows Vista SP2
3.3.2 Añadir un Proxy Server

El proceso de añadir un nuevo Proxy Server es muy sencillo, ya que no es necesario instalar software
alguno sobre este servidor, sino que simplemente habilitaremos una máquina con Windows desde la
consola de administración de Veeam Backup Server con el rol de Veeam Proxy Server.
Asimismo que ya hemos registrado al menos un servidor Windows en Veeam Backup, al cual le
daremos el rol de Proxy. En caso de no haberlo registrado antes, podremos hacerlo utilizando el
mismo asistente de añadir un nuevo Proxy Server
1. En la barra de menú seleccionamos la opción “Add Proxy”, o hacemos click derecho sobre “Backup
Proxies” y seleccionamos la opción “Add VMware Backup Proxy”.
2. A continuación, deberemos seleccionar el servidor Windows al cual le asignaremos el rol de Proxy

Server. En caso de no haber registrado uno previamente, podemos hacer click en “Add New” para
poder registrar un nuevo servidor Windows.
3. En este mismo paso debemos especificar el “Transport Mode”. Por defecto esta en modo
Automático, por lo que será el mismo Proxy quien decida la mejor forma de comunicarse con el
hipervisor para obtener los datos de la VM durante una operación de respaldo o replicación.
Las opciones son Automatic, Direct Storage Access, Appliance Mode y Network Mode.
NOTA: Si desea saber más de los Modos de Transporte puede revisar el siguiente link: https://goo.
gl/gMn9PW
4. Aquí también podemos especificar los Datastores que estarán conectados con este Proxy a través
de una conexión SAN o NFS. Por defecto Veeam detecta automáticamente todos los Datastores
visibles en un Proxy Server.
5. Por último debemos definir la cantidad máxima de tareas concurrentes que podrá ejecutar un
Backup Proxy. Si este valor se excede, el Proxy Server no iniciará nuevas tareas hasta que una de
las actuales finalice.
a. Veeam crea una tarea por cada disco virtual a respaldar/replicar/restaurar. La recomendación
es tener un Core de CPU por cada tarea concurrente.
b. Con eso en mente, si nuestro proxy tiene 4 Cores de CPU, el número de tareas concurrentes
debiera ser también de 4.
6. El siguiente paso es crear las “Traffic Rules” o Reglas de tráfico, las que nos permiten limitar el
tráfico de salida de un Backup Proxy. Utilizando estas reglas podemos gestionar el ancho de banda
máximo que un Proxy puede utilizar en determinados horarios (definidos por el administrador), y
así minimizar el impacto en la performance de la red de producción.
7. Finalmente damos click en Finish, con lo cual habremos registrado nuestro Proxy Server.
3.4 Veeam Repository Server / Gateway Server
Cuando hablamos de repositorio, hablamos simplemente de una ubicación donde Veeam Backup
and Replication almacenará los archivos de respaldo. Técnicamente hablando, un Repositorio es
simplemente una “carpeta” en un dispositivo de almacenamiento.
En una infraestructura con Veeam Backup and Replication podemos implementar múltiples tipos de
repositorio, considerando que Veeam es totalmente agnóstico con el tipo de almacenamiento utilizado
para almacenar los respaldos, pudiendo por ejemplo utilizar:
• Servidores con discos locales
• Almacenamiento sobre cabina iSCSI o Fiber Channel
• Carpeta compartida via NFS o CIFS
• Appliance de Deduplicación
Independiente del tipo de almacenamiento a utilizar, es necesario contar con un servidor con el rol de
Repository Server, el cual tendrá dos funciones principales:
• Contar con acceso al dispositivo de almacenamiento que utilizaremos como repositorio, por
ejemplo, una LUN vía iSCSI, o simplemente discos locales.
• Proveer el servicio de Data Mover.
NOTA: Con Veeam, toda transferencia de datos requiere del servicio de Data Mover, necesitando un
Data Mover de origen (ej: Proxy Server) y un Data Mover de destino (Ej. Repository Server)

Hardware
• CPU: Procesador x86-64, se recomienda un mínimo de 2 Cores. Revisar el apartado de

dimensionamiento en el capítulo anterior para calcular los recursos requeridos según la cantidad
de tareas concurrentes.

• Network: Al menos una conexión de 1Gbps o más rápida para respaldo y replicación local
Software
• Sistemas operativos soportados para la instalación:
• Microsoft Windows Server 2016 (including versions 1709, 1803, 1809)
• Linux (Se require bash shell, SSH Perl).
NOTA: Mismos requerimientos aplican para un Gateway Server
3.4.2 Añadir un nuevo Repositorio

El proceso de añadir un nuevo Repositorio es muy sencillo, ya que no es necesario instalar software,
sino que simplemente utilizaremos una máquina con Windows previamente registrada desde la consola
de administración de Veeam Backup Server, y que tenga acceso al dispositivo de almacenamiento que
utilizaremos como repositorio.
Asimismo que ya hemos registrado al menos un servidor Windows en Veeam Backup, al cual le daremos
el rol de Repository Server. En caso de no haberlo registrado antes, podremos hacerlo utilizando el
mismo asistente de añadir un nuevo Repositorio.
1. Dirigirse a la sección Backup Infrastructure
2. En el panel de inventario hacer click en Backup Repositories y seleccionar “Add Backup Repository”
3. En la ventana que se abre a continuación deberemos seleccionar el tipo de repositorio que

añadiremos.
• Direct Attached Storage: Servidor Windows/Linux con acceso directo al almacenamiento,

pudiendo ser discos locales, almacenamiento iSCSI o FC, entre otros.
• Network Attached Storage: Carpeta compartida mediante NFS o CIFS/SMB. En este caso se
requerirá también un servidor Windows/Linux para operar como Gateway Server, proveyendo
acceso a la carpeta compartida, así como también el servicio de Veeam Data Mover.
• Deduplication Storage Appliance: Dell EMC Data Domain, HPE StoreOnce, Exagrid, Quantum
DXi. Se requiere también de un Gateway Server.
• Object Storage: On-premises o a través de un proveedor de almacenamiento por objetos en

la Cloud. Solo disponible como “Capacity Tier” en una configuración con Scale-Out Backup
Repository (disponible a partir de Veeam Backup & Replication 9.5 Update 4).
4. En este ejemplo usamos la opción Direct Attached Storage.
5. Ingresamos un nombre y una descripción para el Repositorio.
6. A continuación, seleccionamos el servidor que utilizaremos como Repository Server / Gateway

Server. En caso de no haberlo registrado previamente, lo podemos registrar en este paso con la
opción “Add New”.
7. Hacer click en “Populate” para mostrar una lista de los discos disponibles en este servidor, y su
capacidad libre.
8. En el siguiente paso especificaremos la ruta especifica dentro del disco seleccionado, donde
almacenaremos los respaldos. En este punto también podemos controlar la cantidad de tareas
concurrentes que se pueden ejecutar sobre este repositorio. Si este valor se excede, el Repository
Server no iniciará nuevas tareas hasta que una de las actuales finalice. Revisar el apartado de
diseño para recomendaciones de tareas/Jobs concurrentes.
9. El siguiente paso es especificar el Mount Server. Este componente es requerido para restauraciones
de archivos individuales (Instant file level recovery) y para restauración de ítems de aplicaciones
(Veeam Explorers). Durante dichos proceso de restauración, Veeam montará los discos de la VM
que estamos intentando restaurar desde el archivo de respaldo al Mount Server. Esto reduce la
carga sobre la red y acelera el proceso de restauración.
Usualmente utilizaremos el mismo Repository Server como Mount Server, pero podemos especificar
un servidor alternativo.
10. En este mismo punto podemos habilitar el servicio de vPowerNSF, el cual es esencial para tareas
como Instant VM Recovery, SureBackup y On-Demand Sandbox.
IMPORTANTE: No se recomienda habilitar vPowerNFS en un servidor Windows con servicios

NFS habilitados. Si ambos servicios se encuentras activos, ambos presentarán problemas en su
funcionamiento.
NOTA: Si desea saber más de vPowerNFS y como es utilizado por tarea como Instant VM Recovery,
se recomienda revisar el siguiente link: https://goo.gl/Bpp3Sr
11. Revisamos que este todo en orden y hacemos click en Apply.
12. Una vez que la operación esté finalizada, podemos simplemente hacer click en Finish para cerrar
el asistente.
3.5 Veeam Wan Accelerator
A continuación, hablaremos sobre Veeam WAN Acceleration, un componente de la arquitectura de

Veeam Backup and Replication que permite facilitar y hacer más eficiente la transferencia de datos
entre sitios remotos en tareas de Respaldo (aplica solo a jobs de Backup Copy, no a Jobs de Backup
standard) y Replicación.
Esta característica nos permite enfrentar escenarios donde la conexión entre sitios remotos cuenta
con un ancho de banda limitado, y la cantidad de información a transmitir es importante. El objetivo de
WAN Acceleration entonces es optimizar esta transferencia de datos sobre la WAN.
Para el funcionamiento de Veeam WAN Acceleration, se requiere el uso de servidores con el rol de
WAN Accelerator, uno para cada sitio, los cuales serán responsables de gestionar el Cache Global
y la Deduplicación. Los WAN Accelerators se ubicarán entre los Data Movers de origen y destino
(usualmente Repositorios o Proxy Servers) como vemos en la siguiente imagen.
Veeam WAN Acceleration es compatible además con Veeam Cloud Connect, lo que permite realizar
operaciones de Backup Copy y de Replica utilizando proveedores de Cloud públicos.
NOTA: Si desea saber más de Veeam WAN Accelerator, se recomienda leer el siguiente link: https://
goo.gl/zL51y7

Hardware
• CPU: Procesador x86-64 (depende de su tiene el rol de Source o Target WAN Accelerator. Revisar
el apartado de dimensionamiento en el capítulo anterior para calcular los recursos requeridos
según la cantidad de tareas concurrentes.

• Network: Al menos una conexión de 1Gbps o más rápida para respaldo y replicación local.
Software
• Sistemas operativos soportados para la instalación (64 bits):
• Microsoft Windows Server 2016 (including versions 1709, 1803, 1809)
3.5.2 Añadir un WAN Accelerator

El proceso de añadir un nuevo WAN Accelerator es muy sencillo, ya que no es necesario instalar
software alguno sobre éste servidor, sino que simplemente habilitaremos una máquina con Windows
desde la consola de administración de Veeam Backup Server con el rol de WAN Accelerator.
Asumimos que ya hemos registrado al menos un servidor Windows en Veeam Backup, al cual le
daremos el rol de WAN Accelerator. En caso de no haberlo registrado antes, podremos hacerlo
utilizando el mismo asistente de añadir un nuevo WAN Accelerator.
NOTA: El rol de WAN Accelerator puede ser asignado a servidores que también tengan el rol de
Backup Proxy o de Repository Server. La única recomendación en dicho caso es asegurarse que
el dimensionamiento sea el adecuado, donde se deben sumar los requerimientos de ambos roles
asignados a dicho servidor.
1. Dirigirse a la sección Backup Infrastructure
2. En el panel de inventario hacer click en WAN Accelerators y seleccionar “Add WAN Accelerator”.
3. A continuación, deberemos seleccionar el servidor Windows al cual le asignaremos el rol de WAN

Accelerator. En caso de no haber registrado uno previamente, podemos hacer click en “Add New”
para poder registrar un nuevo servidor Windows.
• En este punto podemos personalizar el puerto TCP utilizado por WAN Accelerator. Por defecto
se utiliza el puerto 6165.
• También podemos especificar el número de Streams (conexiones) que WAN Accelerator

utilizará para transmitir los datos de un sitio a otro.
NOTA: Por defecto se utilizan 5 Streams, pero se puede aumentar este parámetro hasta 100 Streams,
lo cual se debe llevar a cabo con precaución, ya que un exceso de Streams (conexiones) podría
saturar en extremo la conexión WAN, y generar latencia en la red. El aumento de Streams también
genera un mayor uso de CPU y Memoria en los WAN Accelerators.
4. A continuación, se debe seleccionar un directorio donde se ubicará el Caché utilizado por WAN
Accelerator para reducir la cantidad de datos transferidos a través de la conexión WAN.
NOTA: El tamaño del Cache es específico para cada WAN Accelerator de origen. Por ejemplo, si
tendrán 4 WAN Accelerators de origen conectados al mismo WAN Accelerator de destino, el tamaño
del Caché deberá ser multiplicado por 4, ya que el Caché no puede ser compartido entre múltiples
WAN Accelerators.
5. La recomendación es que el Global Cache cuente con al menos 10GB por cada Sistema Operativo
que será copiado entre los sitios remotos.
• Cada versión de Windows cuenta como un Sistema Operativo distinto, por lo que cada una
requiere 10GB para el Global Cache.
• Las distintas versiones de Linux cuentan como un único Sistema Operativo, por lo que se
requiere 10GB para contener los bloques de datos de cualquier versión de Linux en el Global
Cache.
• Adicionalmente se requieren al menos 20GB libres para archivos temporales.
6. Revisamos que este todo en orden y hacemos click en Apply.
7. Una vez que la operación esté finalizada, podemos simplemente hacer click en Finish para cerrar
el asistente.
4. Diseño de Jobs
4.1 Buenas Prácticas
Un punto crucial cuando estamos diseñando e implementando una solución de Backup como Veeam,
es un diseño adecuado de los Jobs de Backup, Backup Copy o Replica. A continuación, mencionaremos
algunas buenas prácticas y recomendaciones a la hora de diseñar y crear estos Jobs.
4.1.1 Máquinas Virtuales por Job

Una duda recurrente de muchos clientes y usuarios es cuantas VMs debieran ser incluidas en un
Job de Backup o Replica. Esto depende un poco del diseño de la solución de Backup, pero algunas
recomendaciones son:
• Incluir no más de 20 o 30 VMs por Job, lo cual permite asegurar que los archivos de respaldo
no sean demasiado grandes, y por lo tanto que sean más fáciles de gestionar por el sistema de
archivos.
• En caso de que decidamos utilizar la opción Per-VM Backup File, podemos aumentar en hasta 10
veces el número de VM por Job, es decir, podemos incluir sin problemas de 200 a 300 VMs por
Job.
NOTA: Veeam ha probado Jobs con hasta 5.000 VMs de manera exitosa, no obstante, la experiencia
de sus ingenieros sugiere que el número adecuado de VMs por Job utilizando Per-VM Backup Files es
de alrededor de 300 VMs.
No son pocos los casos además en que algunos clientes deciden crear Jobs con solo 1 VM, lo cual
tiene varias desventajas que iremos viendo a continuación:
• La administración y operación del día a día se hace más compleja al tener que gestionar un número
mucho más grande de Jobs.
• El número de Jobs tiene un impacto directo en el dimensionamiento de CPU y Memoria para

Veeam Backup Server y para los Repository Server, lo que implica que se requerirán muchos más
recursos de CPU y Memoria para poder ejecutar un mayor número de Jobs de manera concurrente.
• La deduplicación nativa de Veeam es menos efectiva, ya que cada archivo de respaldo contendrá
datos de una única VM, por lo que el número de bloques redundantes será extremadamente
reducido. Esto tiene un impacto directo en el dimensionamiento de los Repositorios.
4.1.2 Cómo agrupar las Máquinas Virtuales en Jobs

No solo es importante el número de VMs que configuremos en cada Job. También es importante definir
como agruparemos estas VMs por Job, es decir, que criterios usaremos para distribuir las VMs en
múltiples Jobs. En general este tipo de decisiones depende de muchos factores, pero aquí tenemos
algunas recomendaciones:
• Agrupar VMs que necesiten las mismas frecuencias de respaldo. Es decir, en primer lugar,
debiéramos considerar las VMs con el mismo RPO para que sean configuradas en el mismo Job.
• Agrupar VMs por sistema operativo. Esto permite mejorar la eficiencia de la deduplicación nativa de
Veeam, ya que al tener archivos de respaldo conteniendo VMs con el mismo sistema operativo, el
número de bloques de datos redundantes será mucho mayor, y por lo tanto, el ahorro en capacidad
de almacenamiento en el Repositorio también será mucho mayor.
• Agrupar VMs según su tipo de aplicación. Esto facilitará contar con una configuración común a nivel
de Job, para todas las VM que requieran procesamiento con consistencia a nivel de aplicaciones,
que requieran respaldo de Transaction Logs, que requieran indexación de archivos, entre otros
posibles requerimientos.
4.1.3 Definir el método de Backup

Es importante definir el método de respaldo que utilizaremos, ya que esto tiene un impacto directo en la
capacidad de almacenamiento requerida en el repositorio, pero también un impacto en la performance
del repositorio.
Recordemos que tenemos tres métodos de backup:
• Forward Incremental
• Forever Forward Incremental
• Reverse Incremental
En general el método de respaldo Forward Incremental es el que tiene el menos impacto en la performance
del Repositorio, pero al mismo tiempo requiere de una mayor capacidad de almacenamiento, ya que
requiere de la creación de respaldos Full periódicos.
Por otro lado, Forever Forward Incremental y Reverse Incremental requieren menos capacidad de
almacenamiento, ya que solo se requerirá la creación de un único respaldo Full, sin la necesidad de
crear respaldos Full periódicos.
NOTA: Si desean una explicación más detallada acerca de los métodos de backup, pueden revisar el
siguiente link: https://goo.gl/ZmU2iB. También pueden leer acerca del impacto de cada uno de estos
métodos de respaldo sobre los Repositorios en el siguiente link: https://goo.gl/5R6DoB
4.1.4 Active Full o Synthetic Full

A la hora de configurar respaldos Full periódicos, debemos definir si utilizaremos Active Full o Synthetic
Full.
Lo primero que debemos tener en claro, es que ambos tipos de respaldo Full contienen la misma
información, tienen el mismo tamaño en el Repositorio, e incluso el archivo tiene la misma extensión
(.VBK). La diferencia fundamental entre ambos tipos de respaldo es la forma en que estos son creados:
• Active Full: El 100% de los datos se obtienen desde el Storage en producción donde las VMs se
encuentran hospedadas.
• Synthetic Full: Parte de los datos (incrementos) son obtenidos desde el Storage en producción
donde las VMs se encuentran hospedadas, mientras que la mayor parte de los datos se obtiene
desde los respaldos previos ya existentes en el Repositorio, consolidando los respaldos anteriores
con los nuevos datos incrementales obtenidos al momento de ejecutar el respaldo Synthetic Full.
En general utilizaremos Active Full en los siguientes casos:
• Utilizamos Appliance de Deduplicación como repositorio de respaldo. Esto es especialmente

importante si el appliance utilizado no cuenta con integración con Veeam.
• Cuando nos preocupa la performance del almacenamiento utilizado como Repositorio, donde tener
un número muy alto de operaciones de I/O podrían generar una alta latencia, aumentando los
tiempos requeridos para completar el respaldo.
En general utilizaremos Synthetic Full en los siguientes casos:
• Cuando el Repositorio utiliza discos rápidos, incluyendo controladoras RAID por hardware con un
cache suficiente para gestionar un gran número de operaciones de I/O.
• Cuando nos preocupa la performance del almacenamiento en Producción donde las VMs están
hospedadas, y donde la ejecución de un respaldo Active Full podría generar una cantidad excesiva
de operaciones de lectura en el Datastore, provocando potenciales problemas de latencia en el
Datastore productivo donde se encuentran las VMs siendo respaldadas.
• Utilizamos Appliance de Deduplicación con integración con Veeam:
• Dell EMC Data Domain con DD Boost
• HPE StoreOnce con Catalyst
• Exagrid
NOTA: Si desea saber en detalle cómo se diferencian los respaldos Active Full y Synthetic Full, y cómo
funcionan en detalle, pueden revisar el siguiente link: https://goo.gl/zzSSf5
NOTA: Si desea saber más acerca del uso de Appliances de Deduplicación como Repositorios de
respaldo, pueden revisar el siguiente link: https://goo.gl/SFM9Xv
4.1.5 Per-VM Backup File

Si bien la opción Per-VM Backup File es un parámetro configurable a nivel de Repositorio, y no en un
Job, esté parámetro tiene un impacto directo en la forma en que se crean los archivos de Backup, y por lo
tanto tiene que ser considerado a la hora de diseñar los Jobs. A continuación, algunas consideraciones
a la hora de utilizar Per-VM Backup File.
• Per-VM Backup File permite la creación de Jobs con un gran número de VMs (recomendable un
máximo de 300 VMs por Job), lo cual facilita la gestión de la infraestructura, al tener que lidiar con
un menor número de Jobs.
• Per-VM Backup File tiene consideraciones a nivel de performance, ya que genera una gran cantidad
de procesos paralelos de escritura, lo cual podría reducir los tiempos en que un respaldo se
completa. Esto también podría tener un impacto negativo en algunas cabinas de almacenamiento,
las cuales pueden no estar diseñadas para procesar tantas tareas en paralelo. En este punto es
importante definir el número máximo de tareas concurrentes por Respositorio, de manera de evitar
problemas de performance.
• Por la manera en que opera la Deduplicación nativa de Veeam, donde Veeam solo eliminará los
bloques de datos redundantes que se encuentran DENTRO de un mismo archivo de respaldo, sin
comparar bloques de datos que se encuentren en distintos archivos de respaldo, el uso de Per-VM
Backup File reducirá al mínimo los ahorros de capacidad provistos por la Deduplicación de Veeam.
Al crear un archivo de respaldo por máquina virtual, Veeam solo podrá eliminar los bloques redundantes
en cada archivo de respaldo individual que, en este caso, contiene datos de una única máquina virtual.
Al no tener múltiples VMs en un mismo archivo de respaldo, el número de bloques redundantes será
inmensamente inferior. Todo esto redunda en una mayor capacidad de almacenamiento requerida en
el repositorio.
4.2 Job de Respaldo (Backup Job)
A continuación, veremos el proceso de creación de un Job de Respaldo o Backup Job, incluyendo

algunas recomendaciones. En primer lugar, nos aseguramos de contar con lo siguiente:
• Integración de Veeam con al menos un hipervisor, VMware o Hyper-V.
• Al menos un Proxy Server
• Al menos un Repositorio con suficiente capacidad de almacenamiento.
• Licencia de Veeam Backup & Replication.
• Si van a configurar el Job con Application-aware processing, se debe contar con credenciales con
privilegios de administración sobre las VMs.
• Si van a respaldar Transaction logs, asegurarse de contar con una cuenta con suficientes privilegios
sobre SQL Server u Oracle.
Los pasos a seguir para crear un Job de Respaldo son los siguientes:
1. Dirigirse al tab Home, hacer click en Backup Job > Virtual machine > VMware vSphere.
2. Ingresar el nombre del Job. Se recomienda diseñar una nomenclatura de nombres que permita
identificar fácilmente el objetivo de este Job y las VM que contiene.
3. Seleccionar las VMs que se desean incluir en este Job de respaldo.
a. Hacer click en Add, con lo cual se abrirá otra ventana para seleccionar las VMs a añadir.
b. En la barra de tareas que vemos algunas opciones, que nos permiten visualizar las VMs
utilizando distintas vistas: Hosts and Clusters, VMs and Templates, Datastores and VMs y
VMs and Tags.
c. A continuación, podemos seleccionar VMs individuales, o contenedores con múltiples VMs.

Podemos seleccionar múltiples VMs en este proceso.
d. También en la parte inferior tenemos un cuadro de búsqueda, que nos facilita encontrar VMs
específicas, lo cual puede ser de mucha utilidad en grandes infraestructuras con cientos o
incluso miles de VMs.
4. Adicionalmente en este punto podemos excluir objetos en el Job de backup:
a. Podemos excluir discos virtuales específicos de una VM.
b. Podemos excluir VMs desde un contenedor de VMs (ej. Carpetas, Datastores, Resource
Pools, etc.)
c. También podemos excluir templates de VM.
5. Finalmente, en este punto también podemos cambiar el orden en que las VMs son procesadas al
momento de ejecutar el Job de Respaldo. Esto podría ser útil si desean respaldar en primer lugar
VMs más críticas.
6. A continuación, podemos especificar el Backup Proxy que deseamos utilizar:
a. El parámetro por defecto es “Automatic Selection”, donde Veeam detectará los Proxies que
tengan acceso al o los Datastores donde se encuentran las VMs, y seleccionara el Proxy más
óptimo para procesar las VMs en el Job.
Veeam asignará Backup Proxies a las VMs incluidas en el Job, una por una. Si hay más de un
Proxy disponible, entonces Veeam analizará el Modo de Transporte disponible en cada Proxy
de manera de seleccionar el Proxy con la conexión más óptima al Datastore. Veeam analizará
además la carga de trabajo en los Proxies, para evitar cuellos de botella al asignar un Proxy
que tenga demasiada carga de trabajo actualmente.
b. Es posible también seleccionar un Backup Proxy manualmente. En este caso se recomienda

que se seleccionen al menos dos Backup Proxies de manera de contar con redundancia. Así,
si uno de los Proxies falla o pierde conexión con el Datastore, el Job de Respaldo puede utilizar
el o los Proxies restantes seleccionados.
7. En este punto también debemos especificar el repositorio que utilizaremos para almacenar los
archivos de respaldo.
a. Un Job solo puede tener asignado un único Repositorio.
b. Podemos utilizar Scale-Out Backup Repository para facilitar la gestión de los Jobs y
Repositorios.
8. Finalmente, en este punto debemos especificar la política de retención para este Job. Básicamente
debemos especificar el número de puntos de Restauración que deseamos mantener.
a. Por ejemplo, si realizaremos un respaldo diario, y deseamos una retención de una semana,
debiéramos configurar 7 puntos de restauración.
b. Del mismo modo, si por ejemplo deseamos realizar respaldos cada 1 hora, con una retención
de un día, debiéramos configurar 24 puntos de restauración.
9. A continuación, si hacemos click en Advance, podremos definir los siguientes parámetros:
a. Modo de backup, pudiendo ser Incremental o Reverse Incremental. Si deseamos utilizar

Forever Forward Incremental, debemos seleccionar la opción “Incremental” y remover las
opciones de Full Backup periódicos.
Aquí también podemos configurar respaldos Full periódicos, utilizando Synthetic Full o Active
Full.
b. Opciones de mantenimiento, por ejemplo, realizar un Health Check periódico de los archivos
de respaldo, de manera de verificar que no exista corrupción de datos. Del mismo modo
podemos configurar la ejecución periódica de una desfragmentación y compactación del
archivo Full Backup, algo que puede ser especialmente útil cuando utilizamos Forever Forward
Incremental o Reverse Incremental.
c. Opciones de almacenamiento:
i. Habilitar o deshabilitar deduplicación nativa de Veeam (por defecto habilitada).
ii. Excluir archivos Swap y/o archivos eliminados.
iii. Configurar el nivel de compresión de los archivos de respaldo.
iv. Habilitar encriptación de los respaldos.
d. Parámetros de notificación relacionados al Job, lo que permite especificar una dirección de

correo donde enviar estas notificaciones, así como también que tipo de notificación deseamos
recibir.
e. Parámetros de vSphere, como por ejemplo habilitar o deshabilitar Change Block Tracking
(CBT)
f. En la sección “Integration” también podremos habilitar el uso de Backup from Storage

Snapshots, siempre que la cabina de almacenamiento lo soporte y se encuentre integrada con
Veeam Backup Server.
g. Por último podemos configurar la ejecución de un script antes y/o después de la ejecución
del Job.
10. En el siguiente paso, opcionalmente podemos asociar este Job de Respaldo con un Job de Backup
Copy, de manera de contar con un respaldo secundario para cumplir con la regla 3-2-1. Hablaremos
de Backup Copy en la siguiente sección.
11. A continuación, debemos especificar los parámetros de procesamiento de las máquinas virtuales:
a. Podemos habilitar Application-aware processing, lo cual permite realizar respaldos

consistentes a nivel de sistema operativo, y opcionalmente habilitar el respaldo de Transaction
Logs. Esta opción la podemos habilitar o deshabilitar para todas las VMs del Job, o solo para
algunas de ellas, lo cual podemos personalizar haciendo click en Applications.
i. Aquí tendremos una lista de las VMs en el Job, donde podremos deshabilitar el
procesamiento a nivel de aplicaciones.
ii. También podemos configurar el uso de Transaction Logs para SQL, donde podemos
respaldar estos Transaction Logs o solo truncarlos. También podemos configurar la
frecuencia de la ejecución del respaldo de Transaction Logs (por ejemplo, cada 15 minutos),
el cual se ejecuta de manera independiente a la ejecución del Job de Respaldo.
iii. Adicionalmente podemos configurar el uso de Transaction Logs para Oracle, donde
podemos respaldar estos Transaction Logs o solo eliminarlos. También podemos configurar
la frecuencia de la ejecución del respaldo de Transaction Logs (por ejemplo, cada 15
minutos), el cual se ejecuta de manera independiente a la ejecución del Job de Respaldo.
Aquí además debemos especificar una cuenta de usuario con privilegios de SYSDBA.
iv. En caso de que la VM a respaldar no sea compatible con Microsoft VSS, podemos
también especificar scripts de pre-freeze y post-thaw para poder llevar a cabo el proceso
de quiescing, y así asegurar la consistencia del respaldo.
b. Aquí además podemos habilitar la opción de Indexación del sistema de archivos, lo que
posteriormente facilitará la búsqueda de archivos individuales que necesitemos restaurar con
Instant File Level Recovery. Debemos tener en consideración que la opción de Indexación
podría extender la ejecución del Job de Respaldo, especialmente si la VM contiene una gran
cantidad de archivos, como sería el caso de un File Server.
c. Finalmente, debemos especificar credenciales de usuario con privilegios de administración

sobre las VMs, lo cual es obligatorio en caso de habilitar Application-aware processing o Guest
file system Indexing. Podemos especificar una sola cuenta de usuario para todas las VMs del
Job, o podemos especificar cuentas individuales por cada VM.
12. Finalmente, debemos especificar cuándo se ejecutará este Job en las opciones de Schedule. Un Job
puede ejecutarse diariamente (todos los días o días específicos), mensualmente, periódicamente
(por ejemplo, cada 1 hora), o después de un Job (no se recomienda encadenar Jobs)
a. Aquí también podemos especificar si se re-intentará la ejecución del Job en caso de producirse
una falla. Por defecto el Job reintentará ejecutarse hasta un máximo de 3 veces, con un tiempo
de espera de 10 minutos entre intentos.
b. Por último, podemos especificar una ventana de respaldo, por ejemplo, que los respaldos
se ejecuten entre las 10 PM y las 8 AM. En este caso, si el Job de respaldo no finaliza dentro
de la ventana de respaldo especificada, el Job será cancelado automáticamente, incluyendo el
procesamiento de todas las tareas en ejecución.
4.3 Job de Copia de Respaldo (Backup Copy Job)
A continuación, veremos el proceso de creación de un Job Backup Copy, incluyendo algunas

recomendaciones.
Con Backup Copy podemos crear varias copias del mismo respaldo y almacenar estas copias en
Repositorios secundarios para almacenamiento de largo plazo (archiving). Estos repositorios
secundarios son repositorios normales, y pueden estar ubicados en el mismo sitio que el Repositorio
primario, o puede estar en una ubicación remota (recomendado). Debemos considerar además que
los archivos de respaldo creados por Backup Copy tienen el mismo formato que los archivos creados
por un Job de Respaldo, por lo que los datos pueden ser restaurados directamente desde un Backup
Copy en caso de ser necesario.
Backup Copy no copia el archivo de respaldo completo (archivo .VBK, VIB o VRB) desde un repositorio
a otro, sino que copia los datos por cada máquina virtual a nivel de bloques. Es decir, cuando el proceso
de Backup Copy comienza, Veeam accederá al archivo de Respaldo en el Repositorio de origen,
obtiene los bloques de datos de la VM especifica que quiere copiar desde el archivo de Respaldo, y los
copia en el Repositorio secundario.
Debido a la forma en que Backup Copy funciona, no se genera ningún impacto sobre la infraestructura
virtual o las máquinas virtuales en sí. Backup Copy simplemente copiará datos de un Repositorio a
otro, sin interactuar con el hipervisor, por lo que no se requiere de Snapshots, ni de la interacción con
VSS, entre otros.
Un Job de Backup Copy puede contener una o multiples VMs, en cuyo caso las VMs serán procesadas
en paralelo al momento de ejecutar el Job. Si una VM tiene múltiples discos virtuales, los discos son
procesados secuencialmente, uno detrás de otro.
Los pasos a seguir para crear un Job de Backup Copy son los siguientes:
1. Dirigirse al tab Home, hacer click en Backup Copy > Virtual machine > VMware vSphere.
2. Al iniciar el asistente debemos especificar un nombre y descripción para el Job de Backup Copy.
Se recomienda diseñar una nomenclatura de nombres que permita identificar fácilmente el objetivo
de este Job y las VM que contiene.
Aquí también debemos especificar qué tan seguido se ejecutará el Job de Backup Copy. Un
Job de Backup Copy se ejecuta continuamente, donde el proceso de sincronización se inicia a
intervalos específicos de tiempo, por defecto el intervalo de ejecución de Backup Copy es de 1 día.
Esto significa que el job de Backup Copy creará un nuevo intervalo de Backup Copy una vez al día.
Durante el intervalo de Backup Copy, Veeam verificará si hay nuevos puntos de restauración
disponibles en el Repositorio de origen, y en caso de haberlos, copiara estos nuevos puntos de
restauración disponibles desde el Repositorio de origen hacia el Repositorio de destino.
3. Luego debemos seleccionar las VM que serán parte de este Job de Backup Copy. Debemos
destacar en primer lugar, que las VMs incluidas en un Job de Backup Copy no necesitan coincidir
con las VMs incluidas en un Job de Respaldo. El único requisito en este caso es que la o las VMs
deben estar incluidas en el menos un Job de Respaldo. Podemos seleccionar VMs desde
a. La infraestructura virtual. Cuando el Job se ejecuta, Veeam buscará todos los puntos de
restauración de dicha VM en todos los Repositorios disponibles.
b. Desde los respaldos. Cuando el Job se ejecuta, Veeam buscará todos los puntos de
restauración de dicha VM en todos los respaldos creados por Veeam.
c. Desde un Job de respaldo. Cuando el Job se ejecuta, Veeam buscará todos los puntos de
restauración de dicha VM en los respaldos creados por dicho Job.
Adicionalmente en este punto podemos excluir VMs en el Job de Backup Copy.
NOTA: Es posible limitar los Repositorios desde donde el Job de Backup Copy obtendrá los datos de
las VM a ser copiadas al Repositorio Secundario, en caso de que las VMs se hayan añadido al Job
usando las opciones “From Infrastructure” y “From Backups”. De esta forma, Backup Copy buscará
nuevos puntos de restauración solo en los Repositorios seleccionados. Por defecto Veeam buscará
nuevos puntos de restauración en todos los Repositorios disponibles (No aplica para VMs añadidas a
partir de un Job de Respaldo).
4. El siguiente paso nos permite definir varios parámetros:
a. En primer lugar, podemos especificar el Repositorio donde serán almacenados los respaldos
creados por el Job de Backup Copy.
b. Luego debemos especificar el número de puntos de restauración que utilizará el Job de

Backup Copy. Por defecto Backup Copy se ejecutará diariamente, por lo que, si especificamos
7 puntos de restauración, significa que tendremos una retención de Días.
NOTA: La cadena de respaldo creada por Backup Copy es equivalente a una cadena de
respaldo utilizando Forever Forward Incremental, por lo cual existirá solo un respaldo Full en
la cadena de respaldo creada por Backup Copy en el repositorio secundario. Esto además
recuerden puede tener un impacto en la performance del Repositorio.
c. En caso de requerir una retención más prolongada, podemos utilizar el esquema GFS
(Grandfather, Father, Son), donde el Job de Backup Copy podrá crear respaldos full periódicos,
que pueden ser semanales, mensuales, trimestrales y/o anuales.
Podemos configurar por ejemplo 4 respaldos semanales, 12 respaldos mensuales, y 3 respaldos

anuales, de manera de tener 3 años de retención de los respaldos.
Los respaldos con GFS pueden ser programados para ser ejecutados en días específicos de la
semana o del mes. Por ejemplo, ejecutar los respaldos mensuales el último domingo de cada
mes.
a. Opciones de mantenimiento, por ejemplo, realizar un Health Check periódico de los

archivos de respaldo, de manera de verificar que no exista corrupción de datos. Del mismo
modo podemos configurar la ejecución periódica de una desfragmentación y compactación del
archivo Full Backup, algo que puede ser especialmente útil cuando utilizamos Forever Forward
Incremental o Reverse Incremental.
b. Opciones de almacenamiento:
i. Habilitar o deshabilitar deduplicación nativa de Veeam (por defecto habilitada).
ii. Configurar el nivel de compresión de los archivos de respaldo.
iii. Habilitar encriptación de los respaldos.
c. Parámetros de notificación relacionados al Job, lo que permite especificar una dirección de

recibir.
d. En la sección “Integration” también podremos habilitar el uso de Backup from Storage

e. Por último, podemos configurar la ejecución de un script antes y/o después de la ejecución
del Job.
6. El siguiente punto nos permite especificar si el Job de Backup Copy realizará la copia de los
respaldos de manera directa de un Repositorio a otro, o utilizando WAN Accelerator:
a. La copia Directa permite que los datos de las VMs sean movidos desde un Repositorio a otro
sin interacción de otros componentes. Este método es recomendado para copias de respaldos
dentro del mismo sitio (on-site), o para copias a sitios remotos a través de una conexión de red
de alta velocidad.
b. La copia vía WAN Accelerator permite el uso de un par de WAN Accelerators (uno en cada
sitio) para ahorrar ancho de banda y acelerar la ejecución de Backup Copy. Este método es
recomendado cuando no contamos con un suficiente ancho de banda en la conexión entre
ambos sitios.
NOTA: Si desea saber más sobre el funcionamiento de Veeam WAN Acceleration, pueden
revisar el siguiente link: https://goo.gl/zL51y7
7. Finalmente debemos especificar una ventana de respaldo en la cual el Job de Backup Copy podrá
ejecutarse. Recuerden que por defecto el Job de Backup Copy se ejecuta en intervalos de 1 día,
y con esta opción podemos restringir en qué momento del día se procederá con la copia de los
respaldos. No es posible especificar un horario específico para la ejecución de un job de Backup
Copy.
8. Finalmente verificamos que todos los parámetros estén en orden, pudiendo habilitar de inmediato
el Job para que comience a ejecutarse, y hacemos click en Finish para finalizar.
4.4 Job de Réplica
Veeam Backup & Replication, como su nombre lo dice, no solo puede ser utilizado para respaldar
máquinas virtuales, sino que también podemos crear Replicas de máquinas virtuales. Al igual que con
los respaldos, las operaciones de réplica se ejecutan sin requerir ningún tipo de agente dentro del
sistema operativo de la VM, apalancando el uso de los Snapshots de VM en VMware.
La replicación con Veeam funciona de manera similar a un respaldo incremental, es decir, durante
la primera replicación de una VM, Veeam copia los datos de la VM ejecutándose en el host ESXi de
origen, y crea una réplica completa en el host ESXi de destino. Luego, las siguientes replicaciones
enviarán solo los cambios que se han producido en la VM desde la anterior replicación, de manera
similar a un respaldo incremental, apalancando también el uso de Change Block Tracking (CBT).
A diferencia de los respaldos, una réplica de una VM es una VM estándar que se mantiene en formato
nativo en el host ESXi de destino, por lo que al ejecutar un Failover, la VM replica puede ser encendida
de inmediato y estar operativa en pocos minutos, permitiendo cumplir RTOs muy exigentes.
Es posible utilizar un job de Replicación para replicar una VM localmente en el mismo Datacenter. Esta
modalidad permite de cierta manera proveer de un mecanismo de alta disponibilidad (HA) a VMs cuyos
sistemas operativos y/o aplicaciones no cuentan con mecanismos nativos de HA o Clustering.
Del mismo modo, podemos utilizar un Job de Replicación para replicar una VM a un sitio remoto, de
manera de proteger la VM en caso de un desastre que provoque la caída del Datacenter completo.
Para crear un Job de Replicación en Veeam deberemos seguir un simple proceso:
1. Dirigirse al tab Home, hacer click en Replication Job > Virtual machine > VMware vSphere.
2. Ingresar el nombre del Job. Se recomienda diseñar una nomenclatura de nombres que permita
identificar fácilmente el objetivo de este Job y las VM que contiene. En este punto también existen
algunas opciones adicionales en caso de que planeemos replicar una VM a un sitio remoto:
a. Low Connection Bandwidth: Habilita el uso Replica Seeding, lo cual permite utilizar un
respaldo ya existente en el sitio remoto, de manera de crear la primera replica principalmente a
partir de este respaldo, reduciendo la cantidad de datos que se debe enviar a través de la WAN,
al requerir solo enviar los datos incrementales necesarios, que representan los cambios en los
datos de la VM desde que el respaldo fue creado.
b. Separate Virtual Networks: Si las redes en el sitio remoto no coinciden con las redes en
producción, es posible crear una tabla de Network Mapping para resolver esta inconsistencia.
Básicamente le decimos a Veeam cual PortGroup en el sitio remoto corresponde a determinado
PortGroup en el sitio de Producción.
c. Different IP Addressing Scheme: Permite crear reglas de re-IP para VMs utilizando Sistema
operative Windows. Esto puede ser útil si los segmentos de red utilizados en el sitio local
y el sitio remoto no son los mismos. De esta manera, al realizar un Failover, Veeam podría
reemplazar la IP original de la VM Replica, por una IP valida en el sitio remoto, utilizando las
reglas de re-IP para lograrlo.
3. Seleccionar las VMs que se desean incluir en este Job de Replicación.
a. Hacer click en Add, con lo cual se abrirá otra ventana para seleccionar las VMs a añadir.
b. En la barra de tareas que vemos algunas opciones, que nos permiten visualizar las VMs
utilizando distintas vistas: Hosts and Clusters, VMs and Templates, Datastores and VMs y
VMs and Tags.
c. A continuación, podemos seleccionar VMs individuales, o contenedores con múltiples VMs.

Podemos seleccionar múltiples VMs en este proceso.
d. También en la parte inferior tenemos un cuadro de búsqueda, que nos facilita encontrar VMs
específicas, lo cual puede ser de mucha utilidad en grandes infraestructuras con cientos o
incluso miles de VMs.
4. Adicionalmente en este punto podemos excluir objetos en el Job de Replicación:
a. Podemos excluir discos virtuales específicos de una VM.
b. Podemos excluir VMs desde un contenedor de VMs (ej. Carpetas, Datastores, Resource
Pools, etc.)
5. Finalmente, en este punto también podemos especificar desde donde el Job obtendrá los datos
para crear la replica:
a. Desde el almacenamiento en producción (por defecto). En este caso, Veeam leerá los datos
de las VMs desde el almacenamiento en producción, utilizando alguno de los métodos de
transporte soportados.
b. Desde archivo de respaldo (Remote replica from backup). Permite crear replicas (full e
incrementales) a partir de respaldos previamente creados.
6. A continuación, deberemos seleccionar el destino donde la réplica será creada:
a. En primer lugar, debemos seleccionar un host ESXi o vSphere Clúster de destino. Este host
ESXi debe haber sido registrado previamente en Veeam Backup Server, ya sea a través del
registro de vCenter Server, o el registro del host ESXi directamente.
b. Luego debemos seleccionar el Resource Pool al cual pertenecerá la réplica. Podemos

especificar un Resource Pool para todas las VMs del Job, o utilizar Resource Pools distintos
para cada máquina virtual.
c. A continuación, debemos seleccionar la carpeta a la cual pertenecerá la réplica. Podemos

especificar una Carpeta para todas las VMs del Job, o utilizar Carpetas distintas para cada
máquina virtual.
d. Por último, debemos seleccionar el Datastore donde la máquina virtual será almacenada.
Podemos especificar un Datastore para todas las VMs del Job, o utilizar Datastores distintos
para cada máquina virtual.
7. El siguiente paso es crear los Network Mappings o asociación de redes. Si las redes en el sitio
remoto no coinciden con las redes en producción, es posible crear una tabla de Network Mapping
para resolver esta inconsistencia. Básicamente le decimos a Veeam cual PortGroup en el sitio
remoto corresponde a determinado PortGroup en el sitio de Producción.
8. A continuación, podemos crear también reglas de re-IP para VMs utilizando Sistema operativo
Windows. Esto puede ser útil si los segmentos de red utilizados en el sitio local y el sitio remoto no
son los mismos. De esta manera, al realizar un Failover, Veeam podría reemplazar la IP original
de la VM Replica, por una IP valida en el sitio remoto, utilizando las reglas de re-IP para lograrlo.
9. En este punto también debemos especificar algunos parámetros adicionales requeridos por el Job
de Replicación:
a. Debemos especificar el repositorio que utilizaremos para almacenar la metadata generada

por el Job de Replicación.
i. Un Job solo puede tener asignado un único Repositorio.
ii. No se puede utilizar Scale-Out Backup Repository para la metadata de las réplicas.
b. A continuación, debemos elegir un sufijo a utilizar por las réplicas. Esto permitirá diferenciar
entre la VM original y la VM replica.
c. Finalmente, en este punto debemos especificar la política de retención para este Job.
Básicamente debemos especificar el número de puntos de Restauración que deseamos
mantener en la réplica.
i. Por ejemplo, si realizaremos una réplica diaria, y deseamos una retención de una semana,
debiéramos configurar 7 puntos de restauración.
ii. Del mismo modo, si por ejemplo deseamos realizar replicas cada 1 hora, con una retención
de un día, debiéramos configurar 24 puntos de restauración.
a. Opciones de Trafico:
i. Excluir archivos Swap y/o archivos eliminados.
ii. Configurar el nivel de compresión de los archivos de respaldo.
iii. Optimizaciones de almacenamiento.
b. Parámetros de notificación relacionados al Job, lo que permite especificar una dirección de

recibir.
c. Parametros de vSphere, como por ejemplo habilitar o deshabilitar Change Block Tracking
(CBT)
d. En la sección “Integration” también podremos habilitar el uso de Backup from Storage

e. Por último podemos configurar la ejecución de un script antes y/o después de la ejecución
del Job.
11. El siguiente punto nos permite especificar si el Job de Replicación realizará la copia de los respaldos
de manera directa de un host ESXi a otro, o utilizando WAN Accelerator:
a. La copia Directa permite que los datos de las VMs sean movidos desde un host ESXi a otro
sin interacción de otros componentes. Este método es recomendado para replicación dentro
del mismo sitio (on-site), o para replicación a sitios remotos a través de una conexión de red
de alta velocidad.
b. La copia vía WAN Accelerator permite el uso de un par de WAN Accelerators (uno en cada
sitio) para ahorrar ancho de banda y acelerar la ejecución de un Job de Replicación. Este
método es recomendado cuando no contamos con un suficiente ancho de banda en la conexión
entre ambos sitios.
NOTA: Si desea saber más sobre el funcionamiento de Veeam WAN Acceleration, pueden revisar el
siguiente link: https://goo.gl/zL51y7
12. El siguiente paso es la posibilidad de habilitar Replica seeding o Replica Mapping:
a. Replica Seeding permite utilizar un respaldo ya existente en el sitio remoto como semilla,
de manera de crear la primera replica principalmente a partir de este respaldo, reduciendo la
cantidad de datos que se debe enviar a través de la WAN, al requerir solo enviar los datos
incrementales necesarios, que representan los cambios en los datos de la VM desde que el
respaldo fue creado.
b. Replica Mapping permite utilizar una máquina virtual ya existente en el sitio remoto como
semilla, de manera de crear la primera replica principalmente a partir de esta máquina virtual,
reduciendo la cantidad de datos que se debe enviar a través de la WAN, al requerir solo enviar
los datos incrementales necesarios, que representan las diferencias entre la VM que deseamos
replicar, y la VM que estamos utilizando como semilla.
13. A continuación, debemos especificar los parámetros de procesamiento de las máquinas virtuales:
a. Podemos habilitar Application-aware processing, lo cual permite realizar replicas consistentes

a nivel de sistema operativo, y opcionalmente habilitar el procesamiento de Transaction Logs.
Esta opción la podemos habilitar o deshabilitar para todas las VMs del Job, o solo para algunas
de ellas, lo cual podemos personalizar haciendo click en Applications.
i. Aquí tendremos una lista de las VMs en el Job, donde podremos deshabilitar el
procesamiento a nivel de aplicaciones.
ii. También podemos configurar el uso de Transaction Logs para SQL, donde podemos
elegir truncar o no estos Transaction Logs.
iii. Adicionalmente podemos configurar el uso de Transaction Logs para Oracle, donde
podemos elegir su eliminar o no estos Transaction Logs. Aquí además debemos especificar
una cuenta de usuario con privilegios de SYSDBA.
iv. Podemos además especificar que ciertas carpetas o archivos sean excluidos del proceso
de réplica, como por ejemplo la carpeta de archivos temporales.
v. En caso de que la VM a replicar no sea compatible con Microsoft VSS, podemos también
especificar scripts de pre-freeze y post-thaw para poder llevar a cabo el proceso de
quiescing, y así asegurar la consistencia de la réplica.
b. Finalmente, debemos especificar credenciales de usuario con privilegios de administración

sobre las VMs, lo cual es obligatorio en caso de habilitar Application-aware processing o Guest
file system Indexing. Podemos especificar una sola cuenta de usuario para todas las VMs del
Job, o podemos especificar cuentas individuales por cada VM.
14. Finalmente, debemos especificar cuándo se ejecutará este Job en las opciones de Schedule. Un Job
puede ejecutarse diariamente (todos los días o días específicos), mensualmente, periódicamente
(por ejemplo, cada 1 hora), o después de un Job (no se recomienda encadenar Jobs)
a. Aquí también podemos especificar si se reintentará la ejecución del Job en caso de producirse
una falla. Por defecto el Job reintentará ejecutarse hasta un máximo de 3 veces, con un tiempo
de espera de 10 minutos entre intentos.
b. Por último, podemos especificar una ventana de ejecución para el Job de Replica, por
ejemplo, que los respaldos se ejecuten entre las 10 PM y las 8 AM. En este caso, si el Job
de respaldo no finaliza dentro de la ventana de respaldo especificada, el Job será cancelado
automáticamente, incluyendo el procesamiento de todas las tareas en ejecución.
15. Como último paso hacemos click en Finish, y ya tendremos nuestro Job de Replicación listo para
ser utilizado.
5. Opciones de Restauración
En esta sección revisaremos algunas de las opciones de recuperación que tenemos con Veeam
Backup and Replication.
Podemos utilizar Veeam para restaurar una VM completa de dos formas: Restauración full o Instant
VM Recovery.
5.1 Restauración Full de una VM
El tipo de restauración más tradicional y simple. Utilizando este tipo de restauración, todos los datos
que componen la VM serán copiados desde el Repositorio hacia el almacenamiento en producción.
Este tipo de restauración puede tomar mucho tiempo y consumir considerables recursos, ya que
estaremos transfiriendo grandes cantidades de datos dependiendo del tamaño de la máquina virtual.
Del tamaño de la máquina virtual también dependerá el tiempo que tarde el proceso de restauración
para ser completado.
Durante la restauración, el Proxy elegirá automáticamente el método de transporte más adecuado

para proceder con la copia de los datos al almacenamiento en producción, pudiendo utilizar Direct
Storage Access, Virtual Appliance mode, o Network mode.
Una VM puede ser restaurada a su ubicación original, en cuyo caso la VM original será apagada
y removida antes de restaurar la VM desde el respaldo. Una VM también puede ser restaurada a
una ubicación alterna, especificando host ESXi, Datastore y un nombre para la VM, el cual no debe
coincidir con el nombre de otras VMs en el inventario.
NOTA: Al restaurar la VM a la ubicación original, puede también usarse la opción “Quick Rollback”, la
cual básicamente realiza una restauración incremental sobre la VM que ya existe en el inventario de
vCenter Server.
El proceso de restauración requiere de los siguientes pasos:
1. En el tab Home, click Restore > VMware vSphere > Restore from backup > Entire VM restore
> Entire VM restore.
2. Seleccionar la o las VMs que deseamos restaurar.
3. Seleccione el punto de restauración que desea recuperar, pudiendo ser de un respaldo full o
incremental.
4. Seleccione el modo de restauración, pudiendo restaurar a la ubicación original, o a una ubicación

alterna. También a partir de Veeam Backup & Replication 9.5 Update 4, tenemos una nueva opción
llamada “Staged Restore”. Si quieren saber más acerca de Staged Restore, pueden revisar el
siguiente link: https://goo.gl/Z8Ae5n
5. Si se ha seleccionado la restauración en una ubicación alterna, se deberán especificar los siguientes

parámetros:
a. Host ESXi donde restaurar la VM.
b. Resource Pool donde será ubicada la VM.
c. Datastore donde la VM será almacenada. Se puede elegir un Datastore separado por cada
disco virtual si se requiere, además de poder elegir el formato del disco virtual (Thin o Thick
provisioned).
d. Carpeta donde la VM será ubicada.
e. Especificar el PortGroup al cual la VM será conectada.
6. Es posible también activar el uso de Secure Restore, lo cual permite analizar la VM restaurada con
una solución anti-malware antes de realizar la restauración como tal en el ambiente productivo.
Más información sobre Secure Restore en el siguiente link: https://goo.gl/ST7hsj
7. Podemos además activar el uso de Staged Restore, el cual permite manipular la VM antes de
realizar la restauración en el ambiente productivo. Esta función apalanca las funciones de Virtual
Lab y vPowerNFS para funcionar. Mayor información sobre Staged Restore en el siguiente link:
https://goo.gl/Z8Ae5n
8. Finalmente ingresamos las razones de ejecución de esta restauración, con lo cual Veeam procederá
con la restauración de la VM completa.
5.2 Restauración con Instant VM Recovery
Restaurar una VM completa, dependiendo de su tamaño, puede tardar horas, tiempo en el que los
usuarios no pueden acceder a los servicios afectados por la falla.
Para poder acelerar este proceso, y poder tener los servicios operativos a la brevedad posible, Veeam
nos ofrece Instant VM Recovery, una funcionalidad que permite tener una VM operativa en cosa
de minutos a partir de un respaldo. Para esto se utilizan tecnologías y técnicas desarrolladas
directamente por Veeam.
Instant VM Recovery nos permite restaurar inmediatamente una VM en un ambiente de producción

ejecutando la máquina virtual directamente desde el archivo de respaldo. La VM en sí misma no es
restaurada directamente al Storage de producción (datastore), sino que Veeam buscará encenderla en
un host ESXi mientras que los archivos que componen la VM se encuentran aún en el Repositorio de
Respaldo en estado deduplicado y comprimido.
Debido a que no se necesita extraer la VM desde el archivo de respaldo y copiarlo en el Storage de

producción, se puede iniciar la VM desde cualquier punto de restauración, ya sea Full o Incremental,
en cosa de minutos, mejorando el RTO y minimizando el downtime de las VMs en producción. De esta
forma, una VM restaurada con Instant VM Recovery permite que los usuarios puedan volver a usar los
servicios en Producción, mientras que resolvemos el problema que provocó la falla en la VM original.
NOTA: Si quiere saber más en detalle el funcionamiento de Instant VM Recovery, pueden ver el
siguiente link: https://goo.gl/Bpp3Sr
La restauración de una VM con Instant VM Recovery es un proceso bastante simple, y lo podemos
resumir en los siguientes pasos:
1. Lanzamos el asistente de restauración.
2. Seleccionamos la opción “Instant VM recovery”
3. Seleccionamos la o las VM que queremos recuperar con IVMR
4. Seleccionamos el punto de restauración a utilizar
5. Seleccionamos si deseamos restaurar la VM a su ubicación original, lo cual además incluye la

eliminación de la VM original en vSphere, o si vamos a restaurar la VM a una ubicación alterna
donde podemos especificar distintos parámetros, incluyendo el nombre de la VM.
6. Si seleccionamos una ubicación alterna debemos especificar el host ESXi y Datastore a utilizar,
además de especificar el nombre con el que la VM será restaurada.
7. Es posible también, de manera opcional, especificar un datastore para almacenar los bloques que
hayan cambiado durante la ejecución de Instant VM Recovery. Por defecto estos cambios son
almacenados en un cache de vPowerNFS.
8. Ingresamos un detalle de las razones para la restauración para efectos de auditoria.
9. Y por último especificamos si la VM deberá ser encendida y conectada a la red una vez que sea
restaurada con IVMR.
Instant VM Recovery es solo una restauración temporal de una VM, ya que no podemos dejarla
corriendo permanentemente desde vPower NFS, por dos razones principales:
• La performance de la VM no será comparable a la de una VM completamente en Producción,

ya que estaremos utilizando un archivo de respaldo que se encuentra en estado comprimido y
deduplicado, y en un Repositorio de Respaldo cuyo diseño no está necesariamente optimizado
para performance, sino para capacidad.
• La VM depende de que el servidor vPower NFS se encuentre operativo para que se mantenga
en funcionamiento. Si el servidor vPower NFS falla o deja de funcionar por cualquier motivo, la VM
recuperada con Instant VM Recovery dejará de funcionar inmediatamente.
Entonces lo importante ahora es definir cómo mover de forma permanente esta VM a producción, sin
perder los cambios realizados durante el tiempo que la VM ha estado funcionando sobre vPower
NFS, finalizando así la sesión de Instant VM Recovery. Esto lo podemos conseguir con una de las
siguientes 3 técnicas:
• Storage vMotion: Se puede usar Storage vMotion para migrar la VM restaurada desde el datastore
vPower NFS al Storage en Producción sin ningún downtime. En este caso, la data de la VM será
movida desde el repositorio de respaldo (a través de vPower NFS) a Producción, consolidando

además los cambios realizados mientras la VM se encontraba funcionando con IVMR.
• Replicar o copiar la VM con las funcionalidades nativas de Veeam. En este caso, al finalizar la
copia/replica se debe realizar una operación de Failover, lo cual requiere un periodo de downtime
mientras se copia/replica la VM, se apaga la VM con IVMR, y se enciende la VM copiada/replicada.
• Quick Migration: Veeam restaurará la VM desde el Backup Repository al storage de Producción,

sin el uso de vPower NFS, utilizando una restauración tradicional. El estado de la VM y los cambios
que se han producido mientras la VM se encontraba en ejecución con IVMR serán movidos a la
nueva ubicación donde se está realizando la restauración. Este proceso asegura un downtime
mínimo durante la migración.
NOTA: Si quiere saber más en detalle el funcionamiento de Instant VM Recovery, pueden ver el
siguiente link: https://goo.gl/Bpp3Sr
6. Conclusión
Durante este capítulo de respaldos, hemos revisado múltiples conceptos asociados al proceso de
protección de datos en un Datacenter, así como también algunas recomendaciones y buenas prácticas.
Del mismo modo, hemos podido analizar múltiples recomendaciones de diseño y dimensionamiento
específicos para Veeam Backup & Replication. Si bien es imposible cubrir todas las opciones ofrecidas
por Veeam en este capítulo, se ha hecho lo posible por incluir la información que puede ser de mayor
utilidad a la hora de diseñar e implementar Veeam Backup & Replication.
Si desean saber más acerca de Veeam, y de todas las opciones y funcionalidades disponibles, les
recomiendo leer:
1. Documentación oficial de Veeam Backup & Replication para vSphere: https://helpcenter.veeam.

com/docs/backup/vsphere/overview.html?ver=95u4
2. Documento de buenas prácticas de Veeam: https://bp.veeam.expert
Vembu BDR Suite
No mas complicaciones con el backup
Podría tener actualmente maquinas virtuale o considerar
desplegarlas en un futuro.
Cómo protegería esas maquinas para habilitar la Continuidad
del Negocio?
Está su sistema preparado para fallos inesperados?
Debe tener un plan de acción - BACKUP
Una solución de protección de datos todo incluido para entornos vSphere

“Vembu asegura disponibilidad en nuestros entornos principales de producción que dan soporte a las operaciones de negocio del Grupo
Mackie. Disponibilidad 24x7 en las aplicaciones y sus datos es algo crítico para nosotros, Vembu cumple con nuestros requerimientos.
Vembu se ha convertido en un componente imprescindible en nuestra estrategia de continuidad de negocio de TI.”
- Lee Wong, responsable de Servicios de TI en el grupo Mackie
Backup GRATUITO Ilimitado de Maquinas Virtuales

vembu.com/vembu-bdr-suite-download/
Principales Características
Backup y Replicación sin agentes para Recuperación garantizada con la
proteger todo su entorno vSphere verificación automática del backup
Comience a proteger sus maquinas en menos de 15 Opciones flexibles de backup como app-aware, incremental,
minutos con opciones de recuperación instantánea y políticas de programación y retención y muchas mas…
granular
Capítulo 10
Monitorización de vSphere
Jorge de la Cruz
Capítulo 10 - Monitorización de vSphere Jorge de la Cruz
Monitorización de entornos vSphere
Cuando hablamos de monitorización de vSphere, nos puede venir a la mente diferentes productos,
formas de monitorizar, capas que nos interesa tener controladas, etc.
En este libro vamos a hablar de diferentes maneras de monitorizar nuestro clúster de vSphere, desde
el metal o servidor ESXi que nos otorga la abstracción de recursos de hardware, hasta las aplicaciones
que se ejecutan en las VMs, gracias a las VMware Tools.
Cuando hablamos de monitorización, nos vamos a referir a la habilidad de poder visualizar los eventos
y alarmas de las diferentes capas dentro de nuestro entorno de vSphere, no solamente esto, sino que
además gracias a herramientas como vRealize Operations Manager, vamos a tener una inteligencia
del consumo de recursos durante un periodo de tiempo, y poder crear simulaciones de cargas de
trabajo durante un periodo de tiempo en el futuro.
Si bien este libro no puede abarcar la infinidad de productos comerciales y open source que se
encuentran disponibles a día de hoy para vSphere, vamos a poder analizar en profundidad vRealize
Operations Manager, ESXTOP para monitorización muy a bajo nivel dentro de nuestro hipervisor y
veremos también un ejemplo práctico usando una herramienta de monitorización open source que
hace uso del SDK de VMware.
1. Monitorizando el rendimiento de vSphere con las

gráficas de vCenter Server
Las alarmas son una gran herramienta para alertar a los administradores de condiciones o eventos
específicos, pero las alarmas no proporcionan la información detallada que los administradores a veces
necesitamos tener. Aquí es donde entran en juego los gráficos de rendimiento de vCenter Server.
vCenter Server tiene muchas funciones nuevas y actualizadas para crear y analizar gráficos. Sin estos
gráficos, el análisis del rendimiento de una máquina virtual sería más complicado y necesitaríamos
siempre herramientas de terceros. La instalación de agentes dentro de una máquina virtual no
proporcionará detalles precisos sobre el comportamiento del servidor ESXi o el consumo de recursos
de un clúster. La razón es obvia: una máquina virtual se configura sólo con dispositivos virtuales y es
una abstracción de Hardware. Sólo el VMkernel de VMware conoce la cantidad exacta de consumo de
recursos para cualquiera de esta abstracción de recursos porque actúa como árbitro entre el hardware
virtual y el hardware físico. En la mayoría de los entornos virtuales, los dispositivos virtuales de las
máquinas virtuales pueden superar en número a los dispositivos de hardware físicos reales, lo que
conocemos como consolidation ratio, lo que requiere las complejas capacidades de compartición y
programación del VMkernel.
Al hacer clic en la pestaña de Performance dentro de nuestro Datacenter en nuestro vSphere Client
HTML5 o dentro de un clúster, host o máquina virtual, podemos obtener una gran cantidad de
información.
Vamos a comenzar con un vistazo al estado de salud de nuestro VCSA, para ello, nos iremos hasta
la vista de Hosts and Clusters, haremos click en nuestro VCSA, nos desplazaremos hasta el menú
llamado Monitor y haremos click en Health.
Esta monitorización nos indica el estado de varios componentes y servicios de nuestro VCSA, por
ejemplo, en la ilustración se aprecia el consumo de cada partición de disco del VCSA, muy importante
cuando estamos realizando upgrades, por ejemplo, o también importante en caso de que estemos
almacenando logs de salud por mucho tiempo, estas particiones pueden llenarse.
Esta monitorización no se queda aquí, también nos ayuda a comprender el estado de vMotion, el
estado del almacenamiento de los logs de los ESXi, y por ejemplo el warning que tengo sobre las
vulnerabilidades en el microprocesador Intel, ya que no he aplicado los parches.
Continuando en la vista de Hosts and Clusters, bajaremos hasta el Datacenter que tenemos creado a
nivel lógico, nos iremos hasta Monitor y luego en Performance – Overview, esta vista nos muestra un
vistazo rápido del estado de nuestros diferentes clústeres:
O el consumo dentro de todos los Datastores por tipo de fichero, muy útil para saber si tenemos
Snapshots, o Swap, o cualquier otro tipo de ficheros llenando nuestro valioso espacio en disco:
También podríamos ver si hacemos click una vez más en View, el espacio usado por los diferentes
Datastores, pero es una vista muy básica y he preferido no añadir captura de pantalla.
Si continuamos en la misma pestaña, pero hacemos click en Advanced, podemos ver en este caso
de Datacenter, el número de operaciones especiales realizados en las máquinas virtuales, tales como
pueden ser vMotions, Storage vMotions, VM Power ON y VM Power Off, interesante gráfica:
Vamos a bajar un nivel ahora hasta uno de nuestros Clúster, en éste mismo nos iremos hasta Monitor,
y allí en el menú de Performance, haremos click Overview, hay varias vistas, en la principal podremos
ver el consumo de CPU, RAM y el número de operaciones realizado en las máquinas virtuales:
Continuando en esta misma pestaña, cambiaremos de vista por la de Resource Pool y Máquinas
Virtuales, que nos mostrará un breve resumen del tiempo que seleccionemos referente a consumo de
CPU y Memoria RAM, en un cómodo TOP 10:
Continuando en esta pestaña, pero cambiando a la vista Avanzada, podremos ver que vienen varias
vistas ya preparadas, pero lo más importante es que podremos editar el Chart Options para crear una
vista más refinada.
Las vistas refinadas en los Chart Options nos permitirán una visualización mucho más detallada, pero
en el caso de Clúster no hay demasiada información relevante, con lo que lo veremos más adelante.
Si bajamos un nivel más, hasta uno de los Hosts, nos vamos hasta Monitor, y luego hasta Performance
– Overview, vamos a poder ver un resumen muy detallado del consumo de CPU, RAM, Disco y
Networking en tiempo real con un máximo de hasta una hora, con lo que es perfecto para hacer
troubleshooting de problemas en tiempo real:
Una de mis vistas favoritas en este simple Overview en los hosts, es la vista llamada Virtual Machines,
que nos mostrará de manera agregada el TOP 10 de VMs que están consumiendo más CPU, RAM,
Disco y Networking, de forma que con un simple click, tengo todo lo que necesito:
Si nos desplazamos hasta la opción de Advanced, podemos crear gráficas mucho más detalladas,
ahora sí, como por ejemplo el consumo de CPU Ready en ms, agrupado por VM, sería algo así:
Y el resultado de esta personalización en la visualización de las gráficas quedaría de la siguiente

manera:
El potencial de las vistas Avanzadas, usando el Chart Options es muy amplio, con lo que os invito a
deteneros en esta sección tanto tiempo como sea necesario para que podáis encontrar las métricas,
con el tiempo y los elementos que realmente son importantes para vosotros.
Si bajamos un nivel más, hasta cualquier VM, y nos vamos hasta Monitor, Performance, Overview,
podremos ver una monitorización más granular para esta VM en concreto, podemos visualizar de un
vistazo el consumo de CPU, RAM, Disco y Networking. Además el resto de vistas en Overview nos
proporcionan una monitorización más que suficiente para comprender si la VM tiene algún tipo de
incidencia:
Para las VMs, tenemos ya lista una vista en el apartado de Advanced que nos hará la vida más sencilla
para comprender si la VM ha sido mal dimensionada a nivel de vCPU, o si el host está tardando mucho
en otorgar recursos de CPU, que suele suceder si hemos dimensionado mal el host:
Si cambiamos de vista y nos vamos hasta Storage, seleccionamos un Datastore y hacemos click en
Monitor, Performance, Overview, tendremos varias vistas muy interesantes para poder consumir, os
dejo un breve ejemplo con el espacio consumido en un Datastore por VM, pero hay otras muchas
vistas muy interesantes para comprobar el rendimiento del Datastore en concreto:
La parte de Networking está mucho más limitada y más allá de la monitorización de la red dentro de
VMs y Hosts, no encontramos vistas más detalladas dentro de vSphere Client.
Sin embargo podríamos habilitar NetFlow si estamos haciendo uso de Distributed Virtual Switches
(DVS) y poder capturar el tráfico con herramientas de terceros, aquí un link sobre cómo habilitarlo -
https://blog.paessler.com/netflow-configuration-and-monitoring-via-prtg-on-vmware-vsphere y aquí el
resultado de cómo quedaría por ejemplo con una herramienta comercial llamada PRTG:
2. Monitorizando nuestros ESXi en tiempo real usando

ESXTOP
ESXTOP es una herramienta que viene incluida de serie dentro de ESXi, y que nos proporciona
información en tiempo real del consumo de recursos dentro de un ESXi, como puede ser por ejemplo
CPU, Memoria RAM, Disco, etc. Para todos aquellos que conozcáis un poco de la consola de un
Sistema Operativo normal, ESXTOP es lo que top es para Linux.
ESXTOP incluye nueve diferentes visualizaciones desde la versión de vSphere 6.5, estas visualizaciones
específicas se pueden invocar una vez que estamos en ESXTOP presionando las siguientes teclas:
• c: CPU
• m: Memory
• v: Disk Virtual Machine
• u: Disk Device
• d: Disk Adapter
• n: Network
• i: Interrupt
• p: Power Management
• x: vSAN
Os quiero mostrar con detalle cómo invocar estas diferentes vistas, y todas las opciones que nos
proporciona cada una de ellas, lo primero que haremos será desde un SSH a un Host ESXi, invocar
esxtop, la vista por defecto a la que entramos es la de CPU:
Os dejo una tabla con todos los diferentes parámetros que ESXTOP nos está mostrando respecto al
consumo de CPU:
Métrica Nombre Descripción

ID de una carga de trabajo en ejecución. El ID de la carga
de trabajo suele estar oculto y se muestra el ID del grupo,
ID ID a menos que el grupo se amplíe con el comando “e”. Esto
también se aplica a los grupos con una sola carga de
trabajo. El ID nunca es idéntico al GID.
El ID de grupo de una carga de trabajo en ejecución. Un
grupo a veces también se denomina Resource Pool, que
GID Group ID
no tiene nada en común con los Resource Pools que se
pueden configurar en un Cluster de DRS.
El ID de carga de trabajo líder, también conocido como
ID de cártel VMX para máquinas virtuales. LWID es
LWID Leader Workload ID
típicamente la primera carga de trabajo que se ha iniciado
en un grupo.
Nombre del grupo de una carga de trabajo. El número
que se adjunta al nombre es el LWID. Cuando el grupo se
NAME Name
expande con el comando “e”, se muestra el nombre de la
carga de trabajo.
El número de cargas de trabajo que se ejecutan en un
Number of
NWLD grupo. NWLD es 1 cuando el Grupo es un único proceso,
Workloads
o cuando el grupo ha sido expandido con el comando “e”.
Porcentaje de ciclos de núcleo de la CPU física utilizados
por la carga de trabajo o el grupo. %USED depende
de la frecuencia con la que el núcleo de la CPU está
funcionando y puede ser mayor o menor qué %RUN
cuando la frecuencia nominal (nominal) difiere. Los
%USED Used grupos también pueden ser superiores al 100% cuando
se configuran más vCPUs o cuando hay un alto uso de
%SYS.
UTILIZADO = %RUN + %SYS - %OVRLP
Pulsaremos ‘U’ para clasificar por columna %USED.

Porcentaje del tiempo total programado para que se
ejecute la carga de trabajo. %RUN no tiene en cuenta el
hyperthreading y el tiempo del sistema. En un servidor
%RUN Run habilitado para hyperthreading, %RUN puede ser el doble
de grande que %USED.
La principal diferencia entre %RUN y %RUN es qué

%RUN no tiene en cuenta el tiempo del sistema.
Porcentaje del tiempo que el núcleo VMkernel
ESXi dedica a la carga de trabajo para procesar las
%SYS System
interrupciones y realizar otras actividades del sistema. Un
%SYS alto normalmente significa un IO alto.
Porcentaje de tiempo que una carga de trabajo pasa en el

estado de espera bloqueada u ocupada. Este porcentaje
también incluye %IDLE. El máximo teórico de %WAIT es
%WAIT Wait (NWLD*100). No hay nada malo cuando hay un valor alto
porque el tiempo de inactividad está incluido en %WAIT.
100%= %WAIT + %RDY + %CSTP + %RUN

El porcentaje total de tiempo que una carga de trabajo
pasa en un estado bloqueado a la espera de eventos. La
métrica %VMMWAIT sólo está disponible para vCPUS o
%VMWAIT Virtual Machine Wait combinada en un grupo VM.
Para vCPUS cuando una máquina virtual se expande

con el comando “e”, %WAIT = %VMWAIT + %IDLE +
%SWPWWT
El porcentaje de tiempo que la carga de trabajo estaba
lista para ejecutarse pero esperando en una cola para
ser programada. Esto puede ocurrir incluso cuando hay
muchos ciclos de CPU libres cuando una CPU VM está
limitada administrativamente, lo que se muestra con
%MLMTD.
%RDY Ready Para determinar la contención de CPU de %RDY hay que

tener en cuenta %RDY, %MLMTD y el número de vCPUS.
Si %RDY - %MLMTD es superior al 10% por vCPU, es
muy probable que esté experimentando contención de
CPU. Típicamente usted quiere ver %RDY cerca de 0.
100% = %RUN + %RDY + %CSTP + %WAIT
Presionaremos ‘R’ para ordenar por columna %RDY.

El porcentaje de tiempo que la carga de trabajo de
la vCPU está en un bucle inactivo. %IDLE sólo está
%IDLE Idle disponible para cargas de trabajo de vCPU. Otras cargas
de trabajo no tienen bucles inactivos, por lo que %IDLE
es 0.
Porcentaje de tiempo que los servicios del sistema
dedican a otras cargas de trabajo. Por ejemplo, si VM A
está siendo programado actualmente y el ESXi VMkernel
%OVRLP Overlap
procesa un paquete de red para VM B, el tiempo
empleado aparece como %OVRLP para la máquina
virtual A y %SYS para la máquina virtual B.
El porcentaje de tiempo que la máquina virtual está lista

para funcionar, pero está esperando la disponibilidad de
otras unidades de procesamiento de vídeo. El estado de
calendario se aplica sólo a las máquinas virtuales SMP. El
programador de la CPU puede poner una vCPU en este
estado, cuando la carga de trabajo de la VM no utiliza
%CSTP CoStop
vCPUs de forma equilibrada. Por ejemplo, si tiene una
VM con 2 vCPUs que ejecutan una aplicación sin SMP,
utilizando 1 vCPU al 100% y 1 vCPU al 0%. En ese caso,
el programador de la CPU penaliza a la VM para reducir
la escasez de recursos para otras VM. Esto se representa
como %CSTP.
El porcentaje de tiempo que una carga de trabajo
estaba lista para ejecutarse, pero deliberadamente no
se programó porque al hacerlo se violaría el límite de la
%MLMTD Max Limited
CPU de la máquina virtual o del conjunto de recursos. El
tiempo %MLMTD está incluido en el tiempo %RDY. Si el
valor no es 0, la VM ha sido limitada administrativamente.
El porcentaje de tiempo que una carga de trabajo
pasa esperando a que el núcleo VM cambie de
memoria. La hora %SWPWT se incluye en la hora
%WAIT. Si %SWPWT es mayor que 0, VMkernel está
%SWPWT Swap Wait intercambiando la memoria de la VM al disco. Esto tendrá
un gran impacto negativo en el desempeño general. El
intercambio puede ser causado por una sobresuscripción
de memoria alta o por límites de memoria configurados
en un pool de recursos o en una máquina virtual.
Número de interruptores de carga de trabajo por segundo.
SWTCH/s Switches/sec Un cambio de contexto ocurre cuando una CPU cambia la
ejecución de una carga de trabajo a otra.
Número de migraciones por segundo. Una carga de
MIG/s Migrates/sec trabajo puede migrarse de un pCPU ocupado a un pCPU
menos cargado para el balanceo de carga.
Número de espiraciones cuánticas por segundo. Esto
ocurre cuando expira un tiempo cuántico dado a una
Quantum Expires/ carga de trabajo que se está ejecutando actualmente. Es
QEXP/s
sec común que una carga de trabajo cambie su estado a EN
ESPERA antes de que expire el tiempo cuántico actual
(50 ms).
Número de despertadores de carga de trabajo por
WAKE/s Wakeups/sec segundo. Una carga de trabajo se despierta cuando su
estado cambia de EN ESPERA a LISTO.
Reserva de recursos, máquinas virtuales o atributos
AMIN Alloc Min de carga de trabajo. Un valor de 0 significa que no hay
reserva.
Límite de atributos de recursos, máquina virtual o carga
AMAX Alloc Max
de trabajo. Un valor de -1 significa ilimitado.
Grupo de recursos, máquina virtual o atributo de carga de

trabajo Compartir. Las cuotas por defecto son -4 (Alta),
ASHRS Alloc Shares
-3 (Normal) y -2 (Baja). Cuando se configura una acción
personalizada, se muestra el valor.
AMLMT Alloc Min Limited Parámetro indocumentado.
AUNITS Allocated unit Unidad de atribución (MHz para máquinas virtuales)
El porcentaje de tiempo que el Pool de recursos/Carga
de trabajo estaba listo para ejecutarse, pero no estaba
%LAT_C Latency CPU
programado para ejecutarse debido a la contención de
recursos de la cpu.
El porcentaje de tiempo que el Pool de recursos/Carga
de trabajo estaba listo para ejecutarse, pero no estaba
%LAT_M Latency Memory
programado para ejecutarse debido a la contención de
recursos de memoria.
La demanda de CPU en porcentaje. Representa el
%DMD Demand
promedio de carga de CPU activa en el último minuto.
Asignación mínima efectiva de cpu en caso de contención
de recursos. Esta es la cantidad de MHz que la carga de
EMIN Effective Min
trabajo recibirá cuando las máquinas virtuales compitan
por los recursos.
TIMER/s Timer/sec Tasa de temporizador para esta carga de trabajo.
AFFINITY_BIT_ Máscara de bits que muestra la afinidad de programación
Affinity Bit Mask
MASK actual para la carga de trabajo.
El procesador físico o lógico en el que se ejecutaba la
CPU CPU carga de trabajo cuando resxtop (o esxtop) obtuvo esta
información.
HTSHARING HT Sharing Configuración actual del hyperthreading.
Indica si la carga de trabajo está actualmente en
HTQ HT Quarantine
cuarentena o no. N significa no y Y significa sí.
Consumo actual de energía de la CPU de una máquina
POWER Power Usage Watts virtual (en vatios). El cálculo del uso se basa en el valor
proporcionado por la fuente de alimentación.
Vamos a presionar ahora (m) para visualizar el consumo de Memoria RAM del Host, por VM, etc:
De nuevo os dejo una tabla con todos los parámetros que podemos encontrar en esta vista de ESXTOP:

El ID de la carga de trabajo real se oculta y se visualiza
el ID de grupo. Como no puede expandir el grupo en la
ID ID
pantalla de memoria, no puede ver el ID real de la carga
de trabajo.
El ID de grupo de una carga de trabajo en ejecución. Un
grupo a veces también se denomina Resource Pool, que
GID Group ID no tiene nada en común con los Resource Pools que se
pueden configurar en un Cluster de DRS.
Pulsaremos ‘N’ para ordenar por columna GID.

El ID de carga de trabajo líder, también conocido como
ID de cártel VMX para máquinas virtuales. LWID es
LWID Leader Workload ID
típicamente la primera carga de trabajo que se ha iniciado
en un grupo.
Nombre del grupo de una carga de trabajo. El número que
NAME Name se adjunta al nombre es el LWID. Las máquinas virtuales
no tienen un número añadido.
Number of El número de cargas de trabajo que se ejecutan en el
NWLD
Workloads Grupo. NWLD es 1 cuando el Grupo es un único proceso.
Reserva de recursos, máquinas virtuales o atributos
AMIN Alloc Min de carga de trabajo. Un valor de 0 significa que no hay
reserva.
Límite de atributos de recursos, máquina virtual o carga
AMAX Alloc Max
de trabajo. Un valor de -1 significa ilimitado.
Grupo de recursos, máquina virtual o atributo de carga de
trabajo Compartir. Las cuotas por defecto son -4 (Alta),
ASHRS Alloc Shares
-3 (Normal) y -2 (Baja). Cuando se configura una acción
personalizada, se muestra el valor.
AMLMT Alloc Min Limited Parámetro indocumentado.
AUNITS Allocated unit Unidad de asignación (kilobytes para máquinas virtuales)
Nodo de inicio actual para el pool de recursos o la
máquina virtual. Esta estadística sólo es aplicable a los
sistemas NUMA. Si la máquina virtual no tiene ningún
nodo de inicio, aparecerá un guión (-). Una máquina
virtual se ejecuta sólo en procesadores dentro de su nodo
NHN Numa Home Nodes
de origen, y su memoria recientemente asignada también
proviene del nodo de origen. Una máquina virtual puede
tener varios nodos domésticos cuando el número de
CPUs virtuales excede el número de núcleos por zócalo
físico.
Numa Rebalance
NMIG
Count Delta
Numa Remote Cantidad de memoria remota asignada a la máquina
NRMEM
Memory MBytes virtual.
Numa Local Memory
NLMEM Cantidad de memoria local asignada a la máquina virtual.
MBytes
Porcentaje de memoria local asignada a la máquina

virtual. Este valor debe ser cercano al 100%. Una de las
razones de la mala ubicación de NUMA puede ser que
N%L Numa % Local
una máquina virtual tiene más memoria configurada de la
que está disponible para cada procesador. El acceso a la
memoria remota provoca un aumento de la latencia.
Cantidad de memoria física asignada a una máquina
virtual. Esta es la memoria de la máquina virtual
configurada.
MEMSZ Memory Size MBytes
MEMSZ = SUBVENCIÓN + MCTLSZ + SWCUR + intacto
Presionaremos ‘M’ para ordenar por columna MEMSZ.

Cantidad de memoria física asignada a la máquina virtual.
Memory Granted Si GRANT es menor que MEMSZ, el huésped nunca
GRANT
Size MBytes ha usado toda su memoria configurada o si ha sido
recuperado por el driver de balloon.
Cantidad de memoria consumida por la máquina virtual.
La memoria que consume actualmente la máquina virtual
es igual a la cantidad de memoria que utiliza actualmente
Memory Consumed
CNSM el sistema operativo huésped de la máquina virtual,
Size MBytes
excluyendo la cantidad de memoria guardada por el uso
compartido de páginas transparentes y la compresión de
memoria.
Cantidad específica de memoria física a asignar. Es
SZTGT Target Size MBytes posible que SZTGT sea superior a MEMSZ porque incluye
la memoria superior de la máquina virtual.
La cantidad de memoria física utilizada recientemente
(lectura o escritura) por la máquina virtual. La memoria
tocada es una estimación del conjunto de trabajo, que
TCHD Touched MBytes
indica cuán activamente está utilizando la máquina virtual
su memoria. Este valor es similar a la memoria activa
reportada por el SO huésped.
Touched Write La cantidad de memoria física escrita recientemente por
TCHD_W
MBytes la máquina virtual.
Porcentaje de memoria física activa del huésped, valor
%ACTV Active Estimate
actual.
Porcentaje de memoria física activa del huésped, media
%ACTVS Active Slow Estimate
móvil lento.
Porcentaje de memoria física activa del huésped, media
%ACTVF Active Fast Estimate
móvil rápido.
Porcentaje de memoria física activa del huésped, predecir
%ACTVN Active Next Estimate
qué %ACTVF será en la próxima muestra.
El controlador de memoria de ballon está instalado o no.
MCTL? Memctl? N significa no, Y significa sí. El controlador de ballooning
forma parte de VMware Tools.
Cantidad de memoria física recuperada de la máquina

virtual por medio de un globo. Para disminuir la presión
de la memoria del host, el controlador del globo se infla
dentro de la máquina virtual y hace que la memoria
física esté disponible para otras máquinas virtuales. El
MCTLSZ Memctl MBytes impacto en el rendimiento causado por el balonismo es
pequeño y, por lo tanto, preferible al intercambio. Otra
razón para volar en globo puede ser un límite de memoria
configurado (AMAX).
Pulse ‘B’ para ordenar por columna MCTLSZ.

Memctl Target Cantidad de memoria física que el sistema ESXi intenta
MCTLTGT
MBytes recuperar de la máquina virtual por medio de ballooning.
La cantidad máxima de memoria física que puede ser
MCTLMAX Memctl Max MBytes
recuperada por el driver de ballooning.
SWCUR Swapped MBytes Uso actual de swap por parte de esta máquina virtual.
Destino donde el host ESXi espera que esté el uso de
SWTGT Swap Target MBytes
swap por parte de la máquina virtual.
Swap Read MBytes/ Velocidad a la que el host ESXi intercambia la memoria
SWR/s
sec del disco por la máquina virtual.
Swap Written Velocidad a la que el host ESXi intercambia la memoria
SWW/s
MBytes/sec de la máquina virtual con el disco.
La velocidad a la que se lee la memoria de la caché del
host. Cuando la caché del host está habilitada, el host
Llswap Read
LLSWR/s ESXi puede cambiar a una unidad SSD local, en lugar del
MBytes/sec
almacén de datos de máquinas virtuales, lo que reduce
significativamente el impacto causado por el intercambio.
Velocidad a la que se escribe la memoria en la caché del
host. Cuando la caché del host está habilitada, el host
Llswap Written
LLSWW/s ESXi puede cambiar a una unidad SSD local, en lugar del
MBytes/sec
almacén de datos de máquinas virtuales, lo que reduce
significativamente el impacto causado por el intercambio.
La cantidad de datos leídos del archivo del punto de
Checkpoint Read control. Los datos de un archivo de punto de control se
CPTRD
MBytes leen cuando se reanuda una máquina virtual desde un
estado suspendido.
El tamaño del archivo del punto de control. El archivo
Checkpoint Target
CPTTGT de punto de control se utiliza cuando se suspende una
MBytes
máquina virtual.
El tamaño de las páginas físicas de la máquina virtual que
se ponen a cero. Una página cero es simplemente una
ZERO Zero MBytes
página de memoria que contiene todos los ceros que se
pueden utilizar fácilmente para compartir páginas.
Cantidad de memoria física que se comparte con el
SHRD Shared MBytes
huésped.
Shared Saved Cantidad de memoria física que se guarda debido al uso
SHRDSVD
MBytes compartido de la página.
Copy On Write Hint Cantidad de páginas de sugerencias físicas para el uso
COWH
MBytes compartido de páginas.
Overhead UW Cantidad de memoria de sobrecarga reservada para la

OVHDUW
MBytes carga de trabajo del usuario vmx.
Cantidad de memoria de sobrecarga que consume
OVHD Overhead MBytes
actualmente la máquina virtual.
Overhead Max Cantidad de memoria de recargo reservada para toda la
OVHDMAX
MBytes máquina virtual.
Min Commit Target
MCMTTGT
MBytes
Commit Target
CMTTGT
MBytes
Commit Charged
CMTCHRG
MBytes
Commit Pages Per
CMTPPS
Share
Compressed Tamaño actual de la memoria comprimida por esta
CACHESZ
Memory MBytes máquina virtual.
Used Compressed
CACHEUSD Se utiliza memoria caché de compresión.
Memory MBytes
Compression
ZIP/s Memoria comprimida por segundo.
MBytes/sec
Decompression
UNZIP/s Memoria descomprimida por segundo.
MBytes/sec
Si nos vamos ahora a la vista de Disco por Máquina Virtual (v) podremos ver lo siguiente:
De nuevo, me gustaría incluir una tabla con todos los parámetros que se pueden observar en esta
vista:

El ID de disco SCSI virtual. El ID suele estar oculto y se
ID ID muestra el ID de grupo, a menos que el grupo se amplíe
con el comando “e”. Es el mismo ID que utiliza vscsiStats.
GID Group ID El ID de grupo de la máquina virtual.
Virtual Machine El nombre para mostrar de la máquina virtual.
VMNAME
Name Pulsaremos ‘N’ para ordenar por columna VMNAME.
Nombre del dispositivo VSCSI. Sólo se muestra cuando el
VDEVNAME Virtual Device Name
grupo se amplía con el comando “e”.
Number of Virtual
NVDISK Número de dispositivos VSCSI.
Disks
CMDS/s Commands/sec Número de órdenes emitidas por segundo.
Número de comandos de lectura emitidos por segundo.
READS/s Reads/sec
Presionaremos ‘r’ para ordenar por columna READS/s.
Número de comandos de escritura emitidos por segundo.
WRITES/s Writes/sec Presionaremos ‘w’ para ordenar por columna de
ESCRITOS.
Megabytes leídos por segundo.
MBREAD/s MBytes Read/sec
Pulse ‘R’ para ordenar por columna MBREAD/s.
Megabytes escritos por segundo.
MBWRTN/s MBytes Written/sec
Pulse ‘T’ para ordenar por columna MBWRTN/s.
LAT/rd Read Latency Latencia media (en milisegundos) por lectura.
LAT/wr Write Latency Latencia media (en milisegundos) por escritura.
Si queremos monitorizar ahora los dispositivos de Storage físicos presionaremos (u) que nos mostrará:
Si nos vamos de nuevo a ver una tabla detallada de cada parámetro, encontramos lo siguiente para
ESXTOP y esta vista de los dispositivos físicos de Storage conectados a este Host de ESXi:

DEVICE Device Nombre del dispositivo de almacenamiento.
Esta columna sólo es visible cuando se amplía con “e”
PATH/WORLD/ Path/World/Partition
para Disk World Statistics, “P” para Disk Path Statistics o
PARTITION Id
“t” para Disk Partition Statistics.
Número de rutas de acceso al dispositivo de
NPH Number of Paths
almacenamiento.
Número de mundos que se ejecutan en el dispositivo de
NWD Number of Worlds almacenamiento. Amplíe el dispositivo con el comando “e”
para mostrar estadísticas de mundos individuales.
Número de particiones en el dispositivo de
NPN Number of Partitions
almacenamiento.
Número de acciones. Sólo se muestra cuando el
SHARES Shares dispositivo se expande con el comando “e” (Disk World
Statistics).
BLKSZ Block Size (Bytes) Tamaño de bloque del dispositivo en bytes.
NUMBLKS Number of Blocks Número de bloques del dispositivo.
Profundidad de la cola de dispositivos actual del
DQLEN Device Q Depth
dispositivo de almacenamiento.
Profundidad de la cola de carga de trabajo. Este es el
número máximo de comandos activos del ESXi VMkernel
WQLEN World Q Depth que el mundo puede tener. Esto es un máximo por
dispositivo para la carga de trabajo. Sólo es válido si el
dispositivo correspondiente se amplía a cargas de trabajo.
Número de comandos en el ESXi VMkernel que están
ACTV Active Commands activos actualmente. Esta estadística se aplica sólo a los
mundos y dispositivos.
Número de comandos en el ESXi VMkernel que están
QUED Queued Commands actualmente en cola. Esta estadística se aplica sólo a las
cargas de trabajo y a los dispositivos.
Porcentaje de la profundidad de la cola utilizada por los
%USD % Used comandos activos del ESXi VMkernel. Esta estadística se
aplica sólo a los mundos y dispositivos.
Relación entre los comandos activos del ESXi VMkernel
más los comandos en cola del ESXi VMkernel y la
LOAD Load
profundidad de la cola. Esta estadística se aplica sólo a
las cargas de trabajo y dispositivos.
CMDS/s Commands/sec Número de órdenes emitidas por segundo.
READS/s Reads/sec Número de comandos de lectura emitidos por segundo.
WRITES/s Writes/sec Número de comandos de escritura emitidos por segundo.
MBREAD/s MBytes Read/sec Megabytes leídos por segundo.
MBWRTN/s MBytes Written/sec Megabytes escritos por segundo.
RESV/s Reserves/sec
CONS/s Conflicts/sec
Este es el tiempo promedio de respuesta en milisegundos

Average Driver
DAVG/cmd por comando que se envía al dispositivo. El valor DAVG
MilliSec/Command
es parte de GAVG.
Average Kernel Esta es la cantidad de tiempo que el comando pasa en el
KAVG/cmd
MilliSec/Command VMkernel. El valor de KAVG es parte de GAVG.
Este es el tiempo de respuesta tal y como lo percibe el
Average Guest
GAVG/cmd sistema operativo huésped. Este número se calcula con
MilliSec/Command
la fórmula: DAVG + KAVG = GAVG
Average Queue
QAVG/cmd Latencia media de la cola por comando en milisegundos.
MilliSec/Command
Average Driver Latencia de lectura media del controlador de dispositivo
DAVG/rd
MilliSec/Read por operación de lectura en milisegundos.
Average Kernel Promedio de latencia de lectura de ESXi VMkernel por
KAVG/rd
MilliSec/Read operación de lectura en milisegundos.
Average Guest Latencia de lectura media del sistema operativo huésped
GAVG/rd
MilliSec/Read por operación de lectura en milisegundos.
Average Queue Latencia media de lectura de la cola por operación de
QAVG/rd
MilliSec/Read lectura en milisegundos.
Average Driver Latencia de escritura media del dispositivo por operación
DAVG/wr
MilliSec/Write de escritura en milisegundos.
Average Kernel Latencia de escritura media de ESXi VMkernel por
KAVG/wr
MilliSec/Write operación de escritura en milisegundos.
Average Guest Latencia de escritura promedio del sistema operativo
GAVG/wr
MilliSec/Write huésped por operación de escritura en milisegundos.
Average Queue Latencia media de escritura en cola por operación de
QAVG/wr
MilliSec/Write escritura en milisegundos.
Failed Commands/
FCMDS/s
sec
FREAD/s Failed Reads/sec
FWRITE/s Failed Writes/sec
Failed Bytes Read/
FMBRD/s
sec
Failed Bytes Written/
FMBWR/s
sec
FRESV/s Failed Reserves/sec
ABRTS/s Aborts/sec Número de comandos abortados por segundo.
RESETS/s Resets/sec Número de comandos reseteados por segundo.
Número de comandos PAE por segundo. Esta estadística
PAECMD/s PAE Commands/sec
se aplica sólo a las rutas.
Número de copias PAE por segundo. Esta estadística se
PAECP/s PAE Copies/sec
aplica sólo a las rutas.
Número de comandos de división por segundo. Esta
SPLTCMD/s Split Commands/sec
estadística se aplica sólo a las rutas.
Número de copias divididas por segundo. Esta estadística
SPLTCP/s Split Copies/sec
se aplica sólo a las rutas.
CLONE_RD VAAI Clone Reads
CLONE_WR VAAI Clone Writes
CLONE_F VAAI Clone Failed

MBytes Clone
MBC_RD/s
Reads/sec
MBytes Clone
MBC_WR/s
Writes/sec
ATS Atomic Test and Set
Atomic Test and Set
ATSF
Failed
ZERO Zeros
ZERO_F Zeros Failed
MBZERO/s MBytes Zeroed/sec
DELETE Delete
DELETE_F Delete Failed
MBDEL/s Mbytes Delete/sec
Average Success
CAVG/suc
Latency ms/Clone
Average Failure
CAVG/f
Latency ms/Clone
Average Success
AAVG/suc
Latency ms/ATS
Average Failure
AAVG/f
Latency ms/ATS
Average Success
ZAVG/suc
Latency ms/Zero
Average Failure
ZAVG/f
Latency ms/Zero
Para conocer el estado en tiempo real de las controladoras de disco virtuales, usaremos la tecla (d),
no os voy a mostrar una tabla con lo que significa cada parámetro ya que la vista es bastante básica:
Sin embargo, si hablamos de Networking, tecla (n), esta sería la vista con Switches Virtuales Distribuidos:
Vamos a conocer que significa cada parámetro que tenemos en pantalla para esta vista de ESXTOP:

El ID de puerto utilizado en el conmutador virtual. Este ID
PORT-ID Port ID se utiliza, por ejemplo, para trazas de red con pktcap-uw.
Pulsaremos ‘N’ para ordenar por columna PORT-ID.

Este puerto de switch virtual es un puerto de enlace
UPLINK Uplink?
ascendente físico. N significa no, Y significa sí.
Y significa que el enlace correspondiente está arriba. N
UP Link Up? significa que no lo es. Sólo visible para los puertos de
enlace ascendente.
Velocidad de enlace en Megabits por segundo. Sólo
SPEED Link Speed (Mb/s)
visible para los puertos de enlace ascendente.
Y significa que el enlace correspondiente está operando
FDUPLX Full Duplex? en dúplex completo. N significa que no lo es. Sólo visible
para los puertos de enlace ascendente.
Indica lo que está conectado al puerto de switch virtual.
Los dispositivos conectados pueden ser NICs de
USED-BY Used By máquinas virtuales, puertos VMkernel (vmk#), NICs
físicas (vmnic#) o puertos utilizados para comprobaciones
de estado (Shadow of vmnic#).
El NIC físico que el dispositivo correspondiente está
Team Uplink Physical
TEAM-PNIC utilizando activamente. Esta información es útil para la
NIC Name
resolución de problemas de red.
Nombre del switch virtual. El nombre para mostrar para
DNAME Device Name los switches virtuales o DvsPortset-# para switches
distribuidos.
Packets Transmitted/ Número de paquetes transmitidos por segundo.
PKTTX/s
sec Pulsaremos ‘t’ para ordenar por columna PKTTX/s.
MBits Transmitted/ MegaBits transmitidos por segundo.
MbTX/s
sec Pulsaremos ‘T’ para ordenar por columna MbTX/s.
Average Packet Size
PSZTX Tamaño medio de los paquetes transmitidos en bytes.
Transmitted (Bytes)
Packets Received/ Número de paquetes recibidos por segundo.

PKTRX/s
sec Presionaremos ‘r’ para ordenar por columna PKTRX/s.
MegaBits recibidos por segundo.
MbRX/s MBits Received/sec
Pulsaremos ‘R’ para ordenar por columna MbRX/s.
Average Packet Size
PSZRX Tamaño medio de los paquetes recibidos en bytes.
Received (Bytes)
% Outbound Packets
%DRPTX Porcentaje de paquetes de transmisión perdidos.
Dropped
% Received Packets
%DRPRX Porcentaje de paquetes de recepción eliminados.
Dropped
Número de acciones de Vmkernel publicadas por
ACTN/s Actions Posted/sec segundo. Se trata de un contador interno de VMware sin
más documentación.
Multicast Packets
PKTTXMUL/s Número de paquetes multicast transmitidos por segundo.
Transmitted/sec
Multicast Packets
PKTRXMUL/s Número de paquetes multicast recibidos por segundo.
Received/sec
Broadcast Packets Número de paquetes de difusión transmitidos por
PKTTXBRD/s
Transmitted/sec segundo.
Broadcast Packets
PKTRXBRD/s Número de paquetes de difusión recibidos por segundo.
Received/sec
Si quisiéramos modificar cualquiera de las vistas que hemos analizado, y reducir por ejemplo el número
de campos que queremos mostrar, para facilitarnos el troubleshooting, presionaremos la tecla (f), por
ejemplo, en la vista de CPU he dejado solamente la columna A, D, F, H e I:
Y esto nos muestra la siguiente información, mucho más detallada para lo que yo ando buscando:
Podríamos guardar esta “vista personalizada” con la tecla (W, sí en mayúsculas) y ponerle un nombre
por ejemplo, mivistadecpu:
Para lanzar esta vista en el futuro, tan sencillo como lanzar el comando de ESXTOP de la siguiente
manera:
esxtop –c mivistadecpu
En caso de qué necesitáramos exportar esta información tan valiosa en un fichero .csv para poder ser
analizado en otra herramienta, o en un simple Excel, podríamos conseguirlo de la siguiente manera:
esxtop –b –n 10 > miinformacionimportantedeesxi.csv
Os cuento un poco lo que acabo de hacer, he usado el modo batch de esxtop con el atributo -b.
Además he incluido el atributo -n que lo que hace es tomar la información de 10 tomas en el tiempo,
que por defecto son cada 5 segundos, con lo que he tomado la información de la vista de CPU, la
que viene por defecto, durante 50 segundos de mi ESXi, además como he puesto luego el símbolo de
mayor significa que la información se me guarde en un fichero con el nombre que deseo.
3. Monitorizando nuestro entorno vSphere usando SNMP
SNMP o Simple Network Management Protocol es un estándar de la Industria para monitorizar y

controlar ciertos aspectos de elementos de nuestro Datacenter.
SNMP se usa ampliamente para la monitorización de redes. SNMP expone los datos de gestión en
forma de variables sobre los sistemas gestionados organizados en una base de información de gestión
(MIB) que describe el estado y la configuración del sistema. Estas variables pueden ser consultadas
remotamente (y, en algunas circunstancias, manipuladas) mediante la gestión de aplicaciones.
Si tuviéramos que dibujar SNMP quedaría de la siguiente manera:
SNMP está muy extendido, pero no por ello es un protocolo sencillo ni mucho menos seguro si lo
desplegamos utilizando SNMPv1 (estandarizado en 1988). Hay algunas buenas prácticas que tenemos
que seguir, por ejemplo y siendo breve:
• Abstenerse de usar Comunidades llamadas public o nombres de empresa
• Utilizar siempre que sea posible una red aislada para el tráfico UDP 161 para SNMP
• Utilizar autenticación gracias a SNMPv3 siempre que sea posible (aumenta el nivel de complejidad
a la hora de configuración)
• Utilizar cifrado en SNMP gracias a SNMPv3
El Departamento de Ciber Seguridad de los Estados Unidos recomienda únicamente el uso de SNMPv3
en su web oficial - https://www.us-cert.gov/ncas/alerts/TA17-156A
3.1 Monitorizando nuestro vCenter Server usando SNMP
Una vez que hemos dado un vistazo rápido a SNMP, es el momento de habilitar SNMP v3 en nuestro
vCenter, en mi caso estoy usando VCSA, ya que vCenter para Windows va a dejar de tener soporte
muy pronto.
Nos conectaremos a la Shell de VCSA por SSH, tendremos que tener algo similar a lo siguiente:
VMware vCenter Server Appliance 6.7.0.20100
Type: vCenter Server with an embedded Platform Services Controller
Connected to service
* List APIs: “help api list”
* List Plugins: “help pi list”
* Launch BASH: “shell”
Command>
El primero paso es crear un SNMP ID, para ello tendrá que ser una línea de entre 5 y 32 caracteres
hexadecimal, si queréis generar una aleatoria podéis hacerlo en esta web - https://www.browserling.
com/tools/random-hex En caso de que no introduzcamos nada, a la hora de habilitar el servicio se
generará un ID aleatorio, en este caso quiero introducir el mío propio, con lo que:
Command> snmp.set --engineid 5e19bed515e0023931b2528ab614580d
Si quisiera ver el resultado del comando, podría lanzar el siguiente comando que nos mostrará lo que
hemos introducido:
Command> snmp.get
Config:
Syslocation: ‘’
Pid: n/a
Port: 161
Communities: public
Authentication: none
Engineid: 5e19bed515e0023931b2528ab614580d
Remoteusers:
Targets:
Processlist: False
Enable: True
Privacy: none
Syscontact: ‘’
Loglevel: warning
Notraps: ‘’
V3targets:
Users:
Vamos a configurar ahora los protocolos de autenticación y la privacidad, estos dos protocolos harán
que el servicio de SNMP sea más seguro y sigamos las recomendaciones de seguridad Internacionales.
Comenzaremos con la autenticación, podemos configurarla en none, MD5 o SHA1 de la siguiente

manera, donde protocol tendrá que ser reemplazado por vuestra preferencia:
Command> snmp.set --authentication protocol
Posteriormente configuraremos la privacidad, que nos permite seleccionar entre none y AES128, con
lo que el comando quedaría de la siguiente manera, donde protocol es vuestra preferencia:
Command> snmp.set --privacy protocol
Ahora que tenemos ya configurado la privacidad y la autenticación podemos empezar a crear usuarios,
un usuario, para crear un usuario vamos a necesitar el nombre de usuario, no mayor de 32 caracteres,
y un hash de autenticación y otro de privacidad, vamos a generar estos últimos con un comando de
manera muy sencilla, ejecutaremos el siguiente comando, cambiando el VMware2019@ por vuestra
propia palabra secreta:
Command> snmp.hash --auth_hash VMware2019@ --priv_hash VMware2019@ --raw_secret true
Este comando os dará un output similar a este, pero con vuestras claves privadas para auth y privacidad:
Hash:
Priv_key: d0aa78b4e2304cbc765b513d1e1c03db807c17ec
Auth_key: d0aa78b4e2304cbc765b513d1e1c03db807c17ec
Es ahora cuando podemos crear un usuario, el comando es algo complejo con lo que os dejo una tabla
antes de crearlo:
Parámetro Descripción
userid Reemplazar con vuestro username.
authhash Reemplazar con el valor hash de autenticación.
privhash Reemplazar con el valor hash de privacidad.
Reemplazar con el nivel de seguridad para este usuario, que puede ser auth, para
security autenticarnos únicamente, priv, para autenticación y privacidad, o none, para que
no haya ni autenticación ni privacidad.
Con lo que el comando quedaría de la siguiente manera, tendríais que introducir vuestros propios
hashes y el nivel de seguridad que deseáis:
Command> snmp.set --users userid/authhash/privhash/security
Ya tendríamos casi todo configurado, en el caso de que queramos enviar Traps adicionalmente, el
comando a ejecutar sería el siguiente:
Command> snmp.set --v3targets hostname@port/userid/secLevel/trap
Os dejo una tabla de ayuda para comprender cada parámetro:
Reemplazar con el hostname o IP del sistema de monitorización que recibe las
hostname
traps.
Reemplazar con el puerto por el que el sistema de monitorización escucha. Si no
port
ponemos ninguno se usará el puerto por defecto, 161.
userid Reemplazar con el nombre de usuario
Reemplazar con none, auth, o priv para indicar el nivel de autenticación y
privacidad que deseamos para el usuario. Usaremos auth si hemos configurado
secLevel
únicamente la autenticación, priv si hemos configurado autenticación y privacidad,
y none si no hemos configurado ninguno.
Por último, arrancaremos el servicio de SNMP lanzando el siguiente comando:
Command> snmp.enable
Y comprobaremos el estado y configuración con un snmp.get:
Command> snmp.get
Config:
Syslocation: ‘’
Pid: 54278
Port: 161
Communities: public
Authentication: SHA1
Engineid: 5e19bed515e0023931b2528ab614580d
Remoteusers:
Targets:
Processlist: False
Enable: True
Privacy: AES128
Syscontact: ‘’
Loglevel: warning
Notraps: ‘’
V3targets:
1:
Ip: 192.168.1.15
Sec_level: priv
User: snmpuser
Type: trap
Port: 161
Users:
1:
Sec_level: priv
Auth_key: d0aa78b4e2304cbc765b513d1e1c03db807c17ec
Priv_key: d0aa78b4e2304cbc765b513d1e1c03db807c17ec
Username: snmpuser
Como buena práctica, tendríamos que irnos ahora al siguiente enlace https://kb.vmware.com/s/
article/1013445 y descargar el fichero llamado 1013445_VMware-mibs-6.7.0-10201460.zip, que
incluye las últimas MIB más actualizadas, en concreto tendremos que importar las siguientes MIB para
que podamos monitorizar VCSA de manera satisfactoria:
a. VMWARE-ROOT-MIB.mib
b. VMWARE-TC-MIB.mib
c. VMWARE-PRODUCTS-MIB.mib
Si queremos lanzar un snmpwalk desde un nodo que tenga el paquete instalado, podríamos hacerlo de
la siguiente manera, de esta manera podremos comprobar que nuestro SNMP está bien configurado:
snmpwalk -v3 -l authPriv -u userid -a SHA -A “PASSWORD1” -x AES -X “PASSWORD1” VCSAHOSTNAME
Si todo está bien configurado podremos ver una respuesta similar a este output:
SNMPv2-MIB::sysDescr.0 = STRING: VMware-vCenter-Server-Appliance 6.7.0 build-11338799

VMware, Inc x86_64
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.6876.4.7
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (7840447) 21:46:44.47
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: vcsa.zimbra.io
SNMPv2-MIB::sysLocation.0 = STRING:
SNMPv2-MIB::sysServices.0 = INTEGER: 72
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (1) 0:00:00.01
SNMPv2-MIB::sysORID.1 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.2 = OID: IF-MIB::ifMIB
SNMPv2-MIB::sysORID.3 = OID: IP-MIB::ip
Ya tendríamos nuestro SNMP listo para ser monitorizado por herramientas de terceros.
Para que os hagáis una idea, así quedaría si usáramos por ejemplo PRTG, una herramienta comercial
con versión gratuita de hasta 100 sensores, así se verían los sensores:
Y así se vería un mapa que podemos crear para ver todo de forma mucho más clara:
3.2 Monitorizando nuestros Hosts de ESXi usando SNMP
Llega el turno de configurar SNMPv3 en nuestros Hosts de ESXi, recordemos que SNMPv3 es la
opción segura y recomendad de configurar SNMP, y desde aquí os desaconsejo el uso de SNMPv1 o
v2c, vamos con el paso a paso.
El primer paso es configurar ESXi SNMPv3 con el engine id, para ello podemos hacer uso de la
siguiente página para generar uno aleatorio - https://www.browserling.com/tools/random-hex en este
caso:
esxcli system snmp set --engineid 0293a84c7118760f815e9b08fd75fceb
Vamos a continuar con la autenticación y privacidad de SNMPv3, estos dos protocolos harán que el
servicio de SNMP sea más seguro y sigamos las recomendaciones de seguridad Internacionales.
Comenzaremos con la autenticación, podemos configurarla en none, MD5 o SHA1 de la siguiente

manera, donde protocol tendrá que ser reemplazado por vuestra preferencia:
esxcli system snmp set --authentication protocol
Posteriormente configuraremos la privacidad, que nos permite seleccionar entre none y AES128, con
lo que el comando quedaría de la siguiente manera, donde protocol es vuestra preferencia:
esxcli system snmp set --privacy protocol
Ahora que tenemos ya configurado la privacidad y la autenticación podemos empezar a crear usuarios,
un usuario, para crear un usuario vamos a necesitar el nombre de usuario, no mayor de 32 caracteres,
y un hash de autenticación y otro de privacidad, vamos a generar estos últimos con un comando de
manera muy sencilla, ejecutaremos el siguiente comando, cambiando el VMware2019 por vuestra
propia palabra secreta:
esxcli system snmp hash --auth-hash VMware2019 --priv-hash VMware2019 --raw-secret
Este comando os dará un output similar a este, pero con vuestras claves privadas para auth y privacidad:
Authhash: 3516d465f81e5c08421cb50bd5cc8977
Privhash: 3516d465f81e5c08421cb50bd5cc8977
Es ahora cuando podemos crear un usuario, el comando es algo complejo con lo que os dejo una tabla
antes de crearlo:
userid Reemplazar con vuestro username.
authhash Reemplazar con el valor hash de autenticación.

privhash Reemplazar con el valor hash de privacidad.
Reemplazar con el nivel de seguridad para este usuario, que puede ser auth,
security para autenticarnos únicamente, priv, para autenticación y privacidad, o none,
para que no haya ni autenticación ni privacidad.
Con lo que el comando quedaría de la siguiente manera, tendríais que introducir vuestros propios
hashes y el nivel de seguridad que deseáis:
esxcli system snmp set --users userid/authhash/privhash/security
Ya tendríamos casi todo configurado, en el caso de que queramos enviar Traps adicionalmente, el
comando a ejecutar sería el siguiente:
esxcli system snmp set --v3targets hostname@port/userid/secLevel/message-type
Os dejo una tabla de ayuda para comprender cada parámetro:
Reemplazar con el hostname o IP del sistema de
hostname
monitorización que recibe las traps.
Reemplazar con el puerto por el que el sistema
port de monitorización escucha. Si no ponemos
ninguno se usará el puerto por defecto, 161.
userid Reemplazar con el nombre de usuario
Reemplazar con none, auth, o priv para
indicar el nivel de autenticación y privacidad que
deseamos para el usuario. Usaremos auth si
secLevel hemos configurado únicamente la autenticación,
priv si hemos configurado autenticación y
privacidad, y none si no hemos configurado
ninguno.
message-type Reempazar con trap or inform.
Por último, arrancaremos el servicio de SNMP lanzando el siguiente comando:
esxcli system snmp set --enable true
Podríamos comprobar que la configuración de SNMP, por la parte de traps, está bien configurada
lanzando el siguiente comando, que nos devolvería lo siguiente:
esxcli system snmp test
Comments: There is 1 target configured, send warmStart requested, test completed normally.
Y comprobaremos el estado y configuración con un esxcli system snmp get:
esxcli system snmp get

Authentication: MD5
Communities: public
Enable: true
Engineid: 0293a84c7118760f815e9b08fd75fceb
Hwsrc: indications
Largestorage: true
Loglevel: info
Notraps:
Port: 161
Privacy: AES128
Remoteusers:
Syscontact:
Syslocation:
Targets:
Users: snmpuser/3516d465f81e5c08421cb50bd5cc8977/3516d465f81e5c08421cb50bd5cc8977/priv
V3targets: 192.168.1.15@161 snmpuser priv trap
Como buena práctica, tendríamos que irnos ahora al siguiente enlace https://kb.vmware.com/s/
article/1013445 y descargar el fichero llamado 1013445_VMware-mibs-6.7.0-10201460.zip, que
incluye las últimas MIB más actualizadas, en concreto tendremos que importar las siguientes MIB para
que podamos monitorizar VCSA de manera satisfactoria:
a. VMWARE-ROOT-MIB.mib
b. VMWARE-TC-MIB.mib
c. VMWARE-PRODUCTS-MIB.mib
Si queremos lanzar un snmpwalk desde un nodo que tenga el paquete instalado, podríamos hacerlo de
la siguiente manera, de esta manera podremos comprobar que nuestro SNMP está bien configurado:
snmpwalk -v3 -l authPriv -u userid -a SHA -A “PASSWORD1” -x AES -X “PASSWORD1” ESXIHOSTNAME
Si todo está bien configurado podremos ver una respuesta similar a este output:
SNMPv2-MIB::sysDescr.0 = STRING: VMware ESXi 6.7.0 build-10302608 VMware, Inc. x86_64

SNMPv2-MIB::sysObjectID.0 = OID: VMWARE-PRODUCTS-MIB::vmwESX
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (402700) 1:07:07.00
SNMPv2-MIB::sysContact.0 = STRING:
SNMPv2-MIB::sysName.0 = STRING: esxi-zlon-002
A partir de aquí, ya solamente nos queda usar nuestra aplicación de monitorización de SNMP.
4. Monitorizando nuestro entorno de vSphere usando

herramientas open source
Una vez que hemos visto en detalle cómo habilitar y testear nuestros diferentes componentes de
VMware, he querido dedicar este último capítulo de la sección sobre monitorización al open source.
Es cierto que hay muchas soluciones open source que monitorizan VMware, tales como el ya longevo
Nagios, o soluciones open con parte comercial como son Centreon por poner un ejemplo rápido, pero
en este libro no voy a extenderme sobre el uso y administración de dichas herramientas.
Podemos encontrar en Internet y en Castellano mucho material al respecto sobre las mencionadas
tecnologías open source y VMware.
En esta sección he querido ir un paso más allá y abstraer la complejidad de entornos de monitorización
al uso, gracias a un simple grupo de aplicaciones y servicios open source que se despliegan en apenas
unos segundos, y que nos ofrecerán una visibilidad de nuestro entorno de VMware mediante elegantes
y personalizables Dashboards.
4.1 InfluxDB, Telegraf y Grafana
En este capítulo vamos a ver cómo podemos crear bellos y funcionales Dashboards para poder colgar
en nuestras pantallas donde los técnicos pueden comprobar de un simple vistazo el estado general de
la Infraestructura vSphere.
Antes de sumergirnos de lleno con el despliegue de estos tres servicios, quiero dejaros un breve
diagrama de los diferentes componentes que vamos a desplegar en una simple VM (estos servicios
pueden escalar para monitorizar varios cientos de miles de VMs, pero para comenzar con una VM todo
en uno es suficiente).
Como podemos ver tenemos diferentes actores principales en cada uno de los rectángulos de colores:
• Telegraf: Se trata del servicio que ejerce de agente recolectando todo tipo de métricas de diferentes
orígenes, tales como pueden ser: Scripts, Estadísticas de estado, Networking, logs, o en nuestro
caso recolecta información directamente de nuestro vSphere SDK.
• InfluxDB: La Base de datos que almacena los cientos de miles de eventos de cada componente
de vSphere, además de las métricas de vSphere; InfluxDB puede almacenar cualquier otra serie
con datos en específicos rangos de tiempo.
• Grafana: Una solución open source para la creación de Dashboards que soporta múltiples
orígenes de datos, uno de ellos es InfluxDB, con el que tiene una integración muy completa. Con
lo que Grafana mostrará las estadísticas y contadores que seleccionemos en el rango de tiempo
especificado.
Estas tres soluciones pueden expandirse mucho más para cubrir prácticamente cualquier necesidad
dentro de nuestro Datacenter, pero en este libro nos vamos a enfocar en la visualización de entornos
vSphere con ellas.
4.1.1 Instalación y configuración de InfluxDB, Telegraf y Grafana

Para el laboratorio, vamos a usar Ubuntu Server 16.04, pero estos pasos se pueden seguir con
cualquier otra distribución Linux, buscar por los instalables en la web oficial de cada proyecto.
Estos son los recursos Hardware que recomiendo para un entorno de entre 1 a 25 Hosts ESXi,
almacenando métricas de unas 300VMs por un periodo de unos doce meses.
Recursos Cantidad
vCPU 4
RAM 8GB RAM
Disco 150GB (SAS o SSD)
Networking VMXNET3
Controladora PVSCSI
4.1.1.1 Instalación paso a paso de InfluxDB
Vamos a comenzar con la instalación de InfluxDB, la base de datos donde almacenaremos todas las
estadísticas, para ello vamos a comenzar añadiendo el repositorio necesario para los paquetes de
InfluxDB y Telegraf:
curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add –
source /etc/lsb-release
echo “deb https://repos.influxdata.com/${DISTRIB_ID,,} ${DISTRIB_CODENAME} stable” | sudo

tee /etc/apt/sources.list.d/influxdb.list
Una vez que hemos añadido el repositorio, tendremos que actualizar los paquetes de la siguiente
manera:
sudo apt-get update
Con los paquetes ya actualizados, podremos proceder a la instalación de InfluxDB; lanzando el

siguiente comando:
sudo apt-get install influxdb
Procederemos a ejecutar el servicio de la siguiente manera:
sudo systemctl start influxdb
Este comando nos mostrará un mensaje similar a este:
influxdb.service - InfluxDB is an open-source, distributed, time series database
Loaded: loaded (/lib/systemd/system/influxdb.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2018-12-12 13:10:33 CST; 05s ago
Docs: https://docs.influxdata.com/influxdb/
Main PID: 1718 (influxd)
CGroup: /system.slice/influxdb.service
└─1718 /usr/bin/influxd -config /etc/influxdb/influxdb.conf
Vamos a crear ahora un usuario para administrar InfluxDB, en este caso le he llamado admin, pero
podemos seleccionar el nombre y password que deseemos, entraremos en la aplicación de InfluxDB
lanzando este comando:
influx
Y ejecutaremos este comando cambiando los datos por los vuestros:
CREATE USER “admin” WITH PASSWORD ‘adminvmware2019’ WITH ALL PRIVILEGES
Si lanzamos ahora el siguiente comando podremos ver los usuarios que tenemos:
show users
Output
user admin
---- -----
admin true
Saldremos ahora de la aplicación de InfluxDB con un simple exit:
exit
Y editaremos el fichero de configuración de InfluxDB para habilitar la autenticación HTTP, de la siguiente

manera:
sudo nano /etc/influxdb/influxdb.conf
Haremos scroll hasta que encontremos la sección [http] y donde pone auth-enabled, cambiaremos su
valor por true:
...
[http]
# Determines whether HTTP endpoint is enabled.
# enabled = true
# The bind address used by the HTTP service.
# bind-address = “:8086”
# Determines whether HTTP authentication is enabled.
auth-enabled = true
...
Saldremos y guardaremos los cambios y reiniciaremos el servicio de InfluxDB:
sudo systemctl restart influxdb
4.1.1.2 Instalación paso a paso de Telegraf
Vamos a seguir ahora con la instalación de Telegraf, recordemos el agente que se encarga de recoger
las métricas de diferentes lugares, usando scripts, o en nuestro caso para VMware comunicándose
directamente con el SDK de vSphere, como ya tenemos el repositorio oficial, será tan sencillo como
lanzar la instalación:f
sudo apt-get install telegraf
El servicio se ejecuta de manera automática, con lo que no tenemos que realizar ninguna acción
adicional, ahora tendremos que configurar Telegraf para que pueda mandar la información que recolecta
a nuestra base de datos de InfluxDB, para ello editaremos el fichero de configuración de Telegraf:
sudo nano /etc/telegraf/telegraf.conf
Buscaremos la sección llamada [[outputs.influxdb]] e introduciremos nuestra URL, puede ser localhost
si estamos instalando todo en uno, y muy importante es que seleccionaremos el username y password
que hemos creado anteriormente al instalar InfluxDB:
[[outputs.influxdb]]
## The full HTTP or UDP endpoint URL for your InfluxDB instance.
## Multiple urls can be specified as part of the same cluster,
## this means that only ONE of the urls will be written to each interval.
# urls = [“udp://localhost:8089”] # UDP endpoint example
urls = [“http://localhost:8086”] # required
## The target database for metrics (telegraf will create it if not exists).
database = “telegraf” # required
...
## Write timeout (for the InfluxDB client), formatted as a string.
## If not provided, will default to 5s. 0s means no timeout (not recommended).
timeout = “5s”
username = “admin”
password = “adminvmware2019”
## Set the user agent for HTTP POSTs (can be useful for log differentiation)
# user_agent = “telegraf”
## Set UDP payload size, defaults to InfluxDB UDP Client default (512 bytes)
# udp_payload = 512
Reiniciaremos el servicio de Telegraf con el siguiente comando, para que se incluyan los cambios:
sudo systemctl restart telegraf
Si queremos comprobar el estado del servicio lanzaremos el siguiente comando
systemctl status telegraf
Que nos debería de mostrar un output similar a este:
telegraf.service - The plugin-driven server agent for reporting metrics into InfluxDB
Loaded: loaded (/lib/systemd/system/telegraf.service; enabled; vendor preset:

enabled)
Active: active (running) since Tue 2017-03-14 15:24:41 CST; 1min 26s ago
Docs: https://github.com/influxdata/telegraf
Main PID: 1752 (telegraf)
CGroup: /system.slice/telegraf.service
└─1752 /usr/bin/telegraf -config /etc/telegraf/telegraf.conf -config-directory

/etc/telegraf/telegraf.d
4.1.1.3 Instalación paso a paso de Grafana
Es el turno de proceder a la instalación de Grafana para comenzar a mostrar información básica,

para ello tendremos que añadir el repositorio de Grafana a nuestro sistema operativo de la siguiente
manera:
curl https://packages.grafana.com/gpg.key | sudo apt-key add -
Actualizaremos nuestros paquetes y lanzaremos la instalación de Grafana con los siguientes comandos:
sudo apt-get update
sudo apt-get install grafana
Para hacer que el servicio de Grafana se ejecute con cada inicio del sistema operativo lanzaremos el
siguiente comando:
sudo update-rc.d grafana-server defaults
Procederemos a arrancar el servicio con el siguiente comando:
systemctl start grafana-server
Para comprobar el estado del servicio lanzaremos el status, como hemos hecho anteriormente para
los otros servicios:
systemctl status grafana-server
Que nos mostrará un output similar a este:
grafana-server.service - Grafana instance
Loaded: loaded (/usr/lib/systemd/system/grafana-server.service; disabled; vendor

preset: enabled)
Active: active (running) since Wed 2018-12-19 00:39:00 GMT; 2 months 5 days ago
Docs: http://docs.grafana.org
Main PID: 9769 (grafana-server)
CGroup: /system.slice/grafana-server.service
9769 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini --pidfile=/var/

run/grafana/grafana-server.pid --packaging=deb cfg:default.paths.logs=/var/log
¡Ya tenemos todo listo! Nos iremos a nuestro navegador favorito e introduciremos la siguiente URL
http://IPDELSERVER:3000 esto nos llevará a la página de login de Grafana, el usuario y password por
defecto es admin/admin:
Nada más hacer login tendremos que añadir un Datasource para que Grafana pueda mostrarnos datos
de una base de datos, en nuestro caso recordemos que usamos InfluxDB:
Aunque seleccionaremos InfluxDB, podemos ver el potencial de la herramienta pudiendo añadir una
infinidad de Datasources a Grafana, como he comentado, seleccionaremos InfluxDB ahora:
La configuración es muy sencilla, tendremos que prestar atención solamente a un par de parámetros
tales como la URL, localhost en mi caso, y por supuesto las credenciales de InfluxDB:
Si todo ha ido bien podremos presionar el botón de Save & Test que nos mostrará algo similar a este
mensaje en caso de que todo funcione como es debido:
Por defecto Telegraf recoge información del servidor donde se ha instalado, esto quiere decir que
tendremos datos del estado y consumo de la CPU, RAM, Disco y Networking de esta VM donde
estamos instalando Telegraf, InfluxDB y Grafana, para tomar contacto con el sistema de Dashboarding,
vamos a crear un nuevo Dashboard, de tipo Graph:
Sobre Panel Title, haremos click y seleccionaremos Edit:
Esto nos mostrará la configuración de esta gráfica que queremos mostrar, os dejo la manera tan
sencilla que tenemos para hacer una selección del consumo de la CPU, por ejemplo:
En la imagen vemos que he seleccionado la métrica CPU, del host que es la VM donde hemos
instalado todo este stack, he seleccionado el campo usage_system, y le he dado un poco de formato
ordenándolo por vCPU, y cambiando el resultado que se muestra como %. Como esta gráfica podemos
generar RAM, Disco, Networking y demás, hay varios tutoriales en Internet sobre ello, y en este libro
no hablaremos más en detalle sobre Grafana, vamos ahora a ver cómo importar los Dashboards y
monitorizar VMware.
4.2 Configuración de Telegraf para monitorización de vSphere
La monitorización de entornos de vSphere usando el SDK de VMware está disponible de manera

nativa en Telegraf desde su versión 1.8, anunciada en septiembre de 2018. Esto nos abre las puertas
de una monitorización mucho más detallada y de manera nativa para Telegraf, ¡fantástico!
Para configurar Telegraf para que recolecte información de nuestros vSphere, editaremos el fichero de
configuración de Telegraf:
/etc/telegraf/telegraf.conf
Buscaremos la sección llamada [[inputs.vsphere]] y en ella introduciremos el FQDN, usuario y

contraseña con privilegios de nuestro vCenter:
[[inputs.vsphere]]
## List of vCenter URLs to be monitored. These three lines must be uncommented
## and edited for the plugin to work.
vcenters = [ “https://NUESTROVCSAFQDN/sdk” ]
username = “YOURUSER@vsphere.local”
password = “YOURPASS”
Además, vamos a tener que eliminar el estado de comentario al resto de parámetros, por ejemplo, si
queremos monitorizar todos los parámetros os quedaría así:
## VMs
## Typical VM metrics (if omitted or empty, all metrics are collected)
vm_metric_include = []
# vm_metric_exclude = [] ## Nothing is excluded by default
# vm_instances = true ## true by default
## Hosts
## Typical host metrics (if omitted or empty, all metrics are collected)
host_metric_include = []
# host_metric_exclude = [] ## Nothing excluded by default
# host_instances = true ## true by default
## Clusters
cluster_metric_include = [] ## if omitted or empty, all metrics are collected
# cluster_metric_exclude = [] ## Nothing excluded by default
# cluster_instances = true ## true by default
## Datastores
datastore_metric_include = [] ## if omitted or empty, all metrics are collected
# datastore_metric_exclude = [] ## Nothing excluded by default
# datastore_instances = false ## false by default for Datastores only
## Datacenters
datacenter_metric_include = [] ## if omitted or empty, all metrics are collected
datacenter_metric_exclude = [ “*” ] ## Datacenters are not collected by default.
datacenter_instances = false ## false by default for Datastores only
Además, en caso de que no estemos usando un SSL válido y comercial en nuestro entorno, lo más
sencillo es editar lo siguiente para que acepte certificados SSL auto-firmados y poner true:
insecure_skip_verify = true
Una vez que hemos hecho estos cambios, reiniciaremos nuestro servicio de Telegraf usando:
sudo systemctl restart telegraf
Si quisiéramos ojear de manera rápida si ya estamos recogiendo datos de vSphere, podríamos

directamente realizar estas consultas a la base de datos, donde podremos ver que tenemos ya tablas
llamadas vsphere_*:
influx
> use telegraf
Using database Telegraf
> show measurements
name: measurements
name
----
vsphere_cluster_clusterServices
vsphere_cluster_cpu
vsphere_cluster_mem
vsphere_cluster_vmop
vsphere_datacenter_vmop
vsphere_datastore_datastore
vsphere_datastore_disk
vsphere_host_cpu
vsphere_host_disk
vsphere_host_mem
vsphere_host_net
vsphere_host_power
vsphere_host_storageAdapter
vsphere_host_sys
vsphere_vm_cpu
vsphere_vm_mem
vsphere_vm_net
vsphere_vm_power
vsphere_vm_sys
vsphere_vm_virtualDisk
Esto significa que Telegraf ya está recibiendo correctamente información desde nuestro vSphere hacía
Telegraf y de ahí se está almacenando en nuestra base de datos InfluxDB.
4.3 Importar Dashboards ya listos en Grafana para monitorización de

vSphere
Ahora que tenemos información en nuestro InfluxDB, llega la hora de visualizarla, hemos realizado un
vistazo rápido a Grafana y sus gráficas en la sección anterior, ahora vamos a importar una serie de
Dashboards que he creado, y que ya traen todo el trabajo complicado de crear las gráficas y dejarlas
bonitas, hecho. He creado cuatro Dashboards y vamos a ver cómo importar todos ellos.
En Grafana, una vez hecho login y todo, nos iremos hasta el menú de la izquierda, pulsaremos el + y
seleccionaremos Import:
Podemos introducir el ID de cada Dashboard o la URL, os dejo aquí los datos:
• VMware vSphere – Overview – 8159 - https://grafana.com/dashboards/8159
• VMware vSphere – Datastore – 8162 - https://grafana.com/dashboards/8162
• VMware vSphere – Hosts – 8165 - https://grafana.com/dashboards/8165
• VMware vSphere – VMs – 8168 - https://grafana.com/dashboards/8168
Una vez introducimos el ID o la URL de ellos, veremos el siguiente menú que nos permitirá cambiar el
nombre, seleccionar una carpeta para guardarlos, y el datasource que queremos usar:
Os quiero dejar un ejemplo de cómo queda cada Dashboard para que os hagáis una idea sin necesidad
de importarlos:
VMware vSphere – Overview
Este Dashboard nos muestra un breve resumen de todo el entorno en general, desde el Clúster y
Hosts, pasando por Datastores y VMs con el rendimiento en la parte de Networking y Storage:
VMware vSphere – Datastore
En este Dashboard se muestra el resumen más detallado de cada Datastore, capacidad, espacio
usado y rendimiento:
VMware vSphere – Hosts
En este Dashboard se muestra el resumen más detallado de cada Host, consumo de CPU, RAM y
Networking, así como rendimiento de las HBA y Storage:
VMware vSphere – VMs
Por último, tenemos el Dashboard sobre máquinas virtuales, que nos muestra el resumen más detallado
de cada VM, consumo de CPU, RAM y Networking, así como valores tan importantes como la CPU
Ready:
5. Monitorizando nuestro entorno de vSphere usando

Wavefront y Telegraf
Wavefront es el servicio Enterprise que VMware proporciona para ofrecer una monitorización en tiempo
real, con Dashboards que se crean gracias a la información y métricas que se envían a Wavefront
desde vSphere o desde cualquier aplicación, o componente dentro o fuera de nuestro Datacenter.
Desde la versión 1.8 de Telegraf, en la que se monitoriza vSphere usando el SDK, Wavefront soporta
de manera oficial Telegraf con esta integración de manera nativa - https://docs.wavefront.com/vsphere.
html
Pudiéndose crear Dashboards tan útiles y potentes como el siguiente:
6. Referencias
• https://www.virten.net/vmware/esxtop/
• https://jorgedelacruz.es
• https://wikipedia.com
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 11
Monitorización con Centreon
Héctor Herrero
Capítulo 11 - Monitorización con Centreon Héctor Herrero
Monitorizando vSphere con Centreon
En este capítulo vamos a aprender cómo desplegar Centreon y cómo monitorizar con él nuestra
plataforma virtual.
Centreon es una solución para monitorizar aplicaciones, sistemas, redes y nuestro negocio. Basada
en los mismos conceptos que Nagios y siendo un software de código abierto, distribuido bajo Licencia
Pública General de GNU GPLv2.5. Claro que podemos adquirir una versión comercial donde aparte
de soporte nos proveerán de los complementos de pago, con ellos fácilmente podremos monitorizar
toda la infraestructura. Pero la idea del documento será siempre basarnos en la solución abierta y por
tanto gratuita. Centreon inicialmente fue conocida por aportar una interfaz web de gestión sencilla a
Nagios, evitando tocar sus complicados ficheros de configuración, una alternativa a Nagios y NDOUtils
fueron Centreon Engine y Centreon Broker, que tienen fama de ser más eficientes en cuanto al uso
de recursos y con mayor seguridad. Por tanto, trabajaremos con la ISO de la distribución de Centreon.
Al final del capítulo, veremos también cómo visualizar los datos de nuestro entorno virtual ya
monitorizado con NagVis y Grafana.
1. Monitorización con Centreon
La monitorización es un sistema de supervisión de gran alcance que permite a las organizaciones

identificar y resolver problemas de infraestructura TI antes de que afecten los procesos críticos de
negocio. Un sistema de monitorización le da la tranquilidad de saber que los procesos de negocio de
su organización no se verán afectados por interrupciones desconocidas.
Centreon es una potente herramienta que le permite la visión instantánea de aplicaciones críticas en
la infraestructura de su organización. También le permite detectar y reparar los problemas y mitigar
futuros incidentes antes de que afecten a los usuarios finales y clientes.
Centreon se basa en un sistema distribuido donde podemos tener los componentes en un mismo
servidor, o en entornos grandes separarlo en distintas máquinas, tenemos:
• Centreon Central: Es el servidor que corre el motor de monitorización además de ser también un
Poller y encargarse de las notificaciones entre otros.
• Centreon Poller: Son servidores satélites que podremos ir agregando a nuestra infraestructura para
repartir la carga de ejecución de los chequeos. Además, en entornos donde disponemos diferentes
delegaciones nos servirá para centralizar y encapsular toda la información de los chequeos de las
máquinas remotas al Central.
• Base de datos: Servicio de BBDD basado en MariaDB que dispondrá de dos bases de datos:
• centreon: Almacena metadatos y configuraciones del sitio.
• centreon_storage: Almacena la monitorización en tiempo real y almacena históricos.
Mediante un sistema de alertas, podremos recibir un aviso del servicio afectado por el cual el sistema
puede verse comprometido. Este sistema de alertas gestionará los avisos vía mail, Whatsapp, Telegram,
SMS, o incluso pueden ser introducidos en un sistema de gestión de incidencias (helpdesk), siendo
totalmente escalables a los departamentos responsables de dichos servicios.
1.1 Supervisión en tiempo real
Podremos supervisar en tiempo real el estado de los ítems o Servicios monitorizados, así como el
estado de los Hosts (servidores / impresoras / routers / switches / fw…). Nos mostrará cada Servicio
con un indicador OK, WARNING o CRITICAL dependiendo del estado de su salud.
También podremos agrupar los Servicios por Tipo, por si queremos trabajarlos de forma conjunta,
esto es, ver por ejemplo todos los Routers de un vistazo, o todos los servicios de vCenter, Correo,
Infraestructura virtual, Infraestructura física, de comunicaciones…
Podemos filtrar por Host, Servicio, por Grupo… Desde aquí también podremos deshabilitar un Servicio
que no se monitorice temporalmente, o forzar que se checkee de nuevo, o entre otros habilitar el Modo
Mantenimiento y así excluir durante un periodo los checkeos y no ‘manchar’ las gráficas de SLA con
tiempos de caída de servicio, si no de parada de servicio programada.
1.2 Gráficas
Todo Servicio monitorizado generará unas gráficas que podremos utilizar para conocer su estado,
su crecimiento o conocer su historial para poder analizar y buscar problemas. Podremos filtrar por
periodos y realizar comparaciones con otros Servicios monitorizados, permite exportar las imágenes o
los datos que vemos en CSV para luego tratarlos si interesase de una forma muy rápida.
De este modo podremos calcular la capacidad de nuestros sistemas y pronosticar futuras ampliaciones
sobre ellos.
También dispondremos de un Log de Eventos en el que se registrarán todos los sucesos encontrados
en nuestro sistema, pudiendo así analizarlos eficazmente.
Será un histórico de lo que ha sucedido en nuestro entorno, qué servicios o hosts han caído y cuando.
Como siempre, podremos filtrar también por equipo, o periodos de fecha entre otros.
Con esta serie de avisos podremos atacar los problemas de una manera mucho más eficaz ya que
iremos directamente a solucionar el elemento crítico, reduciendo el tiempo de identificación del
problema y el restablecimiento exitoso del servicio.
La monitorización no solo nos ayudará en caso de caída de servicios, sino que también nos facilitará
su identificación mucho antes de que un servicio llegue a comprometerse.
1.3 Medición de SLA
El Dashboard dentro de la monitorización cumple una función muy importante, ya que a través de
él controlaremos el porcentaje de actividad (OK, WARNING. CRITICAL, UNKNOWN, SCHEDULED
DOWNTIME) de nuestros hosts y servicios en un determinado periodo de tiempo.
Con ello será fácil comprobar el cumplimiento de los SLA de disponibilidad (o acuerdo de nivel de
servicio) de los servicios y servidores. Por supuesto tendremos una medición exacta de la Calidad de
servicio que ofrece,
Podremos ver y medir de una forma muy gráfica los tiempos de servicio o SLA que está dando bien
un equipo, un servicio o grupo de equipos o servicios. Analizaremos el % de tiempo que ha estado
cada ítem, el tiempo en OK será que estaba corriendo perfectamente, WARNING indicará que supera
el baremo que indicamos, pero funcional; CRITICAL sí será el tiempo total de parada y también
interesante, conocer el tiempo de parada programada para mantenimiento!
2. NagVis
NagVis es una capa de visualización de dibujos interactivos que se le añade a Centreon para poder
disponer de cualquier tipo de mapa de estado en tiempo real.
¿Qué es un mapa? Un mapa es cualquier dibujo que queramos tener en una pantalla de TV, estos
mapas pueden ser dibujos lógicos o físicos a los que les añadiremos los Servicios que monitorizamos.
Son dibujos totalmente corporativos y personalizados que mostrarán lo que quieras ver en cada uno
de ellos.
Mapas vivos con tráficos de red de las delegaciones al DataCenter, Estado del rack, Plataforma virtual
y sus dependencias…
Son ideales para disponer de una TV en su departamento y tener un Pool que rota distintos mapas,
demostrará lo bien que tiene controlado su departamento a los demás, en caso de que un servicio
se caiga se pondrá el mapa afectado sonando una alerta. Algunos mapas de ejemplo basados en
entornos vSphere:
Mapa de plataforma virtual:
Mapa de Rack:
Mapa de red de almacenamiento o SAN:
Mapa de comunicaciones LAN
Mapa de comunicaciones WAN:
3. Grafana
Grafana no es más que un Panel de explotación y visualización de datos. Es un Dashboard que permite
visualizar cualquier tipo de métrica. Si con las gráficas de Centreon no te bastan, Grafana es la mejor
solución para tratamiento de datos. Podrás personalizar Dashboards a medida y a gusto, añadiendo
las métricas monitorizadas del Centreon directamente. Super sencillo de usar, podrás añadir gráficas
de CPUs, consumos de Memorias, estado de servicios, tanto de MVs como hosts.
Pero ojo, no queda ahí, Grafana se puede usar para explotar datos de tu empresa, visualizar cualquier
dato que se almacene en una base de datos se puede consultar. Ya sean sus bases de datos del ERP
y analizar crecimiento, ventas o compras entre otros, o su sistema de gestión de tiempos o fichajes,
etc, etc… Podrás exportar tus Dashboards a PDF y programar envíos de correos con informes listos
según la demanda requerida.
Por tanto, Grafana se ejecuta de forma individual en otra máquina virtual y se licencia bajo la licencia
Apache License 2.0, libre de costes en cuanto a licenciamiento.
4. Monitorización de Negocio
Una vez dispongamos de la base totalmente monitorizada, siempre se puede escalar dicha monitorización
y pensar un poco en el Negocio. ¿Qué necesita la empresa para que desarrolle su servicio? ¿Qué debe
funcionar? Bien, con la base monitorizada, podremos interrelacionar las dependencias del Negocio en
los Servicios monitorizados. Con ello, podremos saber y medir el SLA que ofrecemos a la empresa, así
como a sus diferentes departamentos organizativos. Se analizarán y sacarán puntos críticos para que
su Negocio no pare su servicio.
¿Sabía acaso que su negocio podría detenerse si un certificado que apenas pasa de los 50€ se
caduca? Es importante conocer qué monitorizar y por qué.
La monitorización de Negocio consiste en la instalación de un componente de análisis de negocio,

pudiendo ser mediante Centreon Monitoring Bussines Intelligence o Nagios Business Process. Más la
compleja definición de cada Servicio Operacional y sus Servicios de Infraestructura.
Se podrán realizar análisis de impacto, para determinar la importancia de un elemento monitorizado.

A la hora de preguntarse por ejemplo ¿Qué pasa si apago este servidor? ¿y si quito este cable?
Conoceremos a qué Servicios de Negocio afectará antes de tocar nada. Por supuesto también para
conocer simulaciones de configuraciones óptimas, etc…
Ejemplo de los principales Servicios de Negocio:
Ejemplo, Servicio Atención al Cliente:
Ejemplo, Servicio Correo Electrónico:
5. Prerrequisitos
A la hora de desplegar Centreon, debemos considerar el tamaño y tipo de monitorización que

necesitaremos. Si únicamente tenemos los ítems a monitorizar en una ubicación o en distintas, para
saber si comenzar con un servidor Central o al menos necesitaremos Pollers, así como el volumen de
los Servicios que monitorizaremos, ya que la ejecución se realiza desde los servidores de Centreon, a
más ítems monitorizados, más recursos necesitará nuestra plataforma; y es posible añadir servidores
Poller para repartir la carga de los chequeos.
La ISO con la distribución de Centreon se basa en un CentOS 7 de x64, para trabajar con ella
necesitaremos un navegador compatible, hoy en día últimas versiones de Firefox, Chrome o Safari
nos valdrán, así como a partir de IE 11. Se recomienda almacenar los datos en una base de datos de
MariaDB en vez de MySQL, y en entornos grandes en, al menos, una máquina dedicada. Un servidor
Poller podría monitorizar unos 7000 servicios de monitorización, con una CPU de al menos 3Ghz, a
más servicios monitorizados, más CPU necesitaremos; dependerá de la complejidad de los chequeos
y su consumo. Como tabla que nos puede servir a modo referencia, usaremos:
Número de Número de Hosts Número de

Central Poller
Servicios (estimados) Servidores
< 500 50 1 Central 1 vCPU + 1 GB RAM
500 - 2000 50 - 200 1 Central 2 vCPU / 2 GB RAM
2000 - 7000 200 - 700 1 Central + 1 Poller 4 vCPU / 4 GB RAM 1 vCPU / 4 GB RAM
7000 - 14000 700 - 1400 1 Central + 1 Poller 4 vCPU / 8 GB RAM 2 vCPU / 4 GB RAM
14000 - 21000 1400 - 2100 1 Central + 2 Pollers 4 vCPU / 8 GB RAM 2 vCPU / 4 GB RAM
21000 - 28000 2100 - 2800 1 Central + 3 Pollers 4 vCPU / 8 GB RAM 2 vCPU / 4 GB RAM
En cuanto al almacenamiento en disco, esto es, en la base de datos y directorio del Engine; pues todo
dependerá del número de los Servicios que se monitoricen y la frecuencia con la que se ejecutan,
además, será importante establecer una retención de los datos. Por poner una tabla de ejemplo, si
nuestros Servicios se chequean cada 5 minutos y tenemos una retención de 6 meses:
Número de Servicios /var/lib/mysql /var/lib/centreon

< 500 10 GB 2.5 GB
500 - 2000 42 GB 10 GB
2000 - 10000 126 GB 30 GB
10000 - 20000 252 GB 60 GB
20000 - 50000 660 GB 150 GB
50000 - 100000 1.4 TB 600 GB
Los servidores de Centreon deben de usar LVM para la gestión de los discos, este será el espacio que
definiremos:
Rol Path Tamaño

Swap De 1 a 1,5 veces el tamaño de la Memoria RAM
/ Al menos 20 GB
Centreon Central o /var/log Al menos 10 GB
Centreon Poller /var/lib/centreon Indicado en la tabla anterior
/var/lib/centreon-broker Al menos 5 GB
/var/cache/centreon/backup Al menos 10 GB
Swap De 1 a 1,5 veces el tamaño de la Memoria RAM
/ Al menos 20 GB
Servidor de BD /var/log Al menos 10 GB
/var/lib/mysql Indicado en la tabla anterior
/var/cache/centreon/backup Al menos 10 GB

6. Instalando Centreon
Lo dicho, gracias al interfaz de Centreon, podremos monitorizar de una manera sencilla, desplegaremos
una máquina virtual, será el que almacene toda la información y además ejecute los chequeos de
salud. Monitorizaremos nuestros servidores Windows, Linux, hosts ESXi, máquinas virtuales, puertos,
certificados, servicios o ejecución de cualquier script que se nos ocurra, sea PowerShell, scripts en
batch, perl, vb… En esta sección veremos puramente la instalación con un sólo servidor.
Nos descargamos la ISO o el appliance virtual de https://download.centreon.com/ y comenzaremos

su despliegue.
Tendremos en cuenta que también nos podremos bajar directamente un appliance virtual en formato
OVA con todo instalado y listo, pero mejor para laboratorios de casa que en producción.
Tras conectar la ISO a la MV comenzamos la instalación de la distribución CES en Centos 7, escogemos

el idioma para la instalación, “Continue”.
Pulsamos primeramente en ‘Installation Type’
Donde debemos seleccionar el tipo de despliegue que haremos, en este caso como indicamos
tendremos este único servidor con todos los roles. “Done”.
Pulsamos en ‘Installaton Destination’,
Y seleccionamos el disco duro y el modo de particionamiento a utilizar. “Done”.
Seleccionamos ‘Network & Hostname’
Habilitamos la interfaz, le indicamos un nombre de máquina con formato FQDN y pulsamos en

“Configure…”,
En ‘IPv4 Settings’ debemos especificar una dirección IP estática, una máscara de red, puerta de enlace,
servidores DNS y dominio de búsqueda local.
No olvidaremos configurar la hora y la zona horaria. Tras ello, comenzamos ya la instalación pulsando
‘Begin Installation’.
Durante la instalación podremos establecer la contraseña al usuario ‘root’, así como crear si necesitamos
usuarios adicionales.
Con establecer el password a root nos será suficiente.
Esperamos, en cuestión de minutos tendremos Centreon desplegado…
Listo, pulsamos en “Reboot” para reiniciar la máquina, recordar desconectar la ISO.
Accedemos mediante un navegador a la dirección IP de Centreon, comenzará un asistente final de

configuración.
Verificamos que disponemos de los módulos correctamente cargados & “Next”,
Estos serían los datos predeterminados del motor de monitorización:
• Directorio de Centreon Engine: /usr/share/centreon-engine

• Binario de las estadísticas de Centreon: /usr/sbin/centenginestats
• Directorio Centreon Engine: /var/lib/centreon-engine
• Directorio del conector de Centreon: /usr/lib64/centreon-connector
• Directorio de librerías de Centreon: /usr/lib64/centreon-engine
• Directorio donde dejaremos los plugins para usar con Centreon: /usr/lib/centreon/plugins
Información sobre la parte del broker:
• Directorio del broker en etc: /etc/centreon-broker

• Módulo del broker: /usr/lib64/nagios/cbmod.so
• Directorio de logs del broker: /var/log/centreon-broker
• Directorio del fichero de retención: /var/lib/centreon-broker
• Directorio de librerías: /usr/share/centreon/lib/centreon-broker
Debemos establecer una contraseña al usuario admin para la gestión de Centreon, así como indicarle
un nombre, apellido y dirección de correo electrónico, “Next”,
Configuraremos la conexión de Centreon con la base de datos, indicaremos que el servidor es ‘localhost’,
puerto 3306, la contraseña del usuario root, indicaremos un nombre a la BD de configuración, y otro
nombre a la BD de datos, crearemos un usuario y le asignaremos una contraseña.
Antes de proceder, debemos añadir permisos desde consola o acceso mediante SSH ejecutando:
mysqladmin -u root password CONTRASEÑA

mysqladmin -u root -h localhost CONTRASEÑA
Continuamos mientras nos crea la estructura de la BD,
Marcamos los módulos Centreon License Manager y Centreon Plugin packs Manager. Nos servirán de
mucha ayuda para desplegarnos plantillas. Pulsamos en “Install”.
Tras su instalación, continuamos con “Next”,
Y ya dispondremos de Centreon instalado y configurado básicamente. Pulsamos en “Finish”.
Ahora ya podremos loguearnos en nuestro panel de Centreon, accedemos como admin y la contraseña
que le hemos establecido durante el asistente de configuración.
Bienvenidos a la interfaz de Centreon, disponemos los siguientes menús:
• Home: Podremos añadir widgets y hacer una vista inicial algo chula con las gráficas más típicas
que solemos consultar. Así como ver las estadísticas del Poller.
• Monitoring: Será la parte desde donde veremos los resultados de la monitorización, los servicios
que analicemos, aquí será donde veremos si el estatus es OK, WARNING o CRITICAL.
• Reporting: Un apartado chulo para medir SLA’s y tiempos de respuesta a nivel individual o a nivel
de grupos de servicios o hosts.
• Configuration: Donde configuraremos los hosts a monitorizar, así como sus servicios o comandos.
Además, en este apartado podremos crear o modificar usuarios, tipos de notificación, Pollers,
Traps SNMP,
• Administration: Para configurar parámetros de Centreon, extensiones sean widgets o módulos,

permisos de ACL, logs, y supervisar el estado del servidor entre otros.
Desde la barra superior: Interesante, de un vistazo podremos supervisar el estado general de nuestra
monitorización, así como el status general de cuántos hosts o servicios hay caídos.
Si vamos a “Configuration” > “Plugin Packs” > “Manager”, llegaremos gestor de plugins que deberemos
instalar. Estos nos crearán las plantillas o templates que necesitaremos para ir creando nuestros hosts
a monitorizar (hosts serán los servidores, impresoras, dispositivos…). Así que será bueno tener la
base de todos estos y así poder monitorizar al menos ya equipos con Linux, Windows, Impresoras,
dispositivos Cisco, SAI, BD de MySQL, así como el propio servidor de Centreon, su base de datos o
el estado del Poller.
7. Monitorizando Hosts ESXi
Bien, tras instalar Centreon, ya podemos directamente monitorizar nuestra plataforma de vSphere,
comenzaremos con los hosts ESXi.
Utilizaremos un magnifico script que conectará mediante API y obtendrá la información que necesitamos.
Pero primeramente debemos instalar los requisitos que requieren que podamos comenzar a usar el
script.
7.1 Instalación requisitos previos
En la máquina de Centreon debemos comenzar con la instalación de requisitos y dependencias:
yum -y install openssl-devel perl-Archive-Zip perl-Class-MethodMaker uuid-perl perl-SOAP-

Lite perl-XML-SAX perl-XML-NamespaceSupport perl-XML-LibXML perl-MIME-Lite perl-MIME-Types
perl-MailTools perl-TimeDate uuid libuuid perl-Data-Dump perl-UUID make gcc perl-devel
libuuid-devel cpan
Debemos descargar el SDK de 64bit para SO Linux de:
https://my.vmware.com/group/vmware/details?downloadGroup=VS-PERL-SDK67&productId=742
Lo copiamos a la máquina de Centreon, con FileZilla o WinSCP podremos realizarlo sencillamente.

Tras copiarlo al CentOS, lo descomprimimos e instalamos el SDK:
tar xvzf VMware-vSphere-Perl-SDK-6.7.0-8156551.x86_64.tar.gz

cd vmware-vsphere-cli-distrib/
./vmware-install.pl
La instalación de SDK nos realizará una serie de cuestiones que podremos continuar con los valores
predeterminados. Seguimos con UUID, lo descargamos, lo compilamos y lo instalamos:
cd /usr/src
wget http://search.cpan.org/CPAN/authors/id/J/JN/JNH/UUID-0.04.tar.gz
tar -xzvf UUID-0.04.tar.gz -C /opt
cd /opt/UUID-0.04
perl Makefile.PL
make
make install
Instalamos también perl-Nagios-Plugin:
yum install nagios-plugins-perl -y
Seguimos con libwww-perl y módulos de Perl que necesitaremos:
cpan GAAS/libwww-perl-5.837.tar.gz
cpan Monitoring::Plugin
Utilizaremos el script ‘check_vmware_api’ de OP5, nos lo descargamos, lo hacemos ejecutable,

probamos a ejecutarlo con el parámetro -h para ver toda su excelente ayuda y lo movemos al directorio
donde guardamos los plugins:
wget https://raw.githubusercontent.com/op5/check_vmware_api/master/check_vmware_api.pl
chmod +x check_vmware_api.pl
./check_vmware_api.pl -h
mv check_vmware_api.pl /usr/lib/centreon/plugins/
7.2 Dando acceso
En cada host que queramos monitorizar, deberemos crear un usuario para permitir acceso al script y
que pueda obtener los valores que nos interesen.
En el Host Client, desde “Administrar” > “Seguridad y usuarios” > “Agregar usuario” podremos dar de
alta nuestro usuario.
Creamos un usuario modelo,
Y recordamos darle permisos de acceso, sobre el Host con botón derecho > “Permisos”.
Pulsamos en “Agregar usuario”,
Y seleccionamos el usuario recién creado y le asociamos al grupo ‘Solo lectura’, con ello será suficiente
para que pueda leer los parámetros requeridos.
Ahora, ya en Centreon debemos crear un fichero de autenticación, donde almacenaremos el usuario

que utilizaremos con el script. Yo le llamo ‘/usr/lib/centreon/plugins/check_vmware_api.auth’ y con el
siguiente formato indicamos los credenciales:
username=monitorizacion
password=contraseña
Podemos validar que todo es correcto haciendo una sencilla prueba desde la Shell del Centreon. Si
ejecutamos:
/usr/lib/centreon/plugins/check_vmware_api.pl -H DIRECCION_IP_HOST -f
/usr/lib/centreon/plugins/check_vmware_api.auth -l cpu -s usage
Veremos el uso de CPU del host. Como vemos el script se alimenta de distintos argumentos, el primero,
con -H le pasamos la dirección IP del host ESXi, con -f le pasamos el fichero de autenticación, con -l
indicamos el Comando y con -s el SubComando. Adicionalmente le podríamos poner -w de Warning y
-c para Critical, si los cumplimentamos con los valores 80 y 90, nos advertirá con un Warning cuando
la CPU use más del 80% y un Critico cuando supere el 90%.
Con este script como comentamos podemos monitorizar muchas cosas más, esta tabla nos valdrá a
modo resumen de lo que obtendremos con dicho script en cuanto monitorizar ESXi’s.
Comando SubComando Descripción

usage Uso de CPU en %
cpu
usagemhz Uso de CPU en Mhz
usage Memoria RAM en %
usagemb Memoria RAM en MB
swap Memoria Swap en MB
mem
overhead Memoria Overhead en MB
overall Memoria total en MB
memctl Memoria Balloning en MB
usage Trafico en KBps
receive Trafico Recibido en KBps
net
send Trafico Enviado en KBps
nic Estado de las NIC
aborted Comandos abortados
resets Resets
read Latencia de lectura en ms
io write Latencia de escritura en ms
kernel Latencia del kernel en ms
device Latencia del dispositivo en ms
queue Latencia de Queue en ms
vmfs NOMBRE_DS Muestra espacio utilizado del datastore VMFS en MB
con Estado de Conexión
health Salud del host
storagehealth Salud del almacenamiento
temperature Temperatura
runtime
sensor Estado de sensores
maintenance Conocer si está en modo mantenimiento
status Estado general del host
issues Estado de la configuración del host
service [nombre] Estado de los servicios del host
adapter Muestra los adaptadores de almacenamiento
storage lun Muestra las unidades lógicas
path Muestra los paths
uptime Uptime
device cd/dvd Lista MVs con dispositivos conectados
7.3 Definiendo el Comando
Para poder monitorizar los Servicios de CPU, Memoria… antes de nada, tenemos que trasladar a
Centreon qué ejecutar cuando queramos saber el resultado de dichos Servicios de monitorización.
Primeramente, definiremos un Comando basado en el script que hemos ejecutado antes, pero
tendremos que sustituir los valores fijos por variables y así podamos usar un solo Comando para
monitorizar todos los Servicios.
Bien, si vamos a “Configuration” > “Commands” > “Add…” crearemos lo siguiente:
$CENTREONPLUGINS$/check_vmware_api.pl -H $HOSTADDRESS$ -f
$CENTREONPLUGINS$/check_vmware_api.auth -l $ARG1$ -s $ARG2$ -w $ARG3$ -c $ARG4$
Cuando Centreon quiera ejecutar algún chequeo de los que queremos, ejecutará lo siguiente, hemos
sustituido con variables y argumentos los valores a rellenar manualmente.
• La variable $CENTREONPLUGINS$ es ‘/usr/lib/centreon/plugins/’

• La variable $HOSTADDRESS$ sería la dirección IP o nombre FQDN del servidor a monitorizar.
• ARG1 sería el primer argumento que le pasaremos, si recordamos es el ‘Comando’ que se indica
tras ‘-l’.
• ARG2 sería el segundo argumento que le pasaremos, si recordamos es el ‘SubComando’ que se
indica tras ‘-s’.
• ARG3 será el valor de Warning.
• ARG4 será el valor de Critical.
Pulsamos en “Describe arguments”,
Así que asociamos de una forma sencilla qué es cada Argumento, que luego cuando creemos los
servicios, lo agradeceremos. “Save”.
7.4 Definiendo los Hosts
Damos de alta en Centreon nuestro primer servidor, un host ESXi.
Desde “Configuration” > “Hosts” > “Add…” añadiremos nuestro primer host ESXi, completaremos al
menos los siguientes campos:
• Name: Nombre del servidor ESXi.
• Alias: Alias del servidor ESXi.
• IP Address / DNS: La dirección IP o nombre DNS del servidor ESXi.
• SNMP Community & Version: En este caso no sería necesario ya que ESXi no soporta SNMP.
• Template: Normalmente seleccionamos ‘generic-active-host-custom’
7.5 Definiendo los Servicios
Aquí ya por fin podremos crear los servicios de lo que queremos monitorizar, sea CPU, RAM, NICs
caídas, estado de los datastores… para ello, nos apoyaremos como hemos dicho en el comando que
acabamos de crear.
En “Configuration” > “Services” > “Add”, crearemos nuestro primer servicio. Rellenaremos al menos
los siguientes datos:
• Description: Nombre del servicio, en mi caso CPU, Memoria RAM, Memoria Swap…
• Linked with Hosts: Aquí añadiremos el host que hemos creado antes, nuestro servidor ESXi.
• Template: Seleccionamos ‘generic-active-service’.
• Check Command: Escogemos el Comando que hemos creado anteriormente.
• Argumentos: Deberemos rellenar todos los argumentos que nos pida el comando.
Tras realizar el primer Servicio, será más cómodo duplicar el recién creado y modificar de nuevo el
Nombre y los Argumentos. Y, claro, hacer tantos servicios como queramos.
Este sería un ejemplo con un resumen de los Servicios más interesantes.
7.6 Grabando la configuración
Bien, una vez hemos creado los Hosts y los Servicios que nos interese, debemos grabar la configuración,
un proceso que generará y exportará los archivos de configuración de Centreon.
Lo haremos desde “Configuration” > “Pollers” > “Export configuration”, indicamos donde hemos realizado
los cambios, en nuestro Poller Central, además indicamos que genere los ficheros de configuración,
arranque en modo debug, exporte los ficheros y reinicie el motor de monitorización. En el método
normalmente con ‘Reload’ nos será más que suficiente, pero si es la primera vez que lo hacemos,
deberemos pulsar ‘Restart’ para que nos reinicie e inicie los servicios.
7.7 Resultado
Desde “Monitoring” > “Services” podremos finalmente supervisar el estado de los Servicios que le
hemos añadido al host ESXi. De una manera rápida tenemos el primer servidor monitorizado.
Si queremos monitorizar servidores ESXi adicionales, ya lo haremos de manera inmediata,

simplemente, desde ‘Configuration’, clonando este host crearemos el resto, generamos tantos hosts
como necesitemos, le indicamos el nombre y dirección IP y listo, recordando crear el usuario local en
cada ESXi.
8. Monitorizando MVs de vSphere
Podemos seguir sacando jugo a este mismo script, con él podremos conocer las métricas que
proporciona vCenter y obtiene de las máquinas virtuales.
8.1 Dando acceso
En esta ocasión el script en vez de hacer las consultas a los hosts, es preferible hacerlas a través de
vCenter Server, ya que las MVs suelen balancearse y moverse entre los hosts ESXi.
Crearemos un usuario en nuestro entorno vCenter, desde vSphere Client > “Administración” > “Single
Sign On” > “Usuarios y grupos” > “Usuarios”, seleccionamos normalmente vsphere.local > “Agregar
Usuario”.
Creamos un usuario genérico y le establecemos una contraseña robusta, pulsamos en “Agregar”.
Vamos a darle permisos al usuario, en la vista de ‘Hosts & Clusters’ seleccionamos el ítem más alto, en
este caso nuestro propio vCenter, y en la pestaña “Permisos” pulsaremos en agregar.
Buscamos al usuario recién creado y le establecemos un rol, normalmente ‘Solo lectura’ será suficiente.
Y marcamos el tick de ‘Propagar a objetos secundarios’.
Una vez creado el usuario, generamos un archivo en Centreon de autenticación, donde almacenamos
los credenciales que usará el script para hacer consultas, en mi caso lo guardo en ‘/usr/lib/centreon/
plugins/check_vmware_api_vc.auth’ con el siguiente contenido:
username=monitorizacion@vsphere.local
password=contraseña
Para probar, tan sencillo como utilizar el mismo script (check_vmware_api.pl), con -D consultamos a
vCenter Server, con -N indicamos el nombre de la MV como se ve en el inventario, con -f le pasamos
el fichero de autenticación; con -l el Comando y con -s el SubComando. Muy similar que a la hora de
monitorizar los hosts ESXi; acordaros que podríamos meter -w para establecer el valor de Warning y
-c el Critical. En este ejemplo vemos el CPU Ready de una máquina virtual.
/usr/lib/centreon/plugins/check_vmware_api.pl -D DIRECCION_IP_VCENTER -N NOMBRE_MV -f

/usr/lib/centreon/plugins/check_vmware_api_vc.auth -l cpu -s ready
Comando SubComando Descripción

usage Uso de CPU en %
usagemhz Uso de CPU en Mhz
cpu
wait CPU Wait en ms
ready CPU Ready en ms
usage Memoria RAM en %
usagemb Memoria RAM en MB
swap Memoria Swap en MB
swapin Memoria Swap In en MB
mem swapout Memoria Swap Out en MB
overhead Memoria Overhead en MB
overall Memoria total en MB
memctl Memoria Balloning en MB
active Memoria Activa
usage Trafico en KBps
net receive Trafico Recibido en KBps
send Trafico Enviado en KBps
usage Uso del disco en MB/s
io read Lectura del disco en MB/s
write Escritura del disco en MB/s
con Estado de Conexión
state Estado de la MV (Encendida/apagada/suspendida)
runtime status Estado general de la MV
guest Estado del SO invitado
tools Estado de las VMware Tools
8.2 Definiendo el Comando
Necesitamos definir un nuevo Comando, ya que el anterior no nos valdrá, nosotros ahora queremos
consultar mediante vCenter y no mediante los hosts.
Vamos a “Configuration” > “Commands” > “Add…” crearemos el Comando con la siguiente línea de
comandos:
$CENTREONPLUGINS$/check_vmware_api.pl -D DIRECCION_IP_SERVIDOR_VCENTER -N $ARG1$ -f

$CENTREONPLUGINS$/check_vmware_api_vc.auth -l $ARG2$ -s $ARG3$ -w $ARG4$ -c $ARG5$
Y pulsamos en “Describe arguments” para identificar cada Argumento:
• ARG1 sería el primer argumento que le pasaremos, tras -N será el Nombre de la MV.
• ARG2 es el segundo argumento, siendo el ‘Comando’ que le pasamos con ‘-l’
• ARG3 será el ‘SubComando’ que se indica tras ‘-s’.
• ARG4 será el valor de Warning.
• ARG5 será el valor de Critical.
8.3 Definiendo los Servicios
Con el Comando ya definido, crearemos tantos Servicios queramos monitorizar de las distintas
Desde “Configuration” > “Services” > “Add”, crearemos los servicios. O si nos es más cómodos podemos
clonar de alguno ya existente, debemos indicar al menos:
• Description: Nombre del servicio monitorizado. Personalmente, cómo son métricas de virtualización
les suelo llamar ‘MV - …’
• Linked with Hosts: Aquí añadiremos normalmente la máquina monitorizada, para asociarle a ella
las métricas de la capa de virtualización.
• Template: Seleccionamos ‘generic-active-service-custom’.
• Check Command: Elegimos el Comando que acabamos de crear.
• Argumentos: Deberemos rellenar todos los argumentos que nos pida el comando.
8.4 Resultado
Como siempre, tras crear tantos servicios como queramos monitorizar de cada MV y tras grabar y
exportar la configuración en Centreon, ya podremos venir a visualizar los resultados de la monitorización.
Si vamos a “Monitoring” > “Services”, podremos ya buscar los servicios que acabamos de añadir y
visualizaremos su estado actual. Como vemos es una pasada la de métricas que podemos sacar de
cada MV.
9. Monitorizando vCSA
En esta sección del capítulo vamos a monitorizar el appliance virtual de VMware llamado vCenter
Server Appliance o vCSA, que como sabemos es la máquina que proporciona gestión y control de
nuestra plataforma virtual. Y depende del servicio que nos preste puede ser una máquina crítica y
necesaria de monitorizar.
A diferencia de hasta ahora, vCSA lo vamos a monitorizar mediante SNMP, ya que es una MV basada
en Linux. Aún que os recuerdo que el script que hemos visto hasta ahora también tiene una sección
específica para monitorizar DataCenters o incluso a nivel de Clúster, conociendo los recursos de CPU
totales, de Memoria… échale un vistazo a la ayuda:
/usr/lib/centreon/plugins/check_vmware_api.pl -h
Para habilitar SNMP en el vCSA, nos conectamos bien con un Putty por SSH o en consola local,
indicaremos la comunidad SNMP que utilicemos ejecutando:
Command> snmp.set --communities NOMBRE_COMUNIDAD

Command> snmp.enable
9.1 Monitorización base de vCSA
Lo primero de todo, vamos a dar de alta en Centreon la máquina vCSA, para poder enlazarla
posteriormente los Servicios que la van a monitorizar.
Desde “Configuration” > “Hosts” > “Add…” crearemos la máquina, donde:
• Name: Nombre del servidor vCSA.
• Alias: Alias del servidor vCSA.
• IP Address / DNS: La dirección IP o nombre DNS del servidor vCSA.
• SNMP Community & Version: Indicamos la misma comunidad que hemos configurado antes en
el vCSA y establecemos versión ‘2c’.
• Template: Seleccionamos ‘generic-active-host-custom’ y como al inicio instalamos los Plugin Pack

y descargamos las plantillas para SO Linux, añadimos también ‘OS-Linux-SNMP-custom’.
Si grabamos la configuración de Centreon, podremos verificar que al menos algunos de los Servicios
que heredamos de la plantilla Linux nos valdrán para conocer el estado de su CPU, red o Uptime.
9.2 Monitorizando sus discos
Si la plantilla base de Linux que le hemos aplicado al Host de vCSA no nos ha generado los discos,
podremos añadirlos fácilmente.
Desde “Configuration” > “Services” > “Add” añadimos el Servicio que monitorizará el disco ‘/’, lo
enlazamos al Host de vCSA y en ‘Template’ debemos indicar que use ‘OS-Linux-Disk-Generic-Name-
SNMP-custom’. En las macros con indicar el DISKNAME a ‘/’ nos bastará.
Por recordar, una MV vCSA 6.x dispone de los siguientes discos
Punto de montaje Descripción

/boot Boot
/tmp/mount Directorio temporal
SWAP Espacio Swap
/storage/core Core dumps
/storage/log Logs del sistema
/storage/db BD de vPostgres
/storage/dblog Logs de vPostgres
/storage/seat Donde se almacenan las estadísticas, eventos y tareas en vPostgres
/storage/netdump Volcados de red Netdump collector
/storage/autodeploy Repositorio de Auto Deploy
storage/invsvc Servicio de inventario bootstrap y configuración de tomcat
/dev/shm Memoria compartida
/storage/imagebuilder Repositorio de Image Builder
/storage/updatemgr Almacén para Update Manager
/storage/archive Archivado de vPostgres
9.3 Monitorizando Procesos
Si nos interesa conocer si vCSA dispone de los servicios necesarios corriendo, lo más sencillo será
validar que tenemos sus procesos activos, y si los procesos están activos, al menos aseguraremos
que está corriendo.
Podemos utilizar la siguiente tabla para monitorizar los procesos de nuestro vCSA:
Proceso Descripción
vmafdd Servicio VMware Authentication Framework
vmware-cm Servicio VMware Component Manager
vmware-eam Servicio VMware ESX Agent Manager
vmware-sts-idmd Servicio VMware Identity Management Service
vmware-cis-license Servicio VMware License Service
vpostgres Servicio VMware vPostgres
vmware-sca Servicio VMware Service Control Agent
vmware-vpxd Servicio VMware vCenter Server
vmware-vpxd-svcs Servicio VMware vCenter-Services
vmware-vsm Servicio VMware vService Manager
vsphere-ui Servicio VMware vSphere Client
vsphere-client Servicio VMware vSphere Web Client
Para monitorizar cada proceso que nos interese, tendremos que crear un Servicio asociado. Desde
“Configuration” > “Services” > “Add…” y tras rellenar el nombre del Servicio indicaremos que como
Comando de chequeo utilice ‘OS-Linux-SNMP-Process-Generic’, simplemente en las macros que nos
aparecerán cumplimentamos el campo PROCESSNAME con el nombre del proceso asociado.
9.4 Monitorizando caducidad del certificado
Si hemos cambiado los certificados que trae por defecto los servicios de vCSA por unos de confianza,
como buena práctica. Bueno será monitorizarlos para evitar que nos caduquen y tengamos problemas
en el entorno. Este script que utilizaremos también lo podremos utilizar para validar certificados de
otros sitios que dispongamos. Desde Centreon, nos descargamos el script, lo hacemos ejecutable y lo
copiamos al directorio de los plugins:
wget https://raw.githubusercontent.com/matteocorti/check_ssl_cert/master/check_ssl_cert
chmod +x check_ssl_cert
cp check_ssl_cert /usr/lib/centreon/plugins/
Añadimos el Comando que utilizaremos en los Servicios distintos que tengamos para monitorizar
distintos certificados. Indicamos el siguiente ‘Command Line’:
$CENTREONPLUGINS$/check_ssl_cert -H $ARG1$ -A -p $ARG2$ -w $ARG3$ -c $ARG4$
Pulsamos en ‘Describe arguments’ para definir los Argumentos.
Donde el ARG1 será la dirección IP o FQDN contra el que conectaremos. ARG2 es el puerto al que
conectarse. ARG3 son los días de preaviso que queremos para un aviso Warning y ARG4 para cuando
queden menos días y queramos tener un aviso Critical.
Una vez creado el Comando, lo que nos queda como siempre es definir los Servicios que monitorizarán
distintos certificados. En este ejemplo vamos a comprobar la validez del certificado de vSphere Web
Client, por tanto, al crear el Servicio, lo asociamos con el Comando recién creado y cumplimentamos
los argumentos. El primer argumento será la IP o nombre de nuestro vCSA, el segundo argumento
usaremos el puerto 9443 y obtendremos un aviso Warning cuando queden 30 días para que caduque
y si llegados los 15 días ya serán alertas Criticas.
9.5 Monitorizando Puertos
Y por finalizar, si queremos verificar que un puerto tcp está escuchando, lo podremos implementar en
Centreon en cuestión de segundos. Primero instalaremos este plugin de nagios:
yum install nagios-plugins-tcp -y
Tras ello, podremos como ya sabemos, crear el Comando que usaremos para ejecutar el script. Si en
la línea de comandos indicamos:
/usr/lib64/nagios/plugins/check_tcp -H $HOSTADDRESS$ -p $ARG1$
Podremos chequear cualquier puerto (-p) que nos interese.
Y finalmente creamos el Servicio asociado, por ejemplo, para verificar que el puerto de vSphere Web
Client está levantado. A la hora de crear el Servicio seleccionaremos el Comando creado en el paso
anterior y en el argumento simplemente pondremos el número de puerto a monitorizar.
9.6 Resultado
En este pantallazo podemos ver todos los Servicios que hemos ido creando para monitorizar el servidor
vCSA, recordar grabar y exportar la configuración. Con esto aseguraremos conocer en todo momento
qué sucede en nuestro appliance vCSA.
10. Monitorizando Snapshots
En este apartado, veremos cómo Centreon también nos puede ayudar a monitorizar la existencia de
snapshots en nuestra infraestructura virtual, de todos es sabido el peligro que tiene tener snapshots
o dejarlos durante largos periodos… bien generados por backups colgados que dejan snapshots a
medias o nosotros manualmente. ara combatir esto, automatizaremos un checkeo periódico con un
gran script.
Este script necesita que tengamos SSH habilitado en al menos un host ESXi, con ello chequearemos
la existencia de snapshots en sus datastores, no usaremos por tanto SNMP. El script, necesitará
validarse contra el host ESXi a la hora de ejecutarse, por lo que deberemos configurar acceso SSH
con claves públicas. Así el host ESXi confiará en el usuario que ejecuta el script desde la máquina de
Centreon y no preguntará por los credenciales.
Lo primero, será loguearnos en la shell de nuestro Centreon, ahí, nos logueamos con el usuario que
ejecuta los scripts en Centreon, el usuario es ‘centreon-engine’, así que nos logueamos, generamos
las claves para nuestro usuario y copiamos la clave pública al host ESXi; al ser la primera vez que nos
conectemos además confirmaremos con un ‘yes’ que confiamos en su firma.
su - centreon-engine
ssh-keygen -t rsa
scp /var/lib/centreon-engine/.ssh/id_rsa.pub root@DIRECCION_IP_ESXi:/etc/ssh/keys-root/
authorized_keys
Ahora tenemos que descargar el script de esta URL:
https://exchange.nagios.org/directory/Plugins/Operating-Systems/%2A-Virtual-Environments/
VMWare/Check-snapshots-age-and-number/details y lo copiamos con WinSCP o FileZilla a nuestra
máquina Centreon, lo hacemos ejecutable y lo movemos al directorio de los plugins de Centreon:
chmod +x check_VM_snapshots
mv check_VM_snapshots /usr/lib/centreon/plugins
Creamos el Comando en Centreon que vamos a utilizar para llamar a este script, indicamos la siguiente
línea de comandos:
$CENTREONPLUGINS$/check_VM_snapshots $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$
Pulsamos en “Describe arguments” e indicamos lo que significan; el ARG1 es el valor de Warning,

indicando el número de Snapshots que encuentre, el ARG2 para cuando queremos que el número de
snapshots encontrados nos alerte como Critical. Y el ARG3 son los días de antigüedad que permitimos
que tengan los snapshots.
Y ahora ya podremos crear un Servicio que asociaremos a un host ESXi (al que hayamos configurado
el fingerprint), seleccionamos el Comando creado en el paso anterior y acabamos cumplimentando
los argumentos. Donde en este ejemplo los snapshots que tengan más de 7 días me alertarán con
Warning si hay 1 o con Critical si hay 2 o más snapshots.
Tras grabar y exportar la configuración, si volvemos a la vista de Monitorización y buscamos el Servicio

Snapshots creado, podremos verificar qué nos encuentra.
11. Visualizando con Grafana
Si no nos es suficiente con las gráficas que nos da Centreon, podemos integrar nuestro Centreon
con Grafana, podremos exportar los resultados de nuestro Centreon a una máquina con Graphite y
visualizarlo con Grafana.
Centreon (entre otros) permite exportar los datos que recolecciona a formato Base de Datos de Series
Temporales (TSDB), pues gracias a ello, podremos almacenarlos en una Base de Datos de Graphite y
con Grafana presentar esos datos en preciosos Dashboards. Grafana es una plataforma Open Source
para crear nuestros propios cuadros de mando que permiten monitorizar nuestra infraestructura. Así que,
nuestro Centreon monitorizará nuestra plataforma como hasta ahora, pero además, redireccionaremos
las métricas que monitoriza a una BD remota, y Grafana podrá leer dicha información y así nosotros
crear los Dashboard que nos interese. Os recuerdo que con Grafana no sólo podemos ver este tipo de
información, que podemos explotar cualquier tipo de BD, ¿has pensado echarle un vistazo al ERP de
tu empresa y hacer Dashboards?
Ya habéis visto en el capítulo de ‘Monitorización de entornos vSphere’ de Jorge de la Cruz cómo

se instala Grafana, así que esa parte la omitiremos, pero sí indicaremos los pasos necesarios para
instalar Graphite, que bien puede ser instalado en la misma máquina de Grafana.
11.1 Instalación de Graphite
Para instalar Graphite, utilizaremos el repositorio EPEL, si no lo tienes instalado, deberás hacerlo, e
instalamos Graphite, además los paquetes necesarios:
yum install -y epel-release

yum install -y httpd graphite-web python-carbon perl
Inicializamos el interfaz de graphite y lo iniciamos ejecutando:
/usr/bin/graphite-manage syncdb --noinput

/usr/bin/graphite-build-index
/usr/bin/chown -R apache:apache /var/lib/graphite-web
systemctl start carbon-cache
Editamos el fichero de bienvenida ‘/etc/httpd/conf.d/welcome.conf’ y lo comentamos todo con

almohadillas (#). También, modificaremos el fichero ‘/etc/httpd/conf.d/graphite-web.conf’ para permitir
acceso desde cualquier IP:
##ServerName graphite-web
<IfModule mod_authz_core.c>
# Apache 2.4
Require all granted
</IfModule>
<IfModule !mod_authz_core.c>
# Apache 2.2
Order Deny,Allow
Allow from all
</IfModule>
Tenemos que añadir un par de reglas en el firewall para permitir el acceso externo al puerto de Graphite
(2003), así como al acceso web, reiniciamos el firewall para que recargue la configuración:
firewall-cmd --zone=public --permanent --add-service=http
firewall-cmd --zone=public --permanent --add-port=2003/tcp
firewall-cmd --reload
Recordar, para que los servicios arranquen al inicio con la máquina automáticamente, ejecutamos:
chkconfig httpd on
chkconfig carbon-cache on
Y reiniciamos el servicio httpd para recargar la configuración:
systemctl restart httpd
Finalmente, podemos probar a abrir Graphite para ver si tenemos acceso y hemos hecho todo bien,
veremos si el agente predeterminado si contiene algo de información, para ello no será más sencillo
que abrir un navegador contra la dirección IP de la máquina CentOS, en este caso tan fácil como http://
DIRECCION_IP_MAQUINA_GRAPHITE y ver que estamos obteniendo datos.
11.2 Redireccionar output de Centreon a Graphite
Ahora configuraremos que el Broker del Centreon escriba también los datos en Graphite, para ello
deberemos seguir los siguientes pasos en la máquina donde tenemos instalado Centreon. Instalamos
el plugin que necesitaremos en el Broker con:
yum install -y centreon-broker-graphite
Desde la consola de Centreon, vamos a “Configuration” > “Pollers” > “Broker configuration” > “central-
broker-master” > Pestaña “Output” > En el combo del Output escogemos ‘Graphite – Storage – Graphite’
> “Add”, completamos los siguientes campos de la siguiente manera:
• Name: Graphite
• DB host: DIRECCION_IP_MAQUINA_GRAPHITE
• DB port: 2003
• DB user:
• DB password:
• Metric naming: centreon.metric.$HOST$.$SERVICE$.$METRIC$
• Status naming: centreon.status.$HOST$.$SERVICE$
Con esto indicamos a donde exportará la información que recolecta nuestro Centreon y en qué formato
lo mandará a nuestro Graphite.
Recordaremos que, tras cualquier cambio de configuración en Centreon, debemos grabar, exportar
y recargar la configuración, para ello, por repasar, lo hacemos desde: “Configuration” > “Pollers” >
“Export configuration” > Marcamos “Generate Configuration files” & “Run monitoring engine debug” &
“Move Export Files” & en Method seleccionamos “Restart” y pulsamos en “Export”. Por verificar y estar
seguros, os recomiendo reiniciar estos dos servicios de Centreon desde su shell:
service cbd restart

service centengine restart
Si accedemos de nuevo a Graphite ya veremos cómo está almacenando las métricas que Centreon le
va pasando, según vaya monitorizando nuestro Centreon, esto comenzará a alimentarse.
11.3 Creando el conector de Grafana a Graphite
En Grafana, tendremos que crear un origen de datos, en este caso indicaremos a Grafana que pueda
leer los datos de una base de datos de tipo Graphite, desde “Configuration” > “Data Sources” > “Add
data source”.
En este conector indicamos un nombre, indicamos en ‘Type’ que sea ‘Graphite’, y en la URL debemos
indicar la dirección donde está instalado Graphite, si es la misma máquina que Grafana, con indicar
‘http://localhost’ bastará. Pulsamos sobre “Add”.
11.4 Creando el primer Dashboard
Y por fin podemos comenzar a dibujar y crear nuestros Dashboards con los datos de Centreon y
visualizar las métricas y estados de nuestra plataforma virtual. Pulsamos en “New Dashboard” y vamos
a añadir un Panel de tipo Graph de ejemplo para mostrar cómo manejarlo, sin código, sólo con el ratón.
Editamos el Panel recién añadido, “Edit”,
En la pestaña “Metrics” añadimos el Data Source que acabamos de crear llamado Centreon, y en las
Series bastará con ir añadiendo lo que queremos visualizar. Vamos seleccionando y añadiendo con
el ratón lo que nos interese, ‘Centreon’ > ‘Metric’ > ‘Nombre MV’ > ‘Servicio monitorizado’ > ‘métrica
obtenida’.
Y bueno, es cuestión de ir añadiendo series de ítems que queramos visualizar y luego en el resto de
menús definir el formato de lo que estamos visualizando, cambiar la vista a columnas, puntos o líneas
entre otros. A parte de Paneles de tipo Graph, podemos también mostrar únicamente los valores
obtenidos, adornarlos con un acelerómetro, utilizar paneles tipo quesito, etc… Verás que es un interfaz
super intuitivo y sencillo de usar, podrás en pocos minutos crear los Dashboards que te interesen y
visualizar los datos en tiempo real.
¡Verás que Dashboards chulos generas con los datos que monitorizamos desde Cetreon! Podrás crear
tantos Dashboards como necesites y posteriormente crear Play Lists para reproducirlos desde una TV
y que vaya cambiando de Dashboard cada X tiempo. Recordar, por último, que podremos exportar en
PDF los Dashboards y enviarlos programados por correo electrónico de forma totalmente automática.
12. Visualizando con NagVis
Vamos a integrar en nuestro Centreon una capa de visualización de mapas o dibujos interactivos, no
es más que llevar los ítems monitorizados a dibujos vivos totalmente customizados, sean dibujos de
esquemas lógicos, de fotos del CPD, de tráficos SAN, de nuestras máquinas virtuales… de lo que nos
dé la imaginación.
12.1 Instalación requisitos previos
Bajamos a la shell de nuestro Centreon, debemos actualizar gcc a la versión 4.7 si es que no lo
tenemos ya, además de añadir y actualizar variables:
sudo wget http://people.centos.org/tru/devtools-1.1/devtools-1.1.repo -P /etc/yum.repos.d
sh -c ‘echo “enabled=1” >> /etc/yum.repos.d/devtools-1.1.repo’
yum install devtoolset-1.1
scl enable devtoolset-1.1 bash
gcc --version
export CC=/opt/centos/devtoolset-1.1/root/usr/bin/gcc
export CPP=/opt/centos/devtoolset-1.1/root/usr/bin/cpp
export CXX=/opt/centos/devtoolset-1.1/root/usr/bin/c++
Y añadimos en ‘~/.bash_profile’:
export PATH=/opt/centos/devtoolset-1.1/root/usr/bin/:$PATH
Instalaremos MK Livestatus para acceder en tiempo real al estado de los objetos de nuestro Centreon,
será un requisito de NagVis para obtener la información y pintarla al momento:
yum install gcc-c++

cd /tmp/
wget ‘http://www.mathias-kettner.de/download/mk-livestatus-1.2.8.tar.gz’
tar xzf mk-livestatus-1.2.8.tar.gz
cd mk-livestatus-1.2.8
./configure && make
mkdir /usr/lib64/centreon-engine/bin
cp /tmp/mk-livestatus-1.2.8/src/livestatus.o /usr/lib64/centreon-engine/bin/
12.2 Configuración en Centreon
Desde de Centreon, vamos a “Configuration” > “Pollers” > “Engine configuration”, pestaña “Data”,
agregamos un nuevo módulo pulsando en “+ Add a new entry” y añadimos:
/usr/lib64/centreon-engine/bin/livestatus.o /var/lib/centreon-engine/rw/live
Grabamos y exportamos la configuración de Centreon tras modificar esta configuración, reiniciando los
servicios y recargando la configuración, como ya sabemos.
12.3 Instalar Backend NagVis
Comenzamos por fin con la instalación del backend de NagVis en nuestro appliance de Centreon…
comenzamos con los pasos necesarios para descargarlo e instalarlo:
cd /tmp/
wget http://www.nagvis.org/share/nagvis-1.9.11.tar.gz
tar zxfv nagvis-1.9.11.tar.gz
cd nagvis-1.9.11
./install.sh
Arranca el asistente de instalación de NagVis, deberemos responder correctamente las preguntas que
nos haga:
Do you want to proceed? [y]: y

...
Please enter the path to the nagios base directory [/usr/local/nagios]: /usr/lib/centreon
...
Please enter the path to NagVis base [/usr/local/nagvis]: /usr/lib/nagvis
...
Do you want to use backend mklivestatus? [y]: y
..
Do you want to use backend ndo2db? [n]: n
...
Do you want to use backend ido2db? [n]: n
...
Please enter your MKLivestatus socket: unix:/var/lib/centreon-engine/rw/live
...
Please enter the web path to NagVis [/nagvis]:/nagvis

...
Please enter the name of the web-server user [apache]: apache
...
Please enter the name of the web-server group [apache]: apache
...
Create Apache config file [y]:
...
+------------------------------ -------------------------+
| Summary |
+--------------------------------------------------------+
| NagVis home will be: /usr/lib/nagvis |
| Owner of NagVis files will be: apache |
| Group of NagVis files will be: apache |
| Path to Apache config dir is: /etc/httpd/conf.d |
| Apache config will be created: yes |
| |
| Installation mode: install |
| |
| Do you really want to continue? [y]: y |
...
Y tras finalizar ya nos indicará que ha finalizado de una manera satisfactoria. Si necesitamos modificar
algo, el fichero de configuración será: ‘/usr/lib/nagvis/etc/nagvis.ini.php’. Reiniciamos apache para que
recargue la configuración:
/etc/init.d/httpd restart
Y ya podremos entrar a NagVis. Probamos a acceder vía web a mediante la URL: http://SERVIDOR_
CENTREON/nagvis. Por defecto tendremos el usuario admin con la contraseña admin.
12.4 Creando un mapa vivo del Entorno Virtual
Tras acceder a NagVis, ya podremos crear nuestro primer mapa, pero, antes de nada, tenemos que
dibujar la imagen que queremos animar, usaremos Visio, Photoshop… Por poner esta imagen de
ejemplo, donde tenemos nuestras MVs y hosts de una empresa ficticia. Tenemos que subir la imagen
de fondo que vamos a usar con el mapa. Desde NagVis, vamos a “Option” > “Manage Backgrounds”
y subimos el fichero jpeg.
Para crear un mapa, será tan sencillo como ir a “Options” > “Manage Maps” > “Create Map”, ponerle un
nombre y asociarle la imagen de fondo que usará. Creará un mapa totalmente vacío al que le iremos
añadiendo iconos, líneas u objetos especiales que leerá de los Servicios monitorizados en Centreon.
¡Comenzamos a animar el mapa! Algo muy sencillo, poner iconos de estados, para ello, desde “Edit
Map” > “Add Icon” > “Service” los iremos añadiendo. El cursor del ratón nos cambiará y se nos pondrá
una cruz, deberemos pulsar en la zona del dibujo donde queramos añadirlo.
Y nos saltará una ventana emergente de qué queremos añadir, en este ejemplo, estoy añadiendo el
Servicio monitorizado llamado CPU del host ESXi, por tanto, lo buscamos en los combos y lo añadimos,
grabamos con “Save”. Y ya tendremos nuestro primer objeto añadido. Vemos que el mapa está en
Modo Edición, por lo que podremos seguir añadiendo o modificando objetos tranquilamente, lo más
rápido para seguir y crear objetos similares, será clonarlos y colocarlos donde los queramos de nuevo,
tras ello lo modificaremos e indicaremos a qué otro Servicio corresponde este nuevo objeto.
Tras un rato de trabajo tendremos nuestro primer mapa listo, en este caso vemos que he añadido 2
hosts de ESXi y 4 máquinas virtuales de la monitorización de Centreon, donde veremos de un vistazo
su estado, o si el rendimiento se ve afectado, con este tipo de dibujos podemos orientarnos. Al pasar
el ratón sobre cada Objeto añadido veremos el estado del resumen de dicho servicio monitorizado.
Ya sólo nos queda crear pools de imágenes que cambien cada X segundos y poner una TV en el
despacho para demostrar lo bien que tenemos controlado el entorno.
Capítulo 12
VDI con Horizon View
Ricard Ibáñez
Capítulo 12 - VDI con Horizon View Ricard Ibáñez
1. Introducción
Este capítulo, está dedicado a la plataforma de virtualización de escritorios VMware Horizon y no

lo plantearemos de una manera tradicional, describiendo cada componente y función. Intentaremos
realizar un planteamiento más propio de proyecto de implantación en una empresa, consiguiendo una
aproximación a las dudas y procedimientos que seguiríamos en un despliegue de esta tecnología.
El tema del capítulo lo estructuraremos en varios apartados según las necesidades más comunes,
planteadas en un despliegue de Horizon. Estas decisiones no tienen por qué llevarse al 100% de las
empresas donde se plantea una infraestructura de escritorios virtuales, pero intentaremos plantear
situaciones para poder ver la gran cantidad de posibilidades que nos ofrece VMware con Horizon.
2. Descripción del proyecto
Como en la mayoría de los proyectos tenemos que realizarnos varias preguntas y resolverlas antes de
empezar cualquier fase de la implantación.
2.1 Necesidades
Una de las principales necesidades, es mantener un elevado número de equipos disponibles, para los
usuarios que trabajan por turnos, es decir, el mismo equipo que por la mañana está usando un usuario,
por la tarde deberá usarlo otro. Además, hay que evitar que un equipo esté vinculado a un usuario
concreto, para facilitar la movilidad de posición en caso de trabajar por proyectos.
Otra necesidad, es que los responsables de departamentos dispongan de un equipo fijo, con el que
tengan la garantía de que los datos siempre estará disponibles y solo tendrás acceso ellos. También
tendrán aplicaciones distintas a los equipos de usuarios mencionados anteriormente.
Algo que se valora es que el equipo de sistemas tenga la capacidad de gestionar sus equipos con total
libertad a la hora de instalar o configurar aplicaciones, además de poder ampliar las capacidades del
equipo en caso necesario.
Toda esta infraestructura deberá tener alta disponibilidad en un solo centro de datos, para garantizar
el acceso y los datos de todos los usuarios.
2.2 Propuestas
2.2.1 Infraestructura
La principal propuesta es montar una infraestructura redundada a nivel de acceso a los escritorios, lo
cual nos llevará a disponer de dos Connection Servers para balancear las conexiones y en caso de
caída de uno de los dos, disponer de un servidor activo para que los usuarios sigan trabajando.
Un requisito a la hora de montar escritorios Linked Clone es el Composer, el cual, almacenará la base
de datos de relaciones de clones de escritorios virtuales y la VM Base. Además, esta base de datos la
usaremos también para almacenar los Eventos de la plataforma Horizon.
2.2.2 Escritorios trabajadores

Para cumplir con las necesidades se plantea un sistema de escritorios virtuales con Instant Clone, los
cuales facilitan un rápido despliegue y un reaprovechamiento de los recursos en el sistema de turnos
de los trabajadores.
2.2.3 Escritorios responsables

Los escritorios virtuales de responsables se implementarán con el sistema Linked Clone, el cual permite
mantener equipos asignados de manera individual para cada usuario con su espacio de almacenamiento
directo en el escritorio virtual, todo esto sin perder la facilidad de despliegue y actualizaciones.
2.2.4 Escritorios IT
Los escritorios virtuales que requieren mayor flexibilidad serán los del departamento de sistemas, por
lo que crearemos escritorios virtuales clonadas y sin gestión de actualizaciones centralizadas, por lo
que cada escritorio será independiente.
2.2.5 Despliegue de aplicaciones

Para poder facilitar el despliegue de aplicaciones según las necesidades, tendremos varias opciones.
Algunas aplicaciones las instalaremos sobre la plantilla que usaremos para generar escritorios, por lo
que cualquier actualización requerirá el despliegue de la plantilla de nuevo.
Otras las facilitaremos mediante un servidor RDS para centralizar su aprovisionamiento y actualizaciones.
Por último, usaremos el sistema App Volumes para asignar aplicaciones a los escritorios de manera
instantánea, consiguiendo una gran flexibilidad a la hora de desplegar aplicaciones.
2.2.6 Gestión de perfiles

Para controlar los perfiles de todos los usuarios, usaremos User Environment Manager (UEM), el cual
nos permitirá guardar las configuraciones de ciertas aplicaciones para que el usuario las mantenga
independientemente del escritorio donde se ejecuta. Además, podremos substituir algunas de las
configuraciones típicas de Windows GPO por configuraciones en UEM.
3. Infraestructura
La infraestructura necesaria para poner en marcha Horizon es muy básica, basta con implementar un
solo servidor llamado Connection Server y ya podemos generar escritorios virtuales y conectarnos con
el Horizon Client o desde la propia web con HTML5.
Si bien, es muy sencillo implementarlo, vamos a complicar un poco el diseño para tener en cuenta
factores de redundancia de los Connection Server, así como aprovechar características que nos
beneficiaran a la hora de aprovisionar escritorios.
Algo muy importante que tenemos que revisar es la matriz de compatibilidad de VMware, la cual nos
detallará si nuestra plataforma vSphere es compatible a nivel de versiones con la infraestructura de
Horizon que vamos a implementar y sobre todo que versiones de MS SQL Server están soportadas
para cada versión.
Docu VMware - VMware Product Interoperability Matrices

https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#interop&260=
3.1 Diseño
Lo primero que veremos es un esquema del diseño de los servidores y servicios para redundar nuestra
plataforma. En este diseño veremos servicios que se explicarán con más detalle en las siguientes
páginas.
3.1.1 Connection Servers

Este servicio actuará como bróker de las conexiones entre clientes y escritorios virtuales, controlando
la autenticación mediante los usuarios de Active Directory.
Como podemos ver en el diseño, este servicio es el centro de la infraestructura, por lo que como
mínimo, en una implementación como la que queremos llevar a cabo, instalaremos dos servidores.
El proceso de instalación del primer Connection Server y del segundo es distinta, pues el segundo se
instalará como réplica del primero. El sistema que utiliza Horizon para replicar configuraciones entre dos
o más Connection Server es una base de datos LDAP, similar a la que usamos para Active Directory,
por lo que cualquier cambio realizado sobre un Connection Server es inmediatamente enviado a los
otros Connection Server. Una vez desplegados los servidores, tendrán el mismo peso a la hora de
gestionar conexiones, todo dependerá del balanceo de conexiones.
Este balance de conexiones es muy importante para dar siempre acceso a nuestros usuario y un método
muy simple es usar el propio balanceador de Windows Server (NLB), que viene incorporado como una
característica del SO, el problema es que tendremos poco control sobre el uso y disponibilidad de los
Connection Servers en cuanto a monitoreo del tráfico se refiere, por lo que es recomendable usar una
balanceador externo con mejores características.
Docu www.cenabit.com - Balancear las conexiones en Horizon View

https://www.cenabit.com/2018/06/balancear-las-conexiones-en-horizon-view/
Instalación del primer Connection Server
El proceso de instalación es muy sencillo y tan solo debemos respetar los requisitos mínimos en
hardware y versiones.
Docu VMware - Requisitos del servidor de conexión de Horizon

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-E1B927CD-20A1-
47B5-B613-BB9F1A4B58CB.html
Al ser el primer servidor Connection Server que instalamos, debemos selecciona la opción Servidor
estándar de Horizon 7, también marcaremos la opción de HTML Access, de este modo conseguimos
que el servidor acepte estas peticiones y luego ya controlaremos el acceso de los clientes mediante la
configuración en el Pool.
Introducimos una clave de recuperación para poder restaurar el Connection Server de una copia de
seguridad automática.
El Connection Server utiliza unos puertos concretos para comunicarse con los Horizon Client, vCenter
y demás elementos de la infraestructura. Es ideal que sea el propio instalador quien se encargue de
abrir esos puertos sobre el Firewall de Windows para no tener que realizar configuraciones manuales.
Por último, especificaremos el usuario o grupo Administradores de Horizon. Esta configuración la

podremos editar más adelante dentro del portal de administrador de Horizon.
Instalación del segundo Connection Server
La instalación del segundo Connection Server difiere muy poco del proceso realizado sobre el primer
servidor.
La ventana más significativa es en el momento de elegir el tipo de instancia de servidor, que

seleccionaremos Horizon 7 Replica Server y también con la opción de HTML Access.
Como es lógico deberemos establecer cuál es el Connection Server del que haremos réplica, por lo
que introducimos, preferiblemente, el FQDN de nuestro primer servidor.
3.1.2 Composer Server

El servicio de Composer no es un elemento necesario dentro del uso de Horizon, es decir, podemos
trabajar con una plataforma de Horizon sin este componente, pero esto impedirá usar la tecnología de
Linked Clone.
La tecnología que encontramos detrás de Linked Clones, nos permite reducir considerablemente el
espacio ocupado por cada escritorio virtual comparado con las clonaciones completas de VMs y reduce
mucho el tiempo de aprovisionamiento.
Además, nos dará mucha flexibilidad para actualizar todos los escritorios con poco esfuerzo, Windows
Update, actualizar aplicaciones o incluso cambiar de SO.
Instalación Composer Server
Antes de empezar a instalar el servicio, debemos saber que este servicio requiere de una base de
datos SQL y en la versión que está escrita este libro Horizon 7.7, solo tenemos disponibles, Oralce 12C
Standard o MS SQL Server en varias de sus versiones.
Nota. Debéis comprobar esta matriz de compatibilidad antes de poner en marcha el servicio de
Composer, así garantizamos el soporte por parte de VMware.
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php#db&260=3002
Será necesario tener la consola de SQL Management para acceder a la instancia y crear la base de
datos para el servicio de Composer.
Como podéis observar en la imagen debemos crear una base de datos de Composer y otra, que
usaremos más adelante para los eventos de Horizon.
Ahora en el mismo servidor donde instalaremos el servicio Composer, debemos crear un conector
ODBC a nivel de Sistema, para usarlo en la instalación del servicio.
Con los pasos previos finalizados, podemos empezar a instalar nuestro servicio de Composer.
Ahora configuraremos el conector que hemos creado anteriormente para que nuestro servicio de
Composer pueda conectarse a la base de datos.
Confirmaremos el puerto de comunicación y si no tenemos ningún certificado instalado, se generará un

certificado autofirmado para la comunicación entre los Connection Server y el Composer.
3.2 Configuración
Docu VMware - Iniciar sesión en Horizon Administrator

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-55BDE139-3E49-
4C8C-B6D6-D9840BF785DA.html
Antes de empezar a pensar en la creación de Pools de escritorios virtuales, debemos configurar nuestra
plataforma de Horizon View.
Por ello, lo primero que vamos a hacer es acceder al portal de administración y esto lo conseguimos
entrando por https a nuestro servidor con /admin. Por ejemplo, https://Viewcon01.librovmware.com/
admin o si accedemos desde el propio servidor https://localhost/admin.
Como es de esperar, recibiremos un error de certificado porque todavía estamos operando con
certificados autofirmados que no son reconocidos por los equipos como certificados válidos.
3.2.1 Licencia
Docu VMware - Instalar la clave de licencia del producto

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-822318BC-132A-
463C-904C-6E4F8DBF60DB.html
Debemos introducir la licencia adquirida que podemos sacar de nuestra página de https://my.vmware.
com.
Una vez cargada se habilitarán las opciones vinculadas a nuestra licencia.
3.2.2 Grupo administradores de Horizon
Docu VMware - Funciones y privilegios predefinidos

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-administration/GUID-CA6A24E5-
B7C6-4E72-96B8-69B70563DDFE.html
En el proceso de instalación hemos definido un usuario como administrador y es el momento que

ampliemos el número de usuario administradores de View o añadamos un grupo pensado para tal fin.
Es importante saber que Horizon, permite establecer distintos roles sobre la plataforma en función
del acceso necesario para cada tipo de usuario. En organizaciones pequeñas donde existen pocos
administradores, es ideal tener acceso total, pero podemos establecer roles de solo lectura o de gestión
de Pools.
3.2.3 Permitir Pools de Windows Server
Docu VMware - Configuración global de las sesiones cliente

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-administration/GUID-897724CA-
CFCD-4030-8597-CC57EAB25D68.html
Veremos más adelante que podemos generar Pools con Windows versión cliente o servidor, pero si
nos lanzamos rápidamente a crear un Pool con Windows Server en Horizon View, no conseguiremos
encontrar nuestra VM Base para aprovisionar escritorios virtuales. Esto es debido a que por defecto
está deshabilitado y podemos activarlo desde la Configuración Global.
3.2.4 Base de datos de eventos
Docu VMware - Configurar la base de datos de eventos

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-E04FDAC2-AD7B-
4B09-B6E0-4A541646869B.html
Como vimos en el proceso de la configuración de SQL Server, creamos una base de datos llamada
VIEW-Event. Este es el momento donde conectaremos nuestro Horizon, con esta base de datos, para
poder almacenar los eventos generados y diagnosticar y controlar nuestra infraestructura.
Esta configuración es recomendable, pero no imperativa, es decir, si perdemos comunicación con

nuestra base de datos, la plataforma seguirá trabajando con normalidad.
Una cuestión muy importante es que no podemos usar usuarios con Integración de Autenticación de
Windows, sino que debemos usar usuario locale del SQL.
También debemos asegurarnos de abrir el puerto 1433, en el servidor SQL, o el que nosotros queramos
usar para la comunicación de los Connection Server contra esta base de datos.
3.2.5 Conectar con vCenter
Docu VMware - Agregar instancias de vCenter Server a Horizon 7

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-F8210848-BBF9-
4943-BCD8-75E7F5AEFEE8.html
Tenemos la infraestructura de Horizon instalada, pero falta una parte fundamental para poder usarla y
es una plataforma vSphere donde poder generar los escritorios virtuales.
Antes de añadir un vCenter, debemos preparar nuestro vSphere para poder configurarlo adecuadamente.
Lo más habitual es encontrar instalaciones realizadas con el usuario Administrator, tanto de vSphere
como de Active Directory, pero no es la mejor solución.
Debemos prestar atención a los requerimientos de nuestro entorno para conectar la plataforma Horizon
con vCenter.
Docu VMware - Privilegios necesarios para el usuario de vCenter Server

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-A878F876-B359-
42FC-9124-A1E34BFB3319.html
Si no queremos complicar la gestión de los permisos entre las dos plataformas y vamos a usar Control
Total de nuestro vCenter, lo que, si debemos hacer, como buena práctica, es crear un usuario dedicado
a Horizon. La razón es muy simple, de repente, vemos multitud de migraciones de VMs en nuestro
vCenter y si el causante es la infraestructura de Horizon, podremos reconocer esas migraciones por el
usuario que las ejecuta.
Para añadir el vCenter a nuestro Horizon usaremos el FQDN, ya que una vez creada la instancia
de vCenter en nuestra plataforma no se puede modificar. Si que podremos modificar el usuario de
conexión y lo valores máximos de operaciones.
En la misma creación de la instancia de vCenter podremos añadir la configuración de nuestro servidor

Composer, si es que nuestra infraestructura lo usa.
Por último, añadiremos el dominio de Active Directory sobre el que operará nuestro Composer, para
poder generar y eliminar equipos. Es muy importante que el usuario que conectamos tenga esos
permisos sobre nuestro Active Directory.
Docu VMware - Create a User Account for View Composer AD Operations

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-3446495C-FEC8-
425C-AFF8-A6CAABA5E973.html
3.2.6 Añadir dominio para Instant Clone
Docu VMware - Agregar un administrador de dominio de clones instantáneos

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-5E513495-450B-
4C2E-A353-A2B45071BDC7.html
Como tenemos previsto usar nuestra infraestructura con tecnología Instant Clone, es el momento de
configurar un usuario del dominio para poder operar con nuestro Active Directory, del mismo modo que
pasa con el servicio de Composer.
Es importante revisar que permisos requerirá este usuario para operar con nuestro Active Directory.
Docu VMware - Crear una cuenta de usuario para operaciones de clones instantáneos
https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-installation/GUID-E91881F4-F8C0-
48A5-A1A4-61577E287E29.html
3.2.7 Instalar certificado

Hasta ahora toda la plataforma trabaja con certificados autofirmados por cada uno de los servidores
que hemos instalado. Sin tener tan en cuenta los certificados internos de comunicación como vCenter,
Composer, etc… Sí que es importante establecer un certificado de acceso para los usuarios.
Si estamos pensando en una infraestructura de producción, no deberíamos dejar el acceso a los

Connection Server mediante los nombres de las VMs, por lo que deberíamos establecer un nombre
para el acceso, por ejemplo, vdi.librovmware.com, sobre este nombre podremos adquirir un certificado
de una entidad emisora para validar las conexione SSL sin el molesto error de certificado y garantizando
la integridad de la comunicación. También podemos usar una CA propia para poder usar nombres
internos, ya que las entidades certificadoras públicas, solo emiten certificados a dominios públicos.
Para poder generar una solicitud de certificado y enviarlo a nuestra entidad certificadora favorita,
debemos seguir los pasos que nos indica VMware en esta KB.
Docu VMware - Using Microsoft Certreq to generate signed SSL certificates in VMware Horizon
View
https://kb.vmware.com/s/article/2032400
Este proceso, solo se realizará sobre uno de los Connection Server y una vez lo tengamos instalado,
lo exportaremos con Clave Privada y lo instalaremos en el resto de Connection Servers, renombrando

el certificado autofirmado.
Docu www.cenabit.com - Instalación certificado Wildcard en Horizon View

https://www.cenabit.com/2016/03/instalacion-certificado-wildcard-en-horizon-view/
3.3 Conexiones
Docu VMware - Network Ports in VMware Horizon 7

https://techzone.vmware.com/resource/network-ports-vmware-horizon-7
En todo el diseño no hemos hablado de las necesidades de redes, como podemos suponer, cuando
hablamos de distintos productos conectados entre sí, sobre una misma red para dar lugar a una
infraestructura, es muy importante saber que protocolos y puertos necesitan para comunicarse.
Para no repasar toda la documentación de red de Horizon, vamos a comentar lo dos aspectos más
importantes a nivel de conexión, que son de qué manera daremos acceso a nuestros clientes sobre los
escritorios, con conexión a través de túnel o no.
Docu VMware - Configurar el túnel seguro y la puerta de enlace segura PCoIP

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-administration/GUID-7FB5BEBA-
2C20-47B9-94A9-A19C70D8BB66.html
Docu VMware - Configurar la puerta de enlace segura Blast

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-administration/GUID-C075A0DB-
0F59-4CD9-A329-CAF49E93E8DD.html
3.3.1 Conexión tunelizada

Cuando hablamos de conexión tunelizada, nos referimos a la centralización del canal de conexión
entre nuestros Horizon Client y los escritorios virtuales, pasando en todo momento por los servidores
Connection Server.
Esta configuración permite evitar la visibilidad de la red de clientes con la red de escritorios virtuales,
ya que todo pasa por la red de los Connection Server.
Como podemos observar en el diagrama, al controlar todo el acceso a los escritorios a través de los
servidores, cuando uno de esto servidores se apaga, todas las conexiones que gestiona se detienen,
teniendo como resultado la desconexión de escritorios virtuales, por lo que los usuarios deberán volver
a lanzar la conexión para realizar el túnel por otro Connection Server que esté disponible.
Además, para evitar problemas de certificados, deberemos establecer la URL en la configuración de
cada uno de nuestro Connection Servers para que respondan correctamente a las peticiones de los
usuarios.
3.3.2 Conexión no tunelizada

A diferencia del anterior método de conexión de nuestro Horizon Clients, cuando consideramos una
conexión no tunelizada, lo que debemos hacer es permitir el acceso desde los Clientes, tanto a los
servidores, como a los escritorios de manera directa.
Este diseño, requiere de los Connection Server solo en el momento de establecer la conexión entre
cliente y escritorio virtual, una vez esta comunicación se ha establecido, el Connection Server ya no
realizar ninguna operación más, a nivel de conexión.
Por tanto, en el caso de caída de un Connection Server, ningún usuario se verá afectado, si ya está
establecida la conexión. Este escenario, como deducimos es mucho más robusto a nivel de fallos, pero
más “inseguro” a nivel de conexiones.
Para configurar este escenario, lo que debemos hacer es desactivar los túneles de los Connection
Servers.
En el caso del protocolo Blast hay que tener en cuenta que si usamos HTML y no tunelizamos las
conexiones, cuando accedamos, nos dará un error de conexión el propio escritorio virtual, ya que
estamos accediendo directamente a una VM de manera directa mediante IP, lo cual no tiene un
certificado válido.
Para evitar este problema, existe la opción de solo tunelizar el protocolo Blast cuando la conexión sea
sobre HTML, consiguiendo mayor flexibilidad de acceso (HTML y Horizon Client) sin problemas de
certificados y conexiones.
3.4 Consola de administración
Todavía no hemos generado escritorios virtuales, ni Pools, ni aplicaciones, pero aprovecharemos el

acceso a la consola de administración para dar un repaso a ciertos aspectos que deberemos tener en
cuenta.
3.4.1 Dashboard
Desde el Panel del portal de administración, podremos ver la salud de nuestra infraestructura, así
como el espacio libre y ocupado de los Datastores y el estado de los escritorios o sesiones publicadas.
3.4.2 Users and Groups

Como es de esperar deberemos poder asignar autorizaciones a los usuario o grupos para acceder a
determinado Pool de escritorios o aplicaciones y desde esta consola podremos controlar todas estas
asignaciones.
3.4.3 Desktop Pools

Esta ventana de administración nos permite crear los Pools de escritorios virtuales, además de ofrecernos
todos los datos relacionados con cada uno de los Pools e incluso poder editar las configuraciones del
Pool y también las asignaciones.
3.4.4 Application Pools

Podremos asignar aplicaciones RDS de una de las granjas generadas en otro de los apartados.
3.4.5 Thinapps
Esta consola permite aprovisionar las aplicaciones en modo ThinApp que están ubicadas en un
repositorio para que aparezcan en los escritorios de los usuarios.
3.4.6 Farms
Al igual que la creación de Pools, esta consola nos permitirá generar granjas RDS para luego usar la
asignación de aplicaciones o sesiones.
3.4.7 Machines
Sin duda la consola más visitada en la administración de Horizon View, nos mostrará toda la información
relativa a los escritorios virtuales generados. Estado, ubicación, usuario asignado, usuario conectado,
etc…
Desde esta consola podremos realizar tareas individuales sobre los escritorios virtuales como
reiniciarlo, restablecerlo, reconstruirlo o eliminarlo, también poner en modo mantenimiento o cambiar
la asignación de un usuario.
3.4.8 Persistent Disks

Más adelante veremos lo que son los Persistent Disk usados sobre Pools de Linked Clone, pero
podemos avanzar que la gestión y estado de estos discos lo podemos gestionar desde esta consola,
por ejemplo, desconectar un disco o conectarlo a otro escritorio.
3.4.9 Monitoring
No cabe duda de que función tiene esta consola dentro de la administración. Nos permite ver todos los
eventos generados por la plataforma, así como ver las sesiones en curso y poder interactuar con ellas,
como reiniciar la sesión, o enviar un mensaje al usuario.
3.4.10 Global Policies

Nos puede interesar por el tipo de escritorios virtuales que aprovisionaremos restringir a nivel de
infraestructura el acceso a los USB o la aceleración por Hardware del protocolo PCoIP y la redirección
multimedia. Esto lo podremos cambiar desde esta consola.
4. Imagen base con Windows
Una de las primeras elecciones, para poder planificar un despliegue de escritorios virtuales es, escoger
el SO que vamos a usar.
Con VMware Horizon podemos usar varios SO, como por ejemplo Windows Server o Windows Cliente,
además de crear escritorios Linux.
4.1 Windows Server o Windows cliente
La principal diferencia entre escoger un SO de Cliente o un SO de Servidor es el licenciamiento que

usaremos.
No solo vale contemplar las licencias de VMware Horizon para nuestro proyecto, también tenemos
que contemplar las de los escritorios virtuales que aprovisionaremos, por ello esta es la primera gran
elección que deberemos estudiar, probar y confirmar.
Las ventajas e inconvenientes residen es la usabilidad del usuario frente a su escritorio virtual y sobre
todo al sistema de licenciamiento.
En todo este capítulo, trabajaremos con plantillas Windows 10 Enterprise, pero la mayoría de los pasos
se pueden aplicar en Windows Server.
4.1.1 Windows Server

El licenciamiento, para poder usar Windows Server, es algo sencillo de entender. Podemos escoger
entre Windows Server Standard o Windows Server Datacenter, que a grandes rasgos la diferencia
reside en el número de VMs que se puede aprovisionar, a nivel de licenciamiento. La Standard permite
2 VMs por licencia y la Datacenter VMs ilimitadas.
Nota. Leer con detalle el sistema de licenciamiento de Windows Server para cubrir vuestras
necesidades correctamente y tomar la mejor decisión.
https://www.microsoft.com/es-es/cloud-platform/windows-server-pricing
Lo recomendable es trabajar con licencias Windows Server Datacenter, que cubren un número ilimitado
de VMs creadas en nuestro entorno VMware vSphere.
Esto no es todo lo que hay que tener en cuenta a la hora de trabajar con escritorios virtuales de
Windows Server, pues el contrato de Microsoft estipula que, si se requiere acceder a un escritorio
de manera remota sin ser un acceso de administración del servidor, requiere una licencia de Remote
Desktop Services CAL.
En definitiva, necesitamos tantas RDS CAL como usuarios vayan a conectarse sobre los escritorios
virtuales.
4.1.2 Windows cliente

El licenciamiento para Windows Cliente es mucho más complejo. Microsoft nos dice que, para acceder
a un escritorio virtual, se requiere una licencia de Virtual Desktop Access (VDA).
La manera de entender este licenciamiento es que debemos licenciar el cliente que accede a nuestros
escritorios virtuales y no los escritorios virtuales en sí mismos.
Si disponemos de equipos con Windows 7/8/8.1/10 o Windows Tablet ≤ 10,1 pulgadas, entonces lo
más adecuado es coger Software Assurance (SA) en estas licencias para cubrir las necesidades de
nuestro entorno VDI.
Si disponemos de equipos ThinClient, ZeroClient o cualquier otro tipo de dispositivo que no sea los
Windows mencionados anteriormente, entonces debemos adquirir licencias VDA, las cuales nos
permitirán conectar a nuestros escritorios virtuales.
Nota. Para realizar una buena planificación del licenciamiento, consulta los documentos de
Microsoft sobre licencias SA y VDA. Además, contacta con algún Partner de confianza para que te
asesore debidamente para evitar conflictos.
https://download.microsoft.com/download/2/d/1/2d14fe17-66c2-4d4c-af73-e122930b60f6/
windows-10-volume-licensing-guide.pdf
4.2 Versiones de Windows 10
Desde la salida al mercado de Windows 10, ya se confirmó un rumor y es que Microsoft no quería
seguir lanzando nuevos SO cada 2, 3 o 4 años. Este se ha traducido en 1 solo SO, el cual recibe cada
6 meses una gran actualización se todo el sistema.
Estas actualizaciones completas incorporan cambio en el funcionamiento del propio sistema operativo
por lo que es importante conocer las versiones y las funciones que implementan para decidir cuál es
la versión que queremos desplegar en nuestro entorno VDI.
Es cierto que cada una de estas actualizaciones dispone de un ciclo de vida limitado, por lo que
después de este ciclo de vida ya no dispondremos de parches de seguridad, los cuales se liberan
como es tradición una vez al mes.
Esto nos lleva a necesitar más que nunca una plataforma donde podamos pasar de versión de Windows
10 de una manera rápida y confiable todos nuestros escritorios, para no encontrarnos con problemas
de fragmentación.
4.2.1 Modern Apps y LTSB

Windows 10 incorpora, además de grandes cambios en el diseño y funcionalidad, un sistema de
aplicaciones modernas (ModernApps), las cuales pueden ser instaladas desde la tienda de Microsoft
Store. Estas aplicaciones modernas han comenzado a substituir las clásicas aplicaciones de Windows,
como la Calculadora, las Sticky Notes, el visor de Fotos o el nuevo navegador Edge, entre otras.
En entornos VDI donde los administradores queremos el máximo control de los escritorios, estas
aplicaciones suponen un problema de gestión, pues van embebidas en el propio SO y en muchas
situaciones no son necesarias para los usuarios.
Existe una versión de Windows 10 llamada Long Term Servicing Branch (LTSB). Esta versión, no
recibe las actualizaciones de SO cada 6 meses, por lo que tiene una vida de servicio mucho más larga
y tampoco recibe tantas actualizaciones mensuales. Windows 10 LTSB, no incorpora las ModernApps,
ni el navegador Edge, lo cual en entornos de VDI puede ser una versión a tener en cuenta, pero como
contra partida, nuevas funcionalidades que se implementan en las versiones de SO cada 6 meses
tampoco estarán disponibles.
Docu www.sysadmit.com - Windows: 10 LTSB ¿Qué es?

https://www.sysadmit.com/2017/01/windows-10-ltsb-que-es.html
4.3 Preparación imagen base
4.3.1 Hardware virtual

Los requisitos necesarios para usar Windows 10 son escasos, apenas 2GB de RAM y 20Gb de
disco, pero bien es cierto que con esas características mínimas nuestros usuarios tendrán grandes
dificultades para trabajar con fluidez.
Vamos a aprovisionar una VM con 2 vCPU, 4GB de RAM y 25GB de disco.
La configuración de la tarjeta de red debemos elegir el tipo de adaptador VMXNET 3, para mejorar la
gestión de la red, este tipo de adaptador lo podremos seleccionar en la creación de la VM.
Para la controladora SCSI lo ideal es usar el tipo VMware Paravirtual y mejorar la gestión de los
discos virtuales, pero para simplificar la instalación de Windows, lo mejor, es realizar el proceso de
configuración del tipo de controladora una vez instalado el SO y tengamos las VMware Tools instaladas,
por lo que instalaremos el SO con la configuración que viene por defecto, LSI Logic SAS.
Otra parte importante es mantener esta VM con el mínimo de Hardware necesario para funcionar, por
ejemplo, quitar el Floppy Disk o el DVD (después de haber instalado el SO)
Otra buena práctica, es que nuestra VM no opere en BIOS y lo haga en EFI, por lo que también
tendremos que modificarlo antes de nuestra instalación. Cambiar este valor una vez instalado Windows
10, impedirá que arranque el SO.
Por último, realizaremos una configuración sobre las Opciones Avanzadas de la VM para conseguir
que los dispositivos de red y disco no aparezcan en el Windows como dispositivos que se puedan
extraer, así evitamos problemas con los usuarios que trabajen sobre ellos. En el apartado de Opciones
de Máquina Virtual, Avanzado entramos en el menú Editar Configuración… y añadiremos una nueva
línea.
Name Value
devices.hotplug false
4.3.2 Instalación y actualizaciones

No vamos a indicar todo el proceso de instalación de Windows 10, pero es un proceso tan sencillo como
cargar nuestra ISO en un Volumen VMFS de nuestro vCenter y añadirlo a la VM para que arranque.
El primer paso una vez tenemos instalado Windows 10, será la de ejecutar Windows Update para
aplicar todos los parches pendientes y de esta manera asegurar que la plantilla que vamos a desplegar
está completamente actualizada.
Ahora daremos paso a todas aquellas aplicaciones que van a formar parte de nuestra plantilla. Estas
aplicaciones son aquellas que todos los usuarios de nuestro entorno VDI necesitan usar y no requieren
actualizaciones constantes, por ejemplo, 7zip, Java, VLC, Adobe Reader, Chrome, etc… Todas estas
aplicaciones deberán estar configurada para evitar actualizaciones automáticas, de esta manera
nosotros controlaremos el ciclo de actualizaciones.
4.3.3 Liberar espacio del disco

Como es lógico, el espacio en un entorno de VDI es un recurso muy preciado y tenemos que mantener
al mínimo la ocupación de nuestros escritorios virtuales, empezando por la plantilla.
Lo primero que haremos es una limpieza de todos los archivos descargados de Windows Update y
para ello necesitaremos lanzar un comando desde nuestra consola de PowerShell.
dism /online /cleanup-image /StartComponentCleanup
4.3.4 Eliminar Modern Apps

Ya hemos comentado que existe una versión de Windows 10 que no incorpora las Modern Apps,
Windows 10 LTSB, pero también perdemos algunas funcionalidades que se lanzan cada 6 mese, por
esto lo más acertado en el caso de usuarios que han de tener ciertas funcionalidades es eliminar todas
aquellas Modern Apps que no sean necesarias.
Para eliminar las Modern Apps lo podemos hacer mediante PowerShell y tendremos dos apartados
que controlar, los AppxPackage y los ProvisionedAppxPackage.
LISTAR APPXPACKAGE
Get-AppxPackage | ft
LISTAR APPXPROVISIONEDPACKAGE
Get-AppxProvisionedPackage -online | ft
ELIMINAR APPXPACKAGE
Remove-AppxPackage -package “nombre del paquete”
ELIMINAR APPXPROVISIONEDPACKAGE
Remove-AppxProvisionedPackage -PackageName “nombre del paquete” -Online
No es buena idea eliminar todas las Modern Apps sin prestar atención a lo que estamos haciendo,
porque muchas aplicaciones son ahora parte del uso normal del equipo, por ejemplo, la aplicación
Fotos, que es el nuevo visor de imágenes o la Calculadora. Si eliminamos estas dos Modern Apps, y
los usuarios necesitas estas funciones deberemos buscar aplicaciones alternativas que cumplan esa
función.
4.3.5 VMware OS Optimization Tool
Docu Vmware - Vmware OS Optimization Tool

https://labs.vmware.com/flings/vmware-os-optimization-tool
Antes de pensar en desplegar una plantilla es necesario e imprescindible aplicar la herramienta

VMware OS Optimization Tool (VOOT). Esta herramienta nos permite, ya sea con plantillas creadas o
hechas por nosotros, aplicar configuraciones a nuestro Windows 10 para desactivar servicios que no
son necesarios en un entorno de VDI.
Por ejemplo, desactivar servicios como Windows Update, BranchCache, Hyper-V, VSS, entre otros
muchos. También permite la desactivación de efectos visuales o eliminar Tareas Programadas de
Windows como el famoso Defrag Schedule.
El VOOT es una herramienta muy potente y necesaria, pero que hay que dedicarle tiempo a ver
todas las cosas que desactiva o elimina para ver si en nuestro entorno se adapta correctamente. Por
supuesto que es posible seleccionar solo aquellos aspectos que queramos desactivar, por ejemplo,
Windows Search, es un servicio que aumenta la carga en un VDI, pero muy útil para los usuarios para
buscar información en su Windows 10.
Existen muchas plantillas preestablecidas para optimizar nuestro Windows 10 o Windows Server, de
nosotros depende encontrar la que más se ajusta o crear una propia.
ANTES DE OPTIMIZAR
DESPUÉS DE OPTIMIZAR
4.3.6 Modificar el perfil de Windows
Docu ForensiT
https://www.forensit.com/support-downloads.html
Como último paso, me gusta modificar el perfil por defecto que tiene Windows almacenado, el cual
genera ciertos iconos en el escritorio, barra de tareas, así como establecer un fondo de pantalla y los
colores del tema de Windows 10.
Para que en la creación de un nuevo perfil en nuestro escritorio virtual sea lo más estándar y no
tengamos que retocarlo, lo mejor es modificar el perfil por defecto y que de esta manera todos los
usuarios al iniciar por primera vez les aparezca el mismo escritorio.
Para conseguir esto de manera sencilla, existe una herramienta llamada Defprof, la cual clona un perfil
de usuario que hayamos personalizado sobre el perfil por defecto de Windows.
Para poder realizar el proceso debemos arrancar nuestro Windows con un usuario cualquiera y
personalizar el escritorio, los iconos, fondo de pantalla y aspecto que consideremos.
Una vez terminado, accedemos con un usuario Administrador distinto al que hemos personalizado
y lanzamos el programa mediante la Línea de Comandos, indicando el perfil del usuario que hemos
personalizado.
El usuario que hemos personalizado, lo podemos eliminar ya que esa configuración se aplicará a todos
los nuevos usuarios creados en este Windows.
4.4 Agente de Horizon
Docu VMware - Opciones de configuración personalizadas de Horizon Agent

https://docs.vmware.com/es/VMware-Horizon-7/7.6/horizon-virtual-desktops/GUID-61090F90-
186F-4932-BB0F-06902F0908B5.html
La última parte y más importante para preparar la plantilla que usaremos en el despliegue de escritorios,
es la instalación del agente de Horizon.
Para que nuestra plataforma interactúe con los escritorios virtuales y nos permita acceder remotamente
mediante el Horizon Client o por HTML5, es imprescindible que esta, tenga instalados los componentes
del agente de Horizon que vamos a necesitar.
El proceso de instalación es muy sencillo, aplicamos el método Next, Next, Netx, pero nos detendremos
en la siguiente ventana, que es la que determinará que componentes añadiremos a nuestra plantilla.
Entre los componentes del agente de Horizon, encontramos los protocolos de conexión, como PCoIP o
VMware Blast que son de instalación obligatoria, pero también encontramos otros que podemos instalar
si realmente los necesitamos. Por ejemplo, la redirección USB, la virtualización de las impresoras,
redirección de SmartCard, redirección de webcam y audio, entre otras muchas opciones.
En este apartado me gustaría destacar las que tienen un impacto directo en nuestro uso sobre la
infraestructura de Horizon, que son:
• VMware Horizon Composer Agent: Este componente, permite usar la plantilla para desplegar
escritorios virtuales mediante la tecnología de Linked Clone.
• VMware Horizon Instant Clone Agent: Este componente permite usar la plantilla para desplegar
escritorios virtuales mediante la tecnología de Instant Clone.
• VMware Horizon 7 Persona Management: Este componente permite sincronizar el perfil del usuario
contra una ubicación remota, igual que los perfiles remotos de Windows, pero con mayores ventajas
en cuanto a la sincronización. Requiere de las plantillas ADMX para configurarlo mediante GPOs.
Cuando configuramos una plantilla para usarla en Instant Clone, no podemos activar los componentes
de Linked Clone y tampoco los de Persona Management, ya que son tecnologías incompatibles.
En cambio, si queremos usar la plantilla para Linked Clone, sí que podremos usar Persona Management,
pero no podremos activar el agente de Instant clone.
Esto es una parte muy importante, pues si disponemos de Pools con distinta tecnología, requeriremos
obligatoriamente dos plantillas, una para usar en Linked Clone y otra para usar en Instant Clone.
4.5 Horizon Client para aplicaciones RDS
Docu VMware - Conectarse a aplicaciones publicadas y escritorios remotos

https://docs.vmware.com/es/VMware-Horizon-Client-for-Windows/4.10/horizon-client-windows-
user/GUID-45149DE2-75E1-4A7F-9B00-6981F97DF52C.html
La instalación de Horizon Client, no es obligatoria en una plantilla para aprovisionar escritorios virtuales,
ya que es el programa que nos permitirá conectar con nuestros escritorios virtuales, por lo que es un
sin sentido.
Horizon Client, no solo permite conectarnos a escritorios virtuales, sino que también permite conectarse
a aplicaciones RDS, previamente aprovisionadas desde el portal de Horizon.
Normalmente, el despliegue de aplicaciones por RDS no se usa para escritorios virtuales, pues
existen otros métodos, pero es muy sencillo poder aprovisionar aplicaciones de manera rápida sin
complicaciones y eso hacer que en ocasiones queramos mezclar ambos conceptos, escritorios
virtuales con aplicaciones por RDS.
Como vemos en la imagen del Horizon Client, podemos conectar a un escritorio virtual, pero si
queremos acceder a una aplicación RDS, no lo haremos desde dentro del escritorio, deberá ser desde
fuera y esto puede ser muy incómodo para los usuarios.
El fin de instalar Horizon Client en la plantilla, es poner a disposición de los usuarios las aplicaciones
publicadas por RDS con acceso desde su escritorio virtual, consiguiendo una unión de ambos conceptos
y facilitando la usabilidad a nuestros usuarios.
Para administrar la configuración de todos estos Horizon Client, podremos usar las plantillas
administrativas de Active Directory y no configurar las conexiones de manera manual para cada uno
de nuestros escritorios virtuales.
5. Escritorios para IT (Full Clone)
En este apartado, veremos cómo aprovisionar los escritorios virtuales al departamento de IT y antes
vamos a introducir algunos conceptos.
Escritorio Persistente. Estos escritorios almacenan los datos de aplicaciones y usuarios en el mismo
disco del sistema operativo. Es lo más parecido a un escritorio físico.
Full Clone. Todos aquellos escritorios generados desde un pool Full Clone, son máquinas idénticas
entre sí en el instante de ser creadas y todas ocupan un espacio en disco idéntico a la plantilla original.
El tiempo de creación de estos escritorios dependerá mucho del tamaño del disco de la VM Base y de
la tecnología de disco que se usa, SSD, SCSI, SATA.
No requieren conexión con la plantilla original y los datos de usuario, SO y temporales conviven en el
mismo disco duro virtual de cada uno de los escritorios.
Recordemos que estos escritorios deben ser escritorios con un alto nivel de flexibilidad, para instalar
o desinstalar aplicaciones según convenga. Esto implica que cada escritorio una vez clonado será
completamente distinto a otro del mismo Pool.
5.1 Opciones del Pool
Docu VMware - Crear un grupo automatizado que contenga máquinas virtuales completas
https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-DB1E305D-
F9CF-4696-BAB7-7915B0A50DA5.html
Docu VMware - Configurar grupos de escritorios

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-E298BBAC-
CBBD-4235-A8A7-CFF09E96DF28.html
Gracias a la amplia documentación de VMware respecto a Horizon View, podemos ver la cantidad de
parámetros disponibles y sus funciones. A continuación, veremos algunas pantallas en la creación del
Pool y sus configuraciones más relevantes.
5.1.1 Aprovisionamiento
Si decidimos realizar el aprovisionamiento manual, debemos realizar las operaciones de clonación
de la VM Base directamente desde la consola de vSphere, y una vez tengamos las VMs creadas y
configuradas ya podremos asignarlas dentro del Pool.
Si queremos evitar interactuar en la creación de los escritorios, debemos usar este tipo de
aprovisionamiento. Esto, como veremos más adelante, requiere que nuestra VM Base esté en formato
plantilla y debemos tener creados los perfiles de configuración de vSphere para seleccionarlo durante
la creación del Pool.
5.1.2 Asignación de usuario

Podemos escoger asignación Flotante, lo cual cada vez que un usuario cierre la sesión del escritorio
virtual, este se liberará para que otro usuario pueda conectarse. Esta opción no es la adecuada en el
escenario que planteamos, ya que nos interesa que dará usuario disponga de su equipo de manera
dedicada.
5.1.3 Tipo
Tal y como hemos mencionado este será un Pool Full Clone, lo cual debemos indicarlo y además
seleccionar la instancia de vCenter que va a usar para generar las VMs.
Muchas de las características que nos ofrece Horizon View en los Pools, vienen limitadas por esta
elección, al escoger un Pool Full Clone, no podremos realizar Recompose o Push, que son comandos
específicos de los tipos de Pool Linked Clone e Instant Clone.
5.1.4 Nombre
Es imprescindible que cada Pool tenga un identificador distinto, aunque el Nombre para mostrar puede
ser idéntico en todos los casos.
5.1.5 Configuración
Docu VMware - Configuración de grupos de escritorios para todos los tipos de grupos de escritorios
https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-0359DB4C-
4517-4535-8EBC-BD4F27C764F3.html
Dependiendo el tipo de Pool, como ya hemos comentado, tendremos unas opciones u otras y algunas
son comunes a todos. Ahora comentaremos las más interesantes:
• Connection Server restrictions: Nos permite restringir el acceso a este Pool por unos determinados
Connection Servers. Si lo dejamos por defecto, se puede acceder por cualquier Connection Server.
• Automatically logoff after disconnect: Permite lanzar un cierre de sesión del usuario una vez
desconectado del escritorio virtual y podemos escoger entre Nunca, Inmediatamente y Después
de…
• Default display protocol: Establecerá el protocolo de la sesión por defecto, que en la mayoría de
casos usaremos VMware Blast.
• Allow users to choose protocol: Permite al usuario establecer el protocolo que desea usar, Blast,
PCoIP o RDP. Como norma general lo estableceremos en No.
• HTML Access: Si marcamos esta opción permitimos el uso del Pool mediante acceso HTML, para
poder usar esto en la instalación del Connection Server debemos marcar el HTML Access.
5.1.6 Configuración de aprovisionamiento

En este apartado podremos activar o desactivar el aprovisionamiento de los escritorios, es decir
podemos crear el Pool pero que no se lance la creación de los escritorios hasta que habilitemos el
aprovisionamiento.
Aquí definiremos el nombre los escritorios virtuales y para ello tenemos el valor {n} para asignación
automática de números. En el caso que queramos usar dos o más dígitos usaremos el valor {n:fixed=2}.
También, definiremos el número de escritorios virtuales que vamos a crear en este Pool, el cual
podremos modificar más adelante.
Por último, definiremos si queremos aprovisionar todos los escritorios que hemos definido antes de ser
usados o si queremos aprovisionarlos durante el primer inicio de sesión del usuario. Recordad que el
tiempo de creación de estos escritorios será el de clonar y preparar una VM completa, por lo que se
recomiendo aprovisionarlos todos antes del inicio del usuario.
5.1.7 Optimización del almacenamiento

Tan solo debemos seleccionar esta opción en el caso de que el clúster donde vayamos a correr los
escritorios virtuales sea vSAN.
5.1.8 Configuración vCenter

Lo primero que haremos será seleccionar nuestra VM Base, en modo Plantilla de vSphere, luego
seleccionar la carpeta de nuestro vCenter donde colocaremos los escritorios virtuales generados y por
último el Cluster, Resource Pool y Datastore que vamos a usar.
5.1.9 Customización del escritorio

Para no tener que realizar ninguna acción sobre los escritorios que generaremos, como, añadirlos
al Active Directory o hacer un SysPrep manual, la mejor idea es seleccionar una customización de
SO, creada en la consola de vSphere, de esta manera podemos definir cosas como añadir al Active
Director, establecer IP en manual o DHCP y otras configuraciones.
5.1.10 Asignar autorización al Pool
Docu VMware - Agregar autorizaciones a un grupo de escritorios o aplicaciones

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-A5DFB49A-
4C0C-4CCB-B481-B22915FFD6D7.html
Ya tenemos nuestro Pool creado y aprovisionado, eso quiere decir que los escritorios virtuales ya están
disponibles para ser usados.
Lo que necesitamos ahora es asignar un grupo de usuario al Pool para que puedan acceder y empezar
a usarlos.
La mejor manera de controlar el acceso a los Pools es crear grupos en Active Directory que hagan
referencia a estos Pools y añadiendo solamente a las personas indicadas. Si intentamos aprovechar
grupos existentes de Active Directory no podemos encontrar sorpresas como que un usuario, por error
puede acceder a un Pool donde no debería.
5.2 Información y tareas sobre el Pool

Desde la consola de Desktop Pools podemos acceder al estado del Pool que acabamos de crear y
dividido en varias pestañas encontramos los Eventos generados, las Global Policies que se están
aplicando y modificarlas para este Pool en concreto, las asignaciones de autorización al Pool, las
Sesiones activas y poder ver el inventario tanto de escritorios virtuales como de discos persistentes,
pero sin duda, lo más interesante es la pestaña principal Summary.
Desde esta pestaña veremos las opciones de Editar el Pool, Eliminarlo, Asignar usuarios o grupos y
modificar el Estado.
6. Escritorios para responsables (Linked Clone)
En los escritorios creados para los responsables de los departamentos, vamos a introducir conceptos
generales para este tipo de escritorios virtuales.
Linked Clone. La tecnología Linked Clone permite ahorra espacio y tiempo, en la creación de
escritorios generados en un Pool. Para poder ahorrar espacio, los discos de cada escritorio virtual no
se clonan, se establecer como discos diferenciales del disco original de la plantilla (delta disk). Por ello,
es importante mantener la VM Base ya que los escritorios virtuales dependen de ella para generar.
El proceso implica primero disponer de una VM Base y realizar un Snapshot como punto de partida,
para generar una VM Réplica de la original en ese estado concreto. Por último, genera los escritorios,
con los discos diferenciales respecto a la VM Réplica. Los discos de los escritorios virtuales, generados
solo almacenarán los cambios diferenciales entre el disco de la VM Réplica y los datos que genera el
usuario.
Escritorio no Persistente. Este tipo de escritorios permite mantener un escritorio de tal manera que
siempre contiene los mismos datos, por lo que están pensados para sistemas donde los datos y
configuraciones no son relevantes. Cada vez que apagamos un equipo, se restablece volviendo a su
configuración inicial.
Disco Persistente. Estos discos están disponibles en los Pools Linked Clon y permiten mantener los
datos del perfil del usuario (C:\Users), de tal modo que podemos usar un Pool Linked Clon como si
fuese Persistente. Este disco redirecciona el perfil a la unidad D: o cualquier otra que configuremos,
permitiendo que, si escritorio virtual se recompone o se elimina, se mantiene el disco persistente y el
usuario no pierde los datos y las configuraciones del perfil.
Tareas Linked Clone. Existen 3 tareas básicas que debemos entender para saber cómo trabajar con
escritorios Linked Clone.
Refresh. La tarea de refresco o actualización sirve para restablecer el disco de SO del escritorio
virtual (delta disk) al estado en el que se encuentra la VM Réplica, por lo que cualquier cambio
realizado sobre ese disco, se perderá. Este refresco, no afectará a los discos persistentes de los
escritorios.
Recompose. La tarea de recomponer permite cambiar los discos de SO del escritorio virtual con
una nueva VM Base o con un nuevo Snapshot. Por ejemplo, si decidimos actualizar los parches
de seguridad de todos los escritorios virtuales, tan solo debemos hacerlo en la VM Base, realizar
un nuevo Snapshot y recomponer el Pool. Además de poder recomponer todo el Pool, también
podemos recomponer solo un escritorio virtual concreto. La tarea de recomponer no afecta a los
discos persistentes.
Rebalance. La tarea de rebalanceo es muy simple, cuando disponemos de un Pool almacenado

en 1 o varios Datastores, nos puede interesar moverlos por tareas de mantenimiento o migración
a un nuevo almacenamiento. La operativa de esta tarea es realizar un Refresh hacia un nuevo
Datastore, por lo que tenemos que ser consecuentes que se perderán los cambios almacenados
en el disco de SO de cada escritorio virtual.
Los escritorios generados en este Pool han de ser homogéneos en cuanto a aplicaciones y además
necesitamos que sean actualizables de una manera centralizada, por el departamento de IT, con el
objetivo de mantener todos en las mismas versiones tanto de parches como de aplicaciones.
En este Pool no se permitirá disponer de aplicaciones que no estén aprovisionadas de manera general
para todo el Pool ya que se perderán cuando realicemos las acciones de actualización de la plantilla
(Recompose).
Docu VMware - Crear grupos de escritorios de clonación vinculada

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-CE05F77C-
1121-444A-8C02-40BA874CFCD7.html
Para este Pool parece algo obvio que debemos escoger el aprovisionamiento automático ya que no
hay ninguna manera de poder usar la tecnología Linked Clone con un Pool manual.
6.1.2 Asignación del Pool

Para la definición de Pool que hemos establecido, vamos a escoger Dedicado, porque nos interesa
que cada responsable de departamento mantenga su escritorio de manera indefinida y así podamos
tener controlada la asignación.
Sería completamente factible usar la opción Flotante, siempre que nos interesase que los usuarios no
tuvieran asignada un escritorio de manera indefinida y cada vez que se desconectasen se perdiera la
asignación.
6.1.3 Tipo
Como hemos adelantado, usaremos la tecnología Linked Clone para generar este Pool, por lo tanto,
seleccionaremos la opción de View Composer linked clones. Esto nos obligará a escoger una instancia
vCenter con su correspondiente Composer configurado.
6.1.4 Nombre
Como ya hemos comentado le daremos un ID único a este Pool y un nombre descriptivo.
4517-4535-8EBC-BD4F27C764F3.html
En la creación del Pool Full Clone, hemos hablado de estas opciones, ahora veremos que opción
aparece para el tipo Linked Clone:
• Refresh OS disk after logoff: Esta opción permite que, en cada cierre de sesión del usuario, el
disco de SO (disco delta), se refresque de tal manera que cuando vuelva a conectar estará en
el mismo estado que la VM Réplica. Disponemos de varias opciones, Nunca, Siempre, Cada x
días o Cuando el disco llegue al x% de utilización. Esta opción es muy interesante para evitar el
descontrol de configuraciones o instalaciones no centralizadas en la VM Base.
6.1.6 Configuración del almacenamiento

Estas opciones son idénticas al anterior Pool creado, y lo que debemos hacer es darle otro nombre de
equipos al nuevo Pool.
6.1.7 Discos View Composer

Este apartado es único para los Linked Clone. En este apartado definiremos, si nos interesa, el Disco
Persistente, que nos permitirá mantener los datos del perfil sin que se destruyan, reubicando los datos
a la unidad que configuramos.
También podemos y recomendamos configurar el disco de temporales, este disco almacena todos los
archivos temporales que se generan en el escritorio y cuando el usuario cierra la sesión se elimina y
se crea automáticamente de nuevo al iniciarla.
En ambos discos hay que configurar un tamaño especifico máximo, pues estos discos se iniciarán
en modo de aprovisionamiento lento y el gran problema es que no pueden ser ampliados una vez
generados. Si que podemos modificar el valor del disco en la edición del Pool, pero solo afectará a los
nuevos discos.
Para poder ampliar un disco persistente existente, debemos hacer como si de una VM se tratase,
directamente desde la consola de vSphere y luego desde el Windows, esta tarea se deberá hacer
individualmente por cada escritorio virtual.
Si decidimos no usar estos discos, todos los datos de perfil y temporales se almacenarán en el delta
disk y en las tareas de Refresh, Recompose o Rebalance perderemos todos los datos generados.

Este apartado es muy similar al anterior Pool, pero con alguna diferencia, ya que debemos escoger
nuestra VM Base sin ser formato Plantilla de vSphere, sino como una VM normal pero deberemos
disponer de un Snapshot para generar la VM Réplica y luego los escritorios virtuales.
6.1.9 Configuración avanzada de almacenamiento

Este apartado, tenemos opciones para activar la aceleración de almacenamiento, lo cual optimiza
el rendimiento de los discos compartidos para entornos que usan View Composer, también permite
reclamar espacio liberado siempre y cuando nuestra plataforma lo soporte.

La customización de los escritorios generados con Linked Clone, nos permite usar una funcionalidad
muy interesante que se llama QuickPrep. Esta función sustituye al Sysprep de Windows reduciendo
las operaciones de restablecimiento siendo mucho más rápido, además podemos pasar Script
personalizados.
Functions Microsoft Sysprep VMware QuickPrep

Elimina cuentas locales Si No
Cambia el identificador de seguridad (SID) Si No
Eliminar el padre del dominio Si No
Cambia el nombre del equipo Si Si
Añade al dominio Si Si
Genera nuevo SID Si No
Personaliza language, configuración regional, etc. Si (opcional) No
Reinicios necesarios 1 (configuración inicial) 0
Requiere archivo de configuración Si No
Activación licencias KMS No Si
Scripts post-customización No Si
https://kb.vmware.com/s/article/2003797
Desde esta configuración estableceremos la Unidad Organizativa de nuestro Active Directory donde se
crearán los objetos de Equipo de los escritorios virtuales.
Es una buena práctica marcar la opción que permite reutilizar las cuentas de equipo preexistentes, de
esta manera no se crearán multitud de objetos sobre nuestro Active Directory.

La asignación de autorización funciona del mismo modo que en el Pool de Full Clones, por lo que
crearemos un nuevo grupo de Active Directory para asignar los usuarios que deberán usar este Pool.
Como hemos visto en el Pool de Full Clones, podemos ver el estado del Pool desde la consola de
Desktop Pools, pero como hemos comentado cada tipo de Pool tienes sus propias opciones sobre la
pestaña de Summary.
En este caso, además de las opciones vistas anteriormente, podemos encontrar una que es View
Composer que nos ofrece tres posibilidades, Refresh, Recompose y Rebalance.
Estas acciones repercutirán sobre todos los escritorios generados, por lo que hay que ser conscientes
que un error en alguna acción afectará a todos. La tarea más interesante que vamos a ver es la de
Recompose porque es la acción que usaremos cuando quedamos modificar nuestra VM Base, por
ejemplo, con nuevas actualizaciones de Windows.
Como podemos observar lo primero que nos aparece es cuál será la nueva Parent VM, es decir, si
vamos a cambiar la VM sobre la que basamos nuestros escritorios virtuales.
La segunda opción que tenemos es la de escoger el Snapshot de la VM Base, para saber en qué
estado se van a generar los escritorios virtuales. En el caso de haber actualizado nuestro Windows
10, lo que hubiésemos hecho es un nuevo Snapshot y en esta ventana simplemente lo seleccionamos
para que aprovisione a todos los escritorios con ese nuevo Snapshot.
Por último, nos da la opción de que la nueva configuración que vamos a desplegar a todos los escritorios
pase a ser la nueva configuración del Pool, de este modo si generamos un nuevo escritorio mantendrá
la misma VM Base y Snapshot que el resto de los escritorios recompuestos.
Podemos programar la tarea para una hora determinada y además forzar o no, el cierre de sesión de
los usuarios.
Una vez lanzado el Recompose nos dirigimos a la pestaña de Tasks para ver el estado de la tarea e
incluso si queremos Cancelarla.
En la pestaña de Inventory, podemos ver en qué estado se encuentra cada uno de los escritorios,
si ha empezado la tarea de recomponer o si está todavía el usuario conectado o si está el escritorio
disponible para su uso.
Como hemos advertido, esta acción afecta a todos los escritorios virtuales del Pool y debido al gran
riesgo que supone un cambio como este es muy recomendable realizarlo primero en un solo escritorio
para validar su correcto funcionamiento.
Para realizar esto, lo único que debemos hacer, es acceder al escritorio que queramos recomponer y
podremos ver que disponemos de las mismas opciones de Refresh, Recompose y Rebalance, además
de Cancel Task, que teníamos en el Pool.
7. Escritorios para trabajadores (Instant Clone)
En el Pool creado para los trabajadores, vamos a introducir conceptos generales para este tipo de
escritorios virtuales.
Instant Clone. La tecnología Instant Clone es muy parecida en concepto a Linked Clone, pero con
una operativa totalmente distinta. Así como Linked Clone opera a nivel de disco y mantiene un disco
en cada escritorio virtual con los datos diferenciales respecto a la VM Réplica, Instant Clone genera en
cada escritorio virtual, un disco diferencial y una memoria RAM diferencial respecto a una VM Parent,
que se aprovisiona para cada uno de los nodos ESXi y se mantiene encendida.
Esta tecnología no permite mantener ningún dato del escritorio virtual de manera persistente, de este
modo, cuando el usuario cierra la sesión o reinicia el escritorio, este, se destruye y se genera de nuevo
en el mismo estado que la VM Parent.
Instant Clone genera varias VM en el proceso de aprovisionamiento del Pool, por lo que necesitamos
una VM Base con un Snapshot del estado que vamos a aprovisionar. Luego se generará una plantilla,
para todo el Pool, del estado de nuestra VM Base con el Snapshot y seguidamente una VM Réplica
en cada uno de los Datastores asignados al Pool. Estas VM Réplica serán la que generará las VM
Parent en cada uno de los nodos ESXi y en cada Datastore asignado al Pool. Las VM Parent están
siempre encendidas y son las encargadas de compartir tanto el disco como la memoria para generar
los escritorios virtuales y aprovisionarlos en muy pocos minutos.
Push Image. En los Pools de Instant Clone, el concepto para configurar la VM Base es “Published”,
esto quiere decir que cuando nosotros queremos cambiar nuestra VM Base o un Snapshot de la
VM Base, la tarea que realizamos es un Push Image. Este proceso, no reconfigura ninguno de los
escritorios existentes, el proceso realiza las VMs intermedias y las Parents VM en cada host y las deja
aprovisionadas, para que, en el próximo cierre de sesión de un escritorio virtual, se genere de la nueva
imagen publicada.
Este tipo de Pool se compondrá de escritorios virtuales no persistentes, por lo que, en cada cierre de
sesión, reinicio o desconexión, el equipo se eliminará y pasará a entregar un nuevo escritorio virtual al
usuario que acceda al sistema.
Con estos escritorios virtuales no persistentes, debemos asegurarnos de que los usuarios no
almacenan datos sobre sus carpetas de Escritorio, Documentos, Imágenes, etc… ya que, en cada
cierre de sesión, los perderían.
Para evitar este inconveniente, lo correcto es usar el sistema de Redirección de Carpetas de Microsoft
o el mismo sistema de Redirección de Carpetas mediante VMware UEM, que veremos en el apartado
“6 - Perfiles de Usuarios”, así nos aseguramos de que, aun usando escritorios virtuales no persistentes,
garantizamos el acceso a los datos guardados durante su uso.
Docu VMware - Crear grupos de escritorios de clonación instantánea

https://docs.vmware.com/es/VMware-Horizon-7/7.7/horizon-virtual-desktops/GUID-F5C53552-
F6C8-4BE8-B486-9D172CA1F5CD.html
Instant Clone se basa en el mismo concepto que Linked Clone, escritorios que se aprovisionan de
manera automática, por lo que la única opción viable es escoger Pool automático.
7.1.2 Asignación de usuario

La razón de implementar este tipo de Pool a los empleados es que no nos interesa que cada empleado
tenga un escritorio asignado de manera indefinida, por lo que la opción de la asignación de usuario
será Flotante.
Con esta opción, conseguiremos que cuando un usuario cierre la sesión, libere el escritorio virtual para
que otro usuario pueda acceder.
7.1.3 Tipo
Para poder operar tal y como nos interesa, escogeremos el tipo de Pool Instant Clone, y seleccionaremos
nuestro vCenter vinculado.
7.1.4 Nombre
Como ya hemos comentado le daremos un ID único a este Pool y un nombre descriptivo.
4517-4535-8EBC-BD4F27C764F3.html
En la creación de los anteriores Pools, hemos hablado de estas opciones, ahora veremos que opción
aparece para el tipo Instant Clone:
• Allow user to initiate separate sessions from different client devices: Esta opción permite que
un usuario pueda iniciar sesión desde varios dispositivos, teniendo varios escritorios ocupados.
7.1.6 Configuración de aprovisionamiento

Estas opciones son idénticas al anterior Pool creado, y lo que debemos hacer es darle otro nombre de
equipos al nuevo Pool.

Este proceso es idéntico al usado en el Pool Linked Clone, pero hay que ser conscientes que no
podemos usar la misma VM Base, pues en la instalación del View Agent no pueden convivir el agente
de Linked Clone con el de Instant Clone.

Para la customización de los escritorios se usará la tecnología ClonePrep que en funciones es idéntica
a QuickPrep.

La asignación de autorización funciona del mismo modo que en los anteriores Pools, por lo que
crearemos un nuevo grupo de Active Directory para asignar los usuarios que deberán usar este Pool.
Al igual que en los anteriores Pools, ya comentados, disponemos de mucha información sobre
Inventario, Sesiones, Eventos, etc…, pero lo diferenciador son las opciones en la pestaña de Summary.
Tal y como pasa con el Pool Linked Clone, nos aparece una nueva opción Push Image con tres
opciones, Schedule, Reschedule o Cancel.
Del mismo modo que si fuere un Recompose en Linked Clone, nos solicita la VM Base y un Snapshot.
Una vez Publicada esta nueva imagen, todos los escritorios se crearán a través de ella.
Si nos dirigimos a la pestaña de Summary y vemos el apartado de vCenter podremos observar que
disponemos de dos apartados Current Image, en estado Published y otro apartado Pending Image con
el estado Publishing.
Una gran diferencia, con respecto a la gestión de los escritorios virtuales de manera individual, con
Linked Clone, es que ahora no disponemos de tareas adicionales sobre los escritorios virtuales de
Instant Clone, porque el simple hecho de reiniciar el equipo, este se elimina y se genera de nuevo en
el estado idéntico a la imagen Publicada.
8. Gestión de perfiles Windows
Cuando disponemos de un sistema de escritorios virtuales, una de las grandes ventajas es la eliminación
y creación de escritorios de manera rápida, podemos aprovisionar 10 ordenadores nuevos o migrar a
10 usuarios de un Windows 7 a un Windows 10 sin mucho esfuerzo.
Para poder aprovechar esta ventaja es importante saber dónde y cómo ubicar los datos del perfil de
nuestros usuarios, para poder hacer estas migraciones de manera rápida y con el menor impacto
posible. Hablamos de la carpeta que habitualmente se encuentra en C:\Users
En este apartado vamos a plantear distintas opciones para realizar el tratamiento del perfil para encajar
la mejor solución en cada caso.
8.1 Disco local y disco persistente
Cuando instalamos un SO de Windows por defecto la carpeta de los perfiles de usuario se ubica en C:\
Users, por lo que cualquier escritorio virtual que aprovisionemos creará las carpetas del perfil en esa
ubicación.
Esta carpeta, la de los perfiles de Windows, contiene información como Escritorio, Documentos,
Imágenes, etc. Además de las carpetas AppData donde se almacenan los datos de configuración de
las aplicaciones para ese perfil en concreto.
La carpeta del perfil está ubicada directamente en el disco local donde se almacena todo el SO y como
ya hemos adelantado, una de las ventajas es poder cambiar nuestro SO sin necesidad de migrar
datos. La mejor opción es mover esta carpeta a otra ubicación.
Cuando tratamos este tema con un Pool de Linked Clone, ya sabemos que en el momento de
Recompose o Refresh, perdemos todos los datos del disco del SO, entonces no es la mejor idea dejar
la carpeta del perfil en la ubicación por defecto. Como hemos visto en la creación del Pool Linked
Clone, nos permite seleccionar un Disco Persistente para que se añada en cada uno de los escritorios
virtuales generados. Este disco garantizará que el perfil del usuario no se ubica en el disco de SO, por
lo que no se verá afectado por las tareas habituales de los Pools de Linked Clone.
8.2 Redirección de carpetas y perfiles móviles
8.2.1 Redirección de carpetas

La tecnología que más facilita la gestión de los datos del perfil de un usuario es la redirección de
carpetas, que permite acceder a todos los datos desde una unidad de red y donde el administrador, de
manera centralizada, controla y gestiona todos estos datos. Esto le permite aplicar políticas de copia
de seguridad sin depender de los equipos clientes, además garantiza que, si un usuario accede a otro
equipo de la empresa, podrá acceder a sus datos sin problemas y siempre actualizados.
Al disponer de los archivos en un servidor, podemos aplicar medidas de control de espacio, bloqueo de
extensiones de ficheros e incluso crear informes de estado de los documentos de nuestros usuarios.
User Configuration/Windows Settings/Folder Redirection
• Documents y Desktop: Podemos establecer distintas configuraciones sobre las carpetas del
perfil, en este caso usaremos la misma.
Target
• Settings: Basic – Redirect everyone’s folder to the same location.
• Target folder location – Create a folder for each user under the root path.
• Root Path: \\fileserver\folders-redirect
Settings
• Move the contents of Documents to de new location.
• Leave the folder in the new location when policy is removed.
8.2.2 Perfiles móviles

Muy en línea con la redirección de carpetas, encontramos los perfiles móviles que en grandes rasgos
permite sincronizar los datos de aplicaciones almacenados en el perfil, pero solo los que se almacenan
en AppData\Roaming, es decir aplicaciones preparadas para ser móviles.
Los datos almacenados en el perfil móvil se sincronizan con la unidad de red, por lo que en cada inicio
o cierre de sesión se debe actualizar los datos y esto puede enlentecer las tareas de inicio y cierre.
User Configuration/Windows Settings/Folder Redirection
• AppData (Roaming): Podemos establecer la misma configuración que hemos usado para
Documents y Desktop.
Target
• Settings: Basic – Redirect everyone’s folder to the same location.
• Target folder location – Create a folder for each user under the root path.
• Root Path: \\fileserver\folders-redirect
Settings
• Move the contents of Documents to the new location.
• Leave the folder in the new location when policy is removed.
Si nos centramos en la redirección de carpetas y perfiles móviles, quizás podemos pensar que no son
necesarios los discos persistentes, pues con estas soluciones, ya disponemos de todos los datos en
una ubicación compartida. Esto no es así del todo, porque existe una carpeta llamada AppData\Local
que no se puede redirigir y en esta carpeta encontramos configuraciones de aplicaciones o cache de
aplicaciones que por si estructura no se almacenan en la carpeta AppData\Roaming.
Para evitar la pérdida de los datos almacenador en AppData\Roaming en cada Recompose o Refresh,
es buena idea mantener tanto la redirección de carpetas, como el perfil móvil, así como el disco
persistente, obteniendo un control completo de los datos del perfil del usuario.
8.3 Persona Management
VMware en nuestra plataforma de Horizon, nos facilita una tecnología similar a la redirección de
carpetas y los perfiles móviles, pero con muchas más opciones de configuración y flexibilidad a la hora
con configurarlo.
Como vimos en el apartado de Horizon Agent, es un componente que debemos instalar en la plantilla
para poder usarlo, pero para configurar y manipular este servicio requeriremos instalar las Plantillas
Administrativas en nuestro entorno de Directivas de Grupo (GPO).
El concepto de uso es idéntico al mencionado en la redirección de carpetas y perfiles móviles, por lo que,
si la idea principal es usar esas tecnologías, es muy muy recomendable usar Persona Management.
Podremos encontrar muchas configuraciones referentes a Persona Management y ahora veremos las
básicas.
Computer Configuration/Administrative Templates/VMware View Agent
Configuration/Persona Management/Folder Redirection
• Add the Administrators groups to redirected folders: Permite que los administradores puedan
acceder a las carpetas de los perfiles de los usuarios, de lo contrario no podrán acceder.
Computer Configuration/Administrative Templates/VMware View Agent
Configuration/Persona Management/Romaing & Syncronization
• Files and folders excuded from roaming: Podemos establecer las carpetas del perfil de usuario
que no queremos sincronizar con el servidor.
• Music
• Pictures
• Videos
• Download
• AppData\Local\Temp
• AppData\Local\Packages
• $Recycle.Bin
• *thumb*.db
• *icon*.db
• …
• Folders to background download: Permite establecer directorios que se sincronicen en segundo

plano y no afecten al inicio de sesión.
• AppData\Local
• AppData\LocalLow
• …
• Manage user persona: Activa la funcionalidad de Persona Management y establece el tiempo de

sicronización.
• Profile upload Interval: 10 min
• Persona repository location: Establece la ubicación de los datos de los perfiles, sin variables.
• Share parth: \\fileserver\profiles-PM
Como se puede observar en su configuración, no hacemos referencia a ninguna parte de la plataforma

de Horizon, por lo que esta tecnología la podemos llevar a nuestros escritorios físicos, unificando de
este modo a todos los equipos de la empresa. Tan solo requeriremos instalar el Horizon Agent con el
servicio de Persona Management.
8.4 VMware User Environment Manager (UEM)
Quería empezar con la descripción textual de VMware sobre que es UEM, ya que creo que no hay otra
manera de resumirlo para que se entienda.
User Environment Manager permite personalizar y configurar políticas dinámicas en cualquier

entorno de escritorio de Windows virtual, físico y basado en la cloud
https://www.vmware.com/es/products/user-environment-manager.html
Para entender la frase de VMware, nos situaremos en la gestión de políticas de grupo, las GPOs
y más concretamente en todas aquellas que sirven para desplegar configuraciones denominadas
Preferencias a nivel de usuario, por ejemplo, despliegue de unidades de red, impresoras, claves de
registro, conectores ODBC, etc.
Todas estas configuraciones son muy útiles, el problema es que son complejas de administrar cuando
hablamos de muchos usuarios con distintos roles y necesidades.
https://docs.vmware.com/en/VMware-User-Environment-Manager/9.6/com.vmware.user.environment.
manager-adminguide/GUID-4DC595C5-E460-4069-825D-405AAE4EF72E.html
Este sería uno de los tres puntos fuertes de VMware UEM, pero para no perder detalle vamos a verlos
de manera detallada más adelante.
8.4.1 Instalación y configuración
Docu VMware - Configuring User Environment Manager

https://docs.vmware.com/en/VMware-User-Environment-Manager/9.6/com.vmware.user.
environment.manager-install-config/GUID-7D5642ED-736A-48BE-8B80-BACDA81E2929.html
VMware UEM es una herramienta de gestión de perfiles que podemos usar en cualquier entorno,
tanto físico como virtual, tanto con VMware Horizon como con Citrix, esto es debido a que trabaja
directamente con un agente instalado en el equipo cliente y una configuración basada en ficheros que
se configura mediante Directivas de Grupo.
Clientes
En el apartado del cliente, la instalación es muy sencilla, tan solo necesitamos ejecutar el instalador del
agente correspondiente a la arquitectura de nuestro SO, 64 bits o 32 bits.
Consola UEM
En cuanto a la parte administrativa de UEM, tampoco es muy complejo, por un lado, tendremos la
consola de gestión que puede estar instalada en el equipo que usaremos para configurar el entorno,
no instala ningún servicio, ni requiere estar disponible todo el tiempo, tan solo sirve para configurar los
archivos de configuración que se aplicaran a los usuarios.
Configuración UEM
Para la configuración de VMware UEM, tenemos los directorios donde almacenaremos las
configuraciones generales y los perfiles de configuraciones de aplicaciones individuales para cada
usuario.
La carpeta que almacenará la configuración general deberá estar accesible mediante ruta UNC (\\
serfidordearchivos\UEMCONFIG) y dentro de esta se creará una carpeta con el nombre general.
Los permisos sobre esta carpeta serán los siguientes:
Cuenta de usuario Acceso Se aplica a …

Sistema Control Total Esta carpeta, subcarpeta y archivos
administradores Control Total Esta carpeta, subcarpeta y archivos
Usuarios UEM Lectura y Ejecución Esta carpeta, subcarpeta y archivos
Para almacenar los perfiles de las configuraciones de las aplicaciones definiremos otra carpeta,
también accesible mediante ruta UNC (\\servidordearchivos\UEMPROFILES).
Los permisos sobre esta carpeta serán los siguientes:
Cuenta de usuario Acceso Se aplica a …

Sistema Control Total Esta carpeta, subcarpeta y archivos
administradores Control Total Esta carpeta, subcarpeta y archivos
Lista de carpetas / leer datos1
Crear careptas / Anexar datos1
Usuarios UEM Leer los atributos1 Esta carpeta solo
Atributos extendidos de lectura1
Permisos de lectura1
Creador o Propietario Control Total Solo archivos y subcarpetas
1 permisos avanzados
Con los directorios creados, solo nos queda añadir las plantillas administrativas de VMware UEM a
nuestra plataforma de Active Directory y ya podremos configurar el acceso de los usuarios.
La configuración está basada en usuario, por lo que deberemos aplicar nuestra directiva de grupo
sobre las OUs donde residan nuestros usuarios.
Existen muchas configuraciones disponibles en las plantillas de UEM, os mostraremos los mínimos y
alguno más, para que la plataforma funcione correctamente.
User Configuration/Administrative Templates/VMware UEM/FlexEngine
• Flex config files: Directorio UNC de la carpeta de configuración de UEM.
• Central location of Flex config files: \\servidordearchivos\uemconfig\general
• Process folder recursively: marcado
• Run FlexEngine as Group Policy Extension: Ejecuta el servicio de FlexEngine durante el inicio
de sesión.
• Profile archives: Directorio UNC de la carpeta de perfiles de los usuarios. Estableceremos la ruta
del perfil UEM del usuario y para ello usaremos variables.
• Location: \\servidordearchivos\UEMPROFILES\%username%\
• Compress profile archive: marcado
• Retain file modifications date: marcado
• FlexEngine logging: Almacena logs de las acciones de UEM sobre el usuario, nos permitirá saber
si hay fallos en la aplicación de las configuraciones. Aprovecharemos el directorio de los perfiles
para almacenar los logs.
• Path and name of log file:
\\servidordearchivos\UEMPROFILES\%username%\logs.
• Log level: Warn (para no generar excesivos datos sin necesidad).
• Maximum log file in kb: 512.
• Profile archive backups: Nos permite almacenar un copia de seguridad de las configuraciones de
las aplicaciones de cada usuario para recuperarla en caso de error o equivocación en una de ellas.
• Location for storing user profile archive backups:
\\servidordearchivos\UEMPROFILES\%username%\backups
• Number of backups per profile archive: 3
• Create single backup per day: Marcado
User Configuration/Windows Settings/Scripts (Logon/Logoff)
• Logoff: Definiremos una ejecución del programa FlexEngine con un parámetro para el cierre de
sesión del usuario.
• Script Name: c:\Program Files\Immidio\Flex Profiles\FlexEngine.exe
• Script Parameters: -s
Existe una directiva grupo que es necesaria, pero la deberemos aplicar a los equipos donde se vaya a
ejecutar el agente de UEM, ya que es una configuración a nivel de equipo.
Computar Configuration/Administrative Templates/System/Logon/
• Esperar siempre a que se inicialice la red en el inicio del equipo y el inicio de sesión: Como
el nombre indica, esta configuración hace que el equipo deba esperar el inicio de sesión hasta que
la red esté disponible.
8.4.2 Consola VMware UEM

Existen tres grandes conceptos en la consola de gestión de VMware UEM. Estos conceptos están
distribuidos en tres pestañas y empezaremos a comentarlas de derecha a izquierda.
Condition Sets
De lo primero que hablaremos es de la opción de Conditions Sets, lo cual como el nombre indica nos
permite crear condiciones preconfiguradas.
Las posibilidades de creación de condiciones son tan variadas como, pertenecer a un grupo o Unidad
Organizativa de ActiveDiretory, filtrar por versión o arquitectura de SO, filtrar por fechas o día de la
semana, filtrar por IP o rango de red, filtrar por existencia de una clave del registro, fichero o carpeta,
incluso filtrar por un valor de una variable del sistema (%temp%, %username%, etc.).
Con estas condiciones definidas, podremos aplicarlas a cualquier configuración que queramos
implementar dentro de la consola UEM.
User Environment
Docu VMware - Configuring User Environment Settings

environment.manager-adminguide/GUID-3BEEE7A3-A505-479A-BF22-F1ADE24A5619.html
Este apartado es el substituto natural de la Directivas de Grupo a nivel de usuario, de tal manera
que podemos aplicar hasta configuraciones de políticas mediante plantillas administrativas tanto del
sistema operativo como de aplicaciones de terceros.
Como podéis observar en la imagen, existen muchas configuraciones y vamos a ver algunas de ellas.
ADMX-BASED SETTINGS
Las plantillas administrativas que podemos desplegar desde VMware UEM son solo las basadas en
Usuarios y no a nivel de Equipo y lo primero que debemos hacer es cargarlas y para ello tan solo
debemos indicar al VMware UEM de donde las tiene que recoger.
Como es habitual todas las plantillas administrativas las encontramos en la carpeta de los controladores
de dominio C:\Windows\PolicyDefinitions en el caso que uséis el Sistema Centra de GPO, estará en \\
dominio.local\SYSVOL\dominio.local\Policies\PolicyDefinitions.
Cuando se añaden todas las plantillas administrativas, debemos ejecutar el proceso de validación, de
este modo, nos marcará todas las plantillas que no podemos usar y las eliminaremos para mantener
el sistema lo más limpio posible.
Una vez cargadas todas las plantillas administrativas de nuestra ubicación, podemos generar una
nueva configuración de ADMX.
APPLICATION BLOCKING
El nombre no entraña secreto, se nos permite bloquear todas las aplicaciones que no corran dentro
de las carpetas C:\Program Files y C:\Program Files (x86), consiguiendo mediante condiciones poder
ejecutar aplicaciones fuera de ese ámbito.
Primero debemos activar la configuración a nivel de VMware UEM.
Con la configuración general activada, podemos crear bloqueos de aplicación basadas en el Hash del
ejecutable, en la ruta de ejecución o basado en el Publicador de la aplicación.
DRIVE MAPPINGS
Mapear unidades nunca fue tan sencillo, tan solo debemos crear una configuración y asignar los
valores que queramos.
Establecemos un nombre a la configuración, podemos usar Label para dar una descripción breve de la
configuración y Tag para clasificar todas las configuraciones según nos interese.
Decidimos la letra de la unidad sobre la que se cargará la carpeta compartida, establecemos la ruta
UNC y le damos un nombre amigable para que los usuarios lo identifiquen con facilidad.
Respecto a las opciones de aplicación es aconsejable usar tanto la opción “Undo at logoff and refresh
during drive mapping refresh” y “Run asynchronously” para que en cada inicio deba volver a reconectar
la unidad y además, se pueda ir aplicando los cambio durante toda la sesión del usuario y no solo
aplicarlo en el inicio de sesión.
Si vamos a las Conditions, podremos establecer condiciones únicas para esta configuración o
aprovechar para usar las Conditions Sets que hemos establecido al principio, además se puede usar
múltiples condiciones usando operadores de OR, AND o NOT.
FILE TYPE ASSOCIATIONS
Podemos establecer de una manera gráfica, las aplicaciones que abren cada uno de los tipos de
archivos que nos interesa.
Además, podemos establecer la apertura de un archivo realizando una condición de si existe el

programa, es decir, si la asociación de un .docx es con la aplicación Word, que lo aplique solo en el
caso que exista en la ruta de instalación el programa WINWORD.exe.
FOLDER REDIRECTION
Así como hemos visto que podemos redirecciona las carpetas de usuario mediante las GPOs o
mediante Persona Management, VMware UEM no es una excepción y permite redirigir las carpetas
que nos interesa hacia una ruta UNC compartida para almacenar los datos.
La ventaja de aplicar esta configuración mediante UEM es que podemos añadir condiciones para
establecer una ruta u otra según la condición que nos interese y no complicarnos la vida con las GPOs.
PRINTER MAPPINGS
Las impresoras son un apartado que lleva de cabeza a los administradores, desde siempre, y bajo mi
experiencia, puedo deciros que este apartado es el menos aprovechable, ya que no gestiona drives,
colas ni mejora la asignación que podemos hacer con GPOs.
Aun así, permite asignar colas de impresión de una manera sencilla mediante las condiciones.
PRIVILEGE ELEVATION
Este apartado compensa el uso de VMware UEM en cualquier escenario, ya que como el nombre nos
indica, nos permite establecer aplicaciones para que se ejecuten con permisos elevados sin necesidad
de credenciales de administrador.
Por ejemplo, todos nos hemos encontrado una aplicación que requiere de permisos de administrador
para ejecutarse, porque trabaja sobre directorios del sistema operativo y cuando esto lo trasladamos
a un usuario, o le entregamos un usuario con privilegios o debemos hacerlo administrador local del
equipo, para que pueda usar la aplicación, lo cual implica muchos riesgos.
La idea es que nosotros establezcamos que aplicaciones serán usadas con privilegios elevados, de
este modo, el usuario no será administrador local y no deberemos entregar ningún usuario que pueda
comprometer la integridad del equipo.
También es muy útil para instalación de aplicaciones controladas, que requieren elevación de permisos
y por algún motivo lo deben realizar los propios usuarios y no el administrador.
Lo primero es activar la característica y en caso de las imágenes hemos añadido un mensaje cuando
se ejecuta una aplicación con permisos elevados.
Podemos configurar la elevación de permisos, mediante varios tipos de validación, basado en Ruta, en
Hash, en Publicador y en Argumento.
Podemos usar tanto una carpeta como un archivo concreto, siempre que sea un ejecutable .exe.
incluso que los procesos derivados del principal también sean ejecutados con privilegios elevados.
REGISTRY SETTINGS
El proceso para poder aplicar claves del registro mediante VMware UEM, es muy simple, configuramos
las claves en un equipo y las exportamos.
Ahora cuando creamos nuestra configuración lo que haremos es Importar el archivo, con todo su
contenido, el cual será volcado en el usuario al que aplique mediante las condiciones.
SHORTCUTS
Mucho menos complejo, pero muy útil es aprovisionar accesos directos de lo que nos interese, ya sea
en el escritorio o en menú de aplicaciones de los usuarios y como en todos los apartados mediante
condiciones que nos aportan una flexibilidad muy completa.
Personalization
Este apartado, quizás es el más complejo de entender de la herramienta de VMware UEM, pero a su
vez es un concepto muy interesante y potente.
Lo que nos permite esta configuración es almacenar las configuraciones de las aplicaciones que
queremos para que, sí un usuario inicia sesión en otro equipo que no es el suyo, conserve todas
las configuraciones que haya realizado, por ejemplo, accesos directos dentro de Microsoft Office,
configurar la calculadora en modo científico, personalizaciones del Chrome o Firefox, etc.
Esto no solo aplica a las aplicaciones de terceros, también permite aplicarlo a cosas tan útiles como
los certificados instalados, impresoras mapeadas, barra de tareas, contraseñas de Internet Explorer
o Microsoft Edge, entre otras.
Para facilitar esta adopción VMware UEM ya dispone de plantillas de aplicaciones y configuraciones
de Windows almacenadas que podemos usar con muy poco esfuerzo, pero también dispone de una
herramienta para capturar una aplicación y poder añadirla al UEM para gestionarla. Además, podrán
ser ordenadas mediante carpetas.
AÑADIR CONFIGURACIÓN DE WINDOWS
Docu VMware - Create a Flex Configuration File by Using Windows Common Settings
environment.manager-adminguide/GUID-5BA465FD-388B-4FDA-B323-C7117B462AAC.html
Lo primero que veremos es como podemos añadir una configuración de Windows en el UEM para
almacenar las configuraciones del usuario, mediante una las plantillas disponibles.
Al iniciar Create Config File, podemos escoger entre crearla de cero o usar plantillas y en este caso
seleccionamos Use a Windows Common Setting
Seleccionamos Personal Certificates – AppData NOT redirected para que todas las configuraciones de
los usuarios hechas en los certificados puedan ser almacenadas por VMware UEM.
Como podemos observar ya tenemos disponible la configuración, pero si miramos la pestaña de Import
/ Export está vacía, esto es debido a que estamos usando una plantilla de UEM y si queremos ver que
importa y exporta esta configuración, nos dirigiremos a Manage y Expand.
Para entender cómo funciona este apartado de Personalization, podemos ver que sobre el
archivo de configuración se introducen secciones de [IncludeRegistryTrees], [IncludeFolderTrees],
[ExcludeRegistryTrees], entre otro que podemos añadir desde el botón superior Section.
En estas secciones definimos que datos ha de exportar e importar el agente de UEM para conservar los
datos del usuario, en el caso de esta configuración son unas rutas del registro de Windows, excluyendo
una clave en particular y unas rutas de carpetas del perfil del usuario.
Este apartado es completamente editable, puesto que nosotros podemos definir las necesidades y
configuraciones que queramos para que sean exportadas o no.
AÑADIR APLICACIÓN CON PLANTILLA
Docu VMware - Create a Flex Configuration File by Using an Application Template

environment.manager-adminguide/GUID-F6129695-3B26-4906-AD28-26AC2F46C640.html
Si repetimos el proceso de crear un archivo de configuración, nos centraremos en usar la opción de

Use Application Template y seleccionaremos la Calculadora.
Si expandimos la configuración como hemos realizado en la configuración de Windows, veremos que

tan solo exporta una clave de registro para almacenar las configuraciones hechas sobre la aplicación
Calculadora.
AÑADIR APLICACIÓN CON PLANTILLA ONLINE
Docu VMware - Download Configuration Templates

environment.manager-adminguide/GUID-53CB386F-B6F9-408C-B461-051C2E254A11.html
Si os habéis fijado en el anterior proceso, no es que dispongamos de muchas plantillas de aplicaciones,

pero como la comunidad VMware es infinita, se ha creado un repositorio donde la gente aporta plantillas
ya generadas y podemos descargarlas y añadirlas a nuestra plataforma.
https://communities.vmware.com/community/vmtn/user-environment-manager/
content?filterID=contentstatus[published]~objecttype~objecttype[document]
VMware, para facilitar la adopción de algunas plantillas de aplicaciones, ha añadido una opción, en la
consola de UEM, que nos permite conectarnos con las credenciales de my.vmware.com y añadir las
plantillas directamente.
Podemos seleccionar una o varias aplicaciones y guardarlas en nuestra plataforma de UEM para
poder empezar a usarlas.
AÑADIR APLICACIÓN PROPIA Y ESTABLECER CONFIGURACIÓN
Docu VMware - Create a Flex Configuration File by Using Application Profiler

environment.manager-adminguide/GUID-4B10FEF2-25FE-4EE7-9D2A-42E6BDC212BF.html
Aun existiendo infinidad de plantillas ya preparadas dentro de la comunidad de VMware, siempre

nos podemos encontrar con alguna que no existe y que debemos usar en nuestro entorno, por ello
existe una aplicación, Application Profiler, que instalaremos sobre un equipo, donde no esté el agente
de UEM, para poder generar nosotros mismos archivos de configuración de la aplicación que nos
interese. Además, podremos definir una configuración predeterminada.
La finalidad de este proceso es capturar una de las aplicaciones instaladas sobre el equipo donde
hemos instalado el Application Profiler, de esto modo, podremos saber que rutas del perfil, tanto registro
como archivos, modifica la aplicación para poder capturarlo a nuestros usuarios.
Además, este proceso nos permite modificar la aplicación capturada, por ejemplo, el aspecto o
la configuración de parámetros concretos y almacenar esa información para establecerla como
configuración predeterminada a todos los usuarios.
Durante el proceso de guardar la configuración deberemos elegir “Save config dile and Predefined
Settings”.
Con el archivo almacenado en la carpeta de UEM (\\servidordearchivos\uemconfig\general) podemos

acceder a la consola y entrar en la configuración de la aplicación.
PREDEFINED SETTINGS
En la pestaña Predefines Settings, podemos comprobar que se ha generado una entrada y al editarla,
veremos las opciones para aplicar esta configuración.
• Default Settings: Se aplica cuando no existe una configuración definida en la carpeta del perfil de
usuario.
• Partial Enforced Settings: Se aplica siempre, antes de importar el perfil a la sesión del usuario.
• Default Settings with Partial Enforced Settings: Se combinan ambas configuraciones anteriores,
pudiendo ser configuraciones distintas.
• Full Enforced Setting: Se aplica siempre la configuración definida, aun que el usuario la cambie.
BACKUPS
Otras de las pestañas que podemos comentar en la aplicación son la de Backups, que permite modificar
la configuración definida por la Directiva de Grupo para una aplicación concreta.
DIRECTFLEX
La pestaña de DirectFlex es muy interesante e importante saber cómo se comporta. Para evitar un inicio
de sesión del usuario, muy lento, DirectFlex permite realizar la importación de los datos almacenados
sobre la aplicación cuando esta se ejecute por primera vez, permitiendo así reducir el tiempo de inicio
de sesión. Es probable que en algunas situaciones sea mejor desactivar DirectFlex para evitar que el
primer arranque de la aplicación sea demasiado lento y asumir ese tiempo en el inicio de sesión de
equipo virtual.
CONDITIONS
En las pestañas, como no puede ser de otra manera podemos encontrar Conditions para aplicarlas
directamente sobre una aplicación, para que esta configuración no sea usada para todos los usuarios.
Encontramos una pestaña muy interesante, la de User Enviroment, que como podemos deducir, nos
permitirá realizar cualquier configuración que nos interese sobre esta aplicación, unidades de red,
impresoras, tareas de pre-importación, post-importación, claves del registro, etc…
9. Gestión de aplicaciones
Qué sentido tendría implantar una infraestructura de virtualización de escritorios, si luego gestionamos
las aplicaciones del mismo modo que en un entorno tradicional.
Por ello, no vamos a entrar en entornos de despliegue de aplicaciones como las GPO mediante msi o
con plataformas como System Center de Microsoft.
9.1 Aplicaciones en plantilla
El método más simple para aprovisionar aplicaciones a los escritorios virtuales es desplegar estas,
mediante una instalación tradicional sobre la plantilla base que usaremos para generar los escritorios
virtuales.
Esta opción es la más recomendada para todas aquellas aplicaciones comunes para los usuarios de
nuestra empresa como, un visor de PDFs, un programa de compresión de archivos (7zip, WinZip,
WinRAR, etc.), un editor de texto avanzado, incluso algún navegador que no sea el propio del sistema
Windows 10 como Google Chrome o Firefox. También instalaremos todos los programas básicos de
sistemas internos que se requieran, como el antivirus, alguno de acceso remoto como VNC, TeamViewer
o AnyDesk, los agentes de Horizon, UEM o AppVolumes.
Todas estas aplicaciones tendrán algo en común y es que para poder actualizarlas o instalar nuevas
versiones, será imprescindible hacerlo siempre en la plantilla base y luego realizar la tarea de regenerar
los escritorios virtuales para que todos dispongan de estos cambios.
Es, por tanto, un método muy poco útil para aplicaciones que solo afectan a un grupo de usuarios, por
ejemplo, los usuarios de RRHH no tendrán las mismas aplicaciones que los usuarios de Contabilidad
y esto implica que no pueden estar en la plantilla base, por lo que buscaremos otro método para
desplegar estas aplicaciones.
9.2 Aplicaciones de escritorio remoto (RDS)
Docu www.cenabit.com - Granja RDS en Horizon 7 con Instant clone. Preparar Windows Server
2016
https://www.cenabit.com/2017/07/granja-rds-en-horizon-7-con-instant-clone-preparar-windows-
server-2016/
Docu www.cenabit.com - Granja RDS en Horizon 7 con Instant clone. Crear la Granja RDS
http://www.cenabit.com/2017/08/granja-rds-horizon-7-instant-clone-crear-la-granja-rds/
Este tipo de aplicaciones, no nos sorprenderán, pues es básicamente lo que podemos encontrar con
Microsoft RemoteApps o Citrix XenApps.
Mediante los servicios de Escritorio Remoto de Windows podemos aprovisionar aplicaciones

directamente al cliente de Horizon o podemos incluir estas aplicaciones en los escritorios virtuales
usando el protocolo de VMware Blast.
Lo primero que debemos tener en cuenta es que estos servidores deberán disponer de un servidor
de licencias de Remote Desktop Services (RDS) licenciado para tantos usuarios que necesitemos
aprovisionar aplicaciones, lo cual implica un coste añadido. Por otro lado, todas las aplicaciones que
queramos aprovisionar deberán estar instaladas en uno o varios servidores por lo que hay que tener
en consideración licencias, espacio en disco, RAM, etc. En definitiva, un grupo de servidores más que
mantener en nuestra infraestructura.
Hablamos de un grupo de servidores porque la mayor ventaja de aprovisionar servidores de RDS

es usar la tecnología de Instant Clone o Linked Clone para aprovisionar más o menos servidores en
función de las necesidades de un momento determinado. Gracias a estas tecnologías podremos pasar
de 2 servidores RDSH a 5 sin ningún esfuerzo.
9.3 Aplicaciones Thinapp
Docu VMware - VMware ThinApp User’s Guide

https://docs.vmware.com/en/VMware-ThinApp/5.2.4/com.vmware.thinapp.user/GUID-
B289AEDC-9080-4373-9C14-16F1D068ED08.html
El sistema de virtualización de aplicaciones conocido como ThinApp fue el primer método que VMware
puso a disposición de los usuarios.
ThinApp permite encapsular toda la instalación de una aplicación en un archivo ejecutable .exe que
almacenará los archivos de instalación, configuración, claves de registro e incluso accesos directos
creados.
Una aplicación de ThinApp que requiera dependencias de otra, como podrías ser un Framework
específico, deberá ser encapsulada dentro de la misma para evitar problemas de ejecución.
Esta aplicación se ejecuta desde una carpeta compartida y de manera aislada al escritorio desde
donde la lanzamos, esto permite disponer de una aplicación que solo se ejecuta sobre Windows XP
en un entorno de Windows 7, 8 o 10 incluso en Windows Server. Esto permite usar ThinApp tanto en
escritorios virtuales como en escritorios físicos.
Solo permitirá asignar esta aplicación por usuario, lo cual implica bastante gestión para el administrador,
además el aprovisionamiento de la aplicación asignada solo se podrá hacer en el inicio de la sesión,
impidiendo realizar un cambio en tiempo real sobre el usuario.
La consideración más importante para tener en cuenta para desplegar una aplicación con ThinApp es,
realizar una prueba con la aplicación, pues la experiencia de uso, en ocasiones, difiere mucho de lo
esperado.
9.4 VMware App Volumes
Docu VMware - VMware App Volumes Documentation

https://docs.vmware.com/en/VMware-App-Volumes/index.html
La tecnología AppVolumes es lo más nuevo de VMware en cuanto a virtualización de aplicaciones y en

esencia es muy parecida a ThinApp.
Se encapsula la instalación de una aplicación, o varias, sobre un .vmdk que se llamará AppStack
y podrá ser aprovisionado de distintas maneras, por usuario, grupo de usuarios, equipos o incluso,
Unidad Organizativa.
Cuando se asigna un AppStack, podemos aprovisionarlo en tiempo real sobre el escritorio del usuario,
consiguiendo un despliegue instantáneo. Incluso podemos retirar un AppStack a los usuarios y en el
mismo momento asignar un nuevo, sin necesidad de que cierren la sesión, como pasa en ThinApp.
Esto permite ser mucho más flexible con todas las aplicaciones que queremos aprovisionar.
También encontraremos un nuevo concepto que son los Writable Volumes, discos que permiten
almacenar modificaciones de SO y/o del perfil de usuario de manera que se fusiona con el disco del
escritorio virtual al que se conectó.
Ejemplo, disponemos de un escritorio virtual sin posibilidad de instalar ninguna aplicación porque en
cada cierre de sesión se restablece. Si sobre un usuario cargamos un Writable Volume y realizamos una
instalación de una aplicación esta permanecerá sobre el Writable Volume cargándola en cada sesión
de este usuario independientemente si el escritorio al que se conecta tiene la aplicación instalada.
9.4.1 Instalación y configuración
Docu VMware - Installing App Volumes

https://docs.vmware.com/en/VMware-App-Volumes/2.15/com.vmware.appvolumes.install.doc/
GUID-25B53F4E-C22B-4DBD-A253-D7FA33D965BF.html
Servidor
Para poder instalar App Volumes, es necesario disponer de una base de datos de Microsoft SQL
Server, podemos usar la versión Express, teniendo en cuenta los límites de tamaño y rendimiento. Lo
ideal es si ya disponéis de un MS SQL en la empresa, generar una instancia para almacenar la base
de datos.
Cliente
Cuando ya disponemos del servidor instalado, podemos instalar el agente. El agente durante la
instalación nos requerirá la dirección del servidor de App Volumes, esta configuración podrá ser
cambiada más adelante mediante claves del registro de Windows. Además, durante la instalación
deberemos especificar si omitimos los errores de certificados entre la conexión del cliente-servidor.
Configuración
Docu VMware - Configuring App Volumes Manager

https://docs.vmware.com/en/VMware-App-Volumes/2.15/com.vmware.appvolumes.admin.doc/
GUID-3E512951-4045-4C15-A642-69BBCF4C34B6.html
Para la configuración de App Volumes, existe un asistente la primera vez que accedemos al portal web
de administración. Este asistente te guiará por las configuraciones necesarias para poner a punto la
plataforma.
LICENSE
Cargamos el archivo de licencia descargado de nuestro portal de my.vmware.com.
ADD DOMAINS
Introduciremos los servidores de Active Directory de los cuales leeremos la información para poder
asignar AppStacks por grupo, usuario o Unidad Organizativa.
ADMIN ROLES
Seleccionaremos un grupo o usuario para asignarle los roles de administrador de App Volumes,
recordad que siempre es mejor trabajar con grupos para agilizar los permisos.
MACHINE MANAGERS
En este apartado, conectaremos con nuestra plataforma de vSphere, conectando directamente con el
vCenter.
STORAGE
En este apartado tenemos que indicar sobre que Datastore queremos almacenar los AppStacks y
las plantillas de los AppStacks, también definiremos el Datastore donde guardaremos los Writable
Volumes y sus plantillas. En este momento también deberemos cargar las plantillas predefinidas de la
plataforma para empezar a generar AppStacks.
9.4.2 Consola App Volumes

En la consola de App Volumes disponemos de todo lo necesario para crear, adjuntar y controlar los
AppStack y Writable Volumes.
Volumes
En este apartado encontraremos tres pestañas de control que son:
ATTACHMENTS
Nos permite ver todas AppStacks y los Writable Volumes que están añadidos a los equipos virtuales.
ASSIGNMENTS
Podemos ver un listado de las asignaciones de toda nuestra plataforma, ya sean usuarios, grupos,
equipos o Unidades Organizativas.
APLICATIONS
Nos lista todas las aplicaciones que App Volumes ha detectado en los AppStacks que hemos creado y
nos indica en cual están instalados.
Además de lo comentado, existen dos pestañas que pasaremos a comentar con más detalle.
APPSTACK
Esta ventana será la más usada en la gestión de App Volumes, ya que nos permitirá crear AppStacks,
asignarlos y además saber quién tiene conectado el AppStack.
Cuando generamos un nuevo AppStack, debemos especificar a partir de que plantilla se genera.
La plantilla que hemos cargado durante la configuración es un disco de 20GB en modo Thin Provisioning
completamente vacío. Cuando realizamos el proceso de Provisioning, lo que hacemos es cargar este
disco vacío en una VM con el agente instalado, para poder instalar las aplicaciones que queramos.
Una vez terminado el proceso, ya tenemos disponible este AppStack para asignarlo a los usuarios.
Podemos generar nuevas plantillas de AppStack, tan solo copiando, a nivel de vSphere, el archivo
.vmdk a la carpeta donde se almacenan las plantillas cloudvolumes\app_template y al generar un
nuevo AppStack ya podremos seleccionarlo como plantilla.
Otra de las funciones que encontraremos en la gestión de AppStacks es el Update, el cual genera un
nuevo AppStack a partir del que ya existe para realizar algún cambio en él, por ejemplo, actualizaciones
de las aplicaciones o añadir aplicaciones nuevas a un AppStack.
La asignación de AppStaks se puede hacer por usuario, grupo de usuarios, equipos o unidad
organizativa, ya sea de equipos o usuarios.
WRITABLES
Aquí, podremos crear los Writable Volumes y comprobar si están conectados. Además, dispondremos
de opciones sobre ellos, como desactivar un Writable Volume, Expandirlo, moverlo de ubicación,
realizar una copia de seguridad o restaurar de una ya realizada, incluso eliminarlo.
Existen varios tipos de plantillas de Writable Volumes, dependiendo lo que queramos almacenar.
• Template_profile_only_workstation: Almacena solamente en el perfil del usuario.
• Template_uia_only_workstation: Almacena solamente la parte de SO.
• Template_uia_plus_profile_workstation: Almacena tanto la parte de SO como el perfil del usuario.
Así como los AppStack se pueden asignar a equipos virtuales, los Writable Volumes solo se pueden
asignar a nivel de usuario. Podemos crear los discos de manera individual o especificar un grupo
de seguridad y en el momento que el usuario acceda a un escritorio con el agente de App Volumes
instalado, se genere el Writable Volume.
IMPORTANTE. No es posible usar Writable Volume con asignación de AppStack a nivel de equipo,
esto es debido a que para añadir los volumenes el orden siempre deber ser, primero Writable
Volume y luego los AppStacks, si enlazamos primero lo de máquina, no puede cargar los Writable
Volume porque se cargan a nivel de usuario.
Directory
En este apartado encontraremos todo lo Reference a los datos de los usuarios, grupos, equipos
virtuales y Unidades organizativas que tenemos en uso.
Si accedemos a un usuario o equipo, nos dará información tan valiosa como si está Online, que
volúmenes tiene conectados en ese momento, que AppStack o Writable Volume tiene asignado,
incluso las veces que se ha logeado.
Infraestructure
Podemos ver la información de los equipos registrados con el agente sobre nuestra plataforma y su
estado, además de ver el almacenamiento y crear grupos de almacenamiento.
Estos grupos de almacenamiento nos permitirán replicar o distribuir los AppStacks y Writable Volumes
entre varios Datastores.
Activity
Veremos todas las tareas pendientes, logs de actividad, mensajes de sistema, log del servidor y
tenemos un apartado de Troubleshooting que nos permite crear archivos de log en formato zip para
enviar a soporte o analizarlo por nuestra cuenta.
Configuration
Como podemos decidir, este apartado nos permitirá cambiar cualquier configuración de la plataforma,
que hemos configurado en el asistente inicial. Conectarnos a un nuevo vCenter, añadir un nuevo
dominio de Active Directory, administrar los roles de acceso, cargar una nueva licencia, modificar
los datastores y rutas donde se almacenan los AppStacks y Writable Volumes y desde el apartado
de settings, podremos establecer una programación para realizará backup en otro Datastore de los
Writable Volumes.
Una parte que deberemos controlar es que cuando se lanza una actualización de App Volumes,
es probable que se mejoren o amplíen las plantillas predeterminadas y si queremos actualizarlas
deberemos recargarlas desde la pestaña de Storage.
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 13
Citrix en vSphere
Héctor Herrero
Capítulo 13 - Citrix en vSphere Héctor Herrero
1. Qué vamos a ver
En este capítulo vamos a conocer qué nos pueden ofrecer los productos Citrix, cómo dimensionarlos
en un entorno virtual de VMware vSphere, algunas recomendaciones, unas mejores prácticas y una
pequeña comparativa de Citrix y VMware.
Los puestos de trabajo y la forma de desempeñar nuestro trabajo han cambiado mucho en los últimos
30 años, gracias Internet, a las nuevas tecnologías móviles o tecnologías de virtualización entre otras.
Citrix desde entonces viene desarrollando tecnologías que permiten a las empresas que apuestan en
innovación IT el poder permitir trabajar a sus profesionales de la manera más óptima.
Una empresa histórica, fundada en 1989, inicialmente se llamaba Citrus; diseñó un protocolo popular
llamado ICA (Independent Computing Architecture) para el producto WinFrame en la época de
Windows NT; que permitía trabajar a los usuarios de forma remota y segura. Estos productos han ido
evolucionando desde entonces y los hemos conocido como Metaframe, Presentation Server, XenApp
o XenDesktop.
Desde entonces, Citrix es la compañía líder en la entrega de aplicaciones y escritorios virtuales. En

este capítulo nos basaremos únicamente en los productos orientados a la entrega de recursos a los
usuarios.
2. Entrega tradicional
Cualquier empleado para poder desempeñar su trabajo necesitará acceder a ciertos aplicativos,
podemos como tradicionalmente darle un PC con software instalado y configurado. Esta opción menos
segura y más costosa nos hará peligrar la credibilidad de nuestro departamento de IT, ya que:
• Está descentralizado, los datos se almacenan en cada puesto y se pueden perder (fugas de
información, roturas del equipo, robos…)
• Costes de operaciones elevados, cada equipo requiere de su mantenimiento, tanto de software

como de hardware. La instalación del software es manual y se hacen infinitas instalaciones. A parte
necesitaremos licencias de antivirus, de copias de seguridad…
• Descontrol, cada empleado tiene diferentes versiones de software o quizá aplicaciones de más.
Pueden conectar cualquier dispositivo al equipo y no con buen fin.
• Largo etcétera…
3. Entrega con Virtual Apps and Desktops
Virtual Apps and Desktops es la solución que nos proporciona Citrix para la entrega de aplicaciones
y escritorios Podremos entregar aplicaciones Windows o Linux, así como sus escritorios a nuestros
usuarios.
Centralizaremos, securizaremos, y sobre todo tendremos control de nuestro entorno, ya que todos
los datos residirán en nuestro centro de datos y nunca más saldrán de él; todo se ejecutará bajo los
recursos de equipos del CPD evitaremos las pérdidas o fugas de datos. Los usuarios mediante un cliente
ligero o un navegador podrán abrir sus aplicaciones corporativas o trabajar mediante el escritorio que
le entreguemos sin mayor diferencia al trabajo tradicional. Y sí cualquier tipo de aplicación, sean las
tradicionales de una oficina, así como las que requieran carga multimedia, entornos 3D… en equipos
thinclient.
Tendremos servidores para alojar múltiples sesiones de usuarios, permitiéndoles a todos ellos
trabajar de forma conjunta sobre una sola MV. Podremos entregar las aplicaciones que tengan estos
servidores instaladas, asociaremos mediante permisos qué usuarios tienen visibilidad sobre qué apps.
O directamente podremos entregarles todo el escritorio del servidor si es que lo preferimos, este debate
lo tendremos más adelante.
Como podemos imaginar, otro de los grandes beneficios la virtualización de apps y desktops es la
unificación de software, ya que todos los usuarios tendrán las mismas versiones de los productos de
nuestra empresa; nos simplificará las actualizaciones de software o la implantación de uno nuevo en
apenas minutos.
Y por supuesto la movilidad, podrán acceder a sus aplicaciones desde la empresa, desde el hotel,
casa... de igual manera y con la misma seguridad. Al ejecutarse todo en el centro de datos, podemos
ahorrar costes de mantenimiento e incorporar en nuestras empresas equipos thinclient que nunca más
requerirán reemplazos o costes de licenciamiento, agentes...
Cada usuario, accederá con sus credenciales mediante un portal corporativo totalmente personalizado
que les facilitará el acceso a los recursos que necesiten, además con diseños y estilos mobile si es que
se accede desde tablets o smartphones.
4. Componentes
Citrix Virtual Apps and Desktops, anteriormente conocido como XenApp para la entrega de aplicaciones
o XenDesktop para la entrega de escritorios, están compuestos de diferentes componentes que
realizan distintas funciones, tenemos:
• Delivery Controller:
Es el componente central de los Sitios de Virtual Apps and Desktops. Se instalará normalmente en
una máquina Windows Server dedicada y podremos ir añadiendo tantos Delivery Controller cómo nos
interese para repartir la carga y disponer de un entorno tolerante a fallos. Es el Broker de sesiones de
nuestro entorno, quien autenticará y administrará los accesos a los recursos de los usuarios. Realiza
un seguimiento de los usuarios, conociendo en todo momento donde se han logueado y que recursos
disponen, así como les permite reconectarse en caso de necesidad a sus apps o desktops. Podrá
conectarse a nuestra plataforma VMware vSphere para aprovisionar máquinas virtuales de manera
totalmente integrada. Y Delivery Controller por supuesto podrá administrar el estado de las máquinas,
pudiendo iniciarlas o apagarlas en base a la demanda existente.
• Base de datos
Toda la configuración del sitio Citrix Virtual Apps and Desktops; así como los registros del mismo,
sean históricos de conexiones de los usuarios o acciones realizadas por los administradores quedan
almacenados en bases de datos. Las bases de datos se almacenarán en un servidor Microsoft SQL
Server, en entornos muy pequeños un SQL Express sobre el Delivery Controller sería suficiente. Pero
queda clara la importancia de la disponibilidad de las BBDD, por tanto, una solución de alta disponibilidad
será importante, algo como SQL Database Mirroring puede ayudarnos y permitir que Delivery Controller
siempre tenga conectividad. También es recomendable habilitar y configurar LHC o Local Host Caché
en el Broker para seguir dando servicio sin conectividad a BD. De manera predeterminada, estas tres
bases de datos se instalan en la misma ubicación que la BD del sitio; aunque esto se podría modificar.
• Servidor de licencias:
Este servicio administra las licencias del entorno Citrix. Descargaremos desde MyCitrix.com nuestras
licencias en archivos con formato .lic y las importaremos; dependerá de ello nos dará uso a diferente
edición de producto. Delivery Controller se comunica con él para administrar la licencia de cada usuario
o dispositivo que se conecte, mediante un licenciamiento nominal (asociada al usuario) o concurrente
(carga simultánea). Si este servicio cae, tendríamos un periodo de gracia de 30 días hasta solventar el
problema; por tanto, en este caso no es muy habitual tener entornos de alta disponibilidad. Se puede
instalar en una máquina dedicada o en el propio Delivery Controller en entornos pequeños. Se dispone
consola de una administración web donde se pueden gestionar directamente con nuestra cuenta de
MyCitrix, las licencias se almacenarán en %programfiles(x86)%\Citrix\Licensing\MyFiles
• VDA o Virtual Delivery Agent
Es un agente que se instala en cada máquina que vamos a entregar a los usuarios, permitirá que los
usuarios se conecten a la máquina y utilicen sus recursos para trabajar. Esta máquina podrá compartir
sus aplicaciones y su escritorio, podrá ser virtual o física, y correr bajo Windows o Linux. En el caso
de usar edición de Server será multiusuario y por tanto múltiples usuarios de forma simultánea podrán
trabajar, o si es Desktop, un usuario por máquina. Los VDA se registrarán contra Delivery Controller
para comunicar su estado o la información de las sesiones de los usuarios de manera constante, así
como su disponibilidad. El usuario al establecer la conexión con el equipo VDA podrá redirigir cualquier
dispositivo que tenga en local, para trabajar de igual forma, sean impresoras, lectores de tarjetas,
dispositivos USB, cámaras, micrófonos… Gracias a un solo protocolo seguro y optimizado llamado
HDX (anteriormente ICA).
• Citrix StoreFront
Es el frontal, el servicio que autentica a los usuarios y les presenta sus recursos, permite el autoservicio
a los escritorios y aplicaciones a las que tienen acceso; podemos pensar en él como en nuestro Store
corporativo, nuestra tienda de apps o escritorios. Instalaremos al menos un servidor Storefront en
la organización, en entornos muy pequeños podría convivir con Delivery Services. Lo normal será
dedicarle una máquina, así como pensar tener alta disponibilidad y balanceo de carga gracias a los
Grupos de servidores, donde el servidor principal replicará su configuración al resto de StoreFront
miembros. Para facilitar y hacer más familiar el entorno, customizaremos el portal Web con nuestra
imagen corporativa.
• Citrix Workspace App
Es el cliente ligero de Citrix que permitirá conectar al usuario con los recursos de la empresa,
anteriormente conocido como Citrix Receiver. Se instala en los dispositivos que usará para conectarse,
sea un PC, un ThinClient, una Tablet o un Smartphone con Windows, Linux, Mac, iOs o Android.
Ofrece a los usuarios un acceso rápido, seguro y de autoservicio a sus aplicaciones, escritorios o
documentos. En dispositivos donde no podamos instalar este cliente, podremos sencillamente
acceder a la plataforma Citrix con un navegador compatible con HTML5 directamente, gracias a Citrix
Workspace app for HTML5,
• Citrix Studio
Es la consola de administración, nos permitirá administrar y configurar nuestro Sitio de Citrix Virtual
Apps and Desktops. Una única consola para administrar la entrega de las aplicaciones y escritorios a
los usuarios; intuitiva y basada en asistentes, nos simplificará los despliegues de recursos y cualquier
configuración necesaria en el entorno. Desde la misma podremos agrupar nuestras máquinas
en Catálogos, entregar sus recursos mediante Grupos de Entrega, configurar el licenciamiento,
conectividad con entornos virtuales o cloud… La mayoría de la configuración la realizaremos mediante
las Directivas, tenemos un repositorio con cualquier tipo de configuración que necesitemos, que luego
la aplicaremos de la mejor manera que nos interese.
La consola Citrix Studio trabaja contra Delivery Controller, tendremos que tenerla instalada en cualquier
equipo Windows, una buena práctica es instalarla en los VDA y publicarla.
• Citrix Director
Con cualquier navegador podremos acceder a esta consola web, que nos permitirá a los técnicos
monitorizar y supervisar el entorno de nuestro sitio Citrix en tiempo real. Una consola que nos mostrará
las principales alertas de nuestro sitio para que podamos anticiparnos a cualquier eventualidad. Desde
aquí también podremos realizar las tareas más comunes sobre los usuarios o grupos, como son:
ver información de su sesión, aplicaciones, procesos, conexión, tráfico HDX, datos históricos… y por
supuesto la de interactuar con los usuarios, pudiendo controlar remotamente su sesión por si tienen
cualquier incidencia. Con una instancia de Citrix Director podemos conectarnos a distintos sitios de
Citrix.
Componentes adicionales:
• NetScaler Gateway
NetScaler es un appliance virtual (o físico) que optimiza, protege y controla la entrega de recursos.
En, en el libro nos basaremos únicamente en la parte Gateway, que nos permitirá acceso seguro a
nuestros recursos desde el exterior. Los usuarios podrán abrir aplicaciones o escritorios desde el
exterior con 1 sólo puerto, HTTPS. Mediante dicho puerto NetScaler Gateway encapsulará todo lo que
el usuario necesite para trabajar, visualización, dispositivos, impresión, audio, video…
• Provisioning Services
Es un servicio que permite aprovisionar imágenes preconfiguradas de Sistemas Operativos por red.
Podremos usarlo con Virtual Apps and Desktops para crear tantos servidores o escritorios cómo
necesitemos para soportar la carga de nuestros empleados.
5. Arquitectura
Imagen donde podemos apreciar las distintas capas que componen nuestras infraestructuras y la
ubicación de cada componente.
6. Mapa de puertos
En la imagen superior podemos apreciar los puertos que utilizan los principales componentes de Citrix
para comunicarse entre sí. Si deseas tener más información sobre todos los puertos utilizados en
cualquier componente puedes echar un vistazo a: https://support.citrix.com/article/CTX101810
7. Citrix vs VMware
No es objeto de este capitulo realizar una comparativa que confronte los distintos productos de los
fabricantes, si no mostrar que opciones nos ofrecen y poder realizar símiles entre ellos.
Cada empresa de virtualización trabaja continuamente por mejorar sus estrategias y sus productos,
es en estos últimos años donde más se han recortado las distancias. Tanto Microsoft, como VMware o
Citrix, que copan el mercado, disponen productos de lo más interesantes.
Microsoft es un actor que lleva unos años mejorando sus soluciones, y gracias a su poder económico,
está recortando distancias, gracias a productos como Azure o Hyper-V. Aunque, Citrix, que fue fundada
en 1989 y VMware en 1998 llevan especializados en esto mucho tiempo.
Veremos cómo son los productos entre las dos empresas más potentes dentro de este sector de la
virtualización, como son Citrix y VMware. Cada una, en su día, se especializó en un tipo de virtualización,
la primera más orientada a la entrega de recursos a los usuarios y la segunda a la virtualización del
datacenter. Así consiguieron copar el mercado, y hoy en día cualquiera de las dos compite, guardando
las distancias según las necesidades, entre ellas sin problemas.
Así que vamos a explicar un poco por encima, qué características tienen los productos más destacados
tanto de VMware y Citrix, que tienen su pareja entre compañías.
7.1 Hypervisor VMware ESXi vs Citrix Hypervisor (XenServer)
Los dos hypervisores son gratuitos y están basados en sistemas linux. Ambos, tanto Citrix Hypervisor
como VMware ESXi disponen por supuesto de su versión de pago, ya que la versión gratuita tiene
muchas limitaciones, lo que hace que no sea adecuada más que para realizar pruebas o entornos de
laboratorio. Entre otros sistemas operativos, son capaces de gestionar máquinas virtuales Windows
como Linux.
Podríamos destacar en Citrix Hypervisor que ha sido el primer hypervisor compatible con los tres
fabricantes de GPUs más importantes (ATI, NVIDIA e INTEL). Y, por ejemplo, que la versión de pago
de VMware ESXi, unida a la suite vSphere, dispone como sabemos de grandes funcionalidades y
sencillez de gestión.
También es importante, que VMware ESXi, aunque incluso ya se puede instalar en productos ARM
(como en una Raspberry Pi), no es tan compatible con el hardware como lo es Citrix XenServer, ya que
ESXi dispone de una lista de compatibilidad bastante limitada (HCL).
7.2 VMware vCenter vs Citrix XenCenter
Para la gestión centralizada de los hypervisores, usaremos VMware vCenter o Citrix XenCenter. El
primero, se ha convertido en el centro de acción de todos los productos de la suite VMware vSphere,
ya que gracias al despliegue de un simple appliance basado en linux Photon, podemos gestionar
prácticamente todos los productos de VMware. Actualmente sólo vía web y por fin mediante HTML5.
Por su parte, Citrix XenCenter, es un software, una consola que se debe instalar en un equipo Windows
mediante la instalación de un cliente que se descarga como un complemento del hypervisor.
7.3 VMware Horizon Apps vs Citrix Virtual Apps
Citrix Virtual Apps es la herramienta estrella de Citrix. Lo que permite es publicar en un portal las
aplicaciones que el usuario luego ejecuta en un servidor remoto como si fuesen propias (imperceptible
para el usuario). Puede trabajar tanto en escritorios/servidores Windows/Linux físicos, como
virtualizados. Se gestiona mediante Citrix Studio, y para ello se instala un agente VDA en la máquina
destino, y los clientes utilizan otro cliente llamado Citrix Workspace App. Y dispone de su propio
protocolo optimizado para la conexión.
VMware Horizon Apps es un concepto muy parecido a XenApp, donde a un usuario tiene un portal
donde el usuario se loguea y se muestran las Apps, siendo posible su acceso desde cualquier dispositivo
(igual que Citrix) sean móvil, tablet, PC, thinclient o fatclient. Normalmente se entregan apps de RDSH.
Ambos fabricantes permiten acceso sin cliente, mediante HTML5, quizá Citrix con mayores
características. En su defecto se podrá instalar un cliente, tanto VMware Horizon Client como Citrix
Workspace App son multiplataforma (Windows, Linux, Android, IOS, MacOS,…)
7.4 VMware Horizon VDI vs Citrix Virtual Desktops
Si en vez de aplicaciones individuales queremos servir escritorios, utilizamos la misma plataforma tanto
en VMware como en Citrix. Así que en la práctica es el mismo concepto en ambas infraestructuras.
Aunque actualmente Citrix es capaz de soportar escritorios cliente Windows y Linux, y Horizon también
lo hace, en nuestra opinión la parte de Linux está menos desarrollado en Horizon. Eso es una ventaja,
porque al final tenemos que adquirir licencias tanto de Remote Desktop Services (actualmente VDAs)
como de Windows, y realmente, si una empresa puede trabajar con escritorios Linux en sus clientes,
ahorrará costes.
Por su parte, la complejidad de instalación de Horizon y su mantenimiento con respecto a la solución

de Citrix, puede ser una gran ventaja para la segunda. Citrix dispone de un sistema de parcheado y
versiones LTSP muy interesante.
Si quieres ver en 1 minuto una comparativa de lo que necesitas para desplegar un ejemplo de 3
desktops, echa un vistazo a este interesante video: https://www.youtube.com/watch?v=Js8x3ayDbRk
7.5 VMware Workspace One vs Citrix Workspace
La tendencia de estas empresas es la de unificar y permitirnos entregar todos los recursos que podamos
necesitar en los negocios. En esta unificación, casí lo hacen con los nombres de sus soluciones,
siendo VMware Workspace One y Citrix Workspace.
La idea es disponer de una solución global donde el espacio de trabajo del usuario esté unificado y
sobre todo simplificado. De forma que un administrador pueda servir soluciones de todo tipo, siendo
transparente al usuario si ese recurso es una APP local o en la nube, por ejemplo. Ya que a parte
de entregar apps SaaS podremos gestionar sus dispositivos móviles o proporcionarles acceso a sus
ficheros de manera cloud.
7.6 Otros productos VMware vs Citrix
En toda la gama de productos de ambas empresas existen otras soluciones que podrían equipararse
pero que las empresas implementan de forma ya distinta, como la parte de Networking con Citrix
Netscaler o VMware NSX, la parte cloud que podría ser un concepto parecido, la monitorización donde
VMware apuesta por parecerse a Grafana, el tema de Containers donde VMware ya está trabajando
seriamente y enfoca su futuro, y donde Citrix no ha empezado seriamente…O sí disponen de soluciones
serias en cuanto a la gestión del dispositivo móvil o MDM, Citrix dispone de XenMobile y VMware de
AirWatch. Por recordar en cuanto al aprovisionamiento de las máquinas virtuales, VMware dispone de
Linked Clones y Citrix de Provisioning Services.
Por tanto, no creemos que exista una mejor o peor solución para cada empresa o usuario, sino que
muchas veces depende del presupuesto, de la oferta comercial, así como de las cualidades del técnico
que realice la implantación. Cada fabricante tiene diferentes pros/contras en sus soluciones así como
diferentes funcionalidades.
Si tienes interés, en 2014 tuve el placer de colaborar en una serie de charlas, una de ellas llamada
‘Despliegue de aplicaciones y escritorios con Citrix y VMware’, donde profundizamos algo más en una
comparativa de productos, puedes verla en: https://vimeo.com/108571572
8. Definición y requisitos de las MVs
Lo primero, remarcar que obviamente, el dimensionamiento las máquinas a utilizar dependerán de

cada escenario. Tendremos que diferenciar las máquinas que se usarán para la ejecución de los
recursos de los usuarios (VDAs) de las máquinas que se tendremos para controlar y disponer del
entorno.
En entornos LAB o pequeña empresa, podemos en una misma máquina albergar todos los roles
de control como son el Delivery Controller, el StoreFront, Servidor de Licencias, BBDD con un SQL
Express y Director entre otros. Esta máquina debe tener al menos 12Gb de RAM.
Si como es habitual, queremos separar los componentes, por ejemplo, para repartir la carga o
configurar sistemas de alta disponibilidad entre ellos, recordaremos que al menos daremos 5Gb de
RAM al Delivery Controller, 2Gb de RAM para StoreFront, 2Gb de RAM para Director y 2Gb de RAM
al Servidor de Licencias.
Windows
7 SP1 / 8 2008 R2 2012 R2 2012 R2 2016 2016 2019 2019
10
/ 8.1 SP1 Std/Ent Core Std/Ent Core Std/Ent Core
Delivery
X X X X X X
Controller
Studio X X X X
Director X X X X X X
VDA 7.15 X 7.15 X X X X X X
StoreFront X X X
Licensing X X X
Se necesitan 3 bases de datos:
• Site o Sitio: Donde reside la configuración de nuestro Sitio de Citrix, estado de las sesiones actuales
e información de conexión.
• Configuration Logging o Registros: Se almacenan los cambios de configuración del Sitio y cualquier
actividad de los administradores.
• Monitoring o Supervision: . Monitor Service recopila y almacena los datos históricos que necesita
Director, como son las sesiones o información de las conexiones.
Podremos almacenarlas en:
• SQL Server 2008 R2 SP2 o superior. En ediciones Express, Standard, Enterprise y Datacenter.
• SQL Server 2012 SP1, SP2, SP3 y SP4. En ediciones Express, Standard y Enterprise.
• SQL Server 2014 SP1, SP2 y SP3. En ediciones Express, Standard y Enterprise.
• SQL Server 2016 SP1 y SP2. En ediciones Express, Standard y Enterprise.
• SQL Server 2017. En ediciones Express, Standard y Enterprise.
Niveles funcionales del bosque y dominio, soportados:
• Windows Server 2008
• Windows Server 2008 R2
• Windows Server 2012 R2
En cuanto al dimensionamiento de las máquinas VDA que serán las que permitan ejecutar a los
usuarios sus aplicaciones, obviamente dependerá del tipo de entrega que hagamos.
Como tabla de soporte de Citrix Virtual Apps and Desktops en infraestructuras vSphere:
VMware Citrix Virtual Apps and Desktops & Provisioning Services

vSphere /
7.6 LTSR 7.14/7.16/7.17 7.15LTSR 7.18/1811/1808
Hypervisor
5.5, 5.5 Up1, Up2, Soportado Soportado Soportado Soportado
Up3 CTX140135 CTX140135 CTX140135 CTX140135
6.0, 6.0 Up1, 6.0 Soportado Soportado Soportado Soportado
Up2, 6.0 Up3 CTX200969 CTX200969 CTX200969 CTX200969
6.5, 6.5 Up1, 6.5 Soportado Soportado Soportado Soportado
Up2 CTX219808 CTX219808 CTX219808 CTX219808
Soportado con el
Soportado
6.7, 6.7 Up1 No Soportado No Soportado Cumulative Update
CTX235513
3
9. Entregando Apps
Normalmente cuando se entregan apps a los usuarios, se entregan desde Windows Server, ya que
desde un servidor pueden trabajar múltiples usuarios de manera concurrente. Hoy en día ya la mayoría
de las aplicaciones soportan plataformas multiusuario. La entrega de Apps permitirá que el usuario
ejecute la aplicación remota en su equipo, de manera totalmente transparente.
En entornos de carga media de tipo ofimática, trabajaremos bajo Windows Server con normalmente
4vCPUs y sobre los 24Gb de RAM, podrá soportar unas 40 sesiones de usuarios de manera simultánea;
claro está que todo se basa en la carga y uso que hagan de las aplicaciones. Usando una media de
400Mb de RAM por usuario, sería un entorno válido. En cuanto al disco, con apenas 50Gb de disco
podría servir, dependerá de las aplicaciones que tenga instaladas y lo que ocupen, ya que los usuarios
no almacenan datos en el servidor. Será importante almacenar esta máquina en disco rápido.
También podríamos entregar apps a los usuarios desde Windows Desktop, a tener en cuenta que un
usuario por equipo de manera simultánea. Quizá más pensado para entornos Workstation, 3D, CAD,
apps no compatibles con entornos multiusuario o Windows Server…
10. Entregando Desktops
Primero, tendríamos que pensar por qué queremos entregar un escritorio completo a un usuario en vez
de servirle únicamente aplicaciones. Si todas las razones nos fuerzan a optar por entregar escritorios
virtuales tendremos dos posibilidades:
Entregarlo mediante Windows Server, será indiferente para el usuario ya que tendrá la experiencia de
escritorio tradicional
• Si tiene las aplicaciones instaladas, los usuarios consumirán recursos en dicho servidor. Puede
que el usuario tenga visibilidad sobre aplicaciones que no nos interese. Los recursos que debe
tener el servidor son algo superiores al escenario de Entregando Apps.
• Si sólo tiene instalado Citrix Receiver, los usuarios al loguearse pasarán sus credenciales a Citrix
Receiver y éste les mostrará aplicaciones que se ejecutarán en otros servidores VDA. Los usuarios
apenas consumen recursos de CPU y RAM en estos servidores.
Entrega mediante Windows Desktop
• A diferencia de Windows Server, en los Desktop permitiremos 1 conexión de 1 usuario por equipo.
• Los Windows Desktop pueden tener las aplicaciones ya instaladas o entregarlas mediante Citrix
Receiver. En ambos casos cada MV consumirá 1-2 vCPUs, 2-4Gb de RAM y 40Gb en Disco.
• Podemos entregar un pool de Desktops a los usuarios y optar por dar un Desktop aleatorio cada
vez que se conecten o asignarles manualmente el suyo.
Una buena herramienta para el dimensionamiento puede ser el XenDesktop 7.x Sizing Calculator que
tenemos aquí: https://blog.citrix24.com/xendesktop-7-sizing-calculator/
11. Aprovisionando máquinas VDA
Las máquinas donde los usuarios ejecutarán sus aplicaciones o escritorios pueden ser equipos
físicos como máquinas virtuales, tanto con Windows o con Linux. En un entorno virtual, podremos
manualmente crear todas las máquinas VDA que necesitemos, como ya sabemos, cada MV consumirá
sus recursos de CPU, Memoria RAM y Disco.
Si queremos evitar crear las máquinas manualmente, podremos a partir de una imagen maestra
desplegar tantas máquinas VDA como nos interese, al igual que cuando tenemos picos de carga,
aprovisionar más máquinas para atender la demanda. Normalmente dependerá del tamaño del
entorno, en entornos pequeños los VDA suelen ser maquinas creadas manualmente, pero cuando nos
enfrentamos a volúmenes altos de usuarios, se gestiona diferente.
Tenemos dos opciones diferentes a la hora de aprovisionar máquinas, tenemos la tecnología de

Provisioning Services (PVS) o también la de Machine Creation Services (MCS).
PVS permite el aprovisionamiento de máquinas, tanto a MVs como Físicas, se integra totalmente con
nuestro sitio Citrix. Desde una imagen base crearemos tantas máquinas como necesitemos, sean
escritorios como servidores de aplicaciones. Los SO se envían por streaming en red y se ejecutan en
RAM y caché, por tanto, no hace falta que tengan discos duros, simplemente se descargan en demanda
de lo que van necesitando. Ideal para entornos con cargas inesperadas de usuarios o alta demanda.
PVS requiere de al menos un servidor dedicado con este rol de Citrix, y como es recomendable varios
para ofrecer alta disponibilidad y balanceo de carga, así como normalmente NIC teaming en las
interfaces de red, para acelerar el proceso de entrega del SO o apps que requieran los VDA. Trabaja
bajo cualquier almacenamiento sea NAS o SAN, los servidores PVS almacenarán en discos locales o
shares los vDisk de las VDA maestras, para luego aprovisionarlos mediante dichas NICs dedicadas. En
entornos físicos las máquinas arrancarán por PXE y en entornos virtuales podremos usar un pequeño
disco con BDM o Boot Device Manager, ambos indicarán el servidor PVS y la imagen que se deben
descargar.
En cambio, MCS sólo aprovisiona MVs en nuestra plataforma virtual (no aprovisiona en físico). Al
igual, nos basamos en una imagen maestra de una MV y de ella aprovisionaremos tantos servidores
y escritorios virtuales cómo necesitemos. Los clones generados tendrán un disco virtual de identidad
(16Mb) y un disco diferencial donde se almacenan los datos del usuario, pero se reclama con cada
reboot; opcionalmente discos de caché o discos personales (PvD) donde permitiremos que los usuarios
almacenen y mantengan sus cambios. Leerán toda la información de un disco creado a partir del
snapshot de la imagen maestra, que se almacenará en cada datastore compartido que contenga
máquinas MCS. Si disponemos de un entorno nube hibrida, con MCS podremos generar sencillamente
e iniciar VDAs en nuestra nube para no afectar a los recursos del datacenter local, esto con PVS no
lo podríamos hacer. Es preferible usar almacenamientos tipo NFS ya que al ser tipo NAS tarda menos
en aprovisionar las máquinas que usando VMFS en una SAN, ya que trabaja a nivel de bloque y no
de fichero.
Normalmente MCS se emplea en entornos demo o pilotos al necesitarse menos infraestructura o en

entornos puramente VDI ya que su implementación no requiere ninguna complejidad, se intregra con
vSphere directamente. Cuando disponemos entornos VDI con escritorios mixed o a gran escala, se
suele optar por PVS ya que dispone muchas más posibilidades, entre otros, habilitando el cacheo
reducimos IOPS. En entornos donde desplegaremos miles de VDAs, aumentando los puertos de
streaming del 6910 a máximo 6968 (por defecto 6910 – 6930) conseguiremos mayor rendimiento,
cada puerto soporta un numero de treads, y estos deberían de ser el número de cores que disponga
el PVS. Con esto conseguiremos levantar muchas más máquinas por PVS. Si con PVS desplegamos
diferentes imágenes de VDA, es recomendable (siempre que se pueda) agruparlas y que cada PVS
despliegue diferente colecciones de imágenes, con idea de optimizar el cacheo en RAM del PVS
necesitando menos memoria. Tanto MCS con vCenter como los servidores PVS necesitan acceso al
Directorio Activo, donde darán de alta las cuentas de los equipos cuando se generen o las borrarán
cuando eliminemos los Catálogos de máquinas.
Cuando definamos una imagen maestra de MCS o PVS deberemos tener en cuenta realizar una buena
optimización de su SO & Apps. Debemos recordar el establecer un procedimiento de actualización
e instalación de software en nuestros VDA, tendremos que documentar correctamente los cambios
realizados. En cuanto al control de cambios en los VDA y su versionado, esto es, cuando queramos
realizar una actualización en la imagen maestra, ambas opciones disponen de su gestión. En ambas
opciones el funcionamiento es similar, donde tras actualizar con los cambios requeridos el VDA maestro
(updates, nuevas apps…) y apagarla, podremos desplegar este cambio de manera inmediata a todas
las VDAs hijas o esperar a que las máquinas se apaguen y tras un simple reinicio cargarían esta
nueva versión de VDA. PVS al ser más completo que MCS, dispone de un control de versiones donde
tenemos más características, entre ellas, el poder testear la imagen antes de pasarla a producción o
hacer roll backs con un click.
En esta imagen podemos ver un resumen de las máquinas que podremos obtener con una u otra
tecnología:
Con MCS podremos hacer Pools de máquinas y entregarlas de manera aleatoria o asignarlas
estáticamente. Hacer un pool de máquinas con disco personal PvD donde guardarán los cambios.
O por último hacer máquinas dedicadas donde los usuarios estarán asignados a máquinas bien
manualmente o por primer uso.
Con PVS haremos streaming a entornos virtuales o físicos, y si queremos que los usuarios hagan
cambios persistentes en las máquinas usaremos PvD, pero sólo en entornos virtuales.
Por último, subrayar que cada escenario de cada empresa es distinto, y puede que nos encaje más
una solución que otra, o ambas dos de manera simultánea. Si todavía tienes dudas de qué puedes
necesitar:
Por cierto, si quieres ver un video de PVS en funcionamiento, que mejor que el video clásico de cuándo
PVS aún se llamaba Ardence: https://www.youtube.com/watch?v=0v7oJfyn3Hc
A la hora de analizar bien el escenario que más nos interesa, personalmente siempre que se puedo,
opto por la virtualización de aplicaciones antes que una virtualización de escritorios, básicamente por
los recursos que requiere un escenario frente al otro, además debemos sumar los costes de operación.
Pero si forzosamente debemos entregar escritorios, tenemos como hemos visto dos alternativas, en
un escenario donde debamos entregar 300 escritorios a 300 usuarios, podremos pensar en entregar
300 Windows Desktops, o 12 Windows Server que hagan la misma función. Podríamos ligeramente
apoyarnos en esta comparativa también a la hora de virtualizar apps:
Escritorios de Windows Server Escritorios de Windows Desktop
Recursos de cada máquina: Recursos de cada máquina:

• 4 vCPU • 1 vCPU
• 16GB RAM • 1,5GB RAM
Total recursos consumidos: Total recursos consumidos:
• 48 vCPU • 300vCPU
• 192GB RAM • 450Gb RAM
Algo que nos puede ayudar a decidir si podemos optar por una solución de virtualización de aplicaciones
o escritorios pueden ser el siguiente diagrama:
12. Proceso de logon del Usuario
En esta sección veremos el proceso completo de todas las fases que comprenden el inicio de una
sesión de un usuario, desde pincha en la primera aplicación o escritorio hasta que se la muestra y
pueda trabajar con ella. Será interesante comprenderlo para evitar problemas de logons.
Antes de comenzar con más detalle, deberemos tener en cuenta que en un sitio Citrix con múltiples
máquinas de tipo VDA, el usuario deberá tener el mismo entorno a la hora de trabajar. Esto es, deberá
tener las mismas configuraciones, se consigue mediante el uso normalmente de perfiles móviles,
que detallaremos más adelante su optimización. De esta manera se consigue que los usuarios, se
conecten a la máquina VDA que se conecten dispondrán de las mismas personalizaciones, firma de
correo, historial del navegador…
La primera vez que se abre una aplicación o un escritorio comienza el proceso de inicio de sesión,
este tiempo es importante minimizarlo para que la sensación del usuario sea buena, una referencia de
30 segundos será válida. Una vez la aplicación o el escritorio haya iniciado, el resto de aplicaciones
iniciarán de manera instantánea ya que la sesión está establecida.
Pero antes de que el usuario conecte e inicie sesión en una máquina VDA tenemos antes una serie de
pasos importantes que debemos conocer:
1. El usuario contacta con el StoreFront y se autentica. El StoreFront lo valida contra el Directorio

Activo.
2. StoreFront contacta con Delivery Controller para conocer los recursos a los que el usuario tiene
acceso.
3. Delivery Controller le envía una lista con los recursos de apps y escritorios.
4. StoreFront obtiene los recursos.
5. El usuario seleccionará una aplicación o un escritorio al que conectarse.
6. StoreFront contacta con el Delivery Controller para solicitar un VDA disponible que tenga los
recursos.
7. Delivery Controller responde a StoreFront con el hostname e IP de la VDA que puede satisfacer la
necesidad. Si el VDA está apagado, Delivery Controller podrá dar orden de encenderla.
8. StoreFront genera un archivo ICA que contiene la información de la conexión recopilada por
Delivery Controller que se envía al usuario final.
9. En el lado del usuario se descarga el archivo de conexión y se abre con Citrix Receiver.
10. Citrix Receiver comprueba e inicia la conexión contra la máquina VDA.
11. VDA comunica con el servicio de licencias Remote Desktop Service para verificar el licenciamiento.
12. Se crea la sesión en el Delivery Controller y comenzaría el Inicio de sesión del usuario en la
máquina VDA hasta que finalmente le muestra la aplicación o escritorio que solicitó y con el que
podrá trabajar.
Siempre que tengamos bien dimensionado nuestro entorno, los servidores StoreFront y Delivery
Controller responderán sin penalizar el proceso de brokering. La parte más delicada viene en el Inicio
de sesión de los usuarios, que es donde se va el mayor tiempo del proceso de logon. Estas serían sus
9 fases:
1. HDX Connection: El tiempo dedicado a establecer la conexión HDX del cliente Citrix Receiver
a la máquina VDA. Son tareas que realiza el VDA, revisa los requisitos de la aplicación (audio,
video, códecs…) y haciendo una compresión de video y gráficos utilizando el códec H.264. Esta
fase puede verse afectada a la hora de redirigir dispositivos del usuario al VDA, como son los
dispositivos USB, webcam…
2. Session Init: Cuando el usuario inicia sesión en el VDA, se inicia un proceso de subsistema SMSS.
exe y arranca un proceso de Winlogon.exe. En Seguridad, del Visor de sucesos: ID 4688 (smss.
exe) para el INICIO e ID 4689 (smss.exe) para FIN.
3. Network Providers: En cada inicio de sesión se Winlogon notifica al proveedor de red para que
puedan recopilar las credenciales y autenticar al usuario en la red. En nuestros VDA será Citrix
PnSson. En Seguridad, del Visor de sucesos: ID 4688 (mpnotify.exe) para el INICIO e ID 4689
(mpnotify.exe) para FIN.
4. Citrix Profile Management: Durante el logon, Citrix UPM copia todas las entradas del registro,
ficheros y configuraciones del almacén de perfiles al VDA local. Si existiese un perfil local en el
VDA a modo caché, se sincronizaría con los últimos cambios del almacén de perfiles. Normalmente
este suele ser el cuello de botella, ya que los usuarios tienen perfiles de gran tamaño si no hemos
sido finos a la hora de configurar UPM. En Aplicación, del Visor de sucesos: ID 10 y en User Profile
Service: ID 1.
5. User Profile: Durante el inicio de sesión, el sistema carga el perfil del usuario y luego se configura
el entorno del usuario de acuerdo con la información del perfil. En User Profile Service, del Visor de
sucesos: ID 1 para el INICIO e ID 2 para FIN.
6. Group Policy: Es el momento en el que se cargan las políticas de grupo y directivas del usuario.
Es importante verificar que ninguna GPO ralentiza la carga con configuraciones inválidas o el
disponer de cientos de GPO. Hasta que no se cargan las GPO no se puede ver la app o escritorio.
En GroupPolicy, del Visor de sucesos: ID 4001 para el INICIO e ID 8001 para FIN.
7. GP Scripts: Es cuando cargan los scripts de inicio de sesión que tenemos configurados en las
GPO. En el caso de los scripts de inicio de sesión síncronos, el Explorador de Windows no se
inicia hasta que los scripts de inicio de sesión terminan de ejecutarse. En GroupPolicy, del Visor de
sucesos: ID 4018 para el INICIO e ID 5018 para FIN.
8. Pre-Shell: Winlogon ejecuta Userinit.exe, que ejecuta los logon scripts, restablece las conexiones
de red y luego inicia Explorer.exe, la interfaz de usuario de Windows. En las sesiones de RDSH,
Userinit.exe también ejecuta cmstart.exe, que a su vez llama a wfshell.exe que finalmente abrirá la
aplicación publicada y requerida por el usuario. En Security, del Visor de sucesos: ID 4688 (userinit.
exe) para el INICIO e ID 4688 (icast.exe) para FIN.
9. Shell: Es el intervalo entre el inicio de la aplicación o escritorio y el tiempo en el que realmente esta
disponible para el usuario
Para más información os dejo la completa guía con todo detalle del gran Andrew Morgan: http://
goliathtechnologies.com/wp-content/uploads/2016/05/LOD-Guide.pdf
13. Perfiles Móviles
Queda claro pues, que una buena gestión del perfil del usuario les proveerá de un inicio rápido al
entorno. En entornos Citrix usaremos UPM, Citrix User Profile Management, que es un conjunto de
directivas que nos van a permitir configurar los perfiles en base a nuestra necesidad de una manera
muy sencilla.
Habrá que definir primero de todo un almacén, una carpeta compartida que será donde se almacenen
los perfiles de los usuarios. Por tanto, al iniciar sesión el usuario se descargará de aquí el perfil a
C:\Users del VDA; mientras el usuario trabaja con sus aplicaciones el perfil se sincronizará con el
almacén; y finalmente al cerrar la última aplicación se cerrará sesión y el perfil guardará los cambios
pendientes al share.
El almacén de perfiles lo crearemos en un servidor de ficheros o sistema DFS, una carpeta compartida
con los siguientes permisos:
Permisos NTFS Permisos SHARE

Administradores: Control Total Todos: Cambiar
SYSTEM: Control Total Administradores: Control Total
Usuarios autenticados: Mostrar contenido de la

carpeta, Leer datos & Crear directorios y añadir
datos, en este directorio sólo.
Creador/Propietario: Control total, subdirectorios y

ficheros sólo.
Para gestionar de manera centralizada los perfiles, lo más sencillo puede ser crear y configurar una
GPO que aplicaremos a la Unidad Organizativa donde tenemos las máquinas VDA. En dicha directiva
deberemos importar la plantilla administrativa de Profile Management que encontraremos en la ISO.
Será ahí donde indicaremos todas nuestras necesidades.
Deberemos definir las directivas que más nos interesen y se adapten a nuestro entorno, con idea
de mantener un perfil ligero. Primero habilitaremos Profile Management y a continuación deberemos
establecer la Ruta al almacén de usuarios, con formato UNC y pudiendo usar variables podremos
indicar algo como: \\NAS\PerfilesCitrix\%username%
A dicha configuración, podrás añadir tantas directivas como te encajen, algunos ejemplos interesantes:
Grupos Procesados / Grupos Excluidos: Pondrás indicar a qué Grupos de Usuarios aplicar o excluir
de UPM.
Reescritura activa: Al habilitarlo permitimos que todos los ficheros del perfil del usuario en el VDA se
sincronicen con el almacén para hacer un cierre más rápido. Si queremos sincronizar también los
cambios el Registro habilitaremos ‘Registro de reescritura activa’.
Gestión de perfiles: Podremos habilitar ‘Eliminar perfiles guardados en caché local al cerrar la sesión’
si queremos que al cerrar la sesión el usuario se elimine el perfil, por higiene. Además podremos
establecer una demora para hacerlo, ya que a veces puede que algún proceso quede bloqueado
durante X segundos. Así como gestionar si existe un perfil ya en el VDA que hacer, si renombrar el
local, eliminarlo o utilizarlo en vez del perfil del almacén.
Sistema de archivos: Podremos excluir qué archivos o extensiones de ellos no queremos que viajen y
se guarden en el almacén del perfil, o qué directorios… De total obligación su configuración, deberemos
aprender y conocer qué excluir en cada organización; ya que cada aplicación genera sus residuos,
temporales, cachés… Herramientas tipo WinDirStat nos pueden ayudar a conocer por donde se nos
van los perfiles, podremos ver tanto los ficheros grandes como directorios con multitud de ficheros que
quizá sobran.
Además, en la misma GPO, suele ser recomendable crear redirecciones de carpetas con el fin de
evitar que ciertas carpetas que almacenan información no la guarden en el perfil, si no en un share de
la red. Mínimamente redireccionaremos carpetas como Descargas o quizás Mis Documentos…
Por último, una muy buena idea suele ser minimizar el tamaño del perfil Default que trae nuestro VDA
en C:\Users, para que la generación de nuevos perfiles tenga el tamaño menor posible.
Directorios que normalmente puedes excluir de UPM:
AppData\Local\Packages AppData\Local\Microsoft\Windows\RoamingTiles
AppData\Local\Microsoft\Windows\Temporary Internet
AppData\Local\TileDataLayer
Files
AppData\Local\Adobe\AcroCef\DC\Acrobat\Cache\
AppData\Local\Microsoft\Windows\WebCache
ChromeDWriteFontaCache
AppData\Local\Adobe\AcroCef\DC\Acrobat\Cache AppData\Local\Microsoft\Windows\WER
AppData\Local\assembly AppData\Local\Microsoft\Windows\WinX
AppData\Local\Mozilla\Firefox\Profiles\virt4901.
AppData\Local\Citrix\DriveMapper3
default\Cache
AppData\Local\Citrix\SelfService\img
default\cache2
AppData\Local\Comms
default\safebrowsing-to_delete
AppData\Local\CrashDumps AppData\Local\SAP\SAP GUI
AppData\Local\Google\Chrome AppData\Local\SAP\SAP GUI\Cache
AppData\Local\Google\Chrome\User Data\Default\
AppData\Local\SAP\SAP GUI\Traces
Cache
AppData\Local\Google\Chrome\User
AppData\Local\Sun
Data\Default\Cached Theme Images
AppData\Local\Temp
Data\Default\JumpListIcons
AppData\Local\Temporary Internet Files
Data\Default\JumpListIconsOld
AppData\Local\WebEx\wbxcache
Media Cache
AppData\Local\Windows Live
Plugin Data
AppData\Local\Google\Chrome\User Data\
AppData\LocalLow
PepperFlash
AppData\Local\Google\Update\download AppData\Mozilla
AppData\Local\Microsoft\AppV AppData\Roaming\Citrix\PNAgent\AppCache
AppData\Local\Microsoft\GameDVR AppData\Roaming\Citrix\PNAgent\Icon Cache
AppData\Local\Microsoft\Group Policy AppData\Roaming\Citrix\PNAgent\ResourceCache
AppData\Local\Microsoft\Internet Explorer\Recovery AppData\Roaming\Citrix\SelfService\Icons
AppData\Local\Microsoft\Internet Explorer\Recovery\
AppData\Roaming\ICAClient\Cache
High
AppData\Roaming\Macromedia\Flash
AppData\Local\Microsoft\Media Player
Player\#SharedObjects
AppData\Roaming\Macromedia\Flash
AppData\Local\Microsoft\Messenger
Player\macromedia.com\support\flashplayer\sys
AppData\Roaming\Microsoft\Document Building
AppData\Local\Microsoft\Office\14.0\OfficeFileCache
Blocks
AppData\Local\Microsoft\Office\14.0\OfficeFileCache. AppData\Roaming\Microsoft\Internet Explorer\
old UserData
AppData\Roaming\Microsoft\Templates\LiveContent\
AppData\Local\Microsoft\OneDrive
Managed\
AppData\Local\Microsoft\OneNote AppData\Roaming\Microsoft\Windows\Cookies
AppData\Roaming\Microsoft\Windows\Network
AppData\Local\Microsoft\Outlook
Shortcuts
AppData\Roaming\Microsoft\Windows\Printer
AppData\Local\Microsoft\PlayReady
Shortcuts
AppData\Local\Microsoft\Terminal Server Client AppData\Roaming\Mozilla\Firefox\Crash Reports
AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.
AppData\Local\Microsoft\WER
default\Crashes
AppData\Local\Microsoft\Windows Live
default\healthreport
AppData\Local\Microsoft\Windows Live Contacts
default\indexedDB
AppData\Local\Microsoft\Windows Live Mail
default\minidumps
AppData\Local\Microsoft\Windows Mail
default\saved-telemetry-pings
AppData\Local\Microsoft\Windows Store
default\sessionstore-backups
AppData\Local\Microsoft\Windows\1033
default\storage
AppData\Local\Microsoft\Windows\AppCache
default\weave
AppData\Local\Microsoft\Windows\Application AppData\Roaming\Mozilla\Firefox\Profiles\virt4901.
Shortcuts default\webapps
AppData\Local\Microsoft\Windows\Burn AppData\Roaming\Sun\Java\Deployment\cache
AppData\Local\Microsoft\Windows\Caches AppData\Roaming\Sun\Java\Deployment\log
AppData\Local\Microsoft\Windows\Cookies AppData\Roaming\Sun\Java\Deployment\tmp
AppData\Local\Microsoft\Windows\Explorer AppData\Temp
AppData\Local\Microsoft\Windows\GameExplorer Sharefile
AppData\Local\Microsoft\Windows\History Software\Microsoft\Windows NT\CurrentVersion\Fonts
Software\Microsoft\Windows NT\CurrentVersion\
AppData\Local\Microsoft\Windows\INetCache
FontSubstitutes
Software\Microsoft\Windows\CurrentVersion\UHF\
AppData\Local\Microsoft\Windows\INetCookies
SHC
AppData\Local\Microsoft\Windows\Notifications Videos
AppData\Local\Microsoft\Windows\Ringtones AppData\Local\Microsoft\Internet Explorer\DOMStore
La reciente adquisición de Norskale por parte de Citrix, nos trajo Workspace Environment Manager.
Si somos Enterprise o Platinum disfrutaremos de la mejor solución para la gestión del espacio de
trabajo de los usuarios. Integrándose y mejorando nuestra solución de Perfil de usuario, optimizando
el rendimiento para acelerar la entrega de las aplicaciones y tener un mejor tiempo de respuesta.
Finalmente, os quería dejar un diagrama del funcionamiento de Citrix UPM:
14. Administrando con Citrix Studio
Una vez tenemos claro los requisitos para desplegar un entorno Citrix, y vista parte de la configuración
inicial, vamos ahora con las tareas que podremos realizar desde la consola Citrix Studio.
Esta consola será la que utilicemos para administrar el entorno, desde ella daremos de alta las
máquinas VDA y entregaremos sus aplicaciones o escritorios a los usuarios. A modo informativo, si te
gusta el PowerShell, la consola registra toda la actividad y muestra sus comandos, por si necesitas
automatizar tareas.
Deberemos añadir las máquinas VDA a Catálogos de máquinas, que no son más que agrupaciones de
máquinas físicas o virtuales que se administran como una única entidad. Todas las máquinas de cada
Catálogo tienen el mismo S.O., así como normalmente mismas apps instaladas. A la hora de crear
el Catálogo deberemos indicar si son S.O. de servidor o escritorio e indicar si las máquinas VDA ya
existen o queremos crearlas a partir de una VDA maestra.
Como anteriormente indicamos, en entornos virtuales o cloud hibrida podremos apoyarnos de MCS
para crear ‘n’ MVs idénticas a un VDA servidor o desktop. En entornos físicos o virtuales podremos
montar una infraestructura de Provisioning Services y aprovisionar tantas máquinas VDA necesiten
nuestros usuarios en cuestión de segundos. Ambas opciones disponen de una sencilla gestión de
versionado, con realizar los cambios en la máquina maestra podremos desplegarlo al resto de VDAs
tras un simple reinicio.
Tras crear los Catálogos, debemos definir qué recursos de estas máquinas VDA entregaremos a qué
usuarios. Crearemos Grupos de Entrega donde indicaremos máquinas de uno o varios Catálogos
y especificaremos qué usuarios o grupos de ellos pueden usar las máquinas, indicando si pueden
conectarse a su escritorio y/o aplicaciones. En los Grupos de entrega definiremos también la
programación horaria, indicando el número de máquinas que queremos dejar iniciadas, dependiendo
de si es horario normal u hora punta podremos ya dejar máquinas esperando a conexiones de usuario,
para agilizar los inicios; así como apagarlas o suspenderlas tras unos minutos si no se utilizan.
Si vamos a publicar aplicaciones a nuestros usuarios, tendremos un menú donde podremos organizar
las aplicaciones tanto para nosotros como para los usuarios. Para publicar una app, será tan sencillo
cómo indicar de qué Grupo de Entrega y examinar en busca del ejecutable que queramos que se abra
(y opcionalmente sus argumentos). Será importante establecerle un nombre a la app, un icono, una
Categoría para agrupar las apps, podremos limitar el número de veces que queramos que se abra la
app por si es licenciada, o limitar a que sólo la abra una sola vez el usuario… Así como quién puede
ver esta aplicación y filtrar por usuario/grupo.
Siguiendo con otras secciones que podremos configurar desde Studio, si necesitamos conectarnos
a nuestra plataforma virtual o nube para aprovisionar MVs con MCS, deberemos crear una conexión
a los recursos. Podremos conectarnos a nuestra plataforma de VMware vSphere a través de nuestro
vCenter Server; pero también podremos conectarnos a infraestructuras virtuales de Citrix Hypervisor
(anteriormente XenServer), o Hyper-V con System Center Virtual Machine Manager. Podremos
conectarnos a los recursos de las nubes: Citrix CloudPlatform, Microsoft Azure o Amazon EC2.
En la sección de Licencias deberemos conectar contra un servidor de licencias que hayamos instalado
e indicar qué licencias de las que ofrece son para nuestro Sitio, podremos agregar licencias así como
indicar en el Sitio la Edición que queremos utilizar.
En la sección de Configuración, podremos definir roles de administradores de Citrix, con acceso

granular y permisos específicos para nuestros técnicos de IT. También podremos indicar la URL del
servidor StoreFront y así en todos los VDA que dispongan de Citrix Receiver instalado se les configure
automáticamente, personalmente soy más partidario de hacerlo mediante GPO. Podremos también
conectarnos a un entorno de Microsoft Application Virtualization para utilizar App-V y hacer streaming
de apps. En caso que dispongamos una implementación de Citrix con servidores remotos en diferentes
delegaciones, deberemos configurar las Zonas e indicar qué recursos pertenecen a cada sitio. Ah, y
todo lo que hagamos en la consola Citrix Studio quedará registrado, ¡podremos saber quién ha hecho
qué, y cuando!
Y, por último, no por ello lo menos importante, sino al contrario, son las Directivas. Aquí será donde
configuremos la experiencia global del usuario. Mediante pequeñas configuraciones iremos configurando
qué opciones pueden realizar los usuarios o qué configuraciones tendrán aplicadas. Podremos crear
directivas totalmente personalizadas o apoyarnos en unas plantillas base que nos ofrece Citrix. Estas
directivas son casi infinitas, las utilizaremos entre otras cosas, para optimizar conexiones WAN, asignar
experiencia de usuario muy alta, para seguridad y control. Podremos impedir acceso a recursos
locales para evitar que pueda sacar información de la organización, así como asignarles impresoras
específicas… QoS en los canales del protocolo ICA HDX, por ejemplo, limitar que a la hora de imprimir
a través de conexiones de baja latencia no supere ciertos Kbps o % de la conexión. Así hasta un largo
etcétera, por tanto, digamos es de recomendada lectura todas y cada una de las directivas, vienen
correctamente explicadas (y en español). Cualquier directiva se puede aplicar en el ámbito que nos
interese, podremos aplicarlas a usuarios/grupos, a VDAs que pertenezcan a un Grupo de Entrega,
podremos aplicarlas a rangos de direcciones IP, a OUs, tags… y con esto dejar configurado nuestro
entorno en base a nuestra necesidad.
15. Impresión
Para el variopinto mundo de impresoras que tiene cada organización, Citrix se adapta dando soluciones
siempre válidas. Si la organización dispone de impresoras locales en los puestos o impresoras de red,
sean del fabricante que sean podremos asignarlas a nuestros usuarios. Lo realizaremos mediante las
Directivas.
Con las impresoras de red, normalmente dispondremos de un servidor de impresión, este dispone de
los drivers necesarios, hará de cola de impresión y compartirá las impresoras. Tendremos dos opciones,
o bien instalar estos drivers a las máquinas VDA o utilizar el driver universal de Citrix. Personalmente
siempre que se pueda opto por la primera opción, ya que los drivers del fabricante tienen más opciones
e información que a veces el usuario necesita. Si utilizamos el driver universal los usuarios podrán
imprimir con los ajustes básicos de impresión sin problema alguno en cualquier impresora.
Si queremos usa impresoras locales que dispongan los puestos de los usuarios, esta gestión de drivers
en los VDA ya suele ser más complicada. Ya que, si el driver no existe en el VDA, podremos decidir si
queremos que instalen el driver de la impresora al conectarse (si es compatible), o si utilizar el driver
universal de Citrix.
Por último, otra opción que os da Citrix, es la posibilidad de montar (al menos) un servidor donde
desplegaremos Citrix Universal Print Server, normalmente será el mismo servidor de impresión. Esto
nos evitará el tener que instalar drivers de impresoras en las máquinas VDA, ya que al instalar el
agente VDA se instala el driver universal de Citrix, y éste se podrá habilitar sencillamente en una
Directiva. Donde tan sencillamente habilitaremos Universal Print Server e indicaremos que a la hora
de crear la impresora si no existiese el driver nativo, use el universal. Universal Print Server corre en
Windows Server 2012 R2 y 2016.
Escojamos el escenario que nos interese, configuraremos las Directivas de Impresión en Studio,
habilitaremos la creación automática de las impresoras del cliente o asignaremos impresoras de red,
decidiremos si permitiremos que instale su driver el usuario, utilice el nativo o el universal. Luego
estas directivas, como sabremos las podremos aplicar a usuarios específicos, a grupos de usuarios;
o dependiendo de la conexión, si es desde fuera de la organización a través de un NetScaler o por
rangos IP a delegaciones…
Si necesitamos profundizar, tenemos un documento oficial bastante interesante:
https://docs.citrix.com/es-es/citrix-virtual-apps-desktops/printing.html
16. Storefront
En Storefront crearemos al menos una Tienda o Store que de servicio a nuestra organización,
dependiendo de la complejidad de la organización, o si somos un holding de empresas y queremos
separar la forma de presentar los recursos de las apps o escritorios a nuestros usuarios.
Deberemos crear una Tienda especificando una URL cómoda para nuestros usuarios, habilitaremos
SSL con un certificado válido en IIS y podremos comenzar a definirlo. Para permitir un acceso remoto
y seguro a la organización desde Internet, daremos de alta nuestro Citrix NetScaler Gateway y
configuraremos las balizas para que StoreFront sepa el usuario si se encuentra dentro o fuera de la
organización.
Daremos visibilidad a la Tienda sobre nuestras infraestructuras de Citrix, agregaremos los Delivery
Controller de nuestros Sitios Citrix sean versión 7.x o anteriores a la 6.5 con XenApp. Si disponemos
de Citrix XenMobile también podremos unificarlo y publicar nuestras apps y desktops en él.
Podremos habilitar la experiencia de usuario unificada y mostrar un portal más intuitivo para los
usuarios, huyendo de diseños anteriores, sobre todo para el uso con dispositivos móviles.
Definiremos qué tipo de autenticación ofrecemos con StoreFront, por defecto validarán con su usuario
y contraseña del Directorio Activo, pero podremos añadir otros dominios así cómo si les permitimos
cambiar las contraseñas, o disponerles de un autoservicio de sus cuentas; donde podrán resetearse
la cuenta o contraseña si responden correctamente a unas preguntas. Algo interesante también puede
ser habilitar el PassThrough de credenciales, con esto conseguiremos que las credenciales donde
se logueó el usuario pasen al Citrix Receiver directamente, o si trabaja con navegador web. O si los
usuarios disponen de tarjetas inteligentes para loguearse en sus equipos, igualmente pueden ser
usadas para validarse en Citrix.
Dentro de cada Tienda dispondremos normalmente de un sitio web de StoreFront, en caso de querer
personalizar distinto cada sitio web, podremos crear tantos como nos interesen. Ya que intentaremos
customizar y hacer corporativo el portal para que el usuario se sienta identificado con el sito,
definiremos los colores corporativos y subiremos los logos. Decidiremos aquí si requeriremos que el
usuario disponga de Citrix Receiver instalado en local para el acceso a las aplicaciones o escritorios o
si le permitiremos acceso también mediante HTML5 y su navegador. Por supuesto podemos poner a
disposición del usuario unos enlaces para descargar Receiver si lo necesitase. Definiremos tiempos,
entre ellos, cuándo cerrar la sesión del usuario en StoreFront, ya que si pasados X minutos de
inactividad por seguridad deberemos cerrar el acceso a la organización. Podemos definir qué pasa
cuando se cierra esta sesión, o el usuario la cierra, si desconectar la conexión al VDA para continuar
en otro momento, o cerrar la sesión del usuario definitivamente en el VDA. Y finalmente podremos
indicar que vista dejar de forma predeterminada, que vean apps primero, o sus escritorios, o que les
arranque automáticamente el desktop al loguearse en StoreFront.
Si tenemos entornos con clientes antiguos de Citrix, podremos permitir y publicar una URL del servicio
para que puedan conectar, basados en PNA. Da un paseo por la consola y descubre más opciones
avanzadas.
Como inicialmente indicamos, si StoreFront se convierte en un servidor crítico en la infraestructura

podemos pensar en desplegar nuevos servidores, tanto para ofrecer esta alta disponibilidad como
balancear la carga de los usuarios. Crearemos Grupos de servidores, donde el servidor principal es el
que replicará su configuración al resto de servidores miembro, por tanto, en él configuramos StoreFront.
El balanceo sobre a qué servidor conectarnos podremos usar algo tan simple como un DNS Round
Robin, o configurar un NLB en Windows o mejor solución aún, optar por NetScaler y configurar Load
Balancing, que analizará la salud de cada StoreFront.
Un genial recurso a la hora de customizar el portal de StoreFront https://www.citrixguru.com/2016/03/08/

lab-ultimate-storefront-customization-guide/. En ese link podremos aprender a customizar totalmente
nuestro portal, sobrepasando las posibilidades que tenemos con Studio.
17. Optimización del OS VDA
La parte más importante sin lugar a dudas será la parte de optimizar los VDA, ya que serán los
puestos donde nuestros usuarios trabajarán. Deberán ser equipos prioritarios y con recursos, ayudará
el customizar el equipo y aligerar de carga no deseada. Más énfasis aún si serán aprovisionados
mediante MCS o Provisioning Services, cuanto más pequeña la imagen mejor, ya que se eleva
exponencialmente la necesidad de recursos cuántos más VDA dispongamos y más recursos estamos
desaprovechando.
Si los VDA son de tipo MV, deberemos tener en cuenta eliminarles el hardware sobrante como es
la unidad de CD, la disquetera, puertos serie… En los VDA con Windows, deberemos eliminar los
dispositivos ocultos en el administrador de dispositivos para que no se carguen.
Siempre recordaremos tener últimas versiones actualizadas para evitar posibles bugs, tanto del agente
VDA como las VMware Tools si se tuviesen.
Podremos utilizar la magnífica herramienta Citrix Optimizer para optimizar y mejorar el rendimiento del
equipo según las recomendaciones de Citrix. Aquí puedes ver cómo se usa: http://www.bujarra.com/
usando-citrix-optimizer
Debemos deshabilitar todos los servicios innecesarios, podremos hacerlo en la imagen base
directamente o mucho mejor, diseñar una GPO donde vamos a ir aplicando estas mejoras para luego
aplicarlas a las OU de VDAs.
Servicios que podemos deshabilitar en Windows 201x:
Application Layer Gateway Service HomeGroup Listener UPnP Device Host

Background Intelligent Transfer
HomeGroup Provider Volume Shadow Copy
Service
Microsoft Software Shadow Copy
BitLocker Drive Encryption Service Windows Backup
Provider
Block Level Backup Engine Service Offline Files Windows Color System
Windows Connect Now – Config
Bluetooth Support Service Optimize Drives
Registrar
Secure Socket Tunneling Protocol
Computer Browser Windows Defender Service
Service
Device Association Service Security Center Windows Error Reporting Service
Windows Media Player Network
Device Setup Manager Service Sensor Monitoring Service
Sharing Service
Diagnostic Policy Service Shell Hardware Detection Windows Update
Distributed Link Tracking Client SNMP Trap Service WLAN AutoConfig
Family Safety SSDP Discovery WWAN AutoConfig
Fax Superfetch
Function Discovery Resource
Telephony
Publication
Servicios que podemos deshabilitar en Windows 10:
Automáticos Manuales
Background
Intelligent AllJoyn Router Offline Files
Transfer Service
Device Application
Association Layer Gateway Optimize Drives
Service Service
BitLocker Drive
Diagnostic Policy
Encryption Retail Demo
Services
Service
Block Level Sensor
Diagnostic
Backup Engine Monitoring
Service Host
Service Service
Diagnostic Bluetooth Hands UPnP Device
System Host free Service Host Service
Windows Error
Diagnostics Bluetooth
Reporting
Tracking Service Support Service
Service
Function Windows Media
BranchCache
Discovery Player Network
Service
Provider Host Sharing
Function
Computer
Discovery Windows Update
Browser Service
Resource Publication
Home Group Encrypting File WLAN
Provider System Service AutoConfig
WWAN
Security Center Fax Service
AutoConfig
Shell Hardware
Home Group Xbox Live Auth
Detection
Listener Manager
Service
Internet Connection
SSDP Discovery Xbox Live Game
Sharing (ICS)
SuperFetch
Themes
Windows
Connect Now –
Config Registrar
Service
Windows Search

Tareas programadas a deshabilitar en Windows 201x:
AitAgent GadgetManager StartupAppTask

AnalyzeSystem HotStart SystemDataProviders
AutoWake KernelCeipTask UninstallDeviceTask
BfeOnServiceStartTypeChange MobilityManager UpdateLibrary
BthSQM ProgramDataUpdater Upload
ConfigNotification Proxy UPnPHostConfig
Consolidator RacTask UsbCeip
DiskDiagnosticDatacollector RegIdleBackup Windows Filtering
DiskDiagnosticResolver ResolutionHost WinSAT
FamilySafetyMonitor planned
FamilySafetyRefresh SessionAgent
Tareas programadas a deshabilitar en Windows 10:
Application Windows Defender \ Windows

Defrag \ ScheduledDefrag
Experience \ Appraiser Defender CacheMaintenance
Application
Windows Defender \ Windows
Experience \ FileHistory \ File History
Defender Cleanup
ProgramDataUpdater
AutoCHK \ Proxy Maintenance \ WinSAT
DefenderScheduled Scan
Customer Experience
Windows Defender \ Windows MemoryDiagnostic \
Improvement Program
DefenderVerification ProcessMemoryDiagnosticEvents
\Consolidator
Customer Experience
Windows Filtering Platform MemoryDiagnostic \
Improvement Program
\BfeOnServiceStartTypeChange RunFullMemoryDiagnostic
\KernelCeipTask
Customer Experience
Application Experience \ Power Efficiency Diagnostics \
Improvement Program
StartupAppTask AnalyzeSystem
\Uploader
Customer Experience
RecoveryEnvironment \
Improvement Program CHKDSK \ Proactive Scan
VerifyWinRE
\UsbCeip
Shell \ FamilySafetyMonitor Diagnosis \ Scheduled Registry \ RegIdleBackup
DiskDiagnostic \ Microsoft-
Shell \ FamilySafetyRefresh Windows- SystemRestore \ SR
DiskDiagnosticDataCollector
DiskDiagnostic \ Microsoft-
Windows- WDI \ ResolutionHost
Defender CacheMaintenance
DiskDiagnosticResolver
Todas estas tareas podemos eliminarlas con el siguiente script de PowerShell donde omitimos por
ejemplo el GotoAssist por si queremos que se actualice en background o la tarea que permite que
Outlook se minimice en la barra de tareas… ejemplo:
$schedule = New-Object -com Schedule.Service
$schedule.connect()
$tasks = $schedule.getfolder(“\”).gettasks(0)
foreach ($task in ($tasks | select Name)) {
if ($task -notmatch “G2MUpdateTask”){
$task2 = $task
if ($task2 -notmatch “outlook”){
SchTasks /Delete /TN $($task2.name) /f
} }
Limitaremos los visores de sucesos a 1028Kb y en la retención marcaremos que se sobrescriban. Así
como es posible que nos interese redireccionarlos a otro disco, lo tenemos en el registro, en: HKLM\
SYSTEM\CurrentControlSet\Services\Eventlog\NombreRegistro\.
Deshabilitaremos Windows Update y sus reinicios oportunos, además que Windows Update no busque
actualizaciones para los drivers de los dispositivos.
En las opciones avanzadas del sistema, en Rendimiento, estableceremos ‘Programas’ para mejorar
el rendimiento de la programación del procesador. Además, estableceremos los efectos visuales en
la opción para obtener el mejor rendimiento. También recordar que el plan de energía esté en alto
rendimiento, tanto en Windows como en las BIOS si trabajamos con equipos físicos.
Os dejo una tabla resumen con otras opciones interesantes, aún que Citrix Optimizer ya nos automatizará
gran parte de ellas:
Deshabilitar
powercfg -h off
hibernación
Deshabilitar
Data Execution bcdedit /set nx AlwaysOff
Prevention
Deshabilitar la
recuperación bcdedit /set recoveryenabled no
del sistema
Deshabilitar
HKEY_USERS\.DEFAULT\ControlPanel\Desktop
salvapantallas
“ScreenSaveActive”=dword: 00000000
predeterminado
Deshabilitar [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\
logon de W10 System]
animado “EnableFirstLogonAnimation”=dword:00000000
Deshabilitar
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Windows]
mensajes Hard
“ErrorMode”=dword:00000002
Error
Poner los
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\
efectos
VisualEffects]
visuales en
“VisualFXSetting”=dword:00000003
personalizado
Deshabilitar
mostrar el [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\
rectángulo Advanced]
de selección “ListviewAlphaSelect”=dword:00000000
translucido
Deshabilitar
mostrar
Advanced]
sombras bajo
“ListviewShadow”=dword:00000000
las ventanas
Deshabilitar
animar las
[HKEY_CURRENT_USER\ControlPanel\Desktop\WindowMetrics]
ventanas al
“MinAnimate”=”0”
minimizar y
maximizar
Deshabilitar las
animaciones
Advanced]
en la barra de
“TaskbarAnimations”=dword:00000000
tareas
Deshabilitar [HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM]
Peek “EnableAeroPeek”=dword:00000000
Deshabilitar
guardar las
vistas previas [HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM]
de miniaturas “AlwaysHibernateThumbnails”=dword:00000000
en la barra de
tareas
Deshabilitar
suavizar bordes [HKEY_CURRENT_USER \Control Panel\Desktop]
para las fuentes “FontSmoothing”=”0”
de pantalla
Deshabilitar el
[HKEY_CURRENT_USER \Control Panel\Desktop\]
resto de efectos
“UserPreferencesMask”=RegBin: “90,12,01,80”
visuales
Deshabilitar el
[HKEY_CURRENT_USER \Control Panel\Desktop]
parpadeo del
“CursorBlinkRate”=”-1″
ratón
Deshabilitar
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\InternetExplorer\Main]
asistente primer
“DisableFirstRunCustomize”=dword:00000001
uso del IE
Reducir el
tiempo para [HKEY_CURRENT_USER\ControlPanel\Desktop]
mostrar los “MenuShowDelay”, “0”
menús.
Aumentar el
tiempo de [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control]
espera de los “ServicesPipeTimeout”=dword:0x001d4c0
servicios
Deshabilitar
Last Access
Time Stamp [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\File System]
para evitar “NtfsDisableLastAccessUpdate”=dword:00000001
actualizar la
MFT
Disable Large [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BNNS\Parameters]
Send Offload “EnableOffload”=dword:00000000
Desabilitar la [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl]
creación de “CrashDumpEnabled”=dword:00000000
volcados de “LogEvent”=dword:00000000
memoria. “SendAlert”=dword:00000000
En entornos PVS además es recomendable generar las imágenes maestras con UEFI reemplazando
por la BIOS tradicional, el arranque será más rápido. Así como si optamos por generar los discos en
formato VHDX y formatearlos con ReFS v2, obtendremos mucho mayor rendimiento a la hora de
aprovisionar y crear las máquinas, así como a la hora de combinar discos desde los snapshots.
Si estamos usando Windows 10 como entrega, además, deberíamos eliminar todas las aplicaciones
que trae por defecto instaladas. Con ‘Get-ProvisionedAppXPackage -Online|Select DisplayName’
listaremos las aplicaciones instaladas y con ‘Get-AppxPackage -AllUsers | Remove-AppxPackage’ las
eliminaremos.
Si la máquina necesitase de un software agente Antivirus, especial atención a la manera de desplegarlo,

deberemos consultar las guías de cada fabricante para no afectar al rendimiento del entorno. Una
idea buena puede ser habilitar el antivirus de hipervisor VMware vShield para evitar repercutir en el
entorno con este tipo de soluciones antivirus tradicionales. Deberemos además crear las exclusiones
necesarias en cada tipo de máquina:
VDA Servidor
Archivos %userprofile%\AppData\Local\Temp\Citrix\HDXRTConnector\*\*.txt
%ProgramFiles%\Citrix\User Profile Manager\UserProfileManager.exe
%ProgramFiles%\Citrix\Virtual Desktop Agent\BrokerAgent.exe
%ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVD.exe (sólo con AppDisks)
Procesos
%ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVDSVC.exe (sólo con AppDisks)
%SystemRoot%\System32\spoolsv.exe
%SystemRoot%\System32\winlogon.exe
VDA Desktop
Archivos %userprofile%\AppData\Local\Temp\Citrix\HDXRTConnector\*\*.txt
%ProgramFiles%\Citrix\User Profile Manager\UserProfileManager.exe
%ProgramFiles%\Citrix\Virtual Desktop Agent\BrokerAgent.exe
%ProgramFiles%\Citrix\ICAService\picaSvc2.exe
%ProgramFiles%\Citrix\ICAService\CpSvc.exe
Procesos
%ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVD.exe (sólo con PvD y AppDisks)
%ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVDSVC.exe (sólo con PvD y AppDisks)
%SystemRoot%\System32\spoolsv.exe
%SystemRoot%\System32\winlogon.exe
Delivery Controller
%systemroot%\ServiceProfiles\NetworkService\HaDatabaseName.mdf
%systemroot%\ServiceProfiles\NetworkService\HaImportDatabaseName.mdf
Archivos
%systemroot%\ServiceProfiles\NetworkService\HaDatabaseName_log.ldf
%systemroot%\ServiceProfiles\NetworkService\HaImportDatabaseName_log.ldf
Directorios %programdata%\Citrix\Broker\Cache
%ProgramFiles%\Citrix\Broker\Service\BrokerService.exe
Procesos %ProgramFiles%\Citrix\Broker\Service\HighAvailabilityService.exe
%ProgramFiles%\Citrix\ConfigSync\ConfigSyncService.exe
StoreFront
%SystemRoot%\ServiceProfiles\NetworkService\AppData\Roaming
Archivos
\Citrix\SubscriptionsStore\**\PersistentDictionary.edb
%ProgramFiles%\Citrix\Receiver StoreFront\Services\SubscriptionsStoreService
\Citrix.DeliveryServices.SubscriptionsStore.ServiceHost.exe
Procesos
%ProgramFiles%\Citrix\Receiver StoreFront\Services\CredentialWallet
\Citrix.DeliveryServices.CredentialWallet.ServiceHost.exe
Servidor PVS
**\*.vhd
**\*.avhd
**\*.vhdx
**\*.avhdx
Archivos
%SystemRoot%\System32\drivers\CvhdBusP6.sys (Windows Server 2008 R2)
%SystemRoot%\System32\drivers\CVhdMp.sys (Windows Server 2012 R2)
%SystemRoot%\System32\drivers\CfsDep2.sys
%ProgramData%\Citrix\Provisioning Services\Tftpboot\ARDBP32.BIN
%ProgramFiles%\Citrix\Provisioning Services\BNTFTP.EXE
%ProgramFiles%\Citrix\Provisioning Services\PVSTSB.EXE
Procesos %ProgramFiles%\Citrix\Provisioning Services\StreamService.exe
%ProgramFiles%\Citrix\Provisioning Services\StreamProcess.exe
%ProgramFiles%\Citrix\Provisioning Services\soapserver.exe
Agente PVS (o Target Device)
**\*.vdiskcache
**\vdiskdif.vhdx
%SystemRoot%\System32\drivers\bnistack6.sys
Archivos
%SystemRoot%\System32\drivers\CfsDep2.sys
%SystemRoot%\System32\drivers\CVhdBusP6.sys
%SystemRoot%\System32\drivers\CVhdMp.sys
%ProgramFiles%\Citrix\PvsVm\Service\PvsVmAgent.exe
%ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVD.exe (sólo con PvD y AppDisks)
%ProgramFiles%\Citrix\Personal vDisk\BIN\CTXPVDSVC.exe (sólo con PvD y AppDisks)
Citrix Receiver
%userprofile%\AppData\Local\Temp\Citrix\RTMediaEngineSRV
Archivos
\MediaEngineSRVDebugLogs\*\*.txt
%programfiles(x86)%\Citrix\ICA Client\MediaEngineService.exe
%programfiles(x86)%\Citrix\ICA Client\CDViewer.exe
%programfiles(x86)%\Citrix\ICA Client\concentr.exe
Procesos %programfiles(x86)%\Citrix\ICA Client\wfica32.exe
%programfiles(x86)%\Citrix\ICA Client\AuthManager\AuthManSvr.exe
%programfiles(x86)%\Citrix\ICA Client\SelfServicePlugin\SelfService.exe
%programfiles(x86)%\Citrix\ICA Client\SelfServicePlugin\SelfServicePlugin.exe
Para finalizar, si necesitas la guía oficial de optimización de Windows 10, o para analizar detenidamente
con más detalle este tema, puedes echar un vistazo a: https://support.citrix.com/article/CTX216252
18. Upgrade
Una buena práctica para evitar problemas y bugs será siempre utilizar la última versión de Citrix
disponible; nos decantaremos opcionalmente por usar una versión LTSR, que es una versión estable y
con largo tiempo de soporte, pero quizá menos novedades de funcionalidad. No es arbitraria la manera
de actualizar nuestro sitio Citrix, y tras verificar que cumpliremos los requisitos de compatibilidad,
seguiremos un orden específico de actualización.
De manera muy resumida, previo a disponer de copias de seguridad de las BBDD de Citrix, las MVs
que proporcionan servicios y, como no, un snapshot. Comenzaremos por el primer componente,
StoreFront. deberemos actualizar el primer servidor de la granja y posteriormente el resto de servidores
del Grupo Storefront y replicar su configuración. Si disponemos Director instalado en una máquina
dedicada, será su turno. Realizaremos copia también de las plantillas VDA si no lo hemos hecho ya.
Actualizaríamos los servidores de Provisioning Services y a continuación las VDA y su agente de PVS.
Será momento ya de actualizar nuestro primer Delivery Controller (o único) y tras ello abrir la consola
Citrix Studio, deberemos actualizar el sitio de Citrix, y dependiendo el acceso que dispongamos a las
bases de datos, podremos actualizar directamente desde la consola el esquema, o proveer al DBA los
scripts para que haga el upgrade de las BBDD. Tras la actualización del sitio verificamos que todo el
funcionamiento es correcto. Si tenemos más Delivery Controllers procederemos a actualizarlos para
finalizar el proceso de upgrade.
19. Citrix Cloud
Como no, Citrix también provee soluciones cloud o hibridas en base a nuestra necesidad. Como hasta
ahora podemos disponer de nuestra infraestructura en nuestras instalaciones o externalizar el área que
nos interese. Dependerá de nuestro negocio y la manera de trabajo a la hora de diseñar el entorno,
así como de su crecimiento y los recursos que dispongamos On Premise. Analizaremos los costes
y requisitos que nos suponga cada escenario. Obviamente la parte crítica en estos escenarios es la
conectividad al sitio cloud, donde el ancho de banda y la latencia de acceso tiene su importancia, ya
que los usuarios, desde los VDA, deben tener acceso inmediato a los recursos con los que trabajen.
Podemos utilizar los servicios nube públicos como son Citrix CloudPlatform, Microsoft Azure o Amazon
EC2, así como nubes privadas que ofrecen los proveedores de servicios, la idea y resultado final debe
ser el mismo, simplificar la entrega unificando recursos. Todo ello, gracias a Citrix Cloud Connector,
que será el conector que interconecta nuestros recursos con las distintas nubes. Se despliega en cada
sitio que disponga recursos, mediante él dispondremos de una conexión unificada y segura, totalmente
transparente para nuestros usuarios que simplemente se limitarán a trabajar de igual manera.
Puede que nos interese externalizar inicialmente la parte de infraestructura, donde albergaremos y
ejecutaremos nuestras máquinas VDA en nube, suele ser interesante en entornos donde la carga es
indeterminada y variable, donde tengamos que dar recursos a usuarios en base a su demanda, donde
hoy tenemos pocos usuarios y mañana miles de ellos. Sería buena idea albergar parte de los VDA y
generar tantos como necesitemos arriba, ideal en nubes de pago por uso. También conocido como
Cloud Hosted XenDesktop.
Citrix Workspace Control plantea otra posibilidad, y no es más que la de subir al cloud la capa de
control, que igualmente la gestionaremos de manera centralizada desde la nube. Con idea de mantener
los recursos que necesiten los usuarios junto a las máquinas VDA, normalmente en entornos donde
la información no puede salir de la organización y además queremos externalizar la infraestructura
necesaria para su funcionamiento.
Y obviamente, cómo no, podremos externalizar todo lo necesario en un Citrix Cloud Provider y confiar
en él todos nuestros recursos. Se ejecutarán y almacenarán fuera de nuestra organización, donde ya
nada dependerá de nuestra infraestructura.
20. Fundamentos sobre vSphere
En este capítulo de Citrix hemos visto a modo global ciertas mejoras en configuraciones que podemos
aplicar para mejorar tu entorno; ahora, en este apartado, intentaremos agrupar todas las consideraciones
que debemos tener en cuenta a la hora de virtualizar nuestra plataforma Citrix bajo VMware vSphere.
A lo largo del libro habrás ido conociendo trucos y optimizaciones de la plataforma virtual que podrás
aplicar como norma general en tu entorno Citrix.
Quizá de toda la infraestructura de Citrix, las máquinas VDA deben ser especialmente las MVs con
mayores y mejores recursos. De sobra queda indicar que debemos utilizar procesadores de última
generación y evitar siempre que podamos CPU Over-Commitment. Intentando no superar los cores
que ofrece un procesador físico por vCPUs en las MVs. Es importante que las máquinas de Citrix se
ejecuten desde el mismo nodo NUMA, con objeto de no ralentizar accesos a CPU o RAM, por tanto,
definamos las MVs que necesitemos con los cores necesarios, pero sin pasarnos. Sobre todo, en las
máquinas VDA y servidores PVS. Valores a revisar serán el CPU Ready y CPU Wait.
Para optimizar memoria RAM, una buena idea será ejecutar las MVs con el mismo SO sobre los mismos
hosts, la tecnología de VMware, Transparent Memory Page Sharing será más efectiva, ahorrando
memoria física en los nodos. Al igual que con la CPU deberemos tener cuidado a la hora de definir
la RAM de cada MV evitando siempre que podamos pasarnos de los recursos físicos de cada host.
Obviamente, si vemos uso de memoria Swap o Balloning lo corregiremos.
Al igual que para el acceso a disco, deberemos proporcionar almacenamiento rápido, siempre que se
pueda, los VDA y sus usuarios agradecerán disco sólido. Buenas prácticas será disponer de multipathing
configurado en los hosts para su acceso como disponer Storage DRS habilitado en nuestros clústeres
de datastores para evitar saturar los datastores con IOs o latencias altas. En entornos grandes,
deberemos calcular las IOPS necesarias en base a los recursos que vamos a necesitar. Para discos
de datos, como son por ejemplo los almacenes de PVS es buena idea utilizar el adaptador de disco
VMware Paravirtual SCSI o PVSCSI. Y como no, en entornos de producción, siempre utilizaremos
discos thick.
En cuanto a la red, no es necesario hacer hincapié, ya que este recurso es raramente saturado. Una
buena práctica será separar los tráficos de red de las MVs de los usuarios y MVs de infraestructura,
segmentándolos en diferentes vSwitch o con VLANs. Así como disponer NIC teaming en los host para
evitar caídas y balancear tráficos de red. Siempre que podamos, las MVs deberán utilizar el adaptador
optimizado de red VMXNET 3.
Recordar disponer de las VMware Tools instaladas y actualizadas, a la hora de instalarlas en las
máquinas VDA tendremos especial cuidado en no instalar los Shared Folders. Con todo esto, nuestro
entorno virtual no debería tener problemas de acceso a los recursos. Las máquinas virtuales deberán
estar protegidas por clústers con HA habilitado, así como DRS para balancear la carga de los recursos
entre los hosts del clúster. Prestar atención en quizá la necesidad de definición de grupos y reglas
de afinidad y anti-afinidad, ya que las MVs que prestan los mismos recursos se deberían ejecutar en
distintos nodos para garantizar tolerancia a fallos. Remarcar que las VDA son máquinas que quizá
debamos subir sus Shares para un acceso con mayor prioridad que el resto de MVs a los recursos de
CPU, RAM o disco. Dependiendo del entorno podamos reservar recursos mínimos a las MVs de Citrix,
todo ello como ya sabemos, podremos realizarlo de manera individual por MV o mediante Resource
Pools.
21. Links interesantes
Instalación de los componentes de Citrix Virtual Apps and Desktops:

http://www.bujarra.com/instalacion-de-xenapp-7-5/
Configurando alta disponibilidad con Citrix StoreFront:

http://www.bujarra.com/grupo-de-servidores-citrix-storefront-para-ha/
Configuración de balanceo de StoreFront con Citrix NetScaler:

http://www.bujarra.com/load-balancing-de-storefront-con-citrix-netscaler/
Configuración de alta disponibilidad con Citrix NetScaler:

http://www.bujarra.com/alta-disponibilidad-con-citrix-netscaler/
Instalación, configuración y despliegue de imágenes con Citrix Provisioning Services:

http://www.bujarra.com/citrix-provisioning-services-7-1-con-citrix-xendesktop-7-1-parte-1/
Configurando alta disponibilidad con Citrix Provisioning Services:

http://www.bujarra.com/citrix-provisioning-en-high-availability/
Configuración de balanceo de Citrix Provisioning Services con Citrix NetScaler:

http://www.bujarra.com/load-balancing-de-provisioning-con-citrix-netscaler/
Actualizando una imagen VDA maestra con Citrix Provisioning Services:

http://www.bujarra.com/actualizando-un-vdisk-en-citrix-provisioning/
Instalar Citrix VDA en Linux:

https://www.maquinasvirtuales.eu/instalar-citrix-vda-en-servidor-linux/
Cambiando el idioma del portal StoreFront:

http://www.bujarra.com/cambiando-el-idioma-de-citrix-storefront-a-euskera-catalan/
Personalizando mensajes en el portal StoreFront:

http://www.bujarra.com/personalizando-mensajes-en-citrix-storefront/
Personalizando los iconos de los desktops:

http://www.bujarra.com/personalizando-iconos-escritorios-virtuales-aplicaciones-contenido-citrix-
xenapp-xendesktop/
Publicando contenidos:
http://www.bujarra.com/publicando-contenidos-con-citrix-xenapp/
Instalando y configurando Citrix Universal Print Server:

https://www.maquinasvirtuales.eu/instalacion-y-configuracion-citrix-universal-printer-server/
Configurando SQL Mirroring con Witness:

http://www.bujarra.com/xendesktop-sql-mirroring-con-witness/
Grabación de sesiones de los usuarios:

http://www.bujarra.com/session-recording-en-citrix-xenapp-7-6-2/
Auto configuración de Citrix Receiver con el dominio de correo:

http://www.bujarra.com/configuracion-de-citrix-receiver-mediante-el-correo-electronico/
Auto configuración de Citrix Receiver en dispositivos móviles:

http://www.bujarra.com/citrix-mobile-receiver-setup-url-generator/
Raspberry Pi como thinclient para acceso a Citrix:

http://www.bujarra.com/uso-de-raspberry-pi-como-cliente-ligero-soportado-en-citrix/
Hardening en VDAs de Citrix:

https://www.maquinasvirtuales.eu/hardening-citrix-xenapp/
Utilizando Citrix AppDisk:

http://www.bujarra.com/utilizando-citrix-appdisk/
Configuración de vGPU en VMware para Citrix:

https://www.maquinasvirtuales.eu/configuracion-vgpu-en-vmware-6-para-citrix-xenapp/
Auto servicio de cuentas con Citrix Self Service:

http://www.bujarra.com/citrix-self-service-password-reset-autoservicio-de-restablecimiento-de-
contrasenas-y-desbloqueo-de-cuentas/
Personalizar el menú inicio a la hora de entregar desktops:

https://www.maquinasvirtuales.eu/personalizar-menu-inicio-en-una-template-desktop/
Integrando y publicando apps en desktops Citrix:

http://www.bujarra.com/publicando-aplicaciones-de-citrix-xendesktop-a-citrix-xendesktop/
Uso de PowerShell para administrar entornos Citrix:

https://www.maquinasvirtuales.eu/comandos-powershell-administracion-citrix/
Uso de Citrix Health Assistant para chequear la salud del VDA:

https://www.maquinasvirtuales.eu/citrix-health-assistant-chequear-vda/
Citrix Virtual Desktop Handbook 7.6 LTSR

https://support.citrix.com/article/CTX139331
Citrix Virtual Apps and Desktops Security Guidance

https://docs.citrix.com/en-us/xenapp-and-xendesktop/downloads/getting-started-with-citrix-xenapp-
xendesktop-security.pdf
System Hardening Guidance for XenApp and XenDesktop

https://www.citrix.com/content/dam/citrix/en_us/documents/products-solutions/system-hardening-for-
xenapp-and-xendesktop.pdf
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 14
vRealize Orchestrator
Federico Cinalli
Capítulo 14 - vRealize Orchestrator Federico Cinalli
1. Introducción
vRealize Orchestrator o vRO es el gran desconocido en la numerosa familia de productos de VMware.

Se trata de una herramienta de orquestación con interface gráfico, muy simple de utilizar.
Lo mejor de todo es que si disponemos de licencia de vCenter entonces también contamos con la
licencia de vRealize Orchestrator. ¿Simple verdad?
El spin off de vRO era VS-O (Virtual Service Orchestrator) desarrollado por una compañía suiza
llamada Dunes. En 2007 VMware compró Dunes y rebautizó VS-O como vCenter Orchestrator o vCO
introduciéndolo como parte de la Suite vSphere 4.0.
Seguramente muchos se acuerdan de aquel misterioso icono naranja que, en principio, no parecía
aportar mucha funcionalidad.
vRealize Orchestrator empezó a conocerse un poco más de la mano de vCAC o vCloud Automation
Center 5.x/6.x. la cual luego pasaría a llamarse vRealize Automation.
vRealize Orchestrator es el compañero perfecto de vRA. vRealize Orchestrator puede trabajar con
o sin vRA, pero vRA tiene como requerimiento una instancia de vRealize Orchestrator para poder
funcionar.
Como se mencionó anteriormente, el Appliance de vRO consume muy pocos recursos y, en entornos
de producción, es posible configurarlo en modo Cluster para ofrecer alta disponibilidad. Desde la
versión 7.3 de vRO podemos utilizar la base de datos embebida para dar soporte al servicio de Cluster
cuando anteriormente esta configuración requería una base de datos SQL Server externa.
Existen dos formas diferentes de desplegar vRO. Una es utilizar la instancia embebida que incluye el
Appliance de vRA. La segunda, y normalmente la más utilizada, es instalando el propio Appliance de
vRealize Orchestrator de forma independiente.
Imagen OVA de la versión 7.5.0
2. Casos de Uso de vRealize Orchestrator
Tal como comentamos anteriormente, vRealize Orchestrator es el gran desconocido. Básicamente

muchos saben que, en español, vRO es un Orquestador. ¿Pero realmente cuáles son los casos de
uso? Se sabe que el potencial es enorme, aunque tal vez nos falten ejemplos un poco mas concretos
de para qué normalmente podríamos utilizar vRO.
vRealize Orchestrator es un gran pulpo que conecta con prácticamente todos los tipos de recursos y
servicios. Hay conexiones nativas a través de los Plugins que utilizan API. Y hay otras que requieren
conectarse a través de comodines como puede ser SSH, REST API o incluso Powershell.
Integración de vRO en un entorno con vRA y vCenter
Hoy en día el principal caso de uso de vRO es dar servicio a vRealize Automation tanto para los
Blueprints tipo XaaS (lo que sea como servicio), las subscripciones de Event Broker y también lo que
se conoce como Resource Actions. Estos tres tipos de servicios de vRA están respaldados por uno o
más Workflows de vRO.
Extensibilidad de vRO con otros productos vía Powershell
También es posible utilizar vRealize Orchestrator sin vRealize Automation. En ese caso perderíamos el
amistoso interface de usuario, el sistema de autenticación integrado con Identity Manager, control de
costos y el sistema de aprobaciones que aporta vRA.
Para este último enfoque hablaríamos de procedimientos orquestados gestionados únicamente desde
el área de sistemas.
Entre las diferentes tareas que se pueden realizar están la configuración en masa de parámetros en
recursos de infraestructura como pueden ser Hosts y VMs.
Integración con soluciones complementarias como pueden ser Ansible, Puppet y Chef por mencionar
algunas.
Procedimientos orquestados como el alta de un usuario con su cuenta en Active Directory, su buzón
y cuenta en Office 365, su escritorio de XenApp bajo demanda, creación de estructura de carpetas y
asignación correspondiente de permisos y envío de mail con PDF adjunto con instrucciones de uso de
los sistemas de TI.
Automatización de altas de clientes y/o usuarios con sus correspondientes recursos como pueden ser
aplicaciones multi maquina, reglas de firewall, balanceadores, clusters, VPNs, etc.
En el caso de vRA vamos a poder conectar con infinidad de recursos e interconectar, por ejemplo,
servicios de CMDB como Service Now, sistemas de control de costo, soluciones de Backup/DR, IPAMs
y demás como parte de una única petición en el catalogo.
Como vemos las opciones son infinitas.
Bienvenidos al apasionante mundo de vRealize Orchestrator.
3. Configuración y Consolas
La instalación del Appliance de vRO es simple, siguiente-siguiente. Lamentablemente está fuera del
alcance del capítulo pero no es más que configurar parámetros como Contraseña Root, Hostname, IP,
DNS, Gateway, Red, Datastore y Cluster.
Opciones de configuración del Appliance de vRO
Una vez que finalizamos el despliegue del Appliance veremos lo siguiente en la consola de la VM:
Vista de consola de vRO
Como podemos observar existen diferentes consolas en vRealize Orchestrator. A la primera que
deberíamos acceder sería el Appliance Configuration a través de la IP o el nombre de la VM utilizando
https y el puerto 5480.
¿Qué vamos a verificar o configurar en la Consola? Configuraciones como Cluster, cambio de contraseña
de root, parámetros de Red, NTP, verificar algún Parche o Actualización disponible, habilitar el acceso
SSH o simplemente reiniciar o apagar el Appliance.
Vista de la Consola del Appliance de vRO
Lo siguiente a configurar será el Control Center. Para acceder abriremos una instancia del navegador
utilizando https://nombre-o-ip:8283/vco-controlcenter.
TIP: Si una vez desplegado vRO no abre la Web del Control Center, entonces ejecutaremos vía SSH
el siguiente comando -> service vco-configurator restart
Vista del Control Center
Como parte de la configuración inicial tendremos que definir el proveedor del sistema de autenticación
a utilizar. Las dos opciones son: vSphere SSO y vRA Identity Manager.
Configuración del proveedor de autenticación
Aquí no será muy difícil decidirse por una u otra opción. Si estamos desplegando vRO como parte de
vRealize Automation, entonces utilizaremos vRA IM (Identity Manager). Y en el caso de una instalación
simple para orquestar principalmente soluciones en vSphere, entonces utilizaremos Single Sign On.
Otra configuración que utilizaremos frecuentemente en el Control Center será la de gestión de

certificados. Existen varios Plugins que requieren la importación previa de certificados digitales antes
de poder ejecutar correctamente un Workflow.
La buena noticia es que es ridículamente simple importar un certificado como podemos ver en la
siguiente imagen. Tan solo debemos introducir la URL del recurso que utiliza el certificado o bien
importar el fichero PEM.
Importando Certificados en vRealize Orchestrator
La configuración de Logs también la definiremos a través de la consola del Control Center. Por un lado,
el nivel de Logs que deseamos registrar y almacenar, y por el otro el servidor que utilizaremos para
almacenar y gestionar los eventos y Logs.
Configuración de Logs en vRO
Consideremos una buena práctica reenviar los Logs a un sistema centralizado de Almacenamiento,
Indexación y Gestión de Logs como podría ser vRealize Log Insight.
Configuración de la integración de vRO con un Syslog externo
Los Plugins en vRealize Orchestrator nos ofrecen integración con sistemas externos como Powershell,
NSX, AMQP, REST, sistemas que utilizan SSH, Active Directory, vCenter y varios otros.
Por defecto con la instalación tenemos instalados varios Plugins como podemos ver en la imagen:
Algunos de los Plugins que están instalados por defecto en vRO
Cada vez son más las empresas que desarrollan sus propios Plugins para ofrecer un valor agregado
para diferentes tareas. Podremos encontrar Plugins de vRO en las webs de los fabricantes, pero el sitio
por excelencia es VMware Solutions Exchange.
Es posible filtrar por Producto (vRealize Orchestrator) y tipo de contenido para encontrar tanto Plugins
como incluso también Workflows.
Vista de VMware Solutions Exchange
La pregunta que corresponde ahora es: ¿Cómo podemos instalar nuevos Plugins o actualizar alguno
de los existentes? Una vez descargado el Plugin utilizaremos Control Center para instalarlos o
actualizarlos.
Opción del Control Center para subir Plugins
Llegados a este punto debemos repasar. Instalamos el Appliance definiendo los parámetros iniciales
de Red. Validamos la configuración inicial en la consola del Appliance accediendo a través del puerto
5480. Opciones como NTP y Zona horaria (fundamental en Orchestrator para resolución de problemas)
se definen en la consola del Appliance.
Utilizando el Control Center definimos el proveedor de autenticación, configuramos los Logs y los
integramos con nuestro syslog. También importamos los certificados necesarios (aunque esto puede
hacerse en cualquier momento) y pudimos ver cómo instalar un nuevo Plugin.
El siguiente Mind Map puede resultar útil para resumir las diferentes consolas y sus principales
funcionalidades.
Opciones resumidas de las diferentes Consolas de vRO
Ahora, podemos decir que nuestro vRO está listo para comenzar a trabajar con Workflows. ¡Casi listo!
Tenemos que vincular las soluciones con las que queremos trabajar en el inventario de Orchestrator
y para eso necesitamos movernos de herramienta, deberíamos pasarnos al Cliente de vRealize
Orchestrator, pero antes es necesario comprender conceptos fundamentales en vRealize Orchestrator.
4. Conceptos de vRealize Orchestrator
Antes de avanzar con temas mas técnicos veamos primero de forma simple algunos de los nombres y
conceptos que vamos a necesitar comprender para utilizar la herramienta.
Workflow: El Workflow es la esencia de Orchestrator. Es aquí donde definimos lo que queremos

ejecutar, en qué orden, con qué parámetros, basado en qué dependencias o condiciones, hacer
llamadas a otros sistemas y un largo etcétera.
Endpoint: Los Endpoints nos permiten ejecutar una acción sobre un determinado recurso u objeto.
Prácticamente no tiene sentido ejecutar Workflows sin Endpoints. Como ejemplo podemos mencionar
un Endpoint de vCenter, host SSH, host API, DC de Directorio Activo, F5, NSX, Puppet o Infoblox entre
otros.
Acción: Una acción es en vRO lo más parecido a una función ya que se trata de una ejecución simple,
de una única tarea que devuelve un valor. El valor del resultado de la Acción puede ser un valor
boolean, un número, una tarea o un objeto, por mencionar algunos ejemplos.
Recurso: En vRealize Orchestrator es posible crear una lista de Recursos que podemos consultar
desde un Workflow. Un ejemplo de Recurso puede ser un fichero de texto, un documento PDF o una
configuración almacenada.
Configuration Element: Un elemento de configuración o Configuration Element nos permite

almacenar Atributos por fuera del ámbito de un Workflow. Aquí podríamos tener predefinidos valores
como una instancia en concreta de vCenter, credenciales o bien atributos que utilizaremos como parte
de un Workflow. Los valores estarán predefinidos e incluso es posible actualizarlos como parte de la
ejecución del Workflow.
Configuration Element sin valores predefinidos
Paquete: Un paquete es un conjunto de objetos de vRealize Orchestrator. En un paquete podremos

encontrar Workflows, Actions, Configuration Elements y Recursos. Normalmente utilizamos paquetes
de vRO para importar o exportar uno o multiples Workflows y todas sus dependencias, desde una
instancia de vRO a otra.
Vista de la opción Importar Paquete en vRO
Elemento: Un Workflow Element o elemento de flujo de trabajo es un componente del propio Workflow
que cumplirá una función determinada. Un Workflow Element puede ser un Action, un Scriptable Task,
un elemento For Each, una llamada síncrona o asíncrona a otro Workflow o un elemento Log por
mencionar algunos.
Ejemplo de un Workflow con 5 Workflow Elements
Parametro: Un Parametro es un valor, una variable, de un determinado tipo como puede ser Texto
(String), Numero (Number), una variable verdadero/falso (boolean) o incluso un objeto de un Endpoint
como una Unidad Organizativa de una instancia de Directorio Activo.
Existen Parametros de entrada (Input Parameters) y Parametros de salida (Output Parameters). Los
Input Parameters aparecen ni bien ejecutamos un Workflow para que definamos su valor o variable.
Listado de dos Input Parameters de un Workflow
Vista de los Input Parameters al ejecutar el Workflow
Atributo: Un Attribute es un Parámetro que está predefinido o se define durante la ejecución del
Workflow. Si el Atributo está predefinido podríamos considerarlo una constante.
Se utiliza también un atributo para pasar variables entre Workflow Elements durante la ejecución del
Workflow. No es posible pasar una variable de forma directa entre Workflow Elements.
Objeto: Cuando instalamos un Plugin se define una lista de Objetos y las relaciones o dependencias
entre sí. También se suelen incluir junto con el Plugin carpetas con Workflows y frecuentemente Actions.
Como ejemplo podemos decir que un Objeto del Plugin de Active Directory es un Usuario. Para ejecutar
un Workflow o una Acción que trabaja con ese tipo de Objeto deberemos previamente configurar el
Endpoint de ese Plugin con al menos una instancia.
Ejemplo de un Objeto Host que corresponde a una instancia de vCenter
5. El Cliente de vRealize Orchestrator
El Cliente de vRO está basado en Java. Sí…Java. VMware está trabajando en un nuevo cliente llamado
Operations Client (ya disponible en vRO 7.5) basado en HTML v5 pero, al igual que pasó con vSphere
Client en 6.5, está muy (pero muy) limitado en cuanto a funcionalidades a la fecha en que se escribió
este capítulo del libro. No obstante, sabemos que ése es el camino.
Desde la web de vRO http://ip-o-nombreAppliance:8281/vco tenemos acceso al cliente de vRO.

También es posible descargarlo directamente.
Cliente de vRealize Orchestrator
Es posible instalar el cliente de vRO o bien simplemente hacer click en el enlace.
Recordemos que a este punto de la configuración ya tenemos pre-definido el tipo de autenticación

(vSphere SSO o vRA Identity Manager).
Ahora es cuando debemos presentar las credenciales correspondientes para acceder al Cliente de
vRO.
El cliente de vRO tiene tres modos de trabajo que son:
• Administración: El modo Administración permite visualizar los Endpoints y también Importar y

Exportar paquetes de vRO.
• Run: En modo Run o Ejecución seremos capaces de ejecutar Workflows y visualizar objetos del
Inventario.
• Diseño: El modo Diseño es el más interesante con diferencia ya que podremos crear, editar y
ejecutar Workflows a la vez que será posible importar y exportar tanto Workflows como también
Paquetes.
Selección del modo de ejecución del vRO Client
Una vez que seleccionamos el modo de trabajo, normalmente Design, tenemos delante nuestro un
mundo de posibilidades. Lo primero que deberíamos hacer sería agregar las diferentes instancias de
componentes a nuestro inventario o, dicho de otra forma, configurar los Endpoints para tener acceso
a Objetos.
Como ejemplo podemos decir que si pretendemos ejecutar Workflows para cualquier tipo de tarea en
vRealize Automation entonces tendremos que agregar nuestro vRA y su correspondiente IaaS como
Endpoint del vRealize Orchestrator.
Mismo procedimiento para recursos como Active Directory, Powershell, Ansible, NSX, Host API,
Puppet, vCenter, etc, etc.
Naturalmente que la pregunta es: ¿Cómo puedo agregar un recurso al inventario de mi vRO? La
respuesta es muy simple. Ejecutando un Workflow.
Por defecto, en la librería de Workflows, disponemos de elementos predefinidos que nos permitirán
agregar un recurso a modo de Endpoint en nuestro inventario.
Workflow para agregar una instancia de vCenter al Inventario
¿De qué depende que ese Workflow esté disponible en nuestra biblioteca? Son los Plugins los que
agregan carpetas de Workflows en la librería (además de las que creamos nosotros mismos). Esos
Workflows normalmente están disponibles en una carpeta llamada Configuration y son lo que permite
agregar un recurso a nuestro Inventario.
Workflow que agrega una instancia de vCenter al Inventario de vRO
El ejecutar un Workflow veremos un elemento llamado Token que nos indica si la ejecución del Workflow
finalizó correctamente o con un error. Por cada ejecución de Workflow tendremos un Token.
Workflow ejecutado correctamente
Workflow finalizado con un error
Una vez que tengamos un recurso agregado al Inventario ya seremos capaces de ejecutar un Workflow
apuntando a uno o varios objetos de una instancia concreta del Inventario.
Instancia de vCenter en el Inventario de vRO
Veamos un ejemplo: Necesitamos automatizar el despliegue de una maquina virtual utilizando Linked
Clone en un vCenter en concreto. Como parte del proceso de ejecución del Workflow debemos definir
un Input Parameter que, como se aprecia en la siguiente imagen, es un Snapshot de una VM que
corresponde a una instancia de vCenter. Al tener nuestro vCenter en el Inventario ya somos capaces
de seleccionar el Snapshot y proceder con la ejecución del Workflow.
Seleccionando un objeto de una instancia de vCenter del Inventario
6. Parametros, Atributos y Configuration Elements
Si realmente estamos interesados en comprender cómo funciona un Workflow en vRealize Orchestrator,

entonces es ahora cuando debemos aplicar todos los sentidos en este apartado.
En el supuesto caso que nunca hayamos trabajado con Workflows de vRealize Orchestrator, entonces
estamos hablando que este apartado debería ser leído, al menos, un par de veces debido a que
contiene conceptos extremadamente importantes. No estamos diciendo que sea complicado, porque
no lo es, pero sí que existen una cantidad importante de reglas que requieren ser comprendidas para
entender las relaciones y el flujo de variables y constantes en un Workflow.
Existen infinidad de Workflows, desde los simples, los medianamente complejos y los extremadamente
complejos. La inmensa mayoría de los Workflows, incluyendo los más simples, requieren que aportemos
algún tipo de dato o variable, ya sea un objeto, una o varias variables en formato texto, números, etc,
etc. A eso le llamamos Input Parameter y durante la ejecución de un Workflow serán tratadas como
variables.
Con el fin de solicitar la menor cantidad de información posible creando una mejor experiencia hacia
el que ejecute el Workflow, solemos predefinir ciertas variables como podría ser el número de virtual
cores que tendrá una VM.
Otro valor predefinido, o constante, podría ser una instancia concreta de vCenter, una carpeta de
maquina virtual, la versión de Hardware virtual o incluso el tipo de direccionamiento a utilizar, como
DHCP.
La forma de predefinir esas constantes normalmente la gestionamos con lo que llamamos Atributos.
Aunque también es posible hacer lo propio en ciertas situaciones recurriendo a los Configuration
Elements, pero eso lo veremos mas adelante.
Cada parámetro y atributo debe estar asociado a un tipo de dato.
Veamos los tipos de datos mas utilizados:
String: Texto
Number: Número
Boolean: Verdadero o falso
Date: Fecha y hora
Array: colección de datos (ejemplo: VMs con Snapshots). Puede ser colecciones de texto, números,
objetos, etc.
Lista de valores en un Array de texto
Configuration element: Atributos definidos a nivel de vRO que pueden ser consultados desde
múltiples Workflows.
Objeto: Elementos definidos por un Plugin que comienzan por un identificador del Plugin y dos puntos.
Ejemplo: AD:User / VC:VirtualMachineFolder
Lista de tipos de datos de vCenter
Al igual que un cuento, un Workflow debe tener un inicio, un desarrollo y un final (aunque no siempre
sea satisfactorio). Al finalizar el Workflow por lo general vamos a entregar una variable a modo de
resultado. Esa variable será de tipo número, texto, boolean o el resultado de la ejecución de una tarea.
A este resultado le llamaremos Output Parameter.
Veamos a continuación un esquema básico de un Workflow con dos Input Parameters, dos Atributos y
un Output Parameter trabajando con un par de Workflow Elements.
Ejemplo abstracto del flujo de Parámetros y Atributos en un Workflow
En la imagen anterior el flujo comienza cuando el usuario o administrador que ejecuta el Workflow
debe definir tanto el Parametro 1 como el Parametro 2.
A continuación se ejecuta el Workflow Element 1 tomando como Parámetros de entrada el Input

Parameter 2 y el Attribute 1 cuyo valor o constante fue definido como parte del diseño del Workflow.
Como resultado de la ejecución del flujo, el Workflow Element 1 define la variable del Attribute 2.
Aclaración: Los Atributos pueden estar definidos como constantes o variables pero nunca serán
definidos por el usuario que ejecuta el Workflow. Se definen únicamente a nivel de diseño o bien
durante la ejecución del Workflow.
La ejecución del Workflow continúa ahora con el Workflow Element 2 entregando como variable de
entrada al elemento el Input Parameter 1 y el Attribute 2 (valor previamente definido por el Workflow
Element 1).
El resultado de la ejecución del flujo del Workflow Element 2 va a establecer el Output Parameter tanto
del Workflow Element 2 como del propio Workflow.
Más adelante veremos un ejemplo similar sobre un Workflow real pero antes debemos aclarar ciertas
reglas de funcionamiento para una mejor comprensión.
Reglas de flujo de Parámetros y Atributos en un Workflow:
• Las variables de Parámetros de entrada (Input Parameters) se definen cada vez que se ejecuta el
Workflow
• Los Atributos pueden estar definidos como constantes o variables pero nunca serán definidos por
el usuario que ejecuta el Workflow
• Los valores de los Atributos únicamente se definen a nivel de diseño o bien durante la ejecución
del Workflow
• No es posible transferir variables entre Workflow Elements, es por eso que utilizamos Atributos
como elementos de intercambio
• Los valores predefinidos de Atributos se mantienen cada vez que se ejecuta un Workflow y pueden
modificarse las veces que necesitemos como parte del diseño o actualización del mismo. Esto
funciona como una constante.
• Normalmente el último Workflow Element es el que define el Output Parameter
• Un Output Parameter puede ser utilizado como Input Parameter en otro Workflow. Eso aplica
cuando, desde un Workflow, llamamos a la ejecución de otro Workflow.
• Es posible proteger el valor de un Atributo ante modificaciones
Vista de Atributos protegidos y sin proteger contra cambios
Diferencia entre Workflow Input Parameter y Workflow Element Input Parameter
Si bien los nombres son prácticamente iguales, estamos haciendo referencia a parametros en diferentes
ámbitos, aunque deberán estar vinculados entre sí.
Como parte del desarrollo del Workflow vamos a vincular el o los Input Parameters del Workflow con
el o los Input Parameter del Workflow Element.
Partamos de la base que la gran mayoría de Workflows necesitan variables para funcionar, y ya hemos
comentado que esas variables las definimos a través de los Input Parameters.
Supongamos que nuestro Workflow va a crear un usuario asignándole automáticamente una contraseña.
Los datos que necesitaríamos podrían ser:
Input Parameter 1: Nombre del Usuario
Input Parameter 2: Complejidad de contraseña? (Si/No)
Atributo 1: Contraseña
Nuestro Workflow podría tener un Workflow Element 1 que genere automáticamente la contraseña,
basado en el Input Parameter 2 que define si la contraseña deberá tener caracteres especiales o no a
través de una variable tipo boolean. El resultado del Workflow Element 1 definirá el valor del Atributo 1
que será la variable de la contraseña generada.
El segundo Workflow Element utilizará el Input Parameter 1 (nombre de usuario) para crear el usuario
y el valor del Atributo 1 para asignarle la contraseña.
Esquema Parametros y Atributos
Con este ejemplo podemos ver que el Workflow pedirá todos los Input Parameters necesarios para
“entregar” o, mejor todavía, “asociar” esos Input Parameters del Workflow a los Input Parameters de
cada Workflow Element.
A las asociaciones entre un Input Parameter del Workflow y el Input Parameter del Workflow Element,
así como también las asociaciones entre un Attribute y un Input Parameter del Workflow Element les
llamamos Binding.
Como ejemplo podemos decir que cada flecha del esquema es un Binding.
De esta forma podemos ver el Binding a un Workflow Element:
Binding de Parametros y Atributos en un Workflow Element
Importante: Aproximadamente el 80% de los errores en un Workflow tienen que ver con los bindings
o asociaciones entre Input Parameters y los Atributos.
Una vez que comprendamos al 100% las reglas del binding será un antes y un después en nuestra
escala de aprendizaje con vRealize Orchestrator.
La mejor forma de verificar visualmente los Bindings es utilizando la vista “Visual Binding” como vemos
a continuación.
Veamos si hay “alguna” similitud entre el último esquema y la siguiente captura:
Visual Binding en el Workflow Element 1
El binding en un Workflow Element se define a nivel de cada Workflow Element de forma independiente,
en las propiedades, en las pestañas IN y OUT como puede verse en la siguiente captura.
Binding entre un Input Parameter o Atributo y un Input Parameter de un Workflow Element
También es posible hacer Binding utilizando drag and drop en el Visual Binding.
Importante: Recordemos que el usuario que ejecuta el Workflow únicamente definirá la variable de los
Input Parameters. Cuando hacemos referencia a un usuario también podemos estar refiriéndonos al
sistema que ejecute el Workflow como podría ser una instancia de vRealize Automation o un sistema
externo vía REST API.
Mencionamos anteriormente que un Workflow Element puede ser un Scriptable Task, un Action, un
elemento For Each o incluso una llamada síncrona o asíncrona a otro Workflow.
Veamos ahora cómo sería un ejemplo de un Workflow que utiliza un Output Parameter como Input
Parameter.
Ejemplo del Workflow Demo 1 interactuando con el Workflow Demo 2
Nota: Los Output Parameters son utilizados por vRealize Automation como respuesta a una subscripción
de Event Broker y Workflows de tipo XaaS.
En este segundo esquema hemos visto cómo el Workflow Demo 1, a través del Workflow Element 1,
llama al Workflow Demo 2 pasándole la variable que necesita para luego recibir el resultado. En este
caso el resultado o el Output Parameter del Workflow Demo 2 se utilizará como variable en el Attribute
2 del Workflow Demo1. A su vez, el valor del Attribute 2 servirá como Input Parameter para el Workflow
Element 2.
La buena noticia es que si somos capaces de comprender este esquema entonces eso significa que
entendemos el flujo de Parámetros y Atributos.
Si todavía no lo entendemos del todo entonces es un buen momento para comenzar a releer este
apartado desde el principio.
Ámbito de variables de Parámetros y Atributos
En los dos últimos esquemas hemos visto que, si bien algunos Atributos pueden ser predefinidos,
todos los Parámetros e incluso algunos Atributos (los que son definidos durante la ejecución del
Workflow) “pierden” su valor, se quedan en blanco en realidad, una vez que se ejecuta nuevamente el
Workflow. O dicho en otras palabras, necesitamos introducir nuevamente los valores. Después de todo
es justamente esto lo que permite la versatilidad de una orquestación.
Ejemplo de un Atributo predefinido – Complejidad Contraseña
¿Pero qué ocurriría si necesitamos utilizar Atributos en común en dos o más Workflows? ¿Y si
necesitamos actualizar esos Atributos “externos” como parte de cada ejecución de un Workflow?
Llegados a este punto podríamos tener dos situaciones diferentes. Una en que quisiéramos consultar
valores predefinidos que normalmente no cambien. Y otra en que necesitamos que esos valores
externos cambien.
Veamos un ejemplo de cada caso para ser mas concretos.
Caso 1 – Consulta de atributos externos que no cambian
Disponemos de múltiples Workflows para despliegue de VMs. Algunos utilizan Clone y otros Linked
Clone. Cada Workflow utiliza una carpeta diferente en vCenter y puede dimensionar los recursos de
diferente forma, incluso en diferentes clusters, pero hay ciertos valores que no cambian. Esos valores
que no cambian se pueden definir en como un valor externo utilizando Configuration Elements:
• Instancia de vCenter Server
• Versión de Hardware Virtual
• Número de Virtual Cores por Socket
• vSphere Tag para agregar al Backup
Caso 2 – Consulta y actualización de atributo externo que se actualiza
Con el objetivo de la definición de la nomenclatura de una maquina, ya sea para el inventario o para
el hostname, se utilizará un Configuration Element con un Atributo de tipo Number cuyo valor será el
siguiente número disponible.
Un Scriptable Task del Workflow se encargará, utilizando JavaScript, de incrementar en uno el valor del
atributo una vez definido el hostname de la VM.
Éste sería el caso del siguiente esquema en el cual el Atributo 1 obtiene el valor del Configuration
Element y el Workflow Element 2 actualiza el valor del Atributo del Configuration Element incrementando
el número en uno.
De esta forma tanto si este mismo Workflow se ejecuta nuevamente o bien cualquier otro Workflow que
consulte ese Atributo externo tendrá entonces el valor actualizado.
Uso de Configuration Elements como valor externo
Ejemplo de Atributos de un Configuration Element
7. Elementos de un Workflow
Los elementos de un Workflow o Workflow Elements son lo que le dan vida a nuestro flujo de trabajo.
Veamos cuáles son los más utilizados y sus principales características.
Workflow Element Icono Descripción

Cada Workflow tiene un único Inicio y se crea
Start
automáticamente junto con un elemento End.
Cada Workflow debe tener al menos un elemento End.

End
Un nuevo Workflow crea un End automáticamente.
Es probablemente el elemento más utilizado. Es aquí
Scriptable Task donde damos funcionalidad al Workflow utilizando
código con JavaScript.
Las acciones son objetos predefinidos que podemos
encontrar en la librería de acciones. Cumplen una
Action única función y normalmente las asociamos a lo
que sería una función en desarrollo. Tienen código
JavaScript.
Desde un Workflow somos capaces de llamar a otro
Workflow Workflow de la librería. Las llamadas pueden ser
Síncronas o Asíncronas.
Existen tres tipos de elementos Decisión. Decision,
Decision Custom Decision y Decision Activity. Definen la ruta
que continuará el flujo en base a ciertas variables.
Este elemento continúa con un determinado elemento
Switch según una variable existente. Permite considerar
múltiples caminos.
Los Log elements escriben variables y/o el texto que
definamos en el Log o la BBDD de vRO. Existen los
Log
Server y System para eventos de Logs, Warning y
Critical.
Utilizamos frecuentemente estos elementos para
Foreach gestionar colecciones (arrays) de diferente tipo o para
ejecutar acciones repetitivas de forma controlada.
Este simple elemento añade 1 a una variable tipo
Increase counter Number. Se utiliza como complemento del elemento
Foreach.
Una parte esencial de un Workflow es el control de
errores. Este tipo de elemento recibe los errores de
Throw
ejecución y pueden distribuirse en múltiples elementos
del flujo de trabajo.
Algunos elementos del Workflow requieren esperar
Waiting Event un determinado evento para poder continuar con el
siguiente elemento.
Otros elementos o flujos deben esperar hasta una

Waiting Date fecha y hora determinada para continuar con su
ejecución y pasar al siguiente elemento.
Utilizamos este elemento para pausar el Workflow
Sleep por una cantidad determinada de segundos según
necesitemos.
En ciertos flujos es necesaria la intervención del
User interaction usuario para continuar de una forma u otra con el
siguiente elemento.
8. Trabajando con un Workflow
Llegados a este punto vamos a cerrar el capítulo trabajando con un Workflow para poner en práctica
todo lo aprendido hasta ahora.
Utilizando Linked Clone sin la suite Horizon
Linked Clone es una tecnología que nos permite hacer un clon de una máquina virtual, pero utilizando
un Snapshot como disco base. Esto hace que cada VM única comience utilizando un disco Delta de
unos 20MB que irá creciendo a medida que sea diferente de la maquina Parent, ya sea por instalación
de Software, Documentos, Actualizaciones, etc.
Con Linked Clone seremos capaces de crear VMs en cuestión de segundos y utilizando una mínima
parte del espacio que normalmente utilizamos. Vale aclarar que este tipo de clonados no es lo mas
apto para servidores en Producción que requieran un alto rendimiento.
Lo interesante de esto es que Linked Clone está disponible en la Suite Horizon y también como modo
de despliegue en vRealize Automation pero, por alguna razón, no está disponible en vSphere Client o
Web Client de vSphere.
Las tres formas que tenemos de utilizar Linked Clone en vSphere (sin Horizon ni vRA) es utilizando las
API de vCenter, PowerCLI y vRealize Orchestrator.
En este caso no desarrollaremos ningún Workflow nuevo, sino que modificaremos uno preexistente
para simplificar su uso.
En la librería de Workflows, vCenter, Virtual Machine management, Clone, Linked Clone disponemos
del Workflow “Linked clone, no customization”.
Workflow para despliegues con Linked Clone
No es posible modificar un Workflow que viene por defecto en la librería, pero sí que es posible crear
una copia (opción Duplicate) y modificar esa copia a nuestro antojo.
Lo que haremos en este caso es llevar al mínimo los Input Parameters convirtiéndolos en Atributos con
valores predefinidos.
Una vez duplicado el Workflow original (botón derecho sobre el Workflow y opción Duplicate Workflow)
seleccionaremos el Workflow duplicado y lo editaremos presionando Ctrl+E.
Mientras estamos editando el Workflow, en la pestaña General, podremos cambiar el nombre del
mismo.
Cambiando el nombre a un Workflow
En la vista Inputs veremos todos los Input Parameters según se aprecia en la siguiente captura:
Listado de Input Parameters
Y si ejecutamos el Workflow deberemos completar cada uno de los Input Parameters.
Con el fin de simplificar la tarea vamos a convertir (o mover) la mayoría de los Input Parameters en
Atributos y, una vez convertidos, les definiremos un valor.
¿Cómo podemos convertir un Input Parameter en un Atributo? En la misma vista de Input Parameters
seleccionamos uno o varios Parametros y con botón derecho hacemos click en “Move as attribute”.
Moviendo Parametros a Atributos
Una vez movidos los Parametros ya los veremos como Atributos y podremos proceder a asignar valores
predefinidos para llevar al mínimo el número de Input Parameters que debemos definir al ejecutar el
Workflow.
Atributos seleccionados que tendremos que predefinir su valor
Atributos con valores predefinidos
¡¡¡Ahora ya estamos listos para probar el Workflow!!!
Al ejecutar el Workflow únicamente tendremos que especificar el nombre de la VM.
Definiendo el único Input Parameter
Al cabo de escasos segundos podremos verificar en las tareas de vCenter que una tarea de Clonado
ha finalizado. En mi caso demoró 1 segundo.
Tarea de clonado de VM con Linked Clone en 1 segundo
Vista de la nueva VM desplegada con Linked Clone desde vRO
9. Resumen y recomendaciones
Este capítulo fue simplemente un resumen del potencial que puede ofrecer vRealize Orchestrator.
Naturalmente que el producto da para muchísimo mas que un simple capítulo en un libro, pero al
menos disponemos de una buena introducción en nuestro idioma materno.
El Workflow de Linked Clone que modificamos fue solo un ejemplo de cómo reutilizar la librería de
la que disponemos con más de 300 Workflows listos para utilizar ni bien terminamos de desplegar
nuestro vRealize Orchestrator.
No olvidemos que existen recursos fantásticos como VMware Code y VMware Solutions Exchange de
los que podemos descargar tanto Plugins como Workflows.
No obstante, el mejor recurso con diferencia para vRealize Orchestrator son las communities. Es
cierto que están disponibles únicamente en ingles pero la cantidad y calidad de recursos que podemos
encontrar allí es asombroso. Un gran recurso para aprender simplemente leyendo las diferentes
consultas.
Tal vez nos estemos preguntando hasta qué punto necesitamos saber de JavaScript para trabajar con
vRealize Orchestrator. Todo depende de qué tan complejos serán nuestros Workflows. Muchas veces
descubriremos que la tarea que queremos orquestar ya está cubierta por un Workflow de la librería.
Habrá otras situaciones en que deberemos invertir nuestro bien mas valioso, que no es ni más ni
menos que nuestro tiempo, para aprender cómo resolver algo en particular.
Existirán muchas situaciones en que no tendremos mas opción que invitarle un par de cervezas a
nuestro amigo desarrollador.
Un recurso muy interesante es utilizar Powershell/PowerCLI a través de vRO. Ese recurso se convierte
en un comodín muy versátil especialmente cuando JavaScript no es nuestro fuerte.
En ese caso no nos podemos perder el proyecto ONYX. Podemos encontrarlo en VMware Flings y nos
permite utilizarlo cual grabadora de macros de Excel.
Simplemente tenemos que poner ONYX a grabar y ejecutar una o mas acciones en vSphere Web
Client. Al detener la grabación nuestro amigo ONYX nos mostrará el código de Powershell en .NET de
todas las tareas que ejecutamos durante la grabación. ¿Muy interesante verdad?
Y, por último, y no menos importante, necesitamos recordar que todo depende de nosotros. La
herramienta está ahí esperándonos para hacer Workflows increíbles.
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 15
PowerCLI
Miquel Mariano
Capítulo 15 - PowerCLI Miquel Mariano
PowerCLI
1. Introducción
Como muchos ya sabréis, PowerCLI es otra interfaz de acceso a nuestra plataforma vSphere. Es
normal que cualquier administrador de infraestructura virtual esté muy familiarizado con las interfaces
GUI como pueden ser el “vSphere Client” o el “ESXi embeded host client” y no es tan habitual el uso
de PowerCLI.
PowerCLI no es más que un lenguaje de scripting basado en Windows PowerShell que a través de
una serie de módulos (cmdlets) proporcionados por VMware nos permite interactuar con nuestra
infraestructura vSphere.
Imagen proporcionada por VMware
Para mi PowerCLI es una herramienta tremendamente potente que me sirve para desarrollar múltiples
operaciones, desde tareas de administración del propio entorno, tareas de operación con máquinas
virtuales o incluso monitorización y reporting del estado de salud de los entornos que administramos.
En este capítulo veremos cómo hacer la instalación de la última versión, la 10, y aprenderemos los
comandos básicos para poder conectarnos a nuestro entorno y extraer información.
2. Instalación PowerCLI
La primera tarea será asegurarnos de que tenemos PowerShell instalado en nuestro equipo. En las
versiones Windows 7 o superior, el componente viene nativamente instalado pero también os quiero
recordar que desde hace poco más de un año, al ser liberada la versión 6.0 de PowerShell, también
podremos instalarlo sobre Linux y MacOS. Os dejo el anuncio en el blog oficial Microsoft:
https://blogs.msdn.microsoft.com/powershell/2018/01/10/powershell-core-6-0-generally-available-ga-
and-supported
La segunda tarea, será decidir que versión instalar.
En fecha de edición de este libro, la última versión estable es la 11.1.0 y tendremos que comprobar en
la guía de compatibilidad, la que sea compatible con nuestra versión vSphere.
Imagen proporcionada por VMware
Hasta la versión 6.5 de PowerCLI, la instalación era a través de un instalador que nos podíamos
descargar del portal https://my.vmware.com y que tenía un asistente del típico next>next>next>finish
pero fue a partir de la versión 6.5.1 y la llegada de PowerShell 6.0 que todo cambió. A partir de aquí la
instalación de PowerCLI 6.5.1 y superior se realizará a través de PowerShell y su gestor de módulos.
Básicamente son 2 pasos. Nos descargamos los módulos en una ubicación local:
Save-Module -Name VMware.PowerCLI -Path <path>
Instalamos los módulos con el comando siguiente:
Install-Module -Name VMware.PowerCLI
Podréis encontrar una guía paso a paso de cómo instalar la última versión de PowerCLI sobre Windows
en el siguiente post:
https://miquelmariano.github.io/2019/01/instalar-powerCLI-10-windows
3. Cambiar la política de ejecución predeterminada
Una vez tengamos instalada la herramienta, podremos utilizar PowerCLI directamente desde una
consola de PowerShell 6.
La primera vez que utilicemos PowerCLI es posible que recibamos un mensaje de que la política de
ejecución de scripts está configurada en modo restringido.
En este punto, es importante tener clara la política de seguridad de nuestra empresa. La política
de ejecución que configuremos en PowerShell, no debería estar en conflicto con las directrices
propias de seguridad de la empresa.
Para cambiar la política de ejecución de código a un estado que nos permita ejecutar scripts, será
necesario ejecutar PowerShell cómo administrador y posteriormente el siguiente comando:
PS C:\Users\miquel.mariano> Set-ExecutionPolicy RemoteSigned
Este comando, nos configurará PowerCLI para poder ejecutar scripts locales sin ningún tipo de
verificación. Sólo comprobará los scripts descargados de Internet que estén firmados por una entidad
de confianza. Los posibles métodos de ejecución los podréis ver a continuación:
• Restricted - La política de ejecución predeterminada. Permite comandos individuales, pero no

ejecutar scripts.
• AllSigned - Requiere que todos los scripts y archivos de configuración estén firmados por un editor
de confianza, incluidos los scripts que hemos escrito localmente.
• RemoteSigned - Requiere una firma digital de un editor de confianza en los scripts y archivos de
configuración que se descargan de Internet. Sólo se podrán ejecutar scripts locales.
• Unrestricted - Se pueden ejecutar scripts sin firmar. Existe el riesgo de ejecutar scripts maliciosos.
• Bypass – No hay ningún tipo de control ni bloqueo. Tampoco hay advertencias ni avisos.
• Undefined - No hay una política de ejecución establecida por lo que se aplicará la predeterminada,
por lo tanto Restricted.
4. Conexión a nuestro entorno vSphere
Con PowerCLI, al ser un cliente más del ecosistema vSphere tendremos la posibilidad de conectarnos
tanto a un servidor vCenter como directamente a nuestros hosts ESXi.
Para establecer una conexión, usaremos el cmdlet connect-viserver:
connect-viserver <esxi or vcenter> -user <username> -password <password>
A continuación vemos como se ha establecido correctamente una conexión con nuestro vCenter y a la
vez con un host ESXi:
PS C:\Users\miquel.mariano> connect-viserver vcenter.vmwareporvexperts.org -user miquel.

mariano -password Secret123!
Name Port User

---- ---- ----
vcenter.vmwareporvexperts.org 443 VMWAREPORVEXPERTS\miquel.mariano
PS C:\Users\miquel.mariano> connect-viserver esxi01.vmwareporvexperts.org -user root

-password Secret123!
Name Port User

---- ---- ----
esxi01.vmwareporvexperts.org 443 root
Para verificar las conexiones que tenemos activas, nos podremos servir de la variable
$global:DefaultVIServers:
PS C:\Users\miquel.mariano> $global:DefaultVIServers
Name Port User

---- ---- ----
esxi01.vmwareporvexperts.org 443 root
vcenter.vmwareporvexperts.org 443 VMWAREPORVEXPERTS\miquel.mariano
Ahora que ya tenemos establecidas las conexiones, podremos empezar a ejecutar comandos sobre
ellas. Si trabajáis con múltiples conexiones, como es el caso en este ejemplo, utilizaremos el flag
-server para referirnos a una conexión u otra:
PS C:\Users\miquel.mariano> Get-VMHost -server vcenter.vmwareporvexperts.org
Name ConnectionState PowerState NumCpu CpuUsageMhz CpuTotalMhz

MemoryUsageGB MemoryTotalGB Version
---- --------------- ---------- ------ ----------- ----------- -----
-------- ------------- -------
esxi01 Connected PoweredOn 2 228 4198
3,116 5,999 6.7.0
3,119 5,999 6.7.0
3,127 5,999 6.7.0
3,122 5,999 6.7.0
3,120 5,999 6.7.0
formacionesxi03.n... Connected PoweredOn 16 7649 33584
54,352 127,889 6.5.0
69,791 127,889 6.5.0
2,497 127,889 6.7.0
20,548 127,889 6.7.0
PS C:\Users\miquel.mariano> Get-VMHost -server esxi01.vmwareporvexperts.org
Name ConnectionState PowerState NumCpu CpuUsageMhz CpuTotalMhz

MemoryUsageGB MemoryTotalGB Version
---- --------------- ---------- ------ ----------- ----------- -----
-------- ------------- -------
esxi01.vmwareporv... Connected PoweredOn 2 207 4198
3,116 5,999 6.7.0
Para realizar la desconexión de nuestros servidores, utilizaremos el comando Disconnect-vIServer:
PS C:\Users\miquel.mariano> Disconnect-vIServer -Server * -force
Confirm
Are you sure you want to perform this action?
Performing the operation “Disconnect VIServer” on target “User: VMWAREPORVEXPERTS\
miquel.mariano, Server: vcenter.vmwareporvexperts.org, Port: 443”.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “Y”): A
5. Empecemos con lo básico, comando get-help
Antes de empezar a trabajar con PowerCLI es interesante entender los comandos disponibles y cómo
utilizarlos. Con cada versión, VMware suele publicar un poster con todos los comandos disponibles. A
continuación, encontrareis el poster de la versión 10.0 (creo que de la versión 11 todavía no ha salido).
https://blogs.vmware.com/PowerCLI/files/2018/04/VMware_PowerCLI_10_FINAL.pdf
El comando get-help nos será de gran ayuda en todo momento. Lo podremos utilizar de la siguiente
manera:
• get-help <nombre de comando>
Nos enseñará una descripción general del comando y su uso.
PS C:\Users\miquel.mariano> Get-Help get-vm
NAME
Get-VM
SYNOPSIS
This cmdlet retrieves the virtual machines on a vCenter Server system.
SYNTAX
Get-VM [[-Name] <String[]>] [-Datastore <StorageResource[]>] [-Location <VIContainer[]>]
[-NoRecursion] [-Server <VIServer[]>] [-Tag <Tag[]>]
[<CommonParameters>]
Get-VM -Id <String[]> [-Server <VIServer[]>] [<CommonParameters>]
Get-VM [[-Name] <String[]>] [-Server <VIServer[]>] [-Tag <Tag[]>] [-VirtualSwitch

<VirtualSwitchBase[]>] [<CommonParameters>]
Get-VM -RelatedObject <VmRelatedObjectBase[]> [<CommonParameters>]
DESCRIPTION
This cmdlet retrieves the virtual machines on a vCenter Server system. Returns a set
of virtual machines that correspond to the filter criteria
provided by the cmdlet parameters. For virtual machines with multiple NICs and
multiple IP addresses, the IPAddress property of the VMGuest object
contains all IP addresses of the virtual machine. The IP at position 0 is the primary
IP address.
RELATED LINKS
Online Version: https://code.vmware.com/doc/preview?id=6330#/doc/Get-VM.html
Remove-VM
New-VM
Set-VM
Move-VM
Start-VM
Stop-VM
Suspend-VM
Restart-VM
REMARKS
To see the examples, type: “get-help Get-VM -examples”.
For more information, type: “get-help Get-VM -detailed”.
For technical information, type: “get-help Get-VM -full”.
For online help, type: “get-help Get-VM -online”
• get-help <nombre de comando> -examples.
A veces, la forma más rápida de aprender la sintaxis de un comando es viéndolo en acción.
• Get-help <nombre de comando> -detailed.
Obtendremos información adicional sobre el comando, incluidas descripciones de parámetros y

ejemplos.
• Get-help <nombre de comando> -full.
Muestra toda la ayuda disponible para un comando, incluida la información técnica sobre sus
parámetros.
Teniendo esto claro y con un poco de imaginación, podremos hacer casi cualquier cosa con
PowerCLI.
6. Obtener información de un ESXi
El primer comando que os quiero enseñar es el get-vmhost. Nos servirá para echar un vistazo al
componente físico de la infraestructura, al propio host ESXi.
TIP: Con el flag -autosize conseguiremos ver toda la columna
Como Podemos ver, aunque hay información muy útil como uso de CPU y Memoria, versión, etc etc…
hay muchos otros valores que quedan ocultos.
La lista predeterminada que tiene powershell es format-table (ft)
Para poder ver toda la información que devuelve el comando, podemos cambiar la salida a format-list
(fl)
A continuación vamos a explorar un poco más toda la info que nos da la salida del comando get-
vmhost. Por ejemplo, la versión de un servidor ESXi
Get-VMHost | foreach-object {(Get-View $ _.ID).Config.Product}
Vamos a analizar el comando:
• Get-vmhost: Ya conocemos el propósito de este comando
• esxi01: Sirve para posicionarnos sobre un servidor en concreto, si no ponemos nada, se recorrerá
todos los ESXi de nuestra infraestructura.
• Pipe (|): Lo utilizamos para decirle a PowerShell que utilice los resultados del comando anterior, en
este caso, Get-VMhost,
• Foreach-object: Sirve para ejecutar el siguiente comando a más de un objeto. Sería como un
bucle. Quizás el comando get-vmhost devuelve más de un servidor ESX, pues con el comando
foreach-object le decimos que ejecute el comando Get-View (en este ejemplo) para cada objeto
devuelto por el comando anterior (get-vmhost).
• Get-view: Devuelve los objetos que corresponden a los criterios de búsqueda especificados. El
cmdlet recupera la vista de objetos especificados por sus ID o por sus objetos de inventario de
vSphere.
• $ _. ID: La parte $ del comando le indica a PowerCLI que trabaje contra el “objeto seleccionado
actualmente”. Y la parte .ID corresponde a uno de los valores que si os acordais devolvía el
comando get-vmhost
• .config.product: Son sub-objetos que encontramos dentro de .ID y devuelven información de la

versión del ESXi
7. Uso de variables en PowerCLI
Como sabéis, no solo en PowerShell / PowerCLI, el uso de variables añade mucha flexibilidad a la hora
de definir cualquier tarea.
En PowerCLI, las variables se definen usando el símbolo dólar $ justo delante.
Una variable puede ser una colección a través de $nombre_var [número] o una colección multinivel a
través de $nombre_var [número].campo1.
Veamos un sencillo ejemplo, dónde creamos una variable y le asignamos un valor:
PS C:\> $var=23
PS C:\>
PS C:\> $var
23
Otro ejemplo dónde crearemos una variable con múltiples valores:
PS C:\> $var2=23,51,32
PS C:\>
PS C:\> $var2[1]
51
PS C:\>
Trabajando con PowerCLI y vSphere, la salida de un comando casi siempre tiene múltiples valores,
por ejemplo:
Así que cuando metamos la salida de un comando PowerCLI en una variable, ésta será una colección
multinivel.
Como comentábamos, para elegir ciertos valores de la colección, lo haremos de la siguiente forma:
Otra opción que tenemos disponible si queremos seleccionar varios de los valores de esta colección
es usar los bucles y condicionales:
$hosts=get-vmhost
foreach($vmhost in $hosts | where name -notlike “form*”){
$vmhost.Name
$vmhost.NumCPU
$vmhost.MemoryTotalGB
}
Hasta aquí parece fácil, no? Pero, qué pasa si queremos saber, por ejemplo, cuantas vCPUs tiene
nuestro cluster? Para eso necesitaremos usar operadores matemáticos en nuestras variables.
• = Igual
• += Suma el valor y lo asigna a la variable
• -= Resta el valor y lo asigna a la variable
• *= Multiplica el valor y lo asigna a la variable
• /= Divide el valor y lo asigna a la variable
$hosts=get-vmhost
foreach($vmhost in $hosts | where name -notlike “form*”){
$cputotal+=$vmhost.NumCPU
$memoriatotal+=$vmhost.MemoryTotalGB
}
Write-host “En total el entorno tiene $cputotal CPUs y $memoriatotal GB de RAM”
TIP: Para borrar el valor de una variable, utilizaremos el comando Clear-Variable <var_name>
8. Obtener información de VMs
Acabamos de ver cómo obtener información de nuestros hosts ESXi, así que es el turno de bajar un
nivel e irnos a las VMs. El comando get-vm nos permitirá obtener una lista de todas las VMs de nuestro
entorno.
Al igual que hemos hecho con el comando get-vmhost, con la opción ft o fl (format-table o format-list)
podremos manejar la salida a nuestro antojo
Aquí podemos ver la salida detallada con “fl”
Al igual que en los ejemplos anteriores, combinándolo con get-view podremos obtener muchísima
información de cada objeto.
9. Obtener detalles básicos guest
Otro comando interesante a tener en cuenta y que nos da información interesante es get-vmguest.
Datos como la IP que tiene esta VM, o el SO instalado o incluso la versión de las VMware Tools se
podrán extraer con este comando
10. Filtrando con Where-object
En PowerShell y por consiguiente en PowerCLI, por norma general, se suelen generar muchísimos
objetos cuando realizamos una consulta. Lo hemos visto con el comando get-vmhost o get-vm que nos
devuelve la lista de todos los ESXi y VMs respectivamente.
En muchas ocasiones no necesitamos toda esa información y es conveniente especificar que objetos
concretos queremos que nos muestre. Con el cmdlet Where-Object conseguiremos realizar filtros en
nuestras búsquedas para solo mostrar o realizar acciones en los objetos que cumplan ciertos criterios.
Con PowerCLI y Where-Object conseguiremos evaluar cada objeto devuelto por un comando y pasarlo
a la siguiente canalización sólo si cumple con la condición especificada.
Vamos a ver a continuación algunos ejemplos:
Lista de VMs cuyo nombre empieza por “miquel”
Get-VM | Where-Object {$_.Name -like “miquel*”} | ft -autosize
Lista de VMs que están apagadas
Get-VM | Where-Object {$_.powerstate -eq “poweredoff”} | ft -autosize
Lista de VMs con más de 10Gb de memoria configurados
Get-VM | Where-Object {$_.memorygb -gt 10 } | ft -autosize
Lista de VMs con snapshots de más de 3 dias
Get-VM | Get-Snapshot | Where {$_.Created -lt (Get-Date).AddDays(-3)} | Select-Object

VM, Name, Created
Aunque los operadores de comparación son unos cuantos más, a continuación os dejo los que creo
que son más importantes y que está bien dominar:
• -eq igual que
• -ne diferente que
• -gt mayor que
• -ge mayor o igual que
• -lt menor que
• -le menor o igual que
• -like que contiene (se utiliza para buscar patrones, usado con *)
• -notlike que no contiene
• -match que coincida exactamente
• -notmatch que no coincida exactamente
El resto, los podéis consultar aquí:
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_
comparison_operators?view=powershell-6
11. Salida a txt o csv
Otra de las bondades que tiene PowerShell y que evidentemente nos podemos beneficiar usando
PowerCLI es la salida de los comandos hacia ficheros fuera de PowerCLI, ya sean .txt o .csv
Para guardar la salida de un comando en un fichero .txt, utilizaremos la opción Out-File <nombre-del-
fichero.txt>
A continuación un ejemplo:

VM, Name, Created | Out-File snap.txt
En cambio, para generar un fichero .csv, el comando es Export-Csv y se utiliza de la siguiente manera:

VM, Name, Created | Export-Csv snap.csv
12. Comandos de una línea
En este apartado, me gustaría compartir con vosotros una lista de comandos que podemos ejecutar
sin necesidad de crear ningún script y que nos dan información muy valiosa de nuestro entorno:
Lista de VMs que contienen snapshots. Filtramos por nombre de snapshot para que no nos muestre
los realizados por Veeam Backup.
Get-VM | Get-Snapshot | where {$_.Name -notmatch “Restore Point \w”} | Select

VM,Name,Description,@{Label=”Size”;Expression={“{0:N2} GB” -f ($_.SizeGB)}},Created |
FT -Autosize
Lista de VMs que tienen una ISO presentada.
Get-VM | Get-CDDrive | Where-Object {$_.IsoPath -ne $null} | Select Parent,IsoPath
Desmontamos todas las ISOs presentadas a nuestras VMs.
Get-VM | Get-CDDrive | where {$_.IsoPath -ne $null} | Set-CDDrive -NoMedia -Confirm:$False
Verificamos el estado del servicio SSH en nuestros hosts ESXi.
Get-VMHost | Get-VMHostService | Where { $_.Key -eq “TSM-SSH” } |select VMHost, Label,

Running
Arrancar servicio SSH en nuestros hosts ESXi.
Get-VMHost | Foreach {Start-VMHostService -HostService ($_ | Get-VMHostService | Where

{ $_.Key -eq “TSM-SSH”} )}
Detener servicio SSH en nuestros hosts ESXi.
Get-VMHost | Foreach {stop-VMHostService -HostService ($_ | Get-VMHostService | Where {

$_.Key -eq “TSM-SSH”} )}
Contar cuantas VMs se están ejecutando en cada host ESXi.
Get-VMHost | Sort-Object Name | Select Name,@{N=”VM”;E={ if ($_.ExtensionData.Vm -ne

$null) { $_.ExtensionData.Vm.Count } else {0}}}
Contar cuantas VMs se están ejecutando en cada datastore.
Get-datastore | Sort-Object Name | Select Name,@{N=”VM”;E={ if ($_.ExtensionData.Vm -ne

$null) { $_.ExtensionData.Vm.Count } else {0}}}
Ver estado de las VMware Tools y VirtualHW en todas nuestras VMs.
Get-VM | Select @{N=”VMName”; E={$_.Name}}, @{N=”State”; E={$_.PowerState}}, @

{N=”HardwareVersion”; E={$_.Extensiondata.Config.Version}}, @{N=”ToolsVersion”; E={$_.
Extensiondata.Config.Tools.ToolsVersion}}, @{N=”ToolsStatus”; E={$_.Extensiondata.
Summary.Guest.ToolsStatus}}, @{N=”ToolsVersionStatus”; E={$_.Extensiondata.Summary.
Guest.ToolsVersionStatus}}, @{N=”ToolsRunningStatus”; E={$_.Extensiondata.Summary.
Guest.ToolsRunningStatus}} | where state -notmatch poweredoff | FT
Ver las VMs que se han creado recientemente
Get-VIEvent -maxsamples 10000 | Where {$_.Gettype().Name -eq VmCreatedEvent} | Select

createdTime, UserName, FullFormattedMessage
Ver las VMs que se han eliminado recientemente
Get-VIEvent -maxsamples 10000 | Where {$_.Gettype().Name -eq “VmRemovedEvent”} | Select

createdTime, UserName, FullFormattedMessage
Ver los ultimos errores en el visor de eventos de vCenter
Get-VIEvent -maxsamples 10000 -Type Error -Start (get-date).AddDays(-7) | Select

createdTime, fullFormattedMessage
Ver las VMs que tienen el controlador de red e1000
get-vm | Get-NetworkAdapter | where {$_.type -match “e1000”} | select-object

parent,networkname,name,type
13. Script para desplegar VMs
Para terminar este capítulo, me gustaría compartir con todos vosotros un script que llevo utilizando
bastante tiempo y que me es muy útil a la hora de desplegar VMs, sobre todo si son varias, ya que
automáticamente desplegará el nº que le indiquemos.
https://github.com/vmwareporvexperts/vmwareporvexperts/tree/master/libro/capitulo-11/PowerCLI
A continuación os dejo el código, en dónde en el apartado de VARIABLES GLOBALES configuraremos

todo nuestro despliegue.
<#
.DESCRIPTION
vAutodeployVM.ps1 es un script que nos ayuda a automatizar desplieques de VMs
.REQUISITES
PowerCLI 5.5 o superior
Tener un template o VM que nos sirva de base al despliegue
Tener una plantilla de Custom Specifications Manager (https://www.ncora.com/
blog/2016/11/01/customizacion-de-templates-en-vsphere/)
.NOTES
File Name : vAutodeployVM.ps1
Author : Miquel Mariano - @miquelMariano
Version : 1
.USAGE
Ejecutar directamente vAutodeploy.ps1
.CHANGELOG
v1 02/02/2019 Creación del script
#>
#--------------VARIABLES GLOBALES----------------------
$Quantity = 1
$BaseVMname = “VM-DEMO-”
$PrimerVMxx = 10 #Valor autoincremental del nº de VM. VM-DEMOxx
$NameTemplate_or_VM = “miquel-template-W2012R2-Std-ES” #La base para la nueva VM puede
ser una plantilla o un clon de otra VM
$Is_template = 0 # Valor 1 si se va a desplegar desde una plantilla o 0 si es un clon
de otra VM
$CustomSpec = “miquel-windows-domain-dhcp”
$Cluster = “Cluster-EVC”
$Datastore = “G350_FORM_NLSAS_LUN000”
$VLAN = “VLAN6-Formacion”
$PrimeraIP = 110 #Valor del último octeto de la IP. 10.0.0.xx Se irá autoincrementando
en caso que $Quantity sea mayor a 1
$MemGB = 4
$NumCPU = 2
#--------------VARIABLES CUSTOM SPECIFICATIONS (los parametros deben ser validos para

la VLAN que especifiquemos en la variable $VLAN)---------
$net = “10.0.0.”
$mask = “255.255.255.0”
$gw = “10.0.0.1”
$pdns = “8.8.8.8”
$sdns = “4.4.4.4”
#----------BUCLE PARA DESPLEGAR N MAQUINAS-------------

for ($n=1;$n -le $Quantity; $n++) {
$vmname = $BaseVMname+$PrimerVMxx
write-host Desplegando $vmname de $quantity servers -foregroundcolor yellow
$ip = $net+$PrimeraIP
#asignamos una ip estatica a la customización
Get-OSCustomizationSpec $CustomSpec | Get-OSCustomizationNicMapping | Set-
OSCustomizationNicMapping -IpMode UseStaticIp -IpAddress $ip -SubnetMask $mask
-DefaultGateway $gw -DNS $pdns,$sdns
if ($Is_template -eq 1){

New-VM -Name $vmname -OSCustomizationSpec $CustomSpec -ResourcePool $Cluster
-Template $NameTemplate_or_VM -Datastore $Datastore
}
if ($Is_template -eq 0){

New-VM -Name $vmname -OSCustomizationSpec $CustomSpec -ResourcePool $Cluster -VM
$NameTemplate_or_VM -Datastore $Datastore
}
Get-VM -Name $vmname | Get-NetworkAdapter | Set-NetworkAdapter -NetworkName $VLAN

-Confirm:$false
Get-VM -Name $vmname | Set-VM -MemoryGB $MemGB -NumCPU $NumCPU -Confirm:$false
Start-VM -VM $vmname
$PrimeraIP++
$PrimerVMxx++
}
#configuramos la customización para que la IP sea asignada mediante asistente

Get-OSCustomizationSpec $CustomSpec | Get-OSCustomizationNicMapping | Set-
OSCustomizationNicMapping -IpMode PromptUser -SubnetMask $mask -DefaultGateway $gw -DNS
$pdns,$sdns
Para empezar con el despliegue, simplemente ejecutaremos el script sin especificar ningún parámetro
y a disfrutar…
14. Notificaciones con telegram
Hace ya bastante tiempo que utilizo Telegram como sistema de notificaciones.
El correo electrónico está bien, pero las notificaciones instantáneas están aún mejor cuando queremos
reportar una información concreta de forma rápida.
Para poder integrar Telegram con nuestros script de PowerCLI, lo primero que necesitaremos es un
“chat bot”. Crear uno de ellos es una tarea realmente sencilla y la red está llena de documentos paso
a paso para su creación.
Sin ir más lejos, os recomiendo este, que es el mejor que podréis encontrar ;-)
https://miquelmariano.github.io/2017/02/notificaciones-automaticas-con-telegram
Una vez tengamos el bot creado, tendremos los 2 valores clave necesarios para recibir notificaciones
por telegram. El token único del bot y el chatID que identificará a que chat enviaremos notificaciones.
El código PowerCLI para enviar notificaciones sólo son 4 lineas:
$MyToken = “304017237:AAHpKXZBaw_wOF3H-ryhWl3F3wqIVP_Zqf8”
$chatID = 6343788
$Message = “Hola Miquel, este es un mensaje enviado desde PowerCLI”
$Go = Invoke-RestMethod -Uri “https://api.telegram.org/bot$($MyToken)/sendMessage?chat_
id=$($chatID)&text=$($Message)”
• $MyToken: Es el identificador único de nuestro bot
• $chatID: Es el ID que identifica a que chat enviará las notificaciones
• $Message: El cuerpo del mensaje que queremos enviar
• $Go: Lanzamos la URL contra la API de telegram para enviar el mensaje
Tanto el token como el chatID aquí expuestos son reales y totalmente funcionales, pero os
recomiendo que experimenteis con vuestro propio bot ya que esta configuración enviará las
notificaciones a mi cuenta
Ahora que ya sabemos enviar notificaciones con PowerCLI, vamos a intentar exprimir esta funcionalidad
y que nos envíe información de nuestro entorno vSphere.
Vamos a utilizar algunos de los comandos de una sola línea que comentamos anteriormente:
La variable $Message tiene que ser contenido de texto, por lo que la salida de todos nuestros
comandos tendrá que ser una cadena de texto. Esto se consige con el flag Out-String.
También os recomiendo, utilizar el flag, format-list ya que al convertir el resultado en cadena de

texto, las tablas pueden no verse correctamente.
Lista de VMs con snapshots:
$chatID = 6343788
$Message = Get-VM | Get-Snapshot | where {$_.Name -notmatch “Restore Point \w”} | Select
VM,Name,Description,@{Label=”Size”;Expression={“{0:N2} GB” -f ($_.SizeGB)}},Created |
FL | Out-String
$Go = Invoke-RestMethod -Uri https://api.telegram.org/bot$($MyToken)/sendMessage?chat_
id=$($chatID)&text=$($Message)
Lista de VMs que se han eliminado recientemente:
$chatID = 6343788
$Message = Get-VIEvent -maxsamples 10000 | Where {$_.Gettype().Name -eq “VmRemovedEvent”}
| Select createdTime, UserName, FullFormattedMessage | FL | Out-String
En algunos casos, se puede dar la circunstancia de que la variable $Message sea demasiado larga
para que Telegram la acepte. En este caso en vez de enviar toda la información de golpe, tendremos
que hacer un bucle para que vaya enviando los resultados así como se vayan obteniendo.
Lista de VMs el estado de sus VMware Tools y virtual HW:
$chatID = 6343788
$Result = Get-VM | Select @{N=”VMName”; E={$_.Name}}, @{N=”State”; E={$_.PowerState}},
@{N=”HardwareVersion”; E={$_.Extensiondata.Config.Version}}, @{N=”ToolsVersion”; E={$_.
Extensiondata.Config.Tools.ToolsVersion}}, @{N=”ToolsStatus”; E={$_.Extensiondata.
Summary.Guest.ToolsStatus}}, @{N=”ToolsVersionStatus”; E={$_.Extensiondata.Summary.
Guest.ToolsVersionStatus}}, @{N=”ToolsRunningStatus”; E={$_.Extensiondata.Summary.
Guest.ToolsRunningStatus}} | where state -notmatch poweredoff
foreach($output in $Result){
$Message = $output | FL | Out-String
}
15. VMware hands-on-lab
Estoy convencido de que muchos de vosotros ya conoceréis y estaréis familiarizados con la plataforma
de laboratorios de VMware:
https://labs.hol.vmware.com/HOL/catalogs/
Para todos vosotros, os recomiendo el laboratorio HOL-1911-05-SDC dónde podréis practicar y

aprender muchísimas cosas sobre automatización con PowerCLI.
El laboratorio está pensado para unos 90 minutos de prácticas y en el aparte de una introducción a
PowerCLI se proponen muchas prácticas para automatizar configuraciones tanto de vCenter, como de
ESXi así como también de máquinas virtuales.
16. govcsim para crear entornos de test
No quería despedirme de este capítulo sin hablaros de vCenter Server Simulator (govcsim).
Es un proyecto open source que simula la API de un vCenter y ESXi. Está escrito en GO y nos ofrece un
entorno completamente funcional donde podremos probar nuestros scripts de PowerCLI, por ejemplo.
Este simulador, nos creará un entorno que contendrá los objetos más típicos que nos podremos
encontrar en un vCenter: datacenter, cluster, hosts, VMs, resource pools, redes, datastores…
De esta manera, como decía, podremos probar nuestros scripts, comandos o simplemente aprender
de PowerCLI sin correr el riesgo de romper nada.
Aquí encontrareis toda la información relacionada con el proyecto:
https://github.com/vmware/govmomi/tree/master/vcsim
En la documentación oficial están las instrucciones para instalar todo el entorno GO y hacer funcionar
vcsim, pero existe un contenedor docker que nos facilitará mucho más la instalación.
https://hub.docker.com/r/nimmis/vcsim
No corresponde a este capítulo hablar de docker y contenedores, pero una vez tengamos docker
instalado en nuestra máquina, arrancar el simulador es tan fácil como ejecutar el siguiente comando:
docker run --rm -d -p 443:443/tcp nimmis/vcsim:latest
• docker run: Comando para ejecutar contenedores
• –rm: Para que se elimine el contenedor una vez parado. Es opcional pero así nos aseguramos que
cada vez que lo arranquemos tendremos un entorno “limpio”
• -d: Para que el contenedor se ejecute en background, “detached”
• -p 443:443/tcp: Mapeamos el puerto 443TCP del host de docker al contenedor.
• nimmis/vcsim:latest: Utilizamos la última versión de la imagen nimmis/vcsim.
Una vez tengamos nuestro contenedor corriendo, ya podremos coger PowerCLI y lanzar la conexión:
Como veis, el usuario y contraseña por defecto del contenedor es u y p
Una cosa a tener en cuenta y si os acordáis de la guía de compatibilidad, es que vcsim simula
un vCenter 6.5 y PowerCLI 11 no es compatible. Por eso en la captura anterior estoy utilizando
PowerCLI en versión 6.5
A continuación podéis ver los principales objetos que contiene este entorno:
A partir de aquí ya sabéis, con govcsim es posible generar un entorno de laboratorio de forma fácil para
poder probar nuestros desarrollos.
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 16
vRealize Automation
Federico Cinalli
Capítulo 16 - vRealize Automation Federico Cinalli
vRealize Automation, la Prueba de

Concepto
1. Introducción
En el VMworld del año 2011 VMware presentó el término SDDC. Desde entonces el concepto de
Software Defined Data Center fue globalizándose hasta lo que es hoy en día. La clave está en el
Software dicen los que saben…
Si comparamos un Datacenter de hoy en día con otro de tan solo 10 o 12 años atrás, aún con
virtualización, podemos confirmar que conseguimos principalmente dinamismo y eficiencia. Las cargas
de datos siempre van a más, tanto en tamaño como en complejidad. Eso genera la necesidad de, a la
par del crecimiento, ser aún más eficientes en nuestro día a día.
En cualquier Datacenter existen procesos, procedimientos, tareas y requerimientos. También marcos

de Seguridad. La evolución del viaje al Cloud nos sorprendió a muchos estableciendo el entorno
Híbrido como algo más que una opción. Incluso la interconexión entre diferentes Cloud Públicas está
ganando terreno día a día frente al clásico Datacenter en la Empresa.
Esa combinación de Clouds Privadas y Públicas requiere todavía más esfuerzos en la curva de
aprendizaje para que seamos capaces de cumplir con los aprovisionamientos, procedimientos y
seguridad a la vez que maximizamos las inversiones en recursos.
vRealize Automation es una solución Multi-Tenant, Multi-Cloud y Multi-Plataforma que permite no solo
el despliegue de cualquier tipo de máquina virtual en diferentes ámbitos, sino que además ofrece la
gestión de todo el ciclo de vida de esas máquinas. Como si fuera poco vRA también permite ofrecer lo
que conocemos como XaaS, lo que sea como servicio, permitiendo extender de forma exponencial las
posibilidades de automatización a través de un único portal de autoservicio, con independencia de las
plataformas que estemos gestionando.
¿Qué podemos esperar de este capítulo?

vRealize Automation es un producto con un potencial enorme que requiere mucho detalle y desarrollo.
La idea de este capítulo del libro es compartir una introducción al producto, con el objetivo que se pueda
comprender gran parte del potencial y los principales componentes y dependencias, fundamentalmente
orientado a una POC o Prueba de Concepto.
Para una mejor comprensión de este capítulo se recomienda tener conocimientos de NSX y vRealize
Orchestrator, o bien haber leído previamente los correspondientes capítulos de este mismo libro.
Todo el material expuesto está basado en la versión 7.5 de vRA.
2. Casos de Uso
Los casos de uso principales están orientados principalmente a organizaciones dinámicas en cuanto a
consumo de recursos, pero con múltiples reglas y procedimientos que cumplir ya sea a nivel operativo
como también seguridad.
Si bien estas organizaciones pueden disponer de múltiples centros de datos, la propia evolución de la
tecnología las hace interactuar con mayor frecuencia con soluciones Cloud de proveedores Públicos.
La necesidad de un mayor control, una fluida integración de las diferentes áreas de TI sumado a la
búsqueda de la simplificación de las operaciones, aunque alineadas con los sistemas de IT Service
Management (ITSM) hace que una solución como vRealize Automation sea recibida con los brazos
abiertos por la dirección de la organización.
Existen infinidad de casos de uso para vRealize Automation. Ante todo, debemos comprender que
el alcance de vRA no es solo una plataforma SDDC de VMware. A través del socio de vRA, vRealize
Orchestrator, seremos capaces de integrar, complementar, orquestar y automatizar todo tipo de
despliegues, configuraciones y servicios en un entorno Multi-Tenant, con soluciones Multi-Cloud y
tecnologías Multi-plataforma.
Veamos a continuación algunos de los casos de uso más comunes.
Despliegue de Máquinas
El primer caso de uso natural de vRealize Automation es la automatización de máquinas virtuales en
uno o varios Datacenters con plataforma vSphere.
Esos despliegues se personalizarán de tal forma que las maquinas Windows formen parte del dominio
de Active Directory, utilizando la correspondiente OU, asociando el segmento de red correspondiente
según la petición y agregando la VM tanto al IPAM como al CMDB que estemos utilizando en la
organización.
Multiples opciones de personalización
Es posible adaptar los despliegues con pequeñas modificaciones como agregar al usuario que hizo la
petición en el catálogo como miembro del grupo administradores local de la VM o aplicar cambios en
el sistema operativo según requiera la maquetación.
Gestión de Software
vRealize Automation no es una solución de gestión de software. No obstante, sí que es posible preparar
la infraestructura necesaria para un cluster de aplicaciones como puede ser la red de heartbeat,
servicios de balanceador, almacenamiento y hasta reglas de afinidad y anti-afinidad.
De forma complementaria a los Blueprints, seremos capaces de crear nuestra propia librería de
Software en la cual, a través de scripts de bash, cmd y/o powershell automatizaremos la instalación,
inicio, actualización y desinstalación de componentes de Software en nuestras VMs y contenedores.
Librería de Software en vRA
Si bien esta opción aporta una granularidad y funcionalidad considerable, debemos tener claro que
vRA no gestiona un inventario de Software ni mucho menos un sistema de control de versiones o
licencias de toda la organización.
Esto no quita a que vRA sea la herramienta que canalice los cambios a través de soluciones como
Satellite para Linux y System Center para Windows.
Integraciones con Cloud Publica

No hay lugar a ninguna duda que éste es el camino y la evolución natural. Hoy en día hablamos de
Clouds Híbridas y soluciones de Cloud Públicas complementarias entre sí. vRealize Automation nos
aporta la capacidad de interactuar tanto con soluciones de Cloud Privada y Pública de VMware así
como también soluciones de Cloud Publica de Azure, Amazon AWS y Google Cloud. Eso sin olvidar
el comodín de vRealize Orchestrator para interactuar vía API con cualquier sistema que presente su
REST API.
Personalización de EC2 Machine en vRA
Ya sea un nuevo VPC o un repositorio S3 en AWS, o bien una instancia de VM en Azure podrán ser
desplegados y gestionados a través de vRealize Automation como un punto único de control y gestión.
Extensibilidad
Probablemente sea de lo más interesante que podamos aportar a la organización a través de vRealize
Automation. Es aquí donde los proyectos marcan la diferencia entre lo estándar y lo que comúnmente
se llama “valor agregado”.
La extensibilidad la podemos aportar a la hora de entregar nuevas peticiones como también en lo que
llamamos gestión del día 2 a través de Resource Actions o bien como parte de las subscripciones de
Event Broker.
Ya sea una opción de Backup como servicio en el catálogo, la instalación de un componente de

Software o bien la automatización del procedimiento de baja de una VM.
Este último ejemplo se identifica claramente con la filosofía de uso de vRealize Automation. Como parte
de los procedimientos de la organización, al dar de baja una maquina Windows, debemos ejecutar
tareas como remover la VM del Dominio, liberar la IP en el IPAM, cambiar el estado del ítem en la
CMDB y hasta posiblemente liberar el costo en vRealize Business.
Sistema de aprobaciones y control de costo

Para cada nueva petición en el catálogo de vRA es posible definir unos criterios que exijan la necesidad
de aprobación para la petición. Ya sea en base al usuario, a la cantidad de recursos solicitada o
directamente al servicio requerido.
De forma adicional es posible asignar un coste a cada recurso entregado a través de vRealize
Automation con la integración de vRealize Business.
Estas dos simples características son puntos fuertes a la hora de negociar con nuestros amigos del
departamento financiero.
Seguridad por defecto y como servicio

La integración de vRealize Automation con NSX-V y NSX-T es la exquisitez en su máxima expresión.
El hecho de definir Blueprints y alinear las configuraciones con la seguridad pre-definida en NSX es un
gol desde 45 metros.
No solamente la posibilidad de automatizar instancias de NSX EDGE con servicios de Firewall, NAT,
VPN y Balanceadores es más que interesante, sino que además vamos a poder hacer uso de la micro
segmentación pre-definida por los especialistas de seguridad en NSX. Esa asignación de seguridad la
podemos aplicar simplemente asignando una etiqueta en los objetos VM del Blueprint.
Consumo de recursos
Y como si todo esto fuera poco debemos también hacer referencia a las formas de consumir estas
automatizaciones y recursos.
La forma más conocida de uso de vRealize Automation es a través de su entorno gráfico, pero la
herramienta aporta opciones muy versátiles como el uso de CMD y API.
Tareas como importar o exportar Blueprints, solicitar recursos del catálogo o bien ejecutar acciones en
ítems gestionados a través de línea de comandos y/o API nos abren un abanico de posibilidades que
cubrirán todas las necesidades de interacción y gestión.
3. Componentes
Los componentes en una implementación de vRealize Automation son los mismos tanto para una
prueba de concepto como para producción. Evidentemente en entornos en producción cambian los
recursos de cómputo asignados, números de instancias y distribución de los diferentes elementos que
dan servicio al sistema.
Cada implementación de vRealize Automation requiere su diseño y dimensionamiento lo cual va a

determinar el número de instancias de Appliances, el número de servidores Windows con diferentes
componentes y elementos externos como la base de datos SQL y el Balanceador Web.
Componentes de vRealize Automation

vRealize Automation Appliance: Como su nombre lo indica es un Appliance Virtual que descargamos
en formato OVA.
Funcionalidades incluidas en el Appliance de vRA:
• vRealize Automation (Servicio principal)
• Identity Manager (LDAP Server)
• Base de Datos (PostgreSQL)
• vRealize Orchestrator (Orquestador embebido)
Componentes del Appliance de vRA
Recursos por defecto: 4 vCPU / 18GB de RAM / 140GB de Disco
La escalabilidad del Appliance de vRA se consigue ampliando los recursos de cómputo en cada
Appliance o bien desplegando instancias adicionales del mismo. No es posible seleccionar los
componentes internos a instalar, es decir que en cada despliegue del vRA Appliance tendremos
siempre los 4 componentes. Lo que sí es posible es utilizar un Host o Cluster de vRealize Orchestrator
como Orquestador externo liberando de esta forma el consumo de recursos de los Workflows de vRO.
Servidor IaaS: Servidor Windows con servicios de Core complementarios al Appliance de vRA.
Funcionalidades incluidas en el servidor IaaS**:
• Web site (IIS)
• Manager
• DEM Orchestrator*
• DEM Worker
• Proxy Agent
Componentes del IaaS Server
Recursos por defecto con todos los componentes: 4 vCPU / 8GB de RAM / 40GB de Disco
*El DEM Orchestrator es un elemento totalmente diferente a vRealize Orchestrator.
**El servidor IaaS requiere, además, una base de datos SQL Server.
Para escalar los servicios de IaaS podemos implementar nuevas instancias de Windows server
distribuyendo los diferentes componentes (Web, Manager, Agent y DEMs) con los objetivos de proveer
tanto alta disponibilidad como mayor cantidad de recursos.
Base de Datos IaaS: Servidor Windows con una base de datos o instancia SQL Server.
Recursos por defecto: 2 vCPU / 8 GB de RAM / 40GB de Disco
En pruebas de concepto este servicio de Base de Datos puede estar desplegado en el mismo
servidor IaaS, aunque en producción se debería utilizar una instancia externa de SQL Server en alta
disponibilidad.
Componentes externos o complementarios a vRA

El Appliance de vRA, el servidor IaaS y la Base de Datos SQL son los elementos mínimos que
necesitamos para poner en marcha vRealize Automation, al menos para una prueba de concepto.
Cuando se trata de escalar la solución, proveer resiliencia e incrementar las funcionalidades, vamos a
necesitar de determinados elementos externos que describiremos a continuación.
vRealize Orchestrator como elemento externo

Como se explicó anteriormente, el Appliance de vRA incluye por defecto una instancia de vRealize
Orchestrator. En diseños que requieran atender una demanda considerable de Workflows de vRO así
como también en entornos Multi-Site se suele desplegar una o dos instancias externas de vRealize
Orchestrator.
Esto requerirá la implementación de uno o dos Appliances de vRealize Orchestrator (2 en modo Cluster)
reduciendo el consumo de recursos en el Appliance de vRA por parte de los Workflows de vRO.
vRO como elemento externo de vRA
vRealize Orchestrator versión 7.4 introdujo la funcionalidad de Multi-Tenancy que permite definir
un aislamiento de instancias basadas en la autenticación de vRA Identity Manager y de esa forma
incrementar la seguridad de elementos como Workflows, Acciones, Resource elements y otros.
El Cluster de SQL Server

El servidor IaaS necesita una base de datos SQL Server. En entornos de producción se requiere
aprovisionar tanto la propia Base de Datos como también la protección de la misma ante fallos para
que ésta no se convierta en un punto único de fallo de toda la implementación de vRA.
vRA soporta SQL Server 2016 en AlwaysOn y en versiones anteriores de SQL la alta disponibilidad
requiere la implementación de un SQL Server en Failover Cluster.
Balanceador Web
Como Balanceador podemos utilizar mismamente NSX EDGE (normalmente en HA), F5 o Citrix
Netscaler.
Directorio Activo
Los servicios de un Active Directory de Microsoft no son obligatorios en una implementación de vRealize
Automation. No obstante, en el mundo real siempre integramos AD con Identity Manager de vRA como
fuente de autenticación.
Eso nos permitirá simplificar el procedimiento de autenticación a los usuarios con la misma cuenta que
utilizan en sus equipos a la vez que hacemos nesting con los grupos de IT para la delegación de roles
en vRA.
vRealize Business for Cloud

vRealize Business o vRB es una solución de control de costos que forma parte de la suite vRealize.
Es posible incrementar las funcionalidades de vRealize Automation integrando vRA con vRB o bien
desplegar vRealize Business únicamente.
Lo curioso del caso es que, si únicamente queremos desplegar vRB, por más que no vayamos a utilizar
vRealize Automation, vamos a necesitar instalar una instancia de vRealize Automation como soporte y
requerimiento para vRealize Business.
Host de Powershell
Una máquina virtual Windows con Powershell integrada con vRO nos permitirá utilizar el “comodín”
de Powershell más PowerCLI. El appliance de vRealize Orchestrator no puede ejecutar comandos
y/o scripts de Powershell por sí mismo y es por eso que necesitamos integrar vRO con un host de
Powershell.
Si bien esto no es un requerimiento para la implementación de vRA podemos considerar esta extensión
de Powershell como algo prácticamente obligatorio ya que nos dará muchísimo juego en los Blueprint
de tipo XaaS así como en las subscripciones de Event Broker.
Prueba de Concepto de vRealize Automation

Para un POC de vRA normalmente utilizamos el mínimo de componentes aunque eso no impacta en
absoluto en la posibilidad de utilizar el 100% de las funcionalidades del producto con fines de prueba.
Esquema de una instalación mínima de vRA
Un excelente punto de partida para el diseño y dimensionamiento de vRealize Automation en Producción

es el documento “VMware vRealize Automation 7x Reference Architecture” en el que podemos ver 3
diseños y dimensionamientos diferentes con bastante detalle.
Documento de Arquitectura de Referencia para vRA 7.5
4 - Implementación de vRealize Automation
Introducción
Con independencia de si vamos a desplegar una POC o un vRA en Producción, las fases serán las
mismas, aunque con mayor o menor número de componentes. Una solución de vRealize Automation
en Producción y alta disponibilidad requiere de varios elementos externos lo que supone un mayor
tiempo requerido para la puesta en marcha.
A continuación, vamos a detallar las diferentes fases y configuraciones requeridas a modo de introducción
de los diferentes elementos que componen esta increíble solución que es vRealize Automation.
• Fase 0: El Diseño
• Fase 1: La Instalación
• Fase 2: La Configuración
• Fase 3: El Contenido
• Fase 4: Las Operaciones del Día 2
La fase de Diseño define los casos de uso y los requerimientos generales del proyecto.
La Instalación es cuando instalamos los componentes necesarios como el Appliance, Iaas,

balanceadores, registros DNS, etc.
En la Configuración integramos todos los elementos como los endpoints, autenticación, orquestador,
roles, tenants y varios elementos más.
Una vez finalizada la fase de Configuración ya podemos comenzar a crear Contenido en el catálogo
de vRealize Automation a través de los blueprints y su posterior gestión a través de las operaciones
del día 2.
El Diseño
Todo buen diseño debe comenzar con su detalle de Requerimientos, Supuestos, Riesgos y Límites.
Veamos una descripción de cada uno y lo que supone una decisión de Diseño.
Requerimientos: Probablemente la definición más importante del proyecto. Es aquí en donde se

definen los objetivos principales como el alcance, alta disponibilidad, escalabilidad, alineación con
casos de uso y su correcta integración con la infraestructura de la organización.
Los requerimientos siempre están más enfocados al negocio que a la parte técnica.
Supuestos: La lista de supuestos incluye todos los elementos del proyecto que son necesarios para
su correcta ejecución como credenciales, servicios, certificados, licencias, recursos y demás. A la
hora de comenzar con el proyecto, la lista de supuestos debe estar vacía ya que se tiene que haber
confirmado la disponibilidad de la totalidad de las dependencias.
Límites: Esta lista muchas veces está compuesta por malas noticias como que no hay presupuesto
disponible para aprovisionar alta disponibilidad, o que la licencia del producto adquirida con antelación
no incluye una cierta funcionalidad o simplemente define que debemos cernirnos al software-hardware
existente en la organización. El desafío es sortear los Límites cumpliendo los Requerimientos.
Riesgos: Por último los riesgos deben estar perfectamente definidos ya que es una forma de poner por
escrito al conocimiento previo de cada uno de los riesgos. Entre los riesgos está la no disponibilidad de
un centro de datos alternativo (producto de un límite en el presupuesto) o el uso de una base de datos
sin redundancia, como simples ejemplos. Aquí deberán estar listados todos los elementos que puedan
comprometer la continuidad del servicio de una u otra forma. Los riesgos pueden ser asumidos o bien
contar con una salvaguarda correctamente detallada.
TIP: De forma adicional a los elementos definidos anteriormente debe estar muy claro el alcance del
proyecto. Evitar falsas expectativas o bien malos entendidos es el objetivo de este ítem.
Algo tan simple como el número de Datacenters, Endpoints, métodos de autenticación, soporte, número
y detalle de los flujos de trabajo (Workflows) es fundamental para el éxito del proyecto por más que se
trate de una prueba de concepto o un entorno en producción.
Decisiones de Diseño
Una vez definidos los Requerimientos, Supuestos, Límites y Riesgos es hora de comenzar con los
diseños de los esquemas Conceptual, Lógico y Físico.
El Diseño estará compuesto por múltiples decisiones de diseño con su correspondiente justificación,
descripción de impacto y asociación al o los requerimientos relacionados.
Una vez definido el Diseño ya estaremos listos para comenzar con la instalación del producto. Al
tratarse de un sistema que requiere innumerables interacciones debemos tener muy en cuenta la
existencia de los pre-requisitos como registros DNS’s, licencias de producto, certificados digitales,
balanceadores, direcciones IP’s, segmentos de red, claves de producto, recursos de computo, reglas
de firewall, sistemas de autenticación y las credenciales necesarias para todas estas interacciones.
Para una correcta implementación y un buen manejo de los tiempos durante el proyecto debemos
asegurarnos de disponer del 100% de los pre-requisitos y dependencias antes de comenzar con la
implementación.
Es necesario además considerar que la mayoría de las compañías que implementan vRA deben requerir
información, autenticación y configuraciones a otras áreas. Estas peticiones crean dependencias, las
cuales generan retrasos en algunos casos inesperados.
La Instalación de vRealize Automation

La instalación de un sistema como vRealize Automation está compuesta por varios componentes y
múltiples dependencias o complementos. Este capítulo del libro está enfocado a una POC (Prueba de
Concepto) de vRealize Automation por lo que tomaremos como ejemplo una instalación simple de vRA
utilizando el mínimo de componentes.
A continuación, repasaremos los componentes a utilizar y sus funcionalidades.
Appliance de vRealize Automation: 1 maquina en modalidad virtual appliance con plataforma Linux
que descargaremos en formato OVA.
Este appliance dará servicio al core de vRA, el sistema de autenticación, el orquestador embebido
(vRO) y la base de datos PostgreSQL que utilizarán los tres primeros elementos.
La cantidad de recursos que consumirá esta VM será de 4 vCPU, 18GB de RAM y 140GB de Disco
como detallamos anteriormente.
Opciones de configuración del Appliance de vRA
Servidor IaaS: 1 máquina virtual con sistema operativo Windows Server.
El servidor IaaS dará servicio al Web Server, el Manager, DEM Worker, DEM Orquestrator y el Agente
que conectará con vCenter.
Al tratarse de una POC es posible instalar en este mismo equipo una instancia de SQL Express.
También podría utilizarse como el Host de Powershell/PowerCLI.
Los recursos con los que aprovisionaremos esta máquina serán de 4 vCPU, 8GB de RAM y 40GB de
Disco.
Otros servicios a utilizar:
• Servidor DNS
• Servidor DHCP (opcional, no requerido)
• Directorio Activo (opcional, no requerido)
• vCenter Server (opcional, no requerido)
• NSX (opcional, no requerido)
Al utilizar el menor número de recursos posible para la POC no necesitaremos ningún balanceador
web, tampoco certificados digitales emitidos por una CA de confianza ni otros elementos como IPAM
o vRB.
También es posible integrar vRA con vRealize Operations Manager y vRealize Log Insight. Estas
integraciones son muy simples de configurar y, por más que se trate de una prueba de concepto,
aportan un valor considerable al poder ver el rendimiento de las VMs desplegadas y tener un control
de los Logs tanto de vRA como también de los Workflows ejecutados en vRO.
Lo que sí vamos a necesitar van a ser los registros DNS tipo A y PTR para el Appliance de vRA y el
servidor IaaS.
No es necesaria una instancia de Directorio Activo para una POC, aunque sí recomendable para
explicar de forma más simple el uso de los Roles de vRA y el nesting en nuestro dominio de Directorio
Activo.
De cara a darle algo de funcionalidad al POC necesitaríamos una instancia de vCenter con un Cluster
simple que incluso puede estar compuesto de un único Host de ESXi si lo quisiéramos.
NSX tampoco es un requerimiento para vRealize Automation pero utilizar vRA sin NSX es igual a que
el Barcelona deje a Messi en el banco de suplentes.
El diseño Lógico de nuestro POC queda entonces de esta forma:
Componentes de un POC de vRA
Esquema de Instalación para una prueba de concepto de vRA

El orden de Instalación será muy similar al siguiente:
Orden Componente Tareas Imagen
Preparar base de datos SQL. En un POC

1 SQL Server es posible utilizar SQL Express en el mismo
equipo IaaS
Desplegar maquina Windows

2 IaaS Aplicar parches y actualizaciones
Agregar al Dominio
Creación de registros tipo A y PTR

Alta de cuentas funcionales en Directorio
3 DNS y Usuarios Activo basado en roles de vRA
Definir la cuenta administrativa a utilizar en
IaaS
Desplegar Appliance de vRA
4 Appliance vRA Definición de contraseña Root
Configuración de parámetros de Red
Ejecución del asistente desde el equipo IaaS
Asociación de instancia de vRA
Instalación de Agente vRA en IaaS
Validación de requerimientos en IaaS
Configuración de requerimientos en IaaS
Conexión con instancia SQL
Asistente
5 Definición de contraseña Identity Manager
configuración
Configuración credenciales DEM’s
Configuración credenciales Web y Manager
Definición de instancia Agente
Creación de certificados digitales
Pre-validación de los servicios
Instalación de los servicios
6 vRA – IaaS Validación post-instalación (Web, Servicios, Logs)
Asistente de instalación de vRA finalizado correctamente
5. Conceptos de vRealize Automation
Para una correcta comprensión de las siguientes fases debemos comenzar con una breve descripción
de los elementos, algunos lógicos y otros externos como vRO, aunque todos necesarios para la puesta
en marcha de la maquinaria de vRA.
Aclaración: la gran mayoría de la documentación está disponible en idioma inglés. Si bien este libro es
en español vamos a utilizar también conceptos en inglés para una mejor asociación entre los conceptos
y los nombres que podemos encontrar en la mayoría de documentación en idioma inglés.
Tenant: Instancia adicional de vRA que permite segmentar partes de la solución como el Branding,
Autenticación, Recursos y administración. Podemos pensar en un Tenant como una delegación,
división o cliente de una compañía.
Catálogo: El Catálogo de vRA es el elemento que contiene los diferentes tipos de automatizaciones
definidos en los Blueprint.
Tenant y Catálogo de vRA
Endpoint: Es el elemento que nos permite conectar con determinados recursos como una instancia de
vCenter server, NSX, vRealize Orchestrator, vRealize Operations Manager, etc.
Endpoints y DEM conectando a recursos
Fabric: Una vez que temenos configurado el Endpoint y somos capaces de ver los recursos, a esos
recursos los denominamos Fabric. Podemos tener un Fabric de vSphere, AWS, Azure, etc.
Fabric Group: El Fabric Groupo representa una cantidad lógica de recursos que provienen del Fabric.
Como ejemplo podemos mencionar un Cluster de vSphere.
Cluster 1 de vSphere como Recurso en Fabric Group
Reservas (Reservation): Las reservas en vRA son lo opuesto a las reservas en vSphere. Las reservas
de vRA se asignan a Business Groups y establecen un límite de recursos como cantidad máxima
de RAM, de GBs o incluso número máximo de VMs que podríamos desplegar en ese BG (Business
Group) con los recursos presentados a través de la reserva.
Opciones de Reservas de recursos en vRA
Políticas de Reservas (Policy reservation): Utilizamos las políticas de reservas para pre-definir un
tipo de recurso determinado como puede ser un Tier SSD, un Cluster determinado o un Datacenter en
concreto.
Ejemplo de Políticas de Reservas para calidades de Almacenamiento
Business Group: Los BG’s son agrupaciones lógicas que pertenecen a un Tenant determinado.
Una simple analogía podría ser una Unidad Organizativa de Directorio Activo. Entre los ejemplos que
podemos mencionar podrían estar un departamento de la empresa, un proyecto o una sucursal entre
otros.
Asignación de Reservas a log Business Group 1 y 2
Custom groups: En los Custom Groups definimos quién o quienes, normalmente a través de grupos
de Directorio Activo, van a poder diseñar los diferentes tipos de Blueprints.
Creación de Custom Group para definir los Blueprint Architects
Blueprint: Es lo que le da vida a vRealize Automation. Un Blueprint define las reglas y parámetros
de los diferentes tipos de automatizaciones que ofrecemos en el Catálogo de vRA. Podemos tener
Blueprints de máquinas virtuales, contenedores o servicios personalizados (XaaS).
Design canvas donde se configuran los Blueprints en vRA
6. Configuración de vRealize Automation
Una vez completado y validado el diseño, implementado los componentes y verificada la instalación ya
es momento de pasar a la fase de configuración.
En la fase de configuración es donde integramos la implementación estándar con los recursos de

la organización ya sea en los propios centros de datos y/o con los recursos que disponen en Cloud
Publicas.
El orden de implementación de una solución de vRealize Automation puede variar ligeramente en

algunas fases, aunque el procedimiento bastante concreto.
Antes de continuar debemos comprender la diferencia entre los tres sistemas de gestión de identidad
que normalmente nos vamos a encontrar. Es muy fácil confundirse y no podemos comenzar la
configuración con dudas.
Además del Identity Manager, que instala su propio sistema de gestión de identidades, normalmente
vamos a integrar vCenter y Directorio Activo.
Usos de cada sistema de gestión de identidades

Identity Manager: daremos de alta al menos un usuario para la asignación inicial a los roles de IaaS
Admin y Tenant Admin.
Single Sign On: el uso del sistema de gestión de identidades y autenticación de vSphere lo utilizaremos
para gestionar el acceso a los recursos de vSphere.
Directorio Activo: este recurso, integrado en Identity Manager, es lo que normalmente utilizamos en
producción para consolidar las cuentas de usuario finales (usuarios de Business Groups) y también las
de los administradores de vRealize Automation.
Tres sistemas de gestión de identidades
En la pantalla de login de vRA podremos elegir loguearnos con un usuario local del Identitiy Manager
o bien un usuario de Active Directory, siempre y cuando hayamos agregado el dominio de Active
Directory a vRA.
Selección de fuente de identidad en pantalla de Login en vRA
Proceso de Configuración de vRealize Automation

A continuación, describiremos el proceso de configuración de una instalación simple de vRA, partiendo
de la base de un vRA Appliance y un IaaS ya instalados.
Expondremos primero una tabla para identificar el orden, el elemento, las tareas y el rol con el que
debemos hacer la configuración.
Resumen del proceso de Configuración de vRA
Veamos cada paso de forma general.
Nuevo Tenant
Creación del Tenant, definición de la URL y alta de al menos un usuario local que será gestionado por
Identity Manager.
Alta de usuarios locales en vRA
Roles en nuevo Tenant
Definición del Tenant Admin y el IaaS Admin. El Tenant Admin podrá crear los Business Groups y todo
lo relacionado con el Tenant. El IaaS Admin podrá configurar los Endpoints y crear el Fabric Group.
Definición de Roles en nuevo Tenant
Configuración de Endpoints
Cualquier usuario con el Rol de IaaS Admin podrá configurar los Endpoints. Dependerá de los recursos
de la organización y el proyecto en general pero normalmente configuramos Endpoints para vCenter,
NSX, vRealize Orchestrator (por más que utilicemos la instancia embebida) y también vRealize
Operations Manager.
Configuración de Endpoints
Integración Active Directory
Logueándonos con el Rol del Tenant Admin en el default Tenant podremos configurar la integración de
Active Directory con nuestro vRealize Automation. Este paso es de vital importancia para poder utilizar
grupos de Active Directory a medida que vamos creando y configurando componentes.
Integración de dominio de Active Directory en vRA
Creación de Fabric Group
Un usuario con el Rol de IaaS Admin será capaz de crear los Fabric Groups. Como parte del
procedimiento de la creación de los Fabric Groups deberemos definir quiénes serán los usuarios y/o
grupos del Rol de Fabric Group Admin. Esos usuarios serán los encargados de configurar las reservas
de recursos.
Alta de un nuevo Fabric Group
Configuración de Network Profiles
Independientemente de si estamos trabajando con NSX o no, deberemos configurar los Network
Profiles. Es en estos elementos cuando definiremos la lógica de los servicios de Red con parámetros
como segmentos IP, puertas de enlace, servicios DNS y dominios. Los Network Profiles pueden ser
External, NAT y/o Routed.
Durante la creación de las Reservas se asociará un Network Profile con un Port Group o Virtual Network.
Configuración de un Network Profile de tipo External
Creación de Business Groups
Los Recursos de los Fabric Groups y los Blueprints se asignan a los Business Groups. Antes de crear
una Reserva para asignar recursos de Computo y Almacenamiento tendremos que disponer de al
menos un Business Group.
Como parte del procedimiento de creación del BG deberemos definir los roles de BG Manager, Support,
Shared y User. Serán estos últimos, los usuarios del Business Groups, los que podrán hacer peticiones
de ítems del Catálogo.
Creación de un Business Group
Configuración de Reserva
Como hemos visto son múltiples las tareas de configuración que debemos completar antes de poder
asignar recursos a un BG a través de una reserva.
El concepto de Reserva en vRealize Automation es prácticamente el opuesto que en vSphere. Mientras

que en vSphere una Reserva es una promesa de recursos, en vRA hablamos de un ámbito de recursos
y un límite estipulado de los mismos.
En la Reserva podremos definir el límite de VMs, cantidad máxima de RAM y los Datastores con su
correspondiente límite.
Configuración de una Reserva de vSphere
Creación de grupos personalizados
Llegados a este punto ya disponemos de recursos en, al menos, un Business Group del Tenant.
Eso significa que toca comenzar a diseñar Blueprints, pero antes necesitaremos los privilegios
correspondientes. Eso lo hacemos a través de grupos especiales o personalizados que configuraremos
en vRealize Automation.
Los grupos personalizados o Custom Groups nos permiten crear Roles con diferentes privilegios para
trabajar con Blueprints de diferentes tipos.
Creación de Grupos para la definición de Roles de diseño de Blueprints
Listos para diseñar Blueprints
Hemos pasado ya por la fase de Diseño, la instalación de los componentes y su validación, la

configuración de todos los elementos lógicos de vRA y además disponemos del Rol necesario para,
finalmente, poder comenzar con el diseño de los Blueprints.
Un usuario con los Roles de Tenant Admin, IaaS Admin y Arquitecto de aplicaciones y Administrador
de contenedores podrá ver el siguiente menú en vRA:
Vista de la interface de usuario en vRA con todos los Roles
En este punto estaremos listos para comenzar con el diseño y publicación de Blueprints con sus
correspondientes Parámetros, Custom Properties, etc.
No obstante, antes de comenzar con la creación de Blueprints, necesitamos comprender la integración

entre vRA y NSX. .
7. Integración de NSX y vRealize Automation
La combinación de NSX como plataforma de virtualización de Redes y vRealize Automation nos aporta
un control total a la hora de trabajar con los Blueprints, siempre alineados con los requerimientos y
procedimientos pre-definidos de seguridad.
vRealize Automation 7.5 está soportado para trabajar tanto con NSX-V como también con NSX-T. Este
capítulo lo basaremos en una integración de vRealize Automation y NSX-V.
Comenzaremos bien desde abajo hasta llegar a los Network Profiles y las Reservas de forma que,
cuando estemos trabajando con los Blueprints, seamos capaces de comprender correctamente la
integración de los servicios de red con vRA.
vCenter y NSX
• NSX se registra en vCenter y se comunican vía API
• Por cada vCenter se podrá registrar un único NSX en relación 1:1
• NSX necesita trabajar con una base de un virtual distributed switch (vDS1)
• Por cada Logical Switch de NSX se creará un Port Group de base en vDS1
• Los Port Groups de un vDS normalmente están aislados entre sí con vLans
• Los Logical Switches utilizan la encapsulación de VXLAN
• Los DLR son Distributed Logical Routers y están embebidos en el ESXi
• Los DLR pueden trabajar con rutas estáticas, OSPF y BGP
• Los DFW son los Firewall Distribuidos y están embebidos en el ESXi
• Los DFW aportan la Microsegmentación
• Los Microsegmentación se gestiona con los Security Groups y Security Tags
Esquema lógico de vCenter y NSX
vRA, vRO, vCenter y NSX
Se va sumando gente al baile decían en mi pueblo. Una vez que tenemos la base mínima del esquema
lógico entre vCenter y NSX es tiempo de sumar vRealize Automation y vRealize Orchestrator. Es hora
de hacer amigos y registrar las diferentes soluciones entre sí.
Independientemente de que utilicemos una instancia embebida de vRO o si utilizamos la instancia

interna del Appliance de vRA, debemos registrar el Endpoint de vRO en vRA.
Registro de vRO en vRA
En su momento registramos como Endpoints tanto vCenter como también NSX. Tenemos que
asegurarnos de establecer la asociación entre ambos Endpoints en vRA.
En el supuesto caso de tener un segundo o tercer vCenter haremos lo propio con cada instancia y su
correspondiente instancia de NSX Manager.
Asociación entre un Endpoint de vCenter y un Endpoint de NSX
Además de los Endpoints de vRA, gestionados por el IaaS, con vCenter, NSX y vRO es necesario
hacer lo propio en vRealize Orchestrator. Ejecutaremos los Workflows de vRO para registrar tanto la
instancia de vCenter como también de NSX.
Workflows en vRO para registros de vCenter y NSX
Una vez configurados los cuatro Endpoints y la correspondiente asociación entre los Endpoints de
vCenter y NSX en vRA tendremos algo como lo siguiente:
Esquema Lógico entre vRA, vRO, vCenter y NSX
Network Profiles y Redes en vRealize Automation
Una vez definidos los accesos a los recursos de red en vRA, a través de los Endpoints de vRA y vRO,
debemos pasar a la parte lógica.
Por un lado, vamos a configurar los Network Profiles para pasar luego a la asociación de los recursos
lógicos (Network Profiles) con los recursos virtuales (Port Groups o Logical Switches).
Lo primero que vamos a definir a la hora de crear un Network Profile es definir el tipo de red. Veamos
los tres tipos de redes y sus características.
Creación de Network Profiles en vRealize Automation
Tipos de redes en vRealize Automation
External: funciona como un segmento independiente que podría tener acceso a una red superior
como Internet. Necesita un Port Group o Logical Switch creado previamente.
NAT: es un segmento de red que utilizará una instancia de NSX Edge para separar una red Externa
y el segmento interno utilizando reglas NAT. Las VMs se conectarán al segmento interno y es posible
definir las reglas NAT como parte del Blueprint.
Routed: el tipo de red enrutada utilizará un segmento interno, pero estará conectada a un interface
virtual de un Distributed Logical Router que nos permitirá conectarnos a una red superior como puede
ser una red External.
Esquema lógico de redes en vRealize Automation
Según podemos apreciar en el esquema anterior, una red External únicamente requiere un Port Group
o un Logical Switch además de los parámetros necesarios como DNS, rango de IP y puerta de enlace.
Creación de un External Network Profile
Para crear un Network Profile de tipo NAT vamos a necesitar de los servicios de NSX. Tanto la instancia
de NSX Edge, su configuración, como también el Logical Switch se crearán bajo demanda según
definición del Blueprint.
Se requiere definir el tipo de NAT a configurar (one-to-one o one-to-many) y además es posible definir
un ámbito DHCP junto con los parámetros de red.
Creación de un NAT Network Profile
Cuando creamos un Network Profile Routed, además de requerir los servicios de NSX, debemos tener
pre-configurado un DLR el cual asociaremos a la hora de crear la Reserva. Como se puede ver en la
siguiente imagen, debemos apuntar a una External Network.
Creación de un Routed Network Profile
Configuración de Network Profiles en Reservas
Si bien mencionamos anteriormente las Reservas, una parte fundamental es la asociación entre los
Network Profiles y los Port Groups (en caso de no utilizar NSX) o los Logical Switches.
Asociación de un Logical Switch y un Network Profile en una Reserva
Como parte de los servicios de red de NSX en vRealize Automation existe una cantidad importante de
configuraciones y opciones que están fuera del alcance de este libro, aunque da lugar perfectamente
para un libro solo de esa temática.
No obstante, merece la pena recomendar el eBook “VMware NSX Automation Fundamentals” de

descarga gratuita (en idioma Inglés).
Libro NSX Automation por autores y colaboradores de primer nivel
8. Conceptos de Blueprints
El Catálogo de vRealize Automation está clasificado en tipos de servicios y basado en los diferentes
Blueprints.
Para ser capaces de ofrecer lo que conocemos como “Ítems del Catalogo” o “Catalog Ítems” debemos,
además de crear el Blueprint, definir los permisos y privilegios que permitirán a un usuario de un
Business Group hacer un “Request” de un Catalog Item. A este proceso le llamamos “Entitlement”.
Existen diversos tipos de Blueprint, algunos simples y otros complejos.
Veamos algunos ejemplos.
Máquina simple: Despliegue de maquina Windows server con direccionamiento IP estático de un pool
predefinido gestionado por el IPAM de vRA. La máquina se agregará automáticamente al dominio y,
según el usuario que hace la petición, se creará en la Unidad Organizativa correspondiente.
El usuario que solicita la nueva máquina será miembro del grupo de Administradores Local. Cuando
la maquina se elimine desde vRealize Automation se eliminará la cuenta de equipo en el dominio y se
liberará la IP del Pool seleccionado en el Blueprint.
Multi Máquina: Despliegue de dos instancias de Linux Debian. Se establecerá el hostname de forma
manual durante la solicitud. Se creará automáticamente la contraseña de ambas cuentas root siguiendo
las directrices de seguridad pre-establecidas.
Los registros DNS tipo A y PTR se crearán en el la zona DNS como parte del despliegue. Se habilitará
el servicio SSH en ambas instancias y en la primera máquina se instalará Apache como parte de la
configuración inicial utilizando un script de la librería de Software. En la segunda maquina se instalará,
también automáticamente, PostgreSQL. Ambas maquinas estarán conectadas a la misma red y tendrán
acceso a Internet a través de una instancia NSX Edge.
El usuario que solicitó el Ítem del Catalogo recibirá un mail una notificación confirmando el correcto
despliegue de las maquinas. Un documento PDF adjunto en el mail entregará los parámetros como
direcciones IP, métodos de acceso y contraseñas de las cuentas root.
Aplicaciones con servicios de Red: Cuando el usuario de vRealize Automation hace la petición del
Ítem del Catalogo deberá seleccionar el Datacenter en donde se desplegarán las maquinas que darán
soporte a las Aplicaciones.
Una vez seleccionado el Datacenter se crearán dos instancias de Windows Server y SQL Server con
los servicios de AlwaysOn automatizado con Powershell. De forma adicional, otras dos instancias de
Windows Server con los servicios de IIS se desplegarán en la misma red.
Un NSX Edge se creará bajo demanda y se configurarán los servicios de Balanceador Web para los
servicios IIS. Por requerimientos de seguridad se creará una segunda red sin acceso a Internet y
conectará un segundo vNic únicamente en las maquinas IIS.
Máquinas en Cloud Pública: Se creará una instancia de maquina Linux en la Cloud Publica (Azure,
AWS, Etc) y se conectará a un almacenamiento adicional provisto por el mismo proveedor Cloud.
Servicio XaaS: El servicio ofrecerá un Túnel VPN bajo demanda. Además del nuevo Peer, que
se establecerá como parámetro definido por el usuario, se generará la clave compartida de forma
automática definiendo el direccionamiento privado. Se creará una cuenta de usuario en Directorio
Activo que servirá como autenticación interna. La nueva cuenta creada se agregará a un grupo de
usuarios y Unidad Organizativa predefinida.
Como hemos podido ver las posibilidades son prácticamente infinitas. Es cierto que si bien algunos
Blueprints son fáciles de crear y configurar, otros pueden llegar a ser un desafío. ¿Lo mejor de todo?
Las posibilidades.
En el siguiente esquema vemos un esquema lógico en el que conectamos los recursos de vCenter y
NSX con la Reserva y un Blueprint asignado a un catálogo de un Business Group determinado.
Esquema lógico de recursos, reservas, blueprint y catálogo
Objetos gestionados
En vRealize Automation tenemos básicamente dos tipos de Blueprints. Por un lado están los Blueprints
que crean objetos como puede ser una máquina virtual. A estos objetos les llamamos “gestionables”
o “managed ítem” debido a que será posible ejecutar determinados workflows sobre esos objetos o
ítems.
Los otros tipos de Blueprints ejecutan workflows como por ejemplo el cambio de una contraseña o la
ejecución de un backup bajo demanda lo cual no permite ejecutar ningún tipo de workflows sobre el
resultado.
Una vez que un workflow finaliza el despliegue de un objeto gestionado, en ese preciso momento,
comienza lo que llamamos “Día 2”.
Las operaciones del día 2, también llamadas Resource Actions, permiten ejecutar workflows para
tareas de mantenimiento, parcheado, actualizaciones o cambios en la maquetación.
Esos Resource Actions están basados en workflows de vRealize Orchestrator.
Event Broker
Otra forma de trabajar con las operaciones del día 2 es a través de las subscripciones de Event Broker.
Event Broker nos permite identificar un momento determinado del ciclo de vida de la máquina virtual
como puede ser un reinicio, la ejecución de un snapshot, un redimensionamiento o incluso una

aprobación.
Creación de una subscripción de Event Broker
Es posible además considerar múltiples variables como el Tenant, la Reserva, el Usuario o el Datacenter
para concretar la subscripción.
La subscripción ejecutará un Workflow de vRealize Orchestrator en base al criterio necesario.
Definición de condiciones en una subscripción de Event Broker
Las subscripciones de Event Broker permiten personalizar aún más si cabe no solamente la creación
de recursos, sino que permiten controlar prácticamente la totalidad del ciclo de vida de una máquina
virtual.
En esta edición del libro las operaciones del día 2 así como también Event Broker está fuera del
alcance.
9. Creando un Blueprint básico
No podíamos terminar el capítulo de vRA sin ver cómo crear al menos un Blueprint básico.
Veremos a continuación una guía paso a paso sobre cómo crear un Blueprint para un despliegue
simple de una máquina virtual.
1 – Creamos el Blueprint y definimos el nombre del Blueprint
Opciones de Blueprint para limitar el tiempo que las VMs estarán disponibles
2 – Selección de Transport Zone
El Transport Zone define el ámbito de Virtual Networks entre Clusters
3 – En el Design Canvas seleccionamos Machine Types, vSphere (vCenter) Machine y la arrastramos

al centro del canvas.
El Design Canvas en donde agregamos, modificamos y quitamos elementos del Blueprint
4 – Seleccionamos el objeto máquina virtual y veremos las propiedades del objeto. En la pestaña
General podremos definir el ID de la VM, seleccionar el número máximo de instancias a solicitar (en
este caso solo 1) y seleccionar un Policy Reservation y un Machine prefix para asignar un nombre
automático al objeto VM en el inventario de vCenter.
Propiedades de objeto máquina virtual
5 – En Build Information tenemos la opción de seleccionar el modo de despliegue que puede ser
Create, Clone o Linked Clone.
En este caso la maquina se creará de forma rápida utilizando Linked Clone, para lo cual necesitaremos
seleccionar un Snapshot.
Podremos además apuntar a un Customizacion spec que no es más que el VM Customization

specifications del vCenter. A tener en cuenta que el nombre distingue entre mayúsculas y minúsculas.
Opciones de clonado de la VM
6 – En Machine Resources definiremos la cantidad de recursos mínimos y máximos que un usuario

podrá solicitar en este Blueprint.
Es muy frecuente que en entornos en producción se definan políticas de aprobación cuando se solicita
una cantidad de recursos de CPU, RAM o Disco fuera de lo normal.
Definiendo la cantidad de recursos del Blueprint
7 – En Storage es posible agregar un disco virtual adicional definiendo en número máximo de volúmenes.
Algo muy interesante es definir de forma estática la política de almacenamiento o bien ofrecer que el
usuario pueda elegir por sí mismo.
Opciones de Almacenamiento de la VM
8 – La configuración de red la definimos en la pestaña Network. Las opciones son agregar una o
múltiples vNics a la VM. En la siguiente imagen podemos ver que no hay red disponible. Es normal, lo
resolvemos en el siguiente punto.
Configuración de red sin recurso para conectar la vNic
9 – Debemos hacer click en un espacio vacío del Design Canvas y a continuación seleccionar Network
& Security en el menú lateral. Seleccionaremos y arrastraremos Existing Network a un espacio vacío
del canvas.
Agregando recurso de red al Blueprint
10 – Cuando seleccionamos el objeto Existing Network veremos inmediatamente las propiedades.

Debemos hacer click en el botón a la derecha de Network profile y seleccionaremos un Network profile
de la lista de las External Networks.
Este elemento ya lo vemos familiar verdad?
Todavía podemos ver en el Canvas que el objeto VM y el objeto External Network están separados.
Solo de momento…
Asignando un Network Profile al External Network
11 – Seleccionamos nuevamente el objeto VM y, en Network, comprobaremos que ahora está disponible

para “conectar” nuestro Network Profile.
Una vez seleccionado podremos definir el tipo de direccionamiento IP.
Asignando un Network Profile a la VM
12 – Podremos verificar en el canvas que el objeto VM está conectado a la External Network.
Vista de la VM conectada al External Network
13 – Guardaremos el Blueprint y cerraremos el Design Canvas haciendo click en Save y Finish. Esto
cerrará el Blueprint y podremos ver que, por defecto, el Status está en modo Draft.
Es muy importante seleccionar (no editar) el Blueprint y hacer click en Publish para que podamos
proceder con el procedimiento de Entitlement.
Vista del elemento Blueprint en modo Draft
14 – Es momento de asociar el Blueprint a un servicio y configurar el Entitlement para permitir que

usuarios del Business Group puedan ver el Blueprint (luego del Entitlement será Catalog Item) y hacer
su correspondiente solicitud.
Creando un servicio en vRA
Los servicios en vRA son útiles para agrupar conjuntos de Blueprints / Catalog Ítems en común. Por
ejemplo maquinas Windows, maquinas Linux, servicios AWS, operaciones de Backup, etc.
15 – Una vez creado el servicio agregaremos el Blueprint, también llamado en esta instancia ítem.
Asignando un Blueprint a un Servicio
16 – La asignación de privilegios sobre quién será capaz de realizar una solicitud al Blueprint y qué
acciones podrá ejecutar sobre la VM ya desplegada la definimos en el Entitlement.
Entitlements en vRA
Para crear un Entitlement simplemente haremos click en New y seleccionaremos el Servicio, el

Blueprint, los usuarios del Business Group y las acciones que permitiremos ejecutar.
Selección de usuarios y definición de estado del Entitlement
Asociando el servicio, el blueprint y las acciones
16 – Finalmente después de 40 páginas leídas podremos ver un objeto en el Catálogo de vRA ;-)
Ítem en el Catálogo de vRA
17 – Ahora es cuando hacemos click en REQUEST para comenzar la solicitud. Podemos completar los
datos de Descripción y su justificación y hacer click en SUBMIT.
Ejecutando una solicitud en el Catálogo de vRA
18 – Verificando el despliegue de la solicitud en Deployments.
A los pocos segundos de ejecutada la solicitud podremos ver en vCenter el trabajo de clonado de la
VM.
Vista de los despliegues en vRealize Automation
19 – Al cabo de unos pocos minutos ya podremos ver la VM tanto en vRealize Automation como
también en vCenter.
Ítem disponible en vRA
10. Resumen y recomendaciones
Como hemos visto a lo largo de todo el capítulo, tanto la instalación, configuración como también el
diseño del Blueprint lleva un trabajo considerable.
Son muchos los elementos que deben funcionar de forma coordinada para llevar a cabo una correcta
implementación de vRealize Automation.
No obstante la recompensa es alta y sobre todo gratificante.
Cada Blueprint, Workflow y parámetro puede llegar a ser un verdadero desafío que nos pondrá a
prueba.
vRealize Automation es el tipo de solución que verdaderamente aporta valor a la organización. Pero no
solo a la organización, sino que también a nosotros mismos como profesionales.
Evidentemente no es una herramienta para cualquier tipo de empresa como sí puede ser un Host de
ESXi, pero también podemos verlo como una oportunidad de marcar la diferencia respecto a nuestro
perfil profesional.
También es cierto que esta solución es exigente en cuanto a cantidad de recursos y eso incrementa
la dificultad a la hora de invertir horas de práctica pero no debemos olvidar los Hands On Labs de
vRealize Automation como un recurso muy valioso y que tenemos a nuestra disposición en cuestión
de minutos y de forma totalmente gratuita.
Lista de laboratorios de vRealize Automation disponibles en VMware Hands On Labs
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 17
Automatizando vSphere con
Ansible
Miquel Mariano
Capítulo 17 - Automatizando vSphere con Ansible Miquel Mariano
Ansible
1. Introducción a la automatización de tareas
Igual James Cameron no iba tan desencaminado cuando escribió el guión de Terminator y llegará un
día en que Skynet domine el mundo.
En un futuro, cada vez menos lejano, las máquinas serán lo suficientemente inteligentes como para
averiguar lo que queremos que hagan y hacerlo.
Estamos dando pasos agigantados en cuanto a IA y machine learning pero todavía, los humanos, nos
pasamos muchísimo tiempo “diciendo” a las máquinas las cosas que queremos que hagan.
En el mundo de las TI no es una excepción, y los administradores, dedicamos mucho tiempo a tareas
de operación que nos consumen gran parte de nuestra jornada. Crear y configurar un nuevo usuario,
desplegar una nueva VM o servicio o simplemente escalar una aplicación que se nos ha quedado corta
de recursos son algunos de los ejemplos más clásicos.
Seguro que estaréis de acuerdo conmigo en que en vuestro día a día hay decenas de tareas repetiti-
vas y que sería ideal automatizar, pero ¿por qué?
• Por la disminución y menor posibilidad de errores
Siento ser tan directo y deciros esto, pero cometéis errores, cometemos errores. Todos lo hace-
mos. Continuamente, los humanos, malinterpretamos las cosas, leemos mal, nos olvidamos de
algunas tareas, hacemos las tareas en el orden equivocado…Eso es así, y es por eso por lo que
la automatización nos permite salirnos de la ecuación y dejar que los sistemas hagan por si solos.
• Por el ahorro de tiempo
Todo lleva tiempo: iniciar sesión en consolas, buscar configuraciones, conectarse a servidores, es-
cribir comandos. Especialmente cuando, según el punto anterior, arruinamos algo y tenemos que
arreglarlo. Una vez más, simplemente dejemos que los sistemas lo hagan. Dediquemos nuestro
tiempo a innovar, a pensar cómo automatizar más cosas.
• Por la auto documentación
En nuestro día a día, estamos acostumbrados a tratar con infinidad de documentación de insta-
lación y configuración de nuestros sistemas, tareas y operaciones. Esta documentación requiere
de un gran esfuerzo para mantenerla actualizada e inevitablemente en muchos casos se descuida
y entra en desuso. Infrastructure as Code / Programmable Infrastructure son conceptos que nos
permiten a través de código tener una visión clara tanto de la configuración como de la implemen-
tación de un sistema o tarea con sus pasos a seguir bien definidos. Además, en muchos casos, la
configuración inicial y el ciclo de vida de un sistema se automatiza. De esta forma siempre tenemos
el código con la configuración actual sin necesidad de mantener documentación paralela.
• Por la reproducibilidad
Reproducibilidad significa que tenemos que ser capaces de reproducir o recrear nuestro sistema
de manera fácil y rápida.
Se nos puede dar el caso que queramos un entorno paralelo de pruebas para probar nuestros de-
sarrollos o poniéndonos en lo peor, podríamos perder todo nuestro sistema.
Tenemos un servicio X que funciona perfectamente, pero el día menos pensado tenemos una con-
tingencia grave y se pierde todo.
Tenemos los datos bien salvaguardados en copias de seguridad, pero hay que montar de nuevo
toda la infraestructura y la persona que en su día se encargó ya no está en la empresa y sólo dejo
un documento básico de instalación. Seguimos ese documento al pie de la letra, pero no hay ma-
nera de que eso funcione ☹.
Con la automatización y la Infrastructure as Code que comentábamos antes eso es posible, ya que
tenemos el código con la última configuración de ese sistema y seriamos capaces de repetir esas
configuraciones tantas veces cómo nos sea necesario.
2. Terminología
Antes de nada, me gustaría dejar una pequeña recopilación de conceptos y definiciones que vamos a
encontrarnos continuamente al trabajar con Ansible:
• Facts: Información útil de los nodos.
• Inventario: Incluye información, estática o dinámica, de los nodos administrados y su información.
• Módulos: Son las librerías que se utilizan para controlar elementos como ficheros, servicios paque-
tes o comandos. Estos se copian al nodo cliente para que ejecute la tarea indicada.
• Nodo: Objeto a administrar, ya sea un servidor, un router y otro elementos.
• Nodo de control: Máquina donde está instalado Ansible engine y que será desde donde adminis-
tremos el resto de nodos.
• Play: Lista de tareas a realizar en los clientes especificados en el Playbook.
• Playbook: Se encarga de definir todas las tareas que debemos realizar sobre un conjunto de hosts
clientes.
• Roles: Es una agrupación de tareas, ficheros y plantillas, que pueden ser reutilizados.
• Task: Definición de una acción a realizar.
3. Introducción a Ansible
Ansible es una herramienta que nos permite el manejo de configuraciones y despliegue de aplicacio-
nes de manera sencilla.
Esta plataforma de código abierto fue creada por Michael DeHaan como startup en 2013 y fue adqui-
rida por RedHat a finales de 2015.
Dentro de la filosofía de Ansible cabe destacar los siguientes puntos:
• No requiere de agentes en los “clientes”
Suficiente con una clave SSH y un intérprete de python, disponible nativamente en la mayoría de
SO modernos.
• Utiliza lenguaje YAML, muy intuitivo y de fácil comprensión
Eso nos proporciona una suave curva de aprendizaje y en poco tiempo podemos tener implemen-
tada la solución.
• Ahorra tiempo en el despliegue masivo de configuraciones
A través de los playbooks y roles, seremos capaces de desplegar nuestras configuraciones masi-
vamente sobre un inventario de servidores.
• Reduce el % de error humano en la configuración de nuevos servicios.
Una vez tengamos nuestros playbooks y roles definidos ya no deberemos preocuparnos por el
factor humano. Todas nuestras configuraciones estarán basadas en la definición inicial.
• Trabaja con la propiedad de idempotencia
Una instrucción o comando no se ejecutará más veces una vez alcanzado el estado deseado.
• Es OpenSource
Tiene una comunidad muy activa con infinidad de módulos específicos.
Por poner alguna desventaja, comentar que:
• Necesita Python tanto en el nodo de control como en las máquinas a configurar.
• El nodo de control no puede ser un Windows. Es recomendable RedHat, CentOS o Fedora.
Los principales beneficios de Ansible, los hemos comentado anteriormente. Reducir el factor humano
frente a errores, ahorro sustancial de tiempo en tareas repetitivas, auto documentación y poder repro-
ducir fácilmente las operaciones o tareas.
Ansible, se conecta a los equipos que queremos configurar utilizando una clave SSH i a través de este
canal, le envía las instrucciones y configuraciones que queramos aplicar.
Hay que tener en cuenta también que todo lo que queramos hacer lo puede procesar en paralelo, así
que es lo mismo tener que configurar 1, 5, 10 que 50 servidores a la vez.
4. Introducción a YAML y ejemplos
YAML es el lenguaje en el que se definen los roles, los playbooks y demás estructuras en Ansible. Su
nombre son las siglas de Yet Another Markup Language (Otro lenguaje de marcado más) o recursi-
vamente YAML Ain`t Markup Language (YAML no es un lenguaje de marcado), depende de a quién
preguntemos nos encontraremos con una u otra definición.
Como comentábamos, es un lenguaje de marca, simple, basado en ficheros de texto plano y pensado
para ser legible por humanos. En el mundillo del software y juntamente con XML, este es el formato
más extendido para guardar información de configuraciones.
Que Ansible utilice YAML para las definiciones de sus roles y/o playbooks, nos proporciona las siguien-
tes ventajas:
• Conveniencia: No es necesario especificar todos los parámetros en el propio fichero YAML, sino
que a través de variables podremos añadir estos parámetros a través de la línea de comandos en
función de nuestras necesidades.
• Mantenimiento: Los ficheros YAML, al ser texto plano, puede ser gestionados por un sistema de
control de versiones (git o similar), de manera que se pueden registrar los cambios.
• Flexibilidad: Es posible crear estructuras mucho más complejas usando ficheros YAML ya que
podemos hacer que éstos se llamen entre sí.
Dada su sencillez basta con conocer un poco sus estructuras básicas para empezar a crear fiche-
ros para Ansible.
4.1 Mapas YAML
Clave – Valor
Podemos usar relaciones clave-valor en YAML poniendo la clave ‘dos puntos’ valor, en caso de que el
valor sea una cadena no es necesario que este entre comillas, aunque por legibilidad es recomenda-
ble:
Relación Padre – Hijo
La relación padre-hijo en YAML se hace escribiendo la etiqueta padre seguido ‘dos puntos’ y después
en la linea siguiente identado** por dos o más espacios los hijos, siempre hacia abajo y conservando
los mismos espacios para cada hijo del mismo padre:
**https://es.wikipedia.org/wiki/Indentaci%C3%B3n
4.2 Listas en YAML
Relación Clave-Lista
En caso de la clave contenga una lista de valores podemos poner los valores dentro de corchetes []
separados por comas, p.e : [valor1,valor2,valor3] :
La otra forma de hacer una lista es escribiendo los valores como si fueran hijos de la etiqueta valor,
pero identificándolos con un guion -, posicionando cada elemento de la lista hacia abajo.
Relación clave-lista-lista
Igualmente, los elementos de una lista también puede ser un conjunto de valores, es decir, otra lista.
Esto se puede ilustrar de la siguiente manera:
Para finalizar este punto, me gustaría compartir con vosotros algunos consejos generales a la hora de
crear un fichero YAML:
TIP: Usa siempre la codificación UTF-8 para evitar errores.

No uses nunca tabulaciones, mejor utilizar espacios.
Usa una fuente monoespaciada para visualizar/editar el contenido de los ficheros YAML.
(siempre que no trabajes desde la línea de comandos).
5. Instalación
El proceso de instalación de Ansible es bastante sencillo. Hay que tener en cuenta que Ansible no
requiere de ninguna BBDD ni de ningún servicio/daemon a ejecutar. Bastará con la instalación de la
paquetería necesaria en la máquina que actuará como “nodo de control”.
Ansible se puede instalar sobre multitud de plataformas como RHL, Debian, CentOS, OS X…. El único
requisito va a ser que el SO del “nodo de control” cuente con el intérprete de Python 2.6 o superior.
Actualmente está disponible en la mayoría de SO de forma nativa.
A día de hoy, la instalación del “nodo de control” no está soportado sobre plataformas Windows y, al ser
propiedad de Red Hat, se recomienda la instalación sobre RHL, CentOS o Fedora.
A continuación, veremos los pasos a seguir para la instalación de Ansible en las principales distribu-
ciones:
YUM
APT-Ubuntu
Debian
TIP: Al ser un producto de Red Hat se recomienda su instalación sobre SO Red Hat, CentOS o
Fedora
Aquí podéis ver el proceso de instalación sobre un CentOS 7.
6. Configuración de Ansible
Ansible, permite diferentes formas de proporcionar variables de configuración.
A través de variables de entorno, directamente en tiempo de ejecución a través de la línea de comando

o en un archivo de configuración llamado ansible.cfg.
Las opciones que vienen por defecto son bastante correctas y suficientes para empezar, pero hay al-
gunos parámetros que podremos modificar con dicho fichero de configuración.
A mí personalmente me gusta modificar la variable donde indicamos donde se guardan los roles, más
que nada para seguir una cierta coherencia en el árbol de directorios, que ahora veremos.
# additional paths to search for roles in, colon separated

roles_path = /etc/ansible/roles
Los cambios que hagamos y usemos en este fichero de configuración se aplicarán en el siguiente
orden:
• ANSIBLE_CONFIG (variable de entorno si está configurada)
• ansible.cfg (en el directorio actual de trabajo)
• ~/.ansible.cfg (en el directorio home del usuario)
• /etc/ansible/ansible.cfg
De esta manera, por ejemplo, puede ser muy útil para que diferentes usuarios en el mismo “nodo de
control” tengan configuraciones diferentes.
NOTA: Podréis leer mas sobre el fichero ansible.cfg en la documentación oficial

https://docs.ansible.com/ansible/latest/reference_appendices/config.html
Con la instalación inicial de Ansible, se crean una serie de ficheros y directorios en /etc/ansible.
En este directorio se encuentra el fichero de configuración que antes comentábamos ansible.cfg, un

fichero de inventario llamado hosts y una carpeta para guardar los roles.
[root@localhost ansible]# ll /etc/ansible/

total 24
-rw-r--r--. 1 root root 20276 ene 25 16:10 ansible.cfg
-rw-r--r--. 1 root root 1015 ene 25 17:01 hosts
drwxr-xr-x. 3 root root 27 ene 31 19:09 roles
Cómo buena práctica, yo os recomiendo crearos dos directorios más y llamarlos inventory, para guar-
dar ficheros de inventario y playbooks, para guardar playbooks.
[root@localhost ansible]# ll /etc/ansible/

total 24
-rw-r--r--. 1 root root 20276 ene 25 16:10 ansible.cfg
-rw-r--r--. 1 root root 1015 ene 25 17:01 hosts
drwxr-xr-x. 2 root root 36 ene 31 19:57 inventory
drwxr-xr-x. 2 root root 44 ene 31 19:08 playbooks
drwxr-xr-x. 3 root root 27 ene 31 19:09 roles
Ha llegado el momento de generar nuestra pareja de claves para desde el nodo de control, poder ad-
ministrar otros servidores. Eso se hará con el comando ssh-keygen de la siguiente forma:
[root@localhost ansible]# ssh-keygen

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/certificado
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/certificado.
Your public key has been saved in /root/.ssh/certificado.pub.
The key fingerprint is:
SHA256:JEvMdbfL4rz5VAlkqdBtnxnw3Ux2+557eu69dVOYe54 root@localhost.localdomain
The key’s randomart image is:
+---[RSA 2048]----+
| ....=o +|
| o ....++o.=+|
| = .. oo..=+|
| . + .. o++.|
| . S . o = o|
| o . . oo|
| o . .o=|
| + oX|
| o.. .EB|
+----[SHA256]-----+
[root@localho
Una vez tengamos el par de claves generada, tendremos que copiarla en todos nuestros servidores
que queramos controlar con Ansible. Como el libro está enfocado a VMware, vamos a ver como copiar
la clave en el mismo servidor de Ansible y luego entramos en detalle con los ESXi.
[root@localhost ansible]# ssh-copy-id -i /root/.ssh/certificado

certificado certificado.pub
[root@localhost ansible]# ssh-copy-id -i /root/.ssh/certificado ansible-control-node
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: “/root/.ssh/certificado.
pub”
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any
that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now
it is to install the new keys
Number of key(s) added: 1
Now try logging into the machine, with: “ssh ‘ansible-control-node’”

and check to make sure that only the key(s) you wanted were added.
[root@localhost ansible]#
Ahora que ya tenemos las claves generadas y copiadas en el servidor que queremos controlar (como
demo hemos metido a si mismo) podremos comprobar si realmente funciona. Para ello necesitaremos
un inventario.
Un inventario, es una lista de nodos accesibles por Ansible, es decir, que tienen ya la clave pública
copiada. Este inventario se define en un fichero de configuración en formato INI y su ubicación prede-
terminada es /etc/ansible/hosts.
Se puede utilizar perfectamente este fichero, pero lo recomendado es que nos creemos nuestros pro-
pios inventarios y los almacenemos en el directorio que hemos definido previamente para tal labor.
Vamos a ser originales y vamos a crear el fichero /etc/ansible/inventory/servidores.
[root@localhost ansible]# touch inventory/servidores

[root@localhost ansible]# cat inventory/servidores
ansible-control-node
He añadido el propio nodo de control que por DNS se resuelve como ansible-control-node.
Este fichero de inventario puede tener también grupos de servidores [grupo] o incluso definir rangos
esxi[01-10].
En el fichero predeterminado hosts encontraremos diferentes ejemplos.
[root@localhost ansible]# vim hosts

# This is the default ansible ‘hosts’ file.
#
# It should live in /etc/ansible/hosts
#
# - Comments begin with the ‘#’ character
# - Blank lines are ignored
# - Groups of hosts are delimited by [header] elements
# - You can enter hostnames or ip addresses
# - A hostname/ip can be a member of multiple groups
# Ex 1: Ungrouped hosts, specify before any group headers.
## green.example.com
## blue.example.com
## 192.168.100.1
## 192.168.100.10
# Ex 2: A collection of hosts belonging to the ‘webservers’ group
## [webservers]
## alpha.example.org
## beta.example.org
## 192.168.1.100
## 192.168.1.110
# If you have multiple hosts following a pattern you can specify

# them like this:
## www[001:006].example.com
# Ex 3: A collection of database servers in the ‘dbservers’ group
## [dbservers]
##
## db01.intranet.mydomain.net
## db02.intranet.mydomain.net
## 10.25.1.56
## 10.25.1.57
# Here’s another example of host ranges, this time there are no

# leading 0s:
## db-[99:101]-node.example.com
Ahora que ya tenemos las claves debidamente copiadas y un inventario valido, ha llegado el momento
de comprobar si realmente ansible funciona y se puede conectar a un servidor remoto.
El comando básico para hacer la comprobación ha sido siempre el ping, pero también podremos eje-
cutar otros comandos, por ejemplo, preguntar por la versión del SO.
[root@localhost ansible]# ansible -m ping -i inventory/servidores all

ansible-control-node | SUCCESS => {
“changed”: false,
“ping”: “pong”
}
[root@localhost ansible]# ansible -m shell -a “cat /etc/*-release” -i inventory/servi-
dores all
ansible-control-node | CHANGED | rc=0 >>
CentOS Linux release 7.4.1708 (Core)
NAME=”CentOS Linux”
VERSION=”7 (Core)”
ID=”centos”
ID_LIKE=”rhel fedora”
VERSION_ID=”7”
PRETTY_NAME=”CentOS Linux 7 (Core)”
ANSI_COLOR=”0;31”
CPE_NAME=”cpe:/o:centos:centos:7”
HOME_URL=”https://www.centos.org/”
BUG_REPORT_URL=”https://bugs.centos.org/”
CENTOS_MANTISBT_PROJECT=”CentOS-7”
CENTOS_MANTISBT_PROJECT_VERSION=”7”
REDHAT_SUPPORT_PRODUCT=”centos”
REDHAT_SUPPORT_PRODUCT_VERSION=”7”

7. Integración con vCenter y ESXi
Antes de empezar a ejecutar playbooks de Ansible sobre nuestro vCenter o ESXi, hay algunas cosas
que debemos hacer previamente.
Ansible proporciona una gran cantidad de módulos predefinidos para interactuar con vSphere, que se
basan en “PyVmomi”, que no es más que la SDK de Python para la API de VMWare vSphere.
Para instalar PyVmomi, utlizaremos el gestor pip, que previamente tendremos que instalar desde el
repositorio EPEL:
[root@localhost ansible]# yum -y install python-pip

[root@localhost ansible]# pip install pyvmomi
Con eso hecho, ahora ya podremos usar Ansible para interactuar con vSphere.
Para seguir un poco un orden y ya que hablamos del inventario anteriormente, vamos a crear un inven-
tario para nuestros hosts ESXi:
[root@localhost ansible]# vim inventory/ESXi

[esxi:children]
live
test
[live]
esxi01.vmwareporvexperts.org
[test]
NOTA: Hemos creado un grupo llamado esxi que contiene 2 subgrupos, live y test. Cada uno de
estos grupos contiene varios ESXi.
Si os acordáis, anteriormente generamos un par de claves ssh, pues bien, esa clave deberemos de
copiarla en todos los ESXi que queramos manejar con Ansible con el siguiente comando:
cat ~/.ssh/id_rsa.pub | ssh root@dbcesx01 ‘cat >> /etc/ssh/keys-root/authorized_keys’
[root@localhost ansible]# cat ~/.ssh/id_rsa.pub | ssh root@esxi05.vmwareporvexperts.org

‘cat >> /etc/ssh/keys-root/authorized_keys’
Password:
Password:
Password:
Password:
Password:
Para comprobar que las claves están correctas y que nuestro inventario está bien definido, podremos
ya ejecutar los primeros comandos contra nuestros ESXi.
[root@localhost ansible]# ansible -m ping -i inventory/ESXi all

esxi02.vmwareporvexperts.org | SUCCESS => {
}
}
}
}
}
[root@localhost ansible]# ansible -m shell -a “vmware -vl” -i inventory/ESXi live

esxi02.vmwareporvexperts.org | CHANGED | rc=0 >>
VMware ESXi 6.7.0 build-11675023
VMware ESXi 6.7.0 Update 1


[root@localhost ansible]# ansible -m shell -a “vmware -vl” -i inventory/ESXi test


Podreis encontrar más información en el portal oficial de Ansible:
8. Módulos ¿qué son?
Los módulos, son considerados la unidad principal de trabajo en Ansible. Es el código que se ejecuta
en el servidor administrado.
Cada módulo es independiente de los demás y una de las principales características, es la idempoten-
cia, es decir, una acción no se ejecutará más veces una vez alcanzado el estado deseado.
Cada uno de estos módulos, devolverá datos en formato JSON, que será interpretado por Ansible y en
caso necesario, podremos reutilizar esta información.
Un ejemplo, sería el módulo para poner en modo mantenimiento un host ESXi:
- name: Enter VSAN-Compliant Maintenance Mode

vmware_maintenancemode:
hostname: vc_host
username: vc_user
password: vc_pass
esxi_hostname: esxi.host.example
vsan: ensureObjectAccessibility
evacuate: yes
timeout: 3600
state: present
TIP: Encontrareis el directorio completo de módulos para VMWare en la siguiente URL:

https://docs.ansible.com/ansible/2.5/modules/list_of_cloud_modules.html?highlight=vmware%20
modules
9. Tasks
Para Ansible, una tarea es una acción que realizar, la ejecución de un módulo. Estas tareas, se pueden
ejecutar en modo Ad-Hoc o mediante playbook. El modo ad-hoc nos permite ejecutar directamente co-
mandos en una sola línea sobre nuestros hosts utilizando los módulos que ya tiene Ansible. Este modo
se utiliza cuando queremos efectuar una acción simple sobre nuestros hosts, por ejemplo, realizar un
ping.
[root@localhost ansible]# ansible -m ping -i inventory/ESXi all

}
}
}
}
}
La ejecución mediante playbook se haría con el comando ansible-playbook de la siguiente manera:
[root@localhost ansible]# ansible-playbook playbooks/vmware.yml -i

inventory/servidores --tags=maintenance
PLAY [ansible-control-node] *********************************************************

**************************************************************************************
************************************
TASK [Gathering Facts] ***************************************************************

**************************************************************************************
***********************************
ok: [ansible-control-node]
TASK [Enter host maintenance mode] ***************************************************

**************************************************************************************
***********************************
changed: [ansible-control-node]
PLAY RECAP ***************************************************************************

**************************************************************************************
***********************************
ansible-control-node : ok=2 changed=1 unreachable=0 failed=0
En el siguiente capítulo hablaremos en detalle de los playbooks y cuál es su estructura.
10. Playbooks
Los playbooks quizás son la parte más importante de Ansible, están escritos en YAML y son los fiche-
ros donde describiremos todas las acciones a aplicar sobre nuestras máquinas.
Están diseñados para ser fáciles de leer y gracias a la idempotencia, conseguiremos que las acciones
descritas no se ejecuten más, una vez se ha llegado al estado deseado.
En definitiva, un playbook es:
• Una lista de plays**
• Cada play, debe contener:
• Hosts
• Tasks/roles
Y para muestra, un botón…
A continuación, podéis ver la estructura real de un playbook:
[root@localhost ansible]# vim playbooks/vmware.yml

---
- hosts: ansible-control-node
connection: local
vars:
vcenter_hostname: 192.168.6.10
vcenter_username: miquel.mariano
vcenter_password: Secret123!
datacenter_name: VDC
cluster_name: 01-ansible-cluster
esxi_hostname: esxi00
esxi_username: root
esxi_password: Secret123!
tasks:
- name: Enter host maintenance mode
hostname: ‘{{ vcenter_hostname }}’
username: ‘{{ vcenter_username }}’
password: ‘{{ vcenter_password }}’
validate_certs: false
esxi_hostname: esxi01
state: present
tags: maintenance
11. Roles
A medida que vamos añadiendo funcionalidad y complejidad a nuestros playbooks, cada vez se hace
más difícil manejarlo con un solo fichero (playbook). Los roles, nos permiten crear estructuras más
complejas y dotar de mayor lógica a nuestras operaciones.
Según la propia documentación de Ansible: “Roles in Ansible build on the idea of include files and com-
bine them to form clean, reusable abstractions – they allow you to focus more on the big picture and
only dive down into the details when needed.”
Para la correcta utilización de los roles, es necesario crear toda una estructura de carpetas y subcar-
petas donde iremos depositando nuestra configuración.
Tenemos dos opciones para crear estas carpetas, de forma manual o utilizando ansible-galaxy.
Galaxy, es un repositorio público de roles que utiliza github como almacén de datos. Está pensado para
que se pueden crear y compartir fácilmente nuestros roles.
https://galaxy.ansible.com/
Para crear un role mediante ansible-galaxy, ejecutamos el siguiente comando dentro de /etc/ansible/
roles:
[root@localhost ansible]# ansible-galaxy init roles/deploy_new_VM

- roles/deploy_new_VM was created successfully
Y la estructura de carpetas que deberíamos ver seria la siguiente:
[root@localhost ansible]# ll roles/deploy_new_VM/

total 4
drwxr-xr-x. 2 root root 22 ene 31 19:09 defaults
drwxr-xr-x. 2 root root 6 ene 31 19:09 files
drwxr-xr-x. 2 root root 22 ene 31 19:09 handlers
drwxr-xr-x. 2 root root 22 ene 31 19:09 meta
-rw-r--r--. 1 root root 1328 ene 31 19:09 README.md
drwxr-xr-x. 2 root root 22 ene 31 19:09 tasks
drwxr-xr-x. 2 root root 6 ene 31 19:09 templates
drwxr-xr-x. 2 root root 39 ene 31 19:09 tests
drwxr-xr-x. 2 root root 22 ene 31 19:09 vars
NOTA: Encontrareis una amplia explicación sobre los roles y playbooks en mi blog:
https://miquelmariano.github.io/2017/04/roles-y-playbooks-Ansible
12. Casos de uso
Llegados a este punto, estaréis de acuerdo conmigo que el potencial de Ansible para automatizar cual-
quier tipo de tarea, no solo VMware, es tremendamente alto.
Cómo en este libro hemos intentado centrarnos en todo el ecosistema vSphere, vamos a ver algunas
ideas para automatizar nuestro entorno vSphere.
TIP: Os animo a que os paséis por la lista oficial de módulos para VMware y que vosotros mismos
vayáis descubriendo todo lo que podéis hacer con ellos:
https://docs.ansible.com/ansible/latest/modules/list_of_cloud_modules.html#vmware-cloud-mo-
dules
12.1 Crear un cluster y añadir hosts
En este primer ejemplo básico veremos como a través de un playbook podremos crear un clúster y
añadir sus correspondientes hosts ESXi. Finalmente, todos estos hosts nos aseguraremos de que
están en modo mantenimiento. Ahí va el código:
[root@localhost ansible]# vim playbooks/vmware.yml

---
- hosts: ansible-control-node
connection: local
vars:
vcenter_hostname: 192.168.6.10
vcenter_username: miquel.mariano
vcenter_password: Secret123!
datacenter_name: VDC
cluster_name: 01-ansible-cluster
esxi_username: root
esxi_password: Secret123!
tasks:
- name: Create Cluster
local_action:
module: vmware_cluster
datacenter_name: ‘{{ datacenter_name }}’
cluster_name: ‘{{ cluster_name }}’
enable_ha: yes
enable_drs: yes
enable_vsan: yes
state: present
- name: Add ESXi Host to vCenter

vmware_host:
datacenter_name: ‘{{ datacenter_name }}’
esxi_hostname: esxi0{{ item }}
esxi_username: ‘{{ esxi_username }}’
esxi_password: ‘{{ esxi_password }}’
state: present
with_sequence: start=1 end=5
- name: Enter host maintenance mode
esxi_hostname: esxi0{{ item }}
state: present
Si todo ha ido correcto, el resultado debería ser algo similar a esto:
[root@localhost ansible]# ansible-playbook playbooks/vmware.yml -i inventory/servidores

**************************************************************************************
************************************

**************************************************************************************
***********************************
TASK [Create Cluster] ****************************************************************

**************************************************************************************
***********************************
changed: [ansible-control-node -> localhost]
TASK [Add ESXi Host to vCenter] ******************************************************

**************************************************************************************
***********************************
changed: [ansible-control-node] => (item=1)
TASK [Enter host maintenance mode] ***************************************************

**************************************************************************************
***********************************
ok: [ansible-control-node] => (item=1)
PLAY RECAP ***************************************************************************

**************************************************************************************
***********************************
12.2 Configurar NTP y DNS
En este caso, veremos cómo cambiar los NTP de nuestros servidores ESXi y a la vez cambiar tanto el
hostname y la zona de búsqueda predeterminada, cómo los servidores DNS.
Vamos a utilizar el mismo playbook anterior y a continuación le añadiremos el siguiente código:
- name: Configure NTP

vmware_host_ntp:
state: present
ntp_servers:
- 0.pool.ntp.org
- 1.pool.ntp.org
delegate_to: localhost
tags: ntp
- name: Configure ESXi hostname and DNS servers

vmware_dns_config:
hostname: esxi0{{ item }}.vmwareporvexperts.org
username: ‘{{ esxi_username }}’
password: ‘{{ esxi_password }}’
change_hostname_to: esxi0{{ item }}
domainname: vmwareporvexperts.org
dns_servers:
- 8.8.8.8
- 8.8.4.4
tags: dns
Veréis que en cada task le he añadido unas etiquetas “tag”. De esta manera, aunque sepamos que los
módulos trabajan con idem potencia y las tareas anteriores de crear el clúster no se van a ejecutar, con
las “tags” podremos centrar directamente la ejecución a lo que nos interese:
[root@localhost ansible]# ansible-playbook playbooks/vmware.yml -i

inventory/servidores --tags ntp,dns

**************************************************************************************
************************************

**************************************************************************************
***********************************
TASK [Configure NTP] ******************************************************************

**************************************************************************************
**********************************
changed: [ansible-control-node -> localhost]
TASK [Configure ESXi hostname and DNS servers] ****************************************

**************************************************************************************
**********************************
changed: [ansible-control-node -> localhost] => (item=1)
PLAY RECAP ***************************************************************************

**************************************************************************************
***********************************
12.3 Crear VM Portgroups
En esta ocasión, vamos a crear un VM portgroup en todos nuestros ESXi. Para ello, al igual que el
ejemplo anterior, añadiremos el siguiente código al playbook y le añadiremos también una etiqueta:
- name: Add PRODUCCION Network VM Portgroup

vmware_portgroup:
hosts: esxi0{{ item }}
switch_name: vSwitch0
portgroup_name: PRODUCCION
vlan_id: 0
state: present
tags: vm-portgroup
Se ejecuta de la siguiente forma y el resultado sería:
[root@localhost ansible]# ansible-playbook playbooks/vmware.yml -i inventory/servidores

--tags vm-portgroup

**************************************************************************************
************************************

**************************************************************************************
***********************************
TASK [Add PRODUCCION Network VM Portgroup] *******************************************

**************************************************************************************
***********************************
PLAY RECAP ***************************************************************************

**************************************************************************************
***********************************
12.4 Crear nueva VM
En este último ejemplo, vamos ya a intentar hacer cosas realmente chulas, como por ejemplo, crear
una VM en nuestra infraestructura totalmente funcional. Vamos a ello.
Para empezar, crearemos un inventario que lo llamaremos vms-to-deploy que contendrá la siguiente
información de las máquinas a desplegar:
[grupo-test]
test1 vm_ip=10.0.0.20
test2 vm_ip=10.0.0.21
[grupo-prueba]
prueba1 vm_ip=20.0.0.20
prueba2 vm_ip=20.0.0.21
[grupo-prueba:vars]
vc_datacenter=VDC
vc_folder=/MIQUEL/VSAN/VMS/PRUEBA
vc_cluster=Cluster-EVC
vc_note=’Created by Ansible’
vm_datastore=HUS110_LUN0000
vm_networkportgroup=VLAN6_Formacion
vm_networkdns1=192.168.6.100
vm_networkmask=255.255.255.0
vm_networkgw=10.0.0.1
vm_memory=1024
vm_cpu=1
vm_disksize=20
[grupo-test:vars]
vc_datacenter=VDC
vc_folder=/MIQUEL/VSAN/VMS/TEST
vc_cluster=Cluster-EVC
vc_note=’Created by Ansible’
vm_datastore=HUS110_LUN0000
vm_networkportgroup=VLAN6_Formacion
vm_networkmask=255.255.255.0
vm_networkgw=10.0.0.1
vm_memory=1024
vm_cpu=1
vm_disksize=20
[all:vars]
vc_hostname=192.168.6.10
vc_username=administrator@vsphere.local
vc_password=Secret123!
vm_template=miquel-template-W2012R2-Std-ES
dc_domain=vmwareporvexperts.local
localadminpass=Secret123!
Posteriormente, con el módulo vmware_guest, vamos a crear el playbook deploy-vms.yml el cuan nos
permitirá crear y customizar nuestras VMs a nuestro antojo:
---
- hosts: all
gather_facts: false
tasks:
- name: Deploy VM windows from template and customize
vmware_guest:
hostname: “{{ vc_hostname }}”
username: “{{ vc_username }}”
password: “{{ vc_password }}”
validate_certs: no
datacenter: “{{ vc_datacenter }}”
folder: “{{ vc_folder }}”
cluster: “{{ vc_cluster }}”
name: “{{ inventory_hostname }}”
annotation: “{{ vc_note }}”
state: poweredon
disk:
- size_gb: “{{ vm_disksize}}”
type: thin
datastore: “{{ vm_datastore }}”
hardware:
memory_mb: “{{ vm_memory }}”
num_cpus: “{{ vm_cpu }}”
scsi: paravirtual
template: “{{ vm_template }}”
networks:
- name: “{{ vm_networkportgroup }}”
ip: “{{ vm_ip }}”
netmask: “{{ vm_networkmask }}”
gateway: “{{ vm_networkgw }}”
customization:
hostname: “{{ inventory_hostname }}”
autologon: true
dns_servers:
- “{{ vm_networkdns1 }}”
- “{{ vm_networkdns2 }}”
dns_suffix: “{{ dc_domain}}”
password: “{{ localadminpass }}”
Para finalizar, la ejecución del playbook, seria de la siguiente manera:
[root@localhost ansible]# ansible-playbook playbooks/deploy-vms.yml -i inventory/vms-

to-deploy
PLAY [all] ***************************************************************************

**************************************************************************************
***********************************
TASK [Deploy VM windows from template and customize] *********************************

**************************************************************************************
***********************************
changed: [prueba1 -> localhost]
changed: [prueba2 -> localhost]
changed: [test2 -> localhost]
changed: [test1 -> localhost]
PLAY RECAP ***************************************************************************

**************************************************************************************
***********************************
prueba1 : ok=1 changed=1 unreachable=0 failed=0
prueba2 : ok=1 changed=1 unreachable=0 failed=0
test1 : ok=1 changed=1 unreachable=0 failed=0
test2 : ok=1 changed=1 unreachable=0 failed=0
Y aquí veis el resultado:
13. ¿Por dónde empezar?
Antes de terminar con el capítulo, me gustaría hacer una reflexión con todos vosotros. Últimamente,
cuando hablo con alguien de automatización, durante la conversación siempre suele salir la misma
pregunta.
Vale Miquel, esto de automatizar está muy bien, pero ¿por dónde empezamos?
Es la pregunta del millón y no tiene una respuesta fácil. Cada empresa tiene un montón de procedi-
mientos y/o procesos y definir por dónde empezar es clave para no morir en el intento.
Mi recomendación siempre es la misma. Hay que definir estos 3 grandes grupos:
• Tareas repetitivas
Aquellas tareas que realizamos muchas veces durante nuestra jornada laboral y que al fin y al
cabo nos consumen mucho tiempo. Al ser tareas muy repetitivas, tendremos muy claro el proceso
y posiblemente será muy fácil automatizarlo (P.E. Crear un usuario).
• Tareas que nos consumen mucho tiempo
No son tareas muy repetitivas, pero sí que al tener que realizarlas nos consumen bastante tiempo.
Posiblemente tengamos que invertir tiempo en automatizar estas tareas, pero una vez conseguido,
el ahorro de tiempo será muy grande, y podremos dedicarlo a automatizar más ;-) (P.E. Crear una
VM).
• Tareas o procesos críticos para negocio
Aquellas actuaciones que tiene un impacto directo a negocio, ya sea porque hay que programar
una ventana de parada o porque existe un riesgo de caída del sistema. Posiblemente todas estas
tares lleven un gran tiempo de planificación y ejecución con el consiguiente riesgo de error huma-
no. Automatizar todo esto no será tarea fácil, pero una vez conseguido tendremos la tranquilidad
que cada vez que nos enfrentemos a esta tarea tendremos mayor probabilidad de éxito.
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 18
vSphere y Containers
Raúl Unzué
Capítulo 18 - vSphere y Containers Raúl Unzué
1. Introducción
En la actualidad, las tecnologías de virtualización se han convertido en el paso natural para la evolución
de los datacenters en medianas o grandes empresas. A su vez, dichas tecnologías de virtualización
han evolucionado estos últimos años de forma exponencial, adaptándose a las nuevas arquitecturas y
necesidades que van surgiendo.
Una de esas evoluciones ha sido la implementación de virtualización basada en Contenedores. Estos

facilitan una arquitectura de ejecución de aplicaciones como microservicios para la que la virtualización
tradicional tenía ciertas limitaciones. La ventaja principal de los microservicios es que las empresas
pueden desarrollar e implementar aplicaciones de una forma mucho más ágil.
El mayor problema de migrar a este tipo de arquitecturas viene derivado de que hay que hacer algunos
cambios en las prácticas existentes del personal IT. En este punto, es donde VMware se coloca como
uno de los facilitadores del cambio.
La tecnología de contenedores no es nueva, ya que, en 1979, el sistema operativo Unix en su versión

7, introdujo el sistema chroot, lo que permitía cambiar el directorio raíz de un proceso y sus hijos a una
nueva ubicación.Tras varias evoluciones durante estas décadas, gran parte gracias a la comunidad
Linux, ha sido el proyecto open source Docker, cuyo código fue liberado en 2013, el que ha conseguido
explotar la popularidad de la que ahora gozan.
Docker es un entorno de virtualización ligero que te permite construir y ejecutar aplicaciones dentro de
un Contenedor de software aislado.
Un Contenedor, es la unidad estándar de software que permite empaquetar el código, las configuraciones
y todas sus dependencias en un único objeto, para que la aplicación o aplicaciones se ejecuten sobre
un mismo núcleo de sistema operativo de una forma rápida, fiable y consistente.
Ilustración 1 - Arquitectura Containers
Una de las características de los Contenedores, que les han hecho ganar popularidad, es que se
pueden implementar fácilmente en todo tipo de entornos, tanto Clouds Híbridas o Públicas como en
cualquier instalación local. Es por ello que VMware es una de las empresas que más está apostando
en ampliar su oferta en este punto, todo gracias a movimientos estratégicos centrados en mejorar su
oferta On-Premise y su oferta Cloud, donde los Containers tienen mucho que decir.
Ha constituido a través de su producto estrella, vSphere, un ecosistema vSphere+Contenedores con

múltiples actores a su alrededor. Entre esos actores encontramos las tecnologías de orquestación,
los sistemas operativos dedicados, integradores, entornos Cloud y herramientas de monitorización y

gestión.
VMware Project Bonneville fue el proyecto que impulsó la integración con vSphere. Se basa en la API
de Docker que permite alojar Contenedores como si fuesen máquinas virtuales dentro de vSphere.
Para ello utiliza el sistema operativo Photon OS y la clonación instantánea de VMware.
Photon OS es una distribución Linux creada por completo por VMware y que está optimizada para
trabajar con su infraestructura, aplicaciones Cloud nativas, Contenedores e incluso con Kubernetes,
ya que dispone de binarios nativos para su uso en el repositorio Photon.
En la actualidad, VMware, está sumergida en soportar Kubernetes como tecnología de orquestación

para Contenedores bajo el proyecto VMware Cloud PKS (Pivotal Container Service).
Hay que destacar el proyecto de Kubernetes(K8S). Este fue diseñado inicialmente por Google y
posteriormente donado a la Cloud Native Computing Foundation (CNCF), para la automatización de
despliegues, el escalado y la gestión de aplicaciones contenerizadas.
Ilustración 2 – Logo Kubernetes
Kubernetes es la plataforma de referencia en la automatización de Contenedores, que permite simplificar

la gestión de clústeres de grupos de hosts que los ejecutan. Su uso es fundamental para controlar el
autoescalado y el despliegue de arquitecturas complejas formadas por varios contenedores.
La evolución, tanto de Kubernetes como de Contenedores, estos últimos años está siendo imparable,
como demuestran las periódicas encuestas que realiza la Cloud Native Computing Foundation, de la
que VMware es miembro Platinum como otros “grandes actores” (AWS, Cisco, Google Cloud, Microsoft
Azure, RedHat, Dell…).
Ilustración 3 - CNCF Kubernetes
Antes de que empresas como VMware apostaran por los Contenedores y Kubernetes siempre ha
existido el estigma de que eran plataformas que servían para Test o Desarrollo y que tenían bastantes
limitaciones para gestionar las necesidades de entornos de Producción.
Esto está cambiando progresivamente, como ya se está viendo en la evolución de Kubernetes en

las empresas, donde ya se ha convertido en apuesta segura para sistemas de alta disponibilidad y
computación de alto rendimiento.
Hoy en día, gracias al uso de Kubernetes + Contenedores + vSphere, VMware dispone de los argumentos
suficientes para que la adopción de las empresas en entornos productivos sea una garantía de éxito.
Ilustración 4 - CNCF Kubernetes Evolución Producción
Los Contenedores han supuesto un cambio radical en la forma en la que construimos y desplegamos
aplicaciones, en próximos apartados se verá que puede ofrecer VMware desde su perspectiva.
Este esquema, que se irá desarrollando con los siguientes apartados, se puede ver las soluciones de
las que dispone VMware:
Ilustración 5 - VMware Containers
2. Arquitectura Contenedores
Para explicar la arquitectura de Contenedores en VMware, es necesario compararla con la de máquinas

virtuales. La característica clave que distingue un Contenedor de una máquina virtual es la naturaleza
efímera de este.
En un sistema basado en Contenedores existen múltiples instancias de un contenedor. Estas pueden

ser borradas o reemplazadas sin que el servicio se vea impactado. Algo que difícilmente podremos
conseguir con máquinas virtuales sin un gasto excesivo de recursos. Incluso se puede dar el caso de
tener diferentes versiones de estos coexistiendo.
Teniendo en cuenta lo anterior se puede decir que son un sistema escalable, pudiendo variar la
cantidad de contenedores en función de, por ejemplo, patrones de tráfico, ya sean autogenerándose
o borrándose del sistema.
Uno de los puntos que marca la diferencia entre las Máquinas Virtuales y los Contenedores es la forma
en la que cada capa de virtualización utiliza los recursos de la máquina. Dicho de otra forma, mientras
que el hypervisor abstrae el sistema operativo de la máquina virtual del hardware subyacente, el motor
de contenedores abstrae la aplicación del contenedor del sistema operativo subyacente.
Ilustración 2 - Virtual Machine vs Containers
Lo que ha logrado VMware es unir los beneficios de ambas tecnologías a través de vSphere.
3. Beneficios Contenedores en VMware
Las características más importantes de implementar los Contenedores sobre una infraestructura
VMware son:
• Es el propio vSphere el que ejecuta los Contenedores y no Linux como en otras distribuciones.
• Los Contenedores no se despliegan dentro de otras máquinas virtuales, si no que dentro de

vSphere los Contenedores son propiamente máquinas virtuales.
• Todos los datos (volúmenes, imágenes y Contenedores) se almacenan directamente, por ejemplo,
en los datastores VMFS presentados en los ESXi.
• Toda la infraestructura hardware y de red es proporcionada por vSphere.
• Los Contenedores permanecen totalmente aislados tanto del host como de otros Contenedores.
4. vSphere Integrated Containers
VMware vSphere Integrated Containers (VIC) es una plataforma que permite administrar e implementar
Contenedores dentro de vSphere compatible desde la versión 6.x y posteriores.
La implementación se realiza mediante un appliance basado en la distribución Linux desarrollada por

VMware, Photon OS, que se puede encontrar en todos los appliance actuales basados en Linux que
distribuye VMware.
Se trata de un proyecto de código abierto, con lo que se pone en mano de la comunidad los diferentes
componentes de la solución. Al ser una solución open source, no conlleva un sobrecoste su implantación
en una infraestructura vSphere.
Aunque su implantación no tiene sobrecoste, si queremos disponer de soporte por parte de VMware,
necesitaremos una licencia Enterprise Plus. Adicionalmente, es necesario disponer de switches
distribuidos para su implantación, que sólo están disponibles a partir de la licencia Enterprise Plus.
Ilustración 3 - vSphere Integrated Containers
Básicamente dispone de 4 componentes principales:
• vSphere Integrated Containers Management Portal: se trata del dashboard que da acceso a
gestionar los diferentes Contenedores, crear los proyectos asociados, configurar el networking,
entre otras tareas.
• vSphere Integrated Containers Registry: nos permite almacenar y distribuir las imágenes de los
Contenedores que vamos a utilizar.
• vSphere Integrated Containers Engine: incluye el componente vic-machine que permite el

despliegue de los hosts VCH (Virtual Container Host) y con ello la ejecución de los Contenedores
sobre los hosts VMware ESXi.
• vSphere Integrated Containers Plug-In for vSphere Client: permite la gestión y creación de los
hosts VCH desde vSphere. Existen dos versiones del Plug-In tanto para la consola Flash como la
HTML5. En las últimas versiones se instala automáticamente en el procedimiento de despliegue de
VIC y se actualiza automáticamente al hacer un upgrade la plataforma.
4.1 Otros Componentes en VIC
• vSphere Integrated Containers Appliance: como ya hemos comentado, es el Appliance que

proporciona los servicios de Management Portal (Dashboard) y Registry. A su vez es fundamental
para desplegar el resto de los componentes.
• Virtual Container Host (VCH): es un nuevo concepto que introduce VMware vSphere Integrated
Containers, que permite representar los recursos de CPU, RAM y almacenamiento que se van
a asignar dentro de la plataforma de vCenter, y a su vez, da acceso a la API de Docker y a las
imágenes de Docker Hub para la creación de Containers.
Cuando se lanza la creación de un container se ejecuta una máquina virtual liviana que reside
dentro del VCH. De tal forma, que los VCH pueden contener múltiples máquinas virtuales livianas
y varias instancias de contenedores individuales. A su vez almacenan las imágenes de los
Contenedoresdescargadas.
Se pueden generar varios VCH dentro del mismo vCenter, y esta tarea se realiza desde un plugin
personalizado que en las últimas versiones de VIC se instala automáticamente en vCenter al
desplegar VIC.
En la siguiente figura se puede comparar cómo se comporta una infraestructura tradicional de Docker
Containers Hosts y como trabaja Virtual Container Hosts, que es capaz de proveer Containers Docker
nativos como hemos hablado:
Ilustración 4 – Virtual Container Host
4.2 Networking VIC
Uno de los puntos más complejos en toda infraestructura basada en Contenedores es el Networking.
Por ello vamos a intentar explicar en un alto nivel como es el Networking sobre Docker y posteriormente
analizamos como se implementa sobre VIC.
Cuando se instala Docker en un host se crean varias interfaces:
• Bridge: Es la red por defecto, esta configuración la tendrán todos los Contenedores salvo que
indiquemos lo contrario en su creación. Es un puente al interfaz docker0.
• Host: Como su propio nombre indica, se refiere a los interfaces del host, y todas las interfaces
tendrán acceso.
• None: Será todo Docker aislado, sin interfaz de red.
Este sería un esquema común en un servidor Docker:
Ilustración 9 – Esquema común Docker
Cuando quieres que el servicio que ejecuta un Container se comparta con otras redes, por ejemplo
Internet, se realiza una exposición de puertos a través del host anfitrión. Redirigiendo el puerto expuesto
en el host al del Container.
VMware ha intentado simplificar esta configuración de forma que puedes usar switches distribuidos o
NSX para poder implementarla y securizarla con toda la infraestructura de vSphere, y a su vez uniendo
la red lógica y la red física.
Se puede redirigir el tráfico entre Contenedores, el propio VCH, hacia Internet o entre las diferentes
redes que existen dentro de vSphere. Los Containers pueden publicar servicios de red mediante NAT
(Network Address Translation) de la interfaz Public que se define al generar el VCH.
Ilustración 10 – Esquema conexión lógico
La siguiente imagen detalla los puertos y protocolos que intervienen en la comunicación en una
infraestructura VIC y que habrá que tener en cuenta en cualquier diseño:
Ilustración 11 – Esquema puertos utilizados por componentes
A continuación, detallamos los puertos que intervienen entre los diferentes componentes:
vSphere Integrated Containers
Protocolo Puerto Descripción

Se utiliza para conexiones desde los clientes Docker, vSphere Integrated
HTTPS / TCP 443 Containers Management Portal o VCH a vSphere Integrated Containers
Registry
Se utiliza para conexiones al servicio Docker Content Trust para vSphere
HTTPS / TCP 4443
Integrated Containers Registry
Es la conexión por defecto a vSphere Integrated Containers Management
HTTPS / TCP 8282
Portal UI y API
Se utiliza para conexiones al servicio de VIC, que permite crear VCH´s a
HTTPS / TCP 8443
través del plugin de la consola HTML5 de vSphere Client
Se utiliza para la conexión a la página Getting Started del appliance VIC. Que
HTTPS / TCP 9443 dispone de un enlace a Management Portal o descargar vSphere Integrated
Engine bundle, por ejemplo
Hosts ESXi

Es necesario para implementar VCH´s en el host ESXi. Se utiliza para
TCP 2377
conexiones salientes entre la máquina final y el shell del Container
Es necesario para implementar VCH´s en el host ESXi. Se utiliza para
HTTPS / TCP 443
conexiones entrantes de carga o descarga desde los Datastores
Red Bridge

Es necesario para que los VCH´s dispongan de resolución de nombres y
TCP 53
conecten con los DNS´s de la infraestructura
Red Clientes

SSH / TCP 22 Conexiones al VCH cuando se usa el modo debug
HTTP / TCP 2375 Puerto no seguro de acceso a la API de Docker
HTTPS / TCP 2376 Puerto seguro de acceso a la API de Docker
HTTPS / TCP 2378 Conexiones al portal de administración del VCH
Los Contenedores no exponen ningún puerto por defecto, si necesitamos hacer
HTTPS / TCP 6060
debug sobre ellos, hay que generar el VCH con el comando --debug
Red de Gestión

TCP 2377 Conexiones entrantes de los Contenedores al VCH
HTTPS / TCP 443 Conexiones salientes desde el VCH a los hosts ESXi y al vCenter Server
Red Containers

Los Contenedores no exponen ningún puerto por defecto, si necesitamos
HTTPS / TCP 6060
hacer debug sobre ellos, hay que generar el VCH con el comando --debug
4.3 Copia de Seguridad de VIC
LINK REFERENCIA:
https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/backup_vic.html
Cuando añades vSphere Integrated Containers a tu infraestructura vSphere, te das cuenta que el resto
de componentes como VCH´s, Contenedores,…surgen en una unión entorno al appliance de VIC.
Tal y como se ha comentado anteriormente, los Contenedores dentro de vSphere son realmente
máquinas virtuales, es importante tener en cuenta ciertos detalles para crear copias de seguridad de
todos los componentes sin pérdida de información.
Lo primero que tiene que quedar claro, es que la naturaleza, por regla general, de un Contenedor, es
efimera, , con lo que no es un elemento adecuado para generar copias de seguridad, simplemente por
esa naturaleza.
En cambio, dentro de una infraestructura de Contenedores sobre VMware no todos los elementos
son efímeros. Si disponéis de datos como bases de datos, la información que contienen, no pueden
ser datos efímeros. Para ello se asocian volúmenes a estos de tal forma que los datos persistan en el
tiempo.
Los principales componentes que deberemos tener en cuenta para hacer copias de seguridad son:
• Los volúmenes enlazados a los Contenedores. Todo dato persistente dentro de un volumen
asociado a un Contenedor puede hacerse “copia de seguridad”, tanto en forma de Snapshot**
como clonado, sólo si el Contenedor no se está ejecutando. VIC soporta volúmenes en formato
tanto NFS como VMFS así que habría que trabajar con herramientas de copias de seguridad que
soporten estos formatos, bastante estándares actualmente.
• vSphere Integrated Containers Management Portal almacena los proyectos y los usuarios. Se
pueden hacer “copias de seguridad” mediante clonado de la máquina virtual. Además, se puedem
realizar Snapshot** como si fuese un clonado de máquina virtual.
• vSphere Integrated Containers Registry los datos de imágenes. Y también podemos hacer “copias
de seguridad” tanto en forma de Snapshot** como con un clonado de máquina virtual.
** Aunque hablamos de hacer copias de seguridad con Snapshots, no debe tomarse un Snapshot
como referencia para realizar copias de seguridad. Ya que un Snapshot es una imagen en el
tiempo en un punto concreto del sistema y no una copia de seguridad al uso.**
Por otra parte, el propio appliance VIC debe tener su copia de seguridad como máquina virtual dentro
de la infraestructura. Tal y como está diseñado, nos encontramos con 4 discos por defecto:
Ilustración 11 – Discos vSphere Integrated Containers
VMware lo ha diseñado de esa forma, porque cada disco tiene su funcionalidad específica que ahora
detallamos:
Disco Punto de montaje Descripción

En la raíz encontraremos el sistema operative y el estado de la
Disco 1 /
aplicación. Mapeado en SCSI 0:0
Disco 2 /storage/data Diferentes datos y la instancia VIC Registry. Mapeado en SCSI 0:1
Contiene la base de datos MySQL, Clair y Notary para VIC Registry.
Disco 3 /storage/db
Mapeado en SCSI 0:2
Se almacenan los logs de los diferentes componentes. Mapeado en
Disco 4 /storage/log
SCSI 0:3
Este diseño nos permite restaurar la máquina virtual VIC desde un Snapshot o simplemente recuperar
un VMDK concreto de uno de nuestros discos para poder levantar el sistema ante una incidencia
concreta.
4.4 Seguridad en VIC
LINK REFERENCIA:
https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/security_reference.
html
Una de las ventajas de implementar vSphere Integrated Containers es que a nivel de seguridad vamos
a encontrarnos un producto integrado en vSphere y que va a aprovechar funciones ya implementadas

en otros productos de VMware.
Cuando instalamos vSphere Integrated Containers no vamos a generar nuevos usuarios, ni cuentas de
servicio o permisos adicionales que otra máquina del sistema.
De hecho, se reutilizan las cuentas de usuario ya generadas previamente en vSphere. Teniendo la

posibilidad de generar cuentas de usuario para que accedan, dependiendo del perfil que queramos
dar, al VIC Management Portal.
Por ejemplo, un proyecto en el que hay un desarrollador externo que trabajará temporalmente sobre
la plataforma y no necesita permisos adicionales. La implementación es muy sencilla, se pueden usar
usuarios locales o utilizar toda la potencia de LDAP o Active Directory:
Ilustración 12 – Agregar usuarios y grupos proyecto
Adicionalmente, vSphere Integrated Containers asegura las conexiones entre sus diferentes
componentes, con la infraestructura de vSphere y el entorno Docker, mediante el uso de certificados
TLS.
Estos certificados pueden ser personalizados por cada administrador, o pueden autogenerarse. A
continuación, explicamos el esquema de los certificados usados por los distintos componentes de VIC:
Ilustración 13 – Certificados en VIC
4.5 Servicios en VIC
LINK REFERENCIA:
https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/service_status.html
Existen varios servicios que nos pueden dar alguna pista en nuestro appliance VIC y que podemos
comprobar o verificar su estado conectándonos a VIC vía SSH.
Estos son los servicios que verificar:
• harbor.service → vSphere Integrated Containers Registry
• admiral.service → vSphere Integrated Containers Management Portal
• fileserver.service → Servidor de ficheros integrado en VIC
• vic-machine-server → Que nos permite crear los VCH´s a través del plugin HTML5 en vCenter
Como hemos dicho los podemos comprobar vía SSH de la siguiente forma:
systemctl status harbor.service
systemctl status admiral.service
systemctl status fileserver.service
systemctl status vic-machine-server.service
Y puede haber tres tipos de resultados:
Estado Descripción
active (running) El servicio se está ejecutando correctamente
inactive (failed) El servicio no se pudo iniciar.
inactive (dead) El servicio no está respondiendo.
Una muestra del estado de un servicio:
Ilustración 14 – Servicios VIC
Para reiniciar cada componente utilizaríamos el parámetro restart en cada comando.
5. VMware Clouds PKS
Presentada en un principio en el VMware World 2017 US, VMware Cloud Pivotal Container Service
(PKS) se trata de una solución de contenedores basada en Kubernetes. En un principio fue desarrollada
por Pivotal Software y VMware, en colaboración con Google Cloud (Kubernetes).
Pivotal Container Service es la solución de VMware para sus servicios de Contenedores en su

Infraestructura Cloud. VMware Cloud PKS es un servicio en la nube de VMware que proporciona
Kubernetes como servicio.
5.1 ¿Qué es VMware PKS?
VMware Pivotal Container Service (PKS) es una solución de contenedores basada en Kubernetes
(de ahí la “K”), completamente lista para ser puesta en producción, equipada con una gestión de red
avanzada, un registro privado de Contenedores y una gestión completa del ciclo de vida.
PKS simplifica radicalmente la implementación y el funcionamiento de los clústeres de Kubernetes

para poder ejecutar y gestionar Contenedores a escala en nubes privadas y públicas.
A nivel de red, por ejemplo, una sola instancia de VMware NSX-T puede admitir múltiples enrutadores
de nivel 0, que se convierten en una pasarela entre las redes lógicas y las físicas. Con esto, cualquier
organización puede obtener un mayor aislamiento y control de la red. Por ejemplo, es posible utilizar
direcciones IPs superpuestas dentro de la misma infraestructura.
PKS es la versión comercial de KUBO, y está estrechamente integrada con otras soluciones como
Google Container Service (GKE), vSphere, VMware vCloud o VMware NSX para gestionar la seguridad
y la red de los Contenedores.
De hecho, PKS es una solución multi-cloud siendo ya en su versión 1.3 compatible las plataformas
más importantes como son VMware vSphere, Microsoft Azure, Google Cloud Platform y Amazon EC2.
Todo ello desde una interfaz común.
5.2 Componentes VMware PKS
• VMware Harbor: es la solución que ha desarrollado VMware para registrar imágenes de contenedores
y que utilizan PKS como VIC. Recientemente el proyecto ha sido entregado a la CNCF, y gracias
al impulso de la comunidad open source, se integra con proyectos como CoreOS/RedHat Clair que
permite escanear las imágenes en búsqueda de problemas de seguridad o Notary, que permite
firmar las imágenes de los Contenedores.
Ilustración 15 – VMware Harbor
• Bosh: es un proyecto opensource en el que han contribuido empresas como VMware, Google y
Pivotal para implementar Cloud Foundry PaaS, aunque se puede implementar en infraestructuras
IaaS para casi cualquier software como VMware vSphere o vCloud, incluso en otras plataformas
como Microsoft Azure, AWS EC2, Google Compute Platform u Openstack entre otras. Realiza
desde aprovisionamiento, monitoreo, recuperación y actualizaciones de software…ayudando a
gestionar el ciclo de vida del software tanto en nubes pequeñas como a gran escala.
BOSH en Kubernetes o KUBO es el núcleo o corazón de PKS, siendo la herramienta de

implementación de Cloud Foundry. Es el primer componente que se instala en cualquier plataforma
Cloud Foundry.
Ilustración 16 – Cloud Foundry Bosh
• Google Cloud Platform (GCP) Service Broker: proyecto opensource que simplifica la entrega de
servicios a aplicaciones que se ejecutan en Kubernetes. Se basa en la implementación de la API
Open Service Broker (OSB).
Ilustración 17 – Google Cloud Platform
• Cloud Foundry: una arquitectura Cloud Foundry está basada en Contenedores que ejecutan
aplicaciones independientemente de la programación usada. Para dar soporte a recursos
externos también utiliza la API OSB. La premisa es que se puede separar las aplicaciones de la
infraestructura utilizada y ser compatible con cualquier tecnología o herramienta que se utilice
(Docker, Kubernetes, .NET, Java, …).
Ilustración 18 – Cloud Foundry
En el dibujo podéis ver como interactúa cada componente dentro de la infraestructura PKS.
Ilustración 19 – Pivotal Container Service
6. Casos prácticos
En este apartado vamos a mostraros como configurar un entorno de Contenedores en un vCenter On-
Premise y un ejemplo Cloud con PKS.
6.1 Requisitos On-Premise
Hay que cumplir unos requisitos básicos en los hosts antes de empezar la práctica:
LINK REFERENCIA:
https://vmware.github.io/vic-product/assets/files/html/1.5/vic_vsphere_admin/vi_reqs.html
• Licencias Enterprise Plus en los hosts
• Switches distribuidos configurados en host ESXi, con un grupo de puertos para Bridge y otro como
Public:
Ilustración 20 – Distributed Switch
• vSphere Integrated Containers Appliance
• vCenter Server 6.0, 6.5, or 6.7
• ESXi 6.0, 6.5, o 6.7 para todos los hosts
• Al menos 2 vCPUs
• Al menos 8GB de RAM
• Al menos 80GB de disco en Thin Provisioning
• Para la gestión se utiliza el vSphere Client en HTML5. La versión Flash tiene limitaciones y tenderá
a desaparecer.
6.2 Instalación VIC
El primer paso es descargar la OVA desde My Vmware:
Ilustración 21 – My VMware
Cargamos el fichero “Implementar plantilla de OVF”, elegimos red, storage y contraseña para la gestión
en los diferentes pasos:
Ilustración 22 – Plantilla OVF
Habilitamos la regla en el firewall de los hosts ESXi desde “Configurar -> Sistema -> Firewall” al puerto
TCP 2377:
Ilustración 23 – Firewall ESXi
Arrancamos la máquina virtual generada, que como se aprecia dispone de un icono diferente:
Ilustración 24 – VIC
Abrimos una consola de la máquina virtual para saber la IP y nos conectamos vía Web. Y realizamos
la primera conexión a nuestro vCenter como post-instalación:
Ilustración 25 – VIC conexión vCenter Server
6.3 Crear VCH
Una vez instalado VIC y su plugin en vCenter dispondremos de un nuevo menú, pulsamos sobre
“Menú -> vSphere Integrated Containers”
Ilustración 26 – Plugin VIC
Pulsamos nuevamente sobre vSphere Integrated Containers:
Ilustración 27 – vSphere Integrated Containers
Pulsamos sobre “New Virtual Container Host”:
Ilustración 28 – New Virtual Container Host
Le damos un nombre significativo a nuestro VCH y a los Contenedores que generaremos desde él:
Ilustración 29 – Create Virtual Container Host
Seleccionamos un recurso de nuestro Datacenter y pulsamos “Next”:
Ilustración 30 – Compute Capacity
Elegimos Datastore, es buena práctica crear una carpeta para VCH y así tener una mejor gestión.
Adicionalmente, según nuestra necesidad elegiremos el tamaño en disco de los Contenedores:
Ilustración 31 – Storage Capacity
Elegimos el grupo de puertos que hemos preparado previamente como Bridge y Public. Podemos
modificar el rango de red con que nos queremos mover:
Ilustración 32 – Networks
Podemos definir si los clientes necesitan certificados para conectarse a los Contenedores:
Ilustración 33 – Certificates
Una buena práctica, es crear una lista blanca o Whitelist de acceso:
Ilustración 33 – Registry Access
Marcaríamos la casilla y añadiríamos los wildcard domain, CIDR o IP/FQDN que queramos considerar
en la Whitelist:
Ilustración 34 – Registry Access
Introducimos los datos para gestionar vSphere:
Ilustración 35 – Operations User
Pulsamos Finish. Si más adelante queréis repetir los pasos, podéis guardar la configuración en un solo
comando que podréis encontrar en la parte inferior de la sección Summary:
Ilustración 36 – Summary
En unos minutos dispondremos de nuestro Virtual Container Host:
Ilustración 37 – Virtual Container Hosts
En pocos minutos dispondremos de la IP para su gestión, escuchando en dos puertos, uno para
Docker API Endpoint y otro VCH Admin Portal:
Ilustración 38 – Docker API
Y dispondremos de un nuevo elemento en la vista de hosts. Seremos capaces de gestionar los VCH´s
como los Contenedores porque se generan bajo una vApp:
Ilustración 39 – VCH
Ahora necesitamos agregarlo desde el dashboard de VIC para poder utilizarlo en la creación de
Contenedores:
Ilustración 40 – Host de contenedor
Introducimos el puerto y la IP para Docker API Endpoint:
Ilustración 41 – URL Host de contenedor
Verificamos que la conexión es válida:
Ilustración 42 – Verificar Certificado
Si todo es correcto aparecerá como CONECTADO:
Ilustración 43 – Conectado
Podemos aprovisionar Contenedores desde el repositorio oficial. Desde Biblioteca -> Todos los
repositorios -> Repositorios. Desplegamos el botón Aprovisionar y pulsamos Introducir información
adicional.
Ilustración 44 – Introducir información adicional
Rellenamos en el campo Red el puerto que quedará expuesto y también el puerto donde escuchará el
Contenedor:
Ilustración 45 – Aprovisionar un contenedor
El tiempo de ejecución del trabajo dependerá de vuestra infraestructura, pero es una cuestión de
segundos:
Ilustración 46 – Solicitudes
Del Container aprovisionado se generará una máquina virtual que veremos en la vista Hosts y clústeres
de nuestro vCenter dentro de nuestro VCH:
Ilustración 47 – Containers aprovisionados
Y también en la sección Contenedores de VIC que es donde hay que gestionarlo:
Ilustración 48 – Contenedores
La IP del Contenedor es del rango en modo Bridge definido en el Port Group del VCH.
Ilustración 49 – Modo Bridge
Siendo la puerta de enlace de dicha red el propio VCH:
A través de la puerta de enlace que es el VCH y mediante NAT nuestro Contenedor está dando el
servicio por el puerto fijado, en este caso TCP 8080:
Ilustración 51 – Container Nginx
Podréis encontrar más información sobre todos los Contenedores creados desde el “Menú de vuestro
vCenter -> vSphere Integrated Containers”. Se puede ver el estado, ubicación o puertos donde trabaja:
Si queremos Clusterizar el Contenedor desde el dashboard de VIC podemos pulsar en la sección

“Contenedores -> Seleccionamos Contenedor -> Escala”.
Ilustración 53 – Escala
Esto no funciona cuando has fijado el puerto, si no hay hosts libres:
Ilustración 54 – Failed (ERROR)
En unos segundos se generará un Contenedor en paralelo y en vSphere otra máquina virtual:
Si queremos parar o eliminar un Contenedor lo deberemos hacer desde la consola de VIC seleccionando
el Contenedor o los Contenedores sobre los que queremos hacer la acción:
Ilustración 56 – Eliminar o parar Container
Se pueden desplegar varios Contenedores mediante una Plantilla generada vía gráfica o mediante
ficheros YML:
Ilustración 57 – Plantillas
Pulsamos “Importar Plantilla” y copiamos el contenido del fichero YML:
Ilustración 58 – Importar plantilla
6.4 Ejemplo fichero YML
En este ejemplo, vamos a generar varios Contenedores anidados para generar un sencillo Wordpress
con Mysql:
version: ‘2’
services:
db:
image: mysql:5.7
command: --datadir=/var/lib/mysql/data
volumes:
- db-data:/var/lib/mysql
networks:
- db-net
environment:
MYSQL_ROOT_PASSWORD: librovmwarewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- “8081:80”
volumes:
- html-data:/var/www/html
networks:
- web-net
- db-net
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
volumes:
db-data:
driver: “vsphere”
driver_opts:
Capacity: “4G”
VolumeStore: “backed-up-encrypted”
html-data:
driver: “vsphere”
driver_opts:
Capacity: “2G”
VolumeStore: “default”
networks:
web-net:
db-net:
internal: true
6.5 Upgrade VIC
A continuación, vamos a detallar el procedimiento para hacer un Upgrade de vuestro vSphere Integrated
Containers.
Antes de empezar, este procedimiento no debería dejar sin conexión a los VCH y los Contenedores
si hemos implementado bien la red. La idea es generar un nuevo VIC en paralelo y migrar los datos,
Contenedores y VCH´s al nuevo.
Lo primero es bajar el OVA de la nueva versión y cargarla, siguiente el procedimiento de instalación de

VIC. Evitaríamos colocar la misma IP que el anterior appliance:
Ilustración 59 – Cargar OVA VIC
Para actualizar nuestro VMware VIC tendremos que acceder vía SSH al Appliance creado:
Ilustración 60 – IP VIC
Abrimos una consola:
Ilustración 61 – SSH
Utilizamos la contraseña de root:
Ilustración 62 – SSH
Una vez conectados, nos desplazamos al directorio y lanzamos el comando. Destroy es sólo por
eliminar lo antiguo en este paso:
Ilustración 63 – Upgrade.sh
Comienza el proceso de Upgrade, donde podéis ver las respuestas:
Ilustración 64 – Upgrade.sh
Si no se coloca el parámetro Destroy hay que apagar y eliminar el antiguo a mano:
Ilustración 65 – VIC Destroy
En este momento ya estarán migrados todos los proyectos, VCH´s y Contenedores.
Para que los cambios sean efectivos a nivel de vCenter, necesitaremos reiniciar el plugin HTML5
mediante estos comandos vía SSH al vCenter:
service-control --stop vsphere-ui && service-control --start vsphere-ui
service-control --stop vsphere-ui && service-control --start vsphere-ui
service-control --stop vsphere-client && service-control --start vsphere-client
Parámetros adicionales que podemos añadir al comando upgrade:
Ilustración 66 – VIC Destroy
6.6 Desinstalar Plugin VIC
En este procedimiento os vamos a explicar cómo desinstalar el plugin vSphere Integrated Containers:
Ilustración 67 – Plugin VIC
Iremos a la siguiente URL, introducís las credenciales de administrador y pulsáis en la parte inferior
“void -> UnregisterExtension”:
https://vCenter_IP/mob/?moid=ExtensionManager
Ilustración 68 – Managed Object Type
Introducís el valor com.vmware.vic (también com.vmware.vic.ui) y pulsáis “Invoke Method”. Tenéis que
aseguraros que no sale error y sólo muestra void:
Ilustración 69 – Method Invocation Result
6.7 Ejemplo PKS
Os vamos a mostrar un ejemplo de laboratorio generado en uno de los Workshop del VMware World
2018 de Barcelona y que os dejo el enlace al código en github:
LINK REFERENCIA:
https://github.com/Boskey/run_kubernetes_with_vmware/wiki
Es importante que la máquina cliente desde donde os vais a conectar, disponga de VKE CLI y Kubectl,
en próximos puntos veremos el enlace de descarga, disponible tanto para MacOS, Windows o Linux.
Para poder trabajar con VMware Cloud PKS (Vmware Kubernetes Engine (VKE)), deberemos generar
una cuenta desde el siguiente enlace o disponer de una previa en My VMware:
https://console.cloud.vmware.com/csp/gateway/discovery
Una vez creada nos logueamos con nuestro usuario / contraseña:
Ilustración 70 – VMware Cloud Services
Tendríamos que elegir VMware Cloud PKS:
Ilustración 71 – VMware Cloud PKS
Y pulsar Click to Start:
Ilustración 72 – Click to Start
Tendremos que generar una nueva organización si es la primera vez, donde se van a generar nuestros
proyectos:
Ilustración 73 – VMware Cloud Services
E introducir nuestros datos para el cobro de uso de la infraestructura. Para empezar, dispondremos de
150$ de crédito:
Ilustración 74 – Payment Information
Dispondremos en la vista My Services el servicio que vamos a manejar:
Ilustración 75 – My Services
Como podéis imaginar, podemos generar proyectos de diferente índole dentro de la nube de VMware:
Ilustración 76 – Servicios VMware Cloud
Pulsaríamos “Developer center”:
Ilustración 77 – Developer center
Dispondremos del comando de acceso vía consola:
Ilustración 78 – Developer Center
Como hemos comentado, nuestro cliente debe tener instalado el cliente VMware Cloud PKS CLI y
kubectl, que podéis descargar desde Downloads:
Ilustración 79 – Developer Center Downloads
Adicionalmente, desde My Account -> API Tokens, deberemos generar un nuevo Token:
Ilustración 80 – My Account API Tokens
En este ejercicio se dispone de un cluster para cada usuario:
Ilustración 81 – Cluster
Nos conectaríamos desde nuestro cliente al cloud con el nombre de la organización que hemos creado
y nuestro token generado:
vke account login -t ‘your-organization-id’ -r ‘your-refresh-token’
Ilustración 82 – Conexión VMware Cloud PKS
Generamos una carpeta y un Proyecto dentro de VKE:
Ilustración 83 – Crear Folder y Project
Conseguimos la autorización kubectl para nuestro clúster:
Ilustración 84 – My Account API Tokens
Obtenemos nuestros Pods en el clúster:
Ilustracion 84 – Pods
Obtenemos también los servicios:
Ilustración 85 – Servicios
Creamos un namespace. Un namespace está diseñado para usarse en entornos con muchos usuarios
distribuidos en varios proyectos, permitiendo distribuir los recursos de un cluster entre varios usuarios:
Ilustración 86 – Create Namespace
Lo usaremos por defecto:
Ilustración 87 – Namespace default
Listamos los namespaces:
Ilustración 88 – Get Namespaces
Creamos un volumen persistente para MySQL:
Ilustración 89 – Create Volumen Persistent
Verificamos que se ha generado el volumen persistente:
Ilustración 90 – Create Volumen
Desplegamos el pod de MySQL:
Ilustración 91 – Pod MySQL
Implementamos el servidor MySQL que usará el volumen persistente:
Ilustración 92 – MySQL
Ahora desplegamos el Pod del servidor de aplicaciones:
Ilustración 93 – Pod
Desplegamos el Frontend:
Ilustración 94 – Frontend
Desplegamos Redis y ADSB Sync Service:
Ilustración 95 – Redis y ADSB Sync Service
Verificamos que se hayan implementado todos los pods necesarios para los servicios frontend, redis,
DBC Sync y el servidor de aplicaciones.
Ilustración 96 – Verificación Pods
Comprobamos todos los servicios:
Ilustración 97 – Verificación Servicios
Ahora, para poder presentar la aplicación fuera del cluster deberemos crear un servicio que permita el
balanceo de carga:
Ilustración 98 – Balanceo de carga
Comprobamos la IP de balanceo:
Ilustración 99 – Comprobar IP
Con esto disponemos de una publicación de una app con varios servicios enlazados en nuestro
VMware Cloud PKS.
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 19
VMware Code - API
Daniel Romero
Capítulo 19 - VMware Code - API Daniel Romero
VMware {Code}
VMware ha creado una comunidad dedicada a desarrolladores, devops o administradores de

sistemas interesados en la virtualización y su desarrollo, llamada VMware {Code}. A través de un
portal de recursos centralizados es posible acceder a documentación, foros, ejemplos o descargas de
herramientas. Esta comunidad crece continuamente, no sólo de usuarios, sino de recursos gracias a
las nuevas actualizaciones de los productos.
Hasta la publicación de vSphere 6.5 únicamente se disponían de APIs SOAP para el intercambio de
información. Con la llegada del nuevo cliente HTML5 y las nuevas tendencias de desarrollo de software,
VMware ha introducido en sus productos amodelos de API REST que ofrecen a los desarrolladores
una experiencia de programación más completa y sencilla.
Las SDKs también se han actualizado, además se han introducido nuevas. Están disponible en los
lenguajes de programación más populares: .Net, Java, PHP, Python, Javascript, C, Ruby, etc. Esto
ayuda a empresas de terceros a desarrollar productos de calidad y totalmente complementarios a
vSphere, como por ejemplo: integración con herramientas de copias de seguridad, monitorización,
automatización, etc.
A lo largo de este capítulo aprenderemos a trabajar con la API REST de VMware sin hacer uso de las
SDK.
1. ¿Qué es una API REST?
Antes de comenzar haremos un repaso al concepto de API. Una API tal y como su acrónimo en inglés
indica es una interfaz de programación de aplicaciones que permite el intercambio de mensajes o
datos entre dos aplicaciones mediante el uso de operaciones, normalmente basadas en el protocolo
HTTP. Ésta permite aislar el cliente del servidor proporcionando fiabilidad y escalabilidad. Además,
puede ser desarrollada en cualquier lenguaje de programación.
La API REST utiliza un protocolo de cliente/servidor sin estado. Por esto, se requiere enviar toda la
información necesaria en la petición HTTP del cliente. ¿Qué quiere decir esto? Supongamos una API
que requiera autenticación para acceder a información sensible. Cada vez que se realice una llamada
a ésta, hay que enviarle los parámetros correspondientes que permitan el acceso a la información,
mediante el uso de credenciales o un token de autorización.
Sin entrar en profundidad en el protocolo HTTP, hay que saber que las peticiones enviadas a través
de éste se realizan mediante cabeceras, que son las encargadas de transportar la información entre
el cliente y el servidor.
Las operaciones o métodos más comunes utilizadas en este tipo de APIs son:
• POST (crear)
• GET (consultar)
• PUT (editar)
• DELETE (eliminar)
Se forman mediante URIs con la siguiente estructura:
{protocolo}://{host}[:puerto]/{ruta del recurso}?{operación}
Es muy común recibir las respuestas de las llamadas en formato JSON, aunque también es posible
obtenerla en XML u otros formatos. Durante este capítulo todas las respuestas de ejemplo serán en
formato JSON, que es el utilizado por VMware.
Hay que tener en cuenta que las llamadas pueden responder con errores, ya sean porque el recurso
no esté disponible, no se disponga de permisos o cualquier otro factor. La definición de estos errores
se suele realizar mediante códigos de estado de HTTP. Los más comunes que se pueden encontrar
son:
Código HTTP Razón

200 Respuesta correcta
400 La solicitud contiene errores
401 Solicitud sin permisos o autenticación
403 Solicitud sin privilegios para acceder al servicio
503 Servicio no disponible
1.1 Cómo funciona
Para entender correctamente qué es y cómo funciona tenemos que imaginar una API que sea capaz
de editar, consultar o borrar un capítulo de este libro y se desea consultar el capítulo 19.
Primero se formará la URI en el formato que se mencionó anteriormente:
• Protocolo y host: https://vmwareporvexperts.org
• Ruta del recurso: /libro/capitulo/19
• Operación: /consultar
Ahora hay que identificar la operación realizada. Consultar equivale al método GET por lo que utilizando
la herramienta CURL a través de una línea de comandos se podría realizar la llamada correspondiente
y obtener la información.
curl –XGET https://vmwareporvexperts.org/libro/capitulo/19/consultar
Al lanzar el comando se obtendría la respuesta deseada, en este caso la información correspondiente

al capítulo 19.
2. API REST DE VMware
2.1 Diferentes APIs REST de VMware
Ahora que ya se conocemos cómo funciona una API REST, es el momento de ver las APIs que VMware
pone a disposición de los usuarios. Éstas han sido clasificadas dependiendo del entorno o plataforma
a la que pertenecen:
• Cloud Management Platform
• vRealize Automation
• vRealize Log Insight
• vRealize Operations
• vRealize Orchestrator
• vRealize Suite Lifecycle Manager.
• Data Center & Cloud Infraestructure
• vCloud Director For Service Providers
• vCloud Director
• vSphere
• Desktop & Application Virtualization
• Horizon
• Horizon View
• Digital Workspace
• Identity Manager
• Workspace ONE Notifications Service
• Networking & Security
• NSX for vSphere
• NSX-T
• vRealize Network Insight
• Personal Desktop
• Fusion
• Storage & Availability
• VSAN
• Other Platform
• Apteligent
• VMware Cloud on AWS
• VMware Integrated OpenStack
• vCloud Availability for Cloud-to-Cloud DR
• vCloud Usage Meter
No es objetivo de este capítulo aprender cómo funciona cada una de las API mencionadas anteriormente,
sino saber cómo usarlas de forma general. Para ello veremos ejemplos de uso de la API de vSphere.
Podemos consultar toda la documentación de éstas en la dirección: https://code.vmware.com/apis/
2.2 Cómo acceder al explorador de API de vSphere.
Para acceder al catálogo de APIs disponibles basta con abrir en un navegador web la URL de acceso
a vCenter añadiendo la ruta apiexplorer:
https://vcenter.vmwareporvexperts.org/apiexplorer/
La ventana abierta es el Explorador de APIs. Una vez se accedemos podemos ver a través de un
desplegable las diferentes APIs que hay disponible en el entorno vSphere junto con sus recursos. Este
explorador es de gran utilidad ya que permite conocer la definición de cada uno de los recursos de la
API. En resumidas palabras, se puede decir que es la documentación de uso de las APIs.
VMware se ha basado en la interfaz de usuario Swagger UI para la creación del explorador. De esta
forma es posible conocer toda la definición de la API e incluso ejecutar operaciones siempre y cuando
nos encontremos autenticados con un usuario que disponga de permisos suficientes para operar sobre
los componentes de vSphere.
2.3 Recursos de la API de vSphere
Para entender cómo se utiliza la API REST de VMware se utilizará de ejemplo la API de vSphere.
A través del explorador vamos a ver cómo se accede a algunos de los recursos disponibles, por
ejemplo, el de vCenter. Una vez se ha accedido a la URL, en el desplegable Select API hay que
seleccionar vcenter.
Si se recorre todo el listado de recursos que se han cargado, se observará que hay disponibles
diferentes rutas que están clasificadas por cada uno de los componentes de vCenter:
• Cluster
• Datacenter
• Datastore
• Deployment
• Folder
• Guest
• Host
• Inventory
• Network
• OVF
• Resource pool
• Services
• Storage
• System config
• VCHA
• VM
Si pulsamos sobre algún recurso veremos que se despliegan las diferentes operaciones disponibles.
Si volvemos a la definición de API REST, podemos identificar claramente las partes que componen la
URI. Por ejemplo, veamos el recurso GET vm/power que formaría la siguiente URI.
https://venter.vmwareporvexperts.org/rest/vcenter/vm/power
Los métodos son fácilmente identificables ya que aparecen agrupados en diferentes colores. Azul
para los métodos GET, verde para los POST y rojo para DELETE. En la siguiente imagen se pueden
apreciar las operaciones disponibles sobre el encendido/apagado de una máquina virtual.
2.4 Operaciones sobre los recursos de la API
Ya conocemos cómo identificar las operaciones disponibles sobre un recurso, veamos la estructura
general de una de ellas a nivel de parámetros y respuestas.
Tal y como se comentó al comienzo de este capítulo, una respuesta correcta de un método de la API
devuelve el código de estado HTTP 200. Además, suele añadir un cuerpo (body) con la información
de dicha respuesta, aunque hay operaciones que no lo necesitan. Es la primera información que
encontrarás cuando hagas clic sobre una de las operaciones en el explorador de API.
La mayoría de las operaciones sobre una API necesitan parámetros de entrada que permitan identificar
sobre qué objeto se va a operar. Algunos pueden ser obligatorios y otros opcionales a modo de filtro.
Dependiendo del método utilizado se enviará mediante la URI o bien por POST.
En toda definición de la arquitectura de una API se encuentran los mensajes de error. Estos mensajes
permiten identificar mediante códigos HTTP el motivo por el que una operación ha respondido de
forma incorrecta. A través del explorador podemos conocer la razón por la que una operación puede
estar fallando.
El modelo de respuesta de una operación incluye el código de estado de ésta, el cuerpo de la respuesta
y otras cabeceras de ayuda. En la siguiente imagen se podemos observar la respuesta del estado de
una máquina virtual.
VMware ha creado una API bastante bien documentada. Esto ayuda a la comunidad de desarrolladores
enormemente ya que permite interactuar con los componentes del propio software de VMware de
manera sencilla.
2.5 Cómo apagar una máquina virtual desde el explorador de APIs
Veamos un ejemplo práctico de cómo apagar una máquina virtual utilizando el explorador. Hay que
estar autenticado para poder realizar el siguiente ejemplo.
En las operaciones sobre la manipulación del estado de una máquina virtual que se vio anteriormente,
había una de ellas que permitía el apagado de éstas.
POST /vcenter/vm/{vm}/power/stop
Al acceder a esta operación podemos comprobar que no va a devolver un cuerpo de respuesta en

caso de que sea satisfactoria. Únicamente devolverá el código de estado 200. Además, solicita un
parámetro de entrada obligatorio para identificar la máquina virtual que se desea apagar.
“Virtual machine identifier. The parameter must be an identifier for the resource type:
VirtualMachine”
Este identificador es único y la forma de conocerlo es accediendo al recurso de la API VM.
Una vez localizado el recurso, pulsamos sobre la operación GET /vcenter/vm. Cuando se despliegue
toda la estructura de la definición de este método, se podremos comprobar todos los parámetros de
entrada solicitados. En este caso, todos son opcionales, por lo que los dejaremos en blanco. nos
dirigimos a la parte final y hacemos clic sobre el botón azul TRY IT OUT.
Una vez lancemos la petición, se obtendremos una respuesta en el cuerpo en formato JSON que
contiene un ARRAY de valores. Cada elemento que lo compone muestra información de las máquinas
virtuales disponibles.
Tenemos que identificar la máquina virtual que se quiere apagar. El parámetro name nos ayudará a
encontrarla. Una vez se tenga, apuntamos el valor del parámetro vm, que es el parámetro obligatorio
que la mayoría de las operaciones requieren para trabajar con una máquina virtual.
Es el momento de volver al método POST /vcenter/vm/{vm}/power/stop e introducir el identificador de

la máquina virtual que se quiere apagar.
Al igual que hicimos anteriormente, hay que desplazarse hasta el final de la definición del método y
pulsar en TRY IT OUT.
Si la máquina virtual que se ha tratado de apagar existe, se recibiremos la respuesta con el código de
estado HTTP 200. Hay que recordar que esta operación no devuelve ningún mensaje en el cuerpo, tal
y como se observa en la siguiente imagen:
Este proceso es algo engorroso y no muy práctico para apagar una máquina virtual pero el objetivo de
este ejemplo es familiarizarse con la definición de la API y saber utilizar el explorador.
CONSEJO: Entender cómo funciona el explorador de la API de VMware te va a permitir

desenvolverte igualmente con otras APIs que utilizan Swagger UI.
3. Desarrollo
El desarrollo ya no es solo cosa de los programadores. Hasta no hace muchos años, ha sido muy común
ver como operadores desplegaban de forma manual el mismo tipo de máquina virtual cada vez que el
equipo de desarrollo necesitaba probar una versión de código nueva. Hoy en día todo este proceso se
puede automatizar gracias a la disponibilidad de APIs que permiten integrar las herramientas utilizadas
con desarrollos propios.
Los lenguajes de programación más utilizados en la actualidad para realizar estas operaciones son
Python y Javascript (Node.js) ya que son muy versátiles para trabajar con llamadas a APIs. Teniendo
en cuenta el ejemplo anterior del apagado de la máquina virtual, en este apartado veremos cómo
automatizarlo mediante estos lenguajes de programación.
También es posible realizarlo a través de comandos BASH o bien utilizando Powershell, pero no es
objetivo de este capítulo.
Todos los ejemplos con los que se trabajaremos en este capítulo han sido subidos al repositorio oficial
libro VMware por vExperts en GitHub. Puedes acceder a ellos a través de la siguiente URL:
https://github.com/vmwareporvexperts/vmwareporvexperts
3.1 Accediendo a la API REST de VMware a través de PYTHON
Python puede estar entre los tres lenguajes de programación más utilizado de la actualidad. Es muy
sencillo de aprender y versátil. Hoy en día se ha convertido en una herramienta más para cualquier
administrador de sistemas.
En este apartado se realizaremos el ejemplo anterior utilizando Python 3.x. Es recomendable estar
familiarizado con sus sintaxis.
Cualquier script en Python comienza importando los módulos o librerías que se van a usar. Request
es una de las librerías más utilizadas para realizar llamadas HTTP. Su uso es muy sencillo y permite
realizar operaciones GET y POST con pocas líneas de código. Trabajaremos con ella para acceder a
los métodos de la API de vSphere apilando diferentes llamadas. Procederemos a instalar la librería en
caso de no disponer de ella.
pip install request
Un requisito obligatorio para poder trabajar con la de API vSphere es estar autenticado. Ahora ya no
vamos a usar el explorador por lo que es necesario obtener autorización de vCenter para poder apagar
la máquina virtual.
El primer paso consiste en obtener el token, que permitirá que podamos realizar las operaciones
necesarias hasta conseguir apagar la máquina virtual.
Esto se realiza mediante el método POST /com/vmware/cis/session. Este método utiliza la cabecera
vmware-use-header-authn como protección contra CSRF. Además, hay que pasar unas credenciales
de acceso a vCenter que dispongan de permisos para listar y apagar máquinas virtuales. Este devuelve
un token que será utilizado en el resto de las llamadas a la API.
Continuando con el ejemplo de apagado de la máquina virtual, ahora hay que realizar la llamada al
método GET /vcenter/vm pasando en la cabecera el token obtenido anteriormente en el parámetro
vmware-api-session-id.
Esta petición devuelve una respuesta en el cuerpo en formato JSON con los datos de las máquinas
virtuales.
Si la máquina que se desea apagar es la llamada “vm01” hay que obtener el valor del campo “vm”. Esto
se puede hacer fácilmente recorriendo el array hasta encontrarla.
Una vez encontrada, se guarda el valor en la variable vmid. Este es el parámetro obligatorio que el
método POST /vcenter/vm/{vm}/power/stop utiliza para identificar la máquina virtual que se quiere
apagar. Por último, sólo queda invocar la llamada que ejecutará la opción de apagado.
Si la máquina virtual estaba encendida, ésta se apagará y se recibirá un código de estado HTTP 200
en caso de que estuviese apagada el código de estado será 400.
CONSEJO: En el código anterior se ha simplificado y no se controlan las llamadas fallidas a la API.

Es aconsejable comprobar que en las respuestas de las llamadas se obtiene el código de estado
HTTP 200. En caso contrario se debería lanzar una excepción, ya que el resto de las llamadas
fallarán.
3.2 Accediendo a la API REST de VMware a través de NODE.JS
Node.js es un entorno de ejecución de Javascript que está basado en el motor V8 de Javascript

de Google. En la actualidad es muy utilizado en arquitecturas de microservicios ya que necesita muy
pocos recursos para su ejecución.
En lugar de utilizar la librería Request para las llamadas a la API en Javascript se utilizará Unirest, una
librería que es bastante más ligera y fácil de usar.
En este momento, en caso de no tener la librería Unirest habría que instalarla.
npm install unirest
También hay que tener en cuenta que por naturaleza Javascript realiza peticiones de forma asíncrona
y habrá que realizar alguna adaptación para hacerla síncrona. Es recomendable tener experiencia
previa en este lenguaje para entender las operaciones que se van a realizar.
Continuando con los ejemplos anteriores, ahora toca el turno de encender la máquina virtual.
El primer paso consiste, nuevamente, en autenticarnos y conseguir unas credenciales válidas para
poder realizar llamadas a la API de vCenter.
Se ha creado la función getToken() que realiza la petición POST /com/vmware/cis/session pasándole

cómo parámetros los datos de acceso a vCenter. Esta función devuelve una promesa que contiene el
cuerpo de la respuesta. Si todo ha ido bien obtendremos el token que se necesitará para el resto de
las operaciones.
Lo siguiente es construir la función que se encargará de encender la máquina virtual, la llamaremos

startVM(). Esta anidará dos llamadas a la API: la primera para obtendrá el id de la máquina virtual y la
segunda que realizará el encendido.
Anteriormente se mencionó que Javascript opera de forma asíncrona de manera general. Para trabajar
con APIs que necesitan llamadas correlativas hay que realizar una serie de modificaciones para que
las peticiones sean síncronas. Esto quiere decir que antes de realizar la siguiente llamada, hay que
esperar a que una llamada finalice y devuelva su respuesta.
Para conseguirlo hay que inicializar la función startVM() utilizando la expresión async. Esta función
debe de parar su hilo de ejecución cuando se invoque la función getToken(). Esto se consigue utilizando
la expresión await antes de su llamada. De esta forma hasta que no se obtenga el token la función no
continuará con el resto de las llamadas.
Si se observa el código anterior, una vez obtenido el token, se realiza una llamada al método GET /
vcenter/vm que devuelve el listado de máquinas virtuales. Busca la máquina llamada vm01 y guarda
su identificador para posteriormente hacer la operación POST /vcenter/vm/{vm}/power/start que se
encargará de encenderla.
4. Cómo contribuir en VMware {Code}
Hemos aprendido a trabajar con la API REST de VMware. Ahora que somos capaces de crear código
para operar con los diferentes componentes de vSphere podemos compartirlo con el resto de los
usuarios y así enriquecer la comunidad.
Es muy importante que todo el código de ejemplo que se vaya a subir no contenga datos sensibles
como URLs o credenciales de acceso.
A través de la siguiente URL https://code.vmware.com/samples se pueden subir los ejemplos de

desarrollos realizados.
Una vez se ha accedido a la URL hay que pulsar en Add New Sample. Dentro, en el primer paso
tenemos la posibilidad de:
• Copiar y pegar el código
• Subir el código de forma comprimida
• Vincular un repositorio de Github
Dependiendo de la elección seleccionada anteriormente, se habilitará en el paso dos las opciones para
añadir el código. Se verá como ejemplo el uso del repositorio de Github creado para este libro.
Al vincular el repositorio se ha seleccionado la ruta en la que se encuentran los ejemplos en Python de

este capítulo para no mezclar distintos lenguajes de programación.
El siguiente paso es rellenar la información necesaria para identificar el código que queremos compartir:
título, descripción, lenguaje, plataforma, etiquetas...
Con todos los datos rellenos ya se puede subir el código pulsando en el botón de Submit. De esta
forma se ha contribuido a la comunidad con los ejemplos realizados en este capítulo para que otros
usuarios puedan utilizarlos.
GLOSARIO
API: Interfaz de programación de aplicaciones.
REST: Transferencia de Estado Representacional.
SOAP: Protocolo simple de acceso a objetos.
HTML5: Quinta revisión del lenguaje básico de la World Wide Web, HTML.
SDK: Kit de desarrollo de Software.
URI: Identificador de recursos uniforme.
NODE.JS: Entorno de ejecución de Javascript basado en el motor V8 de Javascript de Google.
PYTHON: Lenguaje de programación interpretado.
CSRF: Exploit malicioso que consiste en la falsificación de petición en sitios cruzados.
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 20
VMware Cloud on AWS
Jorge de la Cruz
Capítulo 20 - VMware Cloud on AWS Jorge de la Cruz
1. Introducción a VMware Cloud en AWS
1.1 ¿Qué es VMware Cloud en AWS?
VMware Cloud en AWS nos ofrece todo el poder que ya conocemos de vSphere, ejecutándose en los
Datacenter de Amazon. Consiste en host ESXi baremetal con vCenter, vSAN para el Storage y NSX
para el Networking y Seguridad. Ya que es vSphere, todo el conocimiento adquirido durante estos
años, los scripts que pudiéramos tener o incluso aplicaciones de gestión e incluso Backups, van a
funcionar de la misma manera que lo hacen hoy.
VMware Cloud en AWS aporta las amplias, diversas y ricas innovaciones de los servicios de AWS de
forma nativa a las aplicaciones empresariales que se ejecutan en las plataformas de virtualización de
red, almacenamiento y computación de VMware. Esto nos permite añadir fácil y rápidamente nuevas
innovaciones a sus aplicaciones empresariales mediante la integración nativa de las capacidades
de infraestructura y plataforma de AWS, como AWS Lambda, Amazon Simple Queue Service (SQS),
Amazon S3, Elastic Load Balancing, Amazon RDS, Amazon DynamoDB, Amazon Kinesis y Amazon
Redshift, entre muchos otros.
Con VMware Cloud en AWS, las organizaciones podemos simplificar sus operaciones de TI híbridas
utilizando las mismas tecnologías de VMware Cloud Foundation, incluyendo vSphere, vSAN, NSX y
vCenter Server, en sus centros de datos locales y en AWS Cloud sin tener que comprar hardware nuevo
o personalizado, reescribir aplicaciones o modificar sus modelos operativos. El servicio aprovisiona
automáticamente la infraestructura y proporciona compatibilidad total con la VM y portabilidad de la
carga de trabajo entre nuestros entornos locales y la nube AWS Cloud. Con VMware Cloud en AWS,
podemos aprovechar la amplia gama de servicios de AWS, incluyendo computación, bases de datos,
análisis, Internet of Things (IoT), seguridad, móviles, despliegue, servicios de aplicaciones y mucho
más.
1.2 ¿Por qué es tan importante VMware Cloud en AWS?
Esta solución conjunta nos proporciona lo mejor de VMware, y lo mejor de AWS y hará la vida más
sencilla a los clientes que lo utilicen.
• VMware
• Liderando la parte de computo, almacenamiento y red
• Soporte para una cantidad gigante de cargas de trabajo
• La solución estándar en cualquier Datacenter hoy en día
• AWS
• El pago por consumo y flexibilidad
• Amplia gama de servicios cloud
• Escalado y posicionamiento Global
1.3 La solución: VMware Cloud en AWS (VMC)
• VMware SSDC stack ejecutándose en AWS
• Computo (vSphere), Almacenamiento (vSAN) y red con seguridad (NSX)
• Acceso directo a vCenter, incluye además soporte completo para API/CLI
• Entregado como servicio (todo el ciclo de versiones de VMware vSphere completamente

gestionado por VMware)
• Modo de operación consistente que nos permite beneficiarnos del Cloud Híbrido
• Soporte completo para aplicaciones ya existentes o futuras
• Herramientas de gestión que se pueden añadir como capas encima de la solución
• Despliegue en modo Hybrid o Cloud-only está disponible
• Beneficio de lo económico de cloud, alineando capacidad y demanda
• Una única factura por parte de VMware, para licencias de VMware y la Infraestructura de AWS
• Descuentos para clientes grandes por volumen en licencias de VMware
• Consumir de manera elástica clústers de SDDC
• On-demand o suscripción
• Aprovechar todo el recorrido de AWS
El servicio ya está disponible en diferentes ubicaciones del mundo, siguiendo obviamente los Datacenter
donde Amazon Web Services ya presta servicio, durante todo 2018 se ha expandido a muchas más
regiones, y 2019 se espera que este servicio llegue a muchas otras nuevas localidades.
1.4 Precio y requerimientos mínimos
VMware ha habilitado una página web con todos los detalles del producto, muchos vídeos para
ayudarnos con esta tecnología, y uno dedicado al precio.
A la hora de hardware, VMware no se pilla los dedos y nos ofrece cada server con dos CPU que llegan
a los 36 cores, 72 hyper-threads, 512GB de RAM y de almacenamiento flash local (3.6TB caché,
10.7TB capacidad raw en tier).
• La configuración mínima son 3 Hosts de ESXi, y desde ahí podemos crecer sin límite tanto como
nuestro negocio necesite.
• Es posible desplegar un SDDC con un único Host (Single Host SDDC), perfecto para probar la
Infraestructura, o para determinadas situaciones de DR. Este Host tiene un ciclo de vida de 30 días
máximo, tendrá que convertirse en uno de los SDDC con 3 o 4 hosts o es destruido.
A la hora de consumir la tecnología, y hacer la facturación podemos pagar de tres maneras diferentes:
consumo por hora, pago fijo a un año y pago fijo a tres años.
Lista de precios:
ON-DEMAND (HORA) 1 AÑO RESERVADO 3 AÑOS RESERVADO

PRECIO PÚBLICO ($
$8.3681 $ 51,987 $109,366
POR HOST)
AHORRO
COMPARANDO CON 30.00% 50.00%
ON-DEMAND
De todas formas, os invito a visitar la siguiente página web donde podemos incluso calcular nuestras
cargas de trabajo de manera más personalizada - https://cloud.vmware.com/vmc-aws/pricing
2. Cómo crear un SDDC en VMware Cloud on AWS y

primer vistazo a la solución
Vamos a ver un paso a paso de cómo crear un Software Defined Datacenter en VMware en AWS.
Nada más conectarnos a nuestra cuenta de VMware Cloud on AWS veremos un botón grande donde
podremos crear un nuevo SDDC:
El siguiente paso será seleccionar la región donde queremos lanzar este SDDC, si queremos que sea
Single-Node o Multi-Node y un nombre, tan simple como esto:
En el segundo paso podremos conectar nuestro SDDC a nuestra cuenta de AWS, para poder
expandir nuestro entorno vCenter con S3, EC2, y todos los servicios que el cloud de Amazon ofrece,
seleccionaremos Skip for now:
Por último, seleccionaremos el rango de red que queremos usar para nuestros elementos del SDDC
internos, en mi caso he seleccionado 10.2.0.0/20:
Y con estos tres simples pasos, nuestro SDDC comenzará a desplegarse de forma automatizada,
ESXi, vCenters, VSAN, NSX, todo estará listo en apenas dos horas sin tocar ni una sola tecla más,
disfrutar:
Voilá, pasadas las dos horas ya podremos ver el resumen de nuestro SDDC, con 83GHz, 512GB de
memoria RAM y 10TB de Storage VSAN:
Dentro de View details podemos ver el resumen de nuestro entorno, hacerlo crecer, etc.
En la parte de Networking, por ejemplo, podremos ver el direccionamiento de nuestro entorno de

Management y Compute, y también tenemos dos satélites, uno es Internet y el otro es nuestro Data
Center local que tenemos on-prem, por ahora no están conectados entre sí, pero esto lo veremos mas
adelante.
3. Conectar nuestra cuenta de AWS con nuestra

Infraestructura de VMC
Vamos a ver cómo conectar nuestro entorno de VMware Cloud on AWS con nuestra cuenta de AWS,
para poder usar los servicios de AWS tales como EC2, Balanceadores de Carga, y mucho más, con
nuestras aplicaciones que ejecutamos en nuestro VMware Cloud on AWS. La topología que buscamos
será algo similar a esto donde nuestro VMware Cloud VPC con todos sus Hosts y VMs internas, tendrán
acceso al VPC creado en AWS, donde tendremos dentro las diferentes subnets, EC2, servicios, etc:
El primero paso será irnos hasta nuestro SDDC, y sobre él haremos click en Connect to AWS:
El proceso nos conectará de manera inmediata nuestra cuenta de VMC con la de AWS, podemos
revisar la cuenta, y el CF-Stack, etc, haremos click en Next:
Seleccionaremos el VPC de AWS al que queremos conectar nuestro entorno de VMware Cloud on
AWS, y la subnet que tenemos dentro de ese AWS VPC:
El proceso comenzará y veremos la notificación en la barra superior derecha:
Pasados entre 30 segundos a 1 minuto ya veremos que la conexión se ha realizado correctamente:
Finalmente, si nos volvemos a nuestro SDDC, en la parte de Network podremos ver que nuestra red
de Compute ya tiene acceso directo a nuestro entorno de Amazon VPC.
Nota: Recordar que el Firewall está configurado para denegar todas las conexiones, con lo que
tendremos que crear reglas de Firewall para permitir el acceso entre las ubicaciones.
Nota: Como podemos ver hay dos redes, la de Management, que es donde está todo el direccionamiento
de gestión de la plataforma, por ejemplo, el vCenter y su puerto 443 tiene que ser abierto aquí. Mientras
que en Compute Gateway es la parte de red que las VMs dentro de los Hosts tendrán, es allí donde
tendremos que habilitar por ejemplo el SSH hacía un VM que estemos ejecutando dentro de nuestro
SDDC.
3.1 Habilitar el tráfico entrante ENI en la red de Compute
• Haremos click en la pestaña de ‘Network’
• Haremos scroll hasta la sección de ‘Compute Gateway’
• Expandiremos ‘Firewall Rules’
• Haremos click en ‘Add Rule’
• Seleccionaremos ‘ENI – Inbound’ para el campo ‘Rule Name’
• Haremos cllick en el drop-down donde dice ‘Source’y seleccionaremos ‘All Connected Amazon
VPC’
• En el campo llamado ‘Destination’ , escribiremos nuestro rango del VPC de AWS en este caso
‘192.168.0.0/16’
• Haremos click en el drop-down donde pone ‘Service’ y seleccionaremos ‘Any (All Traffic)’
• Finalmente haremos click en ‘SAVE’
3.2 Habilitar el tráfico saliente ENI en la red de Compute
• Haremos click en ‘Add Rule’
• Escribiremos ‘ENI – Outbound’ donde pone ‘Rule Name’
• Haremos click en el drop-down donde dice ‘Source’ y escribiremos ‘192.168.0.0/16’
• Donde pone ‘Destination’, haremos click en el drop-down y seleccionaremos ‘All Connected

Amazon VPC’
• Haremos click en el drop-down donde pone ‘Service’ y seleccionaremos ‘Any (All Traffic)’
• Finalmente haremos click en ‘SAVE’
Ya tendríamos todo configurado y preparado para permitir el tráfico entre nuestro entorno de VMC y
de AWS.
4. Conectar nuestro Datacenter (pFsense) con nuestra

Infraestructura de VMC
Es turno en este capítulo de ver cómo podemos interconectar nuestro Datacenter con VMware Cloud
on AWS usando VPN IPsec.
4.1 Parámetros básicos que tenemos que tener en cuenta para la VPN
Antes de empezar a configurar nada, tenemos que tener planificado cómo queremos configurar la
VPN, no solo esto, pero también las IP públicas y los rangos internos que queremos interconectar,
preparar una tabla como la siguiente nos ayudará en los pasos posteriores:
Parámetro Valor Editable

IP Pública AWS VMC MGM Gateway 35.177.252.176 No
Rango de Red AWS VMC MGM 10.2.0.0/20 No
IP Pública de nuestro Datacenter 86.1.207.63 No
Rango de Red de nuestro Datacenter 192.168.1.0/24 No
Protocolo IKEv1 No
Modo ISAKMP Main mode No
Algoritmo de Cifrado AES-256 Si
Algoritmo de Hashing SHA1 No
Diffie Hellman DH2 Si
Autenticación IKE Pre-Shared Key Si
Tiempo de vida de ISAKMP/IKE SA 28800 seconds No
4.2 Configuración de VPN en nuestro pfSense
Ahora que conocemos ya los detalles de ambos entornos, vamos a comenzar con la configuración de
nuestro lado, nuestro Datacenter. En mi caso estoy usando pfSense, con IP pública dinámica, con lo
que es bastante sencillo de configurar, incluso en mi caso.
4.2.1 Configuración de VPN Phase 1

El primero paso será hacer login en nuestro pFsense con un usuario con privilegios para editar la
configuración:
Nos iremos hasta VPN – IPsec para configurar nuestro lado de la VPN:
Añadiremos la primera fase de la intercomunicación entre sitios:
Hay que recordar que usaremos todos los parámetros que hemos definido anteriormente, he marcado
con azul los realmente importantes:
Ahora que tenemos la Phase 1 completada, tendremos que configurar la Phase 2, que es el rango
interno al que la VPN tendrá acceso, etc.
4.2.2 Configuración de VPN Phase 2

Al igual que anteriormente, lo primero es tener claro la configuración que queremos para esta fase, por
ejemplo:
Parámetro Valor Editable

Algoritmo de Cifrado AES-256 Si
Diffie Hellman DH2 Si
Algoritmo de Hashing SHA1 No
Tiempo de vida de SA 3600 seconds No
Perfect forward secrecy (PFS) Enabled Si
Desde el menú de VPN – IPsec, veremos nuestro Túnel, haremos click en Show Phase 2 Entries y
haremos click en Add P2
La configuración tiene que quedar similar a la siguiente, he marcado con azul las partes importantes:
Ahora que tenemos ya todo configurado en nuestro pfSense, es el turno de la configuración final en la
parte de VMware Cloud on AWS, vamos a por ello.
4.3 Configuración de VPN en VMware Cloud on AWS
Desde nuestro portal de configuración nos iremos hasta Network y en la parte de Management
Gateway, haremos click en Add VPN:
La configuración de la VPN tiene que contener toda la información que hemos recabado anteriormente,
de la siguiente manera:
Una vez que hagamos click en Save, ya podremos ver que pasados unos segundos la VPN se encuentra
en estado conectado, en color verde:
Con esto ya tendríamos interconectado nuesto Datacenter local con nuestro Datacenter en VMware
Cloud on AWS. En siguientes entradas veremos más pasos para dejar esta configuración de red
perfectamente configurada, como es la configuración de DNS y Firewall, etc.
5. Despliegue y Configuración de Cloud Gateway para

habilitar Hybrid Cloud Extension en VMC
Es turno de ver cómo podemos controlar con una vista única nuestros dos vCenter, el local en nuestro
Datacenter y nuestro vCenter en VMware Cloud on AWS usando Hybrid Linked Mode.
5.1 Hybrid Linked Mode
El Hybrid Linked Mode nos permite enlazar nuestra instancia de VMware Cloud en AWS vCenter
Server con un dominio vCenter Single Sign-On local.
Si vinculamos nuestro servidor de vCenter en la nube a un dominio que contiene varias instancias de
vCenter Server enlazadas mediante el modo vinculado mejorado, todas esas instancias se vincularán
a nuestro SDDC en la nube.
Usando el Hybrid Linked Mode, podemos:
• Visualizar y gestionar los inventarios de nuestros centros de datos VMware Cloud y VMware
Cloud en AWS desde una única interfaz de vSphere Client, a la que se accede mediante nuestras
credenciales locales.
• Migrar cargas de trabajo entre nuestro centro de datos local y SDDC en nube.
• Compartir etiquetas y categorías de etiquetas desde la instancia de vCenter Server a nuestro

SDDC en la nube.
Existen dos opciones para configurar el Hybrid Linked Mode. Sólo podemos utilizar una de estas
opciones a la vez.
• Podemos instalar el dispositivo Cloud Gateway Appliance y utilizarlo para enlazar desde nuestro
centro de datos local a su SDDC en nube. En este caso, los grupos de Active Directory se asignan
desde el entorno local a la nube. No es necesario que añadamos Active Directory como fuente de
identidad en nuestro servidor vCenter en nube.
• Podemos enlazar desde nuestro SDDC en la nube a nuestro centro de datos local. En este caso,
debemos añadir Active Directory como fuente de identidad al servidor vCenter de cloud computing.
El primer paso que haremos será irnos hasta nuestro portal de descargas para descargar VMware
vCenter Cloud Gateway:
Una vez hemos descargado y ejecutado el instalador, un asistente nos mostrará el camino para realizar
la instalación del appliance:
Vemos que se compone de dos fases, la primera es desplegar el appliance en nuestro entorno, y la
segunda se corresponde a la configuración del mismo, vamos allá:
Aceptaremos la EULA una vez leída:
Seleccionaremos nuestro vCenter local donde queremos desplegar este appliance:
Una carpeta dentro de la Infraestructura donde queramos almacenar este appliance:
Seleccionaremos ahora el host o cluster donde queremos lanzar el appliance:
Y le asignaremos un nombre y una contraseña de root:
Es el turno de seleccionar donde queremos lanzar este appliance, y si lo queremos en modo Thin:
Y el último paso será configurar la parte de Networking, muy importante es que la entrada de DNS, así
como la reverse DNS, estén configuradas para el nombre e IP que seleccionamos:
Seleccionaremos el SSO que queremos usar, en este caso es el mismo que el propio VCSA ya que
tengo mi PSC en el mismo equipo:
El proceso comenzará y el appliance comenzará a desplegarse, en mi caso ha tardado unos 10 minutos:
Ahora es el momento de la segunda fase, haremos click en Start:
Nos mostrará el asistente un poco de información de lo que significa el Hybrid Linked Mode, etc:
Seleccionaremos aquí el vCenter Server que tenemos en VMware Cloud on AWS, y las credenciales,
todo disponible desde nuestro portal de SDDC, importante que seleccionemos que usuarios de nuestro
dominio local pueden acceder a este vCenter en Cloud:
Y pasados apenas unos minutos tendremos ya todo preparado, podremos hacer click en lanzar el
vSphere Client:
Y ya podremos ver un vSphere Client HTML5, con los dos vCenter conectados, podemos ver el vCenter
de cloud y el nuestro local, no solamente esto, podemos mover VMs entre ellos, templates, etc. Ya
tenemos nuestro Hybrid Linked Mode perfectamente configurado y funcionando:
A partir de aquí, ya podemos administrar ambos entornos como si fueran uno solo, desplegar VMs,
realizar replicas entre Datacenters, mover cargas de trabajo, etc.
Nota: Recordar que tenemos dos maneras de administrar nuestro SDDC en VMware Cloud on AWS,
una es la consola de gestión del propio SDDC, donde podemos editar configuraciones de Red,
autenticación y mucho más, al más alto nivel posible. Y otra es la gestión mediante vCenter, que
será donde podremos administrar por supuesto todos los recursos lógicos que tenemos a nuestra
disposición, vSAN, VMs, Hosts ESXi, Resource Pools, etc.
Patrocinadores
GOLD
SILVER
BRONZE
Capítulo 21
Consejos para equipos que
administran VMware
Ariel Sánchez Mora
Capítulo 21 - Consejos para equipos que administran VMware Ariel Sánchez Mora
1. Introducción
En los siguientes párrafos trato de generalizar mis consejos a casos que aplican a la mayoría de
nuestros lectores. Esto es producto únicamente de mi experiencia y discusiones de lo que hemos
visto en la comunidad. Se que habrá empresas muy pequeñas donde no habrá suficientes recursos
(humanos o económicos) para lograr implementar ciertas recomendaciones, y también habrá empresas
mucho más grandes donde los casos se sentirán muy sencillos. Me encantaría que compartan estas
ideas y discutan con sus compañeros de trabajo, y me envíen sus comentarios sobre cómo mejorar
este contenido.
Uso el término Tecnología de Información (TI) como el grupo de personas encargadas de manejar la
infraestructura informática de una empresa. No limito los roles dentro de este grupo; conceptualmente
incluye a toda persona involucrada con configuración, soporte, gestión, etc.
Ariel Sánchez Mora

@arielsanchezmor
2. Todo servicio en TI debe ser brindado por un equipo,

especialmente VMware
Parafraseando al padre de la gerencia moderna Peter Drucker: en el contexto de una empresa, los
gerentes son los responsables de manejar recursos con el fin de proveer servicios que la empresa
necesita. Si hay algo mal en el servicio, debes hablar con el gerente asignado para saber qué sucede.
Los gerentes, por definición, deben estar listos para brindar reportes y ejecutar acciones correctivas
con el fin de brindar un buen servicio.
Si has oído hablar de VMware antes, sabrás por qué lo traigo a coalición: las soluciones de VMware
son “gerentes” en software que administran recursos de TI para lograr efectuar los servicios de
infraestructura deseados. Por ejemplo, vSphere administra CPU, memoria, red y almacenamiento. En
efecto, VMware permite la gerencia de todo aspecto de la infraestructura: empezaron con virtualización
de sistemas operativos y hoy en día abarcan todo tipo de redes, soluciones multi-nube y dispositivos
móviles.
Las soluciones de VMware fueron pioneras en proveer un “poder gerencial” para toda la infraestructura
de TI, y siguen siendo las soluciones más completas., Esto es gracias a su dedicación a proveer
aplicaciones de infraestructura programáticas (soluciones de software) - colaborando con la capa física,
sin depender de ella para su configuración. Se puede decir que su mayor innovación fue permitir una
capa de observabilidad y control total de infraestructura, y gracias a ello ahora tenemos la capacidad
de ajustes en software - mucho más ágil y económico q cambiar los componentes de hardware.
Debido a que es tan importante, debemos invertir un poco de tiempo en formular una estrategia que
nos permita obtener el mayor provecho de las soluciones de VMware. Dichas soluciones constituyen
una importante inversión en costo directo y en recursos humanos de la empresa. Es oportuno y
recomendado empezar hablando de la estrategia de crear un equipo que estará a cargo de todos los
aspectos de esta plataforma.
Nota: Existen varias escuelas de pensamiento de cómo se debe manejar TI en general (ITIL, COBIT
por ejemplo) pero por el momento voy a simplificar y aplicar directamente a la administración del
portafolio de VMware. Empresas más grandes estarán acostumbradas a esto y a tener arquitectos
de TI empresariales; lo que quiero recalcar que la falta de estos puestos y procesos a nivel global
de la empresa no debe limitarnos, y podemos implementar buenas prácticas para el manejo de las
soluciones de VMware sin importar nuestro estado actual.
Mi observación personal es que muchas empresas no crean equipos para manejar el ciclo de vida de
las soluciones de VMware, simplemente porque no están acostumbradas a crear equipos similares
para otras plataformas. El concepto de “manejo de ciclo de vida” en TI, simplificado, es que todo
servicio que provee TI debe pasar por las fases de:
a. valoración de las necesidades y soluciones disponibles
b. diseño de la solución elegida
c. planeación del proyecto
d. implementación
e. validación
f. soporte
g. retiro de la solución.
Tristemente es muy común que la falta de recursos o de experiencia conlleva a que todos estos
procesos son efectuados por una o dos personas, muchas veces sin el tiempo debido y sin ser bien
documentados. No debemos aceptar que esta forma de proceder es la correcta, pues sólo creará
problemas más grandes y llevará a deuda técnica.
Definamos la deuda técnica como “cosas que sabemos que debemos resolver, pero no tenemos tiempo
o el conocimiento adecuado, y lo dejaremos así por ahora”. Una función importante de todo encargado
de TI debe ser reducir la deuda técnica. Para evitar hundirnos más en el hueco, hay que dejar de cavar.
Es común que varios miembros del equipo de servidores sepan qué es vSphere, la plataforma
líder en virtualización de sistemas operativos por la cual VMware es famosa, y hasta tengan cierta
destreza y familiaridad con la instalación y administración del producto. Elegir a un único encargado
de la plataforma VMware es tentador - una persona se haría responsable, con libertad para proceder
según mejor le parezca. Debido a que productos como vSphere son sencillos de instalar, conseguirá
resultados rápidamente y pensaremos que todo va bien. Pero esta es la estrategia equivocada, porque
VMware es mucho más que vSphere.
Con el paso del tiempo, las decisiones que generan problemas y deuda técnica se pueden trazar de
vuelta a un administrador que no tenía claridad en los conceptos de la plataforma y los efectos a largo
plazo. A su defensa, hay que resaltar que rara vez se le otorga tiempo suficiente para estudiar (al
menos llevar una clase y certificarse), o no tuvo con quien discutir ideas y dudas, e hizo lo mejor que
pudo. En muchísimos casos, este administrador ya no está en la compañía y el siguiente encargado
debe hacer doble trabajo: implementar nuevos proyectos evitando y resolviendo problemas de deuda
técnica de su antecesor.
Es importante dejar de pensar en un solo administrador que sabe todo de VMware, y pensar en un
equipo constituido por varias especialidades que estará incluido en todas las etapas del manejo de
VMware.
Los principales beneficios de contar con un equipo:
a. Mejora la calidad durante todas las etapas de ciclo de vida del servicio.
b. Soporta la ausencia de miembros para que puedan ir a clases, estudiar y lograr certificaciones,
tomen vacaciones y asistan a conferencias.
c. Al dividir la carga, permite pensar y discutir estratégicamente desde varios puntos de vista.
d. Mejora la comunicación interpersonal y conlleva a más rigor en la documentación de los proyectos.
e. Se logra sucesión sin perder información o ímpetu cuando un miembro debe dejar el equipo.
Viendo estas ventajas, es claro que la moral y la satisfacción laboral serán mucho más altas cuando
los ingenieros son parte de un equipo, y además lograrán mejor trabajo. Es una situación donde todos
ganan.
Es importante determinar las personas más indicadas para ser parte de ese equipo. Tradicionalmente
se ha visto que VMware cae bajo la responsabilidad del equipo de servidores. Como explique
anteriormente, yo considero que esto es problemático: VMware afecta a todas las funciones de
TI, incluidos los equipos de redes y los dispositivos de usuario. Si no se trabaja desde el nivel de
arquitectura y diseño con el resto de los equipos, habrá trabajo redundante y política interna que
retrasará la adopción de la tecnología.
Debido a que las soluciones de VMware tocan toda la infraestructura de una empresa, los equipos de
VMware deben tener integrantes que abarcan varios equipos de TI. La división más básica de equipos
de Tecnología de Información (TI) va algo parecido a esto:
a. Un equipo a cargo de redes.
b. Un equipo a cargo de servidores.
c. Un equipo a cargo de dispositivos de usuario (móviles o estaciones de trabajo).
El primer consejo que le doy a empresas que van a adoptar VMware es que abran sus mentes a lo que
viene en el futuro: el Centro de Datos Definido por Software (SDDC, por sus siglas en inglés, Software
Defined Data Center). Es mejor empezar el camino de VMware asignando ingenieros de cada uno de
los diferentes equipos, escogiendo personas con experiencia interna, que entienden bien el negocio
y los procesos de la compañía. Esto inmediatamente permite identificar oportunidades donde las
soluciones tendrán mayor impacto y da credibilidad a los proyectos que se van a formar.
Además, debido a que en VMware existen varias soluciones y cada solución puede tomar considerable
tiempo en dominar, recomiendo identificar también a ingenieros con mucha sed de aprender, dedicados
a trabajar bien en equipo y con iniciativa propia. Cuando se combinan experiencia, influencia,
conocimiento de la empresa con sed de aprender, mente abierta y buena comunicación, se crean
equipos muy efectivos y hay buena química en TI. Hablaré un poco más de actitudes que llevan al éxito
en VMware en este capítulo.
Quiero aclarar que el “Equipo VMware” es responsable por la plataforma total, pero es claro que cada
implementación de servicio será un proyecto. En cada proyecto es donde se pueden asignar líderes
a cargo del proyecto, pero aquí me gustaría incluir otro concepto. Es importante que los líderes o
pilotos tengan un co-piloto que esté completamente incluido en todas las decisiones y trabajo. El
concepto es muy similar a programación en pareja (pair programming). Es aquí donde unir a uno o
varios ingenieros experimentados y establecidos con un ingeniero con sed de aprender conlleva a sus
máximos beneficios. Mejor aún, combinar personas de diferentes equipos, por ejemplo:
a. Proyecto vSphere: ingeniero de sistemas experimentado con ingeniero de dispositivo de usuario

con sed de aprender.
b. Proyecto NSX: ingenieros de redes y servidores experimentados con ingenieros de redes y

servidores con sed de aprender.
c. Proyecto Airwatch: ingeniero de dispositivo de usuario experimentado con ingeniero de sistemas

con sed de aprender
Hemos hablado de los beneficios de establecer un equipo de VMware, qué tipo de integrantes deben
conformarlo, y cómo manejar el liderazgo de los proyectos individuales. Al establecer un equipo
empresarial para todas las soluciones VMware se podrán tomar decisiones de arquitectura eficientes,
se simplifica el planeamiento futuro y se desarrolla a nuevos miembros. He visto ambos casos en
la vida real - cuando hay un equipo multidisciplinario y cuando es solo un encargado - y el modelo
multidisciplinario es mucho más eficiente, ágil y trae los mejores resultados. El ambiente laboral se
vuelve una de las razones por las cuales los empleados permanecen en la compañía.
Crear este modelo completo requiere importante liderazgo en las posiciones gerenciales y ejecutivas
de TI y una empresa que tenga el objetivo de liderar en sus soluciones tecnológicas. Pero le quiero
decir al lector de este libro que su cargo en la empresa y situación particulares no son una limitación.
Para implementar estas estrategias en su ambiente, lidere la iniciativa y explíquela a sus compañeros.
No es siempre líder el que tiene el título, sino el que lleva a todos a una mejor situación. Explique
a sus jefes, a sus colegas y lleve un cuaderno con ideas de cómo mejorar las cosas. Cuando haya
una situación desfavorable, tome la oportunidad de explicar las ventajas de haberlo hecho desde la
perspectiva de un equipo global, identificando el problema y trayendo la solución.
Por su impacto y beneficios, los proyectos con soluciones de VMware tienden a mostrar valor rápido
y crecer vertiginosamente. Por ello es importante haber establecido un equipo que pueda escalar
a nuevas demandas y adaptarse rápidamente sin perder calidad. Un equipo interdisciplinario que
combina experiencia y sed de aprendizaje es la mejor forma de adoptar VMware. Aún si los equipos no
deciden implementar todas las soluciones de VMware en un ciclo de tecnología, entender los conceptos
e involucrar a miembros de varias áreas es crucial para llegar a tener agilidad y transformación digital
en las empresas a mediano y largo plazo.
3. Actitudes y estrategias que llevan al éxito en VMware
Ya hablamos de cómo empezar bien en la adopción de las soluciones de VMware, formando un equipo
multidisciplinario con integrantes experimentados y sedientos de aprender. Ya que empezamos bien,
sigamos bien adoptando buenas costumbres que aplican a casi todo ambiente.
Empecemos con el detalle de cómo crear expertos internos en nuestro equipo de VMware. Hablaré
en el marco de una empresa que está adoptando soluciones de VMware a pesar de que muchísimas
empresas ya tienen vSphere instalado, pues esto aplica cuando uno adopta nuevas soluciones, como
NSX.
En general, las soluciones de VMware son fáciles de aprender pero difíciles de dominar. Aún los cursos
de Instalar Configurar y Administrar (más conocidos por sus siglas en inglés, ICM) no son suficiente
para ser un buen ingeniero - cubren el material a nivel teórico pero no entran en diseño, por ejemplo.
Personalmente me gustaría que todos los administradores tuvieran el VMware Certified Professional
(VCP) de las soluciones que van a implementar, pues es un examen relativamente difícil que obliga
al estudiante a leer la documentación del producto. Ya con algo de experiencia, los exámenes de
VMware Certified Advanced Professional (VCAP) son buenos desafíos, midiendo conocimiento de vida
real y diseño.
Quiero recalcar esta preparación porque los ingenieros en la compañía pueden tomar los cursos y
exámenes cuando todavía no se ha comprado el producto y empezado el proyecto. Llevar los cursos y
exámenes previo a la compra va a ser una mejor estrategia para su empresa. Comúnmente el proceso
de compra incluye hablar con representantes de VMware que ayudan a crear la solución y tener esta
preparación permite hacer mejores preguntas durante el ciclo de ventas, lo que conlleva a sesiones y
compras más satisfactorias para todos. Cuando planeamos con anticipación, siempre vamos a lograr
un mejor resultado.
Sin embargo, sé que llevar clases y pasar exámenes antes de implementar el producto no es lo común.
Las clases y exámenes requieren inversión monetaria y de tiempo, y tiende a ser que los proyectos
de VMware requieren empezar inmediatamente, con poca planificación previa de las destrezas de los
ingenieros. Entonces recordemos, aunque el producto es fácil de instalar y poner a correr, debemos
saldar la deuda de conocimiento en algún momento, para sacar el mayor provecho.
Hablando de la situación común - ya implementado, no hubo tiempo para que todos llevaran una
clase y menos un examen - mi recomendación es la siguiente. Lee toda la documentación. Si logras
realmente absorber la documentación entera, sabrás más que una persona que llevó el ICM y que
tiene el VCP. En efecto, aún los exámenes VCAP te refieren a la documentación para el estudio.
Me siento cómodo haciendo esta recomendación porque toda la documentación es gratis, disponible
al público y se encuentra en https://www.vmware.com/support/pubs/. Puedes hacer una búsqueda
de “VMware documentation” en Google y será el primer link. He comprobado que puedes cambiar el
idioma y leer la documentación en español, aunque no me extrañaría que primero salga en inglés, y
sea más completa en inglés.
Hablemos de un tema que tristemente no podemos evitar: no hay mucha información en español.
A pesar de que hay traducciones, no son siempre confiables. Debido a esto, una de las mayores
inversiones como profesional de TI es tener un conocimiento de inglés avanzado para encontrar y
asimilar información cuando no se encuentra en español. Con este libro tratamos de cambiar eso,
pero ocuparemos muchos más voluntarios, durante mucho tiempo, para llegar a esa meta donde una
persona no ocupa saber inglés.
La parte de “realmente absorber” al leer la documentación oficial es lo difícil, porque hay varios
conceptos que serán difíciles al principio. No te desanimes, escribe la pregunta en tu cuaderno y

sigue. No serás el único que se ha preguntado algo - la mayoría de las preguntas que te harás están
explicadas en Internet si las buscas en Google. Si no es a través de una respuesta oficial de VMware,
será quizás en un blog o foro. VMware tiene una comunidad grande de usuarios que se dedican a
ayudar a otros; hablaremos de la vCommunity en la siguiente sección.
Quiero recalcar dos tipos de documentación, adicionales a los documentos oficiales, que son sumamente
importantes para todo ingeniero de plataformas VMware. Hablo de leer las notas de lanzamiento
(Release Notes) que vienen con cada nueva versión del producto, y las Bases de Conocimiento
(Knowledge Base, o KBs). Ambos son críticos para poder efectuar adecuadamente las instalaciones
y actualizaciones de producto.
En particular, hay dos KBs que referencio con frecuencia. La primera es la lista de versiones de
productos, 1014508, debido a que contiene todos los productos de VMware, con numero de build
y fecha de publicación. La segunda es el orden de actualización cuando hay varias soluciones de
VMware instaladas y dependientes una de la otra. Se usa la versión de vSphere como base, por
ejemplo para vSphere 6.7 el número de KB es 53710. Puedes poner en Google “KB 53710” y te lo
desplegará como primer resultado.
Aparte de la documentación gratuita, hay varios libros que tienen información valiosa y que no es
fácil de conseguir de otra forma. En particular, los libros donde Scott Lowe, Duncan Epping y Frank
Denneman han sido co-autores o autores principales son buenísimos y a veces hasta se consiguen
las versión eBook gratis. En particular, me gustan mucho los de la serie “Deep Dive”. También, si vas
a implementar Horizon, recomiendo el libro de Johan Van Amersfoort. Los libros se pueden leer más
rápido que la documentación, pero no la sustituyen.
Ahora hablaré de dos recursos web que VMware provee y que son importantísimos para los ingenieros:
la Lista de Hardware Compatible (más conocido por sus siglas en inglés: HCL, Hardware Compatibility
List) y la Matriz de Interoperabilidad de productos VMware (referido como el Interoperability Matrix).
Empezando con el HCL: si uno compra servidores modernos típicamente no hay mucho de qué
preocuparse, pues todos los vendedores certifican sus plataformas, con sus varias opciones de
procesador, tarjetas de red y sistemas de almacenamiento. Pero si por motivos económicos debes
usar servidores vas viejos o construir tus propios servidores, debes de estar consciente si lo que
quieres combinar está en la lista, pues VMware provee soporte de producción sólo si la versión del
software y el hardware están en la lista.
VMware provee drivers para muchísimos dispositivos en su imagen base. Estos drivers son soportados
por VMware como parte de su validación y se llaman inbox drivers. Sin embargo los partners de VMware
pueden añadir más drivers a medida que se descubren bugs y nuevas funcionalidades, muchas veces
también requiriendo una actualización de firmware. Cuando un partner hace esto, los drivers se llaman
de tipo async.
Revisemos un caso de vSphere. Cuando cambian versiones de producto, por ejemplo de 5.5 a 6.0,
VMware puede elegir cambiar completamente el driver o versiones soportadas, por lo que es importante
revisar las consecuencias de HCL al efectuar actualizaciones de versiones mayores. Asimismo, cada
vendedor de servidor debe re-certificar sus plataformas. Muchos fabricantes no certifican hardware que
ya tiene 3 generaciones más nuevas; en esos casos, debes permanecer en las versiones soportadas
hasta que puedas cambiar el hardware. Esto no es un problema grande pues vCenter permite manejar
hasta 3 versiones anteriores de ESXi. Un caso común que veo hoy son servidores HP de generacion
7 o Dell de 11va generación que deben permanecer en vSphere 6.0 y el último vCenter que los podrá
soportar es 6.7.
La gran mayoría de los casos donde hay una falla en el hipervisor, también conocido como Purple
Screen of Death (PSOD) es debido a un driver o firmware que no estaba en el HCL. También puede
ser que a una combinación que estaba listada en el HCL se le descubren problemas y se le pide a los
clientes que pasen a usar otra versión de driver o firmware. Por ello al instalar soluciones de VMware
debemos estar muy conscientes de que lo que hemos instalado esté completamente soportado, y
debemos marcarlo así en nuestra documentación. Si se usan Inbox drivers, VMware deberá proveer la
solución. Si son drivers async, es el fabricante de hardware quien proveerá la solución.
Este tema llega a ser aún más importante cuando hablamos de soluciones de VMware que dependen
de vSphere; por ejemplo NSX-V Datacenter depende de las tarjetas de red configuradas a través de
ESXi. Mostrar que has adherido a las recomendaciones del HCL es la certificación de que has hecho
tu trabajo responsablemente.
Recalco que no es sólo cuando construimos el ambiente que tenemos que estar pendientes del HCL.
Al efectuar todos los pasos de una actualización se pueden cambiar las versiones de drivers. Es
importante mantener actualizada la documentación a medida que cambian los ambientes.
El otro recurso en línea que mencioné es la Matriz de Interoperabilidad. Este recurso nos permite
determinar qué versiones de software de VMware están certificadas para funcionar entre sí. Cuando
hablamos de implementar varias soluciones de VMware, es importante ver que versiones debemos
instalar - casi siempre con respecto a vSphere. Lo más común es que se soporten versiones que han
salido en periodos de tiempo parecidos.
Hablemos un poco más sobre el tema de actualizaciones. Si leemos y seguimos la documentación,

revisamos los KBs y notas de lanzamiento y sabemos cuáles versiones de softwares son compatibles,
tendremos una alta posibilidad de éxito. Lo que quiero mencionar ahora es terminar todos los pasos
de una actualización.
Tristemente es común ver ambientes donde los principales componentes fueron actualizados, pero no
se completó 100% el trabajo. Por ejemplo, el vCenter y ESXi fueron actualizados, pero las máquinas
virtuales siguen con VMware tools o VMware hardware de versiones anteriores. Esto típicamente
muestra que los administradores no están haciendo parches en sus sistemas operativos pues nadie
quiere apagar las máquinas virtuales para hacer estos mantenimientos. Debemos tratar la administración
de infraestructura de TI con respeto y dedicación y asegurarnos de aplicar los parches de seguridad y
los mantenimientos necesarios.
En el tema de seguridad es mi experiencia que las cosas necesarias para mantener un ambiente
funcionando con responsabilidad son en general sencillas, pero requieren ser aplicadas
consistentemente. Cuando configuramos un ambiente siempre debemos asegurarnos como mínimo,
que:
a. el reloj sea correcto en todos los sistemas (configuración del Network Time Protocol, NTP por sus
siglas en inglés)
b. los logs sean enviados a un servidor de syslog (si la empresa no tiene un servidor central, instalar
VMware LogInsight)
c. los permisos de administrador sean dados a usuarios individuales, no a cuentas genéricas.
Es cierto que habrá cuentas de servicio para backups y la cuenta default no se puede cambiar o
desactivar pero si se puede controlar su acceso. Con respecto a las contraseñas de root y Administrator
me gusta ver que los equipos tengan un sistema de manejo de contraseñas. Considero q lo mínimo
que toda empresa debe tener es una base de datos de KeePass o Password Safe en un share con los
permisos de acceso necesarios para que solo el equipo VMware acceda a la información necesaria,
y que se respete una política de expiración de contraseñas. Es aún mejor cuando se cuenta con
soluciones empresariales.
Si administramos estas tres cosas bien y mantenemos la aplicación de parches de seguridad no queda
muchísimo más trabajo para asegurar la plataforma. La documentación explica que la plataforma de
infraestructura debe estar en redes internas, protegida por firewalls. Hay documentos que VMware
provee explicando todas las configuraciones de seguridad llamados Security Hardening Guides. Con
la información de estos documentos se pueden crear políticas de seguridad para la empresa, pero
las tres configuraciones que mencioné son condiciones básicas que deben de estar en todos los
ambientes.
Hablemos por un momento sobre la documentación. Muchas personas están acostumbradas a nada
más conectarse a vCenter y piensan que con revisar algunas secciones es suficiente para entender
el ambiente. Esto es una ilusión: si repasamos cuáles son todas las opciones configurables de un
producto, por ejemplo vSphere ESXi, vemos que hay muchísimas opciones y no todas son visibles
desde las interfaces gráficas.
Crear documentación manualmente toma mucho tiempo. Hay varias herramientas gratuitas para
crear documentación. Yo estoy involucrado con una de ellas junto con mi amigo Edgar Sanchez (@
edmsanchez13). Cuando creamos vDocumentation fue porque vimos la necesidad de tener información
del ambiente en excel para un tiempo específico. Otras herramientas que se pueden usar son RVTools,
vCheck, el “As Built Report” y vDiagram - simplemente búscalas en Google, sabiendo que no son
herramientas oficiales sino de la comunidad.
Al usar estas herramientas gratuitas debemos estar conscientes de que estas fueron creadas por
personas que pensaban en cierta situación y esta situación puede no ser la misma que la nuestra.
Si vemos que falta información que ocupamos, todas estas herramientas son de código abierto y se
puede trabajar con los autores para incluir nuevas funcionalidades, e incluso aportar el código que falta
para hacer el proceso más rápido.
Finalmente, si heredas un ambiente, es importante buscar (o empezar a crear) documentación histórica

de los criterios de diseño del ambiente antes de implementarlo. Es más fácil que tratar de descifrar el
ambiente después de haber sido implementado, y por ello debe ser parte de cualquier implementación
que nosotros efectuemos.
Más allá de la documentación quiero hablar un poco sobre cómo se puede manejar el portal de licencias
de VMware. Cuando uno compra la solución de VMware se le da acceso a un portal en línea donde
están las licencias. Hay que entender que siempre se empieza con dos usuarios importantes en ese
portal: el procurement contact y el superuser. Siempre deben haber cuentas con este rol, y no puede
haber más de una con ese rol.
He visto empresas donde para simplificar el manejo de licencias se usa un solo usuario ligado a
un correo que básicamente envía cualquier cambio que se haga a todo el equipo de VMware de la
empresa (por ejemplo, equipovmware@miempresa.com). Este método ayuda a que todos quienes
tienen acceso a la cuenta puedan ver las mismas licencias, todos puedan hacer actualizaciones de
las notas en las licencias y permite que los equipos distribuidos puedan trabajar más efectivamente. El
principal problema con esta solución es cuando un miembro se va, pues debe cambiarse la contraseña,
lo cual no es tan difícil si hay buen manejo del resto de las contraseñas.
Si en vez se deciden hacer varios logins al portal de VMware se debe definir con el equipo por qué
o cuáles son los permisos que se van a usar. Es importante entender que el procurement contact
es crucial para renovar los contratos de mantenimiento y manejar la relación con VMware y por ello
debe ser alguien con autoridad en la empresa para tener esas discusiones. El superuser es el usuario
con acceso a cambiar los permisos en todas las licencias, que se asignan por folder. Es importante
considerar que a pesar de que un usuario no deba tal vez hacer actualización de licencias, puede
requerir ver la licencia para poder abrir un ticket de soporte en ese producto. Por ello las personas
asignadas al procurement contact y el superuser deben ser conocidos por todos y deben estar
familiarizados con el portal para ayudar al resto del equipo según se necesite.
Dos cosas que me gusta ver en los portales de VMware son notas en las licencias y orden en las
carpetas. Por ejemplo, la mayoría de servidores hoy en día son de 2 o 4 CPU’s. Al dividir las licencias
de VMware para que cada servidor tenga una licencia individual, es fácil mantener el control del uso
de la licencia y si se debe renovar o no. Es mucho más complicado mostrar orden con una licencia
grande que se ha aplicado en varios lugares. Asimismo, crear folders por proyecto, región o estatus de
mantenimiento es más sencillo de entender que la práctica de VMware de crear un folder por cada orden
de compra. El consejo más importante - adoptar estándares internos y seguirlos consistentemente.
Tradicionalmente VMware mantiene tres versiones separadas del software en soporte:
a. La versión más reciente es donde se sacan las nuevas funcionalidades primero, así como las
actualizaciones de seguridad.
b. La versión del medio recibe algunas nuevas funcionalidades y todas las actualizaciones de
seguridad, con un ligero retraso.
c. La versión más vieja sólo recibe las actualizaciones de seguridad.
Cuando se trata de soluciones nuevas con bastante desarrollo de funcionalidades (un buen ejemplo
es NSX o vSAN), es importante estar corriendo la versión más nueva. vSAN, al ser almacenamiento,
es de suma importancia pues queremos que cualquier problema sea arreglado lo más pronto posible.
En mi experiencia las compañías que están corriendo versiones viejas y fuera de soporte lo hacen
simplemente porque no han tenido el tiempo para planificar bien una actualización. Muchas veces
no tienen el conocimiento para crear un plan concreto y tienen miedo de causar downtime (tiempo
inoperativo, lo que nadie quiere). No debemos dejar que las versiones que corramos sean las que
están más lejos de la versión más nueva y correr el riesgo de no estar en una versión soportada.
VMware internamente se enfoca en estabilidad - la versión más estable de VMware es la más nueva!
En la siguiente sección hablaré de estrategias que permiten hacer cambios sin causar downtime.
4. La importancia de ambientes de prueba, homelabs y

Hands On Labs
Una situación que encuentro comúnmente es que muchos ambientes de producción no tienen a su lado
un ambiente de prueba. Cuando hablo de ambiente de prueba me refiero a un ambiente representativo
de lo que se está corriendo en producción, cuya función es servir para practicar cambios antes de
hacerlos en producción.
El esfuerzo para levantar un ambiente de prueba no es particularmente alto pero conlleva importantes
beneficios cuando se usa para practicar futuros cambios en producción:
a. Familiarizarse con los pasos y poder investigar detalles sin estar causando downtime.
b. Tener más tiempo para planificar qué es lo que se ocupa hacer y en qué orden.
c. Comprobar que las integraciones entre varias soluciones o con otro software funcionan después
de una actualización.
d. Entrenar a nuevos miembros y elaborar documentación.
Los ambientes de prueba pueden ser ubicados en servidores más viejos pues el desempeño es de baja
prioridad - lo que estamos probando principalmente es el software. Sin embargo, si las condiciones
lo permiten, es ideal mantenerlo igual al ambiente de producción para no ser sorprendidos por una
dependencia del hardware.
Hay otros dos casos que quiero hablar, los homelabs (laboratorios de casa) y los Hands On Labs.
Es mi opinión personal que no debemos depender sólo de los ambientes de trabajo para aprender
sobre nuevas plataformas sino que también debemos disponer de ambientes que podamos destruir
y reconfigurar según nuestras necesidades personales y donde podamos además experimentar con
nuevas tecnologías. No es válida la excusa que debido a que la empresa no tiene una plataforma de
prueba nosotros no podemos aprender en casa.
Una tecnología que será importante para muchos administradores de VMware es aprender sobre
Kubernetes. Si no se usa todavía en la empresa es probable que se usará en los próximos cinco años.
Un homelab es el lugar ideal para aprender sobre Kubernetes pues no tenemos riesgo alguno de
ocasionar problemas en producción y nos permite mucha flexibilidad en el aprendizaje. También en un
homelab puede trabajar con equipos mucho más baratos que los equipos que se usan en el trabajo -
plataformas populares son Intel NUC, servidores construidos con componentes de PC, o los servidores
de pequeño formato como Supermicro. Si se puede añadir un dispositivo de almacenamiento de red
(NAS) es aún mejor (los Synology son muy populares) y también un switch con ciertas capacidades
empresariales.
Entiendo también que no es fácil construir por primera vez un homelab - se puede gastar bastante
tiempo y dinero en diseñarlo y construirlo. Muchos empezamos con una computadora poderosa
principalmente en memoria RAM, a la q le dedicamos un disco duro y hacemos un dual boot a ESXi,
usando nested hosts. En internet encontrarás mucha información y guías para hacer esto.
Si no quieres gastar dinero y sacrificas un poco de flexibilidad, es más práctico ir a los Hands on Labs
que regala VMware en línea y hacer tus pruebas ahí. Si no has efectuado un laboratorio anteriormente,
debe saber que los ambientes son reales y puedes elegir no seguir el laboratorio, sino simplemente
usar el ambiente para hacer tus pruebas. La única desventaja es que sus ambientes están limitados
en tiempo por lo cual cualquier cosa que construyas se perderá después de algunas horas - pero el
conocimiento queda.
No hay excusa para hacer cambios en producción sin haber ejercido la oportunidad de practicar
los cambios antes de hacerlos. El pecado más grande de un administrador de VMware es causar
downtime. Piénsalo así: si introducir VMware como la capa que maneja la infraestructura diera peores
resultados que manejar los programas directamente sobre el hardware, nadie lo usaría y no estarías
leyendo este libro.
Como administradores de la plataforma de VMware debemos procurar que si hay downtime no sea por
la plataforma de VMware, y no sea causado por nuestras acciones o falta de preparación. Debemos
siempre prepararnos para los peores escenarios y tener soluciones a los posibles problemas que
puedan surgir.
5. Involucrarse en la vCommunity es indispensable
Gracias a programas como vExpert, que se dedica a fomentar la discusión y ayuda entre usuarios, y
al VMware User Group (VMUG), se ha formado un ambiente muy acogedor a principiantes y nuevos
integrantes. Yo le debo muchísimo de mi crecimiento profesional a estos programas y quiero asegurarme
que los lectores de este libro sepan que existen y que también le saquen provecho.
Existe el concepto de vCommunity: la comunidad mundial de administradores y empleados de VMware

que están ahí para ayudarse entre sí. Típicamente lo veras con # porque se usa principalmente en
Twitter cuando alguien hace un post donde se pide o se aprecia ayuda. El termino vCommunity sirve
para incluir todas las diferentes expresiones de esa ayuda.
En mi opinión, las principales vías donde se manifiesta la vCommunity son:
a. Los foros de VMware, principalmente VMTN (communities.vmware.com).
b. Las reuniones locales y virtuales del VMware User Group.
c. Las contribuciones individuales en blogs, podcasts y grabaciones de YouTube.
d. Twitter, tal vez la más importante.
Cada uno de los autores de este libro te dio al menos su Twitter handle. Síguelo y a medida que lees
el libro, si tienes ideas, mándale un mensaje por ahí a los autores - verás que están muy dispuestos a
oír tu opinión y discutir contigo cómo mejorar el contenido. Cuando ayudas al resto a mejorar estarás
participando tú también en el vCommunity.
Todos tenemos un trabajo que hacer pero cuándo somos parte de una comunidad mundial donde se
incentiva ayudar a otros, el trabajo se hace más liviano. Descubrirás que hay muchas más personas
que saben de VMware y hablan espanol de lo que pensabas. Además, las relaciones que se hacen en
línea, a nivel mundial, se vuelven reales cuando asistes a eventos como VMworld y VMUGs en varias
ciudades.
Debo también recomendar que te suscribas a ciertos podcasts que son buenos para mantenerse al
tanto con VMware y tecnología en general. La mayoría están en inglés y por ello permiten practicar el
idioma:
a. El VMTN community podcast es la herramienta oficial del grupo de comunidad de VMware.
b. Virtually Speaking es creado por empleados de VMware y está enfocado principalmente en storage
(vSAN, VVOLs, etc).
c. Gigacast es un podcast producido por la comunidad y más relajado, donde se invita a miembros
del vCommunity para que den sus opiniones y permite conocernos mejor.
d. vBrownBag
En particular (porque soy miembro en dos idiomas y 3 continentes) quiero resaltar a vBrownbag. No lo
veo como un podcast tradicional, sino más bien es una herramienta de aprendizaje creada por y para
la comunidad. Cada semana se invita a un especialista y se le pide que exponga sobre un tema. Esto
se graba en vídeo y se publica tanto en YouTube como en iTunes.
Es común encontrar en vBrownBag guías de estudio para certificaciones, exposiciones de nuevas

tecnologías y grabaciones en vivo de conferencias de TI. Yo siempre ando buscando personas para
exponer en los canales de Europa o Latinoamérica. Si algún día quieres presentar un tema nada más
déjame saber.
Es mi deseo que todo el que lea este libro se involucre en la #vCommunity. Crea un usuario de Twitter,
ponle foto y algunos detalles para conocerte, y síguenos, y mantente en contacto. Este libro se creó
gracias a las relaciones que muchos logramos hacer por internet, y queremos que tu escribas el
siguiente capítulo.

VMware Por VExperts

Transféré par

Informations du document

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

VMware Por VExperts

Transféré par

Droits d'auteur :

#VMwarePorvExperts www.vmwareporvexperts.

14 Bloggers unidos por un Proyecto solidario.

© 2019 - Autores libro

No se permite distribuir ni parcialmente, ni totalmente, la publicación a través de cualquier medio,

• Diseño, implementación y administración de grandes entornos VMware vSphere

Entre mis labores habituales, se encuentran la administración y mantenimiento de

También me dedico a la instalación y gestión de servidores de correo electrónico basados en Microsoft

En la actualidad, una gran parte de mi tiempo laboral lo consume la configuración y administración de

Soporte técnico de Hardware de servidores y dispositivos de almacenamiento de grandes marcas

Me pueden encontrar en mi blog y en redes sociales:

Participo en proyectos de diseño, sizing, implementaciones y health checks para soluciones de

Cuento actualmente con las certificaciones VCIX6-DCA, VCAP5-DCA, VCAP5-DCD, VCP6-CMA,

Mis competencias profesionales se basan alrededor de la virtualización de centro de datos, esto es

WS2012LABS - Windows Server 2012

• Blogger en https://www.SYSADMIT.com: (Año 2013 hasta la actualidad)

Grupo SYSADMIT en Linkedin:

Un apasionado de las tecnologías, últimamente con más profundidad en el mundo de la monitorización

¡Compartir y ser felices!

Todos estos años en un continuo autoaprendizaje he sacado las siguientes certificaciones:

Y donde gracias a escribir en un blog he recibido los siguientes galardones:

• VMware vExpert, por cuatro años seguidos

Me podéis seguir en mi blog https://aprendiendoavirtualizar.com

Desempeño la función de ingeniero/consultor de sistemas en una gran empresa, Sothis.

Autor de los cursos en Udemy: Nutanix y VMware vSAN

Algunas de mis certificaciones y acreditaciones:

Más información sobre mi trayectoria en: http://www.leandroleonhardt.com y en el blog: https://www.

En lo profesional, cuento con mas de 10 años de experiencia en el ámbito de sistemas y en los

• Diseño, implementación y administración de grandes entornos VMware vSphere

Soy miembro de @vBrownBag así como host de @vBrownBagLATAM. He presentado en VMworld

Mi twitter es @arielsanchezmor y ahí me encanta interactuar con otros miembros de la comunidad. Te

Finalmente, agradezco a Dios por esta vida tan linda.

Todo lo que hago es para mi esposa Amy. Te amo.

A nivel profesional me he especializado en virtualización, pero lo que realmente me atrae es poder

Aunque he trabajado muchos años con VMware, en la actualidad también me he especializado en

• Reivindicar y aportar ejemplos de la importantísima contribución de las mujeres a la sociedad.

Ama es un proyecto homenaje a la mujer, para su empoderamiento y donde se busca la igualdad

Si quieren colaborar pueden hacerlo:

Colonya - Caixa de Pollensa

Capítulo 1 - Introducción (Xavier Genestós).......................................................................................25

Capítulo 2 - vCenter, ESXi’s y VMs (Gorka Izquierdo)........................................................................44

Capítulo 3 - Instalación, Configuración y Actualización (Xavier Caballé)..........................................149

Capítulo 4 - Redes en vSphere (Miguel Ángel Alonso).....................................................................222

Capítulo 5 - NSX (Miguel Ángel Alonso)...........................................................................................251

Capítulo 6 - Almacenamiento en vSphere (Leandro Ariel Leonhardt)...............................................282

Capítulo 7 - vSAN (Federico Cinalli).................................................................................................302

Capítulo 8 - Alta Disponibilidad (Leandro Ariel Leonhardt)................................................................360

Capítulo 9 - Backup y Réplicas (Patricio Cerda)...............................................................................399

Capítulo 10 - Monitorización de vSphere (Jorge de la Cruz)............................................................489

Capítulo 11 - Monitorización con Centreon (Héctor Herrero)............................................................544

Capítulo 12 - VDI con Horizon View (Ricard Ibáñez)........................................................................612

Capítulo 13 - Citrix en vSphere (Héctor Herrero)..............................................................................721

Capítulo 14 - vRealize Orchestrator (Federico Cinalli)......................................................................770

Capítulo 15 - PowerCLI (Miquel Mariano).........................................................................................807

Capítulo 16 - vRealize Automation (Federico Cinalli)........................................................................844

Capítulo 17 - Automatizando vSphere con Ansible (Miquel Mariano)...............................................894

Capítulo 18 - vSphere y Containers (Raúl Unzué)............................................................................932

Capítulo 19 - VMware Code - API (Daniel Romero)..........................................................................987

Capítulo 20 - VMware Cloud on AWS (Jorge de la Cruz)................................................................1009

1.1 ¿Qué es la virtualización?

Las máquinas vituales (guests) verán lo que configuremos en el hipervisor (host).

1.2 Tipos de hipervisor

Fuente de la foto: https://es.wikipedia.org/wiki/Hipervisor

Vemos las diferencias entre ambos tipos de hipervisor:

• Se instala directamente en el hardware físico.

• ­El rendimiento es superior a los hipervisores de tipo 2.

• Es el tipo de hipervisor adecuado para un entorno de producción.

• Ejemplos: VMware ESXi, Citrix XenServer, Microsoft Hyper-V.

• El rendimiento es superior a los hipervisores de tipo 2.