Etiqueta: nachoaprendevirtualizacion

SoluciĂłn al Error ‘Cannot open the disk’ en VMware Fusion

en por Diego Felipe Tunubalá Medinaen OtrosDeja un comentario

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
Pasted image 20241017114557.png

Procedimiento

  1. 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.

  2. Una vez localizado el archivos de la VM, vamos a hacer clic derecho sobre el y despues Show Package Contents
    Pasted image 20241017114808.png

  3. 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
    Pasted image 20241017115006.png

  4. Por último, solo debemos eliminar esas carpetas y volver a intentar el Power On de la máquina virtual en VMware Fusion
    Pasted image 20241017115454.png

¡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.

Referencia

SoluciĂłn Rápida para Certificados Expirados en NSX 4.1.x

en por Diego Felipe Tunubalá Medinaen NSX, VCF/VVFDeja un comentario

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!

Pasted image 20241007223829.png

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.

Pasted image 20241007223818.png
Pasted image 20241007223829.png
Pasted image 20241007223847.png

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.

Procedimiento

  1. Descargar el script replace_certs_v1.7.py que se encuentra al final del KB NSX alarms indicating certificates have expired or are expiring
    Pasted image 20241009174718.png


  2. Cargar el archivo a la carpeta /tmp del vCenter Server Appliance utilizando WinSCP o cualquier cliente SFTP.
    Pasted image 20241007225441.png


  3. Como persona responsable asegúrate de tener el Backup de NSX reciente. En mi caso, tomaré un snapshot, ya que es un ambiente Nested.
    Pasted image 20241007225822.png


  4. 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
    Pasted image 20241007235455.pngPasted image 20241008002311.png


    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.

Pasted image 20241008002335.png

Si revisamos el certificado de uno de los NSX Manager, podremos ver que su fecha ha sido actualizada.

Pasted image 20241008002408.png

También podemos verificar que ya no tenemos alertas de Certificados en la sección Settings > Certificates

Pasted image 20241008002431.png

¡Y eso es todo amigos! Ya puedes pasar el susto y volver tus tareas habituales…

ActualizaciĂłn 13012025

La solución de este problema ha sido actualizada y ahora se puede utilizar el script CARR para resolver este problema. Consulte Uso del script CARR (Certificate Analyzer Resolver) para solucionar problemas relacionados con certificados en NSX para descargar el script actualizado.

ActualizaciĂłn 12122024

  • 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.
  • Si el script finaliza con » Keystore is not updated post replacement«, consulte el siguiente artĂ­culo: El script de reemplazo de certificado genera un error durante la ejecuciĂłn: el almacĂ©n de claves no se actualiza despuĂ©s del reemplazo del certificado ‘CBM_X’ en el nodo ‘IP»

¡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.

Licenciamiento de VMware: VCF, VVF y vSAN explicado

en por Diego Felipe Tunubalá Medinaen VCF/VVF1 comentario

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.

¡Pues bien, es sencillo y acá te lo explico!

CONTENIDO

  1. Licenciamiento VCF/VVF por subscripciĂłn requerido para el ambiente
  2. Licenciamiento para vSAN por subscripciĂłn requerido para el ambiente
    1. Herramienta para consolidar la informaciĂłn de la cantidad de licencias

    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

    En el siguiente KB Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN vemos un ejemplo de cuantas licencias deberĂ­a adquirir un cliente para una soluciĂłn de VCF y vSAN teniendo en cuenta la cantidad de hosts ESXi.

    Pasted image 20240917202553.png

    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.

    Como en el caso anterior, dejamos por un ejemplo de lo expresado anteriormente para el caso de VVF con vSAN. Para ver más ejemplos podemos ver el artículo completo Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN

    Pasted image 20240917204756.png

    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:

    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

    Pasted image 20240920125002.png

    $PSVersionTable

    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.

    $PSVersionTable

    Una vez actualizado nuestro PowerShell, ahora sĂ­, instalamos el PowerCLI usando el comando Install-Module VMware.PowerCLI

    Pasted image 20240920122650.png

    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

    1. Desde la consola del PowerShell navegar hasta donde tenemos el archivo descargado del KB indicado anteriormente.
      Pasted image 20240920124024.png

    2. Conectarse a vCenter Server con el siguiente comando
      Connect-VIServer -Server IP_FQDN_vCenter_Server
      Pasted image 20240920124217.png

    3. Importar funciĂłn PowerCLI:
      Import-Module .\FoundationCoreAndTiBUsage.psm1

      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.

      Pasted image 20240920124549.png

    4. 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

      Pasted image 20240920124727.png

    5. Desconectarse del vCenter Server:
      Disconnect-VIServer -Server IP_FQDN_vCenter_Server

      Pasted image 20240920125535.png

    A continuación se muestra un par ejemplos adicionales después de ejecutar la herramienta en PowerCLI.

    Ejemplo de VCF con vSAN

    Pasted image 20240917210921.png

    Ejemplo de VVF con vSAN

    Pasted image 20240917211000.png

    ¡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.

    CĂłmo Usar Script para Convertir OneNote a Obsidian

    en por Diego Felipe Tunubalá Medinaen ToolsDeja un comentario

    CONTENIDO

    1. Historia (Opcional)
    2. Descargar Script desde GitHub
    3. Trabajar con Copias de seguridad si usamos macOS
    4. Abrir copias de seguridad de OneNote en Windows
    5. Ejecutar el script ConvertOneNote2Markdown
    6. Resultado de la EjecuciĂłn
    7. Verificar resultados
    8. Ahora solo falta abrir estas carpetas en obsidian

    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

    Pasted image 20240106132540.png

    Al descomprimir el contenido del .zip deberĂ­amos ver algo como lo siguiente

    Pasted image 20240106133244.png

    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…

    Pasted image 20240106130238.png

    Click en Backup

    Pasted image 20240106130256.png

    Click en Open Backup Folder

    Pasted image 20240106130337.png

    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.

    Pasted image 20240106125921.png

    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.

    Pasted image 20240106125948.png

    OpciĂłn 2

    Dentro de OneNote (Windows) vamos a Archivo -> InformaciĂłn -> Abrir copias de seguridad

    Pasted image 20240106131852.png

    y seleccionamos desde nuestra Memoria Externa, o carpeta compartida, todos los archivos que queremos migrar a Obsidian.

    Pasted image 20240106132021.png

    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.

    Pasted image 20230613004258.png

    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.

    Pasted image 20240106184701.png
    Pasted image 20240106185155.png

    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

    Pasted image 20240106133426.png

    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:

    dryRun: 0
