Vous êtes sur la page 1sur 76

Tema 5 - Virtual Networking, vSwitch

Virtual Networking – VMkernels, Portgroups, vSwitches

En este quinto capítulo de nuestro curso de VMware para la certificacion VCP vamos a configurar
nuestros hosts ESXi, aprendiendo lo que son los VMkernels, vSphere Standard vSwitch, vSphere
Distributed vSwitch y configurando los VMkernels necesarios para vMotion, Fault Tolerance y VSAN,
funcionalidades que veremos en posteriores capítulos.

Configurar la red en VMware vSphere

La base principal de la comunicación en VMware pase por los vSwitches. Disponemos de dos tipos de
vSwitches que veremos a continuación.

vSphere Standard vSwitches

Los Switches Standard de vSphere son una entidad propia de cada host vSphere y se utilizan para
comunicar las máquinas virtuales con el exterior utilizando los adaptadores de red físicos del host. Un
vSphere Standard vSwitch (VSS a partir de ahora) se compone de physical adapters (mínimo 0) y
permite conectar a el dos tipos de objetos. Portgroups y VMkernels.

vSphere Distributed vSwitches

Los Switches Distribuidos de vSphere (Distributed vSwitch o DVS). Los Distributed Virtual Switch
permiten simplificar enormemente la gestión y configuración de redes en un entorno con varios hosts
ESXi. Para configurarlos, se crea el DVS y se asignan las tarjetas de red que queramos de una serie de
hosts. Automágicamente, se creará un switch en todos esos hosts que compartirá siempre la misma
configuración, eliminando posibilidades de error por la creación manual de puertos, etc. DVS tiene
ventajas añadidas como la creación de puertos LACP, Monitorización por Netflow de los puertos de las
máquinas virtuales, pero sinceramente para mí la mayor ventaja es la facilidad de administración y
comodidad a la hora de añadir hosts nuevos a tu infraestructura. DVS está disponible solo con el
licenciamiento VSAN y Enterprise Plus.

Virtual Machine Portgroups

Son objetos que tienen como misión proporcionar conectividad entre las máquinas virtuales de un host y
los vSwitches configurados en ese host. Un Porgroup puede ser Standard o Distribuido. En un Virtual
Machine Portgroup podemos configurar VLANs, reglas de seguridad, Traffic Shaping y NIC Teaming

VLANs

Sirven para etiquetar el tráfico de red con una marca especial que hace que solo sea visible para las
máquinas virtuales conectadas a ese portgroup o a otras que tengan configurada esa VLAN. Las VLANs
pueden quedarse dentro del ámbito de los vSwitches o propagarse más arriba a través de los switches
físicos de la capa de electrónica de red si se configuran estas VLANs en ellos.

Security

Podemos configurar las siguientes reglas de seguridad de forma individual en cada Virtual Machine
Portgroup
 Promiscuous Mode (aceptar / rechazar)
Al activar esta opción permitimos que una máquina virtual conectada a este Virtual Machine Porgroup
pueda poner su interfaz de red en modo promíscuo, capturando todos los paquetes de red que lleguen a
ese Virtual Machine Porgroup en particular. Puede ser util para la resolución de problemas o la
instalación de un sistema de detección de intrusiones (IDS).
 MAC Address Changes (aceptar / rechazar)
Al activar esta opción, permitiremos que las máquinas virtuales de dentro del Virtual Machine Portgroup
cambien su dirección mac desde alguna aplicación o el propio sistema operativo. Puede sernos util a la
hora de montar un bonding / teaming en un equipo.
 Forged Transmits (aceptar / rechazar)
Al activar esta opción estaremos permitiendo que de la máquina virtual salgan paquetes marcados con
una dirección MAC de origen diferente a la que tiene asignada esa máquina virtual. Yo solo he tenido
que hacer esto a la hora de realizar simulaciones para resolución de problemas.

Traffic Shaping

Nos permite limitar el ancho de banda que puede consumir este Virtual Machine PortGroup de tres
maneras diferentes:

 Average Bandwidth
Es el ancho de banda medio que permitimos que fluya por este Virtual Machine Port Group, medido en
kilobits por segundo.
 Peak Bandwidth
El ancho de banda máximo que permitimos que alcance este Virtual Machine Port Group en cualquier
momento, medido en kilobits por segundo.
 Burst Size
La cantidad de kilobytes que permitimos un pico de tráfico antes de penalizar el ancho de banda
aplicando el traffic shaping. Este parámetro se aplica siempre que no se haya superado el ancho de
banda medio establecido en la primera limitación y puede llegar hasta el valor de Peak Bandwidh
siempre y cuando haya ancho de banda disponible en el interfaz.

NIC Teaming

En el menú de configuración de NIC Teaming dentro de un Virtual Machine Portgroup nos encontramos
con dos bloques de opciones configurables:

Policy Exceptions

 Load Balancing – Nos permite establecer opciones de balanceo de carga entre dos o más tarjetas de red
físicas.
o Route based on the originating virtual port ID
Balanceará la carga tomando como parámetro el puerto virtual al que se conecta la VM dentro
del Virtual Machine PortGroup. Tomemos el siguiente ejemplo:
 Tenemos VM1 con identificador en el inventario de su puerto de red 001, VM2 con
identificador 002, VM3 con identificador 003. Si tenemos 2 tarjetas de red, comenzará
asignando el tráfico de VM1 por la NIC1, el de VM2 por la NIC2, el de la VM3 por la NIC3,
por ejemplo. Los ID de los puertos no siempre son correlativos, pero el balanceo de
carga debería ser siempre estable en lo que se refiere a VM – NIC física. Es similar al
siguiente pero se controla mejor por donde va el tráfico de cada máquina virtual.
o Route based on IP hash – Este balanceo de carga tomará los parámetros de dirección IP de
origen y dirección IP de destino para aplicarles un hash (una operación). Dependiendo de ese
resultado, enviará el tráfico por una tarjeta de red u otra. En este escenario (y siempre que haya
más de una dirección IP generando tráfico), el tráfico se enviará de forma activa por todas las
tarjetas de red incluso aunque solo haya una máquina virtual. Se suele utilizar para balancear el
ancho de banda en servidores capaces de saturar el ancho de banda de una única interfaz.
o Route based on source MAC hash – Este modo de balanceo tomará como factor de decisión la
dirección MAC de la tarjeta de red de la máquina virtual que envía el tráfico. Si una máquina
virtual tiene más de una tarjeta de red virtual conectada, podría enviarse el tráfico de forma
activa por más de un interfaz físico del host. En caso contrario, es similar al caso 1.
o Use Explicit failover order – En este modo de balanceo, especificamos en el bloque de opciones
2 (Failover Order) cuales van a ser las tarjetas de red físicas del host que van a usarse de forma
activa, mantenerse en espera para un caso de fallo, o directamente por que tarjeta de red física
no vamos a mandar nada de tráfico nunca.
 Network Failover Detection – Establece los métodos y criterios para detectar la caida de un interfaz de
