Orense, 20

28020 Madrid
D`Aribau, 200
08036 Barcelona
www.formadoresfreelance.es

Tema 1: BUENAS PRCTICAS CON VMWARE VSPHERE

Parte 1 - Introduccin a Vmware Sphere
Parte 2 - Gestin de Maquinas Virtuales
Parte 3 - Redes
Parte 4 - Almacenamiento
Parte 5 - Gestin de recursos

Formadores IT, Todos los derechos reservados. Prohibida su reproduccin total o parcial.

VMware vSphere en un componente esencial dentro de la solucin de virtualitzacin para Datacenters de Vmware.
La funcin bsica de un entorno de virtualizacin es la de particionar una mquina fsica en varias mquinas virtuales con
las mismas funcionalidades que la fsica pero con menos recursos asignados. Conforme la capacidad de proceso de los
equipos va creciendo y las necesidades de las compaas se mantienen constantes, tenemos ms oportunidad de sacar
provecho econmico a un entorno de virtualizacin
Por ejemplo es bastante ms econmico adquirir una mquina con 16GB de memoria que 16 mquinas de 1GB y en el caso
de procesadores, es comn tener los procesadores a un uso medio del 5% o 10%, con lo que tenemos oportunidad de sacar
ms provecho a la inversin realizada si podemos compartir este procesador entre varias mquinas virtuales y conseguir
utilizaciones del 70% o 80%
En cualquier entorno de consolidacin se tiene que tener la vista puesta sobre los contadores que indican el uso para evitar
una sobreasignacin de recursos y afectar a la calidad de servicio de las mquinas virtuales, ya que ningn recurso podr
llegar a ms del 100% de utilizacin

Orgenes
Dentro del mundo basado en Intel x86, los comnmente llamados PC, la virtualizacin es un fenmeno relativamente
moderno, se populariz con la llegada al mercado en 1999 de Vmware Workstation, muy orientado a desarrolladores y
administradores de sistemas. As podan tener en el mismo equipo varios entornos, por ejemplo el entorno corporativo de
trabajo y un entorno virtual para las pruebas emulando los entornos donde el software desarrollado se iba a desplegar, y en
el caso de administradores de sistemas en entornos con mucho peso en Unix/Linux, utilizar por defecto el entorno Linux y
levantar la mquina virtual con Windows cuando requeran hacer algo con las herramientas corporativas.
Casi al momento, se empez a utilizar para hacer demostraciones de productos o simular entornos complejos con varios
equipos en un solo equipo, algo parecido a lo que haremos en la prctica.
Al cabo de poco tiempo, sacaron al mercado Vmware GSX, que ya era un entorno para tener mquinas virtuales en un
servidor, este servidor poda ser Windows o Linux y en el fondo GSX era el producto anterior con herramientas para
gestionar el arranque y parada de mquinas virtuales de forma desatendida. Tambin en el mismo entorno de tiempo,
lanzaron Vmware ESX, que no requera de un sistema operativo con lo que dedicbamos toda la potencia de la mquina a
las tareas de virtualizacin.
Sobre el ao 2003 se empieza a hablar de entornos paravirtualizados, con Xen a la cabeza. La diferencia entre el entorno
virtualizado y paravirtualizado, es que un entorno virtualizado emula a la perfeccin una mquina fsica y por tanto
cualquier software que pueda ser ejecutado en ese hardware debera poder ejecutarse en la mquina virtual. En el caso de la
paravirtualizacin, lo que hacemos es iluminar el sistema operativo alojado de forma que sus controladores de dispositivos
y la forma de acceder al hardware tienen en cuenta que es un entorno diferente.
Los primeros entornos paravirtualizados daban mejor rendimiento que los virtualizados ya que estos ltimos deban de
interceptar llamadas directas al hardware y emular el comportamiento del dispositivo en cuestin. Con la salida al mercado
de procesadores con soporte a la virtualizacin y la maduracin de los varios sistemas operativos que ya incluyen ciertas
iluminaciones por defecto, ya no existe una diferencia tan importante entre rendimiento y compatibilidad sino que en
lugar de tener un entorno de blanco y negro, estamos en un momento ms de grises. Vmware soporta paravirtualizacin en
algunos dispositivos y Xen virtualizacin con ayuda del hardware. Por tanto las diferencias se han difuminado mucho ms y
ahora se valoran otros aspectos como funcionalidades avanzadas de gestin de recursos, compatibilidad, escalabilidad, etc
Aunque es reciente para la mayora de nosotros, los fundamentos de la virtualizacin y del soporte por hardware de la
misma se remontan a los aos 1960 donde IBM ya dispona de procesadores que soportaban la virtualizacin y en el fondo
lo que se acababa ejecutando en esas mquinas era un hipervisor que monitorizaba la mquina virtual, de esta forma
particionaban el equipo y facilitaban las emulaciones de otros sistemas operativos

vSphere
vSphere es la ltima versin del hipervisor de Vmware con los paquetes de gestin relacionados. El hipervisor a da de hoy,
inicios de 2012, sigue llamndose ESX y vamos por la versin 5.0
Dentro del producto vSphere tenemos todo el conjunto de hipervisores y herramientas para otorgar alta disponibilidad a
nuestra infraestructura. Por ejemplo tenemos:

El hipervisor es el componente ms importante de toda una infraestructura basada en la virtualizacin, ya

que es el componente que monitoriza las diversas mquinas virtuales que se ejecutan en un nodo
determinado. Aqu monitoritzacin se entiende como interceptacin del uso de los recursos y autorizacin
de acceso a los mismos, con lo que en el fondo estamos particionando un nodo para que pueda ejecutar
varios entornos operativos (Linux, Windows, etc...)
ESXi: El hipervisor de Vmware. En el siguiente enlace podrs entrar ms en detalle de lo que es y
hace un hipervisor y como consigue controlar a varias mquinas virtuales corriendo en la misma
mquina fsica es.wikipedia.org/wiki/Hipervisor. A partir de la versin 5.0 de vSphere, solo tenemos
disponible ESXi y no ESX. Este ltimo, adems del hipervisor incluia la llamada Service Console
que era un Red Hat con privilegios en el hipervisor para realizar la gestin del mismo. Al no tener la
Service Console, reducimos los recursos necesarios para el funcionamiento, menos disco, menos
memoria y evitamos tener que actualizar el entorno vSphere por fallos de seguridad de Red Hat.
Aqu podemos ver como se comparan ESXi con ESX a nivel de arquitectura
DRS (Distributed Resource Scheduler): El gestor de recursos distribuido de Vmware que permite
balancear las mquinas virtuales entre los nodos de nuestro clster. En el siguiente vdeo realizado
por Dell, se puede observar como acta DRS en un entorno de tres nodos y como consigue
balancear de nuevo el clster. En el vdeo vemos como se genera carga en tres mquinas virtuales
que est en un clster de tres nodos pero se eligen dos mquinas albergadas en el mismo nodo lo
que provoca que el clster se desbalancee, mediante DRS, al cabo de un rato ya que se recalcula
cada 5 minutos por defecto, se mueve una de las dos mquinas virtuales que estn en el nodo ms
cargado al que no tiene nada de carga. Con esto se demuestra que aunque las cargas que hay en
nuestras mquinas virtuales varien de un rato a otro, l solo se encarga de mover las mquinas a los
nodos ms descargados

DPM (Distributed Power Management): Permite que si no hacen falta algunos nodos, estos se
puedan parar para reducir el consumo elctrico
Gestin de memoria: ESXi permite asignar a las mquinas virtuales ms memoria de la existente en
el nodo fsico, esto se conoce como sobreasignacin y un exceso puede provocar problemas graves
de rendimiento
VMFS: Es el sistema propio de ficheros de ESX, como Windows puede usar por defecto FAT o
NTFS o los ext3 o ext4 de Linux. La diferencia principal es que ste est optimizado para albergar a

mquinas virtuales y accesos desde varios servidores simultneamente.

Thin Provisioning: Permite mostrar a nuestra mquina virtual ms almacenamiento que el de
verdad asignado, de esta forma nos caben ms mquinas virtuales de las que cabran si tuvisemos
en cuenta la suma de capacidades asignadas. Un abuso de Thin Provisioning nos implicar estar
muy encima de la ocupacin real de almacenamiento ya que si en algn momento excedemos la
capacidad las mquinas virtuales generaran errores de disco, seguramente corrompiendo los datos
Storage I/O Control: Ya que el almacenamiento es un recurso compartido entre todas las mquinas
virtuales, debemos evitar que una sola acapare gran parte de los recursos afectando al resto. Esta
funcionalidad evita un consumo excesivo de peticiones de lectura/escritura en un conjunto de
mquinas virtuales pueda afectar al rendimiento de todas, priorizando las mquinas con ms peso en
caso de detectar problemas.
Network I/O Control: Al igual que el almacenamiento, la red tambin es un recurso finito y
debemos poder asegurar que las mquinas virtuales ms crticas tendrn disponibilidad de suficiente
ancho de banda en la red
Distributed Switch: La funcionalidad de switch distribuido permite que se simule un switch que
abarca a todo el clster en lugar de varios switches en cada nodo. De esta forma se pueden aplicar
polticas y seguridad a nivel global y tolerar correctamente las migraciones de nodo de las mquinas
virtuales

Luego tenemos los servicios para las aplicaciones que se sustentan en la base de funcionalidades descritas
con anterioridad y son:
vMotion: Es la funcionalidad que permite a una mquina virtual cualquiera migrar a otro nodo del
clster. Esto permite realizar tareas de mantenimiento sin parada de servicio y rebalancear el clster
cuando tenemos nodos descargados y otros con ms carga. En el siguiente vdeo se puede observar
como vMotion es completamente transparente para el usuario

Storage vMotion: Funcionalidad pareja a la de vMotion, pero permite que una mquina virtual
migre de almacenamiento, ya sea para rebalancear capacidad, carga o actualizacin de la cabina de
almacenamiento
High Availability: Funcionalidad que monitoriza que las mquinas virtuales que deben estar
funcionando estn funcionando. En caso de cada de algn nodo fsico, rearrancar las mquinas
virtuales afectadas a los nodos restantes
Fault Tolerance: A diferencia de la anterior, por cada mquina en FT activa, tenemos dos
instancias corriendo en nodos diferentes que van ejecutando las mismas instrucciones, as en caso
de problema con un nodo, no hay afectacin en el servicio ofrecido por la mquina virtual. Como
una imagen vale ms que mil palabras, a partir del minuto 4 del siguiente vdeo se puede observar
como las dos mquinas van a la par

Data Recovery: Es una mquina virtual que ofrece VMware incluida con las licencias ms
avanzadas que permite realizar las copias de seguridad sin instalar ningn sistema alternativo
vShield Zones: La gama de productos de seguridad de VMware se llama vShield y Zones es su
producto de entrada de gama, incluido desde las versiones Advanced hacia adelante. Permite
segmentar la red interna de los nodos de forma que se pueda controlar el trafico entre mquinas
virtuales y aplicar seguridad
VMsafe: Son las interfaces de seguridad de VMware que permiten a otros desarrolladores crear
aplicaciones que se integren con sus soluciones, un ejemplo de aplicaciones que las aprovechan son
los antivirus que a travs de VMsafe pueden proteger a varias mquinas virtuales sin tener que
instalar nada dentro de ellas
DRS: Este es el componente que se ejecuta a nivel de clster que permite que el componente DRS a
bajo nivel pueda realizar su tarea correctamente. Evala los consumos histricos de las mquinas en
cada nodo y elige las migraciones adecuadas para tener al mximo de balanceado nuestro clster
Hot-Add: En los sistemas operativos que lo soportan permiten aadir nuevos recursos permite
aadir nuevos recursos de memoria y procesador mientras la mquina virtual est activa. Aadir
nuevas tarjetas de red o discos la mayora de sistemas lo soportan y no est descrito como
funcionalidad por lo comn de su us. En el siguiente enlace se puede descargar una gua de
compatibilidad de sistemas operativos con el servicio Hot-add. (http://partnerweb.vmware.com
/comp_guide/pdf/VMware_OS_Compatibility_Guide.pdf)

Como se puede observar un entorno virtual nos ofrece muchas ms ventajas que el entorno fsico tradicional,
por este y otros motivos, en bastantes casos conviene virtualizar servidores aunque solo podamos consolidar
muy pocos por nodo
Adems de las funcionalidades propias del entorno virtual, VMware ofrece una serie de productos que ayudan
a sacar ms provecho a la infraestructura, siendo estos:
vCenter: Esta es la herramienta bsica en cualquier despliegue de vSphere, ya que provee de las
funcionalidades para gestionar los nodos del clster, recopilar alertas, controlar las actualizaciones y en el
fondo la gestin de todo lo relacionado con la infraestructura virtual, hablaremos ms extensamente de l
en un momento
vCloud Director: Es el paquete que propone VMware para crear nubes privadas y en el fondo ofertar tu
nube a posibles clientes externos. Dispone de un portal de auto aprovisionamiento, control de consumos,
etcTiene caractersticas de Director ya que puede controlar varios clsteres de varios nodos vSphere.
Un clster vSphere puede tener como mucho 32 nodos y un vCenter unos 1000 nodos, as que para
infraestructuras ms grandes necesitamos de varios vCenter. En el siguiente vdeo puedes ver qu tipo de
interfaz obtiene el usuario
VMware View: Es la solucin de Vmware para albergar escritorios (Windows XP o 7) en la
infraestructura virtual, incluye herramientas para asignar las mquinas en base el usuario o mantener un
numero de mquinas pre-arrancadas de forma que los tiempos de respuesta de conexin de usuario sean
ms giles
vCenter Operations: Permite definir polticas que se deben aplicar a toda la infraestructura de forma
que las ampliaciones, cambios, etc de la misma no las vulneren
vCenter Site Recovery Manager: Otra herramienta vinculada a vCenter que permite tener un cluster en
otra ubicacin de forma que en caso de problemas en el datacenter principal, se puedan levantar las
mquinas virtuales protegidas en otro sitio
vCenter CapacityIQ: En base a las mtricas que ofrece vCenter agregando datos de todos los nodos y
servicios, avisar y proponer mejoras antes de llegar a lmites de capacidad en nuestra infraestructura
virtual
vCenter Chargeback: Facilitar la gestin del cobro de los servicios a los diferentes departamentos de la
compaa. Una forma de que el presupuesto de TI (tecnologas de la informacin) se reparta entre los
usuarios, por ejemplo si marqueting requiere 30 sitios web para sus promociones, lo lgico es tener como
mnimo controlado este coste
vCenter Configuration Manager: Una herramienta para definir tipos de configuracin estndar de
forma que podamos validar si nuestras mquinas virtuales tienen los parches adecuados, parmetros en el
registro o procesos de arranque autorizados
VMware Service Manager: Herramienta para definir qu servicios vamos a ofrecer desde nuestra
infraestructura y llevar todo el ciclo de vida. Est basado en las buenas prcticas de ITIL (glosario)
vCenter Orchestrator: Un plugin para vCenter que permite definir flujos de trabajo y automatizar
tareas, por ejemplo programar que por la noche a la mquina de facturacin le asignamos ms recursos,
mientras se los quitamos a otra y actualizamos a una tercera

vCenter es la mejor baza que tiene VMware ahora mismo respecto a sus competidores, una herramienta de
gestin del clster, fcil de utilizar y a la vez muy potente. Es una aplicacin que corre sobre un sistema
Windows de 64bits y que podemos tener dentro o fuera de nuestro entorno virtual

.
vCenter se encarga de que la gestin de recursos sea eficiente, que las polticas de afinidad (X y Y en el mismo
nodo) y anti-afinidad (X y Y en nodos diferentes) para cada mquina virtual se cumplan, activar el clster entre
varios ESX, pero ante todo es la herramienta bsica para el da a da de un administrador de infraestructura
virtual
Una vez montado nuestro servidor vCenter, tenemos dos opciones para gestionar de forma grfica toda la
infraestructura, utilizar vSphere Client o vSphere Web Client.
vSphere Client es una herramienta solo para Windows que permite configurar y operar con todo lo que se
pueda activar en un entorno vSphere. Para las funcionalidades no incluidas de serie, incluye soporte de plugins
de forma que por ejemplo si instalamos Update Manager, tendremos las herramientas de gestin de este
paquete completamente integradas en el entorno. Por ejemplo hasta podemos cambiar los iconos por defecto en
las mquinas virtuales para facilitar la gestin

En el otro extremo de los casos de uso tenemos a vSphere Web Client que es una aplicacin web que debemos
instalar en algn servidor que tenga acceso a nuestro vCenter Server, ya que utiliza vCenter Server para

gestionar a todo el entorno.

vSphere Web Client est pensada para poder parar y arrancar mquinas, editar parmetros bsicos de las
mquinas virtuales y monitorizar los recursos gastados. Est orientada a aquel usuario que debe interactuar con
vSphere pero no se dedica a administrar la infraestructura virtual
En el siguiente video podis ver un recorrido por la herramienta, est en ingls pero lo importante es que veis
lo que nos permite realizar para decidir si instalamos vSphere Web Client o vSphere Client

2. Gestin de mquinas virtuales

Mdulos

2.1 Requerimientos mnimos

Antes de gestionar las mquinas debemos tener el entorno montado, por un lado tendremos varas
mquinas corriendo el hipervisor ESXi 5, por otro algn equipo SAN o NAS que ofrezca almacenamiento
a ESXi, puede ser NFS, iSCSI o Fibre Channel y vCenter Server corriendo en el propio entorno virtual o
en otra mquina fsica. Estos documentos se pueden encontrar en la web de Vmware
(http://kb.vmware.com/selfservice/documentLinkInt.do?micrositeID=&popup=true&languageId=&
externalID=2005381), pero los incluimos aqu al entender interesante conocer que tipo de servidores
debemos adquirir para nuestra plataforma
Los requerimientos para instalar ESXi 5.0, son:
Su hardware cumple con los requisitos de la Gua de compatibilidad de VMware. Esto incluye:
Compatibilidad del sistema
Compatibilidad de E/S (tarjetas de red y HBA)
Compatibilidad de almacenamiento
Compatibilidad del software de copias de seguridad (backup)
Tenemos un procesador de 64 bits. Tenga en cuenta que VMware ESXi 5.0 slo instala y se ejecuta en
servidores con CPU de 64 bits x86. Adicionalmente slo admite instrucciones de CPU tipo LAHF y SAHF.
Estos son procesadores de 64 bits ampliamente conocidos:
Todos los procesadores AMD Opteron
Todos los procesadores Intel Xeon 3000/3200, 3100/3300, 5100/5300, 5200/5400, 5500/5600, 7100/7300,
7200/7400, y los procesadores 7500
La opcin Intel VT est habilitada en el BIOS del host o servidor.
La memoria RAM es de 3GB. Este es el mnimo requerido para instalar.
Usted tiene uno o ms controladores Ethernet de 1 Gigabit o 10 Gigabit. Para una lista de los modelos
de adaptadores de red, consulte la Gua de compatibilidad de VMware.
Tiene un disco SCSI o uno local, no en red, un LUN RAID con el espacio sin particionar para las
mquinas virtuales. Para Serial ATA (SATA), se debe tener el disco conectado a travs de controladores
SAS soportados o sobre tarjetas controladoras SATA soportadas. Los discos SATA se consideran
remotos, no locales. Estos discos no se utilizan por defecto como una particin de scratch, porque se
les ve como discos remotos.
Nota: No se puede conectar un dispositivo de disco CD-ROM SATA a una mquina virtual en un servidor
ESXi 5.0. Para utilizar el dispositivo CD-ROM SATA, debe usar el modo de emulacin IDE.
Usted est utilizando un sistema de almacenamiento soportado o compatible. ESXi 5.0 soporta la
instalacin y el arranque desde los siguientes sistemas de almacenamiento:
Unidades de disco SATA. Unidades de disco SATA conectados a travs de controladores SAS
compatibles. Algunos controladores SAS soportados son:
LSI1068E (LSISAS3442E)
LSI1068 (SAS 5)
IBM ServeRAID 8K SAS controller

2.1 Requerimientos
mnimos
2.2 Requerimientos de
vCenter 5.0
2.3 Cmo gestionarlas
2.4 Plantillas
2.5 Creacin de una
mquina virtual
2.6 Prerequisitos
Generales
2.7. Ejercicio

2.2 Requerimientos de vCenter 5.0

Los requerimientos mnimos para vCenter 5.0 son:
Asegrese que cumple con los requisitos mnimos de hardware y que el hardware y sistema
operativo son compatibles. El servidor vCenter Server 5.0 del sistema puede ser una mquina fsica
o una mquina virtual. Si va a instalar vCenter 5.0 en una mquina virtual, consulte Running vCenter
Server in a virtual machine (10087) para ms informacin.
vCenter Server 5.0 requiere un nombre de la fuente de datos (DSN) de 64-bit para conectarse a su
base de datos.
En esta tabla se describen los requisitos mnimos de hardware:
Hardware
Requisito
Comentarios
Procesador Procesadores Intel o AMDEl procesador Intel Itanium (IA64) no es compatible. Los
x86 con dos o ms
requisitos de procesador podran ser mayores si la base de
ncleos (cores) lgicos, datos se ejecuta en la misma mquina.
cada uno con una
velocidad de al menos
2GHz
Los requisitos de RAM pueden ser mayores si su base de
Memoria 4 GB de RAM
datos se ejecuta en la misma mquina. La administracin
de servicios web, VMware VirtualCenter Management
WebServices, requiere de 512 MB a 4.4GB de memoria
adicional. La mxima memoria la JVM de Webservices se
puede especificar durante la instalacin dependiendo del
tamao del inventario.
Los Requisitos de disco pueden ser mayores si la base de
Capacidad de4 GB de Disco
datos del servidor vCenter Server se ejecuta en la misma
Disco
mquina.En vCenter Server 5.0, el tamao predeterminado
para los registros log de vCenter Server es 450 MB, que es
mayor que en vCenter Server 4.x Asegrese que el espacio
asignado a la carpeta de registros log es suficiente para
soportar este aumento.
Hasta 2GB de espacio libre en disco para descomprimir el
Disco para 2 GB de Disco
archivo de instalacin. Aproximadamente 1,5 GB de estos
SQL 2k8R2
archivos son borrados despus de finalizada la instalacin.
Express
Recomendacin
Conexin de 1 Gbps
red
Estos son los requisitos para instalar vCenter Server en un disco local no que no sea C::
1 GB en la unidad custom drive para vCenter Server
1.13GB en la unidad C: para Microsoft.NET 3.0 SP1, Microsoft ADAM, Microsoft SQL Server 2008 R2
Express (opcional) y Microsoft Visual C++ 2008 Redistribuible
375MB for la unidad no C: drive%temp%variable
La base Microsoft SQL Server 2008 R2 Express incluida en el paquete requiere al menos 2GB de
espacio libre en disco para la base de datos.
Configuraciones de hardware recomendadas
Esta tabla resume las configuraciones de hardware recomendadas para una instalacin mediana de
hasta 50 hosts y 500 mquinas virtuales encendidas:
Producto
Nmero de ncleos
Memoria
Disco
vCenter Server

4GB

5GB

Producto
vSphere Client

Nmero de ncleos

Memoria
200MB

Disco
1.5GB

Esta tabla resume las configuraciones de hardware recomendadas para una instalacin grande de
hasta 300 hosts y 3.000 mquinas virtuales encendidas:
Producto

Nmero de ncleos

Memoria

Disco

vCenter Server

8GB

10GB

vSphere Client

500MB

1.5GB

Esta tabla resume las configuraciones de hardware recomendadas para una instalacin extra-grande
de hasta 1.000 hosts y 10.000 mquinas virtuales encendidas:
Producto
Nmero de ncleos
Memoria
Disco
vCenter Server

16GB

10GB

vSphere Client

500MB

1.5GB

Requisitos del sistema operativo

Nota: vCenter Server 5.0 requiere un sistema operativo de 64 bits y no se puede instalar en un
sistema operativo de 32 bits. Al realizar una instalacin debe asegurarse de que su sistema operativo
es compatible con 64 bits.
Estos son los sistemas operativos soportados:
Microsoft Windows Server 2003 Standard, Enterprise or Datacenter SP2 64bit
Microsoft Windows Server 2003 Standard, Enterprise or Datacenter R2 SP2 64bit
Microsoft Windows Server 2008 Standard, Enterprise or Datacenter SP2 64bit
Microsoft Windows Server 2008 Standard, Enterprise or Datacenter R2 SP2 64bit
Requisitos de la Pre-instalacin de software
vCenter Server requiere Microsoft .NET 3.5 SP1 Framework. Si no est instalado en su sistema, el
instalador de vCenter Server lo instala por usted.
Nota: Microsoft Framework 3.5 SP1 puede requerir conexin a Internet para descargar y actualizar
los archivos durante el proceso de instalacin.
Si planea utilizar la base de datos Microsoft SQL Server 2008 R2 Express que viene incluida con
vCenter Server 5.0, Microsoft Windows Installer version 4.5 (MSI 4.5) necesita estar instalado en su
sistema. Usted puede descargar MSI 4.5 del sitio Web de Microsoft. Tambin puede instalar MSI 4.5
directamente desde el CD/DVD-ROM de vCenter Server 5.0.
Configuracin de la base de datos de vCenter Server
vCenter Server y el Administrador de actualizaciones (Update Manager) requieren bases de datos
para almacenar y organizar los datos del servidor. VMware recomienda el uso de bases de datos
separadas para vCenter Server y el Administrador de actualizaciones. Para implementaciones
pequeas, una base de datos para el administrador Update Manager podra no ser necesaria, sin
embargo no se recomienda omitirla.
Cada instancia de vCenter Server debe tener su propia base de datos. instancias de vCenter Server
no pueden compartir el mismo esquema de base de datos. Varias bases de datos de vCenter Server

pueden residir en el mismo servidor de base de datos, o tambin pueden estar separadas a travs
de mltiples servidores de bases de datos.
Para bases de datos Oracle, que tienen el concepto de objetos de esquema, usted puede ejecutar
mltiples instancias de vCenter Server en un solo servidor de base de datos si usted tiene un
propietario de esquema diferente para cada instancia de vCenter Server. Tambin puede utilizar un
servidor de base de datos Oracle dedicado para cada instancia de vCenter Server.
No es necesario instalar un nuevo servidor de base de datos para que trabaje la instalacin del
servidor vCenter server. Durante la instalacin de vCenter Server, usted puede apuntar el sistema de
vCenter Server a cualquier base de datos existente que sea compatible o soportada. vCenter Server
es compatible con las bases de datos IBM DB2, Oracle y Microsoft SQL Server. El administrador de
actualizaciones Update Manager es compatible con las bases de datos Oracle y Microsoft SQL
Server. Adicionalmente, las bases de datos de vCenter Server requieren un set de caracteres UTF.
Nota: Si usted tiene una base de datos de vCenter Server que desea conservar, no realice una
nueva instalacin de vCenter Server. Para ms informacin, consulte Upgrading to vCenter Server
5.0 (2003866). Para utilizar una base de datos existente, es necesario proporcionar el nombre DSN
de un sistema de 64 bits que apunte a la base de datos de vCenter Server.
Despus de elegir un tipo de base de datos, asegrese que entiende los requisitos de configuracin
y versin o parche requerido por la base de datos.
Notas:
Microsoft SQL Server 2005 Express est diseado para utilizarse con las implementaciones
pequeas de hasta 5 hosts y/o 50 mquinas virtuales.
IBM DB2 slo es compatible con vCenter Server. No hay soporte para el administrador de
actualizaciones Update Manager o cualquier plug-in que requiera una base de datos.
Un DSN de 64 bits debe ser creado para que apunte a una base de datos configurada con los
requisitos mnimos.
Creacin de un DSN de 64 bits para vCenter Server
El sistema del servidor vCenter Server debe tener un DSN de 64 bits. Este requisito es aplicable a
todas las bases de datos soportadas.
Nota: El administrador Update Manager todava requiere el uso de un DSN de 32-bit.
Para crear un DSN de 64 bits para vCenter Server siga estos pasos:
Seleccione Control Panel > Administrative Tools > Data Sources (ODBC).
Utilice la aplicacin para crear un DSN para el sistema y seleccione el controlador apropiado de
acuerdo a los requisitos del proveedor de bases de datos.
Nota: Por ejemplo, si usted tiene una base de datos Microsoft SQL Server, cree el DSN del sistema
para el controlador de SQL Native Client driver.
Pruebe la conectividad.
Configuracin del servidor vCenter Server para comunicarse con una base de datos local
Si desea instalar vCenter Server y la base de datos en el mismo sistema, la mquina en la que
instale o actualice vCenter Server debe tener un nombre de equipo de 15 caracteres o menos.
Si su base de datos se encuentra en la misma mquina en la que vCenter Server ser instalado, y
recientemente ha cambiado el nombre de esta mquina para cumplir con el requisito de longitud del
nombre, asegrese que el DSN vCenter Server est configurado para comunicarse con el nuevo
nombre de la mquina.
Cambiar el nombre del equipo del vCenter Server impacta la comunicacin con la base de datos si el
servidor de esa base est en el mismo equipo del servidor vCenter Server. Si ha cambiado el nombre
de la mquina, verifique que la comunicacin se mantiene intacta.
El cambio de nombre no tiene ningn efecto en la comunicacin con bases de datos remotas. Usted
puede omitir este procedimiento si su base de datos es remota.

Nota: La limitacin de longitud del nombre aplica al sistema de vCenter Server. El DSN y los
sistemas de bases de datos remotos pueden tener nombres con ms de 15 caracteres.
Consulte con su administrador de base de datos o con el proveedor de bases de datos para
asegurarse que todos los componentes de la base de datos funcionan despus de cambiar el
nombre del servidor.
Cuando est configurando vCenter Server para comunicarse con una base de datos local, asegrese
que:
El servidor de base de datos est en ejecucin
El nombre del equipo del servidor vCenter Server est actualizado en el servicio de nombres de
dominio (DNS)
Para probar la conexin, haga ping al nombre del equipo. Por ejemplo, si el nombre del equipo es
host-1.company.com, ejecute el siguiente comando en una pantalla de comandos de Windows:
ping host-1.company.com
Si puede hacer ping correctamente al nombre del equipo, entonces el nombre est actualizado en el
DNS.
Paquete incluido de la Base de Datos Microsoft SQL Server 2008 R2 Express
El Paquete incluido de la Base de Datos Microsoft SQL Server 2008 R2 Express es instalado y
configurado cuando se selecciona la opcin bundled database durante la instalacin o actualizacin
de vCenter Server.
Para instalar la base de datos Microsoft SQL Server 2008 R2 Express que viene incluida con vCenter
Server 5.0, se necesita que Microsoft Windows Installer version 4.5 (MSI 4.5) est instalado en su
sistema. Usted puede descargar MSI versin 4.5 desde Microsoft. Tambin se puede instalar MSI 4.5
directamente desde el instalador autorun.exe de vCenter Server.
Las siguientes son las bases de datos soportadas:
IBM DB2 9.5
IBM DB2 9.7
SQL Server 2005 32-bit Standard, Enterprise SP3
SQL Server 2005 64-bit Standard, Enterprise SP3
SQL Server 2008 64-bit Express R2
SQL Server 2008 32-bit Standard, Enterprise
SQL Server 2008 64-bit Standard, Enterprise
SQL Server 2008 32-bit Standard, Enterprise SP1
SQL Server 2008 64-bit Standard, Enterprise SP1
Oracle 10g 32-bit Standard, Enterprise, One R2 (supported with version 10.2.0.3.0 or higher)
Oracle 10g 64-bit Standard, Enterprise, One R2 (requires version 10.2.0.4)
Oracle 11g 32-bit Standard, Enterprise, One R1
Oracle 11g 64-bit Standard, Enterprise, One R1
Oracle 11g 32-bit Standard, Enterprise, One R2
Oracle 11g 64-bit Standard, Enterprise, One R2

2.3 Cmo gestionarlas

La gestin de mquinas virtuales en un entorno vSphere la podemos realizar de varias formas,
siendo la ms intuitiva la proporcionada por vSphere Client. Disponemos tambin de acceso va lnea
de comandos a travs de PowerShell (PowerCLI) o trabajando contra el API de ESX o de vCenter
segn convenga. Aqu podemos ver una captura de la ayuda de PowerCLI para el comando
Get-VMhost, que nos listar todos los nodos ESXi dados de alta en un vCenter determinado

Como gua, podemos considerar que casi todo lo podremos hacer por la interfaz grfica, los plugins
se integran perfectamente y adems es la herramienta ms usada por ms administradores lo que
ayuda a encontrar soluciones a nuestros problemas mediante Google o los foros propios de Vmware.
Aun as, es recomendable utilizar la lnea de comandos o el API cuando se realicen tareas repetitivas
o se quiera automatizar alguna de ellas. Por ejemplo si estamos ofreciendo un servicio que debe
permitir a no-administradores solicitar mquinas virtuales de un catlogo, puede ser interesante
automatizar desde un portal Web o parecido la peticin, validar el flujo conforme la peticin est
autorizada (lo mismo que haramos si nos llega un correo electrnico pidiendo una mquina
adicional), clonar una plantilla (Template) y arrancar la mquina virtual automatizando o no la
asignacin de la IP y la membresa en el dominio en caso de mquina Windows.
Automatizndolo de forma correcta, es decir incluyendo registro y auditoria de las acciones y
generando una serie de informes de uso y consumo, ganamos en el control de nuestra plataforma
virtual, ya que el gran problema en las plataformas virtuales es que el coste marginal de una nueva
mquina es casi despreciable y acaban existiendo demasiadas mquinas con su memoria y disco,
de las que no sabemos casi nada y nadie se atreve a eliminarlas, generando un problema de
gestin. Si tenemos un buen registro, siempre podremos preguntar a quien autoriz la activacin el
por qu y si sigue siendo necesaria. Si las peticiones pasan a travs de una persona, puede darse el
caso de activaciones de mquinas mediante una llamada y que luego no quede el registro oportuno,
del quin y porqu se activ esa mquina que lleva 6 meses all sin hacer nada pero ocupando

espacio.
Por ejemplo, esa capacidad de automatizacin es la que permite tener productos como vCloud,
vCenter Orchestrator o de terceros como Abiquo o OpenStack. En el caso de Abiquo, disponemos
de una interfaz Web que nos permite crear nuevas mquinas, indicar relaciones entre ellas,
gestionar desde un nico lugar varios centros de datos y un largo etctera

vSphere nos permite agrupar las mquinas de nuestro clster dentro de carpetas para tenerlas
fcilmente ordenadas y encontrar rpidamente una mquina virtual cuando la estamos buscando por
algn tipo de incidencia o peticin de usuario.

Ya que la carpeta fsica donde est guardada la mquina tiene el nombre de creacin, si definimos
nombres como Test-Servidor1 y luego cambiamos de nombre a Produccin-Servidor1, aunque
la interfaz nos muestre el cambio de nombre, en la datastore o almacn de datos, se mantendr el
nombre antiguo hasta que se realice una datastore migration, por tanto es mucho ms cmodo
mover la mquina de la carpeta Test a la carpeta Produccin y luego no tendremos que tocar
nada.
Una vez tenemos alguna mquina creada, si creemos que vamos a necesitar varias de ellas, la
podemos convertir en plantilla, Template, para luego, clonarla y convertirla de nuevo en mquina
virtual

2.4 Plantillas
Esta es una funcionalidad que aporta vCenter, as que si solo tenemos ESXi, la interfaz no nos
permitir clonar mquinas virtuales o crear plantillas, aunque copiando los ficheros .vmdk (Vmware
disk, el disco de nuestra mquina) y asignndolo a otras mquinas acabamos teniendo clonacin y
una especie de plantillas
Si nos hemos decidido aprovechar la capacidad de disponer de plantillas de mquinas virtuales,
debemos tener en cuenta que al volver a convertirla en mquina virtual se mantendr la
configuracin que tena en su momento la plantilla con lo que tendremos que cambiar la direcciones
IP en caso de tenerlas configuradas como estticas, cambiar nombre la mquina y dems
configuracin especfica. En el caso de mquinas Windows puede ser interesante ejecutar sysprep
(http://technet.microsoft.com/es-es/library/cc721940(WS.10).aspx)
Por tanto una buena prctica es montar un servidor DHCP (http://es.wikipedia.org
/wiki/Dynamic_Host_Configuration_Protocol) para que asigne las IPs a las mquinas o en su defecto,
reservar las IP de las plantillas de forma que cuando activemos una de las mquinas virtuales, lo
primero que debemos hacer es cambiar la IP y seguramente el nombre, e intentar que el nombre de
mquina sea el mismo o muy similar al nombre que le hemos dado a la mquina virtual.
En el fondo, la diferencia de disponer de plantillas o clonar mquinas virtuales, es que las plantillas
no son ejecutables y quedan muy bien identificadas como tales, mientras que una mquina virtual
que utilicemos como base para clonar, por error la podemos pasar a produccin o realizar cambios
que afecten luego a nuevos clones
Los pasos para realizarlo son los siguientes
Escoger una mquina virtual que ser la base de nuestra plantilla. Si est parada mucho mejor

Si seleccionamos "Convert to Template", perderemos esa mquina virtual, si Clonamos a plantilla,

se realizar una copia y podremos seguir utilizando aquella mquina para su uso normal. Si la
clonamos, debemos decidir donde la guardamos. Por comodidad, puede ser interesante disponer de
un datastore para ficheros que no se mueven demasiado como ISOs o plantillas y almacenarlo en
discos baratos

Una vez seleccionado el lugar, nos debemos esperar a que vSphere copie los datos a ese
almacenamiento y marque la mquina como Plantilla. Dependiendo de la velocidad de nuestro
entorno y del tamao de la mquina, pueden ser unos minutos

Una vez clonada y marcada como "Template", podremos ver que el icono a la izquierda del nombre
es diferente

En el siguiente paso, vamos a convertir a nuestra plantilla otra vez en mquina virtual, como se
puede ver en la captura anterior, tenemos dos opciones, una "Deploy Virtual Machine from this
Template" que copiar de nuevo la plantilla a otra ubicacin y luego la marcar como mquina virtual
y "Convert to Virtual Machine" que solo la marcar otra vez como mquina virtual. Se nos pide donde
vincularla, seleccionamos el nodo o el clster en caso de disponer de DRS y ya la tendremos

Y una vez terminado el proceso, volvemos a tener una mquina con icono normal, manteniendo el
nombre y la carpeta en el almacenamiento de la plantilla, as que se debe ir con cuidado para
mantener una cierta consistencia entre nombres de almacenamiento y nombres de inventario. En la
parte de la pantalla que muestra las tareas recientes, podemos ver la diferencia de tiempo en clonar
y marcar la plantilla. Estos 5 minutos que ha tardado en copiar los 40GB implican una velocidad de
casi 150 MB/s, ms de 1Gb/s.

En caso de mquinas Windows, si no nos interesa realizar un sysprep, debemos tener cuidado en
no darla de alta en el dominio ya que al clonarla nos puede dar problemas por autenticacin y
membresa al mismo. As que si vamos a crear plantillas Windows, instalamos, aplicamos los
parches, instalamos las aplicaciones que no son dependientes del nombre de la mquina ni de la
membresa del dominio, como por ejemplo las VMtools y luego generamos la plantilla, cuando la
clonemos a mquina virtual, cambiamos la IP y nombre, la agregamos al dominio y luego ya
instalamos el resto de aplicaciones dependientes

2.5 Creacin de una mquina virtual

El primer paso para crear una mquina virtual es indicrselo a vSphere Client, una vez nos muestra
el dilogo debemos darle nombre a la mquina teniendo en cuenta, que este nombre se usar para
la carpeta en el datastore y no es trivial cambiar el nombre all, si lo hacemos directamente nos
quedaremos sin acceso a la mquina virtual ya que no cuadrar con el inventario

Una vez dado nombre, debemos escoger en qu datastore almacenaremos los ficheros de
configuraci y datos de la mquina virtual. Aunque podemos crear discos relacionados con esa
mquina en varios datastores, mejor guardarlos todos juntos por facilidad de gestin. Un caso podra
ser un servidor de base de datos, donde tenemos el sistema operativo en un almacenamiento "lento"
y las bases de datos en un almacenamiento "rpido"

El siguiente paso es indicar qu tipo de sistema operativo instalaremos en nuestra mquina virtual,
en base a esto, la configuracin por defecto de la mquina ser una u otra, recomendacin de
memoria, emulacin de dispositivos (SCSI, red, etc...) y comportamiento si es 64 o 32 bits.
La mejor forma para hacer pruebas es instalar una pequea distribucin Linux, que al ser de libre
descarga no nos generar problemas legales y al ser Ubuntu una de las ms asequibles para
cualquier usuario, vamos a usar esta

El siguiente paso es escoger qu redes tendr nuestra nueva mquina, cada una de estas tarjetas
de red o NICs en ingls la tenemos que vincular a una red del servidor ESXi, seleccionar que tipo de
adaptador usaremos, tenemos Intel E1000, VMXnet2, VMXnet3 y Flexible, los VMXnet* requieren de
controladores especificos que se instalan con las VMtools, el tipo "Flexible" que dependiendo del
controlador se comporta como una Vlance o una VMXnet.

El siguiente paso es crear un disco donde instalar nuestra mquina, los dos modos "Thick" generan
un fichero en el datastore del tamao especificado y la diferencia es si lo escriben con ceros durante
la creacin o conforme se va accediendo a l. El modo "Thin", muestra a la mquina virtual un disco
del tamao total pero el fichero que da soporte a ese disco va creciendo conforme se va usando, de
esta forma podemos asignar ms disco del existente fsicamente

Revisamos que todo es correcto y ya que esa configuracin no instala el sistema operativo le
indicamos que queremos editar la configuracin antes de crearla

Editamos el CD/DVD emulado para indicarle que utilice una ISO que tenemos en el datastore pero
podemos pasar un CD/DVD que tenga el nodo ESXi o nuestro propio CD donde se est ejecutando
el cliente vSphere

Damos a "Finish" y ya tendremos nuestra mquina virtual creada, ahora solo falta encederla, abrir la
consola (el icono con una pantalla y flecha verde) e instalar Ubuntu de forma normal

Una vez tengamos instalado nuestro sistema operativo hospedado, debemos instalar las
herramientas de Vmware o VM Tools, es interesante instalarlas ya que incluyen controladores
especficos para los dispositivos emulados, ya sea la red, el disco o la pantalla, con lo que
ganaremos velocidad en la mquina virtual y al bajar la carga adicional de recursos o overhead en
ingls, mejoramos el rendimiento para el resto de mquinas virtuales hospedadas en ese nodo.
Adems de los controladores tambin se incluye la capacidad de balloning o un pequeo servicio
que reserva memoria en nuestra mquina virtual para asignrsela a otra mquina virtual que lo
necesita y tiene ms prioridad que la nuestra. Esta funcin, aunque no aportar mejora del
rendimiento en nuestra mquina, si que permite que en algn momento, la suma de las memorias
de las mquinas virtuales supere a la del nodo fsico. El sistema de hinchado de globo se utiliza
porque la mayora de sistemas operativos no toleran demasiado bien que se les quite memoria de un
momento para otro y de esa forma, teniendo un proceso no paginable corriendo en la mquina
virtual, nos aseguramos que los procesos ms importantes seguirn en memoria y se reducir la
memoria asignada a cache de ficheros o usos menos prioritarios

2.6 Prerequisitos Generales

Antes de instalar vCenter Server, asegrese de lo siguiente:
Compruebe que tiene el DVD de instalacin o ha descargado el instalador de vCenter Server.
Verifique que los puertos necesarios estn abiertos. Para ms informacin, consulte Required
Ports for vCenter Server (2005105).
Verifique que su base de datos cumple con los requisitos correspondientes. Para ms
informacin
Recopile la informacin que el asistente de instalacin del servidor vCenter Server requiere. Para
ms informacin.
Verifique que el nombre de dominio completo (FQDN) del sistema donde va a instalar vCenter
Server se pueda resolver. Para comprobar que el nombre se puede resolver, escriba: nslookup
<vCenter_Server_fqdn> en una ventana de linea de comandos. Si el nombre completo (FQDN)
se puede resolver, el comando nslookup devuelve la direccin IP y el nombre de la mquina del
controlador de dominio.
Verifique que no haya Network Address Translation (NAT) existente entre el sistema de vCenter
Server y los servidores que va a administrar.
Verifique que el nombre del equipo no tiene ms de 15 caracteres.
Compruebe que el nombre DNS de la mquina coincide con el nombre real del equipo.
Asegrese que el sistema en el que va a instalar vCenter Server no es un controlador de dominio
de Active Directory. La instalacin de vCenter Server en un controlador de dominio no es
soportada.
En cada sistema que se est ejecutando vCenter Server, asegrese que la cuenta de usuario de
dominio tiene estos permisos:
Pertenece al grupo de administradores
Acta como parte del sistema operativo
Inicia sesin como un servicio
Tenga en cuenta si la instancia del servidor vCenter ser independiente (Standalone) o
pertenecer a un grupo vinculado (Linked Mode group).
Adicionalmente, considere los siguientes puntos:
A menos que usted planee instalar el paquete incluido de SQL Server 2008 R2 Express, cree
una base de datos para el servidor vCenter Server.
Si el sistema que se utiliza para la instalacin de vCenter Server pertenece a un grupo de trabajo
(workgroup) en lugar de pertenecer a un dominio, no toda la funcionalidad estar disponible para
vCenter Server. Si es asignado a un grupo de trabajo, el sistema de vCenter Server no es capaz
de descubrir todos los dominios y los sistemas disponibles en la red cuando utiliza ciertas
funciones. Para determinar si el sistema pertenece a un grupo de trabajo o un dominio, haga
click-derecho en My Computer.
Durante la instalacin, verifique que la conexin entre la mquina y el controlador de dominio
est funcionando.
La cuenta Servicio de red (NETWORK SERVICE) se requiere que est en la carpeta en la que
est instalado el servidor vCenter Server y en la clave de Registro HKLM. Si no est seguro de
esto, pngase en contacto con el administrador del sistema.
Instale vCenter Server, al igual que cualquier servidor de la red, en una mquina con una
direccin IP fija y un nombre DNS conocido, de tal forma que los clientes puedan acceder
confiablemente al servicio. Asigne una direccin IP esttica y un nombre de host para el servidor
de Windows donde residir el sistema de vCenter Server. Esta direccin IP debe tener un registro
(interno) vlido en el sistema de nombres de dominio (DNS). Asegrese que la interfaz de
administracin del servidor ESXi tiene una resolucin DNS vlida desde vCenter Server y desde
todos los clientes vSphere. Asegrese que el servidor vCenter Server tiene una resolucin DNS
vlida desde todos los hosts ESXi y desde todos los clientes vSphere. Si utiliza DHCP en lugar
de una direccin IP esttica para vCenter Server, asegrese que el nombre del equipo de
vCenter Server est actualizado en el servicio de nombres de dominio (DNS).

Haga Ping al nombre del equipo para probar esta conexin. Por ejemplo, si el nombre del
equipo es host-1.company.com, ejecute este comando en una ventana de comandos del
sistema Windows:
ping host-1.company.com
Si puede hacer ping correctamente al nombre del equipo, entonces el nombre est
actualizado en el DNS.
Informacin sobre cuentas
Usted puede utilizar el sistema integrado de cuentas de Microsoft Windows o una cuenta de
usuario para ejecutar vCenter Server.
Con una cuenta de usuario, puede habilitar la autenticacin de Windows para SQL Server y
proporcionar una mayor seguridad. La cuenta de usuario debe ser un administrador en la
mquina local. En el asistente de instalacin, debe especificar el nombre de cuenta como
DomainNameUsername. Debe configurar la base de datos SQL Server para permitir el acceso de
SQL Server a la cuenta de dominio.
El sistema integrado de cuentas de Microsoft Windows tiene ms permisos y derechos en el
servidor que las necesidades del sistema vCenter Server, lo que puede contribuir a problemas de
seguridad.
Para los DSN de SQL Server configurados con autenticacin de windows, utilice la misma cuenta
de usuario para el servicio web VMware VirtualCenter Management Webservices y para el usuario
DSN.
Si no planea utilizar la autenticacin de Microsoft Windows para SQL Server o si est utilizando
una base de datos Oracle o DB2, es posible que an desee configurar una cuenta de usuario
local para el sistema de vCenter Server. El nico requisito es que la cuenta de usuario sea un
administrador en la mquina local.
Nota: Si instala una instancia de vCenter Server como una cuenta de sistema local en una base
de datos local de SQL Server con la autenticacin integrada de Windows NT, y usted agrega un
usuario de autenticacin integrada de Windows NT en el servidor de base de datos local con la
misma base de datos predeterminada que vCenter Server, vCenter Server podra no arrancar.

IPv6
Si instala vCenter Server en un sistema que est configurado para utilizar IPv6, vCenter Server
utiliza IPv6. Cuando se conecte a ese sistema de vCenter Server o instale ms mdulos, debe
especificar la direccin del servidor en formato IPv6, a menos que utilice el nombre de dominio
completo (FQDN). Tal como se especifca en los estndares de la llamada de procedimiento
remoto (Remote Procedure Call - RPC) para direcciones IPv6, se debe incluir la direccin IPv6
entre corchetes. Por ejemplo: [IPv6-address]

3.1 Tipos de Redes y puertos

En vSphere podemos diferenciar dos tipos de redes, las llamadas de Virtual Machine o
mquina virtual y las de VMKernel o necesarias para el hipervisor.
Redes
Las redes de VMKernel son en las que asignaremos las direcciones IP que usar ESXi para
migrar mquinas de un nodo a otro, para gestin y conexin a su vCenter Server asignado, para
decidir qu nodo es el maestro del clster y acceder a almacenamiento basado en IP como
puede ser NFS o iSCSI. Por tanto es una red muy crtica para el buen funcionamiento del
entorno y debe disponer de una alta disponibilidad y ancho de banda, mxime si utilizamos
almacenamiento basado en IP. En caso de utilizar Fibre Channel como protocolo de acceso a
nuestra SAN (Storage Area Network) la red VMkernel, no requerir tanto acho de banda si no
tenemos activado la funcionalidad de vMotion (migracin de mquinas virtuales en caliente)
Las redes de Virtual Machine, en cambio, son las que usaremos para conectar las mquinas
virtuales alojadas en el nodo con el mundo exterior, debemos utilizar sistemas de alta
disponibilidad ya que en el caso de fallo, no solo dejaramos una mquina sin servicio sino todas
las mquinas alojadas dentro del nodo, que pueden ser decenas. A nivel de ancho de banda
disponible, debemos hacer un clculo de la capacidad total necesaria para cada mquina
teniendo en cuenta que al agregarse debemos sumar la capacidad en un momento dado y no la
suma de picos de ancho de banda. Por ejemplo si tenemos una mquina virtual que requiere 900
Mb/s por la noche ya que es la que realiza las copias de seguridad, y otra que requiere 800 Mb/s
por el da ya que ofrece los vdeos para nuestro sistema de formacin en lnea, la capacidad total
que debemos ofrecer ser por lo menos 900 Mb/s en lugar de 1700 Mb/s.
Como hemos visto en la leccin de gestin de mquinas virtuales, al crear una mquina se nos
pregunta qu red o redes queremos asignar a la misma y de esta forma simulamos el latiguillo
de la tarjeta de red virtual a un puerto del switch virtual.
Grupo de puertos
Como veremos en el siguiente apartado, en cada switch virtual por lo menos tenemos un grupo
de puertos, el que viene por defecto. Todos los puertos virtuales del mismo grupo de puertos se
pueden comunicar entre ellos a nivel 2, con lo que lo ms normal es que un grupo de puertos
defina una red con direccionamiento propio, por ejemplo en el caso de redes IPv4, el grupo de
puertos A podra tener asignado el direccionamiento 192.168.10.0/24, si asignamos una mquina
virtual del mismo rango en otro grupo de puertos no se podrn comunicar ya que no usaran una
puerta de enlace o Gateway.
La diferencia principal entre los grupos de puertos en switches distribuidos o estndar, radica en
que en el caso de switches estndar debemos asegurarnos que los grupos de puertos estn
etiquetados con el mismo nombre y en caso de utilizar VLANes est asignados al mismos ID de
VLAN. En cambio en un switch distribuido, la configuracin es global en todo el clster y por
tanto solo necesitaremos una configuracin especfica de VLAN si tambin tenemos mquinas
del mismo direccionamiento en el mundo fsico.
A parte de algunas funcionalidades adicionales como polticas de seguridad, ancho de banda,
etc, la mayor parte del tiempo estaremos utilizando grupos de puertos como sinnimos de
VLAN
En el caso que estemos utilizando puertos troncales de VLANes que permiten que por un mismo
puerto virtual pasen varias VLANes simultaneas y sea la mquina virtual la qu decida qu hace
con ellas, no tenemos una relacin 1:1, pero igualmente funcionar como funcionan los switches
fsicos, tenemos unos puertos que pueden comunicarse con los que pertenecen a su misma
VLAN (o no pertenecen a ninguna), los puertos de acceso, y algunos por los que pueden pasar
una serie de VLANs, los denominados puertos trunk

3.2 Switches
Tenemos dos tipos de switch, los estndares y los distribuidos, a nivel de funcionalidades y
configuracin son muy parecidos. La gran ventaja del distribuido sobre el estndar es que nos
aseguramos que todos los nodos tienen exactamente la misma configuracin de red y por lo tanto
las mquinas virtuales se pueden ser alojadas en cualquiera de ellos de forma indistinta
Switches Estndar

Este tipo de switch es independiente de cada nodo, en el fondo son una abstraccin que permiten
por un lado disponer de conexin al mundo fsico mediante los enlaces de que dispone el nodo, ya
sean gigabit Ethernet, 10gigabit Ethernet o cualquiera de los medios soportados por ESXi, con una o
varias tarjetas para balanceo de carga o disponibilidad y por el otro redes virtuales como las
descritas anteriormente donde tenemos vinculadas las mquinas virtuales.

Por defecto un switch estndar emula a 120 puertos y podemos conectar redes de 1Gb/s, las
emuladas como Intel E1000 o de 10Gb/s en las VMXnet
Para crear un switch, podemos ir desde el cliente vSphere a la pestaa Configuration del nodo
que nos interese, seleccionamos Add Networking, escogemos el tipo de red que nos interese, si
de mquinas virtuales o VMkernel

Decidimos donde vinculamos nuestra nueva red, si en un switch nuevo o la aadimos a un switch
virtual existente.

Una vez creado o seleccionado el switch virtual, le damos nombre a la red e indicamos qu VLAN
(es.wikipedia.org/wiki/VLAN) se asigna a esa red. De esta forma podemos segmentar fcilmente
nuestras redes y mantener un alto nivel de seguridad al poder describir y separar entornos con
internet pblica, DMZ (http://es.wikipedia.org/wiki/Zona_desmilitarizada_(inform%C3%A1tica)) o
entorno privado o de servicios. Todo esto sin necesidad de tener varios dispositivos de red fsicos
para cada una de las redes

Una vez creado el switch virtual, podemos configurarlo para nuestras necesidades, si cada una de
nuestras mquinas virtuales dispone de varios enlaces de red, puede ser necesario ampliar el
numero por defecto de puertos, de los 120 a 4088 teniendo en cuenta que cada puerto asignado
gastar recursos para su gestin, as que una buena opcin es calcular cuantas mquinas virtuales
vamos a tener por nodo y cuantos puertos vamos a utilizar dejando algunos para posibles puntas.
Hemos de ser conscientes que para realizar cambios en el nmero de puertos deberemos reiniciar el
nodo con que mejor decidir de forma conservadora para minimizar cambios en produccin.
Tenemos las opciones de seguridad, por ejemplo si permitimos puertos en modo promiscuo, es decir
que reciban paquetes que no van dirigidos a ellos, si las direcciones MAC (es.wikipedia.org/wiki
/Direcci%C3%B3n_MAC) pueden cambiar o si los equipos virtuales pueden enviar paquetes
falseando la MAC de origen.
Control de trfico, donde podemos limitar para todos los puertos el ancho de banda que pueden
utilizar y de esta forma asegurar que ninguno de ellos supere los lmites establecidos o las opciones
que nos ayudaran a definir qu uso se les da a varios puertos de red vinculados al mismo switch
virtual. Poltica de balanceo en base a puerto virtual de origen o destino, direcciones IP del paquete
o sistema activo/pasivo donde solo se usar el puerto pasivo si el activo no est en un estado
funcional.
Switches Distribuidos

Los switches distribuidos solo estn disponibles en nodos vinculados a un vCenter Server y licencia
Enterprise. Este tipo de switch facilita en gran medida la gestin de la red en entornos relativamente
grandes ya que nos evita tener que crear en cada nodo las redes, asignarles los mismos nombres y
configuraciones, etc para que se puedan mover las mquinas virtuales entre los nodos sin
problemas.

Cuando creamos un switch virtual distribuido, lo creamos a nivel de Datacenter, el sinnimo para
vSphere del clster o grupo de nodos con configuracin equivalente y donde se pueden mover las
mquinas con total libertad.
Le damos el nombre que estimemos oportuno, definimos la compatibilidad entre versiones, ya que si
tenemos nodos vSphere 4.1 y nodos vSphere 5.0 deberemos indicar el modo de compatibilidad de
4.1, el nmero mximo de puertos de subida (uplinks) por nodo, luego asignamos los nodos que
pertenecern a ese switch y qu puertos fsicos de ese nodo estarn vinculados al mismo.
Una vez hecho esto, asignamos los diferentes grupos de puertos (Port Group) que se comportarn
como varios segmentos de red. Todos los equipos virtuales asignados al mismo grupo de puertos se
podrn comunicar sin tener que pasar por un equipo enrutador de nivel 3.
La gran ventaja de los switches distribuidos es que no solo podemos utilizar el propio de Vmware
sino tambin basarse en lgica de otros fabricantes como por ejemplo Cisco con su Nexus 1000V.
De esta forma, se puede gestionar la parte de la red del entorno virtualizado con las mismas
herramientas y muchas de las funcionalidades y ventajas que la gestin de red en el entorno fsico.

3.3 Buenas prcticas en redes

La buena prctica ms importante es asegurarse mediante los medios ms adecuados a
nuestras necesidades que en todos los nodos donde se pueda alojar una mquina virtual
cualquiera tengan la configuracin de red lo ms idntica posible, tanto en lo que respecta a
nmero, tipo y nombre de los switchs virtuales, como de los enlaces hasta la red fsica.
El hecho que se llamen igual y tengan los mismos tipos nos permitir que las mquinas se
puedan ejecutar en esa mquina y que adems se permita la migracin de las mismas. Este
ltimo punto, habilitar una de las funciones ms interesantes de un clster vSphere, la
recuperacin rpida ante fallos y el balanceo de carga.
Otra buena prctica que nos evitar problemas de rendimiento y disponibilidad, es dedicar
algunos enlaces a la red VMkernel, de forma que cuando se est realizando un o varios
vMotions, sincronizando dos mquinas virtuales mediante FT (Fault Tolerance) o comunicaciones
de gestin del propio vSphere.
Y para asegurar que mantenemos el mximo de disponibilidad posible, cada uno de nuestros
nodos debera estar conectado por lo menos a dos switches fsicos para tolerar la cada de uno
de ellos. Debemos tener en cuenta que un nodo de virtualizacin normalmente es mucho ms
crtico que otra mquina no virtualizada, por el simple hecho que en un nodo de virtualizacin
podemos tener decenas de mquinas virtuales y aunque cada una de ellas no sea ms crtica
que las no virtualizadas, la suma de todas ellas puede afectar ms al negocio que la cada de
una de las otras.
Tener en cuenta que podemos aadir y quitar dispositivos de red fsicos asignados a un vSwitch
sin problemas, pero si los quitamos todos o todos los asignados se quedan sin conectividad,
entre las mquinas virtuales del mismo nodo asignadas al mismo grupo de puertos o red se
podrn comunicar, pero no lo podrn hacer con el exterior.
Para proteger las mquinas virtuales ms crticas, se recomienda instalar cortafuegos en el
propio entorno virtual de forma que no se pueda acceder a estas mquinas desde el entorno
fsico sin pasar por el cortafuegos. Adems si no es necesario que este grupo de mquinas se
comuniquen con el exterior podemos vincularlas nicamente a redes sin ningn enlace (uplink)
En las mquinas donde sea posible, para maximizar el rendimiento utilizar como tipo de
adaptador de red VMXnet3
En las mquinas con VMXnet3 es interesante activar la descarga de la gestin de los segmentos
TCP al procesador de la tarjeta de red. Esta funcin hace que sea la propia tarjeta de red fsica
del nodo la que compruebe que los paquetes llegan en orden y de forma correcta, de manera
que el sistema operativo y por tanto el procesador de la mquina virtual no deben realizar esta
tarea, mejorando latencias y rendimientos
En caso de modificar los tamaos mximos de transmisin (MTU), nos debemos asegurar que
por lo menos todos los adaptadores, enlaces y switches vinculados a las redes VMkernel tienen
exactamente el mismo valor, ya que sino nos podemos encontrar con problemas intermitentes
dentro del clster que sern difciles de diagnosticar y solucionar.

3.2 Switches
Tenemos dos tipos de switch, los estndares y los distribuidos, a nivel de funcionalidades y
configuracin son muy parecidos. La gran ventaja del distribuido sobre el estndar es que nos
aseguramos que todos los nodos tienen exactamente la misma configuracin de red y por lo tanto
las mquinas virtuales se pueden ser alojadas en cualquiera de ellos de forma indistinta
Switches Estndar

Este tipo de switch es independiente de cada nodo, en el fondo son una abstraccin que permiten
por un lado disponer de conexin al mundo fsico mediante los enlaces de que dispone el nodo, ya
sean gigabit Ethernet, 10gigabit Ethernet o cualquiera de los medios soportados por ESXi, con una o
varias tarjetas para balanceo de carga o disponibilidad y por el otro redes virtuales como las
descritas anteriormente donde tenemos vinculadas las mquinas virtuales.

Por defecto un switch estndar emula a 120 puertos y podemos conectar redes de 1Gb/s, las
emuladas como Intel E1000 o de 10Gb/s en las VMXnet
Para crear un switch, podemos ir desde el cliente vSphere a la pestaa Configuration del nodo
que nos interese, seleccionamos Add Networking, escogemos el tipo de red que nos interese, si
de mquinas virtuales o VMkernel

Decidimos donde vinculamos nuestra nueva red, si en un switch nuevo o la aadimos a un switch
virtual existente.

Una vez creado o seleccionado el switch virtual, le damos nombre a la red e indicamos qu VLAN
(es.wikipedia.org/wiki/VLAN) se asigna a esa red. De esta forma podemos segmentar fcilmente
nuestras redes y mantener un alto nivel de seguridad al poder describir y separar entornos con
internet pblica, DMZ (http://es.wikipedia.org/wiki/Zona_desmilitarizada_(inform%C3%A1tica)) o
entorno privado o de servicios. Todo esto sin necesidad de tener varios dispositivos de red fsicos
para cada una de las redes

Una vez creado el switch virtual, podemos configurarlo para nuestras necesidades, si cada una de
nuestras mquinas virtuales dispone de varios enlaces de red, puede ser necesario ampliar el
numero por defecto de puertos, de los 120 a 4088 teniendo en cuenta que cada puerto asignado
gastar recursos para su gestin, as que una buena opcin es calcular cuantas mquinas virtuales
vamos a tener por nodo y cuantos puertos vamos a utilizar dejando algunos para posibles puntas.
Hemos de ser conscientes que para realizar cambios en el nmero de puertos deberemos reiniciar el
nodo con que mejor decidir de forma conservadora para minimizar cambios en produccin.
Tenemos las opciones de seguridad, por ejemplo si permitimos puertos en modo promiscuo, es decir
que reciban paquetes que no van dirigidos a ellos, si las direcciones MAC (es.wikipedia.org/wiki
/Direcci%C3%B3n_MAC) pueden cambiar o si los equipos virtuales pueden enviar paquetes
falseando la MAC de origen.
Control de trfico, donde podemos limitar para todos los puertos el ancho de banda que pueden
utilizar y de esta forma asegurar que ninguno de ellos supere los lmites establecidos o las opciones
que nos ayudaran a definir qu uso se les da a varios puertos de red vinculados al mismo switch
virtual. Poltica de balanceo en base a puerto virtual de origen o destino, direcciones IP del paquete
o sistema activo/pasivo donde solo se usar el puerto pasivo si el activo no est en un estado
funcional.
Switches Distribuidos

Los switches distribuidos solo estn disponibles en nodos vinculados a un vCenter Server y licencia
Enterprise. Este tipo de switch facilita en gran medida la gestin de la red en entornos relativamente
grandes ya que nos evita tener que crear en cada nodo las redes, asignarles los mismos nombres y
configuraciones, etc para que se puedan mover las mquinas virtuales entre los nodos sin
problemas.

Cuando creamos un switch virtual distribuido, lo creamos a nivel de Datacenter, el sinnimo para
vSphere del clster o grupo de nodos con configuracin equivalente y donde se pueden mover las
mquinas con total libertad.
Le damos el nombre que estimemos oportuno, definimos la compatibilidad entre versiones, ya que si
tenemos nodos vSphere 4.1 y nodos vSphere 5.0 deberemos indicar el modo de compatibilidad de
4.1, el nmero mximo de puertos de subida (uplinks) por nodo, luego asignamos los nodos que
pertenecern a ese switch y qu puertos fsicos de ese nodo estarn vinculados al mismo.
Una vez hecho esto, asignamos los diferentes grupos de puertos (Port Group) que se comportarn
como varios segmentos de red. Todos los equipos virtuales asignados al mismo grupo de puertos se
podrn comunicar sin tener que pasar por un equipo enrutador de nivel 3.
La gran ventaja de los switches distribuidos es que no solo podemos utilizar el propio de Vmware
sino tambin basarse en lgica de otros fabricantes como por ejemplo Cisco con su Nexus 1000V.
De esta forma, se puede gestionar la parte de la red del entorno virtualizado con las mismas
herramientas y muchas de las funcionalidades y ventajas que la gestin de red en el entorno fsico.

3.3 Buenas prcticas en redes

La buena prctica ms importante es asegurarse mediante los medios ms adecuados a
nuestras necesidades que en todos los nodos donde se pueda alojar una mquina virtual
cualquiera tengan la configuracin de red lo ms idntica posible, tanto en lo que respecta a
nmero, tipo y nombre de los switchs virtuales, como de los enlaces hasta la red fsica.
El hecho que se llamen igual y tengan los mismos tipos nos permitir que las mquinas se
puedan ejecutar en esa mquina y que adems se permita la migracin de las mismas. Este
ltimo punto, habilitar una de las funciones ms interesantes de un clster vSphere, la
recuperacin rpida ante fallos y el balanceo de carga.
Otra buena prctica que nos evitar problemas de rendimiento y disponibilidad, es dedicar
algunos enlaces a la red VMkernel, de forma que cuando se est realizando un o varios
vMotions, sincronizando dos mquinas virtuales mediante FT (Fault Tolerance) o comunicaciones
de gestin del propio vSphere.
Y para asegurar que mantenemos el mximo de disponibilidad posible, cada uno de nuestros
nodos debera estar conectado por lo menos a dos switches fsicos para tolerar la cada de uno
de ellos. Debemos tener en cuenta que un nodo de virtualizacin normalmente es mucho ms
crtico que otra mquina no virtualizada, por el simple hecho que en un nodo de virtualizacin
podemos tener decenas de mquinas virtuales y aunque cada una de ellas no sea ms crtica
que las no virtualizadas, la suma de todas ellas puede afectar ms al negocio que la cada de
una de las otras.
Tener en cuenta que podemos aadir y quitar dispositivos de red fsicos asignados a un vSwitch
sin problemas, pero si los quitamos todos o todos los asignados se quedan sin conectividad,
entre las mquinas virtuales del mismo nodo asignadas al mismo grupo de puertos o red se
podrn comunicar, pero no lo podrn hacer con el exterior.
Para proteger las mquinas virtuales ms crticas, se recomienda instalar cortafuegos en el
propio entorno virtual de forma que no se pueda acceder a estas mquinas desde el entorno
fsico sin pasar por el cortafuegos. Adems si no es necesario que este grupo de mquinas se
comuniquen con el exterior podemos vincularlas nicamente a redes sin ningn enlace (uplink)
En las mquinas donde sea posible, para maximizar el rendimiento utilizar como tipo de
adaptador de red VMXnet3
En las mquinas con VMXnet3 es interesante activar la descarga de la gestin de los segmentos
TCP al procesador de la tarjeta de red. Esta funcin hace que sea la propia tarjeta de red fsica
del nodo la que compruebe que los paquetes llegan en orden y de forma correcta, de manera
que el sistema operativo y por tanto el procesador de la mquina virtual no deben realizar esta
tarea, mejorando latencias y rendimientos
En caso de modificar los tamaos mximos de transmisin (MTU), nos debemos asegurar que
por lo menos todos los adaptadores, enlaces y switches vinculados a las redes VMkernel tienen
exactamente el mismo valor, ya que sino nos podemos encontrar con problemas intermitentes
dentro del clster que sern difciles de diagnosticar y solucionar.

ESXi proporciona una abstraccin del almacenamiento de forma que las mquinas virtuales alojadas en el
nodo ESXi no tienen por qu conocer que tipo de almacenamiento fsico existe en realidad
Una mquina virtual basada en ESXi utiliza un disco virtual para almacenar su sistema operativo, archivos
de programa y otros datos asociados con su funcionalidad. Un disco virtual es un gran fichero o un
conjunto de ficheros fsicos ms pequeos que se pueden copiar, mover o archivar y de los que se puede
realizar una copia de seguridad de forma fcil. Se puede configurar una mquina virtual de forma que
contenga ms de un disco virtual sin problemas.
Para acceder a los discos virtuales, las mquinas virtuales usan controladores SCSI virtuales. Estos
controladores emulan a:
BusLogic Parallel SCSI
LSI Logic Parallel SCSI
LSI Logic SAS
Vmware Paravirtual
Estos controladores son los nicos que una mquina virtual puede ver y acceder.
Cada uno de los discos virtuales que una mquina virtual puede acceder a travs de uno de los
controladores virtuales SCSI, reside en un datastore o almacenamiento basado en el Sistema de Ficheros
de Mquinas Virtuales de vSphere (VMFS), en un datastore basado en NFS o en disco directo o tambin
llamado modo raw (crudo).
Desde el punto de vista de la mquina virtual, cada disco parece que est conectado a travs de un
controlador SCSI, tanto da si el disco fsico est siendo accedido mediante SATA, SCSI, iSCSI, NFS o
Fibre Channel, y por tanto es completamente transparente para el sistema operativo alojados y sus
aplicaciones

4.2 Adaptadores de almacenamiento soportados

Los adaptadores de almacenamiento proporcionan conectividad para nuestro nodo ESXi contra
unidades de almacenamiento o servicios en red (NFS) especficos.
ESXi soporta diferentes tipos de adaptadores de almacenamiento, incluyendo SCSI, iSCSI, RAID,
Fibre Channel, Fibre Channel sobre Ethernet (FCoE) y Ethernet. ESXi accede a los adaptadores
directamente mediante los controladores de dispositivos en el VMkernel, por tanto, debemos validar
que nuestros adaptadores de almacenamiento son soportados por ESXi o que por lo menos existen
controladores para l.
Dependiendo del tipo de almacenamiento que usemos deberemos activar y configurar el adaptador
en cada nodo. Si usamos adaptadores basados en software de FCoE o iSCSI deberemos crear el
adaptador o iniciador y definirle los objetivos
Conexin a un datastore NFS
El primer paso para conectarnos por NFS contra algn almacenamiento compatible, es asegurarnos
que tenemos permisos en ese servidor
En Configuration->Storage seleccionamos Add Storage

Escogemos NFS y se nos pregunta por el servidor NFS, el nombre de la carpeta que queremos usar
y un nombre para drselo al datastore

Finish y ya tenemos un datastore basado en NFS para alojar nuestras mquinas virtuales

3 de 3

27/04/2014 18:30

El proceso de gestin de almacenamiento de ESXi arranca con el espacio de almacenamiento que nuestro
administrador de almacenamiento nos asigna en los diferentes sistemas.
ESXi soporta los siguientes tipos de almacenamiento
Almacenamiento Local: Almacena los ficheros de nuestras mquinas virtuales en almacenamiento
interno del nodo o directamente conectado a l
Almacenamiento en Red: Se almacenan los ficheros de las mquinas virtuales en discos o cabinas
conectadas a nuestro nodo ESXi mediante una red de alta velocidad

Almacenamiento Local
El almacenamiento local pueden ser o discos internos ubicados dentro de nuestro nodo ESXi o bien discos
en dispositivos externos conectados directamente con nuestro nodo mediante protocolos SAS o SATA.
El almacenamiento local no requiere de una red para comunicarse con nuestro nodo. Necesitamos un
cable conectado a la unidad de almacenamiento y cuando sea necesario una controladora compatible en
nuestro nodo.
La siguiente ilustracin muestra una mquina virtual utilizando un almacenamiento SCSI local

En este ejemplo de topologa de almacenamiento local, el nodo utiliza una sola conexin hasta el disco de
almacenamiento. En ese disco podemos crear una datastore VMFS, que podemos utilizar para almacenar
los ficheros de los discos de nuestras mquinas virtuales
Aunque este tipo de configuracin es posible, no es una topologa recomendada. Utilizando una sola
conexin entre el almacenamiento y los nodos, crea puntos nicos de fallo que pueden causar
interrupciones cuando una conexin tiene problemas.
ESXi soporta una gran variedad de dispositivos de almacenamiento interno, incluyendo SCSI, IDE, SATA,
USB y SAS. Independientemente del tipo de almacenamiento usado, nuestro nodo oculta la capa fsica de
almacenamiento a nuestras mquinas virtuales
El almacenamiento local no soporta comparticin entre varios nodos. Ya que la mayora de
almacenamiento local no permite mltiples conexiones, no se pueden utilizar mltiples caminos de acceso
al almacenamiento

4.4 Almacenamiento en red

El almacenamiento en red consiste de sistemas de almacenamiento externo que nuestro nodo
ESXi utiliza para almacenar remotamente ficheros de mquina virtual. Normalmente, los nodos
acceden a estos sistemas mediante redes de alta velocidad.
El almacenamiento en red es compartido, y por tanto los datastores en dispositivos de
almacenamiento en red pueden ser accedidos por mltiples nodos a la vez. ESXi soporta los
siguientes sistemas de almacenamiento en red.
Fibre Channel (FC)
Almacena las mquinas virtuales remotamente en una red de rea de almacenamiento (SAN) FC.
Una SAN FC es una red de alta velocidad especfica para conectar los nodos a dispositivos de
almacenamiento de alto rendimiento. La red utiliza el protocolo Fibre Channel para transportar
trfico SCSI de las mquinas virtuales a los dispositivos de la FC SAN.
Para conectarse a una FC SAN, nuestro nodo debe disponer de un adaptador de bus para nodo
de tipo Fibre Channel (HBA, Host bust adapter). A no ser que usemos conexiones directas a los
dispositivos FC, necesitaremos de switches FC para enrutar nuestro trfico de almacenamiento.
Si en nuestro nodo disponemos de adaptadores FCoE( Fibre Channel sobre Ethernet),
podremos conectarnos a nuestros dispositivos FC compartidos mediante una red Ethernet

En esta configuracin, un nodo conecta a una estructura SAN, que consiste de switches FC y
cabinas de almacenamiento utilizando un adaptador FC. Las unidades lgicas (LUNs) de la
cabina aparecen disponibles al nodo. Podemos acceder a la LUN y crear datastores para
nuestras necesidades de almacenamiento. Los datastores utilizan el formato VMFS
Internet SCSI (iSCSI)
Almacena los ficheros de las mquinas virtuales en dispositivos remotos basados en iSCSI. iSCSI
empaqueta el trfico SCSI de almacenamiento en el protocolo TCP/IP de forma que puede viajar
por una red estndar TCP/IP en lugar de tener que hacerlo por una red especializada basada en
FC.

Con una conexin iSCSI, nuestro nodo hace de iniciador de una comunicacin con el objetivo
(target), ubicado en un almacenamiento remoto iSCSI.
ESXi proporciona dos tipos de conexiones iSCSI
Hardware iSCSI: Donde nuestro nodo se conecta al almacenamiento mediante un adaptador
capaz de procesar gran parte del protocolo iSCSI, descargando por tanto el procesador de
nuestro nodo
Software iSCSI: Nuestro nodo utiliza un iniciador iSCSI basado en software en el VMkernel para
conectarse al almacenamiento. Con este tipo de conexin iSCSI, solo necesitamos un adaptador
estndar de red.
Independientemente del tipo de conexin que utilicemos, debemos configurar los iniciadores en
el nodo para que se pueda acceder a las LUNs y crear los datastores

En el ejemplo de la izquierda, el nodo utiliza un adaptador iSCSI hardware para conectarse con
el sistema de almacenamiento iSCSI. En el caso de la de derecha, el nodo utiliza un adaptador
de software iSCSI y una tarjeta de red Ethernet para conectarse al almacenamiento iSCSI.
De esta manera los dispositivos de almacenamiento iSCSI del sistema de almacenamiento se
hacen disponibles en el nodo y ya los podemos configurar como almacenamiento VMFS
Almacenamiento en Red (NAS)
Almacena los ficheros de mquina virtual en servidores accesibles mediante una red TCP/IP
estndar. ESXi incluye un cliente NFS que soporta el protocolo Network File System (NFS)
versin 3 para comunicarse con servidores NAS/NFS.
Para lo conectividad de red, el nodo solo requiere de una tarjeta de red estndar.

En este caso nuestro datastore no tendr el sistema de ficheros VMFS, sino que al utilizar el
protocolo NFS, se nos abstrae del sistema de ficheros subyacente

4.5 Configuracin de un datastore iSCSI

Un datastore o almacn de datos es donde vSphere ESXi almacena los datos de las mquinas
virtuales, su configuracin, registros asociados a las mquinas para identificar problemas y otros
ficheros para el uso de varios de los elementos que componen el clster, por ejemplo para indicar
qu nodo es el propietario de la mquina.
Lo primero que debemos hacer, es decidir qu tipo de almacenamiento vamos a utilizar. Si sabemos
que vamos a montar un clster, podemos descartar el almacenamiento local desde buen inicio, si
por el contrario las mquinas virtuales de ese nodo NUNCA se movern de ese nodo, un
almacenamiento local nos reducir la complejidad y coste del entorno
Vamos a suponer que necesitamos almacenamiento remoto, ya que as podremos aprovechar todas
las ventajas que tienen vSphere respecto a su competencia.
As pues nos toca decidir si Fibre Channel, NFS o iSCSI. A nivel de protocolo todos dan ms o
menos el mismo rendimiento si el sistema de almacenamiento tiene caractersticas similares, no tiene
sentido comparar discos de estado slido con disco SATA de 4200 rpm. As que lo decidiremos en
base a la capacidad de inversin, sinergias que podamos tener con el resto de servicios o
funcionalidades que se nos faciliten por el protocolo. Aqu tiene sentido hablar con el responsable de
almacenamiento de la compaa y que nos aconseje en base a la infraestructura instalada.
Decidido el almacenamiento, vamos a configurarlo. Los pasos que vamos a mostrar son muy
parecidos en todos los casos. Aadimos o usamos un adaptador que soporte el protocolo, se
accede, se le da formato en el sistema de ficheros VMFS, la versin 3 si tenemos en el clster nodos
con versiones ESX 3.5 o 4.x o versin 5 si solo tenemos nodos con ESXi 5.0. Una vez creado el
datastore ya podemos crear o mover mquinas virtuales al nuevo almacenamiento.
Los pasos para iSCSI son los siguientes:
Aadimos un adaptador iSCSI desde storage adapters

Lo vinculamos a algn interfaz VMkernel

Le indicamos donde tenemos el sistema de almacenamiento y si es necesario le informamos de

usuario y contrasea para el acceso mediante el botn CHAP

Volvemos a buscar si hay nuevos discos disponibles

Se nos indica que en el adaptador que hemos creado, tenemos en nuestro caso un volumen (LUN)
disponible

Ahora en la opcin Storage vamos a aadir un disco o LUN (descripcin en es.wikipedia.org/wiki

/Logical_unit_number). Se nos da la opcin tambin de NFS ya que el adaptador NFS va incluido de
serie con ESXi y no se le da formato al volumen

Seleccionamos el disco que nos interesa

Decidimos el tipo de sistema de ficheros

Creamos particiones, damos nombre y decidimos espacio a utilizar y revisamos que todo est
correcto

Esperamos a que termine y ya tenemos el datastore creado. Ya podemos aadir o mover mquinas
a este nuevo datastore

5.1 Gestin y tipos de recursos

Gestin de recursos:
Para entender la gestin de recursos, debemos ser conscientes de sus componentes, sus objetivos y
cual es la mejor forma de implementarla en la configuracin del clster.
Hablaremos de como la asignacin de recursos para una mquina virtual (peso, reserva y lmites) puede
ser configurada y como ver sus valores. Tambin hablaremos del proceso de control de admisin,
mediante el cual la configuracin es validada teniendo en cuenta los recursos existentes.
La gestin de recursos es la asignacin de recursos desde los proveedores de recursos a los
consumidores de los mismos. La necesidad de una gestin de recursos surge de la sobreasignacin de
los mismos, es decir, ms demanda que capacidad y del hecho que la capacidad puede ir variando
durante el tiempo. La gestin de recursos nos permite reasignar recursos de forma dinmica de manera
que podemos utilizar eficientemente la capacidad disponible
Tipos de recursos
Los recursos que podemos gestionar son todos lo que vSphere nos permite compartir, por ejemplo, la
CPU, memoria, potencia (elctrica), almacenamiento y red.
De esta forma podemos decidir qu parmetros son los ms importantes en cada caso, si nos interesa
una eficiencia de consumo elctrico avanzada en lugar de maximizar el rendimiento, si queremos
asegurar que una mquina concreta tenga los recursos de red y almacenamiento necesarios para
ofrecer su servicio de forma adecuada o si nos queremos asegura que un mquina que ofrece un
servicio poco importante no consuma demasiados recursos del clster afectando a otras mquinas
alojadas en l.
Proveedores de Recursos.
Los nodos y los clsteres, incluyendo los clsteres de almacenamiento, son los proveedores de
recursos fsicos.
Para los nodos, los recursos disponibles son las especificaciones de hardware del mismo menos los
recursos utilizados por el software de virtualizacin, en nuestro caso ESXi.
Un clster es un grupo de nodos. Podemos crear un clster utilizando vSphere Client, y aadir
mltiples nodos al clster, vCenter Server gestiona los recursos de esos nodos de forma conjunta, el
clster tiene asignados todos los recursos de CPU y memoria de todos los nodos.
Podemos habilitar un sistema de balanceo de carga y alta disponibilidad global en todo el clster,
habilitando las funcionalidades de DRS (Distributed Resource Scheduler) y HA (High Availability)
permitidas en algunas licencias de vSphere
Consumidores de recursos:
Las mquinas virtuales son los consumidores de recursos. La configuracin por defecto de los recursos
que se establece durante la creacin de la mquina virtual funciona correctamente para la mayora de
mquinas. Pero posteriormente podemos editar los parmetros para asignar un porcentaje de la CPU
total, memoria, y Entrada/Salida de almacenamiento del proveedor de recursos o garantizar una reserva
de CPU y memoria. Cuando encendemos esa mquina virtual, el nodo comprueba si existen suficientes
recursos no reservados y en caso que los haya permite la activacin de la mquina virtual. Este proceso
se llama Control de Admisin.
Un grupo de recursos es una abstraccin lgica para la gestin flexible de los recursos. Los grupos de
recursos (Resource Pools) se pueden agrupar en jerarquas y ser usados para particionar
jerrquicamente los recursos disponibles de CPU y memoria. De acuerdo con esto, los grupos de
recursos se pueden considerar a la vez, consumidores y proveedores de recursos. Proveen recursos a
los grupos de recursos inferiores en la jerarqua y las mquinas virtuales, pero a la vez consumen
recursos de los grupos de recursos de jerarqua superior y en ltimo termino del clster o del nodo.

Aunque a nivel grfico puede parecer que podemos utilizar los grupos de recursos para ordenar
nuestras mquinas virtuales, solo los debemos utilizar para realizar gestin de recursos, ya que si los
utilizamos como carpetas podemos generar problemas de falta de rendimiento en mquinas crticas y
exceso de recursos en otras no tan importantes.

Los nodos ESXi asignan a cada mquina virtual una porcin de sus recursos de hardware en base a los
siguientes factores:
Recursos disponibles totales para el nodo ESXi o el clster
Nmero de mquinas virtuales arrancadas y los recursos usados por estas
Sobrecoste requerido para la gestin de la virtualizacin

Lmites de recursos definidos por el administrador

Objetivos de la gestin de recursos

Cuando nos podemos a gestionar los recursos, debemos ser conscientes de cuales son nuestros
objetivos.
Adicionalmente a resolver problemas de sobreasignacin de recursos, la gestin de recursos nos puede
ayudar a cumplir lo siguiente
Aislamiento de rendimiento: Evitar que algunas mquinas virtuales monopolicen recursos y garantizar
unos niveles de servicio predecibles
Utilizacin eficiente: Aprovechar recursos sobrantes y sobreasignar recursos con una degradacin
adecuada. Es decir que si estamos en un estado de sobreasignacin, el rendimiento y los recursos
asignados nos permiten cumplir o estar muy cerca de los niveles de servicios acordados (SLA)
Facilitar la administracin: Al controlar la importancia relativa de las mquinas virtuales, permitir un
particionamiento dinmico que nos permita cumplir los niveles de servicio

5.2 Cmo configurar la gestin de recursos

Cuando los recursos disponibles en el clster no cubren las demandas de los consumidores de
recursos (y del sobrecoste de la virtualizacin), los administradores quiz deberan modificar la
cantidad de recursos asignados a cada mquina virtual o a los grupos de recursos donde
residen.
Usaremos los parmetros de asignacin de recursos (cuota, reserva y lmite) para determinar la
cantidad de CPU, memoria y recursos de almacenamiento provedos a cada mquina virtual. En
particular tenemos varias opciones para asignar recursos
Reservar los recursos fsicos del nodo o clster
Asegurarse que por lo menos una parte de la memoria de mquina virtual es proveda por la
memoria fsica del nodo ESXi
Garantizar que una mquina virtual especifica siempre dispone de un porcentaje superior de
recursos fsicos que otras mquinas virtuales
Definir un lmite superior de los recursos que pueden ser asignados a una mquina virtual
Cuotas de asignacin de recursos
Las cuotas (shares) definen la relativa importancia de una mquina virtual (o grupo de recursos).
Si una mquina virtual tiene el doble de cuota que otra mquina virtual, tiene derecho a consumir
como mucho el doble de aquel recurso cuando esas dos mquinas virtuales estn compitiendo
por los recursos.
Las cuotas normalmente se especifican como High, Normal o Low (Alta, Normal o Baja), que
especifican una relacin 4:2:1 respectivamente. Adems, podemos seleccionar Custom
(personalizada) para asignar un nmero especfico de cuota, el cual expresa un peso
proporcional, a cada mquina virtual.
Especificar cuotas tiene sentido solo en mquinas virtuales o grupos de recursos del mismo
nivel, es decir, mquinas virtuales y grupos de recursos que comparten el mismo ancestro en la
jerarqua de asignacin de recursos. Estos consumidores de recursos del mismo nivel,
comparten recursos de acuerdo a su relativo peso en base a cuotas con el lmite inferior de la
reserva y el supero del lmite. Cuando asignamos cuotas a una mquina virtual, siempre
especificamos la prioridad de esa mquina virtual con relacin al resto de otras mquinas
virtuales que estn encendidas.
Por defecto, cada vCPU asignada a una mquina virtual, le asigna 1000 shares de CPU si
estamos con prioridad normal, 500 si en baja y 2000 en alta. Por la parte de la memoria, tenemos
10 shares por cada MB de RAM asignado, 20 si estamos en modo alto y 5 en modo de baja
prioridad.
As que una mquina con dos vCPUs y 16GB de memoria tendr 1000*2=2000 shares de CPU y
16384*10=163840 shares de memoria en estado normal.
La prioridad relativa representada por cada share se modifica cuando una nueva mquina virtual
es encendida, esto afecta a todas las mquinas que estn dentro del mismo grupo de recursos.
Vamos a suponer que todas las mquinas virtuales tienen el mismo nmero de vCPUs.
Dos mquinas virtuales limitadas por CPU (consumimos toda la CPU disponible) corren en un
nodo con 8Ghz de capacidad total. Al tener las dos el mismo nivel de shares, Normal, cada una
recibe 4Ghz
Una tercera mquina es encendida y tiene especificado que los shares de CPU son de tipo Alto,
por lo que debera tener el doble de lo otorgado a las mquinas Normal. La nueva mquina
recibe 4Ghz y las otras dos mquinas se les reduce la capacidad hasta 2Ghz cada una.
Reserva de recursos
Una reserva especifica una garanta mnima de recursos para una mquina virtual.

El vCenter Server o el propio ESXi permite arrancar una mquina solo si dispone de suficientes
recursos no reservados para cumplir la reserva indicada en los parmetros de la mquina virtual.
El nodo garantiza que esa capacidad estar disponible aun y cuando el nodo est muy cargado.
La reserva se expresa en unidades concretas (megahercios o megabytes).
Por ejemplo, imaginemos que tenemos 2GHz disponibles y especificamos una reserva de 1Ghz
para la MV1 y otro 1Ghz para MV2. Ahora cada mquina le garantizamos 1Ghz en caso que lo
necesite pero si en un momento dado MV1 solo est usando 500 Mhz, MV2 podra estar usando
1.5Ghz
La reserva por defecto es de 0, y podemos especificar un valor en caso de necesitar garantizar
ese mnimo de CPU o memoria para cada mquina virtual
Lmite en la asignacin de recursos
El lmite define un umbral superior para los recursos de CPU, memoria o E/S de almacenamiento
que pueden ser asignados a una mquina virtual.
Un nodo puede asignar ms que la reserva definida a una mquina virtual, pero nunca asigna
ms del lmite aunque existan recursos ociosos en el sistema. El lmite tambin se expresa en
unidades concretas (megahercio, megabyte o operaciones E/S por segundo).
Los lmites por defecto son ilimitados. Cuando el lmite de memoria es ilimitado, la cantidad de
memoria configurada para la mquina virtual se convierte en el lmite efectivo.
En la mayora de los casos no es necesario especificar ningn lmite, pero como todo, tiene
beneficios e inconvenientes:
Beneficios: Asignar un limite es til si empezamos un nmero pequeo de mquinas virtuales y
queremos gestionar las expectativas de los usuarios. Ya que el rendimiento se deteriora
conforme vayamos activando ms mquinas virtuales en nuestro sistema, podemos simular
disponer de menos recursos disponibles asignando lmites
Inconvenientes: Podemos malgastar recursos ociosos si especificamos el lmite. El sistema no
permitir utilizar ms recursos que el lmite aun y cuando el sistema est infrautilizado.
Especificaremos un lmite solo cuando tengamos buenas razones para hacerlo.
Recomendaciones en la asignacin de recursos
Vamos a seleccionar lo parmetros de asignacin de recursos (cuotas, reservas y lmites) que
sean apropiados para nuestro entorno vSphere:
Si esperamos cambios frecuentes en el total de recursos disponibles, utilizar la funcionalidad de
cuotas para asignar los recursos de razonable entre las mquinas virtuales. Si usamos cuotas y
mejoramos el nodo (ms Ram, ms CPUs), cada mquina seguir estando en la misma
prioridad, aunque ahora cada cuota representa un valor ms grande de CPU, memoria o E/S
Utilizaremos reserva para especificar el mnimo aceptable de CPU o memoria, no la cantidad que
queremos que est disponible. El nodo asigna recursos adicionales como disponibles en base a
las cuotas, la demanda estimada y los lmites definidos por cada mquina virtual. La cantidad de
recursos concretos (Mhz o MB) no se modifica cuando cambia el entorno, ya sea parando o
arrancando nuevas mquinas virtuales o modificando el tipo o nmero de nodos en el clster
Cuando especifiquemos las reservas de las mquinas virtuales, no asignemos todos los recursos
disponibles, dejemos al menos un 10% no reservado. Cuanto ms cerca estemos de reservar
completamente toda la capacidad del sistema, ms complicado es realizar modificaciones a las
reservas y a la jerarqua de grupos de recursos sin violar el control de admisin. Si nuestro
clster tiene activada la funcionalidad de balanceo de carga (DRS), las reservas pueden
completar toda la capacidad del clster o de los nodos individuales de forma que DRS no pueda
realizar su trabajo de forma eficiente

5.3 Control de admisin

Cuando activamos una mquina virtual, el sistema comprueba la cantidad de CPU y memoria
que todava no se han reservado. En base a esta capacidad de recursos no reservados, el
sistema determina si puede garantizar la reserva que tiene asignada esa mquina virtual, en caso
que la tenga. Este proceso se llama Control de Admisin.
Si existen suficientes recursos no reservados de CPU y memoria, o si no hay ninguna reserva, la
mquina virtual es encendida, en caso que no sea as, se genera una alerta de Recursos
Insuficientes o Insufficient Resources.
A parte de la posible memoria reservada por parte del administrador, para cada mquina virtual
tenemos una cantidad de memoria que es el sobrecoste de la virtualizacin. Esta depender del
nmero de vCPUs asignadas, emulacin de la tarjeta de vdeo, dispositivos y cantidad total de
memoria.
sta memoria tambin se tiene en cuenta al realizar los clculos para el control de admisin.
Cuando tambin tenemos activada la funcionalidad DPM (Distributed Power Management),
algunos nodos pueden se puestos en modo de pausa (es decir, parados, standby) para reducir
el consumo elctrico. Los recursos no reservados proporcionados por estos nodos son
considerados disponibles por el control de admisin. Por tanto si una mquina virtual no puede
ser encendida por falta de recursos, se har una recomendacin para activar alguno de los
nodos en pausa y dependiendo del grado de automatizacin, se les dar la orden de encendido
al nmero de nodos requerido para cubrir las necesidades de recursos.