VMware vSphere 4.1: VirtualCenter Server Service puede fallar al migrar a 4.1

Se ha publicado el KB 1026688 respecto a posibles problemas luego de una migración a vCenter Server 4.1

Sintomas

• El servicio VirtualCenter Server falla luego de la migración a  vCenter Server 4.1.
• Aparece el siguiente error en los logs vpxd:
  
  Panic: Win32 exception: Access Violation (0xc0000005)
     Read (0) at address 0000000000000098
     rip: 000000014071edcc rsp: 000000000419c700 rbp: 000000000419e160
     rax: 000000000419c7a8 rbx: 0000000000000018 rcx: 0000000000000020
     rdx: 000000000419c798 rdi: 0000000000000000 rsi: 000000000e8667b0
     r8:  000000000419c7a8 r9:  000000000cab1eea r10: 0000000002d27fd0
     r11: 000000000419c750 r12: 0000000007279700 r13: 0000000007279740
     r14: 00000000032edeb0 r15: 0000000000000004
  
• En vCenter Server 4.0, las operaciones como la busqueda en el inventario puede fallar.  El archivo vws.log se trunca con el error "Chuncked stream ended unexpected"  
• En vCenter Server 4.1, vCenter falla inmediatamente despues que se inicia el servicio, y el archivo vpxd-*.log muestra errores como los siguientes:
• ASSERT d:/build/ob/bora-258902/bora/vpx/vpxd/util/vpxdDbLoad.cpp:1059
• ASSERT d:/build/ob/bora-258902/bora/vpx/vpxd/util/vpxdDbLoad.cpp:1066

Solución

Este problema es causado por entradas corruptas sobre las maquinas virtuales en la base de datos de vCenter.

Para evitar toparse con este issue se deben seguir los siguientes pasos:

 

1. Descargar el Script apropiado (Para SQL u Oracle).  Los Scripts están disponibles en la publicación del KB.
2. Descomprimir y ejecutar los scripts en la base de datos de vCenter Server 4.0.
• La consulta SQL debe ser ejecutada utilizando nombres completos de las tablas de base de datos (fully qualified database table names).  Si se tienen multiples instancias de base de datos, puede ser necesario utilizar ademas el nombre de db-instance y de db-owner:
• ..VPX_VM_CONFIG_INFO
3. Si ningún resultado es devuelto por la consulta, se puede continuar con la migración. Si cualquiera de las maquinas virtuales es reportada con datos inconsistentes, se debe remover la maquina virtual del inventario de vCenter y luego registrarla nuevamente.
   
4. Continuar con la migración.

Si se realiza el upgrade a vCenter Server 4.1 y el servidor sigue fallando se deben seguir los siguientes pasos:

1. Realizar un roll-back de vCenter Server a la versión 4.0 y conectarlo a un backup de la base de datos.
2. Ejecutar los scripts descargadps en la base de datos de vCenter Server 4.0. 
3. Averiguar si alguna maquina virtual es reportada con datos inconsistentes.
4. Utilizando el vSphere Client, remover y volver a registrar las maquinas virtuales identificadas como inconsistentes.
5. Intentar nuevamente la migración. 

Para revisar el KB completo y descargar los scripts requeridos pueden dirigirse al siguiente link:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026688

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

VMware vSphere/iSCSI: Configuración de la red para iSCSI

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

Si se usa un adaptador iSCSI por Software o por Hardware, se debe configurar la red para iSCSI antes de poder habilitar y configurar los adaptadores iSCSI. La configuración de red para iSCSI incluye abrir los puertos VMkernel pare ltrafico entre el adaptador iSCSI y la interfaz fisica.

Dependiendo del numero de interfaces fisicas que se utilicen para el trafico iSCSI, la configuración de la red puede variar:

• Si se tiene una unica NIC fisica, se crea un puerto iSCSI sobre un vSwitch conectado a dicha NIC. VMware recomienda que se designe un adaptador de red separado para iSCSI. Este adaptador debe ser de 1Gbit o superior.
• Si se tiene dos o más NIC fisicas, se deben crear puertos iSCSI por cada NIC fisica y usar dichas NICs para el multipathing iSCSI.

Configuración de red iSCSI

A continuación realizamos la creación del vSwitch para iSCSI, asi como los puertos VMkernel para cada una de las interfaces fisicas existentes.