red físico de un host ESXi.
o Link status only – La caida del enlace físico de la tarjeta de red del host ESXi es la que hace
considerar al host que no tiene conectividad y que debe hacer el cambio a la tarjeta de red de
StandBy (si la hubiera).
o Beacon probing – Es una modalidad de detección de problemas de red en la que podemos
detectar el mal funcionamiento de una tarjeta de red incluso si no pierde el enlace físico.
Funciona mediante el envío de paquetes de broadcast desde todas las tarjetas de red
pertenecientes a un mismo team (grupo de nics agregadas). El switch, al recibir estos paquetes,
está obligado a retransmitirlos a todos los puertos de red que tiene conectados. De esta forma,
si ESXi detecta que le faltan los broadcasts de una tarjeta de red la marcará como caida y
utilizará las demás. Este método de prueba está recomendado con al menos tres interfaces de
red dentro de un mismo team, para que ESXi pueda determinar que falla una de ellas (las otras
dos se ven entre sí, pero no ven a la tercera que se ha caido). Esta modalidad NO DEBE USARSE
cuando usamos balanceo mediante hash IP.
 Notify Switches – Si activamos esta opción, al hacer un failover de tarjeta de red (activar la secundaria
porque hemos perdido la primaria), ESXi enviará paquetes falsos supuestamente originados en las
máquinas virtuales que acaban de cambiar de tarjeta de red física, de manera que los switches
actualicen sus tablas ARP y acepten sin problemas el tráfico de esas máquinas virtuales en un nuevo
puerto físico.
 Failback – Con esta opción seleccionamos si queremos que una tarjeta de red, tras volver a considerarse
como activa (recuperar el link, por ejemplo) vuelva a entrar en funcionamiento de forma inmediata. Un
caso típico en el que podríamos querer tener esta opción a NO, es cuando estamos haciendo trabajos de
red en un switch y una de las NICS, conectada a este switch, va a estar flapeando (levantandose y
cayendose) durante un periodo de tiempo.

Failover Order

Nos permite configurar las interfaces físicas del vSwitch a las que se conecta el Virtual Machine
Portgroup para establecer uno de los siguientes escenarios:

 Activo-Activo
Todas las tarjetas de red que coloquemos en este grupo se considerarán activas y serán candidatas a
enviar tráfico de las máquinas virtuales en condiciones normales.
 Activo-StandBy
El tráfico se moverá solo por las tarjetas de red que coloquemos en el grupo Active y las que asignemos
al grupo StandBy quedarán disponibles para entrar en funcionamiento en caso de que haya un problema
de red que cause que las activas dejen de estar disponibles.
 Unused
Nos permitirá especificar tarjetas de red del vSwitch al que se conecta el Virtual Machine Porgroup que
deseamos dejar SIN USO de forma específica, porque queremos dedicarlas a otros menesteres, por
ejemplo.

Realiza este ejercicio solo si tienes más de una tarjeta de red en tu host. Si solo tienes una tarjeta
de red, tu host ESXi ya tendrá un Virtual Machine Portgroup que utilizaremos más adelante y
deberás obviar los ejercicios de Distributed Virtual Switch, adaptándolos a Standard Virtual
Switch (Creando vmkernels y Portgroups en tu único vSwitch0).

A continuación crearemos un Virtual Machine Portgroup en uno de los hosts que hemos añadido a
nuestro cluster del laboratorio del curso de VMware.

Seleccionaremos un Host en el inventario e iremos a Manage > Networking > Virtual Switches, para
hacer click en el botón de Add Networking, seleccionando Virtual Machine Port Group for a Standard
vSwitch

A continuación elegiremos crear un nuevo Standard vSwitch


Seleccionaremos las nics que queramos asignar a nuestro VSS
Las ordenamos en función de que queramos utilizarlas en modo activo, pasivo o dejarlas sin uso de
momento.

Continuamos el Asistente de creación poniendo un nombre al nuevo Virtual Machine Portgroup y


finalizamos.

Si hacemos click en el nuevo vSwitch que hemos creado, veremos las tres tarjetas de red que tiene
asignadas, las dos que tiene activas y la otra sin uso (de forma genérica para todo el vSwitch)
Ahora vamos a crear un segundo Portgroup en el vSwitch 1 y vamos a hacer que su tráfico vaya
solamente por la vmnic3, que hemos dejado sin uso en el Portgroup anterior.
Tras crear un nuevo Virtual Machine Portgroup y seleccionar vSwitch1 como el vSwitch al que vamos a
asignarlo, haremos click en su nombre y pulsaremos el botón de Editar
En la sección de configuración de Teaming and Failover, podemos hacer un override de la configuracion
por defecto del vSwitch 1 (que dice que por defecto todos los portgroups conectados a él usan la vmnic1
y vmnic2 de forma activa / activa) y seremos capaces de subir vmnic3 desde Unused adapters hasta
Active y bajar las otras dos a Unused.También aquí podremos cambiar las opciones de balanceo de
carga, detección de fallos, etc que explicabamos anteriormente. En el caso de este Virtual Machine
Portgroup no tiene mucho sentido ya que solo tiene la vmnic3 como punto de comunicación con el
exterior, así que de poco nos serviría el load balancing. Sin embargo si podríamos aplicarlo al penúltimo
portgroup que creamos, que sí tenía dos interfaces activas.

Elimina el vSwitch1 que acabamos de crear, seleccionándolo y pulsando el botón Remove Selected
Standard vSwitch.
Confirmamos la eliminación del vSwitch 1

VMkernels (VMK)

Los VMkernels son interfaces especiales que permiten la conectividad únicamente del HOST ESXi.
Se utilizan para diversas funciones, como administración, vMotion, Fault Tolerance, VSAN,
Replicación y Almacenamiento pero única y exclusivamente por parte del HOST ESXi.

Se pueden tener varios VMkernels por host ESXi, pero deberemos tener como mínimo para la
administración remota de ese host ESXi. Los VMkernels funcionan utilizando IP como protocolo de
comunicación, tanto ipv4 como ipv6, aunque existen algunas limitaciones al utilizar ipv6 en los
VMkernels.

Creación de un Distributed Virtual Switch (Switch Distribuido o DVS)

El resto de ejercicios del curso de VMware los realizaremos utilizando Distributed Virtual Switch, así
que vamos a crear un DVS con las tarjetas de red de que dispongamos en nuestro laboratorio. En mi
caso los hosts esxi tienen 7 tarjetas de red distribuidas de la siguiente forma:

 vmnic0 – Gestion, tráfico de VMs y Almacenamiento


 vmnic1 – vMotion
 vmnic2 – vMotion
 vmnic3 – Fault Tolerance
 vmnic4 – Fault Tolerance
 vmnic5 – VSAN
 vmnic6 – VSAN

