miércoles, 10 de abril de 2024

Cómo actualizar ESXi desde 6.7 hasta 8.0

Vamos a ver cómo podemos realizar la actualización de nuestro ESXi, de la versión 6.7.0 hasta la 7.0u3. Aunque en este caso el salto que haremos será solo hasta la 7.0u3, si tenemos nuestro VCSA previamente actualizado a la 8.0, podríamos irnos a de una vez hasta ESXi 8.0 sin problemas.

Me quedo en la 7.0u3 por limitaciones del lab de pruebas, donde, para el servidor HP que estoy utilizando, el fabricante ha liberado hasta esta versión de ESXi en el momento del post, pero estas mismas instrucciones se pueden utilizar para, de un único salto, ir hasta la 8.0, según se puede comprobar en las tablas de compatibilidad de VMware:

¡Al lio! Nos descargamos la versión de ESXi que vamos a instalar, y la subimos a un disco local del ESXi. En este caso no es la ISO, es el archivo Depot del fabricante. Por ejemplo, si estuviéramos actualizando, pongamos por ejemplo, un nested ESXi, nos valdría la imagen de VMware. En este caso, como trabajaremos sobre un hardware de fabricante asociado, tiramos de la imagen del fabricante:

Verificamos que tenemos acceso por SSH, y si no, lo activamos.

Metemos el nodo que queremos actualizar en modo mantenimiento. Con el modo mantenimiento y el DRS correctamente activado, las VMs deberían reubicarse solas previamente en otros hosts del cluster, pero como no lo tengamos bien configurado, o haya reglas de almacenamiento que se peguen con VMs contenidas en este host, lo que conseguiremos es que estas VMs queden suspendidas, así que previamente revisa todo aquello que pueda influir en el movimiento de las VMs, o si no son muchas, haz un host vMotion a mano para las VMs a desalojar del ESXi. Doy por hecho que están en un datastore compartido y no en local, si no, storage vMotion a una ubicación externa al host a actualizar.

Y con esto, ya podemos poner el host en mantenimiento:

Ahora si, nos conectamos con Putty a nuestro host, y pasamos el siguiente comando:

esxcli software sources profile list -d /vmfs/volumes/xxxxx/VMware-ESXi-7.0.3-22348816-HPE-703.0.0.11.5.0.6-Oct2023-depot.zip

...donde el nombre del volumen lo podemos sacar de la ubicacion, en la ventana Resumen del local datastore. Se entiende mejor en la siguiente imagen:


...y reemplazamos el nombre "VMware-ESXi-7.0.3-22348816-HPE-703.0.0.11.5.0.6-Oct2023-depot.zip" por el nombre de archivo que subiste previamente al local datastore.

Nos indicará lo siguiente:


Esto nos da las imágenes disponibles en el paquete. En este caso, una única imagen del fabricante. Si buscas información sobre el proceso de actualización, muchas veces se omite este paso, y directamente se muestra una salida como la de la siguiente imagen, que corresponde a un archivo standard de VMware:


Vamos a actualizar la actualización con el siguiente comando, que incluye el nombre de la imagen disponible. Para ello, metemos el siguiente comando:

esxcli software profile update -d /vmfs/volumes/589c63a7-a3a57031-65f3-94188282a8b4/VMware-ESXi-7.0.3-22348816-HPE-703.0.0.11.5.0.6-Oct2023-depot.zip -p HPE-Custom-AddOn_703.0.0.11.5.0-6

Que si te fijas no es tanto, es "esxcli software profile update -d" /ruta del archivo /nombre del archivo que subimos previamente /nombre del perfil para actualización disponible.

Nos dará una salida larguísima. Pero prácticamente a la finalización del proceso, nos dará la info sobre el éxito del proceso:

Reiniciamos, sacamos de mantenimiento, ¡y listo! A repetir el proceso en los demás nodos. El reinicio lo puedes lanzar sin problema desde el vCenter.

PD: Recuerda que con el upgrade, hay que meter nuevas licencias...