Si se tiene una unica interfaz de red fisica para el trafico iSCSI, los puertos VMkernel que se creen deberan asignarse a esa unica interfaz de red.

Creación del vSwitch para iSCSI

	Ingresamos al host ESX/ESXi o a vCenter utilizando vSphere Client.
	Hacemos click en el tab de Configuración del host y seleccionamos "Network Adapters". Aqui podemos ver las NICs disponibles y que podemos utilizar para la red iSCSI. En nuestro caso utilizaremos las NICs 4, 6, 8 y 10.
	Nos dirimos hacia la sección Networking y vemos los vSwitches existentes. En nuestro caso solo tenemos creado el vSwitch por defecto, el cual contiene el VMkernel Port para la Management Network (ESXi). Hacemos Click en "Add Networking"
	En el asistente seleccionamos VMkernel como el tipo de conexión a crear.
	Seleccionamos las NICs a utilizar en nuestra red iSCSI. En nuestro caso las 4 NICs a ser utilizadas se configurarán en un unico vSwitch con 4 puertos VMkernel. Hacemos click en Next.
	Seleccionamos el nombre del primer puerto VMkernel. En nuestro caso se llamará MD3200i_iSCSI01. Hacemos clien en Next.
	Seleccionamos una IP dentro del segmento de red asignado para la red iSCSI. Ingresamos también la mascara de subred y damos click en next para continuar.
	En caso de no tener configurado un Gateway por defecto aparecerá la siguiente alerta. Debido a que la red iSCSI utilizará un segmento IP no ruteable no requeriremos este paramentro. Hacemos click en "No" para continuar. Presionamos "Finish" para terminar el asistente.
	Se nos creará un vSwitch de la siguiente manera

Creación puertos VMkernel adicionales

	Ingresamos a las propiedades del vSwitch creado donde veremos la siguiente configuración. Hacemos click en "Add" para crear nuevos puertos VMkernel y realizamos el mismo proceso creado anteriormente para crear el primer puerto VMkernel
	Una vez creados todos los puertos VMkernel veremos la configuración de la siguiente manera.

Asignar cada puerto VMkernel a una unica NIC.

	En las propiedades del vSwich seleccionamos uno de los puertos VMkernel creados y hacemos click en "Edit"
	Nos vamos al Tab "NIC Teaming" y seleccionamos la opción "Override vSwitch Failover Order".
	A continuación dejamos solo una de las NICs activas, dejando las otras 3 NIC como adaptadores no utilizados. Este paso es requerido para la configuración iSCSI con Multipathing.
	Al volver a las propiedades del vSwitch podemos ver que el puerto VMkernel tiene una unica NIC activa. Repetimos el proceso para cada uno de los puertos VMkernel, asignandole una unica NIC activa, diferente para cada puerto. Hacemos click en Close para cerrar las propiedades del vSwitch.
	Ahora podemos ver los cuatro puertos VMkernel creados en el vSwitch, junto con las NIC asignadas.

Al completar estos pasos ya tenemos la primera parte de la configuración requerida para habilitar una red iSCSI. En los siguientes articulos detallaremos como habilitar el iniciador iSCSI por software, y como asignar los puertos VMkernel a dicho iniciador.

Read More

VMware vSphere 4.1: Conexión a una SAN iSCSI

En los siguientes articulos detallaremos el proceso de configuración de nuestra plataforma VMware, de manera de poder utilizar una SAN iSCSI como repositorio para los Datastores VMFS. Incluiremos la configuración requerida a nivel de red, iSCSI y multipathing.

Introducción

Es posible utilizar ESX/ESXi en conjunto con una SAN, que es basicamente una red especializada que conecta sistemas computacionales con subsistemas de almacenamiento de alta performance. El uso de una SAN, ya sea iSCSI o de Fiber Channel, provee una consolidacion del almacenamiento, al mismo tiempo que mejora la disponibilidad y facilita la recuperacion ante desastres.

Una SAN iSCSI utiliza una conexión Ethernet entre servidores y un sistema de almacenamiento de alta performance. Los componentes de una SAN incluyen HBAs (host bus adapters) iSCSI o interfaces de red (NICs) en el servidor, switches y routers que transportan el trafico del storage, Storage Processors (SP o controladoras) y sistemas de discos.

Como funcion el iniciador iSCSI por software?

Una SAN iSCSI utiliza una arquitectura cliente servidor, donde el cliente llamado iniciador iSCSI opera en el host. Este cliente inicia las sesiones iSCSI emitiendo comandos SCSI y trasmitiendolos, encapsulados en el protocolo iSCSI, a un servidor conocido como iSCSI target. El iSCSI target representa un sistema de almacenamiento fisico en la red y responde a los comandos del iniciador transmitiendo los datos iSCSI requeridos.

VMware utiliza puertos VMkernel como los iniciadores de sesiones, por lo que debemos configurar cada puertos que queramos utilizar como un camino (path) para el Storage. Esto es independiente del numero de NICs o HBAs iSCSI, pero en la mayoria de los casos será una relación uno a uno entre los puertos VMkernel y las interfaces disponibles. Una vez que las sesiones a la SAN son iniciadas, VMware NMP se encargará de balancear la carga y distribuir el trafico I/O entre todos los caminos disponibles.

Los volumenes en una SAN iSCSI pueden ser utilizados por ESX/ESXi como un Datastore VMFS o un Raw Device Map (RDM). El iniciador iSCSI por software utiliza los puertos VMkernel que fueron creados y establece una sesion a la SAN y a los volumenes. Con las versiones anteriores de VMware, estas sesiones eran establecidas utilizando un unico camino y cualquier NIC adicional era utilizada solo para efectos de Failover. Con las mejoras de vSphere y MPIO se pueden utilizar multiples caminos a la SAN para un mayor ancho de banda y performance.

Cada puerto VMkernel se encuentra asignado a un adaptador fisico. Dependiendo de la plataforma se pueden crear hasta 8 sesiones simultaneas a un volumen. Para una implementación estandar se recomienda el uso de una relación uno a uno (1:1) entre los puertos VMkernels y las interfaces fisicas, o sea si existen 4 interfaces fisicas, se crearía 4 puertos VMkernel, y se asociaria cada uno de estos puertos a una NIC separada. Este esquema puede ser expandido dependiendo del numero de NICs que se tengan disponibles.

A medida que la infraestructura va creciendo se pueden establecer multiples sesiones a la SAN suscribiendo más puertos VMkernel a las interfaces fisicas existentes. Esto establece multiples sesiones a un volumen, pero aun utiliza las mismas interfaces fisicas para acceder a dicho volumen.

Nuevas caracteristicas del iniciador iSCSI en vSphere

VMware vSphere ofrece muchas mejoras sobre el iniciador iSCSI por Software, junto con la conectividad para SAN iSCSI. Muchas de estas nuevas caracteristicas requieren configuración avanzada para trabajar apropiadamente, de hecho la configuración iSCSI utilizada en ambientes ESX/ESXi 3.5 no suficiente para habilitar todas las funciones avanzadas ofrecidas por vShere.

• Iniciador iSCSI por Software: Este iniciador fue re-escrito completamente en vSphere 4.1 para mejorar su performance y funcionalidad.
• Jumbo Frames: En vSphere 4.1 se puede habilitar Jumbo Frame en el iniciador iSCSI por Software. El soporte para Jumbo Frame permite la transferencia de paquetes más grandes entre los servidores VMware y la SAN, mejorando de esta forma la performance y eficiencia. Jumbo Frame puede ser habilitado solamente via la interfaz de linea de comandos (vCLI). Si se desea habilitar Jumbo Frame se debe recordar que esta configuración debe hacerse end-to-end, o sea desde el vSwitch hasta el Storage iSCSI, incluyendo los componentes intermedios.
• MultiPath I/O (MPIO): Con vSphere es posible el uso de Multipathing iSCSI desde los hosts ESX/ESXi y la SAN, permitiendo multiples conexiones concurrentes, aumentando asi el ancho de banda.

Buenas Practicas

• Se recomienda el uso de un Switch de red Gigabit Ethernet separado para el manejo del trafico iSCSI.
• Se recomienda conectar cada host VMware a 2 Switches iSCSI, cada uno de estos conectados a todas las controladoras disponibles en el Storage.
• Los servidores, Switches y puertos de las controladoras del Storage deben estar en el mismo segmento de red
• Se recomienda tener más de una HBA iSCSI o NIC dedicada para el trafico iSCSI.

Requisitos

