VMware vSphere 4.1: Upgrade de ESX/ESXi usando vihostupdate utility

En los siguientes articulos detallaremos el proceso de upgrade de los hosts ESX/ESXi utilizando la utilidad "vihostupdate". Se debe recordar que no es posible migrar desde ESX a ESXi, para lo cual se debe hacer una instalación en limpio.

Introducción

VMware provee las siguientes herramientas para actualizar los hosts ESX y ESXi:

• vCenter Update Manager: Es un software provisto por VMware en su plataforma vCenter que permite realizar actualizaciones, upgrades y parchado de hosts en clusters, maquinas virtuales y sus respectivos sistemas operativos. Update Manager permite orquestar los upgrades de los hosts y las maquinas virtuales.
• vihostupdate: Utilidad de linea de comandos para ESX y ESXi que se ejecuta a traves de vSphere CLI
• esxupdate: Utilidad de linea de comandos solo para ESX. Se ejecuta directamente en la consola de servicios.

En este caso utilizaremos la utilidad "vihostupdate", la cual permite actualizar los hosts ESX y ESXi desde la versión 4.0 a la 4.1. Para actualizar hosts de una versión 3.x se debe utilizar vCenter Update Manager.

Componentes preservados luego del Upgrade

Cuando se actualizan los hosts a ESX/ESXi 4.1, el proceso de upgrade de los hosts preserva mucho de los componentes de la configuracion de dichos hosts:

• ESXi: Para ESXi, el proceso de upgrade preserva casi todos los datos de configuración, incluyendo configuraciones de red, seguridad y almacenamiento. La unica configuracion que no es preservada, es aquella relacionada al licenciamiento, debido a que nuevas licencias son requeridas luego del upgrade.
• ESX: Para ESX, el proceso de upgrade reutiliza la particion /boot existente para los archivos de booteo de ESX 4.1. El proceso de upgrade preserva casi todos los datos de configuración, incluyendo configuraciones de red, seguridad y almacenamiento. La configuracion de Resource Pools existentes en ESX 3.5 puede no ser preservada despues del upgrade, debido a falta de recursos disponibles.

Recomendaciones

Se recomienda el uso de direcciones IP estaticas para los hosts ESX/ESXi. El uso de DHCP para las direcciones IP de los hosts puede provocar problemas durante el proceso de upgrade.

Proceso de Upgrade

Hay varias herramientas disponibles para hacer el upgrade de los hosts ESX y ESXi, dependiendo del tipo de host que se esta actualizando (ESX o ESXi), y si los hosts son administrador por vCenter Server.

• El upgrade in-place de hosts ESX/ESXi 4.0 a la versión 4.1 es soportado usando la utilidad vihostupdate (a traves de vSphere CLI) y vCenter Update Manager. Adicionalmente los hosts ESX 4.0 pueden ser actualizados utilizando la utilidad esxupdate.
• El upgrade de hosts ESX/ESXi 3.5 a la version 4.1 es solo soportado por vCenter Update Manager.

NOTA: Si se esta haciendo el upgrade de un host administrado por vCenter Server, se debe hacer el upgrade de vCenter Server antes del upgrade de dicho host. Si no se sigue este orden, vCenter no será capaz de administrar el host una vez completado el proceso de Upgrade.

Habiendo entendido las opciones disponibles para el upgrade de los hosts ESX y ESXi, detallaremos los pasos para la migración de ambas versiones del hypervisor de VMware desde la versión 4.0 a la 4.1 utilizando la utilodad vihostupdate.

• Migración de ESX a 4.1
• Migración de ESXi a 4.1
• Consideraciones post-upgrade
• Hacer un Roll-Back del Upgrade

Para una documentación más detallada del proceso y que cubra todos los escenarios, pueden revisar la documentación oficial de VMware.

Read More

vSphere 4.1 / vihostupdate: Upgrade de ESXi con vihostupdate utility