Si te ha gustado el articulo, puedes invitarme a un café ;)

viernes, 15 de marzo de 2024

Actualizar VCSA de 6.7.0 a 8.0.2

 A veces, por unos temas u otros, nos resistimos a la actualización de nuestro entorno. Por esta razón, a veces toca realizar actualizaciones que normalmente se hubieran realizado en varios saltos, pero en uno solo. En este caso vamos a ver cómo actualizar un VCSA de la versión 6.7.0 a la ultima versión disponible.


Lo primero de todo: verificar si es posible el salto que queremos dar. Para ello disponemos de la herramienta Matrix interoperability, que nos permite comparar versiones de productos, y saltos de actualizaciones entre versiones. La verdad es que sólo esta herramienta da para hacerle un apartado, ya que dispone de bastantes opciones y comprobaciones.

Para la actualización que nos compete, podemos ver en la imagen superior que es posible el salto. De manera que comenzaremos con la actualización.

Partimos de que ya hemos descargado la ISO, y la tenemos en nuestro equipo. 

Montamos la ISO y nos vamos a D:\vcsa-ui-installer\win32, para ejecutar “installer.exe”. 



Esto nos abre la siguiente ventana de opciones: 


Podemos desde instalar el VCSA, a realizar una actualización, migrar desde un vCenter instalado en Windows al modelo appliance, o bien realizar una restauración de un backup previo (ojo, realizado con el sistema de backup del vCenter).
En nuestro caso hacemos un upgrade, así que pinchamos sobre esa opción.
Avisa que el proceso se realiza en 2 pasos. Empieza con un despliegue de un nuevo vCenter server, y luego copia datos del antiguo al nuevo.



Nos saldrá una pantalla de aceptación de licencia que debemos aceptar, y pulsamos sobre continuar. Seguidamente nos solicita los datos de conexión del appliance original. FQDN o IP, y puerto, que por defecto es el 443. 
Rellenamos los datos, y pulsamos sobre Connect to Source. Todavia en la misma pantalla, ampliará el número de campos a rellenar. Nos pedirá el Username y password con permisos en el appliance, por ejemplo, el usuario administrator@vsphere.local, y, ojo, el password del usuario root de la appliance origen.
Tras la linea gris de separación, nos pedirá el FQDN o IP del host ESXi que hospeda la actual appliance, cuidado, la actual, no la nueva que estamos desplegando,  así como el username y password con permisos a la misma, por ejemplo, el usuario root:


Nos saltará un aviso de certificados que debemos aceptar, y continuamos al paso 4 del despliegue, donde nos pedirá esta vez la IP del ESXi en el que se alojará el nuevo VCSA, así como usuario y password con permisos de, por ejemplo, el usuario root.



Seguidamente nos pedirá los ajustes para el nuevo VCSA que será desplegado, como por ejemplo, un nuevo password. Este paso no tiene mucho misterio. El paso 6, en cambio, es importante, ya que desplegará el appliance en base al tamaño de la infraestructura que manejará. Elegimos la que corresponda, y continuamos:


En el siguiente paso, elegiremos el datastore en el que vamos a desplegar la nueva VCSA:



No tiene mucho misterio... Si acaso, y sobre todo para un entorno de laboratorio, mejor dejar marcado el Thin Disk Mode. Esto para grandes entornos es mejor que no.
La parte de red es importante: nos pide una ip TEMPORAL para del despliegue del appliance:



Tras esto, nos saldrá un resumen de la configuración introducida para el proceso, y un botón de Finish, que al pulsarlo, iniciará la primera fase de la actualización. Esta primera fase consiste en el despliegue del vCenter Server. No es rápido, pero tampoco afecta al servicio que esté corriendo en esos momentos, pudiendo acceder mientras tanto sin problemas a la consola de nuestro vCenter.
Una vez termina la fase 1, podemos continuar con el proceso, pero también podemos cerrarlo y continuarlo más adelante, a partir del interfaz gráfico del nuevo vCenter desplegado, y todavía no en producción, funcionando con la IP temporal que le dimos en el paso 8 de la configuración:



En este caso, le daremos a continuar, donde nos mostrará una pantalla muy similar a la del comienzo de la actualización, pero indicándonos que ya habremos finalizado la primera parte de la misma, y que la segunda parte consistirá en copiar los datos del appliance origen al nuevo appliance. De hecho, en esta segunda parte del proceso, elegiremos qué datos serán transferidos:



Inicia unos chequeos previos a la actualización que llevan cierto tiempo, y que nos notificará con una serie de avisos y soluciones a los mismos:


Tras estos avisos, llegamos a un paso importante, ya que seleccionaremos los datos que serán traspasados a nuestro nuevo vCenter. Mientras que la primera opción transfiere lo justo, archivos de configuración e inventario, la segunda opción además transfiere tareas y eventos, y la tercera transfiere además las métricas de rendimiento antiguas, de manera que podrías mantener y comparar métricas después de la migración. Lógicamente, cuantos más datos traspases, más tardará este proceso, pero es aconsejable, sobre todo en entornos de producción, transferir todo.


La siguiente pantalla nos ofrece la ocasión de participar en el programa de mejora de experiencia de usuario. Pulsamos Next, y llegaremos a una última ventana de resumen de opciones antes de finalizar el wizard de actualización. Aquí debemos marcar la casilla de que hemos realizado backup del vCenter server original, y de los datos de su BBDD. En mi caso dispongo de un full backup con VEEAM, un snapshot del vCenter, y una copia de seguridad desde el mismo vCenter. Pulsamos Finish,


...y obtendremos un ultimo warning donde nos avisa que el vCenter original será apagado una vez que se active la configuración de red en el vCenter 8. Pulsamos OK, y empieza una nueva pantalla de progreso de la fase 2, dividida en 3 fases:


Nos pueden salir una serie de avisos. Simplemente leemos la información, para tenerla en cuenta, y pulsamos en Close, para continuar el proceso:


Terminará con otra serie de avisos, pulsamos en Close de nuevo, y esta vez nos mostrará una notificación indicando que ha terminado el proceso exitosamente, y la página de acceso a nuestro vCenter:



Hay cambios bastante interesantes, no solo de apariencia. Pero quizá el más notable, si venias de la versión 6.7, es que nos quitamos de en medio Flex, y pasamos por fin a una interfaz completamente HTML5, donde lo que no puedas gestionar desde aquí, es que se hace vía Cli.

lunes, 19 de febrero de 2024

Collector, las RVtools de Nutanix

 En entornos VMware disponemos de las RVtools, imprescindibles para recopilar datos de todo tipo, y con opciones de exportación en distintos formatos, que nos permiten realizar un análisis del entorno más cómodamente que desde el panel principal de un vCenter. Gracias a esta funcionalidad, podemos interactuar con otro tipo de herramientas ideales para, a partir de los datos exportados de las RVTools, realizar labores de estimaciones de capacidad (o rightsizing), usualmente para entornos en la nube.

Con Collector tenemos una herramienta similar, pero con algunas importantes diferencias. 

Lo primero de todo, es que Collector es una herramienta que en este caso no es de terceros, sino que está proporcionada por el fabricante. Si accedemos a my.nutanix.com, podremos descargárnosla sin dificultad. Es más pesada que las RVtools, en este caso, su carpeta comprimida pesa 254 Mb.

La segunda diferencia es que las RVtools están pernsadas para entornos VMware unicamente. En cambio, collector funciona en una amplia gama de entornos, desde Prism, para tomar referencias de su infraestructura nativa, a Hyper-V, vCenter, e incluso MS SQL Server y ONTAP CIFS para evaluar rendimientos de BBDD y espacios en disco requeridos.

La ejecutamos, y como suele pasar en este tipo de herramienta,s pide poca cosa: IP o FQDN del vCenter de turno, y cuenta de acceso:

