He realizado P2V de bastantes máquinas Debian Sarge y Etch a Citrix Xenserver Enterprise Edition 4.0 y visto que no he encontrado demasiada documentación al respecto he decidido comentar el proceso que he seguido:
- Leerse la documentación de Citrix Xenserver Enteprise Edition 4.0 si no se ha hecho nunca.
- Engañar al proceso de P2V para que se inicie pues debian no es un S.O. soportado:
En mis primeros intentos de migración revisé los ficheros que interviene en el proceso de P2V del disco de instalación de Citrix Xenserver Enterprise Edition 4.0 viendo que identificaba las distribuciones por su fichero de versión. Así que para que no de un error con que debian no es una distribución soportada basta con copiar al /etc de la máquina a migrar un fichero de una distribución soportada, yo suelo usar el de una RHEL 4 Update 1. - Paquetes a instalar antes del proceso de migración y que nos ahorrará problemas posteriores:
udev: es el gestor de dispositivos que usa el kernel Linux en su versión 2.6
grub: es un gestor de arranque múltiple
Sin grub nuestra máquina virtual no arrancará y sin udev no reconocerá los dispositivos xvda. - Realizar el P2V de la máquina Debian:
El proceso se realiza normalmente pero no terminará de manera correcta, es normal, recordemos que el P2V de Debian no esta soportado, muy importante: No cancelarlo aunque haya sido erroneo!. Más tarde apagaremos o reiniciaremos la máquina desde la consola(alt+F2) mediante comandos. - Eliminación de VBDs (Virtual Block Devices) erroneos asociados a nuestra máquina virtual si existieran:
Puede que se haya generado algún VBD erroneo en nuestra nueva máquina virtual, el único que deben existir asociado a nuestra máquina es el que se corresponde con xvda, xvda será el único “disco” de nuestra máquina vitual. Podeis usar el comando xe (XenServer command line interface) para ver los VBDs asociados a vuestra máquina virtual y también para destruirlos - Mapeo de los volumenes de nuestra nueva máquina virtual y montaje de los mismos: Es necesario acceder a los ficheros de nuestra nueva máquina virtual para poder adaptar los ficheros de configuración, podemos hacerlos con kpartx y mount. Sería necesario primero identificar el VBDs asociado a nuestra máquina y su VDI, recordemos que podemos obtenerlo a partir de sus VBDs, tras ello:
xe vbd-list vm-name-label=$nombredelamaquina
kpartx -a /dev/VG_XenStorage-xxxx/LV-<vdiuuid>
mount /dev/mapper/LV-vdiuuid /mnt - Cambio de ficheros de configuración e instalación de xentools proporcionado en los discos de instalación de Citrix XenServer Enterprise Edition 4.0 :
Borrar el fichero redhat-release que copiamos en el punto 1 e instalar las xentools en nuestra máquina, la instalación dará algún warning, es normal.
Normalmente sólo tendremos que modificar los ficheros /etc/fstab y /boot/grub/menu.conf, el segundo fichero se debe adaptar pensando en que el único dispositivo de bloques existente es xvda y que la partición raiz es /dev/xvda1. - Arranque de la máquina y últimos pasos:
Tras el paso 6 debemos desmontar(umount) y desmapear(kpartx -d /dev/…) el volumen asociado a nuestra máquina y arrancarla, si se produce algún error volver a revisar los ficheros(puntos 5 y 6), si no se produce ningún error a través de Xencenter o a traves de xe añadir tarjetas de red, modificar tamaño de ram asignada,…
También he encontrado este documento en la base de conocimientos del producto para realizar el proceso, pero nunca lo he utilizado.
En algunos puede que te de un error raro del tipo bzip is corrupted en la máquina virtual(podeis verlo en su consola en xenventer), si esto ocurre al realizar el P2V siempre puedes hacer un tar de los directorios de la máquina original y desempaquetarlo dentro de el volumen de la máquina virtual mapeado.Esto significa que podeis realizar P2V de cualquier máquina que tenga o se le pueda poner un kernel 2.6.
Buen tema Citrix Xenserver Enteprise Edition 4.0. Quisiera instalarlo en una Debian Ethc pero soy nueva en esto y pos no tengo claro como hacerlo. Si me pudieras detallar y enviarlo a mi correo te lo agradeceria mucho.
Lo siento Ariana pero no es lo mismo referirse a Xen a secas que a Citrix Xenserver, del que yo hablo es este: http://www.citrix.com/English/ps2/products/feature.asp?contentID=1297948 y tu te refieres a http://bulma.net/body.phtml?nIdNoticia=2362
Que vaya bien la cosa!
Hola Rafa,
Gracias por compartir tus experiencias.
He leido con detalle lo que comentas sobre la migración a Xenserver de una maquina debian. En mi caso se trata de una maquina centOS5, que tampoco está soportada por el P2V de Xenserver, para instalarla en un Xenserver 4.1.0.
He seguido tus instrucciones y consigo engañar al P2V de Xenserver modificando el fichero redhat-release de la maquina fisica con el de una maquina RHEL4.4 y asi poder crear la clonacion.
La maquina virtual logicamente no arranca, tras lo cual, siguiendo tus instrucciones, consigo acceder al disco de la maquina virtual y modificar el fichero redhat-release y comprobar fstab y mtab. Mi idea era crear un chroot sobre el disco de la maquina virtual y reinstalar grub, pero no lo consigo porque me dice que no existe /dev/xvda1.
Para completar tus instrucciones solamente me falta instalar las xentools. ¿Como monto el Cd para instalar las xentools en la maquina virtual? ¿Supongo que esta instalación hay que hacerla en un entorno chroot no?
Saludos y gracias,
Luciano
No tienes que reinstalar el grub solo modificar su fichero de configuración y no es necesario que lo montes en la máquina, móntalo en otra y copiate el directorio Linux al chroot enviroment, tras eso sh Linux/install.sh y vuelve a revisar el grub por si las moscas.
Ya comentas si con esto pudiste resolver el problemilla.
Hola Rafa,
Eres una máquina
Ya está hecho.
Después de la instalación de las xentools en un entorno chroot tuve que modificar manualmente el menu.lst para indicarle a grub que arrancara con el nuevo kernel de Xen. Luego salimos del chroot, desmontamos y desmapeamos y arrancamos la maquina.
Estaría bien crear un manual detallado de todo esto porque seguro que muchos otros tienen este problema con maquinas virtualizadas.
Muchas gracias por tu ayuda. Cualquier cosa que necesites, estoy a tu disposición.
Saludos,
luciano
Nada, nada las empresas que tienen los problemas que me contraten a buen precio y yo se lo arreglo
.
Hola Rafa,
Una cosilla: cuando haces una copia de una VM en el mismo pool, no se genera un nuevo vdi-uudi, sino que se sigue trabajando con el que ya existía en la maquina copiada. Por ello no funciona el método de acceso a los ficheros de la maquina copiada que comentas, al no existir el PV-vdi-uuid.
Mi objetivo es ahora modificar la maquina virtualizada previamente con el P2V, actualizando el software. ¿Tiene sentido actualizar el kernel si ya lo hemos instalado a partir del CD de las Xentools? Te lo comento porque al actualizar el kernel, la maquina copiada no vuelve a arrancar y no consigo acceder a sus ficheros utilizando tu metodo porque no se crea un nuevo vdi-uuid para la maquina copiada, sino que solo existe el viejo vdi-uuid de la maquina virtual creada con el P2V.
¿Que diferencias existen entre vdi-copy y vdi-clone? Casi no hay documentación sobre ello.
Saludos y gracias de nuevo,
Luciano
Buenas Luciano:
Puedes consultar lo que me preguntas en http://docs.xensource.com/XenServer/4.1.0/1.0/en_gb/reference.html#cli-xe-commands_vdi.
Seguramente al actualizar el kernel te ha vuelto a modificar el menu.lst, prueba a quitar el vdi a modificar con la máquina apagada y a presentarselo a otra máquina, de esta manera podrás montar la partición sin problemas y modificarla a tu antojo.
En linux se puede se pueden añadir y quitar VDIs en caliente que no esten en uso por el SO. de la máquina virtual.
Un saludo Luciano
Hola,
Gracias por la ayuda.
Finalmente lo que he hecho es borrar la maquina virtual clonada con el P2V y volver a importarla. He actualizado el software excepto el kernel y todo funciona bien.
Me ha surgido una curiosidad respecto al almacenamiento y no consigo resolverla googleando: los datos de la maquina virtual clonada con el P2V ocupan 40 gigas. Luego borro 35 gigas de datos que ya no necesito y hago una exportacion de esta maquina a un disco duro externo con la herramienta “Export as backup” del Xencenter.
Curiosamente, la maquina exportada ocupa 40 gigas en lugar de 5. Por lo que he leido en Vmware pasa algo parecido ( http://www.rtfm-ed.co.uk/?p=40 ), aunque sobre Xen no encuentro documentación.
Cuando arrancas esta misma maquina virtual importada en otro host, el sistema operativo de la maquina virtual solo ve los 5 gigas, aunque la importación tarda lo suyo porque finalmente se transfieren los 40 gigas.
Es como si los datos no quedaran completamente borrados del disco de la maquina virtual, aunque a nivel de sistema operativo sí se aprecia el cambio de tamaño.
Lo comento más que nada porque la exportación e importación de las máquinas es muy lenta al transferir 40 gigas en lugar de 5.
¿Te ha ocurrido esto alguna vez? ¿Habrá que utilizar algún comando especial para deshechar los datos borrados por el sistema operativo del disco de la maquina virtual?
Saludos y gracias de nuevo,
Luciano
Pues la verdad que mis vm-export ocupan el espacio que hay ocupado en sistema operativo, no me ha pasado ningún caso como el tuyo la verdad.
Hola Rafa,
Rellenando con ceros todo el espacio libre del disco duro virtual, he consegido reducir el fichero de exportacion de Xenserver en 10 Gigas, de 43 a 33, pero esta todavía no es la solución porque la maquina virtual exportada debería ocupar unos 5 o 6 gigas como maximo.
´
Para rellenar todo el espacio libre del disco con ceros:
dd if=/dev/zero of=junk
sync
rm junk
Cuidado porque el disco se queda completamente lleno hasta que borras el fichero “junk” por lo que si hay bases de datos se pueden perder datos en esta operación.
¿Habrá que borrar el espacio de almacenamiento del Xenserver donde reside la maquina virtual y volver a crearlo? Creo haber leido en algún sitio que aunque borres las entradas de la base de datos de Xenserver los datos de la maquina virtual permanecen. Creo que se hacía con el parametro “forget”.
Saludos,
Luciano
Hola, esto lo intenté realizar con un Fedora Core6, modificando el archivo donde indica la release, y tengo una duda.
La conversión que tú haz realizado es con sobre un sistema linux con particiones para /, /usr, /boot, /var, /etc…. ? o __sólo___ una partición / ?
La prueba que realicé fue con múltiples particiones y el proceso de conversión con Citrix Xenserver 5 sólo migró la partición / y no el resto.
Has tenido alguna experiencia realizando p2v con un sistema linux con más de una partición.
Espero puedas responder.
Saludos.
Michael.-
Pues he hecho los dos, pero en algunos casos con determinadas máquinas me vi obligado a realizar un tar de ciertas particiones con la máquina en init 1 y desplegarlos posteriormente en la máquina virtualizada de manera previa al arranque.
Para que te quedes más tranquilo puedo decirte que los dos servidores que virtualicé usando este rodeo están dando servicio en producción actualmente.
Hola
Estuve viendo la informacion que dejaste y realemente es muy buena. En este momento estoy realizando mi primera migracion de p2v de una maquina linux rhel 4.8 a una maquina virtual por medio del XenServer 5. Pero he tenido problemas, lo maximo que he podido llegar es luego de bootear con el disco del xenserver y ingresar la direccion IP de la maquina fisica y la direccion del hypervisor, el user de acceso del Hypervisor y selecciono la unidad de disco que utlizará. Luego de eso me sale que la version de mi sistema no esta soportado y me pide dar “enter” para reiniciar.
Por lo que lei, tengo que engañar al XenSever que mi linux es un RHEL 4.1, y realice este procedimiento modificando el nombre de mi archivo cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 3).
Pero me sigue dando el mismo mensaje.
Me puedes orientar como puedo enganñar al XenServer 5 para realizar mi proceso de migracion de p2v de mi maquina RHEL 4.8 a una maquina virtual.
Saludos y gracias
Hola,
Tengo la misma duda que Gabriel
Ya he encontrado una manera mas manual de hacerlo.
Gracias
En estos momentos no trabajo con Citrix Xenserver, pero parece que en el parche 5.5 si está soportado el p2v de máquinas Red Hat 4.X:
Secci?o 4.10.4.2. en http://docs.vmd.citrix.com/XenServer/5.5.0/1.0/en_gb/guest.html#linux_guests
Ya me contareis!