A continuación detallaremos el proceso de Upgrade de un host ESXi 4.0 a la versión 4.1 utilizando vihostupdate.

Requisitos

Antes de que se pueda actualizar un host ESXi desde la linea de comandos, se debe tener acceso a un equipo en el cual se encuentre instalada la interfaz de linea de comandos de VMware vSphere (vSphere CLI). vSphere CLI puede ser instalado sobre Windows o Linux. También es posible utilizar el appliance virtual VMware vSphere Management Assistant (vMA) sobre un host ESXi.

El host a actualizar debe tener al menos 3GB de RAM si este se encuentra conectado a vCenter Server.
Adicionalmente se debe configurar una particion scratch y reiniciar el host antes de proceder con el upgrade. Se puede configurar una particion scratch para un host en la sección "Software Advanced Settings" en el tab de Configuración del vSphere Client. La particion scratch debe tener espacio suficiente (Al menos 4GB) para realizar el proceso de upgrade.

La particion scratch no es requerida para el funcionamiento mismo del hypervisor, sino que es utilizada para almacenar la salida de vm-support, lo cual es necesario cuando se crea un bundle para soporte. Si la partición scratch no existe, las salidas de vm-support son almacenadas en un ramdsik, lo cual puede ser un problema en situaciónes en que se cuenta con poca memoria disponible, pero no llega a ser un tema critico. En la versión ESXi Installable, la particion scratch es creada durante la instalacion, y VMware recomienda que esto no sea modificado.

Procedimiento

Descargar el siguiente archivo desde el sitio VMware, dejandolo en una ubicación accesible desde el equipo con vCLI. upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip Se debe apagar cualquier maquina virtual que se esté ejecutando en el host, o en su defecto moverlas o otro host utilizando vMotion
	Si vemos la consola de nuestro host ESXi, podemos ver que actualmente se encuentra en la version 4.0.0 (build - 164009)
	Utilizando vCLI ponemos nuestro host en modo de mantenimiento. Esto tambien puede realizarse utilizando el vSphere Client: vicfg-hostops.pl --server ip_host --operation enter
	Instalar el boletin esxupdate ejecutando el siguiente comando a traves de vCLI para realizar el proceso de pre-upgrade: vihostupdate.pl -i --server ip_host -b upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip -B ESXi410-GA-esxupdate El paquete ZIP de pre-upgrade debe encontrarse en una ubicación accesible por vCLI, pudiendo incluso ser una URL a un sitio HTTP o FTP.
	Instalar el boletin de upgrade ejecutando el siguiente comando a traves de vCLI para realizar el proceso de upgrade: vihostupdate.pl -i --server ip_host -b upgrade-from-ESXi4.0-to-4.1.0-0.0.260247-release.zip -B ESXi410-GA El paquete ZIP de upgrade debe encontrarse en una ubicación accesible por vCLI, pudiendo incluso ser una URL a un sitio HTTP o FTP.
	Se puede verificar los boletines instalados en el host ESXi utilizando el siguiente comando: vihostupdate.pl --server ip_host --query
	Reiniciamos el servidor ESXi, luego de lo cual podremos ver que nuestro host se encuentra actualizado a la versión 4.1

En siguientes articulos detallaremos los pasos de post-upgrade. En caso de tener algun inconveniente con el Upgrade, incluiremos un apartado con los pasos para realizar el rollback del upgrade de los hosts.

Read More

vSphere 4.1 / vihostupdate: Upgrade de ESX con vihostupdate utility

A continuación detallaremos el proceso de Upgrade de un host ESX 4.0 a la versión 4.1 utilizando vihostupdate.

Requisitos

Antes de que se pueda actualizar un host ESX desde la linea de comandos, se debe tener acceso a un equipo en la cual se encuentre instalada la interfaz de linea de comandos de VMware vSphere (vSphere CLI). vSphere CLI puede ser instalado sobre Windows o Linux. También es posible utilizar el appliance virtual VMware vSphere Management Assistant (vMA) sobre un host ESX.