Nos mostrará lo que ha encontrado para escanear. En este caso, en nuestro entorno de pruebas, ha encontrado un par de host:

Pulsamos sobre collect, y tras un examen bastante rápido, nos obsequiará con una pantalla muy parecida al dashboard clásico de Nutanix, y distintas opciones de exportación de los datos:

Fíjate en que tienes 3 pestañas, Cluster, Host y VMs Summary, cada una con un dashboard con su información correspondiente, muy claro y visual.

Junto al botón de exportación en excel, está el botón de mostrar la carpeta donde ha volcado los archivos de datos recolectados, por defecto es la carpeta en la que se ejecuta Collector, y un nombre con la fecha de ejecución del análisis, que en este caso es algo así como  "ntnxcollector_config_perf_collection_2024_2_19_8_40_48.zip".

Una cosa verdaderamente interesante en la exportación de datos es que da la opción de enmascarar datos sensibles, ayudando de esta forma a salvaguardar la GDPR en un examen de la infraestructura de una organización:

Sobre el archivo excel generado, lo dejará por defecto en la carpeta "logs", dentro de la carpeta del ejecutable del collector. El documento generado es calcado a lo que te da unas RVtools. De hecho, nos genera un libro con las siguientes hojas: vDataCenter, vCluster, vHosts, vInfo, vCPU, vMemory, vDisk, vPartition, vSnapshot, vSwitch, vNICs, vPort, vNetwork, vMutlipath, vLicense, vmList y Metadata. 

Los datos que nos va a enmascarar, si así lo pedimos, son los siguientes:Cluster Name, Host IP, Host Name, VM Name, Disk Name, Snapshot Name, Snapshot File, Host, Switch Name, Port Group, vSwitch, Network, Adapter, Disk, License Name y License Key.

lunes, 15 de enero de 2024

Como calcular cores para el licenciamiento de vSphere Foundation y VCF

 Con los nuevos modelos de paquetes y licenciamiento de VMware desde la entrada de Broadcom, así como el fin de las licencias perpetuas, moviéndonos al modelo de suscripción, nos encontramos con que tenemos que hacer bastantes cálculos de procesadores en el momento en el que nos salimos de un vSphere Essentials Plus. 

Para ello, VMware dispone del KB95927 donde se explica cómo debe realizarse este conteo de procesadores para el cálculo de licencias necesarias en nuestra infraestructura. En lineas generales, los requisitos son estos:

  • Cada núcleo requiere una única licencia. Estas licencias no vienen en paquetes de 16.
  • 16 núcleos en el requisito mínimo a adquirir por CPU/procesador físico.
  • Cada TiB reclamado por vSAN requiere una única licencia.
  • Estas licencias no vienen en paquetes, es decir, las licencias TiB no se venden en paquetes de 8, se venden como una licencia única y los clientes pueden agregar la cantidad deseada de TiB para cumplir con sus requisitos de capacidad de almacenamiento.
  • 8 TiB es el requisito mínimo que se debe comprar por CPU/procesador físico para hosts en un clúster de vSAN.
En el KB anteriormente mencionado, se describe en detalle el cálculo a realizar, con ejemplos en tablas. Aun así, sigue siendo complicado realizar el cálculo, más cuanto mas grande sea la instalación. Por ese motivo, VMware ha desarrollado una herramienta PowerCLI que recopila y consolida información sobre la cantidad de licencias de núcleos (con un mínimo de 16 núcleos por CPU física) y licencias TiB (con un mínimo de 8 TiB por CPU física) requeridas para cada host conectado a un vCenter Server. Para ejecutarla seguimos los siguientes pasos:
  • Necesitamos la herramienta de PowerCLI, v10 o superior. Si no la tenemos, desde un PowerShell, la descargamos con Install-Module VMware.PowerCLI -Scope CurrentUser
  • Nos conectamos a un servidor vCenter con Connect-VIServer-Server vCenter_Server
  • Según la documentacion del KB, importamos el módulo necesario con Import-Module .\FoundationCoreAndTiBUsage.psm1
  • A mi, el comando anterior me falla. Si te sucede lo mismo, podemos descargarnos el modulo manualmente desde AQUI. Con $env:PSModulePath podemos ver los path de los módulos de PowerShell. Movemos el archivo descargado a una de estas rutas, y hacemos un "import-module rutacompletadelarchivo\FoundationCoreAndTiBUsage.psm1"
  • Tras esto, ya podremos hacer un Get-FoundationCoreAndTiBUsage