Si dispones de solo dos tarjetas de red, te recomiendo agrupar por un lado vMotion, FT y VSAN y por
otro Gestión, Almacenamiento y Servicio.(lo óptimo es dejar almacenamiento apartado en una nic
propia, pero no en nuestro laboratorio del curso de vmware no vamos a mover barbaridades de tráfico,
así que nos servirá).

Para crear un Distributed Virtual Switch iremos en el vSphere Web Client a la pantalla principal Home y
elegiremos Networking

Haremos click derecho encima de nuestro Datacenter y elegiremos la opción de New Distributed
vSwitch
Elegimos un nombre para nuestro Distributed vSwitch. Este será el primero de tres Distributed
vSwitches que vamos a crear para vMotion, FT y VSAN.
Seleccionamos la versión 5.5.0 de Distributed vSwitch para disponer de todas las características que
aporta la última versión.
Seleccionamos 2 uplinks para nuestro Distributed vSwitch
Al finalizar el asistente podremos ver que aparece un nuevo elemento de red en nuestro inventario de
objetos de red, el Distributed vSwitch que vamos a dedicar a vMotion

Ahora vamos a agregar hosts a este Distributed vSwitch haciendo click derecho sobre él y pulsando Add
and Manage hosts
En el asistente, seleccionamos Add Hosts
Añadimos los hosts de nuestro laboratorio del curso de vmware pulsando en el botón New hosts
Seleccionamos Manage Physical Adapters para agregar a este Distributed vSwitch las tarjetas de red de
cada host correspondientes a este Distributed vSwitch
Seleccionamos los uplinks que queremos para este Distributed vSwitch y pulsamos el botón de Assign
uplink. En el caso de mi laboratorio, asignaré vmnic1 al uplink 1 y vmnic2 al uplink 2. Repetimos la
operación con el resto de hosts.
La siguiente ventana nos analizará el impacto que puede tener esta operación sobre puertos vmkernel ya
existentes. Como estamos migrando uplinks vacíos al Distributed vSwitch, no va a haber ningún
impacto.
Finalizamos el asistente.

El siguiente paso es crear un Distributed Port Group al que conectar los VMkernels de cada host ESXi
destinados a vMotion. Para completar esta tarea, haremos click derecho sobre el Distributed vSwitch y
seleccionaremos New Distributed Port Group.
Le daremos un nombre identificativo, en nuestro caso vMotion.

Dejamos las opciones que vienen por defecto salvo la VLAN si vamos a utilizar alguna en los puertos
directamente conectados. Si estás usando un ESXi anidado, te recomiendo que configures las opciones
avanzadas y permitas modo promíscuo, cambio de MAC y Forged Transmits.
Finalizamos el asistente.

Ahora vamos a crear los vmkernels destinados a gestionar el vMotion en los hosts del laboratorio del
curso de vmware. Para ello, iremos en el inventario a la pestaña de hosts, seleccionaremos cada uno de
los hosts, y en Manage > Networking, haremos click en Virtual Switches. Después seleccionaremos el
nuevo Distributed vSwitch llamado vMotion y haremos click en el botón de Add Host Networking.
Seleccionaremos Añadir VMkernel Network Adapter
Seleccionaremos el Distributed Port Group que acabamos de crear en el paso anterior.

En el siguiente paso, seleccionaremos tráfico de vMotion e IPv4


El siguiente apartado requiere que asignes direccionamiento IP propio de tu red. En mi red, la red de
vMotion es 192.168.2.x.

Finalizamos el asistente

Repetimos el paso de creación de VMkernel para los hosts esxi02 y esxi03.

Repetimos el proceso completo de creación de Distributed Virtual Switch para crear:

 Un nuevo Distributed vSwitch para FT (Fault Tolerance)


 Un nuevo Distributed vSwitch para VSAN
 Un nuevo Distributed Port Group para FT
 Un nuevo Distributed Port Group para VSAN
 Un nuevo VMkernel destinado a Fault Tolerance en cada host ESXi, creándolo en el su Distributed
vSwitch / Distributed Port Group correspondiente.
 Un nuevo VMkernel destinado a VSAN en cada host ESXi, creándolo en su Distributed vSwitch /
Distributed Port Group correspondiente.

Al final, tus distributed vSwitches deberán quedar como puedes ver en la imagen:

En la configuración de CADA HOST, deberíamos tener vmkernels configurados en cada uno de los
Distributed Port Groups como vemos en la imagen:
Existen formas de hacer tareas de las que hemos realizado anteriormente de forma combinada, como
crear un portgroup inicial a la hora de crear el Distributed vSwitch, o Crear VMkernels a la hora de
añadir hosts a un Distributed vSwitch. Practica por tu cuenta esas opciones.

Para futura referencia, en mi laboratorio estoy usando los siguientes direccionamientos ip en los 3 hosts:

esxi01

Gestion y almacenamiento 192.168.1.11

vMotion – 192.168.2.11

Fault Tolerance – 192.168.3.11

VSAN – 192.168.4.11
esxi02

Gestion y almacenamiento 192.168.1.12

vMotion – 192.168.2.12

Fault Tolerance – 192.168.3.12

VSAN – 192.168.4.12

esxi03

Gestion y almacenamiento 192.168.1.13

vMotion – 192.168.2.13

Fault Tolerance – 192.168.3.13

VSAN – 192.168.4.13

Para comprobar si la conectividad es correcta, podemos entrar en uno de los hosts por ssh y hacer
vmkping a las ips de los vmkernels de los demás hosts.

Comprobar conectividad vMotion

Entramos a esxi01 por ssh y hacemos vmkping -c1 a las ips de vmkernel de vMotion de los otros hosts.
El -c1 es para solo hacer un ping.

1 ~ # vmkping -c1 192.168.2.12

2 PING 192.168.2.12 (192.168.2.12): 56 data bytes

3 64 bytes from 192.168.2.12: icmp_seq=0 ttl=64 time=1.064 ms

5 --- 192.168.2.12 ping statistics ---

6 1 packets transmitted, 1 packets received, 0% packet loss

7 round-trip min/avg/max = 1.064/1.064/1.064 ms

8 ~ # vmkping -c1 192.168.2.13

9 PING 192.168.2.13 (192.168.2.13): 56 data bytes

10 64 bytes from 192.168.2.13: icmp_seq=0 ttl=64 time=1.002 ms


11

12 --- 192.168.2.13 ping statistics ---

13 1 packets transmitted, 1 packets received, 0% packet loss

14 round-trip min/avg/max = 1.002/1.002/1.002 ms

Desde esxi01 tenemos conectividad vMotion con los otros dos hosts. Bien, procederemos a probar FT y
VSAN de la misma forma

Comprobar conectividad Fault Tolerance

Desde la sesión SSH que tenemos abierta en esxi01, hacemos vmkping a las ips de los vmkernels de FT
de los otros dos hosts.

1 ~ # vmkping -c1 192.168.3.12

2 PING 192.168.3.12 (192.168.3.12): 56 data bytes

3 64 bytes from 192.168.3.12: icmp_seq=0 ttl=64 time=1.122 ms

