Author Archive

Una de las funcionalidades de las nuevas licencias de vmware vSphere, es la de Hot Add. Esta funcionalidad permite el agregado, en caliente, tanto de memoria como de procesadores virtuales (vCPUs) a una máquina virtual. Realmente es una funcionalidad que puede llegar a ser muy útil en la operatoria diaria de algunas organizaciones, pero hay varios puntos a tener en cuenta para poder llegar a utilizarlo.

Ante todo, las maquinas virtuales deben estar funcionando con la ultima versión de Virtual Hardware, es decir la version 7.
Luego, y como suele suceder en muchas de las funcionalidades que se relacionan fuertemente con el sistema operativo guest, este ultimo debe soportar la funcionalidad.

Por último, más allá de la compatibilidad de Virtual Hardware y de OS, el feature debe ser habilitado desde las opciones de la maquina virtual.

Para poder validar sobre qué sistema operativo podremos usar la funcionalidad, nada mejor que validarlo en el flamante buscador de guías de compatibilidad de VMware, donde seleccionando el Tab Host/OS y luego el OS necesario y la versión de producto de VMware, se podra visualizar los detalles de compatibilidad.
Pruebenlo ustedes mismos, pero por lo pronto les adelanto que en lo que es Microsoft, existen un buen numero de OSs soportando Memory Hot Add, y unos pocos soportando vCPU Hot Add (entre ellos Windows 2008 Datacenter SP1/SP2/R2 y Windows 7 Enterprise). Luego, en el mundo Linux, la compatibilidad es mas diversa para ambos features.
Saludos.

Diego Quintana

En cuanto a las alertas por eventos sobre la infraestructura, cabe resaltar algunas consideraciones en cuanto al envío por e-mail de estas, ya que existe un punto importante a tener en cuenta sobre la configuracion y se trata de la necesidad de habilitar el relay de smtp desde el equipo donde se encuentra instalado el vCenter. Esto salta a la vista cuando vemos que los únicos campos que pueden ser llenados durante la configuración de envío son dirección de origen de los mails y nombre o ip del servicio smtp.

Para acceder a esta configuracion, ir a Administration -> vCenter Server Settings

Luego seleccionar el SMTP Server y el Sender Account

Luego desde cada alerta configurada se podra seleccionar el destinatario del mail, por ejemplo en la siguiente:

De esta manara, habra que gestionar desde el lado de configuracion del servidor de correo electronico, que la cuenta de origen sobre el SMTP tenga permisos para realizar Relay.

Otro detalle a tener en cuenta es la cantidad de alertas que por default estan configuradas con el evento de envío en Repeat, lo que hace que se envien grandes cantidades de emails cada vez que ocurre algun disparo de alarma, conllevando en ocaciones a situaciones tediosas de borrados de email, lo que a largo plazo suele traer como consecuencia que el receptor comience a tomar la llegada de los mails como algo molesto y deje de prestarles atencion; o lo que es peor, configurar que estos mails no toquen el inbox. Debido a esto es altamente recomendable configurar las alertas en las instancias iniciales de una implementacion (lo que ayuda a conocer los detalles de comportamiento de la plataforma) y en la medida justa (evitando que se convienta en algo molesto)

Espero les sea de utilidad,

Saludos,

Leandro Santoro

La configuracion de alarmas para conocer los distintos eventos que se presentan sobre la infraestructura virtual, sin necesidad de estar continuamente frente a la consola de administracion, es una de las practicas mas importantes para contar con una gestion proactiva de la plataforma.

En las ultimas versiones de Virtual Center y vCenter Server, se han observado mejoras en las funcionalidades de las alertas.

Si creamos una nueva alarma o editamos una de las existentes, podemos ver que lo primero que se debera ingresar es qué tipo de objeto vamos a estar monitoreando.

El tipo de objeto a monitorear y el tipo de variable o evento a monitorear definira el tipo de Alarma o Alarm Type

Luego se deben identificar los triggers, que son los disparadores de cada alerta, es decir la condision de las variables correspondientes al tipo de alarma seleccionada, que al cumplirse  ejecuta una accion deseada.

Estos triggers podran depender de si se trata de una condision relacionada a un cambio de estado o una metrica de performance de algun tipo, y de acuerdo a esta seleccion existen dos familias de eventos a ser capturados. Luego cada una podra tener distintos tipos de valores y parametros.
Por ultimo, de acuerdo a la accion, se dispararan eventos de comunicacion de la alarma (mediante el envío de mails o mediante el envío de traps snmp) o acciones de objetos de la infraestructura, como podra ser el apagado de un equipo, el encendido de otro, etc.

Estos se configuran a traves del tab Actions, en el caso de ejemplo es un simple envio de correo electronico.

Para detalles extra ver el post de Consejos para el envio de alertas por email

Espero les sirva!