Por defecto, el script pasa por todos los clusters de vSphere, y muestra los resultados:



Para sacar los resultados en un CSV, utilizamos el comando Get-FoundationCoreAndTiBUsage -Csv -Filename name.csv

Si te ha gustado el articulo, puedes invitarme a un café ;)

martes, 2 de enero de 2024

Como optimizar tus VMs con VMCO de Flings

Vamos con el primer post de este 2024, con una utilidad que quería comentar hace ya tiempo, Virtual Machine Computer Optimizer, o VMCO, de VMware Flings.

Lo primero...¿que es VMware Flings?

Flings son un conjunto de herramientas y utilidades creadas por la comunidad de VMware que, si bien no son oficiales, esto es, que no cuentan con soporte de VMware, y por tanto no se recomienda su uso en entornos de producción, sí que son alentadas por VMware, y soportadas en su web, en este ENLACE.

Hay algunas herramientas que ya no tienen sentido, como los drivers NVMe de la comunidad, ya que VMware ha adoptado esta tecnología en sus productos, u otras herramientas, como el Cross vCenter Workload Migration Uitlity, que han integrado directamente en algunas versiones de vCenter, según licencia.

Pero tienes otras soluciones plenamente vigentes, como el VMCO, que, aunque Aria Operations pueda facilitarte información sobre VMs sobredimensionadas o al contrario, escasas de recursos necesarios para su funcionamiento, puede ser que no tengas este producto, y para eso, VMCO va de maravilla.

Virtual Machine Computer Optimizer (VMCO) es un script y un módulo de Powershell que utiliza el módulo PowerCLI para capturar información sobre los hosts y las máquinas virtuales que se ejecutan en el entorno de vSphere, e informa sobre si las máquinas virtuales están configuradas de forma óptima en función de la CPU y la memoria del host. Marcará una máquina virtual como "TRUE" si está optimizada y "FALSE" si no lo está. En el caso de las máquinas virtuales no optimizadas, se realiza una recomendación que mantendrá el mismo número de vCPU configuradas actualmente, con el número óptimo de núcleos virtuales y sockets.

Es importante tener en cuenta que VMCO no analizará si las máquinas virtuales están configuradas con el número correcto de vCPU en función de la carga de trabajo de la máquina virtual. Una herramienta de análisis más detallada, como VMware Aria Operations Manager, puede determinar el tamaño adecuado en función de la carga de trabajo y el rendimiento real. Pero como herramienta de consulta para un primer paso a un correcto dimensionamiento, es perfecta.
Otro punto importante: VMCO no realiza ninguna modificación. Sólo consulta los objetos existentes para generar un informe, no reconfigura máquinas.

Puedes descargar VMCO desde AQUI.


La utilización de la herramienta es bastante simple, ejecutas el script de PowerShell, y éste instalará los complementos necesarios. Necesitarás también una cuenta de usuario de tu entorno del vCenter con permisos de lectura y la opción "propagate to children" habilitada, según la documentacion. Vaya, que estos permisos se encuentren sobre todos los elementos, para poder acceder a todos los objetos necesarios. 


Para su instalación, desde la ruta en la que tenemos el archivo PS1, ejecutamos".\Virtual_Machine_Compute_Optimizer_v3.0.0.ps1"

 A mi me ha dado guerra la instalación de los módulos directamente con el script. Si te pasa lo mismo, instala primero los modulos, y luego ejecutas el script. Para ello, ejecuta primero:

Install-Module -Name VMCO -Scope CurrentUser

