Administrar ESX(i) durante el desastre (III)
Siguiendo con los comandos de la herramienta que nos ocupa, vim-cmd, esta semana me gustaría centrarme en aquellos comandos que nos permiten gestionar aquellos aspectos más relacionados directamente con el host ESX(i) al que estamos conectados.
Por hacer un poco de memoria, la semana pasada os animaba a ejecutar el comando vim-cmd vimsvc/license –show. Como podréis suponer, este comando muestra información acerca de la licencia que está asignada a nuestro ESX(i):
~ # vim-cmd vimsvc/license –show
[200] Sending request for installed licenses…[200] Complete, result is:
serial: H468P-0E050-58E39-018H0-1RQ05
vmodl key: esxBasic
name: vSphere 4 Hypervisor
total: 0
used: 1
unit: cpuPackage:6core
Properties:
[ProductName] = VMware ESX Server
[ProductVersion] = 4.0
[count_disabled] = This license is unlimited
[feature] = maxRAM:256g («Up to 256 GB of memory»)
[feature] = vsmp:4 («Up to 4-way virtual SMP»)
[FileVersion] = 4.1.0.8
[LicenseFilePath] = /usr/lib/vmware/licenses/site/license-esx-40-e1-4core-200803
…
[200] End of report.
Este comando en particular no presenta opciones mucho más espectaculares que esta, salvo la gestión de tareas mediante los subcomandos tasks_list, tasks_info, tasks_description y tasks_cancel y la gestión de roles del subcomando auth. Al igual que ocurría con las máquinas virtuales, para poder hacer cualquier operación con las tareas tendremos que localizar el identificador de tarea mediante el comando tasks_list.
Permitidme que no me pare mucho en el comando vimsvc, ya que el comando del que os quiero hablar a continuación lo encuentro mucho más interesante, hostsvc. Y es que el interés y la importancia de este comando destacan por sí mismas en el momento en el que listamos los subcomandos de los que dispone:
~ # vim-cmd help hostsvc
Commands available under hostsvc/:
advopt/ enable_local_tsm queryconnectioninfo
autostartmanager/ enable_remote_tsm querydisabledmethods
datastore/ firewall_disable_ruleset refresh_firewall
datastorebrowser/ firewall_enable_ruleset refresh_services
firmware/ hostconfig runtimeinfo
net/ hosthardware set_hostid
rsrc/ hostsummary standby_mode_enter
storage/ login standby_mode_exit
summary/ logout start_local_tsm
vmotion/ maintenance_mode_enter start_remote_tsm
connect maintenance_mode_exit stop_local_tsm
cpuinfo memoryinfo stop_remote_tsm
disable_local_tsm pci_add task_list
disable_remote_tsm pci_remove
Debido a motivos de espacio del post, y sobre todo por no aburriros con todos los detalles, no entraré en todas las opciones que presenta este comando, pero al menos sí que me gustaría hacer una descripción somera de las más importantes y, al igual que la semana pasada, repasar un par de ejemplos con vosotros.
- Advopt, nos da acceso a las opciones avanzadas del host. Sería equivalente al menú de “Advanced Settings” que tenemos disponible en el vClient, en la pestaña “Configuration” del host.
- Autostartmanager, se encarga de gestionar las opciones de inicio y parada automáticos de las máquinas virtuales. Equivalente al menú “Virtual Machine Startup/Shutdown”
- Datastore, habla por sí solo. Veremos un ejemplo en detalle.
- Datastorebrowser, en teoría nos debería permitir explorar los datastores configurados en el host, pero en la práctica no está implementado y por lo tanto no es operativo.
- Firmware, es el encargado de gestionar las actualizaciones y el backup de nuestro ESXi
- Net, realmente interesante, ya que nos permite configurar muchos de los aspectos del ESX(i) relacionados con la red. Veremos un ejemplo en detalle.
- Rsrc, está destinado a gestionar los grupos de recursos.
- Storage, también bastante interesante, es el subcomando encargado de gestionar los aspectos relacionados con el almacenamiento desde el punto de vista hardware.
- Summary, nos presenta un resumen de los dispositivos de almacenamiento.
- Vmotion, encargado de gestionar los aspectos de configuración relacionados con vmotion.
A continuación me gustaría profundizar un poco más alguno de los puntos que comentaba anteriormente con un par de ejemplos.
En el primer ejemplo veremos como añadir un datastore de tipo NFS a nuestro ESXi. Si revisamos la ayuda del comando vemos:
~ # vim-cmd help hostsvc/datastore/nas_create
Usage: nas_create name remoteHost remotePath readonly
Add a NAS datastore.
readonly is a boolean value, 1 for readonly and 0 for rw access.
Con lo que nuestro comando quedaría de la siguiente forma:
~ # vim-cmd hostsvc/datastore/nas_create NFS_Datastore NFS_Host /backups 0
~ #
Al igual que ocurre con los datastores de tipo NAS, podremos crear datastores locales mediante el comando localds_create o datastores “compartidos” mediante el comando vmfs_create. Particularmente importante e interesante es el hecho de que debemos consultar las opciones hardware disponibles a la hora de crear un datastore “compartido” mediante el comando vmfs_query_create_options.
Otras opciones relacionadas con el almacenamiento que no quería dejar escapar son las que se encuentran bajo el comando storage. Si bien, de nuevo, por no hacer muy extenso el post no vamos a entrar en detalle en ellas, creo que es importante mencionar al menos algunas de las más útiles e importantes:
- storage/multipath_info, muestra información acerca de la política de multipath configurada por cada LUN.
- storage/hba_rescan, que permite realizar un re-escaneo de la hba que se le pase como parámetro
Continuando con los ejemplos de algunos de los subcomandos de hostsvc, veremos ahora como crear un nuevo virtual switch y asignarle su correspondiente NIC física y portgroups.
En primer lugar crearemos un virtual switch sin asociaciones ninguna, es decir el “esqueleto” de lo que será un vSwitch completamente funcional:
~ # vim-cmd hostsvc/net/vswitch_add vSwitch_TEST
~ #
A continuación crearemos y asociaremos los portgroups que nos interesen. En este caso agregaremos un portgroup de tipo Virtual Machine:
~ # vim-cmd hostsvc/net/portgroup_add vSwitch_TEST VM_PortGroup
~ #
Es importante consultar la ayuda de este comando, ya que en el apartado OPTIONS encontraremos las diferentes variantes y políticas que podremos configurar para el portgroup, bien durante su creación o posteriormente con el comando portgroup_set.
En este punto añadiremos las NIC físicas para dar servicio a nuestro vSwith:
~ # vim-cmd hostsvc/net/vswitch_setbondbridge –vsbridge-bond-pnics=vmnic1 vSwitch_TEST
~ #
Con lo que tendremos nuestro virtual switch configurado y listo para el servicio.
Es importante recordar que muchas de las opciones y políticas que tenemos disponibles en el vClient a través de las propiedades de los port groups o los virtual switches, las tenemos también disponibles en las opciones de los comandos encargados de gestionar estos elementos, por lo que resulta fundamental consultar la ayuda de estos comandos para realizar los ajustes que más nos interesen.
¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.