Demo
  • Home
  • Categorías
  • VMware Cloud Director

VM Auto Import en VMware Cloud Director 10.x

 

Hola, en este nuevo post revisaremos la funcionalidad de VMware Cloud Director, VM Auto Import para migración de VMs a una organización de nube.

Esta una funcionalidad permite a Cloud Director realizar un movimiento automatizado de cargas de trabajo, a continuación detallo algunas características del VM Auto Import:

  • VM Auto import es una funcionalidad que está disponible desde la versión de vCloud Director 8.20
  • El administrador del systema (system administrator) simplemente arrastrá las VMs dentro del resource pool correspondiente al datacenter virtual de organización vista en vCenter Server. 
  • VMware Cloud Director automáticamente descubre (discovery) las VMs y las importa. Las VMs pueden estar encendidas o apagadas.
  • Para cada VM importada, se crea una vApp especial separada con un prefijo Discovered. Si bien estas vApp se parecen a las vApp normales, no son vApp de vCloud Director reales hasta que se adoptan (adopted). La adopción tiene lugar cuando la VM dentro de la vApp se reconfigura de alguna manera después de importarla a vCloud Director para su administración.
  • Por defecto, la opción de descubrimiento de VMs está habilitada para todas las Organizaciones de VMware Cloud Director. Sin embargo, esta configuración puede ser activada o desactivada en las configuraciones de administración del sistema de vCD.

Diferencias entre Discovered vApp y Adopted vApp:

Discovered vApp

  • Solo se puede tener una Discovered vApp por VM
  • Cuando la VM importada se elimina en vCenter Server o Cloud Director, el objeto vApp se purga automáticamente.
  • Su propietario es System
  • No está sujeta a las configuraciones de recursos de la organización.

Adopted vApp

  • Es como una vApp normal de Cloud Director.
  • Puede tener varias VMs, redes de vApp, etc
  • se adopta una discovered vApp cuando se reconfigura.

Consideraciones para VM Auto Import

  • El proceso de discovery corre en background cada 3 minutos.
  • Por defecto, el reintento de importación cuando una VM falla es de 60 minutos. Este tiempo puede ser cambiado usando el comando CMT:
cell-management-tool manage-config -n managed-vapp.discovery.retry-delay-sec -v 25

Por ejemplo, se establece un tiempo de 25 segundos para el reintento.

  • Las VMs Fault Tolerant, VMs con procesos en vCS, VMs templates, VMs de Cloud Director. No puede ser importadas.
  • Las VMs a migrar tienen que estar conectadas a la red de organización a la cual se quiere migrar.
  • Por defecto, la antiguedad de la VM es de 1 hora, esto significa que las VMs que se reconfiguraron recientemente se omiten para la importación. Esto es para que las VMs se "asienten" primero. Se puede cambiar este valor usando el comanto CMT:
cell-management-tool manage-config -n VM_DISCOVERY_MIN_AGE_SEC -v 60

Por ejemplo, se establece el intervalo de 60 segundos para el minimal age. 

  • Las VMs mantienen su nombre y al momento de la migración, se coloca un identificador al final del nombre.
  • Es importante que el tiempo entre el vCS y el vCD estén sincronizados.

Para validar el proceso de migración podemos usar el comando CMT:

cell-management-tool debug-auto-import --vm "Nombre_VM"

Se presentan diferentes resultados:

 

Donde se puede definir que:

  • System could not find any reason for skipping. La VM no se encuentra más en el inventario de vCS o cambio el MOREF
  • VM in not present in a vCD managed resource pool. La VM está en vCS pero no está dentro del Resource Pool correspondiente al vDC de ORG
  • VM is a shell VM for an indepenent disk. La VM está usando discos independientes, son VMs Shadows o VMs que tengan reglas de DRS (dsrShellVMs) 
  • VM is already imported in vCD or is managed by vCD. La VM ya está siendo administrada por vCD.
  • VM is too recent to be considered for import or it should have a record of task in task_inv whose status is 3 (COMPLETE). La VM está siendo movida o debe esperar un tiempo para discovery nuevamente la VM.

Una vez que se validen todos los procesos se coloca una VM de prueba llamada "testUpgrade" para comprobar que la funcionalidad se realiace y efectivamente la VM se ha importado correctamente.

Finalmente, se recomienda revisar las VMs que estén siendo administradas por vCS pero que no están siendo administradas por vCD, esto puede ocasionar que se haga la Auto Importación aun cuando no se dese hacer una migración.

Migración de VMs hacia una organización nueva en VMware Cloud Director 10.x