Install-Module Vmware.VimAutomation.Core

Y después, ya ejecutas .\Virtual_Machine_Compute_Optimizer_v3.0.0.ps1

Este script generará un documento en formato CSV con distintos datos como el nombre del vCenter, detalles del cluster, detalles del host, detalles de las VMs... pero lo mas interesante, es este apartado:



En la columna de VMOptimized te indica si está optimizada o no, y en las siguientes columnas te indica las recomendaciones de cómo deberían configurarse las VMs para optimizar rendimiento.

Realmente la parte vital de esto es el modulo VMCO, de manera que si te las apañas con PowerShell, puedes realizar directamente consultas a este módulo, que lo que hace es habilitar la función Get-OptimalvCPU.

Aquí tienes varios ejemplos de lo que puedes obtener con dicho comando de PowerShell:

Obtiene todas las máquinas virtuales de vCenters conectadas actualmente
Get-OptimalvCPU

Exporta los resultados a csv

Get-OptimalvCPU | Export-CSV -path "c:\temp\vNUMA.csv" -NoTypeInformation

Abre los resultados en una ventana de cuadrícula - solo sistema operativo Windows
Get-OptimalvCPU | Out-GridView

#Gets resultados solo en la máquina virtual denominada
 "MyVmName"Get-OptimalvCPU -vmName "MyVmName"

#Gets resultados en cualquier máquina virtual con "NY-DC" en su nombre

get-optimalvCPU -vmName (get-vm -name "*NY-DC*")

#Returns toda la información de vCenter, clúster y VMHost
Get-OptimalvCPU -full

Genera informes basados en informes TDM de VMware TAM en formato JSON

Get-OptimalvCPU -tdmJsonFile <FilePath> | Export-CSV -Ruta "c:\temp\VMCO_Report.csv" -

NoTypeInformation



Si te ha gustado el articulo, puedes invitarme a un café ;)

martes, 14 de noviembre de 2023

VMware HealthAnalyzer

Una de las cosas que tiene VMware es que dispone de 1.000 herramientas para revisar su entorno. Vale, sobre todo de pago, y ahora integradas en la suite Aria, pero tienes otras tantas accesibles, como por ejemplo, Skyline Health Diagnostics, o la que vamos a ver, VMware HealthAnalyzer, una herramienta más potente, a su manera.

Si con Skyline podemos realizar un análisis de los logs de la infraestructura, HealthAnalyzer automatiza la recopilación y el análisis del inventario de VMware Horizon, VMware vSphere y NSX, incluidos los datos de configuración y utilización.

Genera descubrimientos y observaciones, sugiere calificaciones y te brinda la posibilidad de ajustar calificaciones y observaciones conforme a los datos organizados según las prácticas recomendadas de revisión de estado. A través de la interfaz web de HealthAnalyzer, puedes revisar los datos recopilados y generar un informe de revisión de estado. Los datos obtenidos por VMware HealthAnalyzer se clasifican siguiendo las mejores prácticas recomendadas.

Los datos que proporciona HealthAnalyzer los puedes obtener de 3 diferentes productos: vSphere, Horizon y NSX. Luego, esos datos puedes exportarlos ya tratados en Word para una más fácil revisión de los mismos

Actualmente van por la versión 5.6.2 de Septiembre de 2023, y ya viene con el problema del java log4j solventado. Lógico, si tenemos en cuenta que podemos instalarlo de 2 formas distintas, y una de ellas es como programa Java sobre un equipo Windows o Mac. La otra manera es como appliance. De ambas maneras el proceso de despliegue y uso es muy simple:


Esta herramienta tiene un gran handicap, y es la obtención para su uso. Y de nuevo las comparaciones...igual que Skyline se puede obtener fácilmente y viene incluida en prácticamente cualquier paquete de licencias que adquieras de VMware, HealthAnalyzer es sólo accesible a partners de VMware, desde este ENLACE.

jueves, 9 de noviembre de 2023

Como conectar el Cloud Gateway de vSphere+