El host a actualizar debe tener al menos 2GB de RAM si este se encuentra conectado a vCenter Server. Adicionalmente se deben cumplir los siguientes requerimientos de espacio en las particiones de ESX:

• La particion /root debe tener al menos 1.8GB disponibles
• La particion /boot debe tener al menos 24MB disponibles

 Procedimiento

Descargar los siguientes archivos desde el sitio VMware, dejandolo en una ubicación accesible desde el equipo con vCLI. pre-upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip Se debe apagar cualquier maquina virtual que se esté ejecutando en el host, o en su defecto moverlas o otro host utilizando vMotion
	Si vemos la consola de nuestro host ESX, podemos ver que actualmente se encuentra en la version 4.0.0 (build - 164009)
	Utilizando vCLI ponemos nuestro host en modo de mantenimiento. Esto tambien puede realizarse utilizando el vSphere Client: vicfg-hostops.pl --server ip_host --operation enter
	Ejecutar el siguiente comando en la consola de servicio de ESX (por SSH o directo en la consola del host), para permitir las conexiones salientes para la Service Console: esxcfg-firewall --allowIncoming --allowOutgoing
	Instalar el boletin esxupdate ejecutando el siguiente comando a traves de vCLI para realizar el proceso de pre-upgrade: vihostupdate.pl -i --server ip_host -b pre-upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip El paquete ZIP de pre-upgrade debe encontrarse en una ubicación accesible por vCLI, pudiendo incluso ser una URL a un sitio HTTP o FTP.
	Instalar el boletin de upgrade ejecutando el siguiente comando a traves de vCLI para realizar el proceso de upgrade: vihostupdate.pl -i --server ip_host -b upgrade-from-ESX4.0-to-4.1.0-0.0.260247-release.zip El paquete ZIP de upgrade debe encontrarse en una ubicación accesible por vCLI, pudiendo incluso ser una URL a un sitio HTTP o FTP.
	Se puede verificar los boletines instalados en el host ESX utilizando el siguiente comando: vihostupdate.pl --server ip_host --query
	Reiniciamos el servidor ESX, luego de lo cual podremos ver que nuestro host se encuentra actualizado a la versión 4.1
	Finalmente, reconfiguramos el firewall de la Service Console por temas de seguridad, ejecutando este comando directamente en la consola. esxcfg-firewall --blockOutgoing

En siguientes articulos detallaremos el proceso de upgrade de un host ESXi, asi como los pasos de post-upgrade. En caso de tener algun inconveniente con el Upgrade, incluiremos un apartado con los pasos para realizar el rollback del upgrade de los hosts.

Read More

VMware vSphere/iSCSI: Habilitación de Jumbo Frame

 

Siguiendo con los pasos necesarios para conectar VMware a una SAN iSCSI, detallaremos a continuación el proceso de habilitación de Jumbo Frame en la conexión iSCSI.

Introducción

En vSphere 4.x es posible habilitar Jumbo Frames en el iniciador iSCSI por software. El soporte para Jumbo Frame permite que paquetes más grandes sean transferidos entre los servidores ESX/ESXi y la SAN de manera de conseguir una mejor performance y una comunicación más eficiente. El soporte para Jumbo Frame puede ser habilitado solo a traves de la linea de comandos (CLI)

Para poder habilitar Jumbo Frame, la red iSCSI debe tener soporte end-to-end para que Jumbo Frame sea efectivo. Esto quiere decir que no solo se debe tener habilitado el soporte Jumbo Frame en los servidores ESX/ESXi, sino que también en los switches utilizados para conectar los hosts al storage, y también en el storage en si mismo.

