Hola amigos, hoy voy a repasar el Webinar de Citrix de la semana pasada, “XenServer 6.0 Technical Master Class” con Lee Bushen y Steve Benton ya que fue muy constructivo y creo que puede ser de vuestro interés.

Podéis descargarlos el material desde:

https://citrix.sharefile.com/d/sa724d4cc19543f8b

En el primer cuarto de hora se pudo ver el funcionamiento interno de XenServer, donde se mostró de una forma muy gráfica [PAG 8 del pdf], los dos “pueblos” que componen este sistema. Por un lado “Xenville” donde vemos “xe”, la XAPI y la “XenServer Pool DB (state.db) y por otro lado la parte “Linux Land”, donde al final, todo lo que interpreta la XAPI, se transforma en ficheros de configuración GNU/LINUX.

Posteriormente se explicó algo que ya hemos hablado en este blog, como XenServer organiza el Storage con sus diferencias y modalidades. SR’s, PBD’s, VBD’s. Una parte muy interesante de esta sección fue cuando explicaron cómo se organizan internamente los snapshots, en función del tipo de almacenamiento que podemos utilizar, NFS y Storage Local, LVMD, iSCSI y FC.

Podemos complementar el PDF con la documentación oficial de Citrix sobre los snapshots: http://support.citrix.com/article/CTX122978

Del mismo modo que el storage, en parte de comunicaciones, se explicó desde el hardware hasta llegar a los dispositivos de red virtuales, el funcionamiento de los bridges y como XenServer utiliza el bonding.

Os dejo también una lista de comandos útiles de Linux y XenServer: https://citrix.sharefile.com/d/s53888bbff9b44949

Y la Network Throughput Guide: http://wiki.xen.org/wiki/Network_Throughput_Guide

En general el Webinar estuvo muy bien. Aplaudo la iniciativa de Citrix y de otras compañías que ofrecen este tipo de seminarios gratuitos para los fans de sus plataformas.

Con esto amigos, nos vemos la semana que viene con la monitorización del storage con Nagios. Aprovecho también para desearos unas felices fiestas a todos.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Esta semana veremos las diferencias entre la virtualización basada en hipervisor y la virtualización basada en host.

La virtualización basada en hipervisor (también denominada Bare-Metal), como por ejemplo vSphere™ ESXi, Microsoft Hyper-V o Citrix XenServer, está instalada en un servidor físico sin la necesidad de que exista un sistema operativo (Windows o Linux) instalado previamente.

No obstante, la virtualización basada en host, como por ejemplo VMware Server, VMware Workstation o VMware Fusion, necesita previamente un sistema operativo instalado, ya sea Microsoft Windows, Mac OS o Linux.

Hay varias razones por las que un cliente elegiría el software de virtualización basado en hipervisor, como por ejemplo vSphere™ ESXi, en lugar de un software de virtualización basado en host, como por ejemplo VMware Server.

• Primero, con el software de virtualización basado en hipervisor, es posible actualizar las máquinas virtuales que se albergan en los servidores físicos sin ningún tipo de downtime.
• Segundo, es muy probable que la empresa ya esté virtualizando varios servidores físicos y quiera tener la opción de tener una gestión centralizada.
• Por último, un hipervisor baremetal siempre ofrece una mayor confiabilidad y rendimiento al no precisar de un sistema operativo Host, con lo cual se elimina un posible punto de fallo.

Aunque la virtualización basada en hipervisor ofrece un mayor rendimiento, es la virtualización basada en host la que ofrece una compatibilidad con el hardware mucho más amplia, es decir, si puedes instalar Windows o Linux en tu servidor físico entonces podrás instalar la solución de virtualización basada en host.

Por consiguiente, una de las mayores diferencias de la solución de virtualización basada en hipervisor y la solución de virtualización basada en host – aparte de las obvias ya mencionadas – , es que esta última tiende a tener una lista de hardware certificado mucha más amplia.

Sin embargo, la virtualización basada en hipervisor tiene un mayor rendimiento, mayor fiabilidad y estabilidad, mayor escalabilidad y mucha más funcionalidad. Para ver más información sobre los tres factores más importantes a la hora de elegir un hipervisor para el software de virtualización entra en este enlace:

