Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

Instalación de Sun Solaris en un hosting OVH (Segundo Intento)

Última Actualización: 24 de Julio de 2009 - Viernes

El intento de instalación de Solaris bajo máquina virtual en OVH ha sido desastroso. Mi primera opción era realizar una instalación dual, para poder aprovechar Solaris al máximo y tener el "fallback" de Linux si había problemas serios. Pero dicha instalación no ha tenido éxito, y como no tenemos acceso a la pantalla, no podemos ver la razón.

Pero OVH acaba de añadir soporte KVM real opcional a sus servidores dedicados. Si funciona correctamente, tenemos dos posibilidades:

  • Realizar una instalación nativa de Solaris. Es lo más sencillo, pero ante cualquier incidencia necesitamos disponer del KVM físico. Osea, tenemos que seguir pagando el KVM mes a mes.

  • Instalar un arranque dual, Solaris y Linux. El arranque "normal" sería Solaris y, en caso de problemas serios, podemos arrancar con Linux, arrancar Solaris dentro de una máquina virtual, solucionar el problema y volver a arrancar Solaris de forma nativa. La instalación es más compleja y delicada, pero te permite ahorrarte pagar el KVM de forma permanente.

Voy a intentar completar la segunda opción, pero para las pruebas iniciales tiraré por la primera, que es más rápida y me permite asegurarme de que tengo los drivers de todo, etc.

  • Ya tenemos un Solaris 10 instalado bajo virtualización, ya perfectamente configurado y actualizado a tope. Me interesa conservarlo, así que mi idea es realizar un backup previo y recuperarlo luego:

    • Tenemos 50 gigabytes ocupados. De ellos, 32 gigabytes son de "swapping" (tengo mis motivos para usar tanto Swap) y 8 gigabytes están asignados al "dump" del sistema si hay problemas. Es decir, tenemos en uso solo unos 10 gigabytes de datos reales. Es de señalar que estoy usando las funcionalidades de compresión de ZFS, así que los datos reales ocupan más.

    • En primer lugar, desactivamos el "dumping" del sistema operativo. Para ello lo ideal sería poder escribir "dumpadm -d none", pero ésto no funciona (Solaris 10 Update 7). Hay que borrar el fichero "/etc/dumpadm.conf" (guárdate una copia por si tienes una configuración extraña). Es de esperar que ésto no sea necesario en el futuro.

    • Listamos los atributos del swap: 
      [root@stargate datos]# zfs get all datos/swap
NAME        PROPERTY                 VALUE                    SOURCE
[...]
datos/swap  compressratio            1.58x                    -
datos/swap  reservation              none                     default
datos/swap  volsize                  32G                      -
datos/swap  volblocksize             8K                       -
datos/swap  checksum                 on                       default
datos/swap  compression              on                       inherited from datos
datos/swap  refreservation           32G                      local
[...]

      Obsérverse que se puede usar compresión en el Swap, y que es bastante efectivo.

    • Desactivamos el "swap" en el fichero "/etc/vfstab".

    • Reiniciamos la máquina.

    • Comprobamos que tenemos desactivado el "dump" con "dumpadm". Luego borramos el ZVOL con "zfs destroy datos/dump".

    • Comprobamos que tenemos desactivado el Swap" con "swap -l". Luego borramos el ZVOL con "zfs destroy datos/swap".

    • Hacemos un "snapshot" del "pool" completo: "zfs snapshot -r datos@20090616-19:46".

    • Generamos el "stream" del disco duro completo. Lo comprimimos para que ocupe menos, y porque la CPU es bastante más rápida que los discos duros. Esta operación lleva bastante tiempo, aunque la máquina sigue en servicio durante la misma (es más, cuando termina el volcado completo podemos realizar otro snapshot y generar un "stream" incremental, que será muy rápido, para tenerlo actualizado al 100%). 
      [root@stargate datos]# zfs send -Rv datos@20090616-19:46 | gzip -9c >/z-dump_disco_Solaris.gz
