Cannot open the disk '/User/XXXX/Virtual Machines.localized/YYYY.vmwarevm/Disco Virtual.vmdk' or one of the snapshot disk it depends on.`
Module 'Disk' power on failed. failed to start the virtual machine
Procedimiento
Buscar la VM en la siguiente ruta que te indica el error. De forma predeterminada, los paquetes de máquinas virtuales se almacenan en Macintosh HD/Users/User_name/Documents/Virtual Machines. Según la versión de Fusion y la configuración de Mac OS, el nombre de esta última carpeta puede ser Virtual Machines.localized.
Nota: Las máquinas virtuales que se ejecutan desde particiones de Boot Camp se almacenan en Macintosh HD/Users/User_name/Library/Application Support/VMware Fusion/Virtual Machines/Boot Camp. Aquà solo se almacenan los archivos de configuración de máquinas virtuales de Fusion para la partición de Boot Camp; Fusion utiliza la partición de Boot Camp como disco virtual.
Una vez localizado el archivos de la VM, vamos a hacer clic derecho sobre el y despues Show Package Contents
La acción anterior nos llevará a un nuevo directorio donde debemos localizar las carpetas con el nombre .lck al final, en este caso tengo dos carpetas
Por último, solo debemos eliminar esas carpetas y volver a intentar el Power On de la máquina virtual en VMware Fusion
¡Y eso es todo amigos! Con este procedimiento vas a poder desbloquear una Máquina Virtual (VM) en VMware Fusion que por X o Y razón resultó bloqueada!
¡IMPORTANTE! He migrado blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artĂculo deja tu buen Like y compártelo con tus colegas, estas aciones me ayudarán a optimizar los motores de bĂşsqueda para llegar a más personas.
Si tienes un ambiente de NSX 4.1.x o superior, has llegado un dĂa a la oficina y te has encontrado con un montĂłn de alertas de certificados expirados. ¡Este post es para ti!
Contexto
El entorno ejecuta NSX 4.1.0.2 o superior y se actualizĂł desde NSX-T 3.2.x.
Las alarmas de NSX indican que los certificados han expirado o están a punto de expirar.
Los certificados que vencen contienen «Corfu Client» en su nombre.
Causa
Hay dos factores principales que pueden contribuir a este comportamiento:
Nota: En NSX 4.1.x, no hay impacto funcional cuando caduca un certificado interno. Sin embargo, las alarmas seguirán activándose y esto es lo que verás si estás frente esta situación, que podrás solucionar en menos de 5 min.
SoluciĂłn
Siguiendo el KB NSX alarms indicating certificates have expired or are expiring nos dice que existe un script en Python que resuelve este problema como por arte de magia. Para ello solo necesitamos una VM con python instalado. La buena noticia es que el vCenter Server ya tiene los mĂłdulos que necesitamos para ejecutar estos scripts, asĂ que no vamos a tener que desplegar nada, solo cargar el script al vCenter Server Appliance y lanzarlo desde ahĂ. Para mayor informaciĂłn por favor revisar el KB indicado anteriormente.
Hacer login al vCenter Server con el usuario root y navegar hasta la carpeta /tmp. Una vez aquĂ simplemente ejecutamos el siguiente comando
python3 replace_certs_v1.7.py
Nota: Lo Ăşnico que tenemos que hacer es responder a las preguntas que nos realiza el script.
Resultado
Una vez finaliza la ejecuciĂłn del script, aproximadamente 30 minutos en el laboratorio, podemos ver que todas las alertas de certificados se han corregido.
Si revisamos el certificado de uno de los NSX Manager, podremos ver que su fecha ha sido actualizada.
Nota para las versiones NSX 4.1.2 o anteriores: debido a problemas de permisos de carpetas y archivos, es posible que el script no reemplace los certificados en la primera ejecuciĂłn y los intentos posteriores sĂ los reemplacen. AsegĂşrese de ejecutar el script una segunda vez en caso de que no funcione la primera vez.
Nota para VCenter 8.0 U3: este script puede fallar en vCenter 8.0 U3 debido a problemas de incompatibilidad. Puede fallar con el error: SshCommandExecutor: An error occurred: [digital envelope routines] unsupported Unable to SSH to '192.168.x.x'. Please fix it and rerun the script SoluciĂłn: use una versiĂłn diferente de vCenter o utilice un dispositivo Linux diferente con los componentes necesarios para ejecutar el script.
¡IMPORTANTE! He migrado blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artĂculo deja tu buen Like y compártelo con tus colegas, estas aciones me ayudarán a optimizar los motores de bĂşsqueda para llegar a más personas.
ATENCIĂ“N!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
Como todos sabemos, todos los productos y soluciones de VMware by Broadcom ahora se centran el marco de VMware Cloud Foundation (VCF) y VMware vSphere Foundation (VVF). Sin embargo, existe aĂşn mucha confusiĂłn con respecto a cĂłmo son cuantificadas las licencias requeridas para el ambiente teniendo en cuenta el modelo de subscripciĂłn de Broadcom.
1. Licenciamiento VCF/VVF por subscripciĂłn requerido para el ambiente
Lo primero que debemos tener presente es que el modelo de suscripciĂłn se basa en la cantidad total de cores fĂsicos, de cada CPU en todos los hosts ESXi asociados con las instancias de VCF o vCenter Server que los clientes planean licenciar con VCF o VVF.
Sin embargo, existe una reglar que indica que los clientes deben adquirir una capacidad de licencia mĂnima de 16 cores por CPU.
Pero además de esto, la cantidad de licencias por subscripción requeridas debe ser la mayor entre el resultado de las siguientes dos operaciones:
1) Qta Licencias Subscripcion VCF/VVF: [NĂşmero de nĂşcleos por CPU] Ă— [NĂşmero de CPU por host ESXi] Ă— [NĂşmero de hosts ESXi]
2) Qta Licencias Subscripcion VCF/VVF: [16 nĂşcleos] x [nĂşmero total de CPU por host ESXi]
Nota: Esto no significa que las licencias se vendan en paquetes de 16, sino que es más bien el mĂnimo de licencias por subscripciĂłn que un cliente puede comprar.
2. Licenciamiento para vSAN por subscripciĂłn requerido para el ambiente
Por otro lado, tenemos el caso del licenciamiento para vSAN, pero este es otro asunto un poco diferente, debido a que aquĂ el licenciamiento depende en primera instancia de si vamos a utilizar VCF o VVF.
Escenario vSAN con VCF
Comencemos por el escenario en el cual vamos a licenciar vSAN para VCF (VMware Cloud Foundation). AquĂ el licenciamiento está definido en TiB (tebibyte), y en este caso la cantidad de licencias de vSAN se basa en el almacenamiento fĂsico total RAW (TiB) reclamado por vSAN en todos los hosts ESXi en cada clĂşster de vSAN asociado con las instancias de vCenter Server o VCF que los clientes planean licenciar para vSAN.
Nota: Para los que no se acuerda, el Terabyte utiliza el sistema decimal y equivale a 1 billón de bytes, mientras el Tebibyte (TiB) utiliza el sistema binario y equivale a 1.099.511.627.776 bytes o lo que es lo mismo 1024 GiB (Gibibyte), que es como normalmente todos en TI lo asociamos. Es más un tecnicismo y cuestión de acostumbrarnos a colocar las siglas correctas.
Dicho esto, podrĂamos utilizar la siguiente expresiĂłn para definir la cantidad de licencias por subscripciĂłn necesarias para vSAN en un ambiente de VCF.
Qta licencias Subscripcion vSAN (en VCF) = [NĂşmero total de TiB reclamados por vSAN en cada host ESXi] x [nĂşmero de hosts ESXi en cada clĂşster].
De esta manera, cada TiB que reclama vSAN requiere una Ăşnica licencia. A diferencia del licenciamiento por subscripciĂłn de VCF, donde mĂnimo debĂamos adquirir 16 licencias, para este caso de vSAN, NO existe un mĂnimo.
Algo importante a resaltar, es que el licenciamiento por subscripciĂłn de VCF provee el derecho a 1 TiB de vSAN por cada licencia de core de VCF adquirida. Esto quiere decir que si el nĂşmero de TiB que necesita el ambiente es menor o igual al nĂşmero de licencias de core de VCF, el cliente no debe adquirir licenciamiento de vSAN adicional. Por otro lado, si el nĂşmero de TiB que necesita el ambiente es superior al nĂşmero de licencias de core adquiridas, probablemente deba adquirir licenciamiento adicional para vSAN Ăşnicamente.
Resumiendo el párrafo anterior, podrĂamos expresarlo de la siguiente forma:
1) (Qta Licencias subscripcion VCF) <= Numero de TiB requereridas por el ambiente, entonces no requiere licencias adicional de vSAN
2) (Qta Licencias subscripcion VCF) > Numero de TiB requereridas por el ambiente, entonces se requiere licencias adicional para vSAN
Nota: Para ver todos los ejemplos disponibles, lo invito a revisar el link anterior.
Escenario vSAN con VVF
Por otro lado, tenemos el escenario en el cual vamos a licenciar vSAN para VVF (VMware vSphere Foundation) . AquĂ el licenciamiento está definido en GiB (Gibibyte), y en este caso la cantidad de licencias de vSAN se basa en el almacenamiento fĂsico total RAW (GiB) reclamado por vSAN en todos los hosts ESXi en cada clĂşster de vSAN asociado con las instancias de vCenter Server o VVF que los clientes planean licenciar para vSAN.
Cuando estamos licenciando para VVF, tenemos derecho hasta 100 GiB de vSAN de prueba, por cada licencia por subscripciĂłn de core adquirida. Es decir si adquirimos 16 licencias de core para VVF tendrĂamos derecho a 16 x 100 GiB = 1600 GiB = 1.5624 TiB.
Nota: Aunque acá la referencia es GiB, es mejor convertirlo a TiB para mayor facilidad.
De esta manera, si los clientes exceden la cantidad de capacidad de prueba de vSAN en el clĂşster de vSAN, deben licenciar la cantidad total de TiB reclamados en el clĂşster de vSAN comenzando desde 0.
Dicho esto, la expresiĂłn para calcular la capacidad máxima trial de vSAN para VVF serĂa la siguiente:
Capacidad vSAN trial (en VVF) = [Qta de licencias de nĂşcleo de vSphere Foundation en cada host ESXi implementado en el clĂşster de vSAN] x [100 GiB] / 1024
Nota: De nuevo acá, dividimos por 1024 para convertir la capacidad a TiB y hacer una comparación más sencilla.
3. Herramienta para consolidar la informaciĂłn de la cantidad de licencias
Como entendemos que contar la cantidad de licencias en nuestro ambiente puede ser una tarea aburrida, VMware By Broadcom ha puesto a disposiciĂłn una herramienta (script) para identificar la cantidad de licencias por Core (con un mĂnimo de 16 cores por CPU fĂsica) y licencias TiB que se requieren para licenciar correctamente los siguientes productos VMware: VMware Cloud Foundation (VCF), VMware vSphere Foundation (VVF) y VMware vSAN.
Nota: VMware Cloud Foundation y VMware vSphere Foundation requieren licencias por core para todos los cores fĂsicos en cada CPU que ejecute el software. OJO! En caso de que los usuarios deshabiliten los nĂşcleos de CPU fĂsicos en la configuraciĂłn del BIOS o por otros medios, el script puede producir resultados inexactos. Por lo tanto, todos los nĂşcleos fĂsicos deben estar activados en cada CPU del host al ejecutar el script.
Los requerimientos para ejecutar el script son los siguientes:
VMware PowerCLI 10.x o superior instalado.
En la VM donde se instalĂł el PowerCLI, abrir una consola de PowerShell y ejecutar el siguiente comando Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypas
Nota: Sin nunca has instalado PowerCLI, ¡No has sido un verdadero guerrero, bienvenido al campo de batalla! Es broma, no te preocupes solo revisa el artĂculo Install PowerCLI si tu VM tiene salida a internet o si no tienes salida a internet entonces usa el siguiente artĂculo Install PowerCLI Offline. Aunque para evitarte la fatiga, te dejo abajo la instalaciĂłn para cuando tenemos salida a internet en la VM.
InstalaciĂłn de PowerCLI
Verificar la versión de PowerShell que tenemos instalada y verificar la Compatibility Matrix de PowerCLI. Sino tenemos la versión correcta de PowerShell indicado en los prerrequisitos de la matriz de compatibilidad (para la versión PowerCLI 13.3), vamos a tener que instalar la nueva versión siguiendo la documentación de Microsoft Installing PowerShell on Windows
Nota: Si el comando anterior les da el error cannot be loaded. The file xxxx.psm1 is not digitally signed. You cannot run this script on the current system. For more information abut running scripts and setting execution policy, see about_Execution_Policies at htt;s//microsoft.... Solo ejecute el siguiente comando Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass y vuelva a intentar el import.
Ejecute la función Get-FoundationCoreAndTiBUsage y especifique el tipo de implementación para traer los resultados. De manera predeterminada, el script iterará por todos los clústeres de vSphere. Get-FoundationCoreAndTiBUsage -DeploymentType VCF Get-FoundationCoreAndTiBUsage -DeploymentType VVF
Desconectarse del vCenter Server: Disconnect-VIServer -Server IP_FQDN_vCenter_Server
¡Y eso es todo amigos! Con esta sencilla herramienta podremos verificar la cantidad de licencias VCF/VVF y vSAN que necesitamos en el ambiente.
¡IMPORTANTE! He migrado el blog del dominio nachoaprendevirtualizacion.com a nachoaprendeit.com. Si te ha servido este artĂculo deja tu buen Like y compártelo con tus colegas, estas acciones me ayudarán a optimizar los motores de bĂşsqueda para llegar a más personas.
En esta oportunidad vamos a explicar un sencillo procedimiento para poder migrar notas desde la herramienta Microsoft OneNote a Obsidian. La version para macOS tiene cierta limitante y diferencias comparada con la version para Windows y es la razĂłn principal por la que muchas veces necesitamos un sustituto para gestionar nuestras notas.
En resumen, ese fue una alerta para sacar mi informaciĂłn de esa herramienta lo mas pronto posible. Como moraleja, NO confĂen su informaciĂłn valiosa a Microsoft OneNote!
Debido a que nuestro objetivo es migrar nuestras notas de Microsoft OneNote (macOS) a Obsidian (macOS), debemos sacar una copia de la carpeta que contiene las copias de seguridad de Microsoft OneNote en nuestro Mac.
(Si usamos macOS) Vamos a la aplicaciĂłn Microsoft OneNote -> OneNote -> Preferences…
Click en Backup
Click en Open Backup Folder
Dentro de esta carpeta podemos ver todas las Secciones que tenemos dentro de nuestro notebook. En este caso el notebook que me interesa migrar es el que dice bloc de notas de diego Felipe.
En este punto debemos sacar una copia de toda la carpeta o de los archivos con extension .one que deseamos migrar con el script.
Nota: Ten presente esta carpeta si vas a utilizar un hipervisor dentro de tu mac, o copia este contenido a una Memoria Externa si vas a usar otro dispositivo Windows para ejecutar el script. Para este caso he creado una carpeta compartida con la VM y asĂ poder leerla desde el OS Windows.
Verificar la ruta de instalaciĂłn de OneNote en Windows
Una vez dentro del equipo con Sistema Operativo Windows, sea este una maquina virtual u otro equipo fĂsico, debemos por supuesto instalar el Microsoft OneNote si es que no lo tenemos ya instalado.
Lanzamos la aplicaciĂłn y vamos a Archivo -> InformaciĂłn, para verificar la ruta default de la carpeta My Notebook, donde se almacenan los archivos .one.
Mover Copias de seguridad a la carpeta de My Notebook
para mover los archivos .one desde las copias de seguridad de Microsoft OneNote (macOS) a nuestro dispositivo fĂsico o virtual basado en Windows, tenemos dos opciones:
OpciĂłn 1
Simplemente copiamos todas los archivos que vimos en las copias de seguridad de OneNote (macOS), a la ruta que acabamos de verificar para el OneNote (Windows). En la imagen anterior vemos que la ruta para este caso es C:\user\Administrator\Documents\OneNote Notebooks\My Notebook. PodrĂa ser diferente de manera que recomiendo revisarla primero.
OpciĂłn 2
Dentro de OneNote (Windows) vamos a Archivo -> InformaciĂłn -> Abrir copias de seguridad
y seleccionamos desde nuestra Memoria Externa, o carpeta compartida, todos los archivos que queremos migrar a Obsidian.
Nota: La Opcion 1 y Opcion 2 generan el mismo resultado.
Abrir el OneNote Windows y verificar que vemos las secciones correctamente
Una vez hemos agregado los archivos .one que me interesan migrar, dentro de la carpeta My Notebook, podemos ver que dentro de la aplicaciĂłn Microsoft OneNote aparecen cada una de las Secciones con sus correspondientes Paginas.
Nota: En este punto recomiendo, ordenar la paginas por orden de creaciĂłn con el fin de tener una consistencia con el orden en el que serán migradas en Obsidian, para esto podrĂamos utilizar alguna de las macros de Onetastic, que es básicamente una extensiĂłn para OneNote que permite automatizar tareas.
Ejecutar el script ConvertOneNote2Markdown
Abrir una ventana de PowerShell y navegar hasta la ruta donde dejamos descargado el script desde GitHub utilizando el comando cd.
Para lanzar el script basta con ejecutar el comando .\ConvertOneNote2MarkDown-v2.ps1
Una vez ejecutado el script, debemos comenzar a responder a cada uno de los inputs con los siguientes datos que me han funcionado de manera correcta:
Por default la ruta de destino de la conversion sera c:\temp\notes pero podemos elegir una diferente
Cuando utilizamos el metodo de conversion por default podriamos experimentar que todas las imagenes migradas desde oneNote quedan con un caption similar al siguiente {width="12.072916666666666in" height="6.65625in"} para evitar esto ver aquĂ) o configurar el siguiente valor en el input `conversion = ‘gfm+pipe_tables-raw_html’
Para comprender mejor lo que significa cada opciĂłn podemos leer la documentaciĂłn del script que se encuentra en el mismo link de descarga.
Una vez terminamos de responder a cada uno de los imputos, comienza el proceso de migraciĂłn.
Resultado de la EjecuciĂłn
Como resultado de la ejecuciĂłn vamos a tener una vista como la siguiente, donde podemos ver que el script se ha ejecutado de manera satisfactoria y sin errores. Si en este punto obtiene algunos errores por lo general estan asociados a la falta de memoria RAM del equipo Windows donde esta ejecutando el script.
Verificar resultados
En mi caso tenia demasiadas notas asĂ que decidĂ hacer la migraciĂłn en oleadas. Esto significa que copiaba a la carpeta de My Notebook en OneNote (Windows) no mas de 20 archivos .one, esto debido a que algunas de mis notas tenian demasiado contenido y podia tardar horas la migraciĂłn y eventualmente generar un error por falta de memoria en la maquina virtual windows que estoy usando. AsĂ que si tienes notas muy grandes, recomiendo migrar las notas por grupos.
El resultado de la migraciĂłn, como lo comente anteriormente, aparece por default en c:\temp\notes. Sin embargo, esta ruta puede ser especificada cuando lanzamos el script e ingresamos el valor del input notesdestpath:
Nota: Es importante notar que antes de iniciar con un grupo nuevo, debemos eliminar las secciones que ya migramos desde la interface gráfica de One Note (windows) antes de pegar o importar los archivos del nuevo grupo. Esta operación aunque se puede tambien hacer simplemente eliminando los archivos de la carpeta My Notebook, aquà recomiendo hacerlo por la interface ya que del otro modo muchas veces el OneNote no actualiza el contenido y genera un error que nos hace tener que reiniciar todo el sistema operativo para que el OneNote (Windows) vuelva a funcionar.
Bueno, continuando la verificaciĂłn, podemos ver dentro de la oleada 1 (grupo 1), la notas migradas a Obsidian tiene una estructura de carpetas, donde cada carpeta representa una secciĂłn en Microsoft OneNote.
Dentro de cada carpeta vamos a tener una carpeta que se llama media donde se almacenan las imágenes y unos archivos con extension .md que contienen la información de lo que serian Paginas en Microsoft OneNote.
Nota: La creaciĂłn de la carpeta media, esta controlada por el input del script medialocation: 2
Ahora solo falta abrir estas carpetas en obsidian
Recordemos que hasta este punto estaba trabajando en una maquina virtual (VM) Windows, de manera que en este punto debo copiar todas las carpetas de cada oleada de migraciĂłn a una Ăşnica carpeta en macOS que contenga toda esa informaciĂłn y que sera el destino de mi Vault en la nueva herramienta Obsidian. En este caso he creado una carpeta llamada Obsidian – Personal Notes que contiene el resultado de cada una de las oleadas.
Ahora en Obsidian usaremos la opciĂłn Open Folder as Vault y le indicamos la carpeta donde tenemos todas nuestras notas migradas.
Voila!, tenemos todo nuestro contenido de OneNote (macOS) ahora en nuestro Obsidian (macOS)
Nota: Si su caso es migrar de Microsoft OneNote a Obisidan en un entorno basado en Windows, algunos de los pasos indicados exclusivamente para macOS pueden ser omitidos. Recordemos que al final quien hace la magia es el script y lo que necesitamos conseguir es la estructura de carpetas que se generan como resultado de la ejecuciĂłn, para configurar nuestro Vault en Obsidian.
Creo que muchos a administradores en su dĂa a dĂa han experimentado el error HTTP Status 500 – Internal Server Error al intentar hacer login en la UI del vCenter Server. Se que su primer instinto será reiniciar mĂşltiples veces sin un resultado satisfactorio.
En este caso lo primero que debemos hacer es verificar es el estado del certificado configurado en el vCenter, si vemos que nuestro certificado ya expirĂł como en nuestro caso (Valid from 12/4/2020 to 12/5/2022), no se preocupe, tenemos un procedimiento para regenerarlo y recuperar la gestiĂłn del vCenter.
PROCEDIMIENTO
1. Iniciar sesiĂłn SSH al vCenter y ejecutar el comando shell
2. Ejecutar el siguiente comando /usr/lib/vmware-vmca/bin/certificate-manager para lanzar el Certificate Management Tools de vCenter Server
3. Digitar la opciĂłn 8 y responder confirmar presionando la letra y
4. A continuaciĂłn podemos dejar los valores por defector del template de vSphere o customizar el template con nuestro valores. Para este caso utilizaremos los valores por default debido a que necesitamos regenerar los certificados default.
Nota: Si decidimos utilizar los valores por defecto podemos presionar la teclar enter varias veces para aceptar los valores por default hasta llegar a las opciones Hostname y VMCA donde debemos especificar el FQDN de nuestro vCenter Server y nuestro Platform Services Controller (PSC). Para versiones superiores a vCenter Server 6.7 donde la Ăşnica arquitectura soportada es PSC Embedded este valor es el mismo para estos dos inputs.
5. Al final de los inputs presionamos nuevamente la tecla y para confirmar la operaciĂłn y podemos ir a tomarnos un cafe mientras los certificados son regenerados. Esto puede tardar aproximadamente 20 min.
6. Al final del proceso debemos obtener el mensaje Reset Status : 100% Completed (Reset completed successfully)
7. Por Ăşltimo, solo nos queda verificar que la fecha de nuestros certificado ha cambiado por una fecha valida y que nuestro vCenter ya esta arriba nuevamente.
ATENCIĂ“N!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
Una de las operaciones de dĂa 2 que mas terror nos daba hace unos años o posiblemente con la que mas sufrĂamos, fue el reemplazo de certificados para las soluciones VMware. Los que tuvimos que luchar esa batalla, recordaremos lo tedioso que era tener que reemplazar cada uno de los certificados de una soluciĂłn de forma manual y encontrarse errores diferentes conforme avanzábamos.
Por suerte, esto ha cambiado y ahora Aria Suite Lifecycle (antes vRealize Suite Lifecycle Manager) nos ofrece una forma fácil, rápida y segura de reemplazar los certificados, por lo menos de los productos asociados a la Aria Suite (antes vRealize Suite) y por supuesto que sean gestionados desde Aria Suite Lifecycle.
En el procedimiento a continuaciĂłn estaremos explicando cĂłmo reemplazar los certificado autofirmados por certificados customizados, es decir certificados firmados por una entidad certificadora del cliente o CA Enterprise. El cambio de un certificado de un autofirmado por otro igualmente autofirmado, es similar al proceso explicado en este post y simplemente costa de los siguientes dos pasos por lo que no representa mayor tiene mayor dificultad.
Crear un certificado en el servicio de locker de vRealize Suite lifecycle Manager
Reemplazar el certificado viejo por el nuevo
Reemplazo de Certificado autofirmado por certificados customizados
Lo primero que debemos tener presente es que el reemplazo de certificados autofirmados por certificados customizados, incluye la participación del equipo de seguridad del cliente, quien será el encargado de proveernos los certificados validos para nuestros productos.
Una manera fácil de hacer esto es solicitar al cliente el/los certificados en extensiĂłn .pem y de esta manera evitamos tener que generar un Certificate Signing Request (CSR), que si bien podemos generarlos desde vRealize Suite Lifecycle Manager, pues lo Ăşnico que harĂa es agregarnos un paso mas en el proceso. Por esta razĂłn, recomiendo solicitar al cliente crear directamente los certificados en su herramienta y exportarlo en el formato indicado y con el Key sin cifrar.
Una vez nos han enviado el/los certificados podemos continuar con los siguientes pasos:
2. Algunas veces nos envĂan el certificado con el key cifrado, entonces debemos pedir que nos envĂen el Key sin clave. Y Rearmar el .pem en otro archivo pero esta vez utilizando el Key sin cifrar.
Recordemos que la secciĂłn asociada al Key deberĂa contener los siguiente:
—–BEGIN RSA PRIVATE KEY—–
—–END RSA PRIVATE KEY—–
3. Una vez hemos verificado la estructura del certificado podemos ir al servicio de Locker de Aria Suite Lifecycle e importarlos en -> Certificates -> Import. En este paso solo debemos hacer click en BROWSER FILE y buscar el archivo .pem que construimos en el paso anterior. Automáticamente los campos Private Key y Certificate Chain serán poblados. Finalizamos el proceso haciedo click en el boton IMPORT
4. Una vez importados se mostraran los detalles del certificado de manera que podremos verificar que los Subject Alternative Name de cada certificado contenga los FQDN de todos los nodos de cada soluciĂłn incluyendo el FQDN del VIP del balanceador que le corresponda, de ser necesario.
5. Si vamos a reemplazar el certificado de una solucion que se encuentra detrás de un balanceador como por ejemplos VMware Identity Manager (vIDM), ahora llamado Workspace One Access (WS1), debemos primero reemplazar el certificado en el balanceador siguiendo la guĂa de cada fabricante.
6. Una vez realizado el cambio de certificados en el balanceador, debemos realizar la action Re-trust Load Balancer en el servicio Lifecycle Operations-> Environments -> Para este ejemplo globalenvironment (ambiente asociado a vIDM o WS1).
7. Para efectuar el reemplazo de certificados lo único que debemos hacer es ir al servicio de Lifecycle Operations-> Environments -> click en VIEW DETAILS del ambiente en cuestión (para este caso globalenvironment) -> Click en los tres puntos (…) para listar mas opciones -> Replace Certificate
8. A continuaciĂłn nos muestra un resumen del certificado actual
9. Hacemos click en NEXT para seleccionar el nuevo certificado (importado) desde la lista desplegable
10. Si el certificado es de una soluciĂłn como vIDM del cual dependen otros productos, nos mostrará que durante el proceso de cambio de certificados hará un Re-Trust sobre los productos listados allĂ. Click en NEXT para continuar.
11. A continuaciĂłn podremos seleccionar si queremos que Aria Suite Lifecycle cree por nosotros un snapshot en la VMs involucradas . Se recomienda esta acciĂłn a no ser que ya hayamos tomado un snapshot directamente desde el vCenter. Luego Click en NEXT
12. Para validar que el certificado que vamos a aplicar es correcto, debemos ejecutar un PRECHECK haciendo click en el botĂłn RUN PRECHECK
Nota 1: Si por alguna razon, reemplaza el certificado de una solucion de Aria Suite (vRealize Suite) sin haber cambiado el certificado del balanceador recibirá una notificación en el Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) indicándole que debe reemplazar el certificado en el balanceador (Importar el certificado nuevo en NSX-T, NSX-v, F5, o el balanceador que corresponda) siguiendo la guia del fabricante, como comentamos anteriormente.
Nota 2: De igual forma, si se cambia el certificado del balanceador despues de cambiar el certificado de vIDM entonces recibirá una unas notificaciones en Aria Suite Lifecycle indicándole que debe realizar una acción de re-trust en cada una de las soluciones que se encuentren detras de ese balanceador. Comenzando de nuevo por Workspace One Access (WS1A).
Nota 3: Sino hacemos esto vamos a recibir un Bad Gateway al intentar a hacer login en WS1A. Para evitar esto, recomendamos reemplazar el certificado del balanceador en primer lugar como lo hemos mencionado anteriormente
15. Como hemos realizado un cambio que esta por fuera del control de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager) debemos realizar la acciĂłn de Re-trust Load Balancer, desde la solucion de Workspace One Access / VMware Identity Manager (globalenvironment) y para esto vamos a Environment -> global environment -> click en los tres puntos (…) para mas opciones y luego click en Re-trust Load Balancer
16. (Opcional) Cuando termine vamos a cada unos de los productos que estaba integrados con vIDM o WS1A, como por ejemplo Aria Operations (antes vRealize Operations Manager), Aria Automation (antes vRealize Automation), Aria Operations for Logs (vRealize Log Insight), etc. En algunas ocasiones podrĂamos necesitar hacer click Re-Trust with Identity Manager en cada una de las soluciones de Aria Suite (vRealize Suite), aunque este proceso por lo general se hace automático durante el reemplazo de certificados de Workspace One Access (WS1A).
17. El reemplazo de certificados de todas las soluciones de la Aria Suite tienen el mismo procedimiento que hemos mencionado para el Workspace One Access (globalenvironement), razon por la cual no haremos este post mas largo.
Nota 4: Para las soluciones que no están detrás de un balanceador, es claro que podemos hacer directamente el reemplazo de certificados siguiendo los pasos 7-13.
Por ultimo, vamos a realizar el reemplazo de certificados de la solucion Aria Suite Lifecycle (vRealize Suite Lifecycle Manager). El reemplazo de esta solucion no tiene un orden especifico y se puede realizar en primero o ultimo lugar. Vemos entonces los siguientes pasos.
Remplazo de certificados de Aria Suite Lifecycle (vRealize Suite Lifecycle Manager)
1. En el servicio de Locker vamos a crear o importar un certificado para esta solucion. Como ya explicamos como importar un certificado, en este caso generaremos uno nuevo desde la opciĂłn -> Certificates -> Add Certificate. Recordar que si lo generamos desde el servicio de Locker, sera entonces un certificado autofirmado o Self-Signed.
2. En Lifecycle Operations click en –> Settings -> Change Certificate
3. Click en el boton REPLACE CERTIFICATE
4. Revisamos los detalles del certificado actual y hacemos click en NEXT
5. Seleccionamos el nuevo certificado, que importamos o generamos en el servicio de Locker y click en NEXT
6. Click en RUN PRECHECK para verificar que todo este bien con el certificado y si todo esta ok, click en FINISH
Y podemos validar que el Subject del certificado ahora contienes los datos que configuramos en el nuevo certificado.
Nota 5: (Opcional) Si ha realizado reemplazo de certificados para WS1A antes de cambiar los de Aria Suite Lifecycle entonces realize una acciĂłn de RE-REGISTER dentro del servicio de Lifecycle Operations -> Settings -> Authentication Provider. DeberĂa haberse realizado de manera automática, pero si tiene algĂşn problema con la autenticaciĂłn de usuarios de dominio en la solucion Aria Suite Lifecycle, este paso solucionara el inconveniente.
Para quienes nos estan familiarizado con Aria Suite Lifecycle podrĂa ser una tarea confusa, pero en este video vamos a ver que realmente es muy sencillo.
ATENCIĂ“N!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
Si alguna vez te has encontrado con el error que muestro a continuaciĂłn, no te preocupes!, muy seguramente tu subscripciĂłn ha expirado, esto en el caso que no tengas una licencia perpetua por supuesto.
"It appears that your subscription has expired.Your workloads are still available. Contact yourAccount Manager or Customer Success Manager torenew so that you can log in and keep working".
Por otro lado, sino es tu caso pero aĂşn quieres saber como reemplazar la licencia asignada a tu soluciĂłn de Aria Automation (antes vRealize Automation), continual leyendo el blog.
PROCEDIMIENTO
1. Lo primero, será entonces iniciar sesión en la solución Aria Suite Lifecycle
4. Una vez adicionada la licencia de vRealize Suite, debemos ir al servicio de Lifecycle Operations
5. Navegar hasta Environments -> Click en VIEW DETAILS del environment donde tenemos el Aria Automation (vRA), en este caso el ambiente que tiene la soluciĂłn de Aria Automation es el llamado VRA-LAB
6. Click en los tres punto de la derecha (…) y luego Add License
7. Seleccionamos la nueva licencia en este caso vExpert 2023
8. Seleccionamos la licencia que vamos a retirar, que en este caso la que está en estado expired y click en el botón FINISH
9. El resultado del Request generado deberĂa ser Succesfull
10. Volvemos al ambiente de vRA y verificamos que ahora la licencia ha sido aplicada
11. Por ultimo podemos vovler al servicio de Locker a eliminar las licencias expiradas para mantener nuestro ambiente limpio
12. Una vez reemplazada la licencia podemos ver que nuestra solucion de vRA esta de nuevo operativa
Nota: El procedimiento aplicado en este blog puede ser utilizado para reemplazar la licencia de cualquier solucion de la Aria Suite (Antes vRealize Suite), esto es, Aria Operations (vRealize Operations Manager), Aria Operations for Logs (vRealize Log Insight), Aria Operations for Networks (vRealize Network Insight), etc.
ATENCIĂ“N!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
En este sexto capitulo de la serie dedicada a la instalación y configuración de NSX-T 3.x, explicaremos los conceptos asociados a los Segmentos o Logical Switches de NSX. Posteriormente explicaremos la creación de estos Segmentos en la interfaz gráfica del NSX Manager y migraremos cargas de trabajo tipo VM (Virtual Machine) desde Distributed Port Groups tradicionales hacia nuevos Segmentos de NSX.
ATENCIĂ“N!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
Nacho Aprende IT 