Asimismo, y a diferencia de las versiones anteriores a VMware vSphere™ ESXi,  las variables memoria reservada y memoria configurada (Reserved Memory y Configured Memory) afectan al incremento o reducción del memory overhead, el cual es una “penalización” a nivel de la capa de memoria que todos tenemos que pagar por el simple hecho de virtualizar nuestro servidor físico. Esta penalización se mide en megas de memoria RAM y son megas de memoria que dejamos de ver y de usar en nuestro servidor físico.

Como consecuencia de este “impuesto revolucionario” que existía por el simple hecho de virtualizar nuestro servidor, VMware vSphere™ ESXi 5 usa una nueva funcionalidad llamada VMX swap con la que es posible reducir el memory overhead de tus máquinas virtuales. Puedes ver un video tutorial sobre el Memory Overcommit en VMware vSphere 5 en este enlace.

Básicamente, con esta nueva tecnología llamada VMX swap, el tamaño del memory overhead se crea en un fichero swap con lo que este espacio de memoria puede llegar a ser reutilizado por el hipervisor. Esta técnica posibilita un aumento en el ratio de consolidación de VMware vSphere™ 5 con respecto a versiones anteriores para soluciones de virtualización basados en hipervisor.

¿Crees que este post le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hola amigos, soy Florián Murillo. Con vSphere 5 nos llega la entrada de vCenter Server al mundo Linux.

La llegada de vCenter Server es en formato OVF, lo que simplifica enormemente la instalación.

Descripción del producto:

La máquina virtual desplegada tiene SUSE Enterprise Linux 11 x64 con 2 vCPUs, 8 GB de RAM y dos discos, uno de 15GB y otro de 60GB.

Incluye:
• Base de datos DB2 Express embebida
• ESXi Dump Collector
• Syslog server (utiliza syslog-ng)
• Auto Deploy Server

Es la primera versión, tiene cualidades y carencias, vamos a repasarlas:

No soporta:
• Microsoft SQL Server
• vCenter Server Linked Mode
• vCenter Server Heartbeat
• Linked Clone de VMware View Composer
• vSphere Storage Appliance
• IPv6

Algunas limitaciones son inherentes a plataforma Windows.

Si soporta:
• Oracle como base de datos externa
• Integración con Directorio Activo
• SRM5
• vCloud Director
• Update Manager
• vCenter Operations

Con la base de datos embebida podemos gestionar hasta 5 host y 50 máquinas virtuales, es el mismo dimensionamiento del Microsoft SQL Server Express.

Los consumos de memoria del appliance dependen de los host y las máquinas virtuales a gestionar, como pasa en la versión Windows, los requerimientos de RAM son similares en Windows y en Linux.

Aún siendo un producto de “desplegar, configurar y usar” las tareas de explotación del día a día requerirán conocimientos de Linux, no recomendaría su uso si no hay capacidades Linux en la empresa.

Sus puntos fuertes:
• No hay sobrecostes de licencias de Microsoft.
• Se despliega mucho más rápido, sobretodo si necesitamos syslog, dump collector o autodeploy.
• No hay debate acerca de vCenter Server en máquina física o virtual.

A mi modo de ver, es una gran noticia la llegada de este producto, el limitador mas importante es no soportar Microsoft SQL Server para gestionar mas de 5 hosts. Pero intuyo que veremos evolucionar el producto en sucesivas actualizaciones.

¿Creéis que vCenter Server Appliance se implantará masivamente?

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Gracias por el apoyo.

Hola amigos, soy Florián Murillo. Hoy estoy nostálgico, me he puesto a recordar la historia de VMware y la evolución de Elastic Sky X, hace tanto tiempo que lo nombramos por sus siglas (ESX) que nos hemos olvidado de su nombre ¿verdad?

¿Cuales son, según mi opinión, las mejores características de cada versión de ESX?

En 2001 nació la versión 1 y para mi, la mejor característica que tuvo fue nacer, y aportar una forma diferente y atrevida de entender el concepto de las TI en las empresas (entornos x86). ¿Cómo sería el mundo de las TI hoy si no hubiera aparecido ESX v.1? ¿Estaríamos hablando de cloud ahora? ¿Habría energía eléctrica en los DataCenters para alimentar a todos los servidores? y… ¿Donde alojaríamos tantos servidores?

