Hola amigos, soy Florián Murillo y hoy hablaremos de como podemos automatizar, desde PowerCLI, la creación de un vSwitch, un port-group y un puerto de kernel en un host.

01. $server = “myHost”
02. $vsw = “vSwitch101″
03. $pg = “Production”
04. $vmkIP = “10.10.1.122”
05. $vmkMask = “255.255.255.0”

06. $o_server = Get-VMHost -Name $server
07. $o_vnw = Get-VMHostNetwork -VMHost $server

08. $pnic = $o_vnw.PhysicalNic[1].DeviceName
09. $o_vsw = New-VirtualSwitch -VMHost $o_server -Name $vsw -Nic $pnic
10. New-VirtualPortgroup -VirtualSwitch $o_vsw -Name $pg
11. New-VMHostNetworkAdapter -VMHost $o_server -PortGroup “vMotion Network” -VirtualSwitch $vsw -IP $vmkIP -SubnetMask $vmkMask -VMotionEnabled:$true

Descripción de cada línea

Antes de describir las líneas anteriores, solo explicar la regla utilizada para asignar nombres a las variables y objetos, los objetos empiezan por “o_” a diferencia de las variables que almacenan valores básicos como una cadena de caracteres.

01 al 05. Asignamos valores a variables, $server es el nombre del host sobre el que vamos a trabajar, $vsw es el nombre del vSwitch que vamos a crear, $pg es el nombre del port-group que crearemos en el vSwitch, $vmkIP es la IP del puerto de kernel que vamos a crear en el vSwitch y $vmkMask es la máscara IP del puerto de kernel.

06 y 07. Creamos objectos, $o_server es el objeto VMHost que representa al host almacenado en $server, y $o_vnw es el objeto VMHostNetwork que almacena la información de red del host $server.

con la instrucción :

> $o_server | Get-Member | Format-List

podemos ver los métodos y propiedades de la clase VMHostNetwork, de la cual hereda $o_server.

08. Una de las propiedades de un objeto del tipo VMHostNetwork es una tabla de objetos llamada PhysicalNic, la cual tiene tantas entradas como interfaces vmnic el host. El objeto PhysicalNic[1] describe el interfaz vmnic1, y su propiedad PhysicalNic[1].DeviceName nos informa del nombre del interfaz. En esta línea asignamos ese valor a la variable $pnic, este será el interfaz a añadir al vSwitch. Hemos visto en esta línea como recuperar la información de una propiedad de un objeto, con la sintaxis “objeto.propiedad”.

09. Creamos el vSwitch llamado $vsw en el host $o_server entregándole la interfaz $pnic. Creamos un objeto $o_vsw que contiene toda la información del switch recién creado. En el vCenter Server veremos lo siguiente:

10. Creamos un port-group llamado $pg en el vSwitch $o_vsw. En el vCenter Server veremos lo siguiente:

Creamos un puerto vmkernel en el host $o_server, el puerto estará en el port-group “vMotion network”, en el vSwitch $vsw y le entregaremos la IP $vmkIP y la máscara $vmkMask. La función a realizar por este puerto de kernel se la especificamos con el flag -VMotionEnabled:$true

Observar que en este comando hemos entrado directamente el valor del port-group sin utilizar una variable, es otra posibilidad.

Habréis observado que a veces entramos objetos como parámetros y en ocasiones variables, eso depende de la definición del comando.

Hasta ahora PowerCLI ha sido una herramienta eficaz para automatizar procesos de explotación, pero ahora además, es necesario su conocimiento para el examen VCAP. Hasta la semana próxima.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.

Esta semana me gustaría retomar el scripting con PowerCLI para trabajar en esta ocasión con los contadores de rendimiento de nuestra plataforma vSphere.

Para obtener la información de nuestra plataforma contaremos con dos cmdlets principales, complementarios entre sí, encargados de darnos la información que requeríamos de nuestro entorno. Básicamente se tratan de:

• Get-Stat, que es el que realmente nos devuelve la información acerca de los contadores de rendimiento que requiramos.
• Get-StatType, que nos informa de los contadores disponibles para el objeto que queramos interrogar, ya sea una máquina virtual, un host ESX(i) o un vCenter.

Si os parece bien, en lugar de ponerme a enumerar los parámetros de cada uno de los cmdlets Get-Stat y Get-StatType, vemos cómo usarlos mediante un par de ejemplos.

