Archive for February, 2010

Cuando describimos lo que era una máquina virtual dejamos pendiente explicar como los recursos de hardware físicos con los que cuenta el servidor son presentados al sistema operativo guest (el sistema operativo que corre dentro de la máquina virtual) y como son utilizados por el mismo.

Para entender como recibe el sistema operativo guest los recursos de hardware, tenemos que entender primero los dos modelo de funcionamiento de hypervisores.

El primer modelo de funcionamiento de hypervisor hosteado o hosted corre por encima de un sistema operativo host como si fuera una aplicación instalada en el mismo siendo algunos ejemplos de este escenario VMware Server, VMware Workstation, VMware Player los cuales deben tener un sistema operativo Windows o Linux por debajo para poder correr. Otro ejemplo de este escenario es el VMware Fusion que corre sobre sistemas operativos Mac OS como el Snow Leopard.

En el otro escenario el hypervisor se conoce como nativo corre directamente sobre el hardware sin necesidad de un sistema operativo como intermediario. En este caso las máquinas virtuales obtienen los recursos del hardware físico de una forma mucho más eficiente ya que no requieren atravesar dos capas de software en el medio. Algunos ejemplos de estos tipos de hypervisores son VMware ESX, VMware ESXi, Xen y Microsoft Hyper-V.

Entonces para resumir como acceden los sistemas operativos guest a los recursos físicos ya vismos los dos posibles escenarios.

Seguimos en el próximo post!

Saludos,

Nicolas Solop

Únete al grupo de virtualización en español en LinkedIn

Tags: Virtualizacion, VMware ESX, VMware ESXi, Xen, Microsoft Hyper-V

Después de mucho tiempo de escribir sobre virtualización me di cuenta que estando en una empresa de tecnología, que se dedica prácticamente de lleno a la virtualización de servidores y desktops y que además tiene un blog con información relacionada al tema no podíamos seguir sin tener un post que "cuente" que es una máquina virtual.

Básicamente una máquina virtual (MV) o virtual machine (VM) como más nos gusta llamarlas a nosotros es una implementación de software de una máquina física ya sea un servidor o una pc. Estas máquinas virtuales utilizan recursos físicos como cpu, memoria y disco rígido del equipo físico donde corren los cuales le permiten a la misma correr un sistema operativo. Dejaremos para otro post el tema de como se le presentan estos recursos físicos a la máquina virtual.
Al mencionar que una máquina virtual es una implementación de software de una máquina física, estamos diciendo que lo que conforma a esta máquina virtual es un conjunto de archivos los cuales, en su mayoría, se pueden manipular como si se tratara de cualquier otro archivo presente en algún sistema operativo.

En la mayoría de los entornos de virtualización existen 2 archivos fundamentales de una máquina virtual:

• El archivo de configuración

• El o los archivos de disco

El contenido del archivo de configuración presenta los parámetros que hacen a la máquina virtual como cantidad de procesadores, cantidad de memoria, que archivo de disco debe utilizar y de que forma (IDE o SCSI) se lo debe presentar al sistema operativo que corre dentro de la misma al que llamamos sistema operativo guest.

En el o los archivos de disco siempre tendremos los archivos del sistema operativo guest, sus aplicaciones y sus datos.

Análogamente a los equipos físicos, las máquinas virtuales le presentan al sistema operativo guest un set de hardware en particular que va a depender de los parámetros definidos en el archivo de configuración y que va a requerir sus respectivos drivers o controladores los cuales son provistos generalmente por el fabricante de la plataforma de virtualización utilizada.

Al encenderse estas máquinas virtuales comienzan a utilizar los recursos disponibles en el equipo físico donde se encuentran corriendo permitiendonos instalar o ejecutar nuestro sistema operativo dentro de la misma. Como siempre, dependiendo de la plataforma de virtualización, el sistema operativo que corre dentro de nuestra máquina virtual no "sabe" que está corriendo dentro de una máquina virtual y no requiere modificación alguna sobre el mismo y podrá ejecutar básicamente cualquier aplicación o servicio sin que el desempeño se vea afectado.

El punto del hardware virtual nos abre la puerta para seguir hablando un poco más sobre los beneficios de la virtualización ya sea para servidores o desktops pero lo dejaremos también para otro post.

Es solo el principio (un poco tarde) del tema pero vale la pena.

Nicolás Solop

Sabemos que ESXi es la versión Gratuita de vSphere que permite a empresas de pequeña infraestructura incursionar en la Virtualización, también muy útil para Laboratorios, Pruebas de Performance, etc.

En este caso, voy a tratar un tema simple pero importante:

¿Qué puedo hacer con ESXi gratis y qué me habilita comprar Licencias?.

Haciendo un poco de historia en este blog, hace casi un año Nicolás Solop anunció el lanzamiento de un Kit de Management para ESXi en forma centralizada.  Con respecto a esta nota, menciono un detalle, ESXi sin Licencia tiene 2 limitaciones Claves:

1- El Host ESXi no puede ser manejado por un vCenter Server.  Los comandos API tienen acceso de sólo lectura al Host

2- No se puede modificar la configuración del Hypervisor automáticamente por medio de scripts.

De este modo, sabemos que al Licenciar ESXi, se activa la posibilidad de operar el Host con:

- vCenter Server

- vCLI

- vMA

- PERL Took Kit

- Powershell Tool Kit

(Próximamente postearé info técnica sobre vCLI y vMA)

Bueno, otra duda que brota a partir de acá, es qué features habilita cada Licencia.  Este cuadro les será de mucha utilidad:

Como se ve en el cuadro, ESXi stand alone es bastante limitado con respecto al resto.

Las herramientas de VMWare que marcan la diferencia se van sumando a medida que la licencia contratada es más alta (más que obvio), de todos modos, se ve claro que con la licencia más básica (Essentials), ya hay una notable diferencia, y su valor en $ no es elevado.  VC Agent, permite conectar el Host a un vCenter Server y poder administrar en forma centralizada los ESXi, además de Update Manager (update automático por medio de vCenter), VMSafe (Seguridad máxima para sus vms sin requerir recursos de la misma) y vStorage APIs para Protección de Datos.

Para conocer más acerca de licencias de vmware, visite:

Licencias Parte 1

Licencias Parte 2

Para mayor información acerca de Licenciamiento y Herramientas de VMWare, contáctenos!.

Saludos!!

Patricio Limeres

Tener en cuenta el comportamiento en el acceso a disco es algo vital en infraestructuras de alta densidad.

Cuando tenemos una gran cantidad de máquinas virtuales por Datastore o muchos ESX en un mismo cluster compartiendo los mismos VMFS, puede ocurrir que encuentren una baja performance en las HBAS, en ese caso probablemente tengamos que cambiar el valor máximo de queue depths en la HBA.

Cuando una sola maquina virtual es la activa dentro de una LUN, solo se debe setear al maximo el valor del queue depth.

Pero cuando muchas máquinas virtuales acceden a una lun y estas permanecen activas (es decir hay operaciones de escritura y lectura) el valor  Disk.SchedNumReqOutstanding también se vuelve critico .

La recomendación de VMware en su KB1267 es la de configurar los valores de Disk.SchedNumReqOutstanding y el queue depth del adaptador en el mismo valor.

Pasos pare cambiar los valores en ESX 4.0

Para ajustar el queue depth para una HBA:

1. Ingresar a la service console:
2. Verificar el modulo de la HBA cargadoQLogic:

   
   vmkload_mod -l | grep qla2xxx

   Emulex:

   vmkload_mod -l | grep lpfcdd

3. Ejecutar el siguiente comando, ej para las: QLogic qla2300_707 y Emulex lpfcdd_7xx
   QLogic:

   esxcfg-module -s ql2xmaxqdepth=64 qla2300_707
   
   Emulex:

   esxcfg-module -s lpfc0_lun_queue_depth=16 lpfcdd_7xx

   En este caso las ql2x y la lpfc0 deberían configurarse con el valor 64.
   

4. Reiniciar el host.

ESX 3.0/3.5

Para una HBA QLogic:

1. Ingresar a la service console:
2. Verificar el modulo de la HBA cargado
   
   vmkload_mod -l | grep qla2300
   
   qla2300_707 (ESX 3.0.x)
   qla2300_707_vmw (ESX 3.5)
   
3. Dependiendo el modulo de la HBA tener en cuenta y ejecutar :
   

   esxcfg-module -s ql2xmaxqdepth=64 qla2300_707
   esxcfg-boot –b
   
   

4. Reiniciar el ESX.

Para cambiar el queue depth of an Emulex HBA:

1. Ingresar a la SC como root.
2. Verificar que modulo de la placa Emulex es el que se encuentra cargado:vmkload_mod -l | grep lpfcdd

   Dependiendo el modulo de la HBA, deberán seleccionar:

   lpfcdd_7xx
   lpfcdd_732

3. Si tienen una HBA  Emulex en el ESX ejecutar el siguiente comando. (el ejemplo es para la el modulo lpfcdd_7xx )
4. Ejecutaresxcfg-module -s lpfc0_lun_queue_depth=16 lpfcdd_7xx
   esxcfg-boot –b

   
   