En 2003 se lanza la versión 2 y como grandes novedades, vMotion y VirtualCenter. Aún era un producto para expertos en Linux, se hacían mas tareas con CLI que con VirtualCenter, pero había nacido con VirtualCenter la Gestión de las Infraestructuras Virtuales. VMware empezaba a mejorar, tímidamente, los negocio, con su producto.

El año 2006 nace la versión 3 y se produce un antes y un después en esta tecnología. Como gran novedad aportó VMware HA, aún recuerdo ese año evangelizando a clientes reunidos en hoteles, un mes si y otro también hablándoles de vMotion y VMware HA, era increíble como les explicabas lo que hacia el producto y no se inmutaban, en el momento que te conectabas a un CPD en producción y se lo enseñaban en vivo y en directo, no les cabían los ojos en las órbitas ¿tan mal me explico?. Era fascinante saber que hacías una presentación y triunfabas, gracias VMware.

El año 2009 se presenta en sociedad la versión 4, aquí discrepo de VMware acerca de cual es la gran mejora de esta versión (ellos dicen que es VMware FT) para mi es Storage vMotion, nos proporciona escalabilidad y disponibilidad y para mi, en segunda posición: La visión de VMware para abrir su producto con APIs de todo tipo. Algunas de ellas son la vNetwork Appliance API, la Pluggable Storage Architecture o la vStorage API for Data Protection.

Con estas incorporaciones, poco visibles a priori, se garantiza la evolución el producto, son soluciones propias o de otros fabricante. Las APIs permiten liberar la creatividad sin el freno de las limitaciones tecnológicas. La prueba de ello es que gracias a estas APIs han seguido deslumbrando en la versión 4.1 con Storage I/O Control, Network I/O Control o VAAI.

¿Cuál crees tu que son las mejores aportaciones de cada nueva versión?

¿Crees que este post puede interesar a alguien? En ese caso clica en los botones de compartir de arriba. Gracias por el apoyo.

Hola, soy Miguel Ángel Alonso y aquí estoy contigo para contarte algo nuevo sobre el tema de la virtualización.

Hoy, y alejándome un poco de los temas anteriores sobre la virtualización que comente las semanas pasadas con Hyper-V, vamos a ver la puesta en escena a grandes rasgos de un software maravilloso para la gestión y creación de entornos de escritorios virtualizados de Microsoft y, muy particularmente, en Linux.

Esta solución viene avalada por la empresa Virtual Bridges y más en concreto con su solución llamada VERDE VDI (5.1 Sp1). Por cierto, el nombre de Verde viene de las sigulas en ingles Virtual Enterprise Remote Desktop Environment.

A continuación, te mostrare los requisitos y sistemas operativos compatibles con este genial producto para poder llevar a buen puerto tan magnífica solución. Pero antes de continuar, quisiera dar las gracias a Dan Perlman – VP of Business Development for Virtual Bridges – por su interés y facilidades para poder probar el producto.

Protocolos de conexión

NX: Protocolo exclusivo para desktops LINUX con seguridad basada en SSH. Trabaja muy bien en redes LAN y Wan de baja latencia.
RDP: Remote Desktop Protocol para nuestros escritorios Windows.
SPICE: Protocolo común tanto para Linux como para Windows en redes LAN y WAN con alta latencia (Multimedia, Bidireccinal) donde se delega la carga de CPU entre las GPU de los clientes y servidores HOST que haya en la infraestructura. Es el más utilizado por su excelencia y el que mas uso en mis laboratorios sin ninguna discusión.

Aquí podéis observar una infraestructura completa de VERDE:

• Cliente tanto por ejecutable como por WEB-Browser
• El agente del escritorio
• Cluster de Servidores VERDE (basados en Hypervisor KVM de RED HAT)
• VERDE Leaf (Escritorios OFF-LINE) como el MODO LOCAL de VMware View o el Xen CLient de Citrix
• Integración con Active Directory  mediante la instalación de LIKEWISE 6.1 (producto opensource gratuito)
• Y Consola de gestión para la creación de Imágenes GOLD y desarrollo de escritorios con tecnología de deduplicación y, además,  gestor de usuarios y permisos

