"El éxito en la vida de un hombre está en prepararse para aprovechar la ocasión cuando se le presente"
Autor: Diego Felipe Tunubalá Medina
Profesional con una sólida trayectoria de más de una década en Consultoría de Servicios Profesionales, reconocido como miembro del VMware CTO Ambassador y ahora desempernándome en el rol de TAM, liderando exitosamente proyectos de gran escala tanto a nivel nacional como internacional en el sector de Tecnologías de la Información, lo que ha fortalecido mis habilidades técnicas y de gestión.
Mi experiencia abarca desde la concepción hasta la implementación de soluciones tanto On-Premise como Cloud, así como el diseño y despliegue de infraestructuras físicas y virtuales. Me especializo en áreas críticas como Cloud Management y Automation (Aria Automation), Network Virtualization and Security (NSX), Compute (vSphere) y Storage (vSAN), así como en las operaciones de ciclo de vida (Aria Suite) de la infraestructura.
Cuento con reconocidas certificaciones en tecnologías líderes del mercado como VMware (VCP, VCAP, Specialist, vExpert), Nutanix (NCP) y CompTIA (Server+), respaldadas por una profunda experiencia en metodologías de gestión de proyectos como PMI, SCRUM e ITILv4. Me destaco por mis habilidades de liderazgo, comunicación y trabajo en equipo, lo que se ha traducido en logros significativos en la mejora continua de la eficiencia de los servicios profesionales prestados al cliente.
Si después de un apagado forzado o una actualización tu Virtual Machine (VM) en VMware Fusion muestra el siguiente error, este post te muestra como salir de este problema rápidamente.
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:
Los NSX Managers tienen muchos certificados para servicios internos. En NSX-T 3.2.x, los certificados de servicio de Cluster Boot Manager (CBM) tenían un período de validez incorrecto de 825 días en lugar de 100 años. Esto se corrigió a 100 años en NSX-T 3.2.3 y NSX 4.1.0. Sin embargo, en cualquier entorno que haya ejecutado anteriormente NSX-T 3.2.x (anterior a 3.2.3), los certificados internos de CBM Corfu vencerán después de 825 días, independientemente de si se actualiza o no a la versión corregida.
En NSX-T 3.2.x, los certificados de servidor internos podían vencer y no se activaba ninguna alarma. No se produjo ningún impacto funcional. A partir de NSX 4.1.0.2, las alarmas de NSX ahora controlan la validez de los certificados internos y se activan en el caso de certificados vencidos o que estén a punto de vencer.
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.
Cargar el archivo a la carpeta /tmp del vCenter Server Appliance utilizando WinSCP o cualquier cliente SFTP.
Como persona responsable asegúrate de tener el Backup de NSX reciente. En mi caso, tomaré un snapshot, ya que es un ambiente Nested.
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.
También podemos verificar que ya no tenemos alertas de Certificados en la sección Settings > Certificates
¡Y eso es todo amigos! Ya puedes pasar el susto y volver tus tareas habituales…
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 NSX 4.1.1 y versiones posteriores: el script no rota CBM_APIlos certificados (certificado de cliente API-Corfu), ya que estos están obsoletos en la versión 4.1.1. Consulte la resolución de KB#367857. Después de completar el script, es posible que algunos certificados sin usar permanezcan en la interfaz de usuario con la columna “ Dónde se usa ” establecida en 0. Estos certificados se pueden eliminar si lo desea.
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
En mi caso tenía la versión 5.0.1 y la documentación dice que necesitaba mínimo la 5.1.0. Sin embargo, instalamos de una vez la última versión disponible. En este caso utilicé la opción por MSI que menciona en Installing PowerShell on Windowsporque creo es la más sencilla.
Una vez actualizado nuestro PowerShell, ahora sí, instalamos el PowerCLI usando el comando Install-Module VMware.PowerCLI
Nota: Si les da algún error solo use el comando con los parámetros Install-Module VMware.PowerCLI -Force -skipPublisherCheck
Usar la herramienta (script)
Una vez instalado el PowerCLI seguir los siguientes pasos para ejecutar el script
Desde la consola del PowerShell navegar hasta donde tenemos el archivo descargado del KB indicado anteriormente.
Conectarse a vCenter Server con el siguiente comando Connect-VIServer -Server IP_FQDN_vCenter_Server
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
A continuación se muestra un par ejemplos adicionales después de ejecutar la herramienta en PowerCLI.
Ejemplo de VCF con vSAN
Ejemplo de VVF con vSAN
¡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.
Historia (Opcional)
La razón de hacer esto fue debido a que OneNote limita el tamaño de nuestras notas y cuando tenemos muchas imágenes, puede llegar a ser un dolor de cabeza. Todo comenzó el día que tuve una falla en mi Mac y tuve que cerrar la sesión de mi OneNote, que estaba abierta hacía mas de 2 años. Gran sorpresa al percatarme que gran parte del contenido, no había sido sincronizado en OneDrive pese que éste contaba con espacio suficiente y el check de sincronización online se mostraba activo en el Microsoft OneNote.
Al verificar en el OneNote Online fue cuando realmente me preocupé, la notas sincronizadas estaban incompletas y muchas nisiquiera habían iniciado su sincronización. ¿Que hubiera pasado si pierdo el laptop? me hubiese quedado sin muchas de mis notas que han sido de gran apoyo durante mi vida profesional. Si bien algunas de estas las comparto en mi blog nachoaprendevirtualizacion.com, muchas otras no son para tal fin.
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!
En la búsqueda de un sustituto para mis notas encontré Obsidian, que básicamente es un gestor de notas que aprovecha características de Markdown. Hay mucha información en la web sobre esta herramienta, así que no nos detendremos a hablar de ella y vamos al grano. ¿Como hice para migrar mis notas de Microsoft OneNote a Obsidian? A continuación te lo explico.
Descargar Script desde GitHub
Lo primero que debemos hacer es descargar un script desde GitHub que hace toda la magia, y después de haber probado varios desarrollos, este fue el que a mi parecer funciona mejor. Vamos entonces aquí para descargar el ConvertOneNote2MarkDown.
Para descargar el contenido del repositorio solo debemos hacer click en Code -> Download ZIP
Al descomprimir el contenido del .zip deberíamos ver algo como lo siguiente
Nota: Si estamos usando dispositivo Mac como en mi caso, recomiendo descargar el .zip en otro equipo con Sistema Operativo Windows, utilizar un VMware Fusion o VirtualBOX para ejecutar una VM windows si es que no tenemos otro dispositivo. Para este caso utilizaré VMware Fusion.
Trabajar con Copias de seguridad si usamos macOS
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.
Abrir copias de seguridad de OneNote en Windows
El script que vamos a utilizar funciona en Windows de manera que para poder migrar las Notas de OneNote a Obsidian vamos a tener que usar una maquina virtual windows, como lo comenté anteriormente.
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:
1. Verificar que los certificados los entreguen en .pem y que estén bien generados. Para esto podemos abrir el archivo .pem con un editor de texto y verificar que tenga la siguiente estructura.
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
13. Después de finalizar el PRECHECK podemos ver que nos solicita una acción de aceptar y nos indica que el remplazo de los certificados sobre los balanceadores debe hacerse manual como lo comentamos anteriormente. Procedemos entonces a hacer click en ACEPTAR y después en FINISH
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
14. Si realizamos el reemplazo del certificado en el balanceador, en primera instancia como lo hemos recomendado, la URL de acceso al WS1 (VIP)después del reemplazo de los certificados del globalenvironment, debería mostrar el sitio como seguro y con los detalles del certificado que hemos importado.
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
Nota: Después de un par de minutos, en el servicio de Lifecycle Operations deberíamos ver el Request asociado a este reemplazo de certificados como Completed.
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.
Después de algunas semana sin tener tiempo para hornear un par de post que tengo pendientes, retomamos esta tarea con este capitulo en el cual vamos a explicar como realizar el parchado (patching) de la solución vRealize Suite Lifecycle Manager, ahora renombrado a Aria Suite Lifecycle.
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
2. En el servicio Locker > Licenses, verificamos que efectivamente tengamos nuestra licencia en estado Expired. De igual forma, como lo comenté anteriormente, si solo quieres saber como reemplazar la licencia, puedes continuar leyendo los siguientes pasos
3. Sino hemos agregado una licencia de Aria Suite (vRealize Suite) que es la que contiene la solución de Aria Automation (vRealize Automation) debemos hacer click en el botón ADD LICENSE MANUALLY e ingresar un nombre para la Licencia (License Alias) y el License Key. Después Click en VALIDATE y posteriormente ADD
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 séptimo capitulo de la serie dedicada a la instalación y configuración de NSX-T 3.x, explicáremos los conceptos básicos necesario para preparar un nodo KVM basado en sistema operativo Ubuntu KVM, como nodo de transporte Node de NSX-T.
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.