Hola, en este nuevo post analizaremos un requerimiento específico que un cliente IaaS realizó a un proveedor de servicios, él solicita la migración de sus máquinas virtuales que viven en un centro de datos virtual / datacenter virtual de organización a otro centro de datos virtual / datacenter virtual de organización de la misma nube.

Para cumplir con este requerimiento se deben seguir algunos procesos, como primera parte, detallados en el KB2150423 para luego continuar con los trabajos de migración hacia el nuevo sitio virtual.

Consideraciones:

Para la migración de las VMs, se debe considerar los siguientes puntos.

  • Los procesos que se van a detallar a continuación, se realizan cuando se quiere mover las VMs a un diferente datacenter virtual de organización.
  • Pero existen otros motivos como son, querer remover las VMs de la administración de VMware Cloud Director.
  • Cuando se quiere migrar las VMs a una instancia diferente de VMware Cloud Director.
  • Y cuando se quiere administrar las VMs desde una plataforma de administración de nube diferente, como por ejemplo vRealize Automation.
  • Además, las VMs requieren ser apagadas.

Proceso 

El proceso de migración / movimiento de VMs entre dos datacenter virtuales de organización en una misma instancia de VMware Cloud Director, a continuación.

  • Se debe iniciar con el apagado de las cargas de trabajo que se desea mover.
  • Una vez apagadas, se procede a limpiar el parámetro UUID que coloca vCD en la VM para identificarla como suya. El parámetro se encuentra en configuraciones avanzadas de la VM.

  • Se identifica la ubicación de los archivos de la VM, paso importante que no debe evitarse.

  • Se procede a quitar del inventario a las VMs que se desea mover. SOLO remover, NO eliminar 

  • Se debe agregar nuevamente al inventario de vCS, cambiando el nombre de la VM y como buena práctica se recomienda cambiar el nombre de los archivos de la VM, proceso que se realiza con un storage vMotion. Para más información KB1029513. Es importante que NO se agregue la VM al mismo Resource Pool ni folder que es gestionado por vCD para evitar que la VM sea auto importada.

  • Como opcional, se puede resetear las MacAddress de las tarjetas de red virtuales.
  • Subir las VMs al nuevo centro de datos, colocarlas en el perfil de almacenamiento, cambiar de vAPP y agregar la red de organización. Mantener la dirección IP origen (se recomienda para evitar problemas con servicios del tenant).

  • Encender las VMs que se movieron, probar conectividad y funcionalidad. Eliminar las VMs originales, estas VMs ya no pueden ser operadas y cualquier trabajo sobre ellas nos dará un error.
  • Para finalizar, remover los límites y/o reservas que fueron configurados vía vCD.

Finalmente, Se recomienda seguir los pasos definidos en el KB, para evitar que los identificadores puedan desincronizar las bases de datos de Cloud Director y vCenter Server. 

Error deploy VMs o vApp en VMware Cloud Director 10.x

 

 Hola, en este nuevo post vamos a solventar un problema que sucede en VMware Cloud Director cuando se quiere crear o desplegar una nueva VM o vApp dentro de una organización. 

Indagando un poco en logs, podemos descubrir que existe una desconexión del servicio de vCD con la Base de Datos vPostgreSQL por sobrepasar el máximo de conexiones que se adminiten por defecto. Podemos validarlo en el KB57013

Por defecto se permiten hasta 75 conexiones, en este caso particular las conexiones sobrepasaron el valor por defecto permitido.

 

Como observamos, dentro del log vcloud-container-debug, se encuentra el error Pool Empty, unable to fetch a connection in 20 secondsindicando el límite de las conexiones.

Solución:

La solución para este evento es aumentar las conexiones máximas del servicio vCD hacia la Base de Datos vPostgreSQL. 

Primero debemos realizar el snapshot sin la habilitar la opción de snaptshot de memoria, este paso lo realizamos en todas las celdas de nuestro ambiente.

Ingresamos a la celda primaria de Cloud Director usando una conexión SSH.

Nos dirigimos a la ubicación de los archivos de configuración de Cloud Director.

Generamos un respaldo del archivo de configuración de Cloud Director.

Procedemos a aumentar al final del archivo la siguiente linea:

database.pool.maxActive = 200

El valor de 200 por ejemplo, es un valor que puede ser negativo como -1. Esto permitirán un ilimitado número de conexiones a la Base de Datos.

Y por último se reinician los servicios de las celdas o se reinician las VMs/celdas.

service vmware-vcd restart

Finalmente, este proceso debe realizarse en todas las celdas de VMware Cloud Director que se tengan.

