Enviado por (0) Comment
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
|
|
Technology Consultant Wetcom Group T:+54 11 5254 7764 Ext.8446 C:+54 911 3112 2662 |
VMware por medio de su sitio de VMWARE PRODUCT LIFE CYCLE SUPPORT hace público el listado de los productos que actualmente están fuera de soporte y de aquellos productos que están cerca de estarlo.

Por eso, para aquellos que hoy tienen productos VMware y necesitan verificar si la version que tienen instalada está por quedarse sin soporte, pasen por aquí y podrán verificarlo de manera sencilla.
Los productos más conocidos que entraron en EOL son:
| VMWSE SERVER Version 2.x 2008/09/23
VMware View Manager 2 (VDM2) 2010/06/02 VMware Workstation Version 6.x 2011/04/27 VMware Workstation Version 5.x EOS Reached |
Por alguna duda sobre otro producto que no vean en el sitio de vmware, no duden en consultarnos!.
Saludos
Diego Quintana
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
Hace dos semanas, VMware liberó el Update 1, pero debido a un importante bug que afectaba a equipos proliant de HP, en el cual luego de hacer el upgrade de versión los equipos quedaban inutilizables, VMWARE LANZO el ESX 4 UPDATE 1 A.
Ahora bien, luego de descargar la versión del nuevo update, cuando intentamos hacer el upgrade desde VMware Update Manager, nos tira el siguiente error:
Upgrade is not supported from host version 4.0.0 build164009 to release version 4.0.0 update 1 build 208167
Error en vCenter update manager al actualizar hacia ESX 4 update 1a
Desafortunadamente este error no fué previsto por QA de vmware, de manera que no se puede actualizar a esta versión desde el Update Manager.
No obstante, recomendamos hacer lo siguiente:
- Colocar el ESX en modo mantenimiento
- Decargar el Archivo ESX-4.0.0-update01a.zip del sitio de VMware
- Subirlo mediante Veeam FASTSCP o WINSCP al directorio TMP de cada ESX
- Ejecutar desde la service console, logueado como root el siguiente comando:
esxupdate –bundle=ESX-4.0.0-update01a.zip update
Luego, reiniciar el equipo.
Al loguearnos al vCenter, o al hacerlo directamente al ESX, comprobaremos que ya está en el nuevo build.

ESX 4.0.0 Update 1a
Saludos,
Ing. Diego Quintana
VCP-VAC
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!
Detalle para Microsoft SQL Server:
Listo.
Las alarmas por Default ya quedarón nuevamente creadas.
Saludos.
Ref: KB Article: 1010399
________________________
Ing. Diego Quintana
VCP-VTSP-VSP-VAC
Mucho se habló sobre la nueva funcionalidad en VMware vCenter 4 (ex VMware Virtual Center)en cuanto a la facilidad de aplicar nuevas licencias al entorno virtual. Esta nueva funcionalidad le permite al administrador de VMware vCenter 4 aplicar los códigos de licencias simplemente en una operación de copiar/pegar desde el portal de licencias de VMware sobre el vCenter. En algunos proyectos en los que estuvimos trabajando nos encontramos con escenarios mixtos (sobre todo en etapas de actualización) donde una vez actualizado el VMware Virtual Center 2.5 a VMware vCenter 4 la nueva funcionalidad de licenciamiento no aplica para los servidores hosts VMware ESX Server 3.x y volvemos a caer en el antiguo VMware License Server y sus eternos archivos de licencias con extensión .lic. Como si esto no pasara inadvertido cuando se instala un nuevo servidor vCenter 4 el mismo no provee ninguna forma de instalar el License Server por lo tanto debemos comenzar a realizar algunas manualidades.
Lo primero que debemos hacer es identificar la situación al querer aplicar las licencias al nuevo VMware vCenter 4.0:
En este caso nuestro vCenter Server antes de ser licenciado gestiona varios hosts 3.5. Por lo tanto debemos realizar la instalación de del Licence Server el cual debemos descargar desde el sitio de descargas de VMware Virtual Infrastructure 3.5. Una vez descargado el license Server debemos comenzar con la instalación del mismo dando doble clic sobre el ejecutable.
Dar clic en el botón Next para continuar:

Seleccionar la opción “I accept the terms..” y dar clic en el botón “Next”

Dar clic en el botón “Next” para continuar aceptando el directorio de instalación por defecto

Dar clic en el botón “Browse” para buscar el archivo de licencias. Una vez seleccionado el archivo correcto dar clic en el botón “Next” para continuar

Dar clic sobre el botón “Install” para comenzar con la escritura de datos en el disco rígido

Dar clic sobre el botón finish para finalizar con la instalación del VMware License Server

El último paso es configurar el módulo de licencias del vCenter Server 4 para que utilice el VMware License Server recién instalado
Espero que les sirva.
Saludos!
Nicolás Solop
Enviado por (0) Comment
El pasado 13 de julio de 2009, AMD (Advanced MicroDevices) comunicó que ya se encuentran disponibles a la venta 9 modelos de procesadores Opteron de seis núcleos.
Esta vez con una arquitectura basada en 45 nm, AMD puso toda su energía en el desarrollo de procesadores de alto rendimiento por bajo consumo, algo que muchos no valoran actualmente pero sin lugar a dudas deberían hacerlo dado que la optimización de los recursos energéticos es prioridad en la agenda de todos los fabricantes de HW de IT.
Luego de varios meses de retraso y ya con un producto de muy buena performance, AMD sale a dar una batalla fuerte en el segmento de procesadores para servidores, donde actualmente Intel tiene el mayor dominio del mercado.
La gama baja de procesadores tiene un consumo de 50 W con velocidades de 2000 a 2100 Mhz por core, en cambio la gama más alta llega hasta los 2,8 Ghz con un consumo de 105 Watts por core.
HyperTransport™ technology (HT) assist es la base de impulsar una mejora considerable de performance en la optimización de uso de cache entre cpus, eso beneficia el uso de aplicaciones que deben hacer uso intenso de múltiples threats o uso de 4 a 8 vías. Un ejemplo claro son las Bases de Datos y sistemas de Virtualización.
Por otro lado encontramos que en el front de su microarquitectura sigue estando la controladora de memoria integrada, en esta acción beneficiando a la CPU en términos de eficiencia en el consumo eléctrico y por medio de RAS mejoran el soporte a fallas propias de la CPU dandole mejor tolerancia a fallas.
Rapid Virtualization Indexing y Tagged-TLB fueron desarrollados con el objetivo de permitir una traducción de virtual a físico del stack de memoria. En concreto, se trata de bajar la latencia y mejorar la performance de las maquinas virtuales. Por otro lado encontramos Extended Migration que permite realizar el movimiento de maquinas virtuales permitiendo compatibilidad hacia atrás en la familia Opteron, desde un single core hasta quad core inclusive.
AMD trae al mercado procesadores de muy buena performance, bajo consumo y un costo moderado y que en los primeros benchmarks muestran mejor performance por watt respecto de su principal competidor y lider intel.
Estos procesadores son excelente para virtualización, teniendo resueltos muchos de los issues de performance que se podían encontrar en los viejos opteron, más aun cuando el ratio de de virtualización por host era elevado. Sin lugar a dudas un procesador más que recomendado.
Saludos
________________________
Ing. Diego Quintana
Problema:
Cuando se trata de iniciar una sesión desde un vmware view client se obtiene el siguiente error:
All available desktop sources for this desktop are currently busy. Please try connecting to this desktop again later, or contact your system administrator.
Causa:
Este es un comportamiento normal dentro del vmware view manager, esto sucede cuando un usuario se encuentra logueado dentro de una virtual desktop y por algún motivo se desconectó y su sessión quedó activa en la maquina virtual. Si un usuario distinto intenta realizar un login a la misma desktop virtual tendrán el error antes mencionado.
Solución:
Para solucionar el problema, el administrador del vmware view deberá ingresar a la consola, seleccionar desktops and pools > la maquina virtual con el problema > Active Sessions > logoff session.
La tarea demorará aproximadamente 1 minuto en quedar efectiva.
Listo, ahora el otro usuario podrá loguearse correctamente en la desktop.
Saludos.
________________________
Ing. Diego Quintana
Enviado por (7) Comment
Como es ya es conocido, está liberado al publico google android para pcs, con el objetivo de ser probado por la comunidad de desarrolladores y por los usuarios finales. De esta manera google empieza a avanzar firme en la carrera por fidelidaz al usuario móvil sobre su sistema operativo.
Para instalar android en una maquina virtual en VMware workstation o VMware ESX, podrán armar una configuración básica como la siguiente:
Colocar como sistema operativo ubuntu.
Luego montar la ISO bajada de Aquí.
Cuando inicia el SO, carga la pantalla de bienvenida. El proceso de booteo no demora más de 10 sgs.
Nos alertará de la falta de carga de batería, esto es normal dado que es una emulación de un móvil.
Listo, tenemos acceso al desktop de Android, ahora dado que la placa de red está en modo bridged, deberían navegar sin inconvenientes dado que el sistema operativo detecta la placa perfectamente.
Probemos como se vé www.wetcom.com.ar en el browser de Android.
Sin estár en caché, el sitio tardó 1 sg en cargar, tiempo más que sorprendente.
Luego si hacemos clic en ESC saldremos al desktop. A la derecha está el acceso al panel de aplicaciones.
Si accedemos al panel de control de android podemos cambiar las configuraciones, tengamos en cuenta que no es un telefono, por lo cual hay funcionalidades que no van a andar.
Bueno, esto es una review de android, simple, para que vean como se puede ejecutar sin inconvenientes sobre VMware, para ver especificaciones propias de Android ya estarán los especialistas en móviles
A divertirse testeando su sitio en android y a los desarrolladores a usar el SDK.
Saludos.
________________________
Ing. Diego Quintana