BUG: soft lockup detected on CPU#2!
[<c0441a54>] softlockup_tick+0×96/0xa4
[<c04092a9>] timer_interrupt+0×504/0×557
[<c0441c87>] handle_IRQ_event+0×27/0×51
[<c0441d44>] __do_IRQ+0×93/0xe8
[<c0406d9b>] do_IRQ+0×93/0xae
[<c0541911>] evtchn_do_upcall+0×64/0x9b
[<c0405515>] hypervisor_callback+0x3d/0×48
[<c04084c3>] raw_safe_halt+0x8c/0xaf
[<c040321a>] xen_idle+0×22/0x2e
[<c0403339>] cpu_idle+0×91/0xab
=======================

Preocupado me puse a buscar y encontré esto en un foro:

The soft lockup is technically not a BUG.

You will see these errors if an IRQ takes more then 10 secondsto respond.

Soft lockup messages after suspend/resume or live migration (Red Hat Bugzilla 250994).
These messages are harmless, but there may be a period of inactivity in
the guest during live migration as a result of the lockup.

Así que nada, ya puedo estar tranquilo.

Tras leer(como siempre) he comenzado las primeras migraciones de Citrix Xenserver 4.0.1 a la versión 4.1 y tengo que decir que han sido gratamente satisfactorias.

La nueva versión de Xencenter es compatible con Citrix Xenserver 4.0, permite pasar las máquinas a modo mantenimiento de forma automática(incluso cambiando un maestro por otro), despliegue de parches en masa, permite seleccionar un servidor para arranque por defecto de las máquinas virtuales, reescanear SRs, soporte de USB y se ha mejorado visualmente, al menos eso es lo que he probado por ahora.

xe trae al menos una docena más de comandos, entre ellos el tan esperado(al menos por mi) vdi-snapshot que probaré aunque según la documentación oficial solo es funcional para NetApp.

Las plantillas ha aumentado también consideradamente con lo que el numero de S.O. soportados ha aumentado.

Aún no me he visto en la situación de realizar P2V, así que por ahora no os puedo decir nada.

Me ha gustado mucho Citrix Xenserver 4.1.

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

Lo he descargado y estoy deseando hincarle el diente

xe vbd-create type=CD mode=RO vm-uuid=0aa694c7-f5e1-c11c-9459-6914a749fee6 device=xvdd

El examen  se realiza en un centro Prometic, 40 preguntas y 120 minutos.

Una experiencia diferente estando acostumbrado a los examenes de Red Hat.

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.