Como remover una "Unresolved-VM" en Cloud Director

Hola, en este nuevo post vamos a hablar de como remover una máquina virtual "unresolved" en nuestro vCloud Director. Recientemente realice este soporte técnico en un cliente que es proveedor de servicios IaaS, el cual tuvo un problema relacionado con la BDD de vCD provocando que una VM quede en estado "unresolved".

Luego de haber realizado varios intentos de eliminación de la VM "unresolved" sin resultados óptimos, debemos trabajar con la BDD de vCD. Para lo cual es recomendable realizar un caso de soporte con VMware.

DISCLAIMER: El método que se realizó en este post es sobre la base de datos PostgreSQL de vCD, los pasos son básicos pero si no están familiarizados con BDDs Postgres, la recomendación es realizar un caso de soporte con VMware.

Solución:

Antes de iniciar, se recomienda realizar un snapshot de las celdas de vCD, no olvidarse desmarcar la opción de snapshot de memoria. 

Debemos iniciar con los accesos a la celda principal por protocolo SSH usando cualquier programa de tu gusto. Y procedemos a ingresar al usuario propietario de la BDD PostgreSQL de vCD, que por defecto es usuario postgres. Para luego ingresar a la BDD y a la instancia de BDD de vCD la cual es vcloud.

root@vcloud [ ~ ]# su - postgres
postgres [ ~ ]$ psql
postgres=# \c vcloud;

Luego de ingresar a nuestra BDD vcloud de las celdas, vamos a buscar a la VM o VMs con problemas y determinar en que estado se encuentra dicha VM en las tablas de la base, usando el siguiente query:

vcloud=# select * from vm_container where name like '%NOMBRE_DE_VM%';

En donde podemos observar que en la columna "creation_status" tenemos como estado "COPYING_CONTENTS" y "RESOLVED". Podemos identificar con el ID del evento en la VM "unresolved" que nuestra VM con problemas es la que tiene el estado "copying_contents".

Para estar seguros que no existan otras VMs con este mismo estado, corremos el siguiente query:

vcloud=# select * from vm_container where creation_status = 'COPYING_CONTENTS';

 

Identificando únicamente la VM con problemas cuyo ID es el mismo al del evento reportado de la VM "unresolved".

 

Con estos resultados, debemos borrar los datos de la tabla usando el siguiente query:

vcloud=# delete from vm_container where creation_status = 'COPYING_CONTENTS';

Volviendo a validar en la tabla si existen mas VMs con problemas solo encontramos la VM original que esta en producción:

Finalmente, revisando a nivel de HTML5 en la URL del cliente se valida que ya no existe la VM con problemas.

Nota, puede existir varias concatenaciones de tablas y ID foráneas que deben ser eliminadas en otras tablas, para lo cual es recomendable revisar el "sg_id" en las siguientes tablas:

vapp_vm;

vapp_vm_disk_storage_class;

vapp_vm_scalss_metrics;

vapp_logical_resource;

En conclusión: Debemos tener cuidado al momento de crear VMs a nivel de vCS, si la VM es creada en el resource pool de una organización podemos correr el riesgo que vCD haga un auto-import sin que nos demos cuenta y puede causar problemas de sincronización de las BDD.

Como remover una red de tenant desde base de datos en Cloud Director

Hola, en este nuevo post vamos a hablar de como remover una red de organización en nuestro vCloud Director. Recientemente realice este soporte técnico en un cliente que es proveedor de servicios IaaS, el cual realizó un mal procedimiento de eliminación de una Organización y un virtual Datacenter de Organización, provocando que una red de organización quede en estado "huérfana" y no pueda ser eliminada. Haciendo que toda la cadena de elementos padres (ORG y VDCORG) queden en estado de espera o con problemas sin resolver.

DISCLAIMER: El método que se realizó en este post es sobre la base de datos PostgreSQL de vCD, los pasos son básicos pero si no están familiarizados con BDDs Postgres, la recomendación es realizar un caso de soporte con GSS de VMware.

Solución:

Antes de iniciar, se recomienda realizar un snapshot de las celdas de vCD, no olvidarse desmarcar la opción de snapshot de memoria. 

Además, se recomienda parar los servicios y jobs encolados de las celdas, colocarlas en modo mantenimiento estaría mejor usando los siguientes comandos:

$VCLOUD_HOME/bin/cell-management-tool -u administrator cell --quiesce true

$VCLOUD_HOME/bin/cell-management-tool -u administrator cell --maintenance true