En ESX/ESXi se debe habilitar Jumbo Frame a nivel de vSwitch y a nivel de VMkernel.
Si se va a utilizar vCLI o la vMA para ejecutar los comandos necesarios para habilitar Jumbo Frame, entonces la habilitación de Jumbo Frame debe ser realizada al momento de crear el vSwitch y los puertos VMkernel. No se puede modificar un vSwitch o los puertos VMkernel para la habilitación posterior de Jumbo Frame utilizando vCLI o vMA, esto solo puede ser realizado con comandos ejecutados directamente en el servidor ESX/ESXi a traves de SSH, o directo en la consola.

Procedimiento

Habilitación Jumbo Frame en vSwitch

	Si ingresamos a traves de vCLI o vMA, debemos ejecutar el siguiente comando para crear un vSwitch con Jumbo Frame habilitado. vicfg-vswitch.pl --server ip_host -m 9000 vSwitch
	Si queremos modificar un vSwitch existente con el fin de habilitar Jumbo Frame debemos ejecutar el siguiente comando a traves de SSH o directo en la consola del host: esxcfg-vswitch -m 9000 vSwitch
	Si queremos ver la configuración de los vSwitch y verificar la habilitación correcta de Jumbo Frame ejecutamos el siguiente comando via vCLI o vMA: vicfg-vswitch -l --server ip_host Opcionalmente podemos ejecutar el siguiente comando por SSH o la consola del host esxcfg-vswitch -l

Habilitación Jumbo Frame en los puertos VMkernel

	Si ingresamos a traves de vCLI o vMA, debemos ejecutar el siguiente comando para crear un puerto VMkernel con Jumbo Frame habilitado. vicfg-vmknic.pl --server ip_host --add --ip ip_vmkernel --netmask mask -mtu 9000 "VMKernel_Name"
	Si queremos modificar un puerto VMkernel existente con el fin de habilitar Jumbo Frame debemos ejecutar el siguiente comando a traves de SSH o directo en la consola del host: esxcfg-vmknic -m 9000 VMKernel_Name
	Si queremos ver la configuración de los puertos VMkernel y verificar la habilitación correcta de Jumbo Frame ejecutamos el siguiente comando via vCLI o vMA: vicfg-vmknic.pl --list --server ip_host Opcionalmente podemos ejecutar el siguiente comando por SSH o la consola del host esxcfg-vmknic --list

Al completar estos pasos ya contamos con nuestro vSwitch y los puertos VMkernel con Jumbo Frame habilitado. Recordar que Jumbo Frame debe ser habiltado en los Switch de comunicación iSCSI y en la SAN para que Jumbo Frame sea efectivo.

Read More

VMware vSphere/iSCSI: Configuracion Multipathing

A continuación seguimos con los pasos necesarios para conectar VMware a una SAN iSCSI.
Una vez creado el vSwitch y los puertos VMkernel, haber habilitado el iniciador iSCSI por Software y haber configurado los iSCSI Targets, proseguimos con la configuración de multipathing para los Datastores VMFS que se encuentran en la SAN iSCSI.

Introducción

Para mantener una conexión constante entre un host ESX/ESXi y su storage, VMware soporta funcionalidades de multipathing. Multipathing es una tecnica que permite utilizar más de una ruta fisica para transferir datos entre el host y un dispositivo de almacenamiento externo.

En caso de una falla de cualquier elemento en una red SAN, ya sea un adaptador de red, un switch o un cable, el host puede cambiar a otra ruta fisica, la cual no utiliza ninguno de los componentes con problemas. Este proceso de cambio de ruta es conocido como Path Failover.

Adicionalmente al Path Failover, Mutipathing provee balanceo de carga, distribuyendo la carga de I/O entre multiples rutas fisicas. El balanceo de carga reduce o remueve potenciales cuellos de botella.

El I/O de una VM puede ser retrasado por hasta 60 segundos mientras se realiza el proceso de Path Failover. Estas demoras le permiten a la SAN estabilizar estabilizar su configuracion despues de los cambios en la topologia. Generalmente estas demoras en el I/O pueden ser más extensas en arreglos activo-pasivos que en arreglos activo-activos. En algunos casos puede ser necesario realizar configuraciones adicionales en las maquinas virtuales para evitar problemas en los servicios producto de estas demoras en el I/O.

Para administrar Multipathing, VMware utiliza una capa especial de VMkernel, la PSA (Pluggable Storage Architecture), que es un framework abierto y modular, que permite coordinar las operaciones simultaneas de multiples plug-ins de multipathing (MPP).
El plug-in de multipathing que ESX/ESXi provee por defecto es el "VMware Native Multipathing Plug-in" o NMP, el cual es un modulo extensible que administra sub-plugins. Hay dos tipo de sub-plugins de NMP:

• Storage Array Type Plug-Ins (SATPs). SATP se preocupa de manejar los Path Failovers para un arreglo de Storage.
• Path Selection Plug-Ins (PSPs). PSP se preocupa de determinar cual ruta fisica es usada para emitir un requerimiento I/O a un dispositivo de Storage.

Los plug-ins SATP y PSP pueden ser provistos por VMware o por software de terceros. Si se requieren funcionalidades adicionales de Multipathing, un software de terceros puede proveer un MPP para ejecutarse como complemento o reemplazo de NMP (Plug-in por defecto de VMware).

NMP asigna un PSP por defecto para cada dispositivo logico basado en el SATP asociado con la ruta fisica para ese dispositivo, sin embargo esta asignacion puede ser sobrescrita. Por defecto VMware NMP soporta los siguientes PSP:

• MRU (Most Recently Used): Selecciona la ruta que el host uso más recientemente para acceder a un dispositivo de storage. Si esta ruta llega a encontrarse no disponible, el host cambia a una ruta alternativa y la continua utilizando mientras ésta se encuentre disponible. MRU es la politica de multipathing por defecto para arreglos activo-pasivo.
• Fija o Fixed: Utiliza la ruta designada como preferida si esta ha sido configurada. De lo contrario utiliza la primera ruta descubierta que se encuentre funcionando correctamente. Si el host no puede usar la ruta preferida, selecciona una ruta alternativa disponible en forma aleatoria. El host vuelve a utilizar la ruta preferida tan pronto como dicha ruta vuelva a encontrarse disponible. Esta politica es la politica por defecto para arreglos activo-activo.
• Round Robin: Utiliza un algoritmo de seleccion de rutas que va rotando a través de todas las rutas activas disponibles, permitiendo balanceo de carga a traves de las rutas.

Configuración de Multipathing para iSCSI

Para configurar el multipathing en nuestros hosts ESX/ESXi, debemos realizar dicha configuración en cada uno de los Datastores asignados a los hosts a traves de iSCSI

	Estando conectados al host ESX/ESXi o a vCenter, nos dirigimos al Tab de configuración del Host y nos dirigimos a la sección "Storage". Seleccionamos uno de los Datastores de nuestro Storage iSCSI y hacemos click en "Properties"
	A continuación se nos muestra los detalles del Datastore seleccionado. Se hace click sobre el boton "Manage Paths" para continuar.
	En nuestro caso, por defecto VMware seleccionó la politica MRU (Most Recently Used) para acceder a esta Datastore en la SAN iSCSI. Esta politica es seleccionada al tratarse de un arreglo iSCSI del tipo activo-pasivo. En nuestro caso modificaremos la politica para utilizar Round Robin como politica de Multipathing.
	Seleccionamos "Round Robin (VMware)" de la lista de seleccion de Paths y luego presionamos el boton "Change". Luego de unos segundos la configuración quedará de la siguiente forma.
	Finalmente cerramos las propiedades del Datastore haciendo click en Close. Al volver a la lista de Datastores disponibles en la sección "Storage", podemos ver que los Datastores estan utilizando Round Robin como politica de Multipathing, y que ven todos los caminos disponibles.

Al completar estos pasos ya contamos con Datastores VMFS a traves de nuestra red iSCSI, y configurados para usar la politica de Multipathing que nos permita asegurar conectividad continua hacia nuestro storage iSCSI, además de proveer balanceo de carga para las conexiones iSCSI. En los siguientes articulos detallaremos como habilitar Jumbo Frame y otras consideraciones como el uso de CHAP para asegurar las comunicaciones iSCSI.

Read More

VMware vSphere/iSCSI: Configuracion Target iSCSI

A continuación seguimos con los pasos necesarios para conectar VMware a una SAN iSCSI.
Una vez creado el vSwitch y los puertos VMkernel, y haber habilitado el iniciador iSCSI por Software, proseguimos con la configuración de los target iSCSI para luego agregar los Datastores VMFS a los hosts.

Configuración de los Targets para el iniciador iSCSI

Se debe configurar las direcciones de descubrimiento de los Targets, de manera que el iniciador iSCSI pueda determinar cuales recursos de Storage se encuentran disponibles en la red.
ESX/ESXi soportan 2 metodos de descubrimiento:

• Dynamic Discovery, también conocido como descubrimiento SendTargets. Cada vez que el iniciador se contacta con un servidor iSCSI especifico, el iniciador envia las solicitudes SendTargets al servidor (Target). El servidor responde indicando una lista de targets disponibles para el iniciador. Los nombres e IP's de los targets aparecen en el tab "Static Discovery". Si se remueve uno de los target estaticos agregados por Dynamic Discovery, el target volverá a agregarse a la lista la proxima vez que se produzca un Rescan, se reinicien las HBA's o el host ESX/ESXi sea reiniciado.
• Static Discovery. El iniciador no tiene que realizar ningún descubrimiendo. El iniciador tiene una lista de targets que puede contactar utilizando las direcciones IP y nombres de targets.

Configuración de Dynamic Discovery iSCSI

	Estando conectados al host ESX/ESXi o a vCenter, nos dirigimos al Tab de configuración del Host y nos dirigimos a la sección "Storage Adapters". Ingresamos a las propiedades del "iSCSI Software Adapter"
	En la ventana de propiedades nos dirigimos al tab "Dynamic Discovery" y presionamos "Add" para agregar la IP de un servidor iSCSI. Agregamos la IP del Storage iSCSI.
	Basta agregar solo una de las IP's utilizadas por las controladoras iSCSI que pueda tener el Storage (en nuestro caso el Storage cuenta con 2 controladoras con 2 puertas iSCSI cada una). No obstante, algunos Storage más basicos pueden requerir incluir todas las IP utilizadas por las controladoras en el tab "Dynamic Discovery"
	Si nuestro Storage ya se encuentra configurado para ser utilizado por los hosts (Creación de arreglos, LUNs, CHAP, etc.), podremos todos los Targets disponibles en el Tab "Static Discovery". Hacemos Click en "Close"
	A continuación se nos mostrará un mensaje recomendando un Rescan de los adaptadores iSCSI debido al cambio de configuración. Hacemos click en "Yes".
	Esto puede tomar unos minutos.
	Finalmente podemos observar que el iniciador iSCSI tiene visibilidad de las LUNs creadas y asignadas a nuestros hosts. Aqui podemos observar además los caminos disponibles entre el host y el Storage iSCSI.

Creación de Datastores VMFS