5 --- 192.168.3.12 ping statistics ---

6 1 packets transmitted, 1 packets received, 0% packet loss

7 round-trip min/avg/max = 1.122/1.122/1.122 ms

8 ~ # vmkping -c1 192.168.3.13

9 PING 192.168.3.13 (192.168.3.13): 56 data bytes

10 64 bytes from 192.168.3.13: icmp_seq=0 ttl=64 time=0.679 ms

11

12 --- 192.168.3.13 ping statistics ---

13 1 packets transmitted, 1 packets received, 0% packet loss

14 round-trip min/avg/max = 0.679/0.679/0.679 ms

Comprobar conectividad VSAN

Por ultimo, de nuevo desde la sesion root de SSH que tenemos abierta en esxi01, hacemos vmkping a las
ips de los vmkernels de VSAN que tenemos en los otros dos hosts.
1 ~ # vmkping -c1 192.168.5.12

2 PING 192.168.5.12 (192.168.5.12): 56 data bytes

3 64 bytes from 192.168.5.12: icmp_seq=0 ttl=64 time=0.932 ms

5 --- 192.168.5.12 ping statistics ---

6 1 packets transmitted, 1 packets received, 0% packet loss

7 round-trip min/avg/max = 0.932/0.932/0.932 ms

8 ~ # vmkping -c1 192.168.5.13

9 PING 192.168.5.13 (192.168.5.13): 56 data bytes

10 64 bytes from 192.168.5.13: icmp_seq=0 ttl=64 time=0.915 ms

11

12 --- 192.168.5.13 ping statistics ---

13 1 packets transmitted, 1 packets received, 0% packet loss

14 round-trip min/avg/max = 0.915/0.915/0.915 ms

Hasta aquí llegamos en esta entrada del curso de vmware para ayudarte con la certificacion VCP. En
siguientes capítulos vamos a comenzar a habilitar y utilizar funciones vomo vMotion, HA, DRS y Fault
Tolerance.
Tema 6 – Almacenamiento compartido en VMware
En este corto capítulo de nuestro curso de vmware añadiremos almacenamiento compartido desde
vCenter a nuestros hosts esxi del laboratorio VMware. Hace un par de capítulos ha habíamos pasado por
encima del almacenamiento, creando datastores en almacenamiento local y mirando como se agregaban
desde el cliente vmware de Windows. Ahora vamos a crearlos utilizando vCenter, que es la forma
habitual de trabajar y simplifica en gran medida tareas como esta, ya que podemos agregar
almacenamiento compartido a literalmente centenares de hosts con una única operación. En este
laboratorio utilizaremos NFS como protocolo para el almacenamiento compartido y crearemos dos
datastores a partir de dos volumenes NFS que debemos tener configurados en nuestro laboratorio con la
solución de almacenamiento compartido que hayamos elegido.

Antes de nada, utilices el protocolo que utilices de almacenamiento compartido, debes dar permisos en
el lado del storage para poder conectar nuestros hosts ESXi. En el caso de NFSv3, la validación es
simplemente mediante la ip de origen que intenta montar el volumen. Yo ya he creado los permisos
correspondientes de lectura y escritura en el dispositivo de almacenamiento compartido de forma previa.

Agregar Datastores en vCenter

Para agregar almacenamiento compartido en vCenter, y dado que queremos agregarlo en todos los hosts
de nuestro cluster del laboratorio, iremos en el inventario a la opción Hosts and Clusters

A continuación, haremos click derecho en el cluster y seleccionaremos New Datastore


Elegiremos la opción NFS

Proporcionamos los datos del dispositivo de almacenamiento y el volumen exportado por NFS.
Seleccionaremos los hosts a los que queremos agregar este almacenamiento compartido y finalizaremos
el asistente.

Podremos ver en el panel de tareas recientes que se ha completado correctamente la operación.

A continuación, repetiremos el procedimiento para agregar un segundo datastore NFS, necesario para las
prácticas de Storage DRS y Storage vMotion.

Una vez dispongamos del segundo datastore, podemos irnos, en el panel de inventario, a la pestaña de
almacenamiento y podremos ver los datastores disponibles
Si queremos confirmar que efectivamente, los 3 hosts de nuestro laboratorio se han conectado al nuevo
almacenamiento compartido, seleccionaremos el datastore e iremos a Related Objects > Hosts

Crear un Datastore Cluster

Al igual que podemos crear clusters con los hosts ESXi, podemos crear Datastore Clusters con el
almacenamiento compartido. Esto nos sirve para repartir su ocupación o para balancear la carga de
trabajo que tienen. A continuación crearemos un Datastore Cluster con los dos volumenes NFS que
hemos agregado anteriormente.

Para crear un Datastore Cluster, dentro de la misma pestaña de Almacenamiento que estábamos antes,
haremos click derecho sobre el Datacenter y elegiremos la opción New Datastore Cluster
Lo nombraremos LAB-CLUSTER y desactivaremos de momento DRS

Proseguimos con las opciones por defecto del asistente hasta llegar a la pantalla de Select Clusters and
Hosts. En esta ventana indicaremos cuales son los hosts y clusters que deberán tener conectividad con
los datastores que formen parte del Datastore Cluster. En cierto modo es una forma de filtrar los
datastores que van a participar en el cluster. Seleccionaremos todo el cluster laboratorio.
A continuación, elegiremos los datastores disponibles en común dentro del objeto que seleccionamos en
el paso anterior. Como todos los hosts pertenecientes al cluster laboratorio tienen conectados los
datastores QNAP01-VM01 y QNAP01-VM02, nos deja elegirlos, y así lo haremos.

Finalizamos el asistente ya veremos el cambio reflejado en el panel de inventario, donde hemos dejado
de ver directamente los dos datastores para pasar a ver el cluster que los contiene.
Tema 7 – Maquinas Virtuales
Hasta ahora en nuestro curso de VMware hemos avanzado en conceptos de virtualización, organización
del inventario de objetos en vCenter, almacenamiento, redes, pero todavía no hemos tocado propiamente
máquinas virtuales. Las máquinas virtuales son el objeto de la virtualización propiamente y merecen un
capítulo propio para aclarar una serie de conceptos importantes de cara a los siguientes capítulos.

Componentes de las maquinas virtuales

Una maquina virtual en sí no es más que un conjunto de archivos que almacenan información relativa a
su configuración de hardware, y los datos del disco duro de esta. Entremos un poco más en profundidad
en estos componentes.

¿Que contiene cada archivo de una máquina virtual de VMware?

Cuando trabajamos con VMware ESXi, estamos manejando, entre otras muchas cosas, máquinas
virtuales (VMs). Estas máquinas virtuales están compuestas por varios archivos almacenados en
carpetas dentro de datastores. Tomaremos como ejemplo el vCenter Server Appliance que instalamos en
el capítulo anterior del curso de vmware para la certificacion VCP:

1 -rw------- 1 root root 16.1M Nov 2 19:03 vcsa55-000001-delta.vmdk

2 -rw------- 1 root root 315 Nov 2 19:03 vcsa55-000001.vmdk

3 -rw------- 1 root root 8.0G Nov 2 12:20 vcsa55-3dbf9190.vswp

4 -rw------- 1 root root 27.6K Nov 2 19:03 vcsa55-Snapshot1.vmsn

5 -rw------- 1 root root 25.0G Nov 2 19:03 vcsa55-flat.vmdk

6 -rw------- 1 root root 8.5K Nov 2 19:03 vcsa55.nvram

7 -rw------- 1 root root 523 Nov 2 12:20 vcsa55.vmdk

8 -rw-r--r-- 1 root root 441 Nov 2 19:03 vcsa55.vmsd

9 -rwxr-xr-x 1 root root 2.7K Nov 2 19:03 vcsa55.vmx

10 -rw------- 1 root root 0 Nov 2 12:20 vcsa55.vmx.lck

11 -rw-r--r-- 1 root root 261 Oct 31 17:15 vcsa55.vmxf

12 -rw------- 1 root root 16.2M Nov 2 19:03 vcsa55_1-000001-delta.vmdk

13 -rw------- 1 root root 320 Nov 2 19:03 vcsa55_1-000001.vmdk

14 -rw------- 1 root root 100.0G Nov 2 19:03 vcsa55_1-flat.vmdk

15 -rw------- 1 root root 529 Nov 2 12:20 vcsa55_1.vmdk


16 -rw-r--r-- 1 root root 136.2K Oct 31 17:47 vmware-1.log

17 -rw-r--r-- 1 root root 160.0K Nov 2 19:03 vmware.log

18 -rw------- 1 root root 110.0M Nov 2 12:20 vmx-vcsa55-1035964816-1.vswp

 vcsa55.vmx
Guarda los datos de configuración de la máquina virtual, desde su dirección MAC, hasta los discos que
tiene conectados, etc.

 vcsa55-3dbf9190.vswp
Se trata del archivo de swap de la máquina virtual. Puede crecer hasta el tamaño que tiene la memoria
RAM de la máquina virtual, por eso tiene asignados los 8192 MB de RAM de la máquina virtual + el
overhead (veremos más adelante eso, en el capítulo dedicado a la gestión de memoria).

 vcsa55.nvram
Este archivo guarda una copia de la BIOS de la máquina virtual

 vcsa55.vmsd
En este archivo se guarda información relativa a los snapshots de la máquina virtual. Solo información
relativa a ellos, no los snapshots propiamente.

 vcsa55.vmx.lck
Este archivo es un lockfile. Indica que esta máquina virtual se encuentra encendida en algún host.

 vcsa55.vmxf
Este archivo contiene informacion de configuración extra para las máquinas virtuales.

 vmware.log
Este archivo guarda un log de eventos relacionados con la máquina virtual. Puede ser útil a la hora de
hacer resolución de problemas.

 vcsa55.vmdk
Contiene una serie de datos de descripción y configuración del siguiente archivo de la lista y
correspondiente al primer disco duro de la máquina virtual

 vcsa55-flat.vmdk
Se trata del disco duro propiamente de la máquina virtual, un contenedor de datos en el que se
almacenan los bytes correspondientes al primer disco duro de la máquina virtual

 vcsa55_1.vmdk
Contiene una serie de datos de descripción y configuración del siguiente archivo de la lista y
correspondiente al segundo disco duro de la máquina virtual

 vcsa55_1-flat.vmdk
Se trata del disco duro propiamente de la máquina virtual, un contenedor de datos en el que se
almacenan los bytes correspondientes al segundo disco duro de la máquina virtual

 vcsa55-Snapshot1.vmsn
Se trata de un archivo que contiene información relativa al estado del snapshot número 1 de la máquina
virtual
 vcsa55-000001.vmdk
Se trata del archivo que guarda la configuración de un disco duro auxiliar creado al hacer un snapshot
del primer disco duro de la máquina virtual.

 vcsa55-000001-delta.vmdk
Se trata del archivo de datos con las diferencias que va habiendo en el primer disco duro de la máquina
virtual desde el momento de creación del snapshot.

 vcsa55_1-000001.vmdk
Se trata del archivo que guarda la configuración del disco duro auxiliar creado al hacer un snapshot del
segundo disco duro de la máquina virtual.

 vcsa55_1-000001-delta.vmdk
Se trata del archivo de datos con las diferencias que va habiendo en el segundo disco duro de la
máquina virtual desde el momento de creación del snapshot.

vCPU

Se trata de la cantidad de CPUs / cores de CPU a los que tienen acceso las maquinas virtuales. Pueden
tratarse de una o más CPUs que se presentan físicamente como sockets o cores (podemos elegirlo).
Aparte de configuraciones avanzadas y optimizadas como afinidad NUMA, etc, podemos vernos en la
necesidad de presentar las CPUs como cores para respetar un escenario como este:

Hemos comprado un software que se licencia por CPU física, es decir, por socket físico.

Nuestro host de virtualización es un servidor con dos procesadores Xeon de 6 cores cada uno, sin
embargo solo podemos utilizar uno de ellos para la maquina virtual si queremos respetar la modalidad
de licenciamiento con el fabricante (una modalidad que por otro lado está totalmente obsoleta).

Para esto, daremos a nuestra maquina virtual 1 socket de CPU y 6 cores de CPU. Además, para
asegurarnos de que vamos a utilizar solo una cpu física para esta maquina virtual, seleccionaremos CPU
AFFINITY 0-5, lo cual hará que solo se utilicen los primeros 6 cores disponibles en el host para esta
máquina virtual. De esta manera, la maquina virtual nunca llegará a hacer uso del segundo procesador
físico y no estaremos rompiendo estos licenciamientos ridiculos.

Otro escenario es que tengamos un software con la misma licencia limitada a 1 CPU física y queramos
hacerle trampas y proporcionarle más cores de los que tienen nuestros procesadores en el host.
Siguiendo el ejemplo anterior del Dual Xeon Hexa Core, podríamos hacer creer a la máquina que tiene 1
Socket, pero otorgarle 12 CORES, con lo que aprovecharíamos el doble procesador y el software no
rechistaría, pensando que tenemos 1 único procesador con muchos más cores de los que realmente
tenemos.

CPU Affinity

Se trata de una opción de configuración de una maquina virtual en VMware que permite seleccionar y
limitar el uso de cores del host a una maquina virtual. Si queremos que “maquinavirtual01” se ejecute
unica y exclusivamente en los cores 0 y 1 de nuestro host, escribiremos 0,1 en los valores de CPU
affinity. Ten presente que esto limita la ejecución de la maquina virtual a estos cores, pero de ninguna
manera los reserva para esta maquina virtual en exclusiva. Ademas, estaras limitando el tiempo de cpu
que se puede dedicar a los diferentes hilos que componen la maquina virtual en tiempo de ejecucion
(worlds) por lo que es posible que termines viendo una merma del rendimiento conforme los diferentes
worlds compiten entre si por obtener recursos en caso de saturacion de los cores a los que hemos
limitado esa maquina virtual.