VMware está de cambios, y uno de ellos son las nuevas versiones "+" de sus productos. Por ejemplo, vSphere, un clásico, suma un "+", que nos da una capa de gestión en la nube, con varias ventajas, como son el gestionar entornos de distintas ubicaciones en un único portal web. Y para ello, solo nos pide el despliegue de un appliance en cada localización con un vCenter.

Para que podamos establecer conexión tenemos una serie de requisitos previos muy simples:

  • Conexión a internet: a pesar de que los vCenter Server no están conectados a Internet (y no deben estarlo), el dispositivo Cloud Gateway requiere acceso a Internet para poder comunicarse con VMware Cloud 
  • Puertos de firewall: algunos puertos deben estar abiertos (principalmente el puerto 443) para las comunicaciones adecuadas hacia y desde el dispositivo Cloud Gateway
  • Recursos: debe haber suficientes recursos (memoria, CPU, almacenamiento) en el clúster en el que se implementará el dispositivo Cloud Gateway

Antes de comenzar, tendremos que crear una conexión entre VMware Cloud Gateway y VMware Cloud.

Para ellos vamos a la web del cloud gateway que hemos desplegado, en este ejemplo, los datos de nuestro cloud gateway son: https://cloud-gateway01.corp.local:5480/gw-platform y pulsamos "get started". Una vez entramos, vemos 2 opciones: conectar el gateway a VMware Cloud, y conectarlo a un vCenter server o una instancia VCF. Empezaremos por configurar la conexion a la nube, así que en el cuadro de Connect VMware Cloud Gateway, pulsamos connect:



Nos lleva a la pantalla de inicio:


Nos puede dar acceso, o nos puede facilitar un código de registro único, como en este ejemplo:


Copiamos el código y lanzamos la ventana de VMware Cloud. Introducimos nuestros datos de acceso,


Nos pedirá la organización a la que conectar. Seleccionamos, y confirmamos. 



Ahora es cuando nos pedirá el valor inicial



Se lo toma con un poco de calma. Una vez creada la conexión de vCenter Cloud Gateway, ahora podemos iniciar sesión en Cloud Gateway y conectar los servidores a VMware Cloud.



Iniciamos sesión en VMware Cloud Gateway con nuestras credenciales:



Veremos que ya tenemos configurada la conexión del gateway a la nube. Ahora la conectamos a nuestro vCenter server, o nuestro VCF, lo que proceda.


Accedemos en otra ventana a nuestro vCenter. Es posible que nos salga una ventana para instalar un plugin. Indicamos que si.


Accedemos a nuestro vCenter con nuestro admin local,


Localizamos en nuestra infra el DNS name que tiene nuestro vCenter Server y lo copiamos



Nos volvemos a nuestra pestaña del cloud-gateway,  donde nos quedamos en el registro de instancias de vCenter, y pulsamos sobre Add vCenter Servers:


Introducimos el nombre DNS de nuestro vCenter, y como user y pass para la conexión, la cuenta de administrator@vsphere.local, y pulsamos sobre Add vCenter


Nos saltará una alerta de seguridad, sobre la que pulsaremos "connect",


Nos aparecerá nuestro vCenter server para seleccionar, y pulsamos Next


Aceptamos condiciones, y pulsamos next


Es posible que nos devuelva a la pantalla de inicio del cloud gateway. Si es el caso, volvemos a acceder,


Y veremos que el vCenter ya nos aparece como conectado. Pulsamos sobre "go to VMware Cloud",


En la consola de VMware Cloud veremos que se ha agregado nuestro vCenter como SDDC


Si tenemos mas vCenter, es repetir los pasos anteriores de "connect new vCenter Servers".

Con esto, accediendo a VMware cloud, podremos ver las distintas instancias que hayamos conectado y gestionarlas desde este punto. Además, si tenemos otros productos "+" como el vSAN, se podrán gestionar también desde aquí.

Si te ha gustado el articulo, puedes invitarme a un café ;)