Requisitos para la instalación:

1. Red Hat Enterprise 5x, 6x (64 bit)
2. Suse Linux Enterprise 11 SP1 o superior (64 bit)
3. Ubuntu 10.04 LTS (64 bit)
4. Habilitar Intel VT o AMD-V en la BIOS de nuestros Hosts
5. Java Runtime Environment (JRE) and Ghostscript
6. Likewise Open versión 6
7. Instalación de paquetes individuales para cada uno de los tres S.O. de Linux que hemos descrito anteriormente y que vienen reflejados muy claramente en la guía de instalación de VERDE 5 SP1

Plataformas de Escritorios Soportados para virtualizar

Windows:

• Windows XP 32-bit (accelerated SPICE or RDP access)
• Windows 7 32-bit (accelerated SPICE or RDP access)
• Windows 7 64-bit

Linux:

• RHEL/CentOS 5.4 32- or 64-bit (NX access only)
• RHEL/CentOS 5.5 32- or 64-bit (NX access only)
• RHEL 6 Workstation, and CentOS 6 when it comes out, 32- or 64-bit (accelerated SPICE or NX)
• Fedora 14 (32- or 64 bit, NX and SPICE)
• Ubuntu 10.04 (NX support only)

Plataformas de cliente soportadas

1. Windows XP/Vista/7/2003/2008 32 or 64-bit
2. 64-bit Linux, Ubuntu 10.04 LTS, or RHEL 6 Workstation (or CentOS 6 when it comes out)
3. Mac (for RDP/NX only)
4. Thin clients (Java required, must be able to install VERDE tools)
5. iPad (RDP only) .

Finalmente os dejo una imagen de cómo están organizados los Hosts y partnerts estratégicos de Virtual Bridges en la instalación de su entorno:

Bueno amigos. Hasta aquí por hoy. Como siempre, me despido de t,i esperando haberte contado algo nuevo de interés, hasta la semana que viene.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Queridos lectores,

El kernel de Ubuntu 10.04 tiene un bug que afecta al SMP cuando está corriendo sobre un Hypervisor de Xen.

Este bug afecta tanto a máquinas virtuales de 32bits como de 64 bits.

Como posible solución a este nuevo bug, Citrix recomienda actualizar el kernel de Ubuntu.

A continuación, paso a detallaros los pasos necesarios para corregir este bug en el kernel de Ubuntu 10.04 sobre XenServer:

• apt-get install python-software-properties
• add-apt-repository ppa:kernel-ppa/ppa
• apt-get update
• apt-get install linux-headers-generic-pae-lts-backport-natty linux-image-generic-pae-lts-backport-natty
• echo xen_blkfront >> /etc/initramfs-tools/modules
• update-initramfs -c -k all
• reboot

Para mas información os dejo un enlace de la referencia de ubuntu a dicho bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/681083

Esto es todo. Como siempre espero que os sea de utilidad.

¿Crees que este artículo puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter y Facebook de abajo o arriba. Gracias.

Queridos lectores,

El el post de hoy explicaré como añadir la configuración del Proxy de nuestra red para que XenServer nos permita hacer una instalación de una Máquina Virtual desde un Repositorio URL.

Seguro que mas de uno se ha encontrado con este típico error a la hora de crear una nueva máquina virtual Linux.

Uno de los posibles fallos sin lugar a dudas, es que no hemos introducido bien la URL de la distribución Linux desde donde queremos descargar para proceder con la instalación.

Pero en otros casos es posible que estemos intentando hacer la instalación desde detrás de un proxy.

Para introducir la configuración del proxy lo haremos de la siguiente manera:

1.- Dentro del servidor XenXerver nos vamos a la ruta:

cd /usr/bin

2.- Editamos el fichero “eliloader”

vi eliloader

3.- Añadimos la línea donde aparecen los datos de conexion de nuestro proxy:

os.environ['http_proxy'] = “http://192.168.0.99:3128″

A partir de ahora seguro que no nos volverá a salir el error de no encontrar la fuente de instalación. Como siempre espero que sea de utilidad.

Queridos lectores,

