Hola amigos, soy Ferran Serafini y hoy os enseñaré a instalar un Ubuntu 10.04 LTS paravirtualizado partiendo de una instalación HVM para nuestro entorno XenServer.

XenServer ya viene preparado para instalar Ubuntu. El método que voy a usar en este post quizá no es el más sencillo y rápido pero podremos ver muchos puntos interesantes y sobretodo la diferencia entre HVM y PV.

Lanzamos “New VM” usando el template “Other Install Media”. La llamaremos Ubuntu-HVM

La seleccionamos de nuestro repositorio de Isos donde previamente hemos descargado la ISO.

De CPU/Memoria se  puede poner lo que uno quiera, por ejemplo 2 CPUs i 512 MB de Ram. Posteriormente creamos su disco duro virtual

Finalizamos la configuración de la máquina virtual y arrancamos la máquina virtual siguiendo el asistente de instalación de una Ubuntu normal.

A modo de consejo personal, prefiero poner la swap en la primera partición del disco, de modo que el sistema este instalado en la ultima partición, así, en el momento que haga falta extender el disco de la maquina virtual por falta de espacio, simplemente haciendo un resize2fs redimensionariamos la partición.

Otro dato muy importante es que pygrub no soporta ahun EXT4, por lo tanto la particion /boot tiene que ser EXT3.

Ya tenemos nuestra Ubuntu 10.04 HVM. Ahora vamos a paravirtualizarla. Para ello, entramos como root y nos “guardamos” algunos datos que necesitaremos para la parametrización siguiente.

Las nuevas versiones de Ubuntu vienen ya con el nuevo grub-pc, accedemos al fichero /boot/grub/grub.cfg y localizamos las siguientes líneas ya que este no es “leíble” para pygrub:

### BEGIN /etc/grub.d/10_linux ###

menuentry ‘Ubuntu, with Linux 2.6.32-33-server’ –class ubuntu –class gnu-linux –class gnu –class os {

recordfail

insmod ext2

set root=’(hd0,1)’

search –no-floppy –fs-uuid –set 115a8cea-b9ac-4ecc-bc2e-3f172630cdc8

linux    /boot/vmlinuz-2.6.32-33-server root=UUID=115a8cea-b9ac-4ecc-bc2e-3f172630cdc8 ro   quiet

initrd   /boot/initrd.img-2.6.32-33-server

Ejecutamos la siguiente línea para especificar que la consola virtual de la maquina sera hvc0 y no tty1 para que podamos usar la consola de la maquina virtual de XenCenter.

sed -e “s/tty1/hvc0/ig” /etc/init/tty1.conf | sudo bash -c ‘cat > /etc/init/hvc0.conf’

Apagamos la máquina virtual.

El siguiente, totalmente opcional, consiste clonar la máquina virtual. Para no confundirnos, la renombramos el clon a Ubuntu-PV.

En el domain0 ejecutamos lo siguiente:

# xe vm-list name-label=Ubuntu-PV

uuid ( RO)           : fce7a414-4475-4875-0af0-632b4a8d6d03

Localizando así el uuid nuestra máquina virtual

# xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 HVM-boot-policy=”"

# xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 HVM-boot-params:”"

Con esto habremos eliminado los parámetros que interpreta XenServer para arrancar la máquina virtual como HVM.

Añadimos ahora los parámetros que vimos en el grub para arrancar  de forma paravirtualizada:

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-args=”root= UUID=115a8cea-b9ac-4ecc-bc2e-3f172630cdc8 ro quiet console=hvc0 xencons=hvc0″

Utilizaremos pygrub para arrancar la máquina virtual:

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-bootloader=pygrub

Como pygrub no es compatible con las nuevas versiones de grub, especificamos el kernel y el ramdisk directamente.

xe vm-param-set uuid=fce7a414-4475-4875-0af0-632b4a8d6d03 PV-bootloader-args=”–kernel=/boot/vmlinuz-2.6.32-33-server –ramdisk=/boot/initrd.img-2.6.32-33-server”

Esta configuración del PV-bootloader-args hay que modificarla cada vez que se cambie/actualice el Kernel de la máquina virtual.

Con esto, arrancamos nuestra máquina virtual y ya la tenemos totalmente paravirtualizada. Vera un incremento de rendimiento muy interesante y estarás aprovechando toda la potencia de Xen. Ahora solo falta instalar las XenTools y convertir como template.

Eso es todo por hoy, espero como siempre, haberte enseñado algo útil para hacerte tu día a día con XenServer más sencillo y eficaz.

¿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, en nuestra sección de Citrix XenServer, veremos más trucos sobre la gestión de discos que ya empezamos la semana pasada. Espero que, como siempre, te resulte interesante.

VBDs a fondo

Vimos que Citrix XenServer es capaz de abstaer el sistema físico de almacenamiento ya sea, SAN, I-SCSI, Storage Link, NFS, etc. De manera que las máquinas virtuales siempre tendrán asociados VBDs y estos hacen de “enlace” con nuestros discos virtuales VDIs.

Eso es muy importante ya que por ejemplo el core de Citrix XenServer utiliza aplicaciones como Pygrub, un grub hecho en python para arrancar los domU (máquinas virtuales) con su propio Kernel. Este, necesita parametros para saber que disco tiene que utilizar para arrancar el sistema. Este parámetro en cuestión es el parámetro “bootable”.

Es común el error: “No bootable device.” Cuando por ejemplo borramos un snapshot que tenia ese parámetro puesto automáticamente.

Sabiendo cual de los VBD->VDI contiene el Kernel de nuestra máquina virtual, simplemente tendríamos que establecer dicho VDB como “bootable” para que el domU arrancara sin problemas:

#xe vbd-param-set uuid=<UUID VBD> bootable=true

Tambien el VDB establece que tipo de disco se presenta (CDRom/Disk), modo (lectura/escritura), dispositivo de la maquina virtual (xvda/ hda) y un largo etc. Os invito a que veais los diferentes parametros en una máquina virtual vuestra con:

# xe vbd-list vm-name-label=<Nombre VM> params=all

Los VBDs tienen tambien comandos extra de gestión como:

• vbd-eject/vbd-insert: Expulsa/inserta un VDI
• vbd-plug/vbd-unplug: Conecta/desconecta un VBD
• xe vbd-create: Como parametro los siguientes flags -> bootable=     device=       mode=         type=         unpluggable=  vdi-uuid=     vm-uuid=
• vbd-destroy: Elimina un VBD por UUID

No olvidemos que el principal objetivo del VBD es el enlace con el VDI. Así que ya podemos saber que VDIs tiene una máquina virtual mediante:

# xe vbd-list vm-name-label=<Nombre VM> params=vdi-name-label

VDIs a fondo

Existen tres típos en función del típo de SR (Storage Repository) que tengamos montado:

• File based VHD: Utiliza thin provisioning y no soporta almacenamiento compartido, solamente es posible usar este típo en SRs de discos locales EXT  o como recurso SR por NFS.

• LVM: La opcón predeterminada de Xenserver. Puede ser por SAN, I-SCSI o SAS. Básicamente los VDIs son representados como volumenes LVM.

• LUN por VDI: Mapeo directo de Luns contra una máquina virtual. Para eso es necesario usar pluguins especificos (NetApp, EqualLogic o StorageLink)

Podemos ver todos los parametros del VDI con:

#xe vdi-list uuid=<UUID-VDI> params=all

También tienen un montón de opciones, espacio virtual, utilización física, sr donde está alojado el vdi, y un largo etc.

Algunos comandos extra para las gestión de VDIs

• vdi-clone: Clona el VDI y lo almacena con un nuevo UUID, nuevo nombre, etc. En el mismo SR
• vdi-copy: Copia el VDI en otro SR
• vdi-import: Importa un VDI desde un fichero exportado con vm-export
• vdi-resize: Reasigna el espacio virtual del disco

Con esto, me despido por hoy, espero que haya podido enseñarte algo nuevo sobre la gestión de discos y como funcionan en XenServer y animarte a que lo veas con tus propias máquinas virtuales.

¿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, soy Miguel Ángel Alonso y aquí estoy como cada martes para hablar contigo sobre un nuevo tema del mundo de la virtualización de sistemas.

En el tema de hoy y como claramente has visto en el encabezado del post te voy a informar sobre un bug que impide realizar vMotion a algunas máquinas creadas con VMware View 5 sobre la plataforma de vSphere 5.0.

Vamos por partes para tenerlo claro, una primera en la que te informo de cuál es el problema y porqué ocurre y otra en la que puedes subsanarlo manualmente de varias maneras.

Error:

Ageneral system error ocurred: Failed to flush checkpoint data!

El error sólo ocurre cuando la versión de nuestro hardware es 8 y las resoluciones de pantalla en nuestros desktops virtuales son  muy altas.

Cuando tenemos activado 3D en nuestros desktops el problema se arregla por un sencillo motivo, y es que al activarlo  nuestros ESXi5 calculan de manera automática la cantidad de buffer necesario para que vMotion se realiza con total éxito. Si no lo utilizamos, tales cálculos no son tomados y nos dará un error cuando se realice un vMotion de estos escritorios, ya sea de manera manual o automática bajo DRS.

Solución:

Hay varias (3 en concreto) que se me ocurran a bote pronto:

1-    Editaremos el fichero config, localizado en /etc/vmware en nuestros ESXi 5 y le añadiremos la siguiente línea:

Migrate.baseCptCacheSize= “16777216”

Con esto se añade en cada fichero vmx de las Vms de nuestro entorno la opción de asegurarse un buffer lo suficientemente grande como para poder realizar el vMotion en caso de necesitarlo para tal fin. Se le asocian 16 MB en lugar de los 8 MB que vienen por defecto.

2-    Otra opción es habilitar como ya he indicado en el apartado de error, el activar 3D para que nos asegure el buffer necesario para la consecución de vMotion.

3-    Otra es ir a la kb de VMware en la que te mostrará otras posibles soluciones para mitigar el error como bajar la resolución a 1280X1024 o inferior, no actualizar las VMs a Hardware 8.

Bueno hasta aquí por hoy.  Espero que te haya gustado y puedas sacar provecho del post si te has encontrado o lo vas a hacer con este problema, y te emplazo hasta la semana que viene para poder seguir  hablando contigo sobre un nuevo tema de la virtualización de sistemas.

¿Crees que este videopost le puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Muchas gracias por tu apoyo.

Esta semana te enseñare a instalar y configurar una cabina SAN iSCSi en la nueva versión de VMware vSphere ESXi 5.0.

Ya esta disponible, en el canal de youtube del blog de virtualización y cloud computing, un nuevo video tutorial sobre la virtualización y el cloud compuitng en español: ¿Cómo instalar y configurar una cabina SAN iSCSI en la nueva versión VMware vSphere ESXi 5.0? Espero que te guste.

Nos vemos el próximo lunes con un próximo episodio donde te enseñare, otro video tutorial sobre la virtualización y el cloud computing.

Gracias a todos los que dejasteis vuestro comentario en los episodios anteriores. Si aun no has tenido la oportunidad de hacerlo, por favor, deja tu comentario abajo en este video.

¿Crees que este videopost le puede interesar a alguien? En ese caso clica en los botones de compartir de arriba o abajo. Muchas gracias por tu apoyo.

¿Que tal? Soy Jose Maria Gris y como cada Miércoles comparto estas páginas virtuales con vosotros.

Hace tiempo publiqué un post (por favor, Jose María) donde teníamos problemas de rendimiento con alguna vmnic. Allí hablábamos como trabajar con herramientas como iperf para ver exactamente que caudal estaba gestionando.

Con la aparición de VMWare vSphere 4.0 y 4.1 han cambiado muchas cosas en este mundillo de las nics y aún me llegan preguntas sobre ellas o bien, cuando estoy en alguna instalación veo que no se han usado los tipos de nic mas adecuados.

Y hoy he creído que sería bueno ver los diferentes modelos de vmnic que hemos movido y para que “sirven” o están planteadas.

Dejo de lado versiones que son “mandatory” para según que clusters y según que combinaciones.

Cito cronológicamente:

Vlance: Vlance es una “Legacy” que tenía su truco. Vlance era una emulación de la AMD 79C970 que su peculiaridad era “to hit de ground running” como los comandos. Esta vmnic empieza a funcionar en cuanto arrancaras la vm tuviera o no las vmwaretools instaladas, eso sí, a 10 Mb, pero conectaba. Al instalar las tools subía a 100 y a 1000 (?).

VMXNET: Este adaptador ya nació virtualizado, pensado para entornos virtuales. Precisaba de las tools. Fue el “abuelo” de las VMXNET actuales.

Flexible: Pues sencillamente eso, Flexible. En cuanto lo arrancabas tenia un comportamiento como una Vlance, al ponerle las tools, se comportaba como una VMXNET

E1000: Emulación de la Intel 82545EM. Personalmente he tenido experiencias no muy satisfactorias con este driver. Mediciones realizadas por mi mismo han dejado la transferencia de este driver muy lejos del Giga.

VMXNET 2 / VMXNET 3: Con vSphere nos llegaron estas vmnics que a mi modo de ver son las que funcionan mejor, incluyendo las ultimas tecnologías de switching. Eso sí, estos tipos tan sólo están soportados por los modernos OS Guest (XP hacia arriba), por lo que no podrán instalarse en entornos Windows 2000. En VMware vSphere 4.1 han sido mejoradas.

Pues con esto me despido 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. 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.

Hola de nuevo. Soy Miguel Ángel Alonso, y aquí estoy como cada martes para hablar sobre un nuevo tema acerca del mundo de la virtualización.

En el día de hoy vamos a hablar de cómo convertir máquinas virtuales de VMware (Workstation o vSphere) a formato XenServer, para ser importadas directamente a nuestros entornos Citrix y listas para trabajar en ellos.

Lo primero de todo será bajarse el v2xva 1.3.4.zip (a fecha de 30-3-2011).

Descomprimimos el zip y copiamos los archivos: v2xva.exe y v2xvadrv.sys a la carpeta de la VM de vmware donde están los vmdk y vmx.

Lo primero de todo y como regla a seguir de lo más aconsejable, es desinstalar las vmware-tools antes de el proceso de conversión.
Arrancamos la línea de comandos con “cmd” y vamos hasta la ruta donde está nuestro archivo v2xva.exe en la carpeta de la VM de VMware y ejecutamos lo siguiente:

Z:\VM_RAWC_Launcher>v2xva.exe /Verbose:Loud /Config:VM_RAWC_Launcher.vmx

Donde:

Z:\VM_RAWC_Launcher = Es la carpeta de la VM de VMware
VM_RAWC_Launcher .vmx = Es el nombre de .vmx de la máquina a convertir
/Verbose:Loud = Sirve para ver el progreso de la conversión, pero se puede omitir si se quiere.
/Config = Parámetro necesario para poder realizar la conversión

Aquí, comienza el proceso de lectura de bloques, sistema operativo y tools de VMware.

Aquí, en este ScreenShot, se puede ver como empieza a escribir los bloques que conformarán finalmente nuestro archivo XVA

Aquí, podemos ver como se crea la carpeta hda con el proceso de conversión y que albergará los archivos temporales de los bloques de la VM y que finalmente conformarán el archivo de Citrix : ova.xml

Aquí, se ven los archivos chunk-00000000X.gz que se forman durante la conversión dentro de nuestra carpeta hda.

Por fin, terminada la conversión, nos creará el archivo ova.xml como podemos ver en el Screenshot de arriba y que importaremos desde Citrix XenCenter a nuestros Servidores XenServer.

Damos en la opción de importar en el servidor de Xen que elijamos e iremos hasta la carpeta donde está nuestro archivo ova.xml seleccionando la versión:
XenServer Virtual Appliance Versión 1 (ova.xml)

Y ya podremos disponer finalmente de nuestra máquina virtual en nuestros XenServer.

Bueno, hasta aquí por hoy. Espero haberte contado algo de vuestro interés y os emplazo hasta la semana que viene con un nuevo tema sobre la virtualización.

Hasta la semana que viene.

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.

Como podréis suponer, sigo a varios gurús y expertos en las tecnologías de la información en general, y de la virtualización en particular, para estar al tanto de lo que se cuece en el mundo tecnológico y cuáles son las tendencias que va marcando el mercado.

Entre las personas a las que sigo relacionadas con la virtualización se encuentra Brian Madden, el cual no hace mucho me ha sorprendido con un post que si bien tiene un título algo incendiario, me ha hecho recapacitar sobre el tema del que trata el post de hoy.

El artículo de Brian, titulado “Why Microsoft hates VDI? ” (“¿Por qué Microsoft odia VDI?”), argumenta los motivos que le (nos) llevan a hacerse (nos) esta contundente pregunta.

Si hacemos una pequeña retrospección en la relación de Microsoft con las tecnologías de virtualización de escritorios, podremos ver que ha sido bastante tardía y cuando ha comenzado esta relación lo ha hecho con modelos de licenciamiento complejos y caros. En este punto en particular resulta curioso como Microsoft opta por ofrecer la licencia que posibilita el acceso por VDI solo para el modelo de Software Assurance, con un coste de 100$ el primer año y de 40$ en las renovaciones sucesivas.

Para aquellos clientes que no quedan cubiertos por el Software Assurance (ThinClients, PCs con Linux, Macs, etc…), Microsoft pone a nuestra disposición las licencias VDA con un coste fijo de 100$ año tras año.

Recientemente Microsoft ha liberado RemoteFX, una tecnología que permite descargar al servidor de las operaciones gráficas al delegar en el cliente las operaciones de renderizado de ventanas y demás, consiguiendo una experiencia de usuario muy superior a la conseguida hasta la fecha y abriendo la puerta a la virtualización de aplicaciones pesadas desde el punto de vista gráfico, como puedan ser las aplicaciones CAD.

Esta tecnología depende de que la máquina virtual Windows 7 esté corriendo sobre Hyper-V, lo que imposibilita que otros jugadores como VMware o Citrix puedan sacar provecho de RemoteFX.

En este sentido resulta interesante el argumento de Brian en el que afirma que Microsoft está apostando por la implementación de RemoteFX en dispositivos como televisores y demás, con lo que, según palabras de Brian, se estaría posibilitando lo que podría ser Xbox en la Cloud.

Sea como fuere, la postura de Microsoft frente a las tecnologías VDI no acaba de quedar clara del todo, o al menos no todo lo alineada con la virtualización de escritorio que nos gustaría que estuviera.

Como siempre en estas cuestiones, el tiempo dirá la última palabra…

Hola amigos, soy Florián Murillo. Cuando utilizamos un mecanismo de balanceo para dar salida a la red a un grupo de VM por mas de un interfaz, nos puede surgir la duda de si el algoritmo nos proporciona el balanceo que buscamos, cuando tenemos muchas VM es mas fácil encontrar la eficiencia en los algoritmos, pero con pocas VM nos puede surgir la duda.

Por suerte tenemos nuestro inseparable amigo esxtop, que con el parámetro n nos indica por que interfaz sale cada una de las VM que tenemos. Veamos un ejemplo:

Tenemos el siguiente port-group:

y la configuración del switch está de la siguiente forma:

Por tanto las VM de port-group “VM Network” saldrán por los interfaces vmnic2 o vmnic3, siendo esto, decidido por el algoritmo escogido, “source MAC hash”.

Emntrando como root en el ESX/ESXi, tecleamos:

# esxtop

y al presentarnos la pantalla de datos, tecleamos “n” que significa network, presentando lo siguiente:

Como podemos observar en la columna USED-BY tenemos una VM llamada vcv01 (última línea) que sale por el vmnic3 (columna TEAM-PNIC).

También tenemos una VM llamada vum01 (penúltima línea) que sale por el interfaz vmnic2.

Para salir solo hemos de teclear “q” y volveremos al prompt.

Espero que os sea útil esta breve información, hasta la semana próxima.