notesdestpath: c:\temp\notes
targetNotebook:
usedocx: 2
keepdocx: 2
docxNamingConvention: 2
prefixFolders: 1
mdFileNameAndFolderNameMaxLength: 200
medialocation: 2
conversion: gfm+pipe_tables-raw_html
headerTimestampEnabled: 1
keepspaces: 1
keepescape: 1
newlineCharacter: 1
exportPdf: 1

    Notas:

    • 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.
    Pasted image 20240106133931.png
    Pasted image 20240106134002.png

    Una vez terminamos de responder a cada uno de los imputos, comienza el proceso de migraciĂłn.

    Pasted image 20240106134024.png

    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.

    Pasted image 20230613004313.png

    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:

    Pasted image 20240106134809.png
    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.

    Pasted image 20240106135216.png

    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.

    Pasted image 20240106135617.png
    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

    Pasted image 20240106135829.png

    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.

    Pasted image 20240106140402.png

    Ahora en Obsidian usaremos la opciĂłn Open Folder as Vault y le indicamos la carpeta donde tenemos todas nuestras notas migradas.

    Pasted image 20240106140544.png

    Voila!, tenemos todo nuestro contenido de OneNote (macOS) ahora en nuestro Obsidian (macOS)

    Pasted image 20240106143201.png
    Pasted image 20240106143251.png

    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.

    Solucionar Error HTTP 500 en vCenter Server

    en por Diego Felipe Tunubalá Medinaen vCenter Server, vSphereDeja un comentario

    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.

    Solucionando error en EMC Unisphere session: The System can not be managed for the following reasons. Certificate has invalid date.

    en por Diego Felipe Tunubalá Medinaen EMC Unisphere, SAN, vSphere10 comentarios

    Como su nombre lo indica este post se enfoca en la solución de un problema de vencimiento de certificados para la consola de administración (EMC Unisphere) de nuestro VNX5200 . Sin embargo no hay de que preocuparse, ¡El mensaje de error asusta más que el problema en sí!.

    Al intentar ingresar a la consola de administraciĂłn del EMC Unisphere aparece el siguiente error:  «The System can not be managed for the following reasons. Certificate has invalid date» y simplemente no permite continuar con el inicio de sesiĂłn.

    image

    El problema básicamente radica en que el certificado ha expirado y no permite el inicio de sesión de ninguna manera.

    image

    SOLUCIĂ“N

    La solución se centra en forzar la generación de un nuevo certificado a través de una interfaz de línea de comandos.

    1. Descargue la herramienta EMC Navisphere CLI desde aquĂ­. Iniciando sesiĂłn con una cuenta de usuario registrada para poder realizar la descarga.

    image

    2.  Instale EMC Navisphere CLI en su ordenador siguiendo cada uno de los pasos del asistente.

    image
    image

    Nota 1: Tenga presente la ruta de instalación de la herramienta (la usaremos más adelante). La ruta por default es C:\Program Files (x86)\EMC\Navisphere CLI.

    image

    Nota 2: En el Paso 3. Deje la validaciĂłn del certificado en Low para que no verifique el certificado. (Solo para este caso, porque esta vencido).

    image
    image

    3. Una vez finalizada la instalaciĂłn. Abra una lĂ­nea de comandos en Command Prompt (CMD) y navegue hasta la ubicaciĂłn de instalaciĂłn de la herramienta Navisphere CLI utilizando el siguiente comando:

    cd C:\Program Files (x86)\EMC\Navisphere CLI

    image

    4. Ejecute ahora la herramienta NaviSECCLI.exe utilizando la siguiente lĂ­nea de comandos:

    NaviSECCli.exe -address [IP_Unisphere] -User [usuario] -Password [Contraseña] -Scope 0 security -SPcertificate -generate

    image

    Nota 3: Verifique que el resultado de la operaciĂłn sea SPCertificate is generated: Sucess.

    Nota 4: Si el equipo cuenta con mas de una controladora, ejecute el comando para cada una de las IPs asociadas a las mismas.

    5.  Abra una ventana en su navegador web e intente realizar la conexiĂłn hacia la consola de administraciĂłn EMC Unisphere nuevamente.

    image

    6. Revise los detalles del nuevo certificado y notará que es valido por cinco años, a partir de la fecha.

    image

    7. Haga clic en Accept Always, para aceptar el certificado.

    image

    8. Por Ăşltimo, inicie sesiĂłn en su consola y verifique que el problema ha sido resuelto.

    image
    image

    Importando VMs a vRealize Automation 7.x

    en por Diego Felipe Tunubalá Medinaen vRealize Automation/Aria AutomationDeja un comentario

    Una de las tareas que deberíamos incluir en nuestros planes de trabajo, luego de la instalación, configuración y prueba de nuestro ambiente Cloud Privado con vRealize Automation, es la importación de las VMs que ya existían en el ambiente virtual y que podrían comenzar a ser administradas desde el portal de VRA, con el fin de mantener unificada la interfaz de gestión de las VMs desde el lado del usuario. Esto ayudará a limitar el acceso de administradores al vCenter debido a que acciones como (reinicio, apagado, snaphots, reconfiguración, etc.) podrán ser realizadas por el usuario desde el portal del VRA.

    ÂżCĂ“MO FUNCIONA?

    Existe una funcionalidad llamada Bulk Imports, que permite importar, actualizar y migrar máquinas a vRealize Automation. Esta funcionalidad crea un archivo .CSV que contiene datos de la VM como reservation, storage path, blueprint, owner, y custom properties.

    Bulk Imports admite las siguientes tareas administrativas:

    • Importar una o más máquinas virtuales no administradas para que puedan administrarse en el entorno de vRealize Automation .
    • Realizar un cambio global en una propiedad de máquina virtual, como una ruta de almacenamiento.
    • Migrar una máquina virtual de un entorno de vRealize Automation a otro.

    Nota: Solo vCloud Director y vSphere son compatibles con Bulk Import. Establecer el filtro en otro tipo de endpoint no genera datos en el archivo CSV.

    PRERREQUISITOS

    • Inicie sesiĂłn en vRealize Automation como fabric administrator y como business group manager.
    • Si está importando máquinas virtuales que usan direcciones IP estáticas, prepare un pool de direcciones configurado correctamente. Para obtener más informaciĂłn, consulte Crear un perfil de red.
    • Cree un Blueprint para la máquina virtual que planea importar. Este plan debe ser publicado y tener un owner válido para ser Entitled a ese propietario.

    PROCEDIMIENTO

    Clic en el siguiente video, o clic aquĂ­ para ver directamente en YouTube.

    Deshacer ELM (Enhanced Linked Mode) en PSC Embedded Windows 6.x (Topología No Soportada)

    en por Diego Felipe Tunubalá Medinaen vCenter Server, vSphereDeja un comentario

    En nuestra oficio como consultores de TI, siempre estamos buscando alinear al cliente con las mejores prácticas del fabricante. Es por esta razón que cuando encontramos clientes con arquitecturas extrañas y fuera de soporte, es nuestro deber realizar el mejor esfuerzo por corregir y traer devuelta al cliente en la dirección correcta.

    Pues bien, esta es la historia de un cliente que implementĂł sus vCenter Servers basados en Windows (version 6.0.x) con Platform Services Controller (PSC) Embebido en una configuraciĂłn de Enhanced Linked Mode, creando sin saberlo una topologĂ­a NO Soportada por VMware (KB2108548).

    image

    clip_image001[7]

    Desafortunadamente, este error puede ser creado ya que en el momento de la implementación el asistente de configuración no realiza una validación de la topología y es responsabilidad del consultor tener en cuenta las mejores prácticas.

    Recordemos que Enhanced Linked Mode con PSC Embedded comenzó a ser soportado desde la versión 6.5U2 y para la versión VCSA (vCenter Server Appliance), no para Windows (Ver). Y es ahí donde nos preguntamos: ¿Que hacia un ELM configurado en esos vCenters 6.0?. «¡De todo se ve en la viña del señor!». A continuación explicaremos el procedimiento (no soportado), para romper el ELM y poder realizar una actualización hacia la version 6.5.

    Nota 1: Al ser una topología no soportada, el procedimiento tampoco esta soportado. Sin embargo, es una manera de deshacer el Enhanced Linked Mode de forma segura, pero deberá aplicarlo bajo su propio riesgo.

    En este punto podrá surgir la pregunta, ¿Para qué querría separar el ELM si esta funcionando?, las respuestas son básicamente tres:

    1. No es una buena práctica, por lo cual no se recomienda configurar en la version 6.0 de vCenter Server basa en Windows.

    2. Es una topologĂ­a No Soportada y si tienes un problema con los vCenter Server, no hay mucho que el fabricante pueda hacer si abrimos un caso con ellos.

    3. Al intentar realizar una actualización hacia la versión 6.5.x o posteriores, obtendrá el siguiente error: «You have embedded vCenter configuration with VMware Single Sign On linked to some other node. Unlink single sign on before to upgrading«. Y es esta la razón, por la cual estamos escribiendo este post.

    Como podríamos evidenciar, el error es generado en los primeros pasos de la actualización, por lo cual no quedará mas remedio que corregir el error antes de intentar de nuevo la actualización.

    image

    Nota 2: Para aclarar un poco las topologías antes de iniciar con el procedimiento, mostraré cual es la topología actual No Soportada y cual será la Topología después del procedimiento.

    TopologĂ­a Actual (No Soportada)

    image

    TopologĂ­a futura (Soportada)

    image

    ANTES DE COMENZAR

    Existen diferentes caminos para migrar hacia una topologĂ­a soportada, entre los cuales podrĂ­amos tener:

    1. Implementar un Platform Services Controller (PSC) Externo en cada sitio, conectados al mismo dominio de Single Sign On, para después re apuntar los vCenters de cada sitio hacia sus correspondientes nuevos PSC Externos KB2113917. Para este caso deberá validar qué soluciones VMware (vRealize Operation, vSphere Replication, Site Recovery Manager, etc)  tiene conectadas al PSC Embedded de los vCenter, ya que tendrá que garantizar el trafico desde dichas soluciones hacia el nuevo direccionamiento de los PSC Externos. Podría necesitar creación nuevas reglas en el FW que no se tenían configuradas.

    2. Si su vCenter cuenta con los prerrequisitos para migrar a la versiĂłn vCenter Server Appliance (Ver), llevarlo a una versiĂłn superior o igual a VCSA 6.5U2, garantizarĂ­a la misma TopologĂ­a pero esta vez soportada por VMware (Ver). De manera que intentar realizar una actualizaciĂłn y migraciĂłn no suena descabellado.

    image

    Nota 3: Si ninguno de los caminos presentados anteriormente es una opciĂłn viable, o por el contrario es un requerimiento de la organizaciĂłn deshacer el ELM, continĂşe con el procedimiento.

    PROCEDIMIENTO PARA DESHACER ELM

    Para nuestro caso de laboratorio hemos construido la misma TopologĂ­a del cliente (No soportada) con las maquinas virtuales vm06 para el vCenter Server del Sitio-1y vm07 para el vCenter Server del Sitio-2.

    1. Tome un snapshot de las VMs asociadas a los vCenter Server del Sitio-1 y Sitio-2, con el fin de tener un mecanismo de rollback si algo va mal. Si tiene soluciones VMware adicionales conectadas a los vCenter, tome un snapshot para esas maquinas también.

    2. Abra un navegador web con dos pestañas nuevas, en una inicie sesión hacia el vSphere Web Client de vCenter Server del Sitio-1 (https://vm06.lab.local/vsphere-client/?csp) y en la otra inicie sesión hacia el vSphere Web Client de vCenter Server del Sitio-2 (https://vm07.lab.local/vsphere-client/?csp). Verifique que el estado de los servicios en Home|Administration|System Configuration es saludable para los dos nodos.

    3. Apague uno de los vCenter Server. En este caso, comenzaremos realizando el procedimiento en el vCenter Server del Sitio-2 (vm07) por lo cual apagaremos de manera controlada la VM de vCenter Server del Sitio-1 (vm06). Una vez apagado el servidor, al refrescar la vista del vSphere Web Client de Sitio-2, podrá observar que ahora aparece una notificación indicándole que no se puede conectar al nodo https://vm06.lab.local:443/sdk (esto es normal).

    image

    4. Inicie conexiĂłn RDP hacia el servidor Windows Server en donde esta instalado el vCenter Server del Sitio-2 (vm07).

    5. Abra una interface de lĂ­nea comandos CMD como administrador y ejecute los siguientes comando:

    cd C:\Program Files\VMware\vCenter Server\bin\
cmsso-util unregister --node-pnid Platform_Services_Controller_System_Name_Site1 --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password


Ejemplo:
cmsso-util unregister --node-pnid vm06.lab.local --username administrator@vsphere.local --passwd VMware1!

    image

    Nota 4: La salida de comando deberĂ­a ser Success.

    6. Cierre sesiĂłn sobre el vSphere Web Client de vCenter del Sitio-2 que esta encendido (vm07) y luego inicie sesiĂłn nuevamente. Ahora puede observar que en Home|Administration|System Configuration, aparece un Ăşnico nodo y la notificaciĂłn de la parte superior ya no aparece.

    image

    6. Encienda la máquina de vCenter Server del Sitio-1 (vm06), y espere que inicialice el servicio de vSphere Web Client para poder iniciar sesión.

    image

    8. Inicie Sesión en el vSphere Web Client del vCenter Sitio-1 (vm06) aproximadamente 10 min después de haber encendido la VM. Vaya hasta Home|Administration|System Configuration y podrá observar que este nodo aún continua viendo la conexión ELM. Esto es normal ya que al haberlo apagado no se dio cuenta del cambio, pero de haber ejecutado el comando con la VM encendida el PSC de este vCenter estaría muerto. Así que continuemos!

    image

    9.  Apague de manera controlada ahora la máquina del vCenter Server del Sitio-2 (vm07). Ya que el procedimiento se realizará ahora sobre la VM de vCenter Server del Sitio-1 (vm06), que aún ve la configuración ELM (aunque ya no esta replicando en el dominio de SSO). Una vez apagado el servidor, al refrescar la vista del vSphere Web Client del vCenter del Sitio-1 (vm06), nuevamente podrá observar una notificación en la parte superior indicándole que no se puede conectar ahora al nodo https://vm07.lab.local:443/sdk (esto nuevamente es normal).

    image

    10. Inicie conexiĂłn RDP hacia el servidor Windows Server en donde esta instalado el vCenter Server del Sitio-1 (vm06).

    11. Abra una interface de lĂ­nea comandos CMD como administrador y ejecute los siguientes comando:

    cd C:\Program Files\VMware\vCenter Server\bin\
cmsso-util unregister --node-pnid Platform_Services_Controller_System_Name_Site2 --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password


Ejemplo:
cmsso-util unregister --node-pnid vm07.lab.local --username administrator@vsphere.local --passwd VMware1!

    image

    Nota 5: La salida de comando deberĂ­a ser Success.

    12. Cierre sesiĂłn sobre el vSphere Web Client de vCenter del Sitio-1 que esta encendido (vm06) y luego inicie sesiĂłn nuevamente. Ahora puede observar que en Home|Administration|System Configuration, aparece un Ăşnico nodo y la notificaciĂłn de la parte superior ya no aparece.

    image

    13. Encienda el vCenter del Sitio-2 (vm07), y espere que inicialice el servicio de vSphere Web Client para poder iniciar sesiĂłn.

    image

    14. Inicie Sesión en el vSphere Web Client del vCenter del Sitio-2 (vm07) aproximadamente 10 min después de haber encendido la VM. Vaya hasta Home|Administration|System Configuration y podrá observar que el nodo ya ha sido separado y no muestra ninguna dependencia con el vCenter Server del Sitio-1.

    image

    De igual forma el vCenter Server del Sitio-1 (vm06) no muestra ninguna dependencia con el vCenter Server del Sitio-2.

    image

    15. (Opcional) Si ahora ejecutamos nuevamente el asistente de actualización sobre cualquiera de los vCenter Server Windows, no obtendrá el error mencionado anteriormente y la actualización se desarrollará de manera satisfactoria. Es así como podemos pasar de una Topología No Soportada a una Topología Soportada.

    image

    image

    CONCLUSIĂ“N

    El KB2106736, indica explĂ­citamente que el comando cmsso no deber ser utilizado para deshacer una configuraciĂłn ELM, por esta razĂłn este procedimiento no esta soportado. Por otra parte, existe una alternativa si se realizan los pasos como se indicaron.

    Si por alguna razón ejecuta el comando con las VMs de ambos sitios encendidas, el resultado será que el vCenter donde ejecutó el comando quedará separado y funcionando. Sin embargo, la suerte para el otro vCenter no será la misma ya que el PSC del otro vCenter tendrá afectación y su vCenter asociado no funcionará mas. Y obtendrá un error como el siguiente:

    image

    Configurar notificaciones en vRealize Automation 7.x con cuenta Gmail

    en por Diego Felipe Tunubalá Medinaen vRealize Automation/Aria AutomationDeja un comentario

    ¿Por qué utilizar una cuenta externa?

    En la mayorĂ­a de las ocasiones, cuando tenemos un ambiente de Laboratorio, no tenemos los recursos disponibles en la infraestructura para crear nuestro propio servidor de correo, ya sea por capacidad de procesamiento, memoria, storage, licencias, experiencia en la configuraciĂłn del mismo o simplemente no contamos con el tiempo suficiente para hacerlo.

    Es por esta razĂłn, que en este post explicaremos el procedimiento para emplear una cuenta de Gmail (100% gratis) como Email Server, Inbound (usada para responder a las notificaciones y completar tareas) y Outbound (usada para enviar notificaciones basadas en eventos del sistema), de la soluciĂłn vRealize Automation 7.x y de esta manera poder notificar a los administradores acerca de lo que sucede en la infraestructura.

    Nota 1: No se recomienda utilizar cuentas de correo externo para ambientes productivos.

    PROCEDIMIENTO

    Dicho lo anterior, veamos cada uno de los pasos involucrado en la configuraciĂłn de las notificaciones para vRealize Automation, empleando una cuenta Gmail.

    1. Cree una cuenta Gmail o utilice una cuenta de correo existente.

    Para efectos de laboratorio he decido crear una cuenta nueva Ăşnicamente para este fin. Para crear una cuenta nueva haga clic aquĂ­. Una vez creada, inicie sesiĂłn en su cuenta recientemente creada y siga las instrucciones del asistente de configuraciĂłn de Gmail.

    image

    2.  Habilite en la cuenta el acceso IMAP (Internet Message Access Protocol)

    El Protocolo de Acceso a Mensajes de Internet (IMAP), es un protocolo de aplicaciĂłn que permite el acceder los mensajes almacenados en un servidor de Internet y permite tener acceso al correo electrĂłnico desde cualquier equipo que tenga una conexiĂłn a Internet.

    Por defecto, la cuenta Gmail esta configurada con IMAP deshabilitado por lo que será necesario habilitarlo como sigue:

    a) En su computadora, abra Gmail.
    b) En la esquina superior derecha, haga clic en ConfiguraciĂłn ConfiguraciĂłn.
    c) Haga clic en ConfiguraciĂłn.
    d) Haga clic en la pestaña Reenvío y correo POP/IMAP.
    e) En la sección «Acceso IMAP», haga clic en Habilitar IMAP.
    f) Por ultimo, haga clic en Guardar cambios.

    image

    Nota 2: Tenga en cuenta que para configurar el cliente IMAP vamos necesitar mas adelante los siguientes datos propios de Gmail y de la cuenta asociada.

    image

    3. Active el acceso de apps menos seguras en la cuenta Gmail.

    Si una app o un sitio no cumplen con los estándares de seguridad, es posible que Google bloquee a las personas que intenten acceder a su cuenta desde ellos. Las apps menos seguras pueden permitir que los hackers accedan a la cuenta con más facilidad. Es importante bloquear los accesos desde ellas con el fin de mantener su cuenta protegida.

    Dicho lo anterior, la cuenta Gmail por defecto es configurada para denegar el acceso de app menos seguras. Sin embargo, para este fin, debe ser habilitado como sigue:

    Nota 3: No realice este procedimiento en su cuenta de correo electrĂłnico personal.

    a) En su computadora, abra Gmail.
    b) En la esquina superior derecha, haga clic en Google Appsimage.
    c) Haga clic en Cuenta.
    d) Haga clic en Seguridad y baje hasta la secciĂłn Acceso de Apps menos seguras.
    e) Haga clic en Activar el acceso (no se recomienda).
    f) Por ultimo, haga clic en el botĂłn Permitir el acceso de apps menos seguras.

    image
    image

    4. Configure Email Servers en vRealize Automation appliance

    Una vez realizado lo anterior, podrá configurar los Email Servers Inbound y Outbound en vRealize Automation 7.x como sigue:

    a) Inicie sesiĂłn en el Tenant deseado https://IPĂłHostname_vRA/vcac/org/nombre_tenant con un usuario  Tenant Administrator. (si es el default tenant entonces https://IPĂłHostname_vRA/vcac/ ).
    b) Haga clic en la pestaña Administration.
    c) Haga clic en la secciĂłn Notifications y luego clic en Email Servers.
    d) Clic en New  (Add) y seleccione Email – Inbound.
    e) Configure el servidor IMAP con los datos suministrados en la Nota 2 y los datos de la cuenta de correo electrĂłnico creada en el paso 1.
    f) Haga click en el botĂłn TEST CONNECTION. Si la conexiĂłn es exitosa (image Connection tested successfully) haga clic en OK.

    image

    Nota 4: El test debería pasar, si no es así verifique la contraseña. Si la contraseña es correcta y recibe el mensaje image Invalid username or password, revise los pasos anteriores para la configuración de IMAP y Acceso de app menos seguras.

    g) Clic en New  (Add) y seleccione Email – Outbound.
    h) Configure el servidor SMTP con los datos suministrados en la Nota 2 y los datos de la cuenta de correo electrĂłnico creada en el paso 1.
    i) Haga click en el botĂłn TEST CONNECTION. Si la conexiĂłn es exitosa (image Connection tested successfully) haga clic en OK.

    image

    Nota 5: El test debería pasar, si no es así verifique la contraseña. Si la contraseña es correcta y recibe el mensaje image Invalid username or password, revise los pasos anteriores para la configuración Acceso de app menos seguras. Adicionalmente, si no ha permitido el Acceso de app menos seguras, recibirá un correo con una advertencia de inicio de sesión.

    image

    Por ultimo, al finalizar la configuración de Email Servers, la vista deberá lucir de la siguiente forma.

    image

    5.  Seleccione los escenarios de notificaciĂłn

    En la pestaña Administration | Notifications | Scenarios, seleccione de la lista, la fuente de notificación que desea Activar o Suspender mediante los botones imageo image.

    clip_image001

    6. Configure una direcciĂłn de correo electrĂłnico a los usuarios

    vRealize Automation enviará las notificaciones a las cuentas de correo electrónico configurada para cada uno de los usuarios. De esta manera si se han configurado usuarios de dominio, esta configuración deberá realizarse en el Active Directory.

    image

    Para visualizar el cambio realizado en el AD desde vRealize Automation será necesario forzar una sincronización, para esto debemos realizar los siguientes pasos:

    a) Inicie sesiĂłn en el Tenant deseado https://IPĂłHostname_vRA/vcac/org/nombre_tenant con un usuario  Tenant Administrator. (si es el default tenant entonces https://IPĂłHostname_vRA/vcac/ ).
    b) Haga clic en Administration | Directories.
    c) Seleccione el Active Directory y clic en Sync Now.

    Si por el contrario, esta usando Ăşnicamente usuarios locales (no recomendado), defina una cuenta de correo electrĂłnico para los usuarios locales del Tenant, iniciando sesiĂłn como System Administrator (Administrator) en https://IPĂłHostname_vRA/vcac/ .

    a) Vaya a la SecciĂłn Tenants.
    b) Seleccione el nombre del Tenant y clic en editar.
    c) Seleccione la pestaña Local Users.
    d) Seleccione el usuario local y defina una cuenta de correo electrĂłnico.

    image

    7. (Opcional) Cree o edite un Custom Group

    Los Custom Group proporcionan un control más granular sobre el acceso dentro de vRealize Automation, que los Business Groups que corresponden a una línea de negocio, departamento u otra unidad organizativa; debido a que los Custom Groups permite centralizar la asignación de roles dentro del Tenant.

    Para efectos de laboratorio, se ha creado un Custom group LAB-vRA-Admins para agrupar todos los usuarios de dominio con permiso de administrador, y se le han otorgado todos los roles (esto es valido para entorno de laboratorio), para un ambiente productivo deberá segregarse cada uno de los roles. Cree un Custom Group siguiendo los pasos descritos aquí.

    clip_image001[5]

    En los miembros asignados al Custom Group se encuentra el usuario de dominio Diego Tunubalá (diego.tunubala@lab.local) que como observamos muestra el email diego.tunubala@xxxx.com configurado en el Active Directory.

    image

    8. (Opcional) Cree o edite un Business Group

    Los Business Groups se utilizan para asociar un conjunto de servicios y recursos a un conjunto de usuarios. Estos grupos a menudo corresponden a una línea de negocio, departamento u otra unidad organizativa. Puede crear un Business Group para poder configurar reservas y autorizar a los usuarios a aprovisionar elementos del catálogo de servicios para los miembros del grupo empresarial. Cree un Custom Business Group siguiendo los pasos descritos aquí.

    En nuestro ambiente de laboratorio se ha creado el Business Group LAB-BS-Group01 cuyos miembros son el Custom Group LAB-vRA-Admins, con el Role Manager asignado, y el grupo de dominio gvarusers@lab.local con el role de usuario.

    clip_image001[7]

    Con el fin de verificar las notificaciones tanto del lado del administrador como del lado del usuario, adicionaremos el usuario pruebavra@lab.local al group de dominio gvarusers@lab.local en el Active Directory.

    Nota 6: Al usuario pruebavra@lab.local le fue configurado una cuenta de correo electrĂłnico del mismo modo a lo explicado en el paso 6, pero con una cuenta de correo diferente.

    9. Verificar la llegada de notificaciones

    La verificaciĂłn de las notificaciones es una tarea muy sencilla, ya que basta con iniciar sesiĂłn en el Tenant con un usuario autorizado y realizar la solicitud de un Ă­tem del catalogo. Para este prueba utilizaremos el usuario pruebavra@lab.local y realizaremos una solicitud de despliegue.

    image

    Debido a que la solicitud de ítems del catalogo tiene configurada un Approval Policy, la solicitud quedará a la espera de la respuesta del usuario Aprobador configurado en el Tenant (para este caso de laboratorio, es el mismo Tenant Administrator) y será enviada una notificación.

    image

    En este punto podemos pasar a verificar los mensajes enviados en la cuenta de Gmail configurada y observaremos que desde la cuenta se ha enviado un mail tanto al usuario Administrador del Tenant como al usuario solicitante.

    image

    En la cuenta de correo asociada al Administrador del Tenant diego.tunubala (mismo usuario aprobador), llegará un correo con dos acciones disponibles Approve y Reject. Que permitirán Aceptar o rechazar el despliegue y enviar un comentario al usuario.

    image

    Mientras tanto en la cuenta de correo asociada al usuario de prueba pruebavra llegará una notificación indicando que la solicitud ha sido presentada.

    image

    10. Aprobar solicitud a través de email.

    Debido a que el usuario de dominio diego.tunubala@lab.local tienen configurado el role de Aprobador, al hacer clic en el enlace Approve, nos dará la opción de enviar un mensaje adjunto a la aprobación que será enviada a vRealize Automation de manera inmediata sin necesidad de entrar al portal de vRA. Lo mismo sucede si elegimos la opción Reject.

    image

    Una vez aprobada la solicitud, el usuario será notificado mediante un correo con el status Approved.

    image

    Después de la aprobación de la solicitud el flujo de despliegue continuará, finalizando nuevamente con una notificación vía correo electrónico al usuario, esta vez con la información de la VM o servicio solicitado desde el catálogo.

    image
    image

    Automatizando configuración de Dump Collector en ESXi 6.x

    en por Diego Felipe Tunubalá Medinaen ESXi, vSphereDeja un comentario

    De manera similar a como funciona Syslog Collector el cual recolecta todos los archivos Logs de los hosts ESXi, Dump Collector recopila el estados de la memoria VMkernel (Core Dumps) que generan los hosts cuando el sistema encuentra una falla crĂ­tica y se produce la conocida PSOD (Purple Screen of Death) o pantalla de la muerte.

    Antes de comenzar con la configuración, debemos saber que durante la instalación del hipervisor ESXi se crean dos particiones (Diagnostic Patition) encargadas de almacenar estos archivos, una Primaria de (110 MB) y una Secundaria de (2.5 GB). Sin embargo, es recomendable configurar un servidor remoto (Log Server) para transferir estos archivos a través de la red con el fin de tener una mayor retención de los mismos y poder realizar un mejor proceso de seguimiento y troubleshooting en la detección de la causa raíz de la falla. Para mayor información acerca del diseño de particiones de ESXi haga click Aquí.

    Por suerte sino contamos con un Log Server en nuestra infraestructura a dĂłnde dirigir estos Dumps, podemos utilizar la particiĂłn incluida en el vCenter Server Appliance dedicada para este propĂłsito.  Para mayor informaciĂłn de los servicios incluidos en vCenter Server consulte Componentes y Servicios de vCenter Server.

    image

    (Opcional) CONFIGURAR SERVICIO DUMP COLLECTOR EN VCENTER SERVER APPLIANCE

    Si vamos a utilizar la partición del vCenter para almacenar los Core Dumps, debemos tener en cuenta que el servicio Dump Collector no viene activo por defecto por lo que será necesario iniciarlo y dejarlo en modo automático para que se inicie con el Sistema Operativo. Para esto sigamos los siguientes pasos:

    1. Inicie sesiĂłn en el vCenter Server Appliance (VCSA) desde el vSphere Web Client con un usuario que cuente con permisos de administrador y luego vaya a Home > Administration > System Configuration > Services.

    2. En el panel de servicios del lado izquierdo haga click en el servicio VMware vSphere ESXi Dump Collector.

    3. En el panel central haga click en Actions > Edit Startup Type…,seleccione Automatic y click en OK.

    image

    4. (Opcional) Haga click en la pestaña Manage para  verificar el tamaño asignado al repositorio. Si desea cambiarlo haga click en el botĂłn Edit… El valor por defecto es 2 y el máximo 10.

    image

    5. Haga click en icono Start the Service para iniciar el servicio

    clip_image001

    CONFIGURAR ESXi DUMP COLLECTOR

    Si ya configuramos el servicio de Dump Collector en el VCSA o si por el contrario tenemos un Log Server disponible en la infraestructura, podremos iniciar con la configuraciĂłn en cada uno de los ESXi como sigue, utilizando como es costumbre la lĂ­nea de comandos ESXCLI o PowerCLI para automatizar la configuraciĂłn en todos los hosts del vCenter.

    ESXCLI

    La utilidad de lĂ­nea de comando esxcli puede ser utilizada en la consola del host ESXi, en el vCLI  (vSphere CLI) o en el vMA (vSphere Management Assistant).

    1. Inicie una sesiĂłn SSH al host ESXi que desea configurar ESXi Dump Collector

    2. Configure el ESXi con la dirección IP del servidor remoto que será utilizado como Dump Collector ejecutando la siguiente línea de comandos:

    esxcli system coredump network set --interface-name vmkX --server-ip xx.xx.xx.xx --server-port 6500

    Nota 1: Como mejor practica se recomienda utilizar un puerto VMkernel diferente al de gestiĂłn (vmk0). Sin embargo, para ambientes de laboratorio utilizaremos el mismo.

    Nota 2: La dirección IP del servidor remoto puede ser IPv4 o IPv6 ya que ambas son soportadas. Para el ejemplo la dirección IP será la dirección del VCSA.

    3. Habilite ESXi Dump Collector ejecutando la siguiente lĂ­nea:

    esxcli system coredump network set --enable true

    4. (Opcional) Verifique que ESXi Dump Collector esté configurado correctamente ejecutando la siguiente línea de comandos:

    esxcli system coredump network check

    image

    PowerCLI

    Con el fin de automatizar la tarea en todos los hosts del vCenter, podemos apoyarnos en la herramienta PowerCLI ejecutando script que se muestra a continuaciĂłn:

    1. Instale PowerCLI sino lo tiene instalado, con ayuda del siguiente video haciendo click aquĂ­.

    2. Inicie sesión hacia el vCenter desde el panel de script de PowerShell ISE ejecutando los siguientes cmdlets y espere a que le solicite usuario y contraseña:

    Connect-VIServer FQDN_IP_vCenterServer

    image

    3. Ejecute el siguiente script para configurar ESXi Dump Collector en todos los hosts del vCenter

    #Configurar ESXi Dump Collector