CPU affinity además, inhabilita la maquina virtual para ser manejada mediante la funcionalidad DRS
automatizada de un cluster y no puede ser habilitado en una maquina virtual que resida en un cluster con
DRS ya habilitado.

La recomendación general es que no utilices CPU affinity en tus maquinas virtuales pues puede
penalizarte más que los beneficios que te aporte. Además, CPU affinity es una funcionalidad
incompatible con vMotion y por tanto con DRS.

vRAM

La vRAM, o RAM virtual, es la cantidad de memoria del host que se asigna a cada máquina virtual para
trabajar y, en definitiva, la que este guest verá como disponible. Se puede asignar desde unos pocos MB
hasta 2TB de memoria RAM. La recomendación general es que se debe asignar a la máquina virtual
tanta memoria como vaya a utilizar, ni más ni menos. No es interesante asignar a un equipo mucha más
memoria de la que vaya a utilizar, pues estaremos perjudicando a las demás máquinas virtuales en caso
de que ocurra una situación de contención de recursos (falta de recursos).

Disco Duro Virtual

Otro de los componentes básicos de una máquina virtual es su disco duro. Si bien es perfectamente
posible ejecutar máquinas virtuales que no dispongan de almacenamiento de este tipo, existen pocos
casos prácticos en los que vayamos a querer nuestra máquina virtual arrancando solo desde PXE o una
ISO arrancable como un Live CD. Un ejemplo clásico de máquina virtual sin disco duro es aquella en la
que montamos una ISO de un Live CD de Linux para probarlo durante un periodo determinado de
tiempo y cuya información no nos preocupa perder si la apagamos.

Los discos duros virtuales de una maquina virtual se conectan mediante controladoras, al igual que en un
ordenador normal. Disponemos de diferentes tipos de controladoras de disco:

 Buslogic Parallel IDE


 LSI Logic Parallel
 LSI Logic SAS
 VMware PAravirtual

Podemos conectar hasta 4 controladoras de disco SCSI a una maquina virtual, y 15 discos duros a cada
una de ellas, por lo que podremos disponer de un máximo de 60 discos duros conectados a una única
máquina virtual. En el caso de controladoras IDE, podremos conectar una única a nuestra maquina
virtual, con hasta 4 dispositivos conectados a la misma. Si, por el contrario, elegimos un adaptador
Virtual SATA, podremos conectar 4 de este tipo, con 30 dispositivos por cada controladora SATA
virtual.

Crear maquinas virtuales

Una tarea habitual en un entorno virtualizado es la creación de máquinas virtuales dentro de nuestro
vCenter. La creación de máquinas se realiza de la siguiente manera:
Seleccionaremos el nivel dentro del inventario en el que queremos crear nuestra máquina virtual. El
nivel más alto al que podemos crear una máquina virtual es el cluster. Si no tenemos un cluster,
crearemos la máquina virtual en un host. Las máquinas virtuales también pueden crearse en resource
pools, vApps y carpetas.

Para crear una máquina virtual, haremos click derecho sobre el objeto padre donde queramos alojarla y
haremos click en New Virtual Machine

Ahora se nos presentara un menú en el que veremos todas las formas que existen para crear una maquina
virtual.
Repasémoslas:

Create a new virtual machine

La forma tradicional y más manual de crear una máquina virtual. Se te pedirán los valores de
configuración de la máquina virtual para que luego procedas a instalarla, es como instalar un servidor
físico normal.

Deploy from template

Se utiliza una máquina virtual que previamente has convertido en una plantilla. Suele estar ya instalada
y lista para configurar valores como el hostname o su IP. Facilita bastante los despliegues de varias
máquinas virtuales.

Clone an existing virtual machine

Puedes usar una máquina virtual ya existente para generar una clonándola. Tiene la ventaja de que tiene
el mismo contenido, pero el inconveniente de que las ips, hostnames, configuraciones, son las mismas
que las de la máquina que ya tienes. Puede haber conflictos de ips duplicadas, aplicaciones compitiendo
por conexiones, etc.

Clone virtual machine to template

Con este método crearemos una plantilla o template a partir de una máquina virtual que ya tenemos lista
y preconfigurada. Es requisito para la opcion 2 de este menú.

Clone template to template

Esta funcionalidad nos permite clonar un template o plantilla. Normalmente lo utilizaremos si queremos
realizar modificaciones a la plantilla que solemos utilizar para desplegar máquinas virtuales.

Convert template to virtual machine

Esta funcionalidad suele ser complementaria a la anterior. Dado que los templates o plantillas de
maquinas virtuales no se pueden encender, necesitamos convertir la plantilla a máquina virtual normal
cada vez que vayamos a introducir algún cambio en la misma, como por ejemplo, instalar
actualizaciones de sistema o meter nuevas versiones de software para disponer de ellas en futuros
despliegues.

En este curso de VMware 5.5 vamos a aprender a crear máquinas virtuales de forma tradicional, pero es
importante que conozcas TODAS las formas de creación de máquinas virtuales, incluidos los
despliegues con plantillas/templates y la personalización del despliegue usando herramientas como
sysprep. Si estás preparando el examen VCP, son preguntas de examen VCP.

Lo primero que se nos pedirá en el asistente de creación de máquinas virtuales será el nombre y
ubicación de la misma. Debemos dar un nombre por el que la vayamos a poder identificar. Este nombre
será también el nombre de la carpeta que se creará dentro del datastore para almacenar los diferentes
archivos que conforman la máquina virtual.
Como anteriormente hemos elegido el datacenter virt.es, se nos presenta una lista de los objetos que
contiene. Yo he elegido el cluster laboratorio, pero puedes elegir el que se adapte a tus necesidades.
La siguiente pantalla nos muestra una selección de los diferentes datastores que tenemos disponibles par
almacenar nuestra máquina virtual. Elegiremos uno con suficiente capacidad disponible y debemos tener
presente si el resto de nuestros hosts tienen visibilidad del mismo, para funcionalidades posteriores
como HA, FT, vMotion…
La siguiente pantalla del asistente nos pregunta la versión del hardware virtual que queremos poner a la
máquina virtual. Esta elección, aparentemente sencilla, la hará compatible o incompatible con hosts de
versiones anteriores a la que seleccionemos. Además, según la versión del cliente vSphere de Windows
que utilices, podrás realizar o no acciones como editar las propiedades de la máquina virtual. Como
regla general, para mantenernos en el lado seguro, diremos que el Cliente vSphere de Windows solo
puede editar máquinas virtuales con hardware versión 8, equivalente a ESXi 5.0. Con las últimas
versiones del cliente vSphere, podremos editar máquinas con versión superior de hardware, pero
únicamente modificar los parámetros que ya existían en la versión 8 de hardware virtual. Las nuevas
capacidades de hardware v9 y hardware v10 no serán editables. El cliente Web no tendrá problema para
editar las máquinas virtuales de como máximo, su versión.
Elegiremos el tipo de sistema operativo que va a ejecutar nuestro guest. Recordemos que el guest es la
máquina virtual que estamos creando. En mi caso, he elegido Linux, y dentro de la familia Linux, el
sistema operativo Debian 7.
En esta pantalla se nos permitirá ajustar los parámetros que por defecto se recomiendan para el tipo de
máquina virtual que hemos seleccionado crear. Pregunta de examen VCP. En mi caso suelo quitar la
unidad de floppy, ya que nunca la utilizo.
En esta última pantalla revisaremos todos los parámetros antes de crear la máquina virtual. Si estamos
de acuerdo con todo, pulsaremos en Finish.
Una vez la máquina virtual está creada, haremos click derecho sobre ella y seleccionaremos Power On
para ponerla en marcha.
Nuestra máquina virtual ya está creada, pero carece de un sistema operativo que arrancar. Pulsaremos el
botón que se indica en la imagen para conectarle un archivo .iso en el que tendremos nuestro sistema
operativo.
Seleccionamos la opción Connect to CD/DVD image on a local disk, si lo tenemos descargado en
nuestro ordenador de escritorio.