Saludos,

Leandro Santoro

Respetando la estrategia de dar empuje a la API de vStorage anunciada junto con el lanzamiento de la linea vSphere, VMware anuncia el End of Life de VMware Consolidated Backup, la herramienta y conjunto de scripts que permitía el respaldo de maquinas virtuales, y archivos contenidos en éstas.

Esta noticia confirma la posicion de VMware de promover el uso de sus APIs por parte de terceros y la utilizacion de la herramienta de Data Protection para los ambientes donde ésta pueda cubrir las espectativas de los clientes.

A continuacion el anuncio:

Announcing End of Availability for VMware Consolidated Backup

	Dear Valued Customer, The purpose of this letter is to inform you of our vSphere backup product strategy, ongoing enhancements, and end of availability plans for VMware Consolidated Backup. VMware Backup Product Strategy VMware released vStorage APIs for Data Protection (VADP) with the vSphere 4.0 release in May, 2009. VADP is the next generation of VMware’s backup framework. We have also been working with several backup partners to integrate VADP into their solutions to make backup of vSphere Virtual Machines fast, efficient and easy to deploy compared to VCB and other backup solutions. Several of our major backup partners have already released VADP integrated backup products and we expect most of the major backup partners to have VADP integrated backup software by the upcoming feature release of the vSphere platform in 2010. Future Product Licensing Given the strong interest and adoption of VADP by our backup eco-system and the benefits offered by VADP compared to VMware Consolidated Backup (VCB), we are announcing the End of Availability for VCB starting with next vSphere feature release in 2010. Starting with the next vSphere platform feature release, VCB will be removed from vSphere platform. VADP integrated backup products (including VMware Data Recovery) will be the recommended option for efficient backup and restoration of vSphere Virtual Machines. This will allow us to focus new value added feature development on VADP instead of two backup frameworks (VCB and VADP). You can find more information about the use of vStorage APIs for Data Protection in our Developer Community. For information on the availability of VADP integrated release of your backup product please contact your backup vendor. End of Availability With the release of the next vSphere platform, we will continue to provide the binaries for VCB, but they will not be compatible with the next platform release. We will continue to provide support for VCB on the current vSphere platform per the VMware support policy. If you need assistance in the migration from VMware Consolidated Backup to the vStorage APIs for Data Protection, please contact your local reseller or storage backup vendor. Best regards, VMware Product Management

Fuente: vmware.com (link)

Leandro Santoro

La sincronización de información y la aplicación de cambios de configuración que se realizan mediante el vCenter sobre los ESX se realizan por medio de un usuario especial en cada uno de los ESX. Se trata del vpxuser, usuario unix local de los ESX que trabaja al mismo nivel que la cuenta root de estos.

Un dato importante al momento de encarar el aspecto de seguridad de los ESX, es la importancia de no realizar cambios sobre la cuenta vpxuser de cada ESX, ya que los atributos de dicha cuenta, como ser el password, son determinados en el momento de la incorporacion del host ESX a la infraestructura de vCenter. Esto se realiza justamente mediante el wizard de Add Host dentro de una estructura de datacenter.

A modo de ejemplo, a continuacion se muestra el comportamiento de dos ESX que fueron manipulados erroneamente mediante un cambio de password de la cuenta vpxuser luego de haber sido sumados a la infraestructura de vCenter.

Como ven, ambos figuran como desconectados y arrojan eventos de falla en la sincronizacion.

Error:

Cannot synchronize host <hostname>. Cannot complete login due to an incorrect user name or password.

Con solo realizar la desconexion y volver a conectar los hosts  se soluciona el problema ya que se vuelve a configurar automaticamente la cuenta vpxuser. Esto se realiza mediante el menu del ESX, opciones Disconnect y Connect respectivamente.

Tener en cuenta que este proceso de reconfiguracion solo es posible debido a que para la conexion del host debe ingresarse una cuenta root y su correspondiente password.

Como practica recomendada para los casos de segurizacion de los ESX recomendamos que si bien la cuenta root puede ser ensobrada y realizarle cambios de password periodicos sin impactar en la inraestructura, en cambio, la cuenta vpxuser debera ser siempre dejada a un lado de estos protocolos para que sea solo manipulada internamente por el proceso de reconexion, evitando impactos importantes en el comportamiento de la infraestructura virtual.

Espero les sea de utilidad.
Muchas Gracias!

Leandro Santoro

Hace unos dias un cliente queria utilizar la funcionalidad de “copy & paste” de archivos entre datastores. Hasta ahi no hay problema, sabemos que si estamos conectados a un vCenter con visualizacion sobre dos datastores, se pueden browsear estos datastores, hacer copy y luego paste, generandose una tarea de copia.

El verdadero problema es cuando tenemos dos esx que se ven entre ellos a nivel service console, pero no comparten la visualizacion sobre los mismos datastores.

En esos casos, nada mejor que ir a las herramientas mas simples que nos da la distribucion de Linux sobre la que esta implementado la Service Console de los ESX!

Utilizando el scp (secure copy), que es la herramienta de linux para poder hacer copy sobre protocolo ssh, y teniendo el recaudo de abrir los puertos necesarios y de tener los permisos adecuados, se podran pasar archivos de un esx a otro, sin importar si se trata del storage local, storage compartido, o storage que cada esx ve independientemente.

Para esto vamos a pensar en un ESX “origen”, y un ESX “destino”, sobre los cuales deberan estar logueados con super user (root)

Para loguearse con super user:

- Utilizar algun cliente ssh (como ser putty) o directamente la herramienta ssh para los que accedan desde una consola linux.

- Conectarse con un usuario local del ESX que no sea root (recuerden que por defecto no esta habilitado el acceso directo por ssh mediante la cuenta root).

- Una vez dentro, ejecutar la herramienta “super user” para escalar privilegios, la herramienta solicitara el password de la cuenta de root.

- Una vez que esten dentro como super user en el host de origen y de destino, ejecutar el resto de los pasos.
Podran validar que esten como super user, si su prompt tiene como ultimo caractér un “#”, lo que simboliza que se tienen privilegios de super user.

- En el host Origen:

# esxcfg-firewall -o 22,tcp,out,ssh
Esto abrira (-o) el puerto 22, correspondiente al servicio ssh, para el protocolo tcp, en sentido saliente (out)

- En el host Destino:

#esxcfg-firewall -o 22,tcp,in,ssh
Esto abrirá (-o) el puerto 22, correspondiente al servicio de ssh, para el protocolo tcp, en sentido entrante (in)

Hasta aqui, solo estaran abriendo un puerto puntual, que luego cerraremos al terminar el proceso de copia. Tengan en cuenta que no es una practica recomendada bajar la totalidad del firewall para hacer la operatoria. Si conocemos el puerto que necesitamos abrir, es un despropósito y un gran riesgo bajar la totalidad del firewall.

- En el host Origen:
# scp * vmware@destino:/home/bla
En este ejemplo del comando, se realiza la copia de todo archivo del directorio donde este parado, y se lo copia a /home/bla del equipo destino, vmware@ significa que en el equipo destino se ingresara con el usuario “vmware”
Tengan en cuenta que por defecto no se pueden hacer conexiones directamente usando root. Es por eso que en el ejemplo, la conexion se realiza con el usuario vmware, que ha sido creado durante el momento de la instalacion del ESX.

El proceso indicara el progreso de la accion de copia.

Una vez terminado se cierran los puertos que habiamos abierto tanto en origen como en destino de la siguiente manera:

- En el host Origen:
#esxcfg-firewall -c 22,tcp,out,ssh

- En el host Destino
#esxcfg-firewall -c 22,tcp,in,ssh

Eso es todo! Puede que los salve de un apuro…
Saludos,

Technology Consultant

Wetcom Group

T:+54 11 5254 7764 Ext.8446

C:+54 911 3112 2662

lsantoro@wetcom.com.ar

Como sabemos, este mes se realiza un cambio de hora en Argentina que sigue los lineamientos de las modificaciones de Ahorro de Energía realizadas en esta materia a partir de 2007.

Mas allá de las provincias que estén adoptando o no este cambio horario, es importante tener en claro cómo hay que actuar para poder impactarlo en nuestros hosts de infraestructura virtual, y que mejor que hacer referencia a nuestro ultimo post sobre el tema.

En esta oportunidad la norma indica que el Sábado 17 de Octubre de 2009 los relojes pasaran de las 23:59:59 a la 01:00:00 del dia Domingo 18 de Octubre.

Saludos!

virtualizar un equipo con una lun atachada

1. Deshabilitar el servicio o aplicación que accede a la LUN en el equipo Guest
2. Desmapear la lun del equipo físico (verificar que el equipo físico no vea la lun)
3. Virtualizar el equipo físico (cold clone o hot clone)
4. Mapear la lun con datos a TODOS los hosts del cluster donde correrá la VM con la lun
5. Apagar la VM
6. Edit Settings de la VM –> Add Hardware –> Hard disk

7. Seleccionar Raw Device Mapping

8. Seleccionar la LUN que fue mapeada en el punto 4

9. Seleccionar un volúmen VMFS (de SAN) para almacenar el puntero a la lun

10. Seleccionar el tipo de compatibilidad como virtual para permitir la ejecución de snapshots y VMotion

11. Seleccionar el id SCSI por defecto

12. Verificar la configuración propuesta

13. Iniciar el equipo virtual y desde el computer management verificar que esté viendo el disco de SAN con la letra correcta. En caso de que no lo vea iniciar un refresh de los discos para lograr esto.