Al igual que hice hace ya tiempo en un post anteriror, donde explique como redimensionar un disco de una VM Windows cuando me quedo sin espacio, hoy lo haré para una máquina virtual linux.

Cabe señalar que para el siguiente ejemplo lo haremos sobre una partición ext3 y sobre una máquina virtual que trabaja en runlevel3, es decir no disponemos de entorno gráfico. Y esto último lo digo porque en distribuciones como Ubuntu o OpenSuse llevan utilidades en modo GUI desde las cuales puedes redimensionar los discos.

1.- Incrementaremos desde la consola de Citrix XenCenter el tamaño del disco de la VM que queremos aumentar, para poder hacer esto la VM tiene que estar apagada:

2.- Desatachamos el disco:

3.- Nos descargamos la ultima versión del liveCD de GParted y la guardamos en el repositorio ISO.

4.- Creamos una nueva máquina virtual y le decimos que arranque desde la iso que nos hemos descargado:

5.- Antes de finalizar el proceso de creación de la VM desmarcamos la opción que arranque automáticamente al acabar.

6.- Una vez creada, le atachamos el disco que queremos redimensionar:

7.- Arrancamos la VM desde la ISO descargada y desde las utilidades de GParted redimensionamos la partición. Hay que decir que este proceso durará bastante tiempo, dependiendo del tamaño de la partición.

8.- Una vez finalizado, apagamos la máquina virtual y hacemos el proceso inverso. Desatachamos el disco de la máquina temporal y lo
atachamos en su máquina original y con esto tendremos el disco redimensionado a un tamaño mas grande.

Como veis es un proceso sencillo que además podemos hacerlo desde modo GUI que es más fácil e intuitivo. El mismo proceso es posible realizarlo desde comandos CLI e incluso desde la misma máquina local, pero hay que tener en cuenta que al ser una partición ext3 antes de trabajar sobre ella hay que desmontarla primero.

Nada más queridos lectores, me despido hasta la semana que viene, como siempre espero que os sea de utilidad.

Es para mí un placer anunciar, que el Blog de Virtualización en Español, cuenta desde hoy con un nuevo colaborador y especialista del mundo de la Virtualización de Servidores, Microsoft y Linux.

Santi Fernández, como el mismo se denomina, es Consultor/Administrador de sistemas todo-terreno.

Santi Fernández empezó su andadura en los sistemas Unix, con Solaris 8 y 9 desde donde salto al software libre con Linux.

Finalmente, Santi paso al mundo Microsoft y a la virtualización en diversas tecnologías. Ha sido formador de sistemas y seguridad y actualmente desarrolla su trabajo como Consultor Senior de tecnologías Microsoft y VMware en el departamento de I+D de QoS Consulting.

Cada semana, Santi compartirá contigo, mi querido y apreciado lector, la noticia más importante acaecida en el mundo de la virtualización de sistemas.

Muchas gracias Santi por tu más que desinteresada colaboración con el blog y espero y deseo que tengas mucha suerte con nuestros cientos de miles de queridos y apreciados lectores.

Si queremos hacer una instalación de nuestra distribución preferida primero debemos saber si está soportada por nuestra versión de XenServer, mas que nada por si queremos aprovechar los drivers de paravirtualización del mismo.

El listado lo podemos sacar de los manuales de instalación o bien del mismo menú de templates que da XenCenter a la hora de crear una máquina virtual nueva.

Una vez claro que nuestra distribución es soportada y que la tenemos correctamente instalada, nos aparecerá la alerta de “Tools not installed” en la consola central de XenCenter. Pulsaremos con el botón derecho sobre la máquina virtual y le diremos que queremos instalar XenServer Tools:

Acto seguido nos vamos a la consola de nuestro linux y hacemos lo siguiente:

mkdir /mnt/xe-tools
mount /dev/xvdd /mnt/xe-tools
cd /mnt/xe-tools/Linux
bash install.sh
reboot

Esperamos a que reinicie y ya tendremos los drivers de paravirtualización instalados en nuestra distribución Linux. Para comprobarlo poniendo uname -a veremos que la versión del kernel habrá cambiado.

Para terminar recordaros que hoy día 9 de diciembre, tal y como anuncié en otro post, espero veros en el Webinar Delivering Business-Critital Applications with Citrix Xenserver será aproximadamente a las 17:00 hora española.

Saludos y hasta la semana que viene.

Es para mí un placer anunciar, que el Blog de Virtualización en Español, cuenta desde hoy con un nuevo colaborador y especialista del mundo de la Virtualización de Servidores.

Adolfo Muñoz Moratalla, es Director Ejecutivo de Custom Professional Hosting, empresa dedica a la personalización de sistemas de hosting, sistemas de virtualización y alta disponibilidad para hosting.

Adolfo tiene una amplia experiencia en el mundo de la virtualización sobre las plataformas de Virtuozzo, Linux y XenServer, el cual nos aportara, sin lugar a dudas, una gran visión y experiencia sobre dichas tecnologías.

Cada Miércoles, Adolfo compartirá contigo, mi querido y apreciado lector, la noticia mas importante acaecida en el mundo de la virtualización de XenServer & Linux, el truco más revelador en XenServer, aquel artículo que no puedes permitirte el lujo de no leer o aquel hallazgo sobre la tecnóloga de virtualización de XenServer & Linux que nos dejara a todos con la boca abierta.

Muchas gracias Adolfo por tu mas que desinteresada colaboración con el blog y espero y deseo que tengas mucha suerte con nuestros queridos y apreciados lectores. Bienvenido a tu casa.

Al parecer ya es oficial el hecho de que la próxima versión de VirtualCenter en VMware Infrastructure 4.0, al que ya se conoce como vSphere, por fin también estará disponible para servidores Linux.

Una de las sesiones, que no me perderé, del próximo VMworld Europe 2009 en Cannes titulada DC08, confirma tal hecho.

Aquí tienes el link con la descripción de dicha sesión y en donde se menciona el soporte para Linux (requiere login)

Si aun no te has registrado para el VMworld 2009, te adjunto la descripción de la sesión para que lo compruebes por ti mismo.

“Customer demand for vCenter Server running on Linux has been astounding. While the majority of the Code is inherently cross platform, getting vCenter Server to run on Linux in a manner compatible with the current set of features has its own set of challenges. This presentation will discuss the issues of cross platform development for vCenter, including issues regarding internationalization support, database support, multi-vCenter support, and image customization. The talk will conclude with a live demonstration of the latest development version of vCenter Server running on Linux”

Parece ser que la demanda por parte de los clientes de tener una versión de VirtualCenter para Linux ha sido un factor determinante para que VMWare se pusiera a trabajar en ello.

Sera interesante saber cuántos clientes optan implantar la versión de VirtualCenter en Linux vs Windows.

Por fin tendremos una herramienta de migración de físico a virtual (P2V)  que soporte maquinas Linux, concretamente el próximo Vmware Converter 4.0 tendrá soporte para Red Hat, SuSe y Ubuntu.

Puedes suscribirte al programa beta de la herramienta de migración, Converter 4.0 aquí. (Requiere logon)

Para los usuarios que compren VMware ESX Enterprise edition, se encontraran con el  Converter 4.0 embebido en VirtualCenter.  Para aquellos usuarios que no compren la licencia Enterprise, tendrán la opción de utilizar la versión stand-alone Converter 3.0.3, y que puede descargarse aquí.

La semana pasada VMware lanzo su tercera actualización de VirtualCenter.

Se han mejorado y corregido muchas e importantes funcionalidades en HA aunque la mas importante yo diría que es que ahora es posible borrar las opciones avanzadas de HA, opciones que dicho sea de paso fueron introducidas con el update 2.  Suena paradójico, verdad!.

Otro bug que  ha sido solucionado con esta actualización y que fue muy comentado en los foros de VMware, fue el hecho de que las maquinas no se migraran con VMotion cuando se ponía el host en modo mantenimiento, que es lo que realmente debería ocurrir en caso de poner un host en modo mantenimiento.

Para conseguir el update 3 del VirtualCenter 2.5 pincha aquí. (Requiere login)

Como nota final, no olvides que con esta actualización los plugins de Update Manager y VMware Converter también serán actualizados a la última versión.

Lamentablemente el soporte de VMware Converter para conversiones Linux es aun experimental.