La aplicación web solicitará permiso para acceder a nuestro ordenador, para poder montar la iso en la
máquina virtual como si de un CD se tratase.
Seleccionamos la iso que queramos instalar y pulsamos Open. En mi caso he usado una de lubuntu para
el ejemplo, aunque posteriormente he de confesar que me arrepentí y puse kubuntu para probar KDE
Plasma 5 🙂

Volveremos a la pantalla de Summary para esta vez vamos a fijarnos en un texto que pone “Launch
Console”. Haremos click sobre él. Es el equivalente a conectar un monitor y teclado a un servidor
tradicional. Desde aquí controlaremos la instalación del sistema operativo en la máquina virtual.
Vaya, la máquina virtual ya estaba arrancada y efectivamente ha detectado que no tenemos sistema
operativo en el disco duro. Como hemos conectado la imagen ISO a modo de CD con posterioridad,
vamos a mandarle un reinicio mediante el botón de Ctrl-Alt-Supr indicado en la imagen

Una vez pulsamos, podremos ver como esta vez si arranca desde la ISO y comienza la instalación del
sistema operativo.
Crear un template de una maquina virtual

Crear una plantilla puede facilitar enormemente el despliegue de múltiples máquinas virtuales. Una vez
tenemos nuestra máquina virtual instalada, seguiremos el siguiente procedimiento para convertirla en
plantilla.

Apagar la máquina virtual. Es requisito. Para convertir una máquina virtual preexistente en una
template, ha de estar apagada.

Pulsaremos sobre la máquina virtual apagada con el botón derecho del ratón y elegiremos la opción
Convert to Template. Esta opción puede estar dentro de All vCenter Actions en el Web Client.

¡OJO! Para ver las plantillas tenemos que ir al tab de VMs, ya que no aparecen en el de Hosts and
Clusters.

Si nos fijamos en el inventario, el icono representativo de los templates es diferente al de las máquinas
virtuales. Esto permite diferenciarlas mucho más fácilmente.
Crear una plantilla de personalización para despliegues (Customization Specification)

Cuando desplegamos una máquina virtual desde una plantilla, si el sistema operativo está soportado,
podemos personalizar aspectos como su hostname, direccionamiento de red, DNS… Esto es una ventaja
y hace mucho más ágil el despliegue de máquinas virtuales (te lo dije!)

Debes saber que para personalizar despliegues en Windows, podemos utilizar la herramienta sysprep de
microsoft, que permitirá personalizar más a fondo el despliegue.

En mi caso, como voy a desplegar y personalizar una plantilla de Ubuntu, crearé una customization
specification para este sistema operativo.

Haremos click en el icono de Home de vSphere Web Client, para posteriormente hacer click en
Customization Specification Manager

El asistente de creación de personalización de VMs nos pedirá inicialmente el sistema operativo que
vamos a personalizar. Puede ser Windows o Linux. Ten presente que no todos los Linux están
soportados.
La siguiente pantalla nos permite personalizar opciones de hostname y dominio de la máquina que
vamos a personalizar en tiempo de despliegue. Personalmente, creo que la opción más sensata es elegir
el mismo hostname que el nombre que vamos a dar en el inventario de vCenter a la máquina virtual.
Nos ahorrará confusiones para identificar nuestros equipos cuando el entorno crezca.
La siguiente pantalla no tiene ningún secreto y nos pide la zona horaria del equipo.
El siguiente paso es el de configuración de red. Podemos elegir que interfaces se configuran con DHCP
y cuales se configuran con una dirección estática o una combinación de ambos si tenemos más de una
tarjeta de red. El paso siguiente es también relacionado con la red y consistirá en configurar los
servidores DNS.
El paso final es el habitual de revisar los parámetros antes de finalizar la creación del guest
customization specification.
Desplegar una plantilla y personalizarla

Utilizando el guest customization specification que acabamos de crear, desplegaremos la plantilla.

Haremos click derecho encima de la plantilla y seleccionaremos Deploy VM from this Template
Se nos pedirá el nombre que queremos poner a la maquina virtual en el inventario.
El siguiente paso nos pide la ubicación de la máquina virtual.
A continuación, se nos pedirá el datastore donde queremos desplegar la máquina virtual.
El siguiente paso entra directamente en la personalización de la máquina virtual que estamos
desplegando.
Se nos permitirá elegir una especificacion de personalización de las que ya existen. En este caso,
elegiremos la que hemos creado en el paso anterior.
Revisamos los parámetros y aceptamos si estamos de acuerdo.
Hemos visto como desplegar maquinas virtuales desde una plantilla nos permite disponer de forma ágil,
de máquinas virtuales que nacen “iguales” ahorrándonos el paso de instalación del sistema operativo, y
que en cuestión de minutos, podemos disponer de varias maquinas virtuales con diferentes hostnames,
configuración de red, etc. Se trata de conceptos básicos, pero para quien no quiera meterse en formas de
despliegue más complicadas (Orchestrator), le servirá de sobra.

El tiempo de despliegue de la máquina virtual que he usado en el ejemplo ha sido de 3 minutos. En


almacenamientos de mayor categoría que el de mi laboratorio, con tecnología flash, se puede disponer
de máquinas virtuales listas para la acción en pocos segundos.

Borrar maquinas virtuales

Para borrar una máquina virtual en VMware, haremos click derecho sobre ella y seleccionaremos Delete
From Disk. Si elegimos Remove from Inventory, la máquina virtual desaparecerá del inventario de
vCenter, pero permanecerá en el datastore intacta.
Power States

Las maquinas virtuales en VMware pueden tener diferentes estados

 Encendida (Power On) – La máquina virtual se encuentra en funcionamiento. Una máquina virtual
