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.
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.
Como ya sabemos, una suma de verificación o checksum, es el resultado de ejecutar una función hash criptográfica dentro de un archivo, que tiene como propósito principal detectar cambios en una secuencia de datos para proteger su integridad. La particularidad de esto es que un pequeño cambio en el archivo provoca una salida totalmente distinta.
Dicho esto, checksum nos permite verificar la integridad del medio de instalación y estar seguros que el contenido del mismo no ha sido alterado y es tal y como lo indica su fabricante.
Lo importante a tener en cuenta en este post es que el objetivo no es garantizar una procedencia confiable del medio de instalación, sino verificar la integridad del archivo descargado.
Dejando un lado la teoría vamos a lo que nos interesa…
PROCEDIMIENTO
Utilizando la línea de comando de Windows (CMD) y la herramienta CertUtil incluida en las versiones mas recientes del sistema operativo. Ejecute el siguiente comando.
Nota 1: Para no tener que escribir el nombre del archivo, podemos simplemente seleccionarlo y arrastrarlo dentro de la consola de CMD de Windows y de esta manera incluirá la ubicación completa del mismo.
El resultado del comando nos devuelve un número de verificación similar al siguiente. Selecciónelo y cópielo para el siguiente paso (el de su Command Prompt).
e05748cea32d60566f0738a5b811cfdc
Para verificar que el archivo no ha sufrido ninguna modificación durante la descarga o posterior a ella, vaya a la página de descargas de VMware, donde descargó el medio de instalación, utilice la función Buscar… (ctrl+f o command+f) y dentro del campo de búsqueda pegue el numero que devolvió la salida del comando anterior.
De esta manera podemos buscar rápidamente si el numero que nos devolvió la herramienta CertUtil corresponde con el numero de verificación (MD5SUM) publicado por el fabricante.
Nota 2: Sino puede ver los detalles del medio de instalación en pagina de descargas. Haga clic en el enlace Read more para visualizar la información publicada por VMware.
Si el numero es encontrado como en la imagen anterior, el medio de instalación es apto para ser usado. Sino es así, vuelva a descargar el medio de instalación porque seguramente esta corrupto.
Nota 3: Puede utilizar la herramienta CertUtil para la suma de verificación de otros algoritmos hash cambiando el parámetro MD5 en el comando por cualquiera de los siguientes. VMware en su página de descargas publica la información para MD5SUM, SHA1SUM y SHA256SUM.
MD2
MD4
MD5
SHA1
SHA256
SHA384
SHA512
Por ultimo y como recomendación, realice este procedimiento para evitar algunos dolores de cabeza y perder tiempo tratando de solucionar problemas que probablemente vienen del medio de instalación y no del proceso de instalación o actualización.
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.
El problema básicamente radica en que el certificado ha expirado y no permite el inicio de sesión de ninguna manera.
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.
2. Instale EMC Navisphere CLI en su ordenador siguiendo cada uno de los pasos del asistente.
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.
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).
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
4. Ejecute ahora la herramienta NaviSECCLI.exe utilizando la siguiente línea de comandos:
Algunos de nosotros en el rol de consultor, hemos tenido que realizar implementaciones con diferentes tipos de hardware, HP, DELL, Huawei, Intel; pero no es sino hasta que nos encontramos con una infraestructura basada en Cisco Unified Computing System (UCS), con su UCS Manager, FI (Fabric Interconnect), Switches, chasis, blades, IO Modules, que nuestra primera impresión es decir, “Esto es otro mundo!”.
Pues bien, este es uno de los casos en donde la primera impresión no cuenta demasiado, y mas que complejo este tipo de infraestructuras resulta ser muy robusta y a la vez versátil. Alguno de sus beneficios se resumen en la siguiente lista. (Para ver mas información).
Aumento de la productividad del personal de TI y la agilidad empresarial a través del aprovisionamiento justo a tiempo y la igualdad de soporte para ambientes virtualizados y bare-metal.
TCO (Total Cost of Ownership) reducido a nivel de plataforma, sitio y organización a través de la
consolidación de infraestructura.
Un sistema unificado e integrado que se gestiona, repara y prueba como un
todo.
Un ecosistema de gestión integral que admite completo
aprovisionamiento y administración de infraestructura que puede hacer a sus instancias de Cisco UCS cualquier cosa, desde un motor de aplicaciones empresariales sin formato hasta un entorno multicloud contenedorizado.
Escalabilidad mediante la capacidad de administrar hasta 10,000 servidores con Cisco
UCS Central Software y escalar el ancho de banda de I/O para satisfacer la demanda.
Estándares abiertos de la industria respaldados por un ecosistema partner de industrias lideres.
Un sistema que se adapta para satisfacer las futuras necesidades del Centro de Datos como, potencia de computo, memoria y ancho de banda de E/S, etc.
Dicho lo anterior, veamos como configurar de manera sencilla una arquitectura DAS para poder presentar nuestro almacenamiento a los servidores UCS, sin tener que conectarlos a Switches de SAN y realizar las configuración a nivel de Zoning que esto conlleva.
En versiones de UCS anteriores a 2.1, se tenía la opción de usar DAS con UCS. Sin embargo, se necesitaba un Switch SAN conectado a los FI (Fabric Interconnect) para que el Switch pudiera enviar la base de datos de zonas a los FI. Es decir, la plataforma UCS no podía construir una base de datos de zonas por si misma. Por suerte, desde la version 2.1 en adelante UCS ahora tiene la capacidad de construir su propia base de datos de zonas de manera automática. Por lo tanto podemos tener DAS (Direct Attached Storage) con UCS sin la necesidad de un Switch SAN para crear la configuración de zonificación. Esta topología luce de la siguiente forma:
PROCEDIMIENTO DE CONFIGURACIÓN
1. Aunque suene obvio el primer paso es realizar las conexiones entre el almacenamiento y las interfaces de los FI.
2. Configurar FI en FC Switch Mode
Inicie sesión en el USC Manager y navegue hasta Equipment.
Expanda Fabric Interconnects.
Click en Fabric Interconnect A.
En la pestaña General click en Set FC Switching Mode
Repita los pasos 2(2-4) para el Fabric B.
3. Crear VSAN Requerido
Nota 1: VSAN (Virtual Storage Area Network) es una red de área de almacenamiento virtual. Las VSAN proporcionan aislamiento entre dispositivos que están físicamente conectados a la misma estructura. Con VSAN se pueden crear múltiples SAN lógicas sobre una infraestructura física común y se pueden diseñar múltiples VSAN con diferentes topologías.
Nota 2: Storage VSANs deberían ser creados solo bajo Storage Cloud y no debería ser permitido en los enlaces ascendentes FC, si es que los hay.
En el UCSM, navegue hasta la pestaña SAN.
Expanda Storage Cloud.
Expanda Fabric A.
Click derecho en VSANs, y seleccione Create Storage VSAN.
Ingrese el nombre de la VSAN.
Seleccione Enabled para FC Zoning.
Seleccione Fabric A.
Ingrese el VSAN ID y un VLAN ID para Fiber Channel over Ethernet (FCoE) para el Fabric A. Asegúrese que el FCoE VLAN ID es un VLAN ID que no esté actualmente usado en la red.
Repita los pasos 3(2-8) para el Fabric B.
4. Configure el rol del puerto en UCS
En este punto vamos a seleccionar los puertos de los FI conectados al almacenamiento para configurarlos como FC Storage Ports.
En el UCSM, navegue hasta la pestaña Equipment.
Expanda Fabric Interconnects.
Expanda Fabric Interconnect A.
Click derecho sobre el puerto conectado al almacenamiento, y seleccione Configure as FC Storage Port.
Seleccione la VSAN correcta para este puerto desde la lista desplegable.
Repita los pasos 4(1-5) para el Fabric B.
Si el puerto está configurado correctamente y está en arriba en el almacenamiento, el puerto de almacenamiento FC en UCS debería estar en línea.
5. Confirme que la WWPN del Storage Port haya iniciado sesión en el Fabric
Inicie sesión a través del shell seguro (SSH) o establezca una conexión Telnet a la IP virtual (VIP) del UCS.
Ingrese el comando
connect nxos {a | b}
, donde a | b representa FI A o FI B.
Ingrese el comando
show flogi database vsan vsan_ID
, donde vsan ID es el identificador del VSAN. En este ejemplo el identificador es 600.
La siguiente imagen muestra la salida de estos dos comandos, tanto para el Fabric A como para el B y en ellas se observa que la WWPN del puerto de almacenamiento ahora está conectada a la VSAN 600. Asegúrese de confirmar el inicio de sesión de los puerto de almacenamiento en ambos Fabrics.
6. Cree Storage Connection Policy.
En el UCSM, navegue hasta la pestaña SAN.
Expanda Policies, expanda Root, click derecho en Storage Connection Policies, y seleccione Create Storage Connection Policy.
La ventana Create Storage Connection Policy se abre para permitirle definir las WWPN Target del almacenamiento y los detalles del Fabric.
Ingrese el Nombre del Storage Connection Policy.
Seleccione un tipo de Zoning desde las tres opciones:
None: Use esta opción cuando no tenga zonas creadas en el FI, pero tenga zonas usadas para trafico ascendente del FC switch para una VSAN particular. Single Initiator Single Target: Use esta opción cuando solo tenga un puerto de almacenamiento conectado a un Fabric. Single Initiator Multiple Targets: Use esta opción cuando tenga más de un puerto de almacenamiento conectado a una Fabric. (Para el ejemplo tenemos dos conexiones hacia el almacenamiento desde cada Fabric).
Click en el signo mas (+)Add, para abrir la ventana que permite crear el FC Target Endpoint.
Ingrese la WWPN del FC target (almacenamiento).
Click en Path para el Fabric A.
Seleccione el VSAN ID correspondiente desde la lista desplegable.
Haga click en OK para guardar los cambio y repita los pasos e-h para agregar más WWPNs del almacenamiento (en el caso de haber seleccionado Single Initiator Multiple Targets).
Repita los pasos 6(5-9) pero esta vez seleccionando el Path en el Fabric B y agregando las WWNP Target del almacenamiento conectadas al Fabric B.
7. Edite el Service Profile.
Si ya tenemos hosts con Service Profiles asignados, solo necesitamos editarlos de la siguiente forma:
En el UCSM navegue hasta la pestaña Servers.
Expanda Servers, expanda Service Profiles, expanda root y seleccione el Service Profile asociado al host al cual desea conectar el almacenamiento.
Nota 3: Si todos los Service Profile de los hosts pertenecen a un mismo Service Profile Template, puede optar por modificar el Template y aplicar los cambios a todos los Service Perfiles desplegados desde esa plantilla.
Haga click en la pestaña Storage del panel central y luego click en vHBA Initiator Groups.
Click en (+) Add, Elija un nombre para el grupo de iniciadores y una descripción.
En Select vHBA Initiators, seleccione la vHBA conectada al Fabric A.
En Storage Connection Policy, seleccione la política creada en el paso anterior para el Fabric A y click en OK.
Repita los pasos 7(4-6) seleccionando esta vez la vHBA conectada al Fabric B y la Storage Connection Policy creada para ese Fabric.
Como resultado obtendrá una vista como la siguiente.
Expanda ahora el Service Profile, expanda vHBAs y seleccione una de las vHBAs del Service Profile (ejemplo vHBA vHBA0).
Haga click en la pestaña General del panel central y luego en la propiedad VSAN seleccione desde la lista desplegable la VSAN correspondiente al Fabric al cual se encuentra conectada (para el ejemplo Test_VSAN_Fabric_A, creada anteriormente).
Repita los paso 7(9-10) para la demás vHBAs configuradas en el Service Profile teniendo en cuenta seleccionar en la propiedad VSAN, la correspondiente de acuerdo a la conexión física hacia el Fabric.
8. Verifique la creación de las Zonas
En este punto las zonas deben haber sido creadas de manera automática por los FI y para verificarlas solo siga los siguientes pasos:
En el UCSM navegue hasta la pestaña Servers.
Expanda Servers, expanda Service Profiles, expanda root y seleccione el Service Profile asociado al host al cual presentó el almacenamiento.
Click en la pestaña FC Zone, y verifique la creación de las Zonas de manera automática.
Adicionalmente, puede también verificar las Zonas desde CLI de la siguiente forma:
Inicie sesión a través del shell seguro (SSH) a la IP virtual (VIP) del UCS.
Ingrese el comando
connect nxos {a | b}
, donde a | b representa FI A o FI B.
Ingrese el comando
show zoneset active vsan vsan_ID>
, donde vsan ID es el identificador para el VSAN. (En este ejemplo, el identificador VSAN es 600).
La siguiente imagen es un ejemplo de la salida de estos dos comandos.
Por último, solo debemos realizar rescan a las HBAs del host para visualizar las LUNs presentadas desde el almacenamiento. En este caso dado que es un host ESXi lo haremos de la siguiente forma:
Inicie sesión al vCenter con un usuario administrador.
Navegue hasta el host ESXi y haga click en Configure y luego en Rescan Storage…
Haga click en cada una de las vmhbas y podrá observar que ahora en la pestaña Devices se muestran las LUNs presentadas. Para el ejemplo, solo una LUN de 512GB.
Lanza Putty nació hace un par de años por la necesidad de tener que agregar un usuario con permisos específicos en más de doscientos blades distribuidos en aproximadamente veinte enclosures de la marca HP (Hewlett Packard) en la compañía para la cual me desempeñaba como administrador de infraestructura. Una tarea que por supuesto no tenía ningún sentido realizar manualmente en cada uno de los blades desde la interfaz de administración. Por esta razón, decidí desarrollar una herramienta que utiliza PuTTY.exe y Plink.exe para lanzar múltiples conexiones SSH, Telnet, Rlogin o RAW; y envía uno o varios comandos a una lista de instancias remotas desde una única interfaz.
Lanza Putty es una herramienta desarrollada en lenguaje LabVIEW y aunque fue inicialmente pensada para facilitar la administración de chasis y bahías en la infraestructura, puede ser también útil para administrar cualquier sistema basado en Linux, incluso en ocasiones la utilizo para enviar comandos ESXCLI a múltiples hipervisores.
¿Por qué en LabVIEW?
La respuesta es muy simple, necesitaba resolver el problema rápidamente y el lenguaje de desarrollo que mejor manejaba en ese entonces por su ventajas en cuanto al tiempo de desarrollo era LabVIEW. Hoy en día aunque nos apoyamos con herramienta más especializadas como PowerShell y PowerCLI para la implementación y administración de vSphere, me sigue siendo de gran utilidad esta herramienta.
FUNCIONAMIENTO
1. Descargue el Run-Time Engine de LabVIEW (versión 2011) de la página oficial o desde aquí, e instálelo en su ordenador para poder ejecutar el .exe de la aplicación.
2. Descargue la aplicación desde el repositorio compartido haciendo click Aquí.
3. Cree un archivo *.txt con la lista de FQDNs o IPs de las instancias remotas que desea administrar, y guárdelo en la carpeta \Lanza_PuTTY_APP\Data
4. Ejecute la aplicación LanzaPuTTY.exe que se encuentra en el directorio raíz y seleccione el archivo creado anteriormente.
5. Ingrese usuario y contraseña de las instancias remotas
6. Seleccione el protocolo a utilizar. El valor por defecto es el protocolo SSH
7. Ingrese los comandos que desea ejecutar en las instancias remotas. Por ejemplo si utilizamos la herramienta para verificar el driver, firmware o vendor ID de varios hipervisores podemos incluir los siguientes comandos en el campo “Comandos a Ejecutar”
#ESXi Hostname
hostname
#ESXi Version
vmware -v -l
#NICs
esxcli network nic list
#Drivers y firmware NICs
esxcli network nic get -n vmnic0
#Vendor ID NICs
for a in $(esxcfg-nics -l |awk '{print $1}' |grep [0-9]) ;do vmkchdev -l |grep $a; done
8. Haga click en Archivo->Ejecutar para realizar ejecución con salida en Command Prompt (cmd), se recomienda que la primera vez que se accede a la instancia remota a través de esta herramienta se realice con este modo de
ejecución debido a que la sesión solicita una confirmación de seguridad de PuTTY, que debe ser aceptada escribiendo Y y luego presionando Enter.
9. La opción Archivo->Ejecutar sin CMD, realiza una ejecución con salida en el indicador “Salida de Comandos”, que automáticamente crea un fichero con el nombre Log_Putty.txt con estas salidas de comando. Este modo de ejecución se debe utilizar si ya se ha accedido a las instancias por lo menos una vez con PuTTY.exe, de lo contrario el programa se quedara esperando la confirmación de la alerta de seguridad de PuTTY, sin mostrar ninguna notificación debido a que el programa estará ejecutándose de manera oculta. Esta opción se recomienda para generar Logs después de haber realizado acciones con el modo indicado en el paso anterior.
10. Verifique el contenido del Log_Putty.txt ubicado en la carpeta raíz de la aplicación
![clip_image001[5]](https://nachoaprendeit.com/wp-content/uploads/2018/07/clip_image00151.png "clip_image001[5]")
![clip_image001[5]](https://nachoaprendeit.com/wp-content/uploads/2018/07/clip_image00152.png "clip_image001[5]")
![clip_image001[7]](https://nachoaprendeit.com/wp-content/uploads/2018/08/image.png "clip_image001[7]")
![clip_image001[9]](https://nachoaprendeit.com/wp-content/uploads/2018/07/clip_image0019.png "clip_image001[9]")
![clip_image001[11]](https://nachoaprendeit.com/wp-content/uploads/2018/07/clip_image001111.png "clip_image001[11]")
Nacho Aprende IT 