sending from @ to datos@20090604-13:48
sending from @20090604-13:48 to datos@20090616-19:46
sending from @ to datos/ROOT@20090604-13:48
sending from @20090604-13:48 to datos/ROOT@20090616-19:46
sending from @ to datos/ROOT/solaris10u7@20090604-13:48
sending from @20090604-13:48 to datos/ROOT/solaris10u7@20090616-19:46
sending from @ to datos/ROOT/solaris10u7/var@20090604-13:48
sending from @20090604-13:48 to datos/ROOT/solaris10u7/var@20090616-19:46
sending from @ to datos/export@20090616-19:46
sending from @ to datos/export/home@20090616-19:46
sending from @ to datos/usr_local@20090609-19:36
sending from @20090609-19:36 to datos/usr_local@20090616-19:46

      El fichero resultante, comprimido, mide 4.1 gigabytes.

    • Copiamos el volcado a otra máquina. De esta forma podemos toquetear lo que queramos, teniendo una copia de seguridad completa recuperable de forma rápida. Calculamos el SHA1 del fichero de réplica en ambos lados, por si las moscas...

  • Tomamos nota de los datos de red del Host, como su IP, su ruta por defecto, su márcara de red y su servidor DNS.

  • Intentamos hacer una instalación por red, pero la máquina se cuelga si la reiniciamos con el KVM conectado. Ésto limita mucho la utilidad del KVM, especialmente el arranque a desde un DVD remoto. Éste es uno de los muchos problemas que he encontrado a estos KVM, que documentaré más adelante.

    Debido a ésto, me salto la "prueba" inicial que quería hacer e intento ir directamente al arranque dual.

  • Realizamos una instalación linux normal y corriente, e instalamos una máquina virtual Solaris sobre él. Los detalles son prácticamente idénticos a mi intento previo, así que no voy a justificar nuevamente por qué hago cada cosa, ni los comandos exactos utilizados. Los detalles están en la página de mi intento anterior.

    • Instalo Ubuntu 8.04 LTS 64 bits. Uso el particionado por defecto.

    • Elimino las puertas traseras de OVH.

    • Actualizo el sistema a la última versión.

    • Instalo el arranque vía GRUB.

    • Instalamos el kernel oficial de Ubuntu, en vez de la versión modificada de OVH.

    • Instalamos VirtualBox.

    • Cambiamos la estructura de particiones, swap, etc.

    • Realizamos una instalación mínima de Solaris, para hacer pruebas.

    • Reconfiguramos el sistema de arranque para que arranque Solaris de forma nativa. Ya que tenemos KVM configuro el "GRUB" para que espere a que seleccionemos una entrada del menú para el arranque.

  • Ahora reiniciamos la máquina en modo Solaris nativo. Como tenemos un KVM podremos, por fin, ver qué falla cuando la máquina intenta arrancar Solaris. También como el KVM cuelga la máquina al arrancar por software, hacer el reinicio "a lo bestia" mediante el panel de control.

  • Arranca el GRUB del linux, luego el GRUB de Solaris y luego... fallo brusco y reinicio de la máquina. ¡¡No nos da tiempo a ver nada!!.

  • Volvemos a probar, arrancando Solaris en el modo a prueba de fallos. El modo a prueba de fallos funciona perfectamente. Lamentablemente el fallo en el modo normal es tan temprano y repentino que no se graba nada en los logs. ¿Qué hacer?.

  • Pruebo a Instalar OpenSolaris 2009.06, sin éxito tampoco.

  • En el tiempo transcurrido, Sun ha publicado una nueva versión (3.0.0) de VirtualBox, que permite utilizar varias CPUs virtuales. Con esa mejora se puede plantear utilizar Solaris virtualizado, con suerte sin los problemas de estabilidad de VMWare Server detallados con anterioridad.

    Para ello debemos hacer "VBoxManage modifyvm Solaris10 --cpus 2". No hace falta reinstalar nada.

  • Supongo que el problema es un tema de drivers, así que voy a intentar localizar cual es el problema. Iré desactivando drivers poco a poco, hasta que funcione...

  • Arrancando en el modo a prueba de fallos, para eliminar algún driver y probar, monto el disco ZFS. El sistema detecta que tengo un archivo de arranque inconsistente y se ofrece a actualizarlo automáticamente. Acepto la sugerencia. Movido por una intuición, vuelvo a reiniciar la máquina... ¡¡Y arranca!!.

  • ¿Será posible que estemos viendo la luz al final del túnel?.

  • Arranco la máquina. Parece que funciona. Me arranca en modo gráfico, así que lo primero que hago es "login" en el entorno gráfico, abro un terminal como administrador y desactivo el entorno gráfico con "svcadm disable cde-login". Mejor, mucho mejor.

  • Ahora Solaris 10 parece arrancar correctamente, pero no tengo red. En el log de arranque no se ve nada, "dladm" tampoco es de ninguna ayuda. Parece que no tengo el driver de la tarjeta de red. ¿Cuál es?.

  • Vuelvo a arrancar en Linux y compruebo que tarjeta de red tengo con "lspci". Me sale lo siguiente: 
    00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller (rev 10)
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root Port (rev 10)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrated Graphics Controller (rev 10)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

  • Buscando por Internet, encuentro un hilo relevante. Al parecer tengo que instalar el driver "gani". Para meter el driver en el Solaris hay que pasárselo de alguna forma, sin disponer de red. Complicado. O puedo volver a arrancarlo en la máquina virtual y pasarlo por "shared folders" o por red. El problema es que no tengo la red virtualizada preparada para funcionar.

    Vuelvo a instalar Solaris de nuevo, preparado para utilizar la red virtualizada.

  • Arrancando Solaris de forma virtualizada, puedo conectar (en modo NAT) a otra máquina y descargar el driver de red. El teclado cofigurado en el KVM es AZSERTY (francés), pero acabo localizando los símbolos que necesito para realizar esta tarea.

    Es complicado copiar desde el Solaris 10, porque el mapeo de teclado del VRDP no es correcto y necesito caracteres a los que no puedo acceder de forma simple, pero me las acabo apañando.

  • Instalo el driver tal y como se explica en la documentación.

  • Reinicio la máquina en Solaris de forma nativa, conectando por el KVM. Por supuesto el arranque nativo falla, así que arranco en el modo a prueba de fallos, monto el ZFS bajo "/a". En esta ocasión no detecta que el archivo de arranque esté desactualizado. Si escribo "bootadm update-archive -R /a", no parece que el archivo de boot esté incorrecto.

    Hago un "touch /a/reconfigure" y reinicio en modo normal. Parece que así arranca.

  • Un "dladm show-dev" parece que funciona. Nos muestra la interfaz de red "gani0". La configuro con la IP de la máquina asignada por OVH... ¡¡Y todo parece funcionar!!.

  • El contenido de "/etc/hostname.pcn0" es una linea en blanco, lo que imagino que implica que es una tarjeta de red configurada por DHCP. Elimino ese fichero y creo un fichero "/etc/hostname.gani0", con los datos correctos. También creo el fichero "/etc/defaultrouter". Hago un "bootadm update-archive" por si las moscas, que reconstruye cosas (posiblemente por el "reconfigure" previo). Reinicio la máquina.

  • Al arrancar veo que sigue intentando configurar "pcn0" como DHCP, así que tengo que tocar alguna otra configuración al respecto. Tampoco parece hacerle caso a "/etc/defaultrouter". Ésto es algo a resolver más tarde; ahora lo que me urge es recuperar el backup, que tiene todo configurado a mi gusto. Los ajustes de red los haré en esa versión, que es la que voy a conservar. Para recuperar ese backup hago lo siguiente:

    • Recupero el fichero en el que volcamos el "pool" ZFS que me interesa. Está en otra máquina de OVH, así que la transferencia va a tope de línea, aunque tarda un buen ratillo simplemente porque son varios gigabytes a transferir.

    • Nuestro "pool" actual es un "mirror", así que lo "rompemos" y aprovechamos el segundo disco para recuperar ahí los datos del backup: 
      bash-3.00# zpool status
  pool: rpool
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            c2d0s0  ONLINE       0     0     0
            c3d0s0  ONLINE       0     0     0