encendida consume recursos de CPU, memoria, disco y red en el hipervisor donde se esté ejecutando.
 Apagada (Power Off) – La máquina virtual se encuentra apagada y no está consumiendo recursos en el
hipervisor. Sin embargo, la máquina virtual sigue consumiendo recursos de disco (espacio) en el
almacenamiento donde se encuentre.
 Suspendida (Suspended) – La máquina virtual se encuentra en estado suspendido. Su memoria RAM se
ha volcado a disco duro y después la máquina virtual se ha apagado. Al encenderla, volverá al mismo
punto en que estaba antes de suspenderla. Es el equivalente al suspender de un equipo portátil normal.

Además existen los siguientes comandos que hacen cambiar de estado a la maquina virtual:

 Reset – Es el equivalente a dar un botonazo a la máquina virtual. El reset desconectará las imágenes de
CD que tenga conectadas desde la consola la maquina virtual, igual que un power off – power on.
 Shut Down Guest OS – Manda una orden a las VMware tools para que envíen una señal de apagado
ACPI. Esta señal equivale a un apagado ordenado del equipo. Es la opción preferida por delante del
apagado de botonazo.
 Restart Guest OS – Manda una orden a las VMware tools para que envíen una señal de reinicio ACPI.
Esta señal equivale a un reinicio desde el sistema operativo y es preferible a realizar un reset.
Tema 8 – Snapshots
Los snapshots son merecedores de un corto capítulo en el curso de VMware. Mal utilizados por muchos,
infravalorados por otros, y grandes ayudantes para la gente que realiza modificaciones serias en sus
máquinas virtuales y quiere disponer de una red para no tirarse al vacío realizándolos.

¿Qué es un Snapshot?

Un snapshot es una instantánea que se toma de una máquina virtual en un momento en el tiempo. Al
crear un snapshot, creamos un punto de restauración en la máquina virtual, de manera que si, por poner
un ejemplo extremo, la formateamos dos minutos después, podemos recuperar todo con un par de clicks.

Tenemos dos niveles de snapshots, que proporcionan una vuelta atrás más o menos completa:

Snapshot RAM + Disco Duro – Es el snapshot más completo que podemos hacer. Incluye la memoria
RAM del equipo, por lo que si hacemos uso de él, volveríamos al estado exacto del equipo en el
momento de realizarlo, incluidas las aplicaciones abiertas y su estado. Tarda en realizarse el tiempo que
se necesite para hacer un volcado de la memoria RAM a disco duro.

Snapshot solo Disco Duro – Es un snapshot inmediato, en el que guardamos el estado de los bloques
del disco duro. Volver a este snapshot supone reiniciar el equipo y perder el estado de las aplicaciones
que estuviesen ejecutándose cuando se tomó el snapshot.

¿Qué NO es un Snapshot?

Un snapshot NO es un backup. No es una forma de hacer copias de seguridad. No es una forma de


Disaster Recovery. No es un business continuity plan. No es algo que haces porque sí.

Los snapshots de máquina virtual penalizan el rendimiento de la máquina virtual e impactan en el


almacenamiento. Los Snapshots crecen y crecen y pueden llegar a ser un auténtico problema a nivel de
espacio en disco. Además, intentar borrar un snapshot que lleva mucho tiempo creado y ha crecido de
forma desproporcionada, puede ser una tarea casi imposible y hacer sudar a almacenamientos de varios
miles de euros en según que entornos.

¿Como funcionan los Snapshots en VMware?

Cuando hacemos un snapshot de disco, VMware “atonta” de forma momentánea a la máquina virtual y
aprovecha para darle un cambiazo en el disco duro. La máquina virtual comienza a partir de ese
momento a escribir todos sus cambios en un nuevo archivo, que es un diferencial o delta con respecto al
disco duro original de la máquina virtual. Es por esto que si queremos volver atrás en el snapshot, tan
solo debemos indicar al hipervisor que le vuelva a dar el cambiazo a la máquina virtual y la apunte al
disco duro que tenía anteriormente. Los snapshots se pueden anidar, de la siguiente forma

Como crear un Snapshot en VMware

Para crear un Snapshot en VMware, haremos click derecho sobre la maquina virtual y seleccionaremos
Take Snapshot.
En el menú que nos aparecerá, escribiremos el nombre del snapshot (busca algo identificativo que te
permita saber luego si lo puedes borrar)
También aparecerán dos opciones:

 Snapshot the virtual machine’s memory – Es la opción para hacer snapshot también del estado de la
RAM del disco, permitiendo guardar el estado de las aplicaciones en ejecución. Tarda más en realizarse,
por lo que solo debes hacerlo cuando realmente te valga la pena.
 Quiesce guest file system (Needs VMware Tools Installed) – Es una opción que hace que las VMware
tools ordenen una escritura a disco al sistema operativo de todos los datos que tenga pendientes de
escribir. Esto hace que los snapshots del disco tengan un mayor grado de consistencia, aunque no
proporciona consistencia a nivel de aplicación, como en el caso de algunas bases de datos.

Con estos dos pasos, ya hemos creado un snapshot de la máquina virtual. Si quieres, puedes probar a
borrar algunos archivos ahora que disponemos del snapshot.

Como volver a un snapshot anterior en VMware

Ahora que hemos borrado unos archivos (o instalado una actualización de sistema operativo o una
aplicacion) vamos a imaginarnos que algo ha ido desastrosamente mal y queremos volver a como
estábamos antes de comenzar. Haremos click derecho encima de la máquina virtual y seleccionaremos
Manage Snapshots

En el siguiente menú, seleccionaremos al punto de snapshot al que queremos volver y pulsaremos el


botón Revert To. Esta acción nos dejará la máquina como la teníamos en ese momento. Si el snapshot
incluía RAM, la máquina se restaurará encendida. Si el snapshot no incluía memoria RAM, la máquina
se restaurará apagada y tendrás que encenderla a mano.
Te has fijado en que los snapshots se pueden anidar, incluso crear diferentes ramificaciones? He visto
desarrolladores que usan esto para crear desde una misma máquina virtual diferentes entornos y poder
moverse de una configuración a otra de forma bastante rápida.

Borrar Snapshots en VMware

El borrado de snapshots en VMware se realiza seleccionando el snapshot que quieres eliminar y


pulsando el botón Delete que ves en la captura anterior. Si quieres eliminarlos todos, deberás pulsar
directamente el botón Delete All.

Estás avisado de que el borrado de snapshots es una tarea MUY intensiva con el disco que implica
lecturas, escrituras y borrados. Procura hacerlos en horas valle de tu almacenamiento. También debes
saber que durante el proceso de borrado de snapshots la máquina quedará “atontada” en algunos
momentos y no puedes hacer nada para evitarlo.

Otra cosa muy importante y que lamentablemente todos aprendemos cuando un borrado de snapshot está
afectando al rendimiento de nuestro almacenamiento. Un borrado de snapshots NO SE PUEDE
CANCELAR.