Para la configuración de iSCSI en vSphere existen algunos requisitos que se detallan a continuación:

• Al menos una HBA iSCSI o NIC para el trafico iSCSI. En nuestro ambiente utilizaremos cuatro NICs para la configuración iSCSI.
• No se debe utilizar Switches Distribuidos (dVS) para el trafico iSCSI.
• Un segmento de IP dedicado para el trafico iSCSI. En nuestro caso utilizaremos el segmento no ruteable 10.0.0.x
• Verificar que todo el hardware utilizado, incluyendo las interfaces fisicas, el Storage y los servidores ESX/ESXi, se encuentren soportados por VMware.  Comprobar la compatibilidad en la Hardware Compatibility List (HCL)
• Solo se debe crear un Datastore VMFS por cada LUN creada en el Storage
• En VM utilizando Windows, aumentar el valor del parametro SCSI TimeoutValue para permitir que Windows tolere mejor las demoras en el I/O que pueda resultar del failover de los caminos o paths.
• Cuando se utiliza vCenter Server con vMotion o DRS, asegurarse de que las LUNs para las maquinas virtuales estén disponibles para todos los hosts ESX/ESXi requeridos.

Restricciones

• ESX/ESXi no soporta dispositivos de cinta conectados por iSCSI
• No se puede utilizar software de Multipathing en las maquinas virtuales para realizar el balanceo de carga de I/O a una unica LUN fisica.
• Un host no puede acceder a una LUN utilizando simultaneamente adaptadores iSCSI por software y por hardware.

Configuración de iSCSI en vSphere

Habiendo entendido la arquitectura de una SAN iSCSI y sus requerimientos y buenas practicas, a continuación detallaremos el proceso de configuración de iSCSI en VMware vSphere 4.1:

• Configuración de Red para iSCSI
• Habilitación del iniciador iSCSI
• Configuración de Targets iSCSI y agregar Datastores
• Configuración Multipath
• Habilitación de Jumbo Frame

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 / Cluster MSCS: Consideraciones finales

A continuación, y terminando con la Implementación de Cluster MSCS Across Boxes, entregaremos algunas consideraciones finales luego de la creación del Cluster.

Cuando se utiliza MSCS en un ambiente VMWare con HA o DSR habilitado, se deben realizar algunas configuraciones tanto a nivel de host como de virtual machine:

Todos los hosts que estan ejecutando virtual machines en cluster MSCS pueden ser parte de un cluster HA/DRS en vCenter Server. No obstante, si el cluster MSCS se encuentra en maquinas virtuales corriendo sobre un cluster VMware, se deben crear reglas de afinidad o de anti-afinidad. 

Las reglas de afinidad especifican cuales maquinas virtuales debieran permanecer juntas en el mismo host (esto aplica para cluster MSCS en una configuración Cluster In a Box). Por otro lado, las reglas de anti-afinidad especifican cuales maquinas virtuales debieran permanecer separadas en hosts fisicos distintos (esto aplica para cluster MSCS en una configuración Cluster Across Boxes). En nuestro caso especifico utilizaremos reglas de anti-afinidad. 

Para asegurar que las reglas de afinidad o anti-afinidad son aplicadas estrictamente, se debe configurar la opción avanzada ForceAffinePoweron para VMware DRS, dejandola con el valor "1", lo cual permitirá la aplicación estricta de las reglas creadas.

Se debe configurar el nivel de automatización de todas las maquinas virtuales en un cluster MSCS, dejandolas como "Partially Automated" o parcialmente automatizadas. Con esto se logra que vCenter Server realice la ubicacion inicial de las virtual machines cuando estas son encendidas y proveerá de recomendaciones de migración para estas. Considerar que no es recomendado la migración de Virtual Machines que sean parte de un cluster MSCS

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

Espero que toda esta serie de articulos les haya sido de utilidad. Como siempre, estoy atento a cualquier consulta.

Read More

VMware vSphere: Cuantas vCPU asignar por Virtual Machine?

Cuando creamos nuevas maquinas virtuales o realizamos una migración P2V con vCenter Converter frecuentemente surge la duda respecto de cuantas vCPU asignar a dicha maquina virtual.  A continuación detallaré algunas recomendaciones respecto a este tema, de manera de tener más claridad a la hora de configurar este recurso.

El numero de vCPUs requeridas para una VM depende del sistema operativo, aplicaciones y carga de trabajo.