errors: No known data errors
bash-3.00# zpool detach rpool c3d0s0
bash-3.00# zpool status
  pool: rpool
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          c2d0s0    ONLINE       0     0     0

errors: No known data errors
bash-3.00# zpool create datos c3d0s0
bash-3.00# zpool status
  pool: datos
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        datos       ONLINE       0     0     0
          c3d0s0    ONLINE       0     0     0

errors: No known data errors

  pool: rpool
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          c2d0s0    ONLINE       0     0     0

errors: No known data errors
bash-3.00# gzcat z-dump_disco_Solaris.gz | zfs receive -Fdv datos
receiving full stream of datos@20090604-13:48 into datos@20090604-13:48
received 34.6KB stream in 1 seconds (34.6KB/sec)
receiving incremental stream of datos@20090616-19:46 into datos@20090616-19:46
received 16.0KB stream in 2 seconds (8.02KB/sec)
receiving full stream of datos/ROOT@20090604-13:48 into datos/ROOT@20090604-13:48
received 13.6KB stream in 1 seconds (13.6KB/sec)
receiving incremental stream of datos/ROOT@20090616-19:46 into datos/ROOT@20090616-19:46
received 312B stream in 1 seconds (312B/sec)
receiving full stream of datos/ROOT/solaris10u7@20090604-13:48 into datos/ROOT/solaris10u7@20090604-13:48
cannot mount '/': directory is not empty

      El problema es que al recibir el atributo "mountpoint" para ese "dataset", Solaris 10 (Update 7) intenta montar el "dataset", lo que falla. Si intento recrear el "pool" mientras está "exported", Solaris me dice que no existe. ¿Qué hacer?. Este problema parece estar solucionado en OpenSolaris, pero en Solaris 10 Update 7 significa que no podemos hacer un "stream" de replicación conteniendo el ZFS "root". Haría falta que el "zfs receive" no montase los "datasets", o bien poder hacer un "zfs receive" sobre un dataset exportado.

      Seguramente ésto se solucionará en el futuro, pero ahora mismo estamos jodidos. ¿Qué hacer?.

      El atributo "canmount" nos podría ayudar, pero no se hereda.

      Una idea es descargar el código fuente de la utilidad, modificarlo para que ignore ese error, recompilarla y volver a intentarlo. De hecho no haría falta modificarla, porque viendo el código actual de OpenSolaris han añadido una opción "-u" para evitar montar los "datasets" recibidos. Pero para compilarlo necesito el compilador de Sun, que es gratuito pero que no tengo. Siempre puedo extraer el comando de OpenSolaris, ya compilado, y rezar para que funcione en Solaris 10. Además, es posible que el Kernel de Solaris 10 simplemente no acepte esta posibilidad.

      Otra idea es procesar el "stream" para eliminar los puntos de montaje o poner "canmount=off" en cada "dataset". Pero ésto dista de ser trivial.

      Pensando sobre el asunto, me doy cuenta de que el problema es similar a cuando enchufamos un "pool" ZFS no confiable, como un USB externo. En ese caso es posible restringirlo usando un parámetro en la importación. Veamos... 

      bash-3.00# zpool export datos
bash-3.00# mkdir zz
bash-3.00# zpool import -R/zz datos
bash-3.00# gzcat z-dump_disco_Solaris.gz | zfs receive -Fdv datos
receiving full stream of datos@20090604-13:48 into datos@20090604-13:48
received 34.6KB stream in 1 seconds (34.6KB/sec)
receiving incremental stream of datos@20090616-19:46 into datos@20090616-19:46
received 16.0KB stream in 1 seconds (16.0KB/sec)
receiving full stream of datos/ROOT@20090604-13:48 into datos/ROOT@20090604-13:48
received 13.6KB stream in 1 seconds (13.6KB/sec)
receiving incremental stream of datos/ROOT@20090616-19:46 into datos/ROOT@20090616-19:46
received 312B stream in 1 seconds (312B/sec)
receiving full stream of datos/ROOT/solaris10u7@20090604-13:48 into datos/ROOT/solaris10u7@20090604-13:48
cannot mount '/zz': directory is not empty

      Uhmmm... Dentro de "/zz" se crea un directorio "datos" que es el "dataset" que alberga el "pool" completo. Podemos eliminarlo haciendo un "zfs set canmount=off datos". Ahora la cosa tiene mejor pinta: 

      bash-3.00# gzcat z-dump_disco_Solaris.gz | zfs receive -Fdv datos
receiving full stream of datos@20090604-13:48 into datos@20090604-13:48
received 34.6KB stream in 2 seconds (17.3KB/sec)
receiving incremental stream of datos@20090616-19:46 into datos@20090616-19:46
received 16.0KB stream in 1 seconds (16.0KB/sec)
receiving full stream of datos/ROOT@20090604-13:48 into datos/ROOT@20090604-13:48
received 13.6KB stream in 1 seconds (13.6KB/sec)
receiving incremental stream of datos/ROOT@20090616-19:46 into datos/ROOT@20090616-19:46
received 312B stream in 1 seconds (312B/sec)
receiving full stream of datos/ROOT/solaris10u7@20090604-13:48 into datos/ROOT/solaris10u7@20090604-13:48
received 4.79GB stream in 105 seconds (46.7MB/sec)
receiving incremental stream of datos/ROOT/solaris10u7@20090616-19:46 into datos/ROOT/solaris10u7@20090616-19:46
received 369MB stream in 34 seconds (10.9MB/sec)
receiving full stream of datos/ROOT/solaris10u7/var@20090604-13:48 into datos/ROOT/solaris10u7/var@20090604-13:48
received 621MB stream in 33 seconds (18.8MB/sec)
receiving incremental stream of datos/ROOT/solaris10u7/var@20090616-19:46 into datos/ROOT/solaris10u7/var@20090616-19:46
received 264MB stream in 20 seconds (13.2MB/sec)
receiving full stream of datos/export@20090616-19:46 into datos/export@20090616-19:46
received 15.0KB stream in 1 seconds (15.0KB/sec)
receiving full stream of datos/export/home@20090616-19:46 into datos/export/home@20090616-19:46
received 13.6KB stream in 1 seconds (13.6KB/sec)
receiving full stream of datos/usr_local@20090609-19:36 into datos/usr_local@20090609-19:36
received 4.69GB stream in 89 seconds (53.9MB/sec)
receiving incremental stream of datos/usr_local@20090616-19:46 into datos/usr_local@20090616-19:46
received 127MB stream in 12 seconds (10.6MB/sec)
bash-3.00# zfs set canmount=on datos

  • Copiamos el driver de red de un "pool" ZFS al otro, para tenerlo disponible cuando destruyamos el original.

  • Ahora arrancamos de nuevo el linux. Queremos comprobar que el "pool" "datos" es suficiente para arrancar el sistema, así que reconfiguramos la máquina virtual para eliminar el primer disco: "VBoxManage modifyvm Solaris10 -hda none". Arrancamos la máquina virtual. Parece que funciona

  • Volvemos a activar el disco, arrancamos Solaris 10 virtualizado, destruimos el "pool" "rpool", que reside en el primer disco, y añadimos ese disco al segundo "pool" (datos), como un "mirror" (RAID1). Esperamos unos 5 minutos para resincronizar los 11 gigabytes del "pool". Reiniciamos la máquina virtual... y no funciona.

    :-(

  • Estoy bastante cansado de pegarme con ésto, así que realizo una instalación desde cero, pensando en que será la definitiva y no voy a utilizar el backup previo. La configuración es básicamente la ya descrita en el otro documento.

  • Cambio el arranque GRUB del linux para que arranque Solaris 10 al reiniciarse la máquina.

  • A la hora de configurar el cortafuegos hay que permitir el "PING", porque es lo que usa OVH para comprobar que la máquina está viva. Si no es así, la reinicia a lo bestia (le quita la electricidad y se la vuelve a dar). La máquina que hace "ping" se llama, muy apropiadamente, "ping.ovh.net".

    Curiosamente, OVH reporta los errores desde esa IP, pero la IP que realiza el sondeo de verdad no es esa. Parece que hay un "nat" en medio, tal vez para no detectar problemas si alguien restringe su red a la LAN.

    Lo fácil sería abrir el "PING" a todo el mundo. Pero me parece excesivo. De momento abro solo para mi LAN, mi /24.

  • Tras instalar todo, hago un snapshot de todos los "datasets" relevantes. Básicamente todo menos el "swap" y el "dump".

  • Ejecuto el siguiente programa en python: 
    import os, time
syncs = 10000
f = open("zz","w")
t = time.time()
for i in xrange(syncs) :
    f.write("a")
    f.flush()
    os.fsync(f)
print "Realizamos %d transacciones por segundo" %(syncs/(time.time()-t))

    Me salen 117 transacciones por segundo, acordes con el hardware que estoy utilizando.

Últimos flecos

Tras tener la máquina en servicio durante una semana, con bastante carga de red, CPU y actividad de disco, considero que todo funciona como debe y está lista para pasar a producción.

Faltan por pulir los últimos detalles.

  • Conecto al KVM, reinicio la máquina y activo el Linux.

  • Actualizo el linux.

  • Si en el futuro surge un problema grave que no puedo resolver desde el KVM (o lo pierdo, o no está accesible), debo configurar el arranque de la máquina, desde el gestor OVH, para que arranque en modo "rescue". Una vez reiniciada la máquina, me llegará por email la clave de acceso temporal al modo "rescue". Con dicha clave debo entrar en la máquina, montar el disco del sistema ("/dev/md1", recordemos que es un RAID 1) y cambiar el menú GRUB para que arranque el linux. Seguidamente debo reiniciar la máquina en modo normal. Una vez arrancado el linux, debo conectar a ella y lanzar la máquina virtual, para solucionar el problema que surja.

    En esta situación el stress es importante, además de ser algo que se hace de forma tremendamente esporádica. Por lo tanto es importante reducir las posibles causas de errores, que todo sea lo más sencillo posible.

    Y en este procedimiento de recuperación hay un paso delicado que, si no lo recordamos, destruirá nuestro sistema de recuperación... Cuando arrancamos la máquina virtual en el Linux, arrancaré el GRUB que, con el cambio realizado arrancará... el Linux. Así que si no somos rápidos lanzando el cliente VRDP y seleccionando "Solaris 10" en el menú de arranque... podemos encontrarnos con que hemos corrompido el Linux y, con ello, nuestras esperanzas de resolver la situación rápido.

    Naturalmente ésto no lo recordaremos dentro de dos años, cuando necesitemos saberlo.

    Para evitarlo, voy a dejar configurada la máquina virtual con una pequeña imagen ISO que simplemente contiene un GRUB que arranca el Solaris. De esta forma si arrancamos la máquina virtual y no somos lo bastante rápidos para entrar por VRDP enseguida, no pasará nada. Llamémoslo una pequeña inversión en tranquilidad.

    • "cd /root/.VirtualBox"

    • "mkdir -p iso-arranque-Solaris10/boot/grub"

    • "cp /usr/lib/grub/*-pc/stage2_eltorito /boot/grub/menu.lst iso-arranque-Solaris10/boot/grub/"

    • Editamos el "menu.lst" que hemos copiado, para que arranque el Solaris 10.

    • Creamos la imagen ISO con

      mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table \
      -o iso-arranque-Solaris10.iso iso-arranque-Solaris10

    • Enlazamos ese ISO con la máquina virtual:

      VBoxManage modifyvm Solaris10 -dvd /root/.VirtualBox/iso-arranque-Solaris10.iso

    • Arrancamos la máquina virtual y, en nuestro puesto, arrancamos RÁPIDAMENTE el cliente VRDP, conectamos y comprobamos que todo va bien. Se arranca el Solaris virtualizado, no el linux, aunque no hagamos nada.

      Acabamos de evitar meter la pata dentro de 2 años, cuando necesitamos resolver una urgencia rápidamente sin recordar absolutamente todos los detalles.

  • El VRDP va sin autentificar y sin cifrar. Como es algo que se va a utilizar muy esporádicamente, con suerte nunca, no nos preocupa demasiado. Pero si algún día necesitamos echar mano de la máquina virtual, sería buena idea lanzarla en un puerto "raro". Afortunamente no nos hará falta nunca, gana la primera conexión (que será la nuestra) y durante la recuperación no nos hará falta meter ninguna clave...

  • Documentamos todos los pasos con extremo cuidado, para uso futuro. Por ejemplo, detalles como que si en algún momento entramos en el Solaris 10 a través de la máquina virtual, habrá que entrar primero en el modo a prueba de fallos, hacer un "reconfigure" y luego entrar en el modo normal. Y cuando volvamos al arranque nativo, hay que hacer lo mismo. Esta última parte es especialmente delicada si no tenemos el KVM a mano por si las moscas. Con suerte no hará falta nunca...

  • Preparamos todo nuestro sistema de backup para acoger la nueva máquina.

  • A priori no sería necesario hacer backup del Linux, porque estará inactivo salvo casos de extrema necesidad. Existe la posibilidad de instalar una máquina virtual en Solaris 10 y ejecutar desde ella el Linux de forma nativa, para lanzarlo de vez en cuando y mantenerlo actualizado. Pero al margen de la complejidad de que el Linux pueda arrancar en los dos modos (y con red, para poder actualizarlo y para poder hacer backup), no tenemos la seguridad de que una actualización afecte al linux de forma que sea incapaz de arrancar rápidamente en Solaris virtualizado, por ejemplo porque se haya actualizado el kernel... y eso lo descubres justo en el peor momento; es decir, cuando necesitas levantar la máquina virtual Solaris 10 en plena crisis.

    Por ello, a priori, no me preocupo ni de actualizar el Linux ni de hacerle backup. No lo considero necesario, aunque es una decisión que se puede valorar de nuevo más adelante.

  • Hay que tener cuidado con la instalación de GRUB en el sector de arranque. En mi configuración, el GRUB maestro es el de Linux, que arranca el GRUB de Solaris que está en su partición. Esta configuración es estable, ya que el Linux no deberíamos tocarlo, y el Solaris, una vez instalado, no vuelve a tocar el GRUB.

    Pero si ocurre "algo", hay que reinstalar el GRUB de linux en el sector de arranque, tal y como he descrito en el documento anterior.

Con todo ésto, considero que la máquina está lista para entrar en producción.

KVM remoto

La opción de KVM (teclado, video y ratón) remoto nos ha sacado del atolladores, pero hay algunos problemas:

  • El primer KVM instalado bloqueaba la máquina al arrancar. Es decir, la máquina se colgaba tras la BIOS y antes de arrancar el sistema operativo. La única forma de que funcionase era quitarle la alimentación y volver a dársela.

    Tras abrir una incidencia con OVH, me cambiaron el KVM. Naturalmente ese período de dos semanas lo pagas, aunque no puedas usar ni el KVM ni el ordenador al que está conectado...

    Había también algunos problemas con el mapeo de teclado, que se solucionaron cuando reemplazaron el componente.

  • Cuando me activaron el KVM, me pusieron teclado francés (AZERTY). Yo soy español, y uso un teclado QWERTY español. Tras abrir otra incidencia y esperar otro par de días, activaron el mapeo de teclado español. Nuevamente, más tiempo pagando y sin poder usar el servicio.

  • No se puede arrancar el sistema desde un USB/ISO local. Actualmente tengo este incidente abierto. La consecuencia más obvia es que ante un fallo grave del sistema Solaris, dependeré del Linux instalado en el disco duro, de la máquina virtual, etc., ya que no puedo arrancar el sistema por red.

    A ver si me dicen algo...

  • Cuando me resuelvan el problema anterior, hay otro... De vez en cuando el KVM admite conexiones y muestra la pantalla correctamente, pero no admite ni teclado ni ratón. Es como si alguien tuviese una conexión en modo "exclusivo". Es posible que la gente de OVH esté curioseando, pero me ha ocurrido muchas veces en diferentes horarios... es mosqueante.

    Como sólo se puede abrir un incidente simultaneo por equipo, no puedo plantear éste hasta que cierren el de arranque remoto.

    Por supuesto, mientras sigues pagando...

  • No puedes cambiar la clave de acceso al KVM.

Historia

  • 24/jul/09: Pulimos los últimos detalles y publicamos el documento.

  • 15/jul/09: Parece que lo he conseguido...

  • 16/jun/09: Primera versión de esta página.

Python Zope ©2009 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS