ESX

El día 27 de Octubre de 2011 VMware ha lanzado al público una nueva actualización de la versión de VMware vSphere 4.1 hacia el  Update 2 , con el objetivo de solucionar problemas de base y agregar algunas ¨pequeñas mejoras¨.

Para quienes tengan la versión 4.1  y estén evaluando hacer la actualización, aquí les dejo algunas de las mejoras de esta nueva actualización:

Información de Build

• ESXi 4.1 Update 2 Installable | 27 OCT 2011 | Build 502767
• ESXi 4.1 Update 2 Embedded | 27 OCT 2011 | Build 502767
• VMware Tools | 27 OCT 2011 | Build 493255

VMware ESX/ESXi

• Sporte para Procesadores AMD Opteron de la Serie 6200 (Interlagos) y AMD Opteron 4200 Serie (Valencia).
• Posibilidad de incluir nuevos drivers
• Nuevos sistemas operativos guests soportados (11.10 Oneiric Ocelot)
• Fixes de seguridad y bugs resueltos

VMware vCenter

• Soporte para Guest customization para nuevos Sistemas Operativos
• Soporte adicional para la base de datos de vcenter
• Fixes de seguridad y resolución de bugs

VMware vCenter Update Manager

• Soporte para instalación sobre Windows 2008 R2
• Soporte para instalación sobre SQL Express 2008 R2

Del otro lado de la cordillera de los Andes, me surge escribir esta nueva entrada para comentar cuales son los los 5 errores más comunes en ambientes virtuales y que traen grandes dolores de cabeza a más de uno.

Puesto #5 – Borrado de un Host dentro de un vCenter.

En más de una oportunidad hemos visto como dentro de un vCenter han querido borrar una vm y han terminado borrando un host, afortunadamente para ellos que lo han realizado, la tarea solo quita al host del vcenter, dejando todas las vms funcionando correctamente.

Puesto #4 -  Borrado de Snapshots.

A los administradores de VMware les recomiendo siempre tomar café a la mañana , en varias oportunidades hemos recibido el llamado diciendo – como recupero una vm que le borré el snapshot? – . Afortunadamente siempre hay soluciones, dependiendo cual fue el problema. Para esos casos les recomiendo buscar el grupo vmdk doctors en VMTN. Allí van a encontrar mucha información útil.

Puesto #3 – Upgrade del Esxi formateando los discos de la SAN.

Aumentando la severidad del daño, es conocido el caso de quién hace upgrade de un ESX/ESXi y cuando debe seleccionar el disco donde instalará simplemente elige uno de la SAN y se lleva consigo unas cuantas VMs al cielo. Para evitar este problema, les recuerdo que siempre que hagan un upgrade, si no están seguros, desconecten las fibras del servidor - método infalible – , caso contrario pueden quitar el host (sus wwn) de las zonas de switch de fibra.

Puesto #2- HA fuera de control por fallas de conectividad.

Siempre que instalen sus servidores de infraestructura recuerden tener al menos dos management ports o service console portgroups. Cada una de ser posible en redes y vlans distintas. Es más de ser posible, en switches distintos (se que es pedir mucho).

La recomendación viene porque el problema aparece cuando se cae una red de management, si no existe una redundante, los Host se declararán ISOLATED y se disparará el HA en todos los hosts a la vez generando un estado de caos total.

Puesto #1- Borrando las Luns del Storage con máquinas virtuales dentro.

Llegando al final cada vez hay  más casos de administradores que borran luns del Storage con máquinas virtuales dentro. Frente a estos casos, nada mejor como un buen backup.

Dejanos tus comentarios de cuales son para tí las peores.

Saludos,

En el segundo Podcast #2 de Wetcom, los vExperts Nicolás Solop y Diego Quintana debaten sobre los beneficios de migrar desde VMware ESX hacia VMware ESXi.

Conocé cuales son los desafíos técnicos para la migración,  mitos sobre el nuevo hypervisor y todos los pros y contras de hacer el cambio.

Seguí a Nicolás Solop (@nsolop) y a Diego Quintana (@daquintana) en Twitter!.

En el día de hoy VMware liberó la versión beta de VMware Converter Standalone 5.0 la cual dentro de lo que podemos encontrar como mejoras vemos la siguiente lista:

*Preservación de volúmenes LVM durante la conversión de sistemas operativos Linux.

*Mejoras en la sincronización post conversión y la posibilidad de programar bajo calendario varias sincronizaciones en un único job.

*Optimización de la alineación de particiones y del tamaño de clusters de disco

*Encripción de la información de conversión entre el origen y el destino.

VMware Converter es una herramienta desarrollada por VMware para ejecutar la conversión de servidores o estaciones de trabajo físicas en virtuales como así también la ejecución de conversiones de equipos virtuales a virtuales o la conversión de imágenes de disco como Symantec Ghost a máquinas virtuales.

VMware Converter viene en dos versiones Enterpise la cual se integra con vCenter Server y permite la conversión de equipos en frîo. La otra versión es la Standalone y permite la conversión de equipos en caliente contemplando sistemas operativos Microsoft Windows y algunas distribuciones de Linux.

Para quienes estén interesados en trabajar en la versión Beta de VMware Converter Stand Alone pueden visitar http://www.vmware.com/betaprogram/CONVERTER-5-BETA

Nicolás Solop
VMware vExpert

Primer podcast de Nicolas Solop y Diego Quintana, ambos VMware vExperts, donde explican con gran nivel de detalle cada una de las versiones de licencias de VMware vSphere disponibles al día de hoy en el mercado.

Seguilos a Nicolas Solop y a Diego Quintana en Twitter.

Links:

En varias situaciones (más aún en VDI) queremos prevenir que los usuarios no puedan ver ni modificar valores en las vmware tools.

Para evitar esto, se recomienda lo siguiente:

Acceder por medio de regedit a la siguiente ruta HKEY_CURRENT_USER\Software\VMware y modificar la clave ShowTray en 0 .

Con esto no alcanzará, también debemos  Ingresar al directorio   C:\Program files\VMware\VMware Tools .hacer click

derecho en el archivo VMControlPanel.cpl , acceder a la opción properties y elegir el tab Security

hacer click en Advanced y quitar el tilde Allow inheritable permissions.

luego hacer click  en Deny for Read and Execute and Read for the users

Una vez finalizado, hacer click en ok y loguearse como Administrador.

Hacer click derecho en el icono de las VMware Tools en la barra de sistema.
Seleccionar la opción  Disable.

Acceder por medio de regedit y borrar la siguiente la clave vmware tools de la siguiente cadena HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

Saludos

Diego Quintana

Una de las nuevas funciones que incluyó VMware ESX 4.1 es la posibilidad de realizar la autenticación de usuarios con servicios de directorio como Active Diretory. Esto es algo que desde la versión 2.5 se venia haciendo con procedimientos manuales que generalmente traian problemas a futuro cuando se necesitaba hacer algún upgrade de los equipos.

Para poder configurar esta función tendremos que loguearnos con el vSphere Client directamente a uno de nuestros servidores ESXi con una cuenta de root. Una vez logueados en el equipo tenemos que ir a la solapa de configuración, dar clic en Authentication Services

Luego damos clic sobre el link properties que se encuentra sobre la derecha de la ventana lo cual abrirá  una ventana para configurar los parámetros de autenticación. Completamos los datos del dominio y presionamos el botón "Join Domain"

Completamos los campos de usuario y contraseña con los datos de un usuario con privilegios para agregar equipos en el domio y presionamos el botón "Join Domain"

Una vez completo podemos ver que la opción que nos aparece es la de dejar el dominio cosa que no queremos hacer

El próximo paso es el de asignar los permisos correspondientes al grupo o usuario que designemos dentro de la jerarquia de vSphere

Luego de esto podremos loguearnos en el servidor con una cuenta de dominio del que el host pertenece en este momento

En el margen derecho podemos ver las credenciales con las que nos autenticamos y podemos ver son las del usuario del dominio

Nicolás Solop

Hace ya unos meses VMware anunció la actualización de VMware vSphere 4.1 la cual incluye unas cuantas mejoras en cuanto a prestaciones y algunos cambios sobre las existentes. A los pocos días también anunció varias actualizaciones de sus productos complementarios como VMware Site Recovery Manager y VMware View sumándoles la compatibilidad con la nueva versión de su producto central vSphere.

Uno de los puntos claves del primer anuncio es la aceptación formal por parte de VMware de que la versión 4.1 es la última versión en incluir ambas versiones de su Hypervisor ESX y ESXi. Este tema se venia discutiendo hace tiempo de forma informal con empleados de VMware locales y con usuarios de la tecnología en el grupo de Virtualización en Español que creamos en Linkedin.

La principal preocupación de muchos de los usuarios es como vamos a comenzar a trabajar de forma definitiva con esta tecnología y cuales deberían ser los puntos a tener en cuenta a la hora de comenzar con la migración de la tecnología VMware ESX hacia VMware ESXi. Muchos coincidimos en que a la hora de trabajar directamente sobre el cliente de administración de VMware (vSphere Client) prácticamente no existian diferencias entre trabajar sobre uno u otro de los modelos de Hypervisores pero la historia cambiaba si hablabamos de trabajar sobre la línea de comandos provista.

Desde un comienzo la consola de comandos de ESXi en las versiones anteriores a la 4.1 uno debía typear "unsupported" para acceder a la misma lo cual nos daba una idea de donde nos estabamos metiendo pero en la versión 4.1 ya tenemos en la terminal amarilla tan característica de ESXi la opción de habilitar y acceder a la consola de comandos lo cual nos muestra una pequeña evolución.

De todas formas con ganar acceso a la consola no es suficiente ya que no todos los comandos y opciones están implementados en la misma y no tenemos más opción que recurrir al VMware vMA el cual tiene implementado, por medio de API’s propias de VMware, la posibilidad de gestionar la plataforma virtual de VMware desde la linea de comandos ya sean interactivos o por medio de scripts. Sabiendo esto resolveriamos uno de los puntos que nos frenaban para comenzar a trabajar con ESXi pero existen algunos factores más a tener en cuenta que son muy importantes.

Por ejemplo tenemos aplicaciones de terceros que corrian sobre nuestras infraestructuras ESX por ejemplo nuestros agentes de la UPS o bien los agentes de software de monitoreo. Funcionarán sobre ESXi? tendremos las mismas funcionalidades? cómo se deberán implementar?. Estas preguntas en muchos casos no son nuevas pero la mayoría sigue sin respuesta o sin una respuesta oficial por lo que VMware y sus socios tecnológicos deberán realizar un trabajo muy fino de integración y utilización de las API’s provistas por VMware para garantizar que este cambio que con el tiempo tendremos que hacer forzadamente no sea un dolor de cabeza.

Otro de los puntos importantes a tener en cuenta son las funcionalidades similares que tienen ambas versiones del Hypervisor y entender que mucho de lo que se dice del ESXi de VMware son solo mitos.

Para cerrar la idea en muchos menos renglones… esto no va a ser simplemente instalar un ESXi, hacer un VMotion a otro equipo físico, instalar ESXi en el equipo vacio y distribuir la carga.

Nicolás Solop

Seguime en Twitter

Es muy probable que durante la actualización de hardware de nuestro datacenter virtual, se nos presente la necesidad de habilitar EVC en el cluster de vCenter para obtener la compatibilidad necesaria entre procesadores.

Resulta imposible realizar esta tarea si el vCenter Server está corriendo dentro de una VM en el Cluster objetivo.

Los pasos presentados a continuación son una de las soluciones disponibles para afrontar esta problemática:

Nota: EVC es compatible con ESX 3.5 Update 2 o superiores. Los hosts dentro del cluster deben contar con la misma arquitectura de CPU para que el procedimiento funcione correctamente.

1. Conectarse con vSphere Client al vCenter Server.
2. Crear un cluster vacio.
3. Habilitar EVC en el Nuevo cluster.
4. Migrar todas las maquinas virtuales de uno de los hosts del cluster viejo para liberarlo.
5. Desconectar el host vacio del vCenter (sin eliminarlo).
6. Arrastrar el host desconectado al cluster con EVC habilitado.
7. Reconectar el ESX host

   Esto deja el EVC cluster con un solo host ESX

8. Conectarse con el vSphere Client directamente al host ESX que tiene el vCenter.
9. Anotar la ubicación del archivo de configuración de la VM (.vmx) dentro del datastore.
10. Apagar el vCenter Server.
11. Boton derecho sobre la VM de vCenter y “Remove from Inventory”.
12. Conectarse con el vSphere Client directamente al host ESX dentro del EVC cluster.
13. Buscar en el datastore el archivo de configuracion de la VM (.vmx) del paso 9.
14. Boton derecho sobre el .vmx y “Add to Inventory”.

    De esta manera, tendremos el vCenter Server registrado en el host ESX dentro del EVC cluster.

15. Encender la VM del vCenter Server.
16. Conectarse con el vSphere Client al vCenter Server.

    En este punto, tenemos el vCenter Server corriendo en el EVC cluster y todas las otras VM en el host fuera del EVC cluster.

17. Para poder agregar el host ESX faltante al EVC cluster hace falta migrar todas las VM al host dentro del cluster.

    Si la migración falla en caliente, se deben apagar las VM y migrarlas en frio.

18. Una vez que todas las VM sean movidas dentro del EVC cluster, aplicar los pasos 5, 6 y 7 para agregar los host ESX faltantes al EVC cluster.

VMware vSphere ESXi es un hypervisor de VMware que puede ser utilizado gratuitamente por cualquier usuario que solicite la correspondiente clave de activación de ESXi a VMware. La primer versión de ESXi fue la 3.5 la cual apareció junto con la versión 3.5 de VMware ESX y la intención del mismo era que el mismo fuera embebido directamente en los servidores cuando salieran de fábrica pero con el correr de los meses VMware decidió liberar VMware ESXi para que cualquier persona lo pudiera utilizar sin colocar un peso en una orden de compra.

A diferencia de la versión VMware ESX, VMware ESXi es una versión reducida en tamaño al cual se le quitó el service console por lo tanto no contamos más con una línea de comandos nativa soportada por VMware. Al ser una versión reducida en tamaño tenemos también menos líneas de código lo cual se traduce en menos bugs, menos aplicaciones de parches y para cerrar, un hypervisor más seguro y salvo algunas diferencias que pueden existir dependiendo si corremos el VMware ESXi con o sin licencias es el mismo producto.

Desde el lanzamiento de ESXi en la versión 3.5 aparecieron varios mitos alrededor de esta versión del motor de virtualización de VMware que intentaremos romper ahora mismo:

• VMware ESXi no se puede utilizar con VMware vCenter para una administración centralizada:

FALSO | Se puede utilizar VMware ESXi conectado en un vCenter server para una administración centralizada siempre y cuando el usuario adquiera una licencia paga de VMware las cuales comienzan desde las VMware Essentials Plus.  Lo que no se puede hacer es utilizar un servidor con VMware ESXi desde un vCenter si el mismo no tiene las licencias necesarias para correr.

• VMware ESXi tiene menos funcionalidades que el VMware ESX

FALSO | La única diferencia entre las dos versiones de ESX es que una tiene una línea de comandos soportada y la otra no. El resto de las funcionalidades (VMware HA, VMware vMotion, VMware DRS, etc.) dependen de las versiones de licencias aplicadas sobre el servidor.

• Se requiere un upgrade a ESX  para poder utilizar las funcionalidades de las versiones pagas de licencias de VMware

FALSO | No se requiere realizar ningún tipo de upgrade o reinstalación para poder utilizar las versiones pagas de licencias de VMware vSphere ya que simplemente se debe adicionar el servidor ESXi a un vCenter server y asignarle las licencias de VMware correspondientes. 

• VMware ESXi no puede utilizar más de 8GB de memoria RAM

FALSO | Si bien VMware ESXi tiene algunos requerimientos mínimos de hardware, no tiene ningún tipo de limitación en la cantidad de memoria que puede utilizar para asignarle a las máquinas virtuales que corren en el mismo. Bueno tiene uno pero no creo que a nadie le afecte ya que el mismo es de 1TB de memoria RAM. Para verificarlo pueden revisar los máximos y mínimos de configuración de VMware ESX/ESXi 4.

Hay algunos puntos que generalmente no aparecen dentro de los "Mitos" de VMware ESXi ya que simplemente no son preguntados por los usuarios con los que me voy encontrando durante todos los días de trabajo. Básicamente todos están relacionados con la posibilidad de administrar y operar remotamente los servidores ESXi por ejemplo con la ejecución de snapshots desde la línea de comandos o bien realizar monitoreo remoto de los equipos.

Debemos ir acostumbrándonos a utilizar ESXi ya que se estima que en las próximas versiones del producto VMware anunció que la versión 4.1 será la última versión del producto donde podremos utilizar esta versión del motor de virtualización de VMware ya que la versión estándar de VMware ESX estaría por ser discontinuada.

Para ir viendo un poco del tema podemos ir leyendo sobre temas como:

• Administración remota de VMware ESXi por medio de Microsoft PowerShell
• Administración de VMware ESXi por medio de VMware vMA
• Acostumbrarnos al vSphere Client

Nicolás Solop