1. Por defecto asignar solo una vCPU, a menos que haya una clara necesidad por más recursos:
2. Si hay una necesidad de mas vCPUs, entonces el sistema operativo y las aplicaciones deben soportarlas.  El sistema operativo debe soportar symmetric multiprocessing (SMP), y las aplicaciones deben ser multithreaded.  En el caso de las aplicaciones multithreaded, se debe consultar la documentación de la aplicación para determinar el numero de vCPU recomendadas por el fabricante.
3. Si la carga de trabajo requiere multiples vCPU, configurar tan pocas como sea posible, esto con el fin de lograr una mejor perfomance a nivel de maquina virtual y a nivel de host.
4. Mientras más vCPUs tenga una maquina virtual, mas recursos de CPU y Memoria son necesarios para administrarla.  Esta carga adicional desperdicia recursos innecesariamente si las vCPUs adicionales no son requeridas (Sistema Operativo sin soporte SMP o aplicaciones sin soporte Multithread).
5. Si la aplicacion no soporta multithread y se requiere mayor capacidad de procesamiento, se recomienda utilizar una estrategia scale-out, instalando múltiples maquinas virtuales con una única vCPU, cada una proveyendo el mismo servicio o aplicacion a diferentes usuarios.

Tener en cuenta lo siguiente en caso de decidir utilizar más de una vCPU por virtual machine:

1. Las vCPU consumen interrupciones del reloj aun cuando dichas vCPU no estén siendo utilizadas por la Virtual Machine.
2. Mantener la memoria consistente entre multiples vCPU consume recursos adicionales
3. Algunos sistemas operativos obsoletos ejecutan ciclos vacíos sobre las vCPU no utilizadas, lo cual consume recursos que podrían ser reasignados y mejor utilizados para otros fines.
4. Debe ser posible para todas las vCPU ser programadas sobre un Core físico al mismo tiempo, cuando la Virtual Machine esta programada para ejecutarse.  Esto no significa que cada vCPU será programada para ejecutarse sobre un procesador fisico cuando la VM esta programada para ejecutarse.  Cuantas vCPUs están ejecutándose a la vez, depende de la operacion que este siendo realizada en dicho momento.
   Este punto es muy importante, ya que si nuestra Virtual Machine tiene, por ejemplo, 4 vCPU y una operación requiere el uso de todas las vCPU a la vez, la operación debe esperar hasta que se encuentren 4 Cores físicos disponibles a la vez para atender la solicitud, de lo contrario no se podrá ejecutar dicha operación.  Esto puede provocar problemas de performance importantes si la espera por disponibilidad de Cores fisicos se prolonga.
5. El numero de vCPU no puede exceder el numero de Cores físicos en el host.  Por ejemplo, si un host tiene 1 CPU Quadcore, el numero máximo de vCPU a asignar es de 4.  En el mismo ejemplo, si los cores tienen soporte Hyperthreading, el numero máximo de vCPU es de 8.

Finalmente, cuando se realicen migraciones de maquinas físicas a virtuales, las maquinas virtuales deben ser creadas con hardware virtual que coincida con la capa de abstracción de hardware (HAL) del servidor físico.  Esto evita problemas de performance asociados con un host físico multiprocesador siendo virtualizado a una maquina virtual con un solo procesador.  Se recomienda revisar la documentación especifica del sistema operativo a ser virtualizado.
En caso contrario, VMware recomienda cambiar la HAL en la virtual machine a uniprocesador, si el servidor físico esta configurado con HAL multiprocesador, y la maquina virtual de destino esta configurada para usar una unica vCPU.

Espero que estas recomendaciones les sean de utilidad a la hora de crear una maquina virtual, o realizar una conversión P2V.  En un próximo articulo entregaré recomendaciones respecto a la gestión de la memoria en una plataforma VMware.

Read More

VMware vSphere: Monitorear con System Center Operation Manager

Para quienes utilizan System Center Operation Manager (SCOM) para monitorear sus plataformas y desean además poder monitorear su infraestructura VMware, Quest Software lanzó el Management Pack for VMware, el cual extiende las capacidades de Microsoft System Center Operation Manager.

Pueden chequear sus funcionalidades y descargarlo desde el siguiente link:
http://vizioncore.com/product/Management-Pack-for-VMware

Read More