P>V esta basado en arquitectura cliente servidor, es necesario instalar un agente en el Maestro de tu pool de máquinas y otro en la máquina física a virtualizar. Tras la instalación de los agentes se lanza el asistente de la máquina física a virtualizar donde podremos elegir los discos a virtualizar

El proceso de P2V se ha realizado con la máquina dando servicio  y únicamente ha habido que tocar un par de parametros.

La verdad es que el proceso  ha sido nada problemático

1. Leerse la documentación de Citrix Xenserver Enteprise Edition 4.0 si no se ha hecho nunca.
2. 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.
3. 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.
4. 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.
5. 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
6. 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
7. 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.
8. 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.

Situación 1

Tras repasar una y otra vez la configuración del grub me acordé de /boot/grub/device.map que es un fichero que guarda un mapeo de los dispositivos de bloques, su contenido unicamente posee dos cadenas de texto por linea:

device file

device es un dispositivo especificado en la sintaxis de GRUB (ver Device syntax), y file es un fichero de S.O., normalmente un dispositivo de bloques.

Tras cambiar el dispositivo sda por xvda la máquina arrancó sin problemas.

Situación 2

Aplicando el Caso 1 no mejoraba el problema :S. Quitando los parametros rhgb y quiet del kernel por defecto en el grub me percaté de que estaba cargando el driver de mptsci.. Tras adaptar el fichero modprobe.conf y rehacer el initrd problema resuelto.