En su ejecución más simple, sin parámetro ninguno, este cmdlet nos devolverá el promedio de los contadores de rendimiento normales en el intervalo de muestreo, que por defecto se establece en 20 segundos, para host o vCenter al que estemos conectados. Por ejemplo:

PowerCLI> Get-Stat
MetricId Timestamp Value Unit Instance
——– ——— —– —- ——–
mem.usage.average 11/05/2011 15:27:00 90,42 %
mem.usage.average 11/05/2011 15:26:40 90,43 %
mem.usage.average 11/05/2011 15:26:20 90,43 %
…
net.usage.average 11/05/2011 15:27:00 0 KBps
net.usage.average 11/05/2011 15:26:40 0 KBps
net.usage.average 11/05/2011 15:26:20 0 KBps
…
disk.usage.average 11/05/2011 15:27:00 129 KBps
disk.usage.average 11/05/2011 15:26:40 98 KBps
disk.usage.average 11/05/2011 15:26:20 125 KBps
…

Si sólo estamos interesados en alguno de los grupos genéricos usaremos los modificadores Memory, CPU, Disk o Network según el que nos interese.

Sin embargo, como todos sabemos, los contadores de rendimiento en vmware no se limitan solo al Host o al vCenter, sino que se extienden a máquinas virtuales, resource pools, etc… Para acceder a esta información sólo tendremos que usar el parámetro Entity al que le pasaremos un array con los objetos sobre los que queramos información.

Por ejemplo, como ya vimos en otro post anterior, el cmdlet Get-VM nos devuelve todas las máquinas virtuales registradas en un host, cluster o vCenter. Si queremos obtener los contadores de rendimiento comunes de todas nuestras máquinas virtuales encendidas, sólo tendremos que ejecutar el siguiente comando:

PowerCLI>Get-Stat (Get-VM | Where-Object { $_.PowerState –eq ‘PoweredOn’ } | Export-CSV –delimiter “;” perfVM.csv

Donde Where-Object { $_.PowerState –eq ‘PoweredOn’ } es el filtro que nos permite discriminar por el estado de la máquina virtual y Export-CSV –delimiter “;” perfVM.csv exporta el resultado a un fichero CSV para que sea más sencillo realizar el tratamiento de los datos. Si estáis interesados en los datos de una VM en particular sólo tenéis que cambiar el filtro y la pipe anterior (el símbolo |) por el nombre de la máquina virtual.

No me gustaría terminar sin comentaros el modificador para mí más importante Stat. Este modificador admite como parámetro una array de tipo cadena con un listado de los contadores de rendimiento en los que estamos interesados. Es precisamente en este punto donde entra en juego el otro cmdlet que os mencionaba al principio, Get-StatType, que es el encargado de mostrarnos los contadores que tenemos disponibles para un tipo de objeto en particular. Tened presente que la lista de contadores disponibles dependerá de los elementos de los que dispongáis en vuestra plataforma.

Una vez consultado los contadores que nos interesen mediante Get-StatType, podemos interrogar a nuestra plataforma por los valores que nos interesen.

En el siguiente ejemplo comprobaremos la latencia y el throughput en el adaptador de almacenamiento vmhba2.

PowerCLI> Get-Stat -Stat @(“storageAdapter.totalReadLatency.average”, “storageAdapter.totalWriteLatency.average”, “storageAdapter.read.average”, “storageAdapter.write.average”) | Where-Object { $_.Instance -eq ‘vmhba2′ } |Out-GridView

Donde @(“storageAdapter.totalReadLatency.average”, “storageAdapter.totalWriteLatency.average”, “storageAdapter.read.average”, “storageAdapter.write.average”) es el array con los contadores que nos interesan y Where-Object { $_.Instance -eq ‘vmhba2′ } de nuevo es un filtro que en esta ocasión nos permite fijarnos sólo en el adaptador vmhba2.

Esta vez en lugar de exportar los datos a un fichero CSV he preferido sacar los resultados a una ventana externa donde además podremos filtrar mucho más los resultados.

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.

En un video post publicado en enero de este año, te explique cómo cambiar la memoria del Service Console en VMware ESX y porque a veces es necesario.

Es posible incrementar la cantidad de memoria física de tu servidor físico destinada al Service Console en VMware ESX – aunque este cambio requiere en reboot de tu servidor ESX.

Una mejor práctica para la partición swap de tu servidor VMware ESX es dedicar, al menos, el doble de memoria física del tamaño de la memoria destinada al Servico Console.

El problema, que se menciona en el video post, es que al cambiar la memoria del Servico Console, no se cambia automáticamente el tamaño de la partición swap. En otras palabras, en una instalación de VMware ESX por defecto, la memoria del Service Console suele ser de unos 300Mb – este valor sera mayor dependiendo de la memoria física total del servidor físico. Por consiguiente, el tamaño de la partición swap del Service conosle será de 600Mb.

Ahora bien, ¿Qué pasa si cambiamos la memoria del Service Console como explique en el video anterior? Pues sencillamente, que la partición swap no crece y hay que hacerlo manualmente.

A continuación, te resumo los tres pasos más importantes que hay que hacer para aumentar la partición swap del Service Console cuando se cambia el valor por defecto de la memoria del Service Conosle.

1. Crea un nuevo fichero de swap para la partición swap con el siguiente comando:

dd if=/dev/zero of=/path/al/fichero.swap bs=1024 count=1572864

2. Usa el siguiente comando para cambiar el formato del fichero anterior a fichero tipo swap:

mkswap /path/al/fichero.swap

3. Habilita el fichero swap con el siguiente comando:

Swapon /path/al/fichero.swap

Estoy seguro que te estarás preguntado: ¿Y qué pasa con VMware ESXi? ¿Cómo se incrementa la partición swap del Service Console? La buena noticia es que no te tienes que preocuparte de ello pues como bien sabes, VMware ESXi no tiene Server Console!.

¿Y tú, qué opinas? ¿Conoces alguna mejor manera de aumentar el tamaño de la partición swap del Service Console? ¿Cuáles son tus experiencias personales con la partición swap y el Servce Console? Deja tu comentario abajo o charlemos sobre ello en twitter.

Como cada miércoles estoy aquí con vosotros para ver temas nuevos del ecosistema de VMware. Soy Jose Mª Gris y hoy no hablaremos de cosas extrañas ni cosas que nos han desaparecido.

Hoy hablaremos sobre la activación del EVC Mode, funcionalidad que nos permite crear una “baseline” para que nuestros procesadores, aunque no sean iguales entre ellos, puedan ejecutar vMotion. Eso si, tendremos EVC para AMD y EVC para Intel. Las churras con las churras y las merinas con las merinas. Ya sabéis aquello de “las que entran por las que salen … “

Bien, ya hemos decidido activar nuestro EVC en el cluster de producción, lo activamos, seleccionamos la baseline y entonces nos damos cuenta que para poder activar la funcionalidad, el cluster tiene que estar parado. Y claro, no sería tan fácil, porque cuando decimos que vamos a parar “un momentito” pues “va a ser que no”, porque “show must go on….”.

Vale. Pues vamos a montarnos nosotros solos la fiesta. En estos casos lo que hago es definir un segundo cluster, pasar toda la producción del ESX2 al ESX1, parando todo lo no crítico. Cuando tengo ESX2 libre lo pongo en maintenance mode y lo paso de Cluster.

Posteriormente voy haciendo vMotion de las VM en producción entre ESX1 y ESX2, dando continuidad al servicio. Una vez tengo el primer cluster y ESX1 libre de carga, lo paro y activo EVC. Si señor! De parrafada y sin equivocarme!

Posteriormente no tengo más que devolver las VM de producción a ESX1 y devolver en su momento ESX2 a su cluster de procedencia. Podemos borrar el cluster temporal que hemos montado y todo vuelve a su lugar, pero con el EVC en marcha para que podamos entrar un nuevo ESX con un procesador “algo” distinto.

Take care.

Queridos lectores,

En el post de hoy explicaré como desactivar Task Offload. En ocasiones desactivandolo notaremos un incremento de rendimiento en la red.

Lo haremos tanto en las interfaces virtuales (VIF) como en las físicas (PIF).

1º .- Desactivamos Task Offload en una VM Windows 2003 :

- Vamos al registro HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameter
– Creamos la siguiente Key DisableTaskOffload

2.- Desactivamos CheckSum Offload en XenServer

- Sobre la interfaz virtual:

xe vif-param-set uuid=”uuid” other-config:ethtool-tx=”off”
xe vif-param-set uuid=”uuid” other-config:ethtool-rx=”off”

-Sobre la interfaz física:

xe pif-param-set uuid=”uuid” other-config:ethtool-tx=”off”
xe pif-param-set uuid=”uuid” other-config:ethtool-rx=”off”

Y con estos sencillos pasos lo tendremos desactivado. Recomiendo encarecidamente hacer pruebas para ver si realmente se mejora el rendimiento.

Y como siempre espero que sea de utilidad.

Queridos lectores,

Hace unos días Citrix publicaba el nuevo parche para su descarga.

Por lo visto desaparecía el CDROM adjuntado después de una migración de una máquina virtual windows y que además podía dar lugar a perdidas de rendimiento producidas por exceso de CPU.

Aquí os dejo el enlace para su descarga directa:

http://support.citrix.com/servlet/KbServlet/download/26483-102-650199/XS56EFP1005.zip

A continuación paso a recordaros como podéis realizar su instalación desde CLI.

1.- Descarga del hotfix de la url que os pongo anteriormente.

wget http://support.citrix.com/servlet/KbServlet/download/26483-102-650199/XS56EFP1005.zip

2.- Subimos el parche sobre XenServer

xe patch-upload file-name=”nombre del parche”

3.- El comando anterior imprime por pantalla el siguiente UUID:

6548ea15-2d71-4230-afaf-bf4f4936a893

4.- Aplicamos el parche sobre XenServer

xe -patch-pool-apply uuid=6548ea15-2d71-4230-afaf-bf4f4936a893

5.- Verificar

xe patch-list

El parche se aplicará sobre todos los host del pool, pero no tendrá efecto hasta que no se reinicie.

Como veis con unos sencillos pasos tendremos la última versión de XenServer actualizada. Espero, como siempre, que os sea de gran utilidad.

Hola de nuevo, soy Miguel Ángel Alonso y aquí estoy como cada martes para contaros algo nuevo sobre el maravilloso mundo de la virtualización.

Hoy nos centraremos en como instalar un certificado en nuestro entorno VMware View para poder utilizarlo en nuestras conexiones WAN, y así de esta manera poder cifrar nuestros datos de conexión.

Lo primero de todo, tendrás que ir a las propiedades del equipo de tu servidor Broker en “Configuración avanzada del Sistema” – “Opciones Avanzadas” – “Variables del entorno”, para seleccionar el campo llamado “Path” y añadir el siguiente path:

C:\Program Files\VMware\VMware View\server\jre\bin

El segundo paso a seguir en tu servidor Broker o connection server, es abrir una sesión desde la línea de comandos con “cmd” y asegurarte que estas en el irectorio raíz “C:”. Después, escribe la siguiente línea de comandos:

Keytool –genkey –keyalg “RSA” –keystore keys.p12 –storetype pkcs12 –validity 360

Esta linea de comando, generará una clave privada llamada keys.p12 en algoritmo RSA usando el formato PKCS12 y válida por un año: Tendrás que rellenar los datos de formulario que te pide, como por ejemplo, nombre FQDN de tu organización, Ciudad, País y etcétera.

En el siguiente paso, crearas un archivo de requerimiento de certificado, el famoso CSR, para ser enviado a la CA correspondiente, tanto sea de tu entorno Microsoft si es que dispones de ella como si es un CA correspondiente a una de las autorizadas en Internet y conocidas, como por ejemplo, THAWTE, GLOBALSIGN o VERISIGN.

El comando para generar el archivo CSR es el siguiente:

Keytool –certreq –keyalg “RSA” –file micertificado.csr -keystore keys.p12 -storetype pkcs12 -storepass p@sswOrd

Donde micertificado.csr será el nombre de tu ”csr” y p@sswOrd, será la contraseña que utilices para tu certificado.

Una vez hecho todo esto, nos generará el archivo .csr el cual como he indicado antes deberás enviar a la entidad de certificados CA que hayamos elegido.

En mi caso será una CA interna de Microsoft Windows 2008 y la cual dispongo dentro de mi entorno de laboratorio. Nos conectamos mediante http://servidorCA/certsrv

Entonces, eliges la opción de enviar una solicitud de certificado con un archivo codificado en base64 CMC o PKCS#10, o una solicitud de renovación con un archivo codificado en base64 PKCS#7, donde en “plantilla de certificado” pondrás “Servidor Web” y “pegaras” el archivo csr que he generado anteriormente en formato texto.

Luego, descarga los archivos por defecto Certnew.crt y Certnew.p7b (obligatorio en formato pkcs#7) a tu direcrorio raíz C:

Vuelve a la línea de comando para importar tu root CA y teclea el siguiente comando:

Keytool –import –trustcacerts -keystore “C:\Program Files\VMware\VMware View\jre\lib\security\cacerts” -storepass changeit –alias Root -import -file c:\Certnew.crt

Después, importa tu archivo Certnew.p7b (formato pkcs#7) mediante la siguiente línea de comando:

Keytool -import -keystore keys.p12 -storetype pkcs12 -storepass p@asswOrd -keyalg “RSA” -trustcacerts -file Certnew.p7b

Te preguntará si confías en este certificado: por supuesto le dices que sí.

Como últimos pasos, lo que harás será ir a tu Security Server y en el directorio: C:\Program Files\VMware\ViewManager\Server\sslgateway\conf modificas, o creas sino dispones de este, un archivo llamado Locked.properties. Ánade las dos lineas siguieres:

Keyfile=keys.p12
Keypass=p@sswOrd

Seguidamente, y en ese mismo directorio, importa la clave keys.p12 que generaste en tu servidor Broker anteriormente, y reinicia el sevicio View Security Service con los siguientes comandos:

Net stop VMware View Security Server
Net start VMware View Security Server

Como nota final, recuerda que el archivo locked.properties y la importación de la clave privada keys.p12 deberías hacerlo en todos tus Security Server.

Bueno, hasta aquí por hoy. Espero haberos contado algo de vuestro agrado y me despido de vosotros hasta la semana que viene. Os emplazo hasta el próximo martes con un nuevo tema sobre la virtualización.

Hola de nuevo. Soy Miguel Ángel Alonso, y aquí estoy como cada martes para hablar un poquito más del maravilloso mundo de la virtualización.

Hoy vamos a hablar de una característica maravillosa pero muy poco conocida de VMware vSphere, llamada: DVFS (de las siglas en Ingles Dynamic Voltage and Frequency Scaling).

Para tener una vista clara de esta característica, la vamos dividir en 3 secciones muy claras.

1. Para qué sirve y como activarla
2. Requerimientos
3. Limitaciones

1. Para qué sirve y cómo activarla

Esta característica permite a los Hosts cambiar la frecuencia y los voltajes de la CPUs basándose en la demanda de la carga de trabajo de estos.

Consigue que los procesadores puedan llegar a consumir menor energía y por consiguiente menor temperatura de trabajo.

Se activa mediante una interface que permite operar sobre los estados de rendimiento de una Cpu (P-State).

Los P-States son definidos para fijar la frecuencia y voltaje que operan a en las Cpus. Los procesadores pueden operar en niveles diferentes de P-States:

• Pmin= P-State de menor nivel
• Pmax0 P-state de mayor nivel

Los P-States, son controlados desde la ROM del sistema o desde algún Sistema Operativo.

En VMware vSphere, los P-States son controlados por el Vmkernel, el cual optimiza la demanda de frecuencia de cada CPU.

2. Requerimientos

Las CPUs deben soportar y tener activadas las siguientes características:

- Enhanced SpeedStep para procesadores Intel

- Enhanced PowerNow para procesadores AMD

- Todas la versiones de vSphere soportan esta característica

- En la pestaña Configuration/Advanced Settings/Power/ Power.cpu = Dynamic.. Por defecto está en estado de Static, en el cual el Vmkernel es capaz de leer todos los P-states pero no realiza cambio alguno en las CPUs.

Recuerda que esta optimización de la frecuencia de las CPUs jamás afecta en el rendimiento.

3. Limitaciones

No hay manera de poder monitorizar los P-States en vSphere.

Debo de decir, que en esta última versión de vSphere 4.1 Update 1, no encuentro la política que activa dicha característica en (Advanced Settings) por lo cual indagaré un poco por ahí para saber cómo se activa o donde se encuentra dicha política.

Bueno, hasta aquí por hoy. Me despido de vosotros, esperando haber podido contar algo interesante y te emplazo hasta la semana que viene, con un nuevo capítulo sobre la virtualización.

Ya esta disponible online el septimo episodio en nuestro Web TV show de virtualización en español.

Virtualizacion.TV es nuevo programa de televisión web que ayuda a profesionales y usuarios de la virtualizacion como tú, a virtualizar tu centro de datos y no morir en el intento.

Esta semana tenemos una gran leccion de CheckPoint Systems, hablaremos de la oferta dos por uno en la certificación de VMware VCP en el campo de la virtualización, contestaremos a una gran pregunta de un usuario relacionada con el uso de la tecnología de hyperthreading a nivel de CPU y descubriremos una utilidad increíble de VMware que te ayudara a convertir, exportar e importar el formato de tus máquinas virtuales.

¿Y tú, eres ya certificado VMware VCP? ¿Cuáles fueron los recursos que usaste para aprobar el examen oficial de certificación VMware VCP que es el valor real de la certificación VCP de VMware? Deja tu comentario abajo en este video o charlemos sobre ello en twitter.

Hola soy Jose Maria Gris y de nuevo estoy aquí con vosotros. Últimamente esta sección parece un poco como cuarto milenio . Lo que os comentaré hoy no es que sea cosa de brujas pero si es cierto que me ha traído de cabeza en 2 instalaciones estos días y la verdad es que no acababa de verlo claro. Tras investigación y pruebas de laboratorio, ha quedado bastante claro.

Bien, todo empieza cuando llego a una instalación que “se ha vuelto loca”. Sencillamente es ingobernable, no contesta ni responde correctamente ni al VI client ni a vCenter…. No se comporta correctamente con SSH. Vamos, un potro desbocado. Eso sí, las VM continúan dando servicio sin problema.

Nos ponemos en contacto con soporte y nos comentan que lo que tenemos es un “All paths Down” o APD. Solución: Hay que entrar en las vms por RDP, pararlas y posteriormente hacer caer el ESX/i con un Cold Reset. Cuando se levante, todo estará en su sitio. Soporte “dixit”

Bien, vamos a ver como ocurre esto. El KB 1016626 nos empieza a dar luz sobre el tema. El resumen es “si se efectúa un rescan cuando una lun esta con todos los enlaces caídos puede generar o bien que otra vm deje de responder o como me ocurrió a mi, que los hosts se vuelvan locos.” Las razones pueden ser múltiples, error de hardware, sacar una lun de golpe, etc. Lo cierto es que con diversos levels de ESX he visto comportamientos muy parecidos, pero distintos.

Por lo que he estado investigando, es un bug de vSphere. Con 3.5 no pasaba. Básicamente si en un rescan el sistema detecta que no encuentra una Lun, se vuelca con el proceso hotsd a buscarla, tanto, que llega a bloquear nics, etc….

Si estás leyendo esto y estas en 4.0. U1, tienes que pensar en instalar el parche que se indica mas abajo en referencias, el cual minimiza el tiempo de “no respuesta”. Con 4.0 U2 y 4.1 ya viene instalado.

La buena noticia es que ya leí en un KB que en versión 4.1 U1 el tema se solventaba. La tengo instalada en mi laboratorio y efectivamente entre las features comenta que “ya no deberá pasar mas”, aunque hay un comentario sobre “si ocurre, contacta con soporte técnico.”

No contento con ello he cogido una instalación grande en preproducción, con SANs y con Datacore importante y simplemente he sacado una lun para posteriormente hacer un rescan manual desde el cluster. Lo cierto es que no le ha gustado nada, ha “tosido” se ha molestado, se ha recorcobecado, pero al cabo de un par de minutos estaba todo bien y continuaba en su sitio. Nada que no se pueda mitigar.

Lo reconozco, no me he quedado contento. Lo he probado en mi pobre labo. Los resultados han sido los mismos.

No os voy a decir que el APD ha quedado eliminado, esto lo debe decir el fabricante, pero en mis pruebas, al menos, no ha aparecido….

No obstante, la próxima semana os presentaré como hacer correctamente un “masking” desde ESXi para despresentar una LUN en vSphere 4.x (esté o no solventado el APD, por si las moscas).

Hasta la semana que viene.

Referencias
KB Article: 1016626 Virtual machines stop responding when any LUN on the host is in an all-paths-down condition (APD)
VMware ESX 4.0, Patch ESX400-200912401-BG: Updates vmkernel, vmklinux, tools, CIM, and perftools (1016291)
VMware ESXi 4.0, Patch ESXi400-200912401-BG: Updates Firmware (1016295)