$MyLogServer= “IP_FQDN_Remote_Server”

Foreach ($hostx in (Get-VMHost)){
Write-Host "Configuring Dump Collenctor in $hostx" -ForegroundColor Yellow
$esxcli = Get-EsxCli -vmhost $hostx
$esxcli.system.coredump.network.set($null, “vmk0”, $null, $MyLogServer, 6500)
$esxcli.system.coredump.network.set($true)
$esxcli.system.coredump.network.get()
}

    4. Verifique la configuraciĂłn ejecutando el siguiente script

    #Check ESXi Dump Collector

Foreach ($hostx in (Get-VMHost)){
Write-Host "Checking dump collector in host $hostx" -ForegroundColor Yellow
$esxcli = Get-EsxCli -vmhost $hostx
$esxcli.system.coredump.network.get()
}

    image

     

    VERIFICACIĂ“N DE LA TRANSFERENCIA DE CORE DUMPS

    Una manera de verificar que los archivos Dump están siendo enviados de manera correcta al servidor remoto configurado, es generar un crash o PSOD en el servidor de manera controlada como sigue:

    1. Abra la consola remota del servidor (iLO, CIMC, iDRAC, etc.) en el que desea simular la falla, para monitorear el comportamiento del servidor.

    2. Inicie una sesiĂłn SSH en el host ESXi y ejecute la siguiente lĂ­nea de comandos:

    vsish -e set /reliability/crashMe/Panic 1

    3. Espere que se genere el archivo dump y reinicie el servidor.

    clip_image001[1]

    4. Verifique en el servidor remoto configurado, la existencia del archivo zdump generado.

    5. (Opcional) Si utilizĂł VCSA como repositorio de los archivos Dump inicie sesiĂłn SSH al vCenter Server, active la interfaz shell digitando Shell en la pantalla y verifique el log netdumper.log ejecutando la siguiente lĂ­nea de comandos para verificar que el archivo haya sido transferido y validar su ruta de destino:

    cat /var/log/vmware/netdumper/netdumper.log

    image

    Nota 3: El nombre del archivo generado contiene el nombre zdump y para el ejemplo con Dump Collector configurado en el VCSA, los archivos son alojados en la siguiente ruta /var/core/netdumps/ffff/AA/BB/CC/DD o lo que es lo mismo /storage/core/netdumps/ffff/AA/BB/CC/DD donde AA.BB.CC.DD indican los octetos de la direcciĂłn IP del host ESXi.