5. Para multiples HBA Emulex ejectuar:
   
   esxcfg-module -s "lpfc0_lun_queue_depth=16 lpfc1_lun_queue_depth=16" lpfcdd_7xx
   esxcfg-boot –b

   En este caso, ambas HBAs lpfc0 y la lpfc1 tendrán el LUN queue depths en 16.
   

6. Reiniciar el ESX.
   

Aquí les dejo la fuente del articulo de vmware.

Saludos

Diego Quintana

EL pasado 29 de enero de 2010, VMware Inc. publicó una nueva actualización de VMware Virtual Center 2.5, en este caso llevo el release al UPDATE 6, el cual contiene mas de 60 actualizaciones, algunas referidas a seguridad y el resto referidas a componentes de Storage, CIM, Networking, etc.

Para los usuarios que tienen vencida la suscripción en VMware, pero tienen licenciado el vcenter 2.5, podrán descargarla sin problemas desde aquí.

Este nuevo update trae como novedades el soporte a los siguientes sistemas operativos para el guest customization wizzard:

• Windows 7 Enterprise (32-bit and 64-bit)
• Windows 7 Ultimate (32-bit and 64-bit)
• Windows 7 Professional (32-bit and 64-bit)
• Windows 7 Home Premium (32-bit and 64-bit)
• Windows Server 2008 R2 Standard Edition (64-bit)
• Windows Server 2008 R2 Enterprise Edition (64-bit)
• Windows Server 2008 R2 Datacenter Edition (64-bit)
• Windows Server 2008 R2 Web Server (64-bit)

También incluye el soporte a Firefox 3.x para el vcenter web access.

Algunos de los issues reportados que se solucionaron en esta versión fueron:

When deploying virtual machine from a Windows 2000 guest operating system, customized keyboard and regional settings are reset to US English (KB 1017615)

Virtual machines deployed from Windows XP or Windows Server 2003 template do not display customizations made on the base template (KB 1005067)

Packets are duplicated when you configure a portgroup or a vSwitch to use a route that is based on IP-hash and Beaconing Probing policies simultaneously (KB 1017612)

VirtualCenter Server times out on successful snapshot quiesce operation (KB 1017608)

VI Client host memory is incorrectly reported on the ESX Server 3.5 host (KB 1017613)

I/O error occurs when downloading a large file from the datastore browser or when exporting a virtual appliance to OVF (KB 1017614)

A nivel seguridad, se hace referencia al update de APACHE TOMCAT a la version 5.5.28 y el upgrade de JRE a 1.5.0_22.

Para tener un detalle completo de los fixes de este nuevo release, les dejo el link.

http://www.vmware.com/support/vi3/doc/vi3_vc25u6_rel_notes.html

Saludos,

Ing. Diego Quintana

Siguiendo la tendencia de utilización del protolo PCoIP para virtualización de desktops impuesta por VMware en su producto View versión 4, Wyse Technology lanzó al mercado el thin client Wyse P20, su primer dispositivo que soporta este protocolo. Para ambientes de virtual desktop o blade pc, los equipos de la clase P de Wyse proveen un desempeño similar al de una pc de escritorio inclusive para aplicaciones CAD, 3D, rendering y los usos más exigentes de software de productividad.

Con un motor PCoIP basado en hardware el Wyse P20 no tiene como requerimiento un sistema operativo local lo que lo transforma en un completo stateless zero client.
Debido a que la implementación del protocolo PCoIP se apoya en un hardware dedicado para el mismo se obtienen considerables mejoras de rendimiento de video junto con capacidades que le permiten al Wyse P20, por ejemplo trabajar de forma nativa con dos monitores.

El Wyse P20 brinda una completa interoperabilidad de periféricos USB sobre ambientes locales LAN o remotamente sobre enlaces WAN de alta latencia haciendo uso de las habilidades del protocolo PCoIP para optimizar algoritmos de compresión permitiendo al usuario trabajar sobre diferentes tipos de enlaces y anchos de banda.

El equipo se encuentra soportado por VMware para su producto View 4 desde el día de su lazamiento y la empresa se encuentra trabajando en los ajustes necesarios para permitirle a sus thin clients anteriores poder trabajar con el protocolo PCoIP por medio de una implementación basada en software del mismo.

En breve dispondremos de algunos P20 en Wetcom para realizar demos y pruebas del mismo en oficinas de cliente. Si desea puede utilizar el formulario de contacto para coordinar demostraciones o pruebas de los mismos cuando estén disponibles.

Nicolás Solop

Únete al grupo de virtualización en español en LinkedIn

Tags: VMware View, Wyse, P20, PCoIP