Debemos iniciar con los accesos a la celda principal por protocolo SSH usando cualquier programa de tu gusto. Y procedemos a ingresar al usuario propietario de la BDD PostgreSQL de vCD, que por defecto es usuario postgres. Para luego ingresar a la BDD y a la instancia de BDD de vCD la cual es vcloud.

root@vcloud [ ~ ]# su - postgres
postgres [ ~ ]$ psql
postgres=# \c vcloud;

Luego de ingresar a nuestra BDD vcloud de las celdas, vamos a ejecutar los siguientes queries:

vcloud=# DELETE FROM network_interface WHERE lnet_id IN (SELECT id FROM logical_network WHERE name IN 
('Nombre_de_la_red'));

vcloud=# DELETE FROM gateway_assigned_ip WHERE gateway_interface_id IN (SELECT id FROM gateway_interface 
WHERE logical_network_id IN(SELECT id FROM logical_network WHERE name IN ('Nombre_de_la_red')));

vcloud=# DELETE FROM gateway_interface WHERE logical_network_id IN (SELECT id FROM logical_network 
WHERE name IN ('Nombre_de_la_red'));

vcloud=# DELETE FROM logical_network WHERE link_lnet_id IN (SELECT id FROM logical_network WHERE name IN ('Nombre_de_la_red'));

vcloud=# DELETE FROM logical_network_ip_scope WHERE logical_network_id IN (SELECT id FROM logical_network 
WHERE link_lnet_id IN(SELECT id FROM logical_network WHERE name IN ('Nombre_de_la_red')));

vcloud=# DELETE FROM shared_org_vdc_network WHERE lr_id IN (SELECT id FROM logical_network WHERE name IN ('Nombre_de_la_red'));

vcloud=# DELETE FROM logical_network WHERE name IN ('Nombre_de_la_red') AND scope_type=2;

vcloud=# DELETE FROM vdc_logical_resource WHERE lr_type = 'NETWORK' AND name IN ('Nombre_de_la_red');

En donde podemos observar que existen 6 elementos de la base de datos que están atados a esta red de organización, estos elementos ya no existen en la organización pero quedaron "pegados" en estas tablas.

Luego de realizar estos pasos se reestablece el servicio de vDC y se hacen las revisones que la red de organización con problemas haya sido eliminada por completo, usando el comando:

$VCLOUD_HOME/bin/cell-management-tool -u administrator cell --maintenance false

Nota, puede existir varias concatenaciones de tablas y ID foráneas que deben ser eliminadas en otras tablas, por lo general sucede este problema cuando la red de organización estaba compartida para todos los VDC de Organización:

Se debe eliminar el ID de la red en la tabla de BDD shared_org_vdc_network usando el siguiente query:

vcloud=# DELETE FROM shared_org_vdc_network WHERE lr_id = 'ID DE RED';

Donde el ID de la red es el que hace referencia entre las dos tablas de BDD y nos indica que es la red compartida que deseamos eliminar.

En conclusión: Debemos tener cuidado al momento de eliminar elementos en una Organización, se deben tener procesos claros y seguir la buenas prácticas de eliminación de redes y VMs.

Configuración de SSL VPN-Plus con NSX Edge

Hola, en este nuevo post vamos a configurar una VPN SSL para que los usuarios remotos puedan tener una conexión segura a una red privada de organización a través de un NSX EDGE. Los usuarios remotos podrán tener acceso remoto a servidores y aplicaciones de la red privada de organización.

Antes de iniciar, se recomienda mirar los requisitos previos y compatibilidades de sistemas operativos soportados con el cliente SSL VPN-PLUS de NSX EDGE para ello nos guiamos de la siguiente tabla: (más información, SSL VPN-Plus Overview)

SISTEMA OPERATIVO VERSIONES SOPORTADAS
Windows 8, 10 (including Windows 10 Secure Boot option enabled)
Mac OS Sierra 10.12.6
Mac OS High Sierra 10.13.4
Mac OS Mojave 10.14.2 to 10.14.6 (supported in NSX 6.4.4 and later) 
Linux Fedora 26, 28
Linux CentOS 6.0, 7.5 
Linux Ubuntu 18.04 

Importante:

  • El Cliente SSL VPN-PLUS no es soportado en computadores que usan procesadores ARM.
  • Asegurarse que la última versión de controlador Npcap (0.9983 o superior) esté instalado en el computador Windows, si tenemos una versión antigua, la función de reconexión automática no funcionará correctamente.
  • Para que la interfaz de usuario funcione en Linux, debemos instalar las siguientes librerías: Linux TCL, TK y Network Security Services (NSS).

Configuración de servicio de autenticación:

Para iniciar con la configuración, nos dirigimos al NSX EDGE de nuestra organización y el damos click en servicios, que desplegará la pantalla de administración y en la pestaña SSL VPN-PLUS y luego en Autenticación creamos una política de autenticación de acuerdo a las necesidades y normas de seguridad de cada organización.

Habilitamos la política de contraseñas, la política de bloqueo de cuentas y por último el estado de la política de autenticación.

Verificamos que se hayan realizado los cambios:

Habilitar y configurar servidor SSL:

Nos ubicamos en la pestaña configuración de servidor y procedemos a habilitar, escogemos la dirección IP Pública que el NSX EDGE tiene configurada como puerta de enlace público y recomiendo cambiar el puerto de comunicación que en nuestro ejemplo es el 60003 TCP, escogemos el método de cifrado y habilitamos la política de Logging.

Esta configuración creará automáticamente una regla de firewall habilitando el puerto colocado en este caso 60003 en donde se ata el servicio de SSL VPN.

Configuración de Pool de IPs:

Una vez que el servidor SSL VPN se haya habilitado, seleccionamos la pestaña de IP Pools para crear un rango de IPs que será usado por la VPN, agregando un rango de IPs en nuestro ejemplo 192.168.200.0/24 con un pool 192.168.200.100-192.168.200.120 y gateway 192.168.200.1. Las opciones de DNS no son requeridas por el momento.

Habilitamos el grupo para que pueda ser usado por el servidor SSL VPN y damos en OK.

Verificando que las configuraciones se muestran continuamos.

Configuración de redes privadas:

En este paso tenemos que dar permiso de conectividad a las redes internas de organización que deseamos acceder, para ello agregamos una nueva red privada, colocamos la red que deseamos ingresar en nuestro ejemplo 192.168.100.0/24, escogemos Over Tunnel y habilitamos.

Luego de la configuración se comprueba que estén los cambios.

Configuración de Usuarios:

Seleccionamos la pestaña de usuarios y agregamos una cuenta de usuario para la conectividad de la VPN-PLUS SSL, se configuran las opciones de contraseña y se habilita al usuario para que pueda conectarse a través de la VPN. En nuestro caso el usuario es uservpn

Configuración de paquete de instalación:

Vamos a configurar el instalador que será descargado por el usuario habilitado, este se instala en el sistema operativo y nos ayudará con la conexión a la VPN. Considerar que si se hacen cambios en los gateways o puertos de servicio de la VPN que configuramos previamente, debemos generar otro paquete de instalación. Habilitamos cualquier parámetro necesario que se requiera (depende del administrador de la Organización).

Se da click en la pestaña paquete de instalación y agregamos un nuevo perfil.

Revisamos que este creada la política y habilitada.

Configuración de Cliente VPN:

En la pestaña de configuración de cliente se configura las opciones del cliente de VPN, el modo túnel debe estar configurado en Split para permitir conexiones simultaneas, pero se puede colocar en modo full si así demanda la aplicación. Se puede configurar exclusiones de subnets en este apartado.

Configuración general:

Se pueden tener otras opciones generales para la conectividad de los usuarios de la VPN, como por ejemplo: evitar varias sesiones de VPN con un mismo usuario o forzar teclados virtuales, tiempos de inactividades de conexión y habilitación de registros. Depende del administrador de la Organización. 

 

Una vez finalizados los pasos en el lado de la Nube, procedemos a descargarnos el instalador a través de la pagina Web configurada previamente y la instalación del cliente SSL VPN-PLUS de NSX EDGE.

Colocando la dirección IP pública y puerto que definimos y configuramos previamente, colocamos el usuario y contraseña habilitado para ingresar a la VPN.

Colocando las credenciales, procedemos a descargar el instalador configurado previamente, este instalador contendrá los datos para la comunicación con la VPN-PLUS SSL.

 

Una vez instalado el Cliente en nuestro PC, vamos a conectarnos con las credenciales que hemos configurado. 

La conexión se establece y podemos validar en el ícono de la barra de tareas que esté conectado.

Luego damos click derecho y procedemos a verificar las estadísticas de conexión.

Finalmente,

Las configuraciones varían de acuerdo a las políticas internas del cliente y a los clientes que el administrador va a generar.

La conexión SSL VPN-PLUS se la realizará usando el enlace de internet contratado, tomar en cuenta el correcto dimensionamiento del ancho de banda.

 

Más artículos...

Este Blog usa cookies propias y de terceros para optimizar la navegación y que puedas ver correctamente su contenido. Si permaneces en el sitio asumiremos que estas de acuerdo .