esx

Actualizando nuestros servidores ESX 4.x a ESXi 5

Que tal gente, con el anuncio de vSphere 4.1 se dejo en claro que dicha versión era la ultima en contar con las dos arquitecturas a las cuales todos estábamos acostumbrados ESX y ESXi, y así cambiar de lleno a una arquitectura basada en ESXi. Existen muchas empresas que manejan la arquitectura ESX y que se deberán enfrentar al cambio hacia ESXi, en este post les estaré mostrando las tres distintas maneras que tenemos para poder realizar una actualización de ESX a ESXi sin necesidad de realizar una re-instalación.

Comencemos por dejar en claro que esta actualización si representa un impacto a la producción, ya que requiere de un reinicio y de que nuestros hosts entren en modo mantenimiento.

Tenemos las siguientes opciones:

  • VMware Update Manager (VUM) - para mi punto de vista la opción mas sencilla y automatizada vamos a ver como es el proceso:

Ingresamos a update manager y vamos a la pestaña de “ESXi images”, hacemos click en “Import ESXi image…” y seleccionamos nuestro iso:

            Esto importará la imagen de ESXi 5 a nuestro servidor de VUM

Una vez importado, tendremos la opción de crear un baseline para aplicar este upgrade marcamos la casilla de “Create a baseline using the ESXi image” y la configuramos:

De tal manera que quedará creado un baseline que podremos asignar a un objeto del inventario:

En este punto solo necesitamos seleccionar nuestro host o cluster y aplicar dicho baseline:

Aquí podemos ver como comienza la actualización del host esx3.hispavirt.com de ESX 4.1 a ESXi5:


  • Actualización Interactiva - Esta actualización la realizamos con la media de ESXi 5, puede ser local o booteo por PXE, al iniciar la instalación detectará que existe una partición VMFS y un sistema ESX instalado:

Donde tendremos las siguientes opciones:

  1. Migrar a ESXi 5 preservando el datastore VMFS
  2. Instalar ESXi 5 preservando el datastore VMFS
  3. Instalar ESXi 5 sobre escribiendo el datastore VMFS

Migración Completada

  • Actualización con Scripts - al igual que una instalación con nuestro archivo kickstart o (ks.cfg) podemos realizar una actualización, solo es cuestión de especificar que la operación sera “upgrade” en nuestro script (por default es install).

 

 

VCAP – Sección 5 – Implementar y mantener Host Profiles

Que tal gente continuando con la serie de VCAP-DCA nos toca hablar de Host Profiles, vamos a conocer en que nos apoyan y como configurarlos, también podremos ver cuáles son las limitaciones actuales.

¿Qué es un Host Profile?

Básicamente es una plantilla de configuraciones de red, almacenamiento, seguridad, etc. que nosotros creamos a partir de un host ESX/ESXi que tiene todos estos parámetros de manera ideal. Utilizando este profile podemos mantener la misma configuración a través de un gran número de hosts lo cual simplifica la administración del día a día.

Para poder utilizar esta capacidad necesitamos tener el licenciamiento enterprise plus.

Limitaciones

  • En el caso de contar con clusters basados en ESX y ESXi no podremos utilizar host profiles, debido a diferencias que existen entre los mismos, en este caso se recomienda crear clusters de ESX y clusters de ESXi para poder utilizar host profiles.
  • Solo podemos aplicar un profile por cluster.
  • No podemos incluir configuraciones de ISCSI.
  • No podemos incluir información de licenciamiento.
  • No podemos incluir configuraciones de multipathing.
  • No podemos incluir políticas de Distributed switches.

Utilizar el editor de perfiles para editar y/o deshabilitar políticas

Para crear un perfil de un host solo es cuestión de seleccionar nuestro host , click derecho sobre el mismo y Host Profile>Create Profile from Host…

Esto nos abrirá un wizard donde tendremos que ingresar el nombre del perfil y descripción del mismo, este host será tomado como referencia para el perfil creado.

Una vez creado este perfil o nuestros perfiles requeridos, podemos editarlos desde Home>management>Host Profiles.. , donde podremos seleccionar el perfil que necesitamos modificar click derecho sobre el y “Edit Profile…” , esto nos abrirá la ventana de edición:

En esta ventana podremos ver todas las políticas y configuraciones que se obtuvieron a partir del host de referencia agrupadas en “sub profiles”.

Crear sub-profiles

