Zimbra 6.X. La actualizción más sencilla.

Este fin de semana finalmente me animé a actualizar a Zimbra 6.x
A pesar de que esta release llevaba meses en el mercado, y e igualmente a pesar de que soy un gran forofo de Zimbra y siempre suelo estar a la última o a lo sumo una o dos "minor releases" por detrás, esta vez me lo tomé con mucha más calma.
Por un lado, la migración a Zimbra 6.0 desde 5.5 nos dio muchos problemas en el entorno de laboratorio cuando salió la 6.0.1, lo cual nos hizo replantearnos un upgrade tempranero.
Por otro lado el paso a 6.0 iba con la sutil sugerencia por parte de Zimbra de que la 6.0 será la última versión soportada sobre Red Hat 4.x, sistema operativo que utilizamos para nuestro sistema de correo desde que empezamos con la versión 3.5 de Zimbra.
Así pues, mi idea original pasaba por hacer un upgrade "in-place" a Red Hat 5.X para posteriormente retomar la actualización de Zimbra. No obstante, un upgrade del sistema operativo implica un reinicio total de la máquina, el uso de DVDs (ciertamente, RedHat en este aspecto hace años que debería haberse puesto las pilas) y a fin de cuentas presencia física en la oficina, en horarios intempestivos, y sin realmente hacer mucho (solo mirar y cruzar los dedos).
Posteriormente opté por que tal vez fuera mejor opción aprovechar todo de una vez, pasar a una distro seria para el tema de actualizaciones (Ubuntu 10.04 LTS es la precandidata en este caso) y de paso acometer esa virtualización que llevo meses planeando. Lamentablemente este proceso lleva igualmente mucho tiempo, dado que el manual "oficioso" de zimbra implica un full backup & restore, el cual lleva casi 12 horas... too much time...
Así que finalmente me he decantado por un upgrade de zimbra "a la exchange", esto es, montando un segundo servidor en un pool y finalmente moviendo los buzones del servidor antiguo al nuevo.
Pero para ello, ambos servidores de zimbra han de ir al mismo nivel de revisión. Y dado que es absurdo instalar una 5.0.23 para luego actualizar a 6.0.8, últimas versiones disponibles a día de hoy para la 5.x y 6.x, opté por actualizar primero la instalación existente, montar posteriormente nuestro nuevo servidor, y migrar cuando haya tiempo y ganas de pasar un poco de tensión.

He de reconocer que la actualización desde la 5.0.23 a la 6.0.8 ha sido fabulosa. Si con las pruebas entre la 5.0.18 y la 6.0.1 las pasamos canutas, en esta ocasión no hubo problema alguno. Ni en el entorno de laboratorio ni en el entorno real.
La operación duró 30 minutos, durante los cuales tuve tiempo para portar los cambios menores que hacemos a Zimbra para adaptarlo a nuestras necesidades que son básicamente un skin propio con logos de la compañía, cambiar el corrector ortográfico al español, y ajustes al sistema anti-spam.
Una vez terminado el upgrade, el sistema se ha levantado a la primera sin un solo fallo. Se le nota más ligero, dado que he aprovechado para activar memcached y darle un poco de vidilla a la base de datos. Además el paso a Java 1.6.0 también se ha notado bastante.

Entre las novedades que son muchas pero no destacan por ser especialmente espectaculares, sobresale la adición de acuses de recibo desde la interfaz web, la nueva gestión de ACLs para administración delegada del servidor, un puñetero bug para la sincronización de Zimbra Mobile en dispositivos Android que hacía que no se pudieran enviar correos con el cliente nativo de HTC, un nuevo sistema de estadísticas mucho más ligero (lamentablemente perdemos tres años de estadísticas con el cambio), mejoras en la interfaz web (estándar, extendida y móvil), mejoras en el conector de Outlook para gestión de permisos, y muchos, muchos bugs solucionados.
Se echa en falta mi eterna petición de "firma corporativa" o "disclaimer corporativo", lo cual odio pero es motivo de queja constante por parte de algún departamento de la empresa.

Ah, la migración del sistema operativo a Ubuntu LTS 10.04 para más adelante, dado que el soporte para 10.04 LTS por parte de Zimbra todavía está en beta. ;)

Una larga temporada apagado pero seguimos mejorando.

En los últimos meses apenas he escrito entradas en el blog. Y es que ciertamente cuando uno es padre por segunda vez le queda poco tiempo libre que dedicar a este tipo de historias. Obviamente, en el trabajo hemos seguido adelante con mogollón de proyectos interesantes que podrían haber dado para escribir varias entradas. Pero como tampoco ahora mismo tengo tiempo, me limitaré a enumerar las cosas más importantes durante todo este tiempo:

- Proyecto de virtualización: Hemos acometido un importante proyecto de virtualización de todo el entorno de producción. En el mes de Marzo pusimos a funcionar un entorno Vmware vSphere 4 sobre micros Intel Xeon 55XX (Nehalem) que nos ha facilitado y mucho la vida.
El sistema se compone de dos servidores Dell Poweredege R610 con 32GB de memoria RAM, dos micros quad core cada uno, y una cabina Dell Equalogic PS4000 con unos 4TB de espacio de almacenamiento en RAID10. Para completar, un Dell Poweredge R410 con vmware vCenter como sistema de control centralizado.
Durante este tiempo se han ido consolidando en este entorno los diferentes servidores de producción: herramientas de gestión de proyectos (gForge), gestión de facturación, contabilidad, intranet, servidor de VoIP (de backup), controlador de dominio SAMBA/CIFS, parte de la web pública, Team Foundation Server, proxies reversos, servidor de Bussiness Inteligence (Pentaho) y multitud de servicios accesorios que se repartían por un elenco de servidores.
A día de hoy únicamente nos queda por virtualizar el servidor de correo electrónico (Zimbra) y el servidor de gestor documental (Xerox Docushare) los cuales han sido pospuestos por los requerimientos de espacio que implican que una conversión "physical to virtual" llevaría demasiado tiempo. En algún momento se abordará.
El sistema ha sido recientemente actualizado a vSphere 4.1, que entre otras mejoras aporta memoria comprimida en las distintas máquinas virtuales, lo cual redunda en una óptima gestión de los recursos. En nuestro caso el uso de CPU no es el problema, así que el sistema no ha notado merma alguna en cuanto a rendimiento.
En lo referente precisamente a este último aspecto, la respuesta a la pregunta que muchos se hacen es NO, NO HEMOS NOTADO MERMA ALGUNA EN EL RENDIMIENTO AL VIRTUALIZAR. Es más, el rendimiento es muy superior a lo existente, por cuanto que el sistema de almacenamiento en SAN y la potencia de las máquinas físicas que componen el entorno es muy superior al hardware que reemplaza.

- Nuevo sistema de VPNs. Hemos mejorado el sistema de VPNs reemplazando un viejo Cisco VPN Concentrator 3000 por un flamante Cisco ASA5510. Los problemas recurrentes con la estabilidad de las conexiones IPSec nos forzaron a reemplazar el equipo original.

- Actualización a Zimbra 6.

- Incremento de la capacidad de nuestras líneas de comunicaciones con los diferentes centros y creación de VPNs especializadas con diferenciación por servicio (VPN, red interna, red de cliente).

Red y Libertad

Los internautas consideramos imprescindible la retirada de la disposición final primera de la Ley de Economía Sostenible por los siguientes motivos:

1) Viola los derechos constitucionales en los que se ha de basar un estado democrático en especial la presunción de inocencia, libertad de expresión, privacidad, inviolabilidad domiciliaria, tutela judicial efectiva, libertad de mercado, protección de consumidoras y consumidores, entre otros.

2) Genera para la Internet un estado de excepción en el cual la ciudadanía será tratada mediante procedimientos administrativos sumarísimos reservados por la Audiencia Nacional a narcotraficantes y terroristas.

3) Establece un procedimiento punitivo “a la carta” para casos en los que los tribunales ya han manifestado que no constituían delito, implicando incluso la necesidad de modificar al menos 4 leyes, una de ellas orgánica. Esto conlleva un cambio radical en el sistema jurídico y una fuente de inseguridad para el sector de las TIC (Tecnología de la Información y la Comunicación). Recordamos, en este sentido, que el intercambio de conocimiento y cultura en la red es un motor económico importante para salir de la crisis como se ha demostrado ampliamente.

4) Los mecanismos preventivos urgentes de los que dispone la ley y la judicatura son para proteger a toda ciudadanía frente a riesgos tan graves como los que afectan a la salud pública. El gobierno pretende utilizar estos mismos mecanismos de protección global para beneficiar intereses particulares frente a la ciudadanía. Además la normativa introducirá el concepto de “lucro indirecto”, es decir: a mí me pueden cerrar el blog porque “promociono” a uno que “promociona” a otro que vincula a un tercero que hace negocios presuntamente ilícitos.

5) Recordamos que la propiedad intelectual no es un derecho fundamental contrariamente a las declaraciones del Ministro de Justicia, Francisco Caamaño. Lo que es un derecho fundamental es el derecho a la producción literaria y artística.

6) De acuerdo con las declaraciones de la Ministra de Cultura, esta disposición se utilizará exclusivamente para cerrar 200 webs que presuntamente están atentando contra los derechos de autor. Entendemos que si éste es el objetivo de la disposición, no es necesaria, ya que con la legislación actual existen procedimientos que permiten actuar contra webs, incluso con medidas cautelares, cuando presuntamente se esté incumpliendo la legalidad. Por lo que no queda sino recelar de las verdaderas intenciones que la motivan ya que lo único que añade a la legislación actual es el hecho de dejar la ciudadanía en una situación de grave indefensión jurídica en el entorno digital.

7) Finalmente consideramos que la propuesta del gobierno no sólo es un despilfarro de recursos sino que será absolutamente ineficaz en sus presuntos propósitos y deja patente la absoluta incapacidad por parte del ejecutivo de entender los tiempos y motores de la Era Digital.

Papá por segunda vez

Ayer día 1, a las 8:50 de la mañana nació mi segundo peque, Diego, con un peso de 2.750kg y 50 centímetros de "altura".
Es un bichín muy salao con carita de pillo que está todo el día durmiendo y acurrucado con su mami.
A ver si nos sale al menos la mitad de bueno que su hermano mayor, David. ;-D

Añadir filtro de ADs a Google Chrome / Chromium

Con la llegada de las extensiones, llega igualmente la posibilidad de bloquear ADs de forma sencilla (antes había extensiones "de andar por casa" que no funcionaban demasiado bien).

En principio instalando AdBlock para Google Chrome tendremos ya disponible la extensión, pero habrá que configurarla.

Podemos activar easylist (altamente recomendado)... pero echamos en falta nuestros filtros preferidos que son los de "Filtros Nauscópicos", especializados en webs en habla castellana.

Para añadirlos solo tenemos que hacer lo siguiente.

Editamos el fichero options.html ubicado en nuestro home, dentro de

/.config/chromium/Default/Extensions/gighmmpiobklfepjocnamgkkbiglidom/1.2.22

e inmediatamente de easylist Romanian añadimos lo siguiente:

"easylist_spanish": {

url: "http://s3.amazonaws.com/lcp/maty/myfiles/AdBlock-Nauscopio-maty.txt",

label: " - addittional Spanish filters"

},

... quedando la cosa tal que así...

"easylist_romanian": {

url: "http://www.picpoc.ro/menetzrolist.txt",

label: " - additional Romanian filters"

},

"easylist_spanish": {

url: "http://s3.amazonaws.com/lcp/maty/myfiles/AdBlock-Nauscopio-maty.txt",

label: " - addittional Spanish filters"

},

"adblock_chinalist": {

url:"http://adblock-chinalist.googlecode.com/svn/trunk/adblock.txt",

Por fin extensiones para Google Chrome / Chromium

Finalmente Google ya tiene disponible en su repositorio la tan añorada biblioteca de extensiones que tango echamos de menos los usuarios de Firefox y razón por la cual no nos hemos pasado a usar Google Chrome / Chromium definitivamente (la velocidad es sustancialmente superior a Firefox 3.5).

Es muy sencillo... simplemente hemos de ir al icono de Herramientas / Extensiones y tendremos a nuestra disposición todas las extensiones publicadas hasta la fecha, entre ellas la integración con Gmail, Google Wave, Google Reader, Facebook, ebay, etc, etc... además de mi añorado Adblock.

Punto para Google (otro más).

Primeras impresiones sobre Android

Esta semana he conseguido de nuestro proveedor habitual un teléfono HTC Hero para poder echarle un vistazo en serio a Android. Este teléfono viene con un Android 1.5, a la espera de Android 2.0 que se espera para finales de año.

¿Impresiones? Pues ciertamente IMPRESIONANTE. Hasta la fecha había hecho uso de smartphones basados en Windows Mobile 5 y 6, y ciertamente la diferencia con respecto a Android es espectacular. Cierto es que los operadores tienden a sobrecargar de aplicaciones absurdas y widgets inútiles sus smartphones, y en el caso de los HTC Diamond, por poner un caso, es realmente terrible. Pero incluso cambiando la ROM por una tuneada (que va mucho mejor que la original), al lado de este HTC Hero con Android palidecen.

Por un lado el rendimiento. No tiene absolutamente nada que ver. La fluidez de la interfaz, la velocidad de respuesta. Es otro mundo. Nada que enviar a los iPhone.

Por otro lado la interfaz. Clara, usable y muy lograda. Y eso que todavía pueden pulirlo más.

En cuanto al elenco de aplicaciones, a pesar de que el marketplace de Android todavía está lejos de la AppStore, las aplicaciones que empiezan a aparecer son muy curiosas. Lectores de código de barras, compresores, terminales de consola, etc, etc. Y todo lo que viene detrás.

Sobre trasteo del teléfono, he aprovechado para cambiarle la RADIO (firmware para GPS, 3G, batería, etc) y actualizar a una ROM más moderna de la propia HTC. Pero realmente el SDK de Android te permite hacer cualquier cosa con el teléfono, pudiendo logarte por consola y trabajar contra el linux que subyace como si de tu propio ordenador se tratara.

En fin, que la experiencia ha sido gratificante y por fin me libro de los ladrillos basados en Windows Mobile. No sé cómo será la versión 6.5... pero Microsoft como siga así lo tiene crudo.

Ah, como no todo puede ser bueno, la aplicación de correo que trae este HTC Hero deja un poco que desear. La parte de sincronización con Exchange funciona muy bien, pero tiene una gran pega y es que no sincroniza automáticamente las carpetas de correo. Esto en mi caso es una gran, GRAN pega. Esperemos que sea corregido pronto (la aplicación no es de Android, si no una aplicación externa proporcionada por la propia HTC).

Rendimiento en Drupal (II)

Sobre el tema que ocupaba en el anterior post, continuamos.

El site se diseñó sobre Drupal 5.x, el cual aunque tiene importantes mejoras de rendimiento sobre las versiones 4.x, no llega a lo que puede dar de sí 6.x o incluso la 7.x, actualmente en desarrollo.

Es por ello que tuvimos que implementar una serie de mecanismos para reducir el impacto sobre el hardware disponible. Estos fueron los mecanismos implementados.

- Uso intensivo de memcache. Memcache es un sistema de cachés en RAM, como su nombre indica. Se utilizó para evitar queries masivas sobre la base de datos (mysql). Drupal utiliza la base de datos para prácticamente todo. El ir añadiendo módulos y bloques hace que este uso sea tremendamente intensivo. Esto puede llegar a crear un gran problema. Memcache lo que hace es cachear las queries más habituales en una gran tabla hash, lo que reduce a la mínima expresión (updates e inserts) los accesos a BBDD. El impacto de memcache sobre el site fue brutal, especialmente a nivel de BBDD.

- Uso de las cachés internas de Drupal. Drupal 5.x tiene un sistema propio de cachés. Genera un expires en las páginas, de forma que el usuario que navegue no las recargue cada vez que pase por el site. En 5.x este sistema se limita a eso y poco más. En la versión 6.x se cachea por bloque, lo que produce un importante incremento del rendimiento, pero no así en la 5.x. Además, cada vez que un usuario registrado accede, se limpia la caché. Una lástima. Existen algunos módulos interesantes, como "Advanced Cache" (advcache) que mitiga parte del problema, o Block Cache que fue incluído en Drupal 6.x como caché de bloques. En nuestro caso, utilizamos una versión desarrollada a medida y más flexible de block cache para reducir la carga de site, la cual resultó muy beneficiosa.

- Uso de un proxy reverso. En este caso, squid 2.6. Un sistema de caché reversa puede salvar el pescuezo a cualquiera. Al contrario que la caché interna de Drupal que cachea principalmente objetos, el proxy reverso cachea las páginas renderizadas tal cual, así como los gráficos, css, javascript, etc. Si bien estos últimos apenas suponen carga para el servidor web, sí que implican el uso de procesos, escrituras del log, etc, etc. El cacheo de páginas renderizadas libera realmente al site de producción. En nuestro caso, modificamos drupal para generar dos tipos de URL. Una URL genérica para usuarios anónimos, y una URL con un parámetro para usuarios logados, de forma que el sistema de caché reversa cacheara todos los accesos anónimos (segun drupal indicara en su expires) y liberara de los mismos al servidor. Los usuarios logados seguían cargando (y mucho) el site, pero al menos crawlers, usuarios ocasionales (la gran mayoría) ya no lo hacían.

- PHP eaccelerator. Es un acelerador de PHP. Básicamente lo que hace es almacenar el código PHP ya compilado para que el sistema no tenga que volver a interpretarlo cada vez que una página es invocada. El rendimiento del código se incrementa entre x3 y x5. Hay otros sistemas como APC o Xcache que tienen un impacto similar.

- En MySQL, cambio de MyISAM a InnoDB. Soy poco fan de MySQL y siempre me ha parecido que postgres es un sistema de BBDD mucho más robusto, fiable y serio. Pero es lo que hay. Como estábamos trabajando con MySQL 5, teníamos posibilidad de usar InnoDB en lugar de MyISAM como sistema de almacenaniento. Aunque sobre el papel MyISAM es más rápido a la hora de realizar consultas por su mayor simplicidad, InnoDB es mucho más avanzado por cuanto que no bloquea tablas completas en consultas o updates. En nuestro caso, además, prácticamente no usamos las consultas porque memcache las sirve casi todas, y experimentamos bloqueos por queries un tanto "rudas" contra la BBDD que en algunas ocasiones colgaron el sistema. El paso a InnoDB solucionó este problema. Modificamos algunos puntos del código para eliminar bloqueos explícitos que realiza Drupal 5, pensado para MyISAM, en aras de mejorar el rendimiento, aunque como supondréis mucho, poco incrementó dicho rendimiento habida cuenta de que (otra vez) casi todo se lo come memcache.

Adicionalmente a estas medidas, y como red de seguridad, sugerimos una serie de cambios al proveedor (sí, lo sé, esto no debería haber sucedido jamás, pero el mundo de los sysadmins está lleno de manías y no es fácil decirle a uno lo que tiene que hacer. A todos nos sienta mal que nos lo digan).

- Limitar el número de procesos de Apache (para evitar que el servidor se sature). Mejor hacer esperar al usuario unos segundos encolado, a hacerle esperar para siempre porque nuestro servidor se ha ido a freir monas. Aquí lo ideal es realizar un estudio a grosso modo entre la memoria utilizada por proceso, la memoria de la máquina y la potencia de CPU de la máquina. Esto es, si cada proceso viene a tomar 100MB, tenemos una máquina con 2GB de memoria y un procesador doble núcleo, no parece lógico coger más a allá de 15 procesos en Apache para no quedarnos sin memoria... o sin CPU, si la aplicación es muy intensiva.

- Limitar el número de conexiones a BBDD. Tanto a nivel de gestor como a nivel de php. En este caso, si como máximo vamos a tener 15 procesos, no tiene sentido dar más de 15 conexiones a BBDD. Como siempre, mejor "encolar" que ser "enculados" (no tiene gracia, pero bueno).

Con estos cambios más algunos a nivel de código que realizaron los desarrolladores (desde la parte de administración IT podemos hacer muchas cosas para mitigar, pero a fin de cuentas muchos de los problemas, si no casi todos -que no ha sido en este caso-, se solucionan desde la pantalla del programador) conseguimos que lo que fue una abrupta salida en producción se convirtiera dos días después solo en un problema, y al cabo de dos semanas en un problemilla.

Todavía hay muchas mejoras que se pueden hacer, sobre todo a nivel de cachés de Drupal y optimización de algunos componentes internos, pero a nivel de IT poco más se puede hacer. Y si alguien tiene alguna sugerencia que me la diga, que estoy completamente abierto a nuevos planteamientos.

Rendimiento en Drupal (I)

Recientemente hemos tenido una incidencia en un proyecto basado en Drupal debido a un problema grave de rendimiento. El site es un portal público con un gran número de accesos, y obviamente, al salir a producción emergió este problema.

Normalmente este tipo de situaciones no debería darse si se dimensionan unos benchmarks en condiciones, pero lamentablemente no fue este el caso. Un error muy común a la hora de definir benchmarks es no plantearlos adecuadamente.

Por un lado, hemos de diseñar unos casos lógicos de navegación. De poco basta definir una prueba de carga contra una home si luego la mayor parte de los usuarios se centran en dos o tres páginas concretas. Es importante, así pues, contar con una estadística de accesos al portal previo (caso de una actualización) o con una estimación lo más ajustada posible en caso de una nueva salida. Para este último caso se puede contar con un grupo de usuarios de control que, durante una temporada, hagan uso del portal para así generar un patrón de uso lo más realista posible.

Por otro lado, a la hora de diseñar los patrones de navegación es importante realizar varios patrones diferentes, incluir páginas diferentes en cada uno de esos patrones e incrementar lógicamente el número de hits sobre las páginas que van a ser accedidas con mayor frecuencia.

Todo esto y mucho más se puede realizar perfectamente con Jakarta JMeter.

Finalmente, y para el caso que nos ocupa, en el dimensionamiento de las pruebas, y este fue el GRAN ERROR, no se tuvo en cuenta que no es lo mismo un usuario anónimo que un usuario registrado. Estos últimos, por las características inherentes de Drupal, hacen que se haga flush del sistema de cachés por toda página sobre la que navegas.

El resultado es que aunque los test de carga daban un portal que podría soportar lo que fuera, a la hora de la verdad fue todo lo contrario.

En resúmen, es muy importante plantear y diseñar un sistema de pruebas de carga lo más realista posible a la hora de sacar un site a producción, especialmente cuando son sites sobre los que se va a tener una gran concurrencia.

Chrome en Linux

Hace ya algunos meses que las alphas de Chromium compilan en Linux y más que menos funcionan. Son realmente rápidas, pero además de incluir algunos bugs y funcionalidad sin terminar, no soportan plugins como flash, java y otros.

Si ya de por sí en Linux solemos tener problemas con algunos plugins creados en exclusiva para Windows, que encima los más comunes tampoco se soporten en Chromium hacen que el navegador quede relegado a pruebas o a sites donde queremos velocidad sin importarnos los dibujitos.

Pero esto ha cambiado. Desde hace muy poco, ya podemos igualmente hacer funcionar los plugins sobre Chromium, eso sí, añadiendo algo de inestabilidad al sistema.

Para ello basta con ejecutar Chromium desde línea de comandos:

chromium-browser --enable-plugins

Y automáticamente todo plugin de firefox estará disponible en Chromium (con sus ventajas y desventajas).

Para usuarios de Ubuntu y derivados, tenéis las builds disponibles en lauchpad como de costumbre.

Virtualbox o VMware (player)

Virtualizar es algo realmente útil, especialmente para aquellos como yo que nos encanta trastear y nos vemos en la obligación en muchas ocasiones de utilizar software que no está preparado para funcionar en nuestro sistema operativo favorito (en mi caso, Linux).
Pero una vez puestos, hay que seleccionar el software de virtualización preferente. En mi caso, tras años de trabajar con VMWare, me he encontrado con una grata sorpresa al probar por pura curiosidad VirtualBox 3 de Sun.
VMWare, de siempre, ha contado con su VMWare Server, el cual da unas grandes prestaciones y hasta la fecha me ha servido realmente bien. Con la llegada de la versión 2.0 decidieron abandonar definitivamente la interfaz cliente nativa y se centraron en una interfaz web, dejando por otro lado el producto VMware Client como hasta la fecha.
El problema de VMware server, ahora, es que al levantar un servidor web es bastante más pesado que antaño, y además, este cliente es mucho más lento. Además, para tomar control sobre la máquina nos vemos obligados a usar el Add-on de Vmware para firefox, el cual tiene la peculiaridad de no funcionar sobre FF 3.5, el cual vengo usando en versión beta y RC desde hace meses. En resúmen, VMware orientó su VMWare Server para servidores y su VMWare client (productos separados) para ejecuciones locales. El problema viene con que además, VMWare client no te permite crear virtuales y es incompatible el tenerlo funcionando con VMWare Server, de forma que has de instalar VMware server, crear tu máquina virtual, desinstalar, instalar VMware Client y seguir a partir de este punto. Además ya no podrás tocar dicha máquina salvo que modifiques el .vmx a mano. No podrás crear nuevos discos (vmdk), no tendrás aceleración 3D (no es que me importe pero bueno)... en resúmen, te encontrarás con un producto capado que, aunque para la mayor parte de los mortales es más que suficiente, te obliga a desinstalar e instalar el Server a la hora de crearte una nueva máquina virtual.
La alternativa es VMware Workstation, que te permite hacer todo esto en una única aplicación... pero... hay amigo... es de pago. Y no nos gusta pagar cuando hay alternativas gratuitas y mucho menos piratear que es de mala gente (los que usan Windows y tal) :)

Al probar Sun VirtualBox me encontré con un producto muy similar a VMware Workstation, con un magnífico rendimiento y una consola "nativa" que me permite crear máquinas virtuales, tocar opciones, ejecutar máquinas, parar, reanudar, pasar a pantalla completa, etc, etc al igual que VMware Server en sus versiones 1.X.
Lo único que no trae VirtualBox que si trae VMWare (client) es la posibilidad de lanzar aplicaciones "en ventana" de forma que puedas lanzar, por ejemplo, Office directamente como aplicación en lugar de como máquina al completo, aunque en realidad la máquina virtual se ejecuta al completo pero solo te muestra la aplicación que te interesa. Esto está muy bien para usuarios finales que quieran tener la "sensación" de que están operando una aplicación nativa, pero no deja de ser una curiosidad.
Por otro lado, virtualbox hasta la fecha se me ha revelado bastante más sólido que VMware Server, el cual me colgó en un par de ocasiones la máquina.

Lo dicho. Me he pasado a VirtualBox, si bien para entornos corporativos sigo jugando en la liga de VMware... aunque claro, ESX Server, nada que ver con los productos de "andar por casa" que son VMware client y VMware server.