Una vez configurado los Targets iSCSI en nuestro iniciador, y luego de asegurarnos de que nuestro host tiene conexión con las distintas LUNs asignadas en el Storage iSCSI, podemos proceder con la creación de los Datastores VMFS.

	Estando conectados al host ESX/ESXi o a vCenter, nos dirigimos al Tab de configuración del Host y nos dirigimos a la sección "Storage". Hacemos click en "Add Storage" para agregar un nuevo Datastore.
	Seleccionamos el tipo de Storage a utlizar. En nuestro caso seleccionamos "Disk/LUN" que es la opción para Datastores sobre SAN iSCSI y Fiber Channel. Hacemos click en Next para continuar.
	Seleccionamos la LUN que queremos agregar. Hacemos click en Next para continuar.
	Nos muestra un resumen con la información de la LUN que agregaremos. Hacemos click en Next para continuar.
	Seleccionamos un nombre para el Datastore. Hacemos click en Next para continuar.
	Seleccionamos la capacidad a utilizar por el Datastore. Recordar que no se debe crear más de un Datastore por LUN. Seleccionamos además el tamaño de bloques del sistema de archivos. De la opción que elijamos dependerá el tamaño maximo que podrá tener un disco virtual (VMDK). Hacemos click en Next para continuar.
	Nos muestra un resumen del Datastore a crear. Hacemos click en Finish para terminar el proceso.
	Una vez que agregamos todos los Datastores que necesitemos, podremos ver algo como lo que se ve en la imagen, donde tenemos 4 Datastores VMFS disponibles para el uso de nuestra plataforma VMware.

Al completar estos pasos ya contamos con Datastores VMFS a traves de nuestra red iSCSI, y que pueden ser utilizados por nuestra plataforma VMware para crear Virtual Machines, Templates, etc. En los siguientes articulos detallaremos como configurar las politicas de Multipathing, asi como la habilitación de Jumbo Frame.

Read More

VMware vSphere/iSCSI: Habilitación del iniciador iSCSI

A continuación seguimos con los pasos necesarios para conectar VMware a una SAN iSCSI.

Una vez creado el vSwitch y los puertos VMkernel para el trafico iSCSI, debemos proceder con la habilitación del iniciador iSCSI por Software, asi como la asignación de los puertos VMkernel a dicho iniciador.

Configuración de Iniciador iSCSI

Habilitación del Iniciador iSCSI

	Estando conectados al host ESX/ESXi o a vCenter, nos dirigimos al Tab de configuración del Host y nos dirigimos a la sección "Storage Adapters". Ingresamos a las propiedades del "iSCSI Software Adapter"
	En la ventana de propiedades hacemos click en Configure.
	A continuación hacemos click en "Enabled" para habilitar el iniciador iSCSI.
	Una vez habilitado nos aparecerá la siguiente información en las propiedades del iniciador iSCSI, incluyendo el identificador IQN de éste. Hacemos click en close para terminar.

Asignación de puertos VMkernel al Iniciador iSCSI

Una vez habilitado el iniciador iSCSI por software, es necesario asignar cada uno de los puertos VMkernel (designados como vmk#) a dicho iniciador. De esta forma podemos luego habilitar el uso de Multipathing. Este paso solo es posible realizarlo a traves de la interfaz de comandos.

	Ingresamos a la interfaz de comandos vCLI.
	Ingresamos el siguiente comando por cada uno de los puertos VMkernel a asignar al iniciador iSCSI. esxcli --server ip_fqdn_host swiscsi nic add -n vmk1 -d vmhba37 Aqui se debe indicar la IP del host ESX/ESXi sobre el cual estamos trabajando, asi como el identificador del puerto VMkernel y del iniciador iSCSI (por default vmhba37). Ejecutamos este comando por cada uno de los puertos VMkernel
	Si ejecutamos el siguiente comando podremos ver los puertos VMkernel asignados al iniciador iSCSI: esxcli --server ip_fqdn_host swiscsi nic list -d vmhba37

En el caso de requerir remover un puerto VMkernel desde un iniciador iSCSI, el comando a utilizar es el siguiente:
esxcli --server ip_fqdn_host swiscsi nic remove -n port_name -d vmhba

Al completar estos pasos ya tenemos habilitada nuestra red iSCSI, incluyendo la configuración inicial del iniciador iSCSI por Software. En los siguientes articulos detallaremos como agregar Targets al iniciador iSCSI, asi como la creación de los datastores VMFS creados sobre LUNs iSCSI..

Read More