Aquí más que crear yo lo veo como editar los sub perfiles, es decir, no podemos agregar un nuevo sub perfil sino editar las políticas que pertenecen al mismo, tenemos los siguientes sub-profiles:

  • Memory reservation – Aquí configuramos la cantidad de memoria que necesitamos asignar al Service console (solo aplica para ESX).

  • Storage – aquí configuramos nuestros datastores de NFS, ojo aquí no podemos configurar ningún parámetro de ISCSI ni políticas de multipathing.

  • Networking – en este subprofile tenemos la capacidad de editar que nics se estarán utilizando en cada vSwitch, duplex de las nics, portgroups, incluso configuración de Switches distribuidos.

  • Date and Time – Aquí podemos configurar el servidor de tiempo (NTP) y zona horaria que necesitemos.

  • Firewall – aquí configuramos las políticas de firewall, en este caso solo aplica para ESX.

  • Security – En este sub profile tenemos la capacidad de asignar los permisos de usuario.

  • Service – en este sub profile podemos configurar que servicios estarán iniciados como ssh, ntp, vpxa (vcenter), etc.

  • Advanced configuration option – en este sub profile podemos definir opciones avanzadas que seran aplicadas en los hosts a los cuales se les aplique el profile en cuestión.

  • User configuration - aquí definimos los usuarios que necesitamos tener en nuestros hosts.

  • User group configuration – aquí podemos definir grupos de usuarios.

  • Authentication Configuration - aquí definimos el dominio al que se deberán unir nuestros hosts y las credenciales para poderlo realizar.

Utilizar host profiles para configurar vDS

Honestamente esta de mas repetir algo que ya está bien documentado por VMware incluso con imágenes. Les sugiero echar un ojo a este documento a partir de la pagina 24 se describe perfectamente el procedimiento

http://vmware.com/files/pdf/vsphere-vnetwork-ds-migration-configuration-wp.pdf

 

Logs de Host profiles

todas las operaciones que realizamos las podemos encontrar en un log en la siguiente ruta:

C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs
Estos logs se llaman PyVmomiServer.log.#

 

Paso-a-paso – Dropbox & vSphere vMA

Que tal gente, hace un tiempo que no podía postear debido a que me encontraba fuera del país dictando un curso y que también estuve bastante ocupado estas ultimas semanas… pero estoy de vuelta , y esta vez les voy a dar el paso a paso de como integrar Dropbox a su vMA. Generalmente para los ambientes de VMware que administro utilizo la vSphere Management Assistant (vMA) para facilitarme tareas entre todos los hosts. Muchas veces me encuentro con el problema que solo tengo acceso a traves del vsphere client a la infraestructura remotamente por lo cual es un verdadero problema estar subiendo archivos.

Vamos a revisar los pasos para poder instalar Dropbox en nuestra vMA:

Paso 1-. Instalamos Dropbox en nuestra vMA

descargamos el source para 64 bits

wget -O dropbox.tar.gz "http://www.dropbox.com/download/?plat=lnx.x86_64"

extraemos el tar

tar -xvzf dropbox.tar.gz

y ejecutamos el daemon de dropbox

~/.dropbox-dist/dropboxd

Paso 2-. Una vez ejecutado el daemon de dropbox se nos mostrará un mensaje como el siguiente donde se nos da un link para registrar este cliente con una cuenta de dropbox ya creada:

Una vez registrado el cliente tenemos la capacidad de poder sicronizar carpetas locales con dicho cliente, aquí tengo un ejemplo de windows y mi cliente (vMA):

OPCIONAL

Si nosotros queremos que dropbox se ejecute cada vez que nuestra vMA se inicia, debemos seguir los siguientes pasos:

copiamos el contenido del script de initd que podemos encontrar en este link  FedoraStartup vamos a nuestra vMA y editamos un archivo llamado dropbox en la ruta /etc/init.d con vi y copiamos el contenido:

Editamos el archivo /etc/sysconfig/dropbox para agregar el usuario o usuarios que necesitamos que ejecuten dropbox:

Damos permisos a los archivos:

chmod 0755 /etc/init.d/dropbox
chmod 0644 /etc/sysconfig/dropbox
ls -l /etc/init.d/dropbox /etc/sysconfig/dropbox

Activamos el servicio de dropbox para los runlevels 3 y 5:

chkconfig dropbox on

Verificamos que efectivamente esta activado en dichos run levels:

chkconfig --list | egrep '3:on|5:on' | less

VCAP – Sección 3 – optimización de performance para vSphere

Que tal gente, hemos llegado a la sección 3 de nuestra guÍa para el examen VDCA410, en esta sección estaremos hablando de performance y DRS. Todas las mejores prácticas, datos que debemos saber y las configuraciones ideales para poder lograr el mejor performance.

Identificar parámetros de BIOS requeridos para un óptimo funcionamiento de nuestros servidores ESX/ESXi:

Existen muchos parámetros de BIOS recomendados para VMware ESX, muchos son basados en modelos específicos de servidores. Aquí les dejo los más comunes y lo que debemos siempre verificar:

  • Siempre estar al día en cuanto a la versión de BIOS de nuestros servidores ESX/ESXi.
  • Verificar que todos los sockets con procesadores esten habilitados.
  • Habilitar Hyperthreading (Intel).
  • Habilitar “Turbo Boost” , esto en procesadores Intel.
  • En el caso de AMD deshabilitar “node intervealing” debido a que esto nos deshabilita NUMA (non uniform memory access)
  • habilitar cualquier tecnología de virtualización asistida por hardware VT-x , AMD-V , EPT ,RVI.
  • Deshabilitar cualquier tecnología para el ahorro de energía Enhanced Intel SpeedStep o Enhanced AMD PowerNow! en el caso de buscar performance, si se quiere utilizar DVFS (Dynamic Voltage and Frequency Scaling) necesitamos dejarlas habilitadas.
  • Deshabilitar dispositivos que no vayamos a utilizar, USBs, puertos seriales, etc.
  • En el caso de ciertos servidores IBM (lo experimente en una implementación utilizando 3850 M2) con cluster mode, verificar que este configurado a modo “physical” esto debido a que en modo “logical” nos muestra el doble de scokets y por lo tanto esto nos genera un mayor uso de licencias.
  • Habilitar “no execute memory protection”  (XD o NX) esto para un correcto funcionamiento de  EVC (enchanced VMotion compatibility).

Identificar versiones de drivers para  nuestros ESX/ESXi

Aquí mas que nada seria verificar que versión de driver es recomendada para el dispositivo que se esté utilizando, esto lo podemos verificar en el HCL de VMware:

Aquí les dejo un ejemplo de una tarjeta 10Gbe de Intel:

Verificar compatibilidad de dispositivos

Siempre es necesario verificar la compatibilidad de los dispositivos que estaremos utilizando, esto lo vemos en el HCL (Hardware Compatibility List) de VMware:

http://www.vmware.com/go/hcl

Tunning de memoria tanto para host ESX como VMs

Aquí les dejo algunos tips:

  • Se debe de dar una cantidad de memoria solo un poco mayor al consumo de dicho host debido a que entre mas memoria mas overhead para virtualizar dicha memoria.
  • En el caso de vms linux 32 bits  tratar de no sobre pasar el limite de 896 mb debido al como linux accede a la memoria virtual (hasta 1 GB).
  • Tratar de definir prioridades con shares para nuestras vms, debido a que en momentos de overcommitment la asignación de memoria se basara en estos shares para asignar recursos de memoria.
  • Siempre instalar VMware tools, debido a que ellas nos proporcionan la capacidad de utilizar el balloon driver dentro de la vm.
  • Las reservaciones de memoria deben de ser utilizadas con cierta planeación y para vms que sea totalmente necesario el mantener cierta cantidad de memoria ram, debido a que la memoria reservada no puede ser reclamada en momentos de over commitment.
  • En el caso de maquinas virtuales con aplicaciones java para tener un correcto funcionamiento debemos seguir los siguientes pasos:
  1. Crear una reservación de memoria del mismo tamaño a la memoria asignada
  2. La asignación de memoria debe de ser basada en el tamaño de máximo del heap size de dicha aplicación Java.
  3. En caso que el os y nuestra app soporten paginas de memoria mas grandes (large pages) habilitarlas.
  • Si se piensa tener un over commitment alto de memoria es preciso monitorear el estado de nuestro swap.
  • Es una buena práctica el tener vms con el mismo sistema operativo, con esto TPS (transparent page sharing) puede actuar mucho mejor compartiendo las páginas de memoria idénticas entre dichas vms.

Tunning de redes para nuestros hosts ESX y vms

Aquí les dejo unos tips, mas que nada son mejores prácticas:

  • siempre utilizar full duplex en nuestros links no auto negociación.
  • Dedicar interfaces para cada tipo de trafico SC/VMotion/FT/ip-storage/trafico de vms
  • En todos los casos tratar de utilizar vlans, con esto permitimos una correcta segmentación de nuestro tráfico.
  • Tratar de utilizar Link state tracking de cisco, beacon probing puede derivar en un altas cantidades de broadcasting.
  • habilitar trunkfast en switches cisco para la que los puertos cambien de estado velozmente.

Les dejo un excelente whitepaper de cisco para que lo lean:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/vmware/VMwaredg.pdf

Tunning de CPU para nuestros hosts ESX/ESXi y nuestras vms

  • nunca asignar múltiples vCPUs a menos que estemos seguros que nuestra aplicación se beneficia de multiprocesadores, vamos a ver porque:
  1. cuando tenemos vCPUs en stand by estos consumen “timer interrupts” básicamente estas interrupciones son utilizadas para medir el tiempo en las vms.
  2. muchos sistemas operativos mantienen un proceso idle consumiendo recursos innecesarios en nuestro host ESX/ESX.
  3. posible transición de las instrucciones de una aplicación no compatible con multiples cpus entre los distintos vCPUs, con esto perdemos el cache de cada uno de los cpus por lo tanto performance.
  • asegurarnos de siempre tener el HAL (Hardware Abstraction Layer) ya sea uni procesador o multi procesador ej. vm Windows con multi procesador:

Tunning de Storage para nuestros hosts ESX/ESXi y nuestras vms

les recomiendo leer mi post previo

VCAP- Sección 1 – Storage Best Practices

Aquí me gustaría agregar un punto de como modificar el queue depth de nuestras hbas. El queue depth determina la cantidad de operaciones concurrentes que dicha hba podrá estar procesando, en el caso de VMware el valor default de este queue depth es de 32,  muchas veces este valor lo modifican en el  momento de la implementación. Honestamente a mí me gusta verificar primero cual es el queue depth del almacenamiento, debido a que en el momento que nosotros aumentamos este queue depth a 64 podemos sobrepasar el valor de nuestro almacenamiento  y con esto tendríamos problemas. Muchos almacenamientos tienen un queue depth de 2048 con esto podemos ver que con 32 hosts podemos fácilmente llegar a ese limite.

¿Cómo puedo saber si estoy teniendo problemas con mi actual queue depth?

Ejecutamos esxtop en alguno de nuestros hosts ESX/ESXi que tengan visibilidad con de la lun que este presentando problemas, una vez dentro de esxtop, tecleamos la letra “u”, con esto se cambiara la vista a disk device que básicamente son las luns y discos locales que tenemos en dicho host. Observamos el valor de QUED, si este valor es distinto a0 estamos teniendo operaciones encoladas por lo que debemos verificar el queue depth de nuestra hba:

¿Cómo modifico el queue depth de mi hba?

Paso 1-. Verificamos el modulo que está en uso

Para Qlogic:

vmkload_mod -l |grep qla

Para Emulex:

vmkload_mod -l |grep lpfc

Paso 2-. Realizamos la modificación basada en el modulo detectado, en este ejemplo estaremos viendo el modulo qla2xxx de Qlogic  y lpfc820 de Emulex:

Qlogic:

esxcfg-module -s ql2xmaxqdepth=64 qla2xxx  #esto modificara el queue depth a su valor máximo que es de 64.

Emulex:

esxcfg-module -s  lpfc0_lun_queue_depth=64 lpfc820 #esto modificara el queue depth a su valor máximo que es de 64.

Paso 3-. Reiniciamos nuestro host y verificamos el cambio:

esxcfg-module -g <driver>

Paso 4-. Modificamos el valor de “Disk.SchedNumReqOutstanding” al valor que le dimos a nuestra HBA, este valor es la cantidad de operaciones que será capaz de mandar el vmkernel (el total de operaciones para todos las vms que residan en dicho host), por lo tanto si tenemos un valor menor al que le dimos a nuestra HBA existiría un cuello de botella

desde el vsphere client vamos a configuration>advanced settings>disk>Disk.SchedNumReqOutstanding y le damos el valor requerido:

Esto también lo podemos realizar desde la línea de comando:

esxcfg-advcfg -s 64 /Disk/SchedNumReqOutstanding

Paso 5 (opcional pero recomendado)-. En la guía de config de ESX/ESXi se nos recomienda modificar el valor de Disk.UseDeviceReset y verificar que el valor de Disk.UseLunReset sea de 1, esto realizara los resets (se liberan todas las reservaciones scsi) a nivel de la lun no del almacenamiento para no afectar el almacenamiento completo:

Desde el vsphere client vamos a configuration>advanced settings>disk>Disk.UseDeviceReset y modificamos el valor a 0

Esto también lo podemos realizar desde la línea de comando:

esxcfg-advcfg -s 0 /Disk/UseDeviceReset

Configurar y aplicar atributos avanzados para nuestros host ESX/ESXi

Tenemos dos maneras para realizar modificaciones a parámetros avanzados en nuestros hosts desde la línea de comando utilizando esxcfg-advcfg (vicfg-advcfg  en el caso de vcli) o  desde el vsphere client vamos a configuration>advanced settings.

Aquí debemos de conocer bien lo que estamos haciendo porque podemos dañar nuestro sistema.

Configurar y aplicar atributos avanzados para nuestras VMs

Existen bastantes atributos avanzados que podemos modificar en nuestras vms, para realizarlo tenemos 2 opciones, editamos el archivo vmx directamente o ingresamos con el vsphere client , seleccionamos la vm>click derecho>edit settings>options>general>Configuration Parameters:

Al igual que la modificación de parámetros avanzados para nuestros hosts les recomiendo saber que es lo que están haciendo antes de realizarlo o probarlo en una vm de testing. Aquí les dejo una página excelente donde se documentan muchos de los parámetros que podemos modificar en el vmx:

http://www.sanbarrow.com/vmx.html


Tuning y modificación de NUMA

NUMA (non uniform memory access) un tipo de arquitectura en cuanto a la comunicación entre procesadores y memoria se refiere, a diferencia de arquitecturas anteriores cada procesador o grupo de procesadores  tienes  su propia memoria ram, a este grupo de memoria y procesadores se le llama “nodo numa”:


Cada nodo numa tiene un bus a través de cual se lleva a cabo la comunicación entre cpu y memoria a esto se le llama memoria local, pero también se puede acceder memoria de otros nodos que se le conoce como “foreign” o memoria remota claro que bajo un costo en cuanto al performance.

El algoritmo de numa en VMware se encarga de balancear las vms entre los nodos dependiendo de la carga que tiene el sistema, el nodo al que se asigna se le llama “home node” y este mismo algoritmo trata de asignar memoria en su mismo nodo numa para que esta memoria sea local.

Recomendaciones:

  • No asignar un número mayor de vCPUs de los que tiene el host ESX/ESXi a una vm, debido a que estas maquinas no pueden ser manejadas por el algoritmo de numa para migrarlas entre los nodos según las cargas.
  • No utilizar cpu affinity debido que afecta el correcto balanceo de numa.

Optimizaciones manuales:

  • Asociar una vm a un nodo numa utilizando cpu affinity
  1. ingresamos con el vsphere client y seleccionamos una vm, hacemos click derecho y click sobre “edit settings”.
  2. vamos a resources>Advanced Cpu e ingresamos el procesador o los procesadores donde queremos que se ejecute esta vm.
  • Asociar que memoria será asignada según el nodo numa (requiere haber definido afinidades en cpu)
  1. ingresamos con el vsphere client y seleccionamos una vm, hacemos click derecho y click sobre “edit settings”
  2. vamos a resources>memory y definimos la afinidad de memoria.

Opciones avanzadas de Numa:

  • VMkernel.Boot.sharePerNode —> este valor avanzado define si se podrá realizar de duplicación de paginas idénticas (Transparent page sharing) entre distintos nodos NUMA, por default viene deshabilitada. Generalmente esta opción no la modificamos debido a que overhead (aunque sea muy pequeño) que se presenta entre compartir memoria entre nodos numa.

existe una gran variedad de opciones avanzadas de numa (23) pero lo más recomendable es no modificar estas a menos que sea requerido por soporte VMware.

VCAP – Sección 1 – LUN masking utilizando comandos de PSA

Que tal gente, continuando con los temas para la preparación de VCAP nos toca hablar de cómo hacer un mask o prevenir que ciertos hosts ESX/ESXi puedan tener visibilidad de algún LUN en especifico, esto basándonos sobre el nuevo plugin de PSA MASK_PATH de PSA.

En el diseño de nuestra arquitectura siempre es importante tomar en cuenta la cantidad de Hosts que estarán accediendo concurrentemente a un LUN, debido a que a mayor cantidad de hosts , mayor cantidad de operaciones SCSI. Si nosotros tenemos un granja de servidores ESX/ESXi 15+  servidores es un punto que tenemos que tener muy presente, aquí es donde entra el objetivo de enmascarar ciertas LUNs para ciertos hosts.

Generalmente este enmascaramiento lo hacemos del lado de la SAN y lo conocemos como zoning, pero también tenemos la capacidad de hacer este enmascaramiento directamente en los hosts ESX/ESXi, tengamos en cuenta que lo recomendado y lo más sano en términos de administración es hacerlo del lado de nuestro almacenamiento.

¿Cómo enmascaro algun LUN en mis hosts ESX/ESXi?

Paso 1-. Ingresamos a nuestro servidor ESX/ESXi con el vSphere Client, una vez dentro, navegamos a configuration>Storage Adapters

Paso 2-. Seleccionamos el adaptador a través del cual se esté llegando a dicho almacenamiento (HBA de FC , SW iscsi o HBA de ISCSI). Una vez seleccionado, en  los detalles de dicho adaptador encontraremos 2 tipos de vista Devices/Paths , damos click en Paths, aquí se nos mostrará cuales son los paths a través de los cuales se llega a dicho almacenamiento:

Paso 3-. Una vez que ya tenemos enlistados los paths, es cuestión de crear reglas para enmascarar cada uno de ellos, comenzamos por enlistar las reglas existentes para poder saber con que numero de regla podemos comenzar:

esxcli corestorage claimrule list

Paso 4-. Creamos las reglas necesarias (numero de paths) para enmascarar dicho LUN:

esxcli corestorage claimrule add -P MASK_PATH -r 120 -t location -A vmhba33 -C 3 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 121 -t location -A vmhba33 -C 2 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 122 -t location -A vmhba33 -C 1 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 123 -t location -A vmhba33 -C 0 -T 0 -L 0

-C Canal o channel

-T destino o Target

-L LUN

-A adaptador

Recuerden que estos son los elementos del runtime name

Paso 5-. Cargamos las reglas que recién creamos y verificamos que efectivamente ya se muestran en la lista de reglas:

esxcli corestorage claimrule load

esxcli corestorage claimrule list

Paso 6-. Si se trata de un LUN que ya se presentaba en nuestro host ESX/ESXi, necesitamos quitar la regla actual:

esxcli corestorage claiming unclaim -t location -A vmhba33

Paso 7-. Ejecutamos nuestras reglas:

esxcli corestorage claimrule run

Una vez realizados estos pasos ya hemos enmascarado dicho LUN a nuestro host, si ingresamos con nuestro vSphere client y navegamos a configuration>Storage Adapters se nos muestran los paths como “dead”:


Paso-a-paso – Actualización de servidores ESX

Que tal Gente, el día de hoy les voy a hablar de cómo actualizar nuestros hosts ESX/ESXi de la versión 4.0 a la versión 4.1, ya que últimamente he visto mucho esta duda.

Antes que nada les comento que las opciones para actualizar nuestros servidores que veremos a continuación pueden ser utilizadas no solo para una actualización de la versión 4 a la 4.1 sino tambien para actualizaciones previas. Comencemos por conocer que opciones tenemos para actualizar los servidores:

Opción 1 - vihostupdate, esta “utilidad”, o más bien script que forma parte del vSphere CLI , nos permite hacer  actualizaciones tanto para nuestros servidores ESX como ESXi. Es a través de la línea de comando de la misma suite de vSphere CLI.

Requerimientos:  tener instalado vSphere CLI      http://downloads.vmware.com/d/details/vcli41/ZHcqYmRoaCpiZHdlZQ==

Paso 1 -. Una vez instalado vSphere CLI, vamos a menú inicio > VMware y ejecutamos vSphere CLI, se nos abrirá una ventana idéntica a la línea de comando de Windows o “cmd”, nos movemos al directorio “bin”  con el siguiente comando:

cd bin

Paso 2 -. Ya dentro de la carpeta bin, ejecutamos vihostupdate.pl,  y le agregamos los parámetros de servidor al que nos vamos conectar, -i (instaló), -b (bunde) y ruta del archivo .Zip de actualización, deberá quedar algo como esto:

“ vihostupdate.pl  — server (ip o fqdn) –i –b C:\ruta\a\archivodeactualización”

Nos pedirá las credenciales de nuestro servidor y listo.

Nota : en ciertas ocasiones se requerirá de un paquete de “pre-upgrade” que se tendrá que instalar antes del paquete de actualización, el proceso es exactamente igual, solo cambiamos la ruta hacia el paquete de pre-upgrade.

Aquí les dejo un video de cómo realizarlo:

Opción 2 – esxupdate, esta utilidad, forma parte de los comandos encontrados en la service console de nuestros servidores ESX, aquí tenemos que tener en cuenta que esto está pensado para servidores ESX, no ESXi, si quisiéramos hacer un update de un ESXi standalone lo más conveniente sería hacer esta actualización a través de vihostupdate.

En esta opción tenemos que tener acceso directo al service console de nuestro servidor ESX o a través de ssh.

Paso 1 -. Subimos el o los paquetes (en caso de existir un pre-upgrade package) de actualización a una carpeta de nuestro servidor ESX, en este caso yo les recomendaría subirla a la carpeta /tmp, para ello requerimos una utilidad de SFTP o SCP (en este caso utilice Winscp , para ver su funcionamiento den click en el video)

Paso 2 -. Ponemos el host en modo mantenimiento, esto lo podemos hacer directamente desde el vi client o si ya estamos en la consola de servicio con el siguiente comando :

“vimsh -n -e /hostsvc/maintenance_mode_enter”

Y confirmamos que efectivamente esta en modo mantenimiento con el siguiente comando :

vimsh -n -e /hostsvc/runtimeinfo | grep inMaintenanceMode | awk ‘{print $3}’

Paso 3 -. Una vez con el o los paquetes de actualización dentro de nuestro servidor ESX y el mismo en modo mantenimiento, nos vamos a la línea de comando, nuevamente, esto puede ser a través de ssh o directamente en la consola, e ingresamos el siguiente comando:

“esxupdate – bundle = <paquetedeactualización.zip> update”

Recordemos que si se tiene para esta versión un paquete de pre-upgrade lo tendremos que instalar antes del paquete de actualización principal. Una vez realizadas las actualizaciones tendremos que reiniciar el servidor ESX y sacarlo del modo de mantenimiento, para esto nuevamente tenemos la opción de hacerlo directamente desde el vi client, o en la línea de comando con el siguiente comando:

“vimsh -n -e /hostsvc/maintenance_mode_exit”

Aquí les dejo un video del cómo realizar este proceso:

Opción 3 – VMware Update Manager (VUM) , para mi esta es la mejor opción dado que podemos realizar esta tarea para varios hosts ESX dentro de nuestro cluster, y no ir de uno por uno actualizando, recordemos que tenemos que tener instalado VUM en nuestro vCenter.

Paso 1 -. Nos logeamos a nuestro servidor vCenter con nuestro vi client, una vez dentro, navegamos a “Solutions and Applications” > Update Manager. Una vez dentro del update manager, veremos varias pestañas en la parte superior, damos click en la pestaña de “Host Upgrade Releases”.

Paso 2 -. Una vez dentro de la pestaña de Host Upgrade Releases , damos click en “import upgrade release” tendremos que seguir un wizard donde se nos pedirá la locación de nuestro .zip de actualización.

Paso 3 -. Dentro de la misma pestaña de “Host Upgrade Releases”  ya veremos enlistado nuestro paquete de actualización , en la parte inferior damos click en “Create Baseline” , donde nuevamente tendremos que seguir un wizard , donde daremos el nombre de nuestro baseline, el tipo de baseline, en este caso Host Upgrade, y dejamos las opciones por default. Solo como dato en esas opciones tenemos la capacidad de dictar donde estará el service console en caso que estemos actualizando un servidor ESX 3, correr un script después de la actualización  y también tenemos una opción que está habilitada por default que si la actualización falla el servidor o servidores ESX, se reiniciaran y harán un roll back del upgrade realizado.

Paso 4-.
Una vez creado nuestro baseline, hacemos un attach del mismo a nuestros servidores que se actualizaran y corremos un scan de estos o este servidor ESX el cual nos mostrara que se encuentra en un estado “no compliant”, damos click en remidiate y lo demás se lo dejamos a VUM.

Aquí les dejo un video que les dejara claro los pasos para poder actualizar por medio de VMware Update Manager: