Hola en este nuevo post vamos a dar continuación al post anterior (post). Se hará una configuración de nics y vmknics para la recuperación de la red de administración en uno de los nodos ESXi que dejó de comunicarse a partir de una actualización a vSphere 7.0U2. KB84148.
La cuasa de este problema es relacionado a que uno o varias interfaces VMKERNEL pueden encontrar en un error durante la fase de jumpstart lo que provoca que las interfaces no se restauren. La solución es colocar la version vSphere 7.0U3d
Workaround, para poder tener gestión al ESXi debemos tener acceso al DCUI, hablé en un post anterior sobre como entrar a modo comandos. Aquí. Luego de ello debemos conocer los comandos útiles que ayudarán a la gestión y configuración de las redes virtuales.
Identificación de vSwitch
Luego de identificar el vSwitch que tenía la configuración de la red de administración del hosts usando el comando esxcfg-vswitch podemos detectar que no tiene NICs ni VMKNICs conectados.
Crear nuevo portgroup virtual y agregar la tarjeta de red
esxcli network vswitch standard portgroup add --portgroup-name=<name> --vswitch-name=<vSwitch_name>
El comando anterior crea un nuevo portgroup donde va a ser configurado la red de administración del host ESXi.
Si la red de administración tiene tagueado una VLAN; se coloca la configuración de la VLAN usando el comando:
esxcli network vswitch standard portgroup set -p <pg_name> --vlan-id=<VLAN_ID>
Y para agregar la tarjeta de red disponible al vSwitch se usa el siguiente comando:
esxcli network vswitch standard uplink add --uplink-name=<vmnic0> --vswitch-name=<vSwitch_name>
En el ejemplo, el portgroup destinado para administración del Host es mgmt y la nic vmnic0, y la red no tiene configurado un VLAN ID
Creación de un nuevo VMKERNEL
Luego de tener listo el vSwitch, el portgroup y la tarjeta de red física configurada, debemos crear el puerto de kernel que tomará la configuración de red del host ESXi. Usamos el siguiente comando:
esxcli network ip interface add --interface-name=<vmkX> --portgroup-name=<pg_name>
Revisamos que se cree un nuevo VMKERNEL, va a crear automáticamente dos puertos de kernel, uno para IPv4 y otro para IPv6.
Observamos que no tienen configuración de direccionamiento IP, para configurar las direcciones IP, máscara de red y tipo (estática o DHCP). El Comando que realiza esta configuración es:
esxcli network ip interface ipv4 set --interface-name=<vmkX> --ipv4=<Direccion_IP> --netmask=<mascara_red> --type=static
Finalmente, se cuenta con conectividad de red al servidor ESXi, solventando el inconveniente. Se recomienda realizar validación previa de las versiones a instalar para evitar los errores conocidos.
Hola en este nuevo post vamos a realizar trabajos sobre switches virtuales, tarjetas de red y puertos de kernel usando línea de comandos. Por lo general estos trabajos son realizados en las consolas de administración del host o de vCenter Server.
En días pasados tuve que realizar un procedimiento de troubleshooting relacionado con el cambio de la configuración de redes físicas externas que afectó directamente a la red de nuestros servidores ESXi.
Para poder tener gestión al ESXi debemos tener acceso al DCUI, hablé en un post anterior sobre como entrar a modo comandos. Aquí. Luego de ello debemos conocer los comandos útiles que ayudarán a la gestión y configuración de las redes virtuales.
Comandos esxcli y esxcfg
Los comandos forman parte de los paquetes de vSphere CLI que nos permiten realizar configuraciones. (vSphereCommandLine) Estos comandos son:
Comandos vCLI
Descripción
ESXCLI
Grupo de comandos que administra aspectos de hosts ESXi, es el nuevo grupo de comandos para el ESXCLI que pueden ser usados remotamente o por ESXi Shell. Además que pueden ser ejecutados desde PowerCLI usandos cmdlet Get-EsxCli.
vicfg-
Grupo de comandos que eventualmente serán reemplazados por el grupo de comandos ESXCLI, En este grupo se incluyen el conjunto de comandos esxcfg- que son el reflejo de los comandos vicfg- en el paquete vCLI.
Otros Comandos: vmware-cmd, vifs, vmkfstools
Grupo de comandos que son implementados bajo Perl, este grupo al igual que vicfg- serán reemplazados por ESXCLI.
DCLI
DCLI es un cliente CLI para la interfaz de vCloud Suite SDK para administrar los servicios de VMware SDDC.
Por lo tanto, los comandos que vamos a usar para listar las redes virtuales o switches virtuales, tarjetas de red y puertos de kernel de nuestro ESXi son:
Listar vSwitches
[root@esx01:~] esxcli network vswitch standard list
Observamos que el comando lista todos los vSS que están creados en el ESXi, además nos muestra datos que pueden ser útiles para procesos de troubleshooting como los son los puertos usados, el MTU, los Uplinks, los portgroups y los comandos beacon si están configurados.
[root@esx01:~] esxcli network vswitch dvs vmware list
El comando muestra de igual manera que los vSS a todos los vDS que están creados en el ESXi, en esta vista, a parte de la información importante para troubleshooting, está listado los diferentes Port ID. Estos Port ID son las identificaciones de cada elemento del vDS que se usa para realizar las configuraciones necesarias apuntando a cada elemento por su ID.
[root@esx01:~] esxcfg-vswitch -l
El grupo de comandos se diferencia en que se listan todos los switches vSS y vDS en una sola ejecución, pero no muestra mayor información que puede ayudar a una revisión profunda de problemas.
Listar vmknics
[root@esx01:~] esxcli network ip interface list
Aquí observamos todos los puertos kenel que están configurados en nuestro ESXi, podemos apreciar que tenemos información relacionada con los IDs de los vSwithces que pertencen.
[root@esx01:~] esxcfg-vmknic -l
de igual manera que el comando ESXCLI, se listan todos los puertos de kernel que tiene el ESXi creados y configurados. La diferencia es que nos da las direcciones IP y tipo de protocolo IP (IPv4).
Listar nics
[root@esx01:~] esxcli network nic list
[root@esx01:~] esxcfg-nics -l
Los dos gurpos de comandos muestran la misma información, la única diferencia es el estado administrativo de la tarjeta de red, que puede ser controlado usando los comandos ESXCLI.
[root@esx01:~] esxcli network nic up -n vmnic1
[root@esx01:~] esxcli network nic down -n vmnic1
En una segunda parte de este post, vamos a realizar configuraciones de nics y vmknics.
Hola, en este nuevo post explicaré el uso de comandos necesarios para realizar cambios de máquinas virtuales a nivel de shell de ESXi.
Recientemente trabajé en un cliente que perdió conectividad total a todo el ambiente de gestión de VMware y lo único que podíamos hacer era ingresar a la consola DCUI (Direct Console User Interface) de los hosts. La solución para el cliente fue encender unas VMs para levantar los accesos. Pues bien, los pasos que debemos realizar para solventar este tipo de problemas son:
Habilitar ESXi shell (Tech Support Mode) y Modo Mantenimiento
Una vez dentro de la consola DCUI del ESXi, debemos activar el servicio de ESXi Shell para tener acceso a los comandos esenciales de mantenimiento, en la opción Troubleshooting Mode y dando enter en Enable ESXi Shell.
Luego realizamos la combinación de teclas ALT+F1 para ingresar al ESXi Shell local, y una vez dentro, ejecutamos los comandos necesarios para solventar el problema. En este caso en particular primero colocamos al hosts en modo mantenimiento usando los comandos:
esxcli system maintenanceMode set --enable true
Para salir de modo mantenimiento ejecutamos:
esxcli system maintenanceMode set --enable false
Para saber si el host está o no en modo mantenimiento, se ejecuta el comando:
esxcli system maintenanceMode get
Comandos VIM-CMD
En este momento los comandos que usaremos corresponden a la familia de comandos de vmware-vim-cmd que básicamente son comandos interactivos de la sesión de línea de comandos y pueden ser usados con o sin el servicio ESXi shell activado.
El comando que usaremos es:
vim-cmd vmsvc
Correspondiente a VMs con las siguientes opciones:
getallvms
Lista todas las VMs que el host esta gestionando, acá se presenta el VMID importante para realizar trabajos sobre la VM.
power.getstate
Muestra el estado actual de la VM, si esta encendida, apagada, suspendida.
power.off
Apaga la VM, el apagado es completo
power.on
Enciende la VM
power.reboot
Reinicia a la VM
power.reset
Reinicia a la VM, reinicio es gracefull. La VM debe tener instalado VMware Tools
power.shutdown
Apaga a la VM, apagado gracefull. La VM debe tener instalado VMware Tools
power.suspend
Suspende a la VM. La VM debe tener instalado VMware Tools
Primero, debemos tener el VMID de la VM que deseamos gestionar, ejecutando el getallvms
Ejecutamos la opción que necesitamos realizar a la VM rv-ad01 con VMID 42, en nuestro ejemplo vamos a encender a la VM, sin antes validar en qué estado se encuentra (encendida, apagada, suspendida)
Y realizando el encendido de las VMs que crearon el problema, pudimos solucionar la conectividad y posterior gestión del ambiente VMware.
Finalmente, el grupo de comandos vmware-vim-cmd cuentan con opciones que nos ayudarán a realizar un troubleshooting a nivel de ESXi shell cuando no podamos realizarlo a nivel de interfaz web o vsphere-client.
Recomiendo revisar la documentación de VIM-CMD para mayor información acá.
Hola, en este post vamos a realizar la verificación de integridad de una cadena de snapshots para asegurarnos que no existe una pérdida de comunicación en la cadena, errores en los discos miembros de la cadena o pérdida de discos de la cadena.
Tip, el snapshot es una funcionalidad de la virtualización que es de gran ayuda cuando necesitamos realizar algún cambio importante en la máquina virtual, en un servicio y/o aplicación, instalación de un aplicativo nuevo, o simplemente actualización del sistema operativo.
el proceso es sencillo, se crea una foto o un punto de restauración al cual podemos retroceder si encontramos algún problema o se presente un evento que afecte al servicio. El proceso de un snapshot crea discos delta.vmdk por cada archivo flat.vmdk y discos XXXX#.vmdk por cada vmdk que la máquina virtual tenga.
Pero qué pasa cuando un disco delta o un delta parte de una cadena de snapshots se pierde, se borra o se daña??. Podemos perder información, datos o incluso el disco completo de la máquina virtual. En algunos casos solo se pierden los datos ingresados en el disco delta.
VMKFSTOOLS
Usaremos el comando vmkfstools para revisar si la cadena de snapshots esta correcta:
vmkfstools -q discoXXXX#.vmdk -v10
Primero se toma el ultimo snapshot XXXX#.vmdk generado, en este ejemplo es -000004.vmdk:
Luego corremos el comando:
El comando realiza la revisión de la integridad de toda la cadena de discos deltas que tiene el disco original. Al finalizar debería darnos toda la información de cada uno de los snapshots creados.
Si existe un Failed quiere decir que no existe una concordancia con la cadena de snapshots, para ello debemos revisar cada uno de los discos XXXX#.vmdk de la cadena de snapshots.
En nuestro ejemplo tenemos un error al no encontrar un disco vmdk:
También puede ser usado el comando:
vmkfstools -e discoXXXX#.vmdk
Este comando debe ser usado solamente cuando la VM este apagada. Caso contrario se produce el siguiente error:
Failed to lock the file (16392)Disk chain is not consistent : Failed to lock the file (16392)
Si la cadena esta correcta no muestra
Disk chain is consistent
Si la cadena no está consistente nos muestra:
Finalmente, recomiendo NO usar un snapshot como un respaldo, para evitar eventos de pérdida de información de los discos que forman la cadena de snapshots.
Se pueden seguir las mejores prácticas de snapshots sobre ambientes vSphere aquí.
Hola, este post tiene dos partes, una parte detallo la solución de un problema que tuve en la implementación de vRO 7 y la otra parte nos enfocamos en como generar el certificado en formato PEM que nos será útil para la conexión con vCloud Director.
Sincronización manual de clúster vRO
Hace un tiempo atrás tuve un problema en una instalación nueva de vRO 7 Standalone. Todo el procedimiento fue satisfactorio hasta llegar a la parte en que el vRO pide reiniciar para que tome las configuraciones de SSO y agregue los íconos Role Based Access Management e Inspect Workflows, lo cual es normal.
Pero luego de varios reinicios, la validación de la configuración aplicada y el estado del clúster no levantan.
Luego de revisar en Logs de vRO: vco-server.log y vco-configurator.log y en los cuales se menciona que "vRO requiere sincronización de la configuración", aún si no existen otros elementos en el clúster de vRO.
Me encontré con el KB: 59598, que detalla como sincronizar el clúster de forma manual usando el script vro-configure.sh ; pero el KB sirve para un clúster de dos o más vRO instalados, y al tener un clúster standalone con solo un vRO instalado, debemos usar como opción syn-local
Ingresando por consola de comandos y con credenciales de root. Usando el cliente PuTTY por ejemplo, podemos correr los siguientes comandos:
Primero debemos parar los servicios vco-server y vco-configurator
service vco-server stop; service vco-configurator stop
service vco-server start; service vco-configurator start
Con estos sencillos pasos, la sincronización de la configuración y el estado del clúster standalone levantan sin problemas.
Generación de certificado PEM
El certificado es importante para la conectividad de vRO con vCloud Director, por ello, detallo como extraer el certificado digital en formato PEM usando los siguientes pasos:
Primero, ingresando con credenciales root al SSH de vRO, debemos obtener la contraseña del contenedor keytool de Java, usando el comando:
El archivo vro.pem fue generado y almacenado en la ruta que se defina en este caso /root y puede ser descargado usando WinSCP por ejemplo.
Finalmente, siempre se recomienda realizar un snapshot antes de ejecutar y/o cambiar archivos de vRO.
Este Blog usa cookies propias y de terceros para optimizar la navegación y que puedas ver correctamente su contenido. Si permaneces en el sitio asumiremos que estas de acuerdo .
