Instalación de Sun Solaris en un hosting OVH
Última Actualización:
15 de Junio de 2009 - Lunes
Mi sistema operativo de elección, por infinidad de razones (incluyendo ZFS y DTrace), es Solaris.
El problema es que la mayoría de los hostings no soportan Solaris de forma nativa. Ello no sería
un problema grave si se dispusiese de capacidad para KVM+DVD/USB remoto, pero tampoco suele ser
el caso.
Veamos OVH, por ejemplo: no soportan Solaris de forma nativa, su KVM es una máquina virtual
con muchos problemas de compatibilidad y sin capacidad para acceder a ningún medio de instalación
por red, y en el modo "rescue" arranca un linux.
Tras darle muchas vueltas al asunto, veo tres opciones:
- Instalar un Linux y conformarse con él... Mala opción para mí.
- Instalar un Linux mínimo, una máquina virtual Solaris sobre él y meter todos los servicios
sobre dicha máquina virtual. Ésta es una buena opción, porque si hay problemas con el Solaris, tenemos
el Linux por debajo, al que podemos conectar para examinar qué ocurre con ella. Otra ventaja importante
es que nos desentendemos de problemas de drivers con Solaris. Como desventajas fundamentales, tenemos
problemas de rendimiento (por ejemplo, los servidores baratos de OVH no soportan las instrucciones
de virtualización hardware de las CPUs modernas, así que tenemos que meter un kernel Solaris en 32 bits,
y tampoco podemos asignarle toda la memoria a la máquina virtual) y que si el Linux subyacente tiene
problemas de seguridad o falla en una actualización, estamos bien jodidos. Además, los kernel OVH no
nos sirven.
- Otra opción es tener un sistema con arranque dual. En modo normal, arranca Solaris. Si hay problemas
entramos por el KVM virtual y configuramos el sistema para que arranque Linux. Una vez arrancado Linux, podemos
arrancar la partición de Solaris... dentro de la máquina virtual, para ver qué le duele, solucionarlo y, luego
arrancar de nuevo de forma nativa. La ventaja es rendimiento nativo. La desventaja es la mayor complejidad y los
posibles problemas de compatibilidad hardware.
En este documento explico las pruebas realizadas y sus resultados, en mayo de 2009:
- Alquiler de una máquina OVH "SuperPlan BestOF", 4 gigas de memoria, 2 discos duros de 750 gigabytes,
Intel Core2Duo 2.66Ghz.
- Instalación de Ubuntu Server 8.04 LTS 64 bits. Utilizo esta versión porque es un LTS (Long Time Support).
- En los servidores baratos de OVH el servicio vKVM, que es una máquina virtual, no funciona si el
sistema instalado es de 64 bits. Por tanto, una vez instalado el sistema, usamos el panel de control
de OVH para arrancar el equipo de forma virtualizada y comprobar así si tenemos acceso vKVM.
Me apena decir que es el caso también con las máquinas caras. Osea, no podemos usar un kernel 64 bits
si esperamos poder usar vKVM cuando tengamos una crisis. El error es:
This kernel requires an X86-64 CPU, but only detected an i686 CPU.
Unable to boot - Please use a kernel appropiate for your CPU.
- Dado el punto anterior, el siguiente paso es reinstalar el sistema, con un kernel 32 bits.
Elijo Ubuntu Server 8.04 LTS 32 bits, por las razones expuestas.
Afortunadamente es una operación relativamente rápida (unos 15 minutos).
En este caso todo funciona perfectamente... salvo por unos errores muy sospechosos de disco duro.
Durante el proceso observo que hay un checkbox para arrancar un vKVM en 64 bits... Uhmmm.
- Debido a los errores de disco que estoy viendo en modo virtual, arranco el sistema
de forma nativa y hago un chequeo de ambos discos duros con "badblocks". Son discos de 750 gigas,
así que este proceso es bastante lento. Paciencia...
- En el modo vKVM es posible arrancar una imagen ISO remota (accesible vía FTP). Según ésto
sería posible arrancar un disco de instalación de Solaris, realizar una instalación nativa, utilizar
la máquina nativa y volver a arrancar a través del ISO remoto, si surgen problemas serios.
El problema es que la imagen ISO mide más de 2 gigabytes, lo que requiere tener una máquina en la misma
LAN que el servidor problemático, para que el arranque se realice a una velocidad razonable. Además,
no parece funcionar correctamente; el servidor carga la imagen ISO, pero no parece hacer nada con ella.
Dada la situación, y considerando que esta funcionalidad debe estar disponible en momentos de crisis,
no podemos jugárnosla.
Si funcionase correctamente, sería la mejor opción, siempre que la máquina no tenga problemas
de drivers con Solaris.
- Vuelvo a instalar la versión de 64 bits. Compruebo si funciona el modo vKVM, marcando el "checkbox"
de 64 bits. Con ésto, parece funcionar correctamente.
Aprovecho para configurar el RAID 1 (Mirror) para la partición de arranque de Linux: Creo una
partición de sistema de 10 gigas, un swap de dos gigabytes (uno en cada disco; es curioso que el
swap no se proteja) y 5 gigabytes en "/SolarisDVD", que es donde dejaremos las imágenes ISO del sistema Solaris.
- Actualizo el sistema a la última versión, a través de "apt-get update", "apt-get upgrade" y
"apt-get dist-upgrade". Reiniciamos para asegurarnos de que todo funciona.
- La distribución Linux instalada por OVH tiene sus propias modificaciones. Lo primero que hago es
eliminar las claves SSH de OVH para "root", y la línea de "rtm" en el "/etc/crontab". De esta forma OVH pierde
la capacidad para entrar en mi máquina.
- OVH utiliza LILO como gestor de arranque. A mí me interesa usar GRUB. Hacemos los siguiente:
- "apt-get install grub".
- "mkdir /boot/grub".
- "update-grub".
- "cat /boot/grub/menu.lst".
title UBUNTU 8.04 (Kernel OVH)
root (hd0,0)
kernel /boot/bzImage-2.6.27.10-xxxx-grs-ipv4-64 root=/dev/md1
- "apt-get install mdadm". Ésto es necesario porque tenemos la partición raíz protegida en RAID 1 (mirror).
- "grub-install /dev/sda".
- "grub-install /dev/sdb".
Ahora reiniciamos con vKVM y comprobamos que el arranque va con GRUB.
Si ésto tiene éxito, reiniciamos en modo normal y seguimos.
- El kernel OVH está modificado. No permite, por ejemplo, instalar módulos dinámicos. Ésto lo necesito
para poder ejecutar VirtualBox. Lo que me
interesa es instalar el kernel nativo de Ubuntu, no la versión modificada por OVH.
- "apt-get install linux-image". Este comando ya actualiza el "menu.lst" de configuración de
arranque del GRUB.
- Reiniciamos y comprobamos que todo va bien y arranca el kernel correcto, con el comando "cat /proc/version".
- A continuación instalamos VirtualBox:
- "apt-get install dkms". Este paquete es necesario para recompilar el módulo Kernel de VirtualBox si
actualizamos el kernel del sistema.
- "dpkg -i virtualbox-2.2_2.2.2-46594_Ubuntu_hardy_amd64.deb". La instalación de este paquete fallará
porque necesitamos satisfacer dependencias. Las resolvemos usando "apt-get install" con cada una de ellas,
y volvemos a intentar instalar VirtualBox. También podemos hacer un "apt-get install -f", para resolver
todas las dependencias pendientes de forma automática.
- Ahora intentamos instalar Solaris dentro de la máquina virtual:
- El primer paso es utilizar el espacio libre en los discos duros para asignárselo a Solaris. Para
ello empleamos la utilidad "fdisk", tanto en "/dev/sda" como en "/dev/sdb". Las definimos de tipo "bf",
es decir, Solaris. Ésto no tiene ninguna importancia si estamos trabajando con máquinas virtuales,
pero sirve también como documentación.
- A continuación debemos definir ambas particiones como discos VirtualBox
- "VBoxManage internalcommands createrawvmdk -filename /root/.VirtualBox/SolarisA -rawdisk /dev/sda4 -register".
¡¡Mucho cuidado con equivocarnos de partición!!.
- "VBoxManage internalcommands createrawvmdk -filename /root/.VirtualBox/SolarisB -rawdisk /dev/sdb4 -register".
- "VBoxManage createvm -name Solaris10 -register".
- Comprobamos que tenemos soporte de virtualización por hardware escribiendo "cat /proc/cpuinfo" y buscando
las extensiones "vmx" y/o "smx".
- "VBoxManage modifyvm Solaris10 -memory 3500M -acpi on -vrdp off -dvd /SolarisDVD/sol-10-u7-ga-x86-dvd.iso
--ostype Solaris --vram 32MB --ioapic on --hwvirtex on --nestedpaging on --vtxvpid on --hda /root/.VirtualBox/SolarisA
--hdb /root/.VirtualBox/SolarisB --sata on".
- "VBoxHeadless --startvm Solaris10 --vrdp on". Con esto arrancamos la máquina virtual. En nuestra
máquina local debemos lanzar un cliente VRDP, como "rdesktop" o similar (en Linux), y conectarnos a la máquina
remota.
Es importante recordar que por defecto el servicio VRDP permite conexiones desde cualquier IP y sin
autentificación, así que debemos ser rápidos para conectarnos a ella (solo se permite una conexión simultanea,
así que el primero gana). En un entorno real habría que configurar el cortafuegos del Linux subyacente para
permitir conexiones exclusivamente desde IPs bajo nuestro control. De todas formas, con la máquina virtual
en producción no vamos a tener activado VRDP, así que ésto no es problema. Solo activaremos VRDP en
caso de problemas, mediante "VBoxManage controlvm Solaris10 vrdp on".
También hay que recordar que la conexión no va cifrada, así que cuidado con pasar claves a través de ella.
Probablemente lo mejor sería activar el servidor VRDP exclusivamente en la IP 127.0.0.1 y canalizar la conexión
a través de un túnel SSH o similar.
VirtualBox dispone de capacidad tanto para autentificar como para cifrar la conexión VRDP, pero no nos
preocupamos de ello de momento, ya que esta funcionalidad sólo se usará de forma muy esporádica, ante emergencias.
- Tras completar la instalación, desactivamos el DVD virtual con "VBoxManage modifyvm Solaris10 --dvd none".
- Tras instalar el sistema hay que comprobar algunas cosas:
- Soporte de red. Hay varias formas para configurarla. No voy a entrar en detalles en este documento.
- Kernel 64 bits y soporte de virtualización. Para ello usamos los comandos "isainfo -v" de Solaris.
- Comprobamos que vemos los dos cores de la CPU, con el comando "psrinfo" de Solaris... No es el caso, solo
vemos uno. Se trata de una limitación de VirtualBox.
- Un detalle MUY importante de ZFS es que es crítico que los discos duros obedezcan los comandos de control
de caché. En caso contrario podemos tener problemas muy serios.
Una posibilidad para comprobar ésto es ejecutar 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))
Ejecutando este programa en el Linux, obtenemos 558 transacciones por segundo. Esta cifra es muy alta
para los discos duros que estamos usando, así que se está utilizando la caché de escritura de los discos duros,
lo que es muy peligroso si se va la luz a la máquina, etc. Desactivando la caché de escritura,
mediante el comando "hdparm", obtenemos 30 transacciones por segundo, que es una cifra mucho más razonable
para discos de 7200RPM y ext3.
Haciendo la misma prueba dentro de la máquina virtual, obtenemos unas 300 transacciones por segundo
en un caso y unas 100 en el otro. La segunda cifra es razonable bajo ZFS y este hardware.
Por tanto, antes de lanzar la máquina virtual hay que desactivar la caché de escritura de los discos duros,
mediante el comando "hdparm". En caso contrario, nos arriesgamos a perder el sistema.
- Ahora intentamos montar un arranque dual entre Linux y Solaris. Dado que el GRUB de Linux está en el arranque
del disco duro, arrancaremos con él. Como es incapaz de arrancar un sistema Solaris con ZFS de forma nativa, el
GRUB de Linux debe ejecutar el GRUB de Solaris, que reside en la partición 4, en nuestra configuración.
title SOLARIS10
rootnoverify (hd0,3)
chainloader +1
- A continuación arrancamos con vKVM e intentamos lanzar Solaris. El lanzamiento falla con un error
"bad pbr sig". Tras investigar el asunto online, parece que el problema es que cuando instalamos el sistema
bajo una máquina virtual, con arranque ZFS, Solaris está viendo la partición como si fuese un disco completo.
En ese caso Solaris creará etiquetas EFI en el disco. Debemos evitarlo. Además, está creando una tabla de
particiones dentro de una partición, lo que podría tener sentido su fuese una partición lógica, pero no es así.
- Una posible solución sería instalar Solaris sobre el disco de Linux. El disco duro COMPLETO. Es decir,
en vez de decirle a Solaris que una partición del disco duro es un disco duro completo, le doy el disco duro
completo y le digo que use la partición correspondiente. Esto debería funcionar, salvo, tal vez, porque no
quiero que el GRUB de Solaris se instale en el arranque del sistema, sobre el GRUB de Linux.
Hay que tener muchísimo cuidado con una cosa: Si montamos el disco duro entero para VirtualBox, cuando
arranquemos VirtualBox va a intentar arrancar el disco... que con mi configuración actual supone arrancar Linux
dentro de la máquina virtual. Esto supone que ambos Linux, el real y el virtual, están accediendo a las mismas
particiones a la vez, lo que es receta segura para tener corrupción de datos de forma instantanea.
Éste es un problema muy grave, que me preocuparé de solucionar luego.
De momento lo que hacemos es recrear la configuración de la máquina virtual, pero esta vez indicándole los
discos duros enteros. Osea, hacemos:
- "VBoxManage internalcommands createrawvmdk -filename /root/.VirtualBox/SolarisA -rawdisk /dev/sda -register".
- "VBoxManage internalcommands createrawvmdk -filename /root/.VirtualBox/SolarisB -rawdisk /dev/sdb -register".
Lamentablemente no consigo afinar bien el sistema, y corrompo el Linux subyacente, así que tengo que
reinstalarlo de nuevo. Probablemente insistiendo un poco pueda solucionar el problema, pero cada prueba requiere
instalar dos sistemas operativos, etc., lo que es un proceso lento, aburrido y proclive a errores.
- Otra vía posible es, ya que esta máquina tiene dos discos duros, utilizar una partición Linux
en el primer disco, que es el que arranca, e instalar Solaris en el segundo disco. A priori eso debería
funcionar bien, encadenando los sectores de arranque. Una vez en producción sería posible añadir el espacio
libre del primer disco como una extensión (RAID 0) o un "mirror" (RAID 1) del ZFS de Solaris, a elegir.
Los pasos serían los mismos, salvo que:
- Cuando instalamos el GRUB de Linux, el "root" en "menu.lst" debe ser "/dev/sda1", en lugar de
"/dev/md1".
- A la hora de instalar el GRUB en el sector de arranque de Linux, lo instalamos en el primer
disco, pero NO en el segundo disco, donde va a ir el arranque de Solaris.
- El particionado de ambos discos duros debe ser comparable, para poder usarlos como "mirror" (RAID 1)
- A la hora de crear la máquina virtual, mapeamos solo el segundo disco. De esta forma evitamos meter
la pata y cargarnos en linux del primer disco. Pero en este caso es importante que si usamos el primer disco
también para Solaris, que lo añadamos como "mirror" (RAID 1). De esta forma podremos trabajar sin problemas,
y ZFS se encargará de resincronizar el "mirror" cuando volvamos a arrancar en modo nativo.
- Una vez instalada la máquina virtual, y comprobando que arranca correctamente, añadimos lo siguiente al
GRUB del Linux:
title SOLARIS10
rootnoverify (hd1,0)
chainloader +1
Seguidamente hay que arrancar desde vKVM y comprobar que arranca Solaris si elegimos esa opción en el GRUB.
Pero... vKVM NO soporta dos discos duros, así que no podemos arrancar el Solaris. ¡¡Todo son problemas!!.
Dios, qué chapuza...
Intentar poner a andar ésto sin soporte vKVM es arriesgado porque, por ejemplo, tenemos que localizar
exactamente el driver de la tarjeta de red que debemos configurar para tener la máquina accesible
desde el exterior. Algo que no es trivial si no podemos ver la pantalla...
- Vuelvo a la opción de instalar Solaris en el primer disco, en otra partición.
- Hago una instalación normal de Solaris. Ésto instalará su GRUB en el sector de arranque.
- Seguidamente, en el Linux, reinstalo su arranque GRUB, mediante "grub-install".
- Edito el GRUB de Linux con
title SOLARIS10
rootnoverify (hd0,3)
chainloader +1
- Arrancando la máquina virtual intentará arrancar el GRUB normal (cuidado con arrancar una
segunda sesión del Linux, porque será corrupción segura del disco duro). Seleccionando la entrada
Solaris obtenemos... nada. No funciona. Solo muestra "GRUB" y se para. Aparentemente ejecuta el GRUB
de Solaris, pero éste no es capaz de continuar (posiblemente no encuentra los stage 1.5 o 2).
Tras investigar el asunto durante un par de horas me doy cuenta de una cosa... ¡¡¡¡¡¡¡Solaris está
instalando su GRUB en la partición de SWAP de Linux!!!!!!!. Esto es así porque su código de partición
se solapa con la de Solaris. Es decir, Solaris la reconoce como una partición propia. Naturalmente ésto
no funciona, porque la partición de Swap, aunque la máquina esté aburrida, tiene una pequeña actividad
que va corrompiendo cualquier cosa que se grabe en ella.
¿Podría ser ésto el origen de todos mis males?. Tal vez la corrupción del punto anterior se debiese a este
problema (Solaris sobreescribe la partición de Swap de Linux, y éste se comportará de forma errática
cuando intente volver a cargar en memoria sus datos, que han sido sobreescritos).
Hago algunas pruebas eliminado el SWAP de Linux, y todo parece funcionar como debe. Pero, curiosamente,
el instalador de Ubuntu no me deja desactivar la partición de Swap a la hora de formatear el sistema...
¡Qué cosas!.
Tal vez si la primera partición Solaris estuviese en el disco antes que el Swap, la usaría primero...
Aún así, el tema parece un pelín frágil para arriesgarse. Las cosas podrían cambiar en una actualización
futura y mordernos el culo. Tal vez sea más inteligente o desactivar el swap a las bravas, una vez
instalado en Linux, o desactivarlo puntualmente cuando se toquen cosas relacionadas en Solaris. Éste último
paso parece proclive a errores. Hay que meditarlo un poco.
- Con todo lo anterior, procedo a reinstalar de nuevo el Linux desde cero, con las particiones en RAID,
a actualizarlo, etc. Es obligatorio definir partición de SWAP, así que lo hago.
- Debido a los problemas con el Swap Linux al instalar Solaris, desactivo temporalmente la memoria virtual
en el Linux, con el comando "swapoff", elimino las dos particiones (una en cada disco duro), creo las
particiones que albergarán Solaris y nuevas particiones de Swap tras ellas (al final del disco duro), y reactivo
el Swap.
Es muy importante actualizar el "/etc/fstab" para reflejar la posición del nuevo Swap. También es importante
inicializar las areas de Swap de Linux con el comando "mkswap".
Reinicio la máquina para asegurarme de que todo funciona.
- A la hora de instalar el Solaris, creo los dos discos virtuales cubriendo los dos discos duros reales.
- No hay que olvidar, tras instalar Solaris, que la instalación configura el arranque para arrancar Solaris.
Debemos reinstalar el arranque GRUB de Linux mediante el comando "grub-install", como ya se ha descrito. También
actualizamos el "menu.lst" para añadir una entrada para arrancar el Solaris, como se ha descrito también
(apuntando a la partición correcta). Con estos cambios, hay que tener mucho cuidado al reiniciar la máquina
virtual, porque intentará arrancar, por defecto, una instancia virtualizada de Linux sobre la misma partición
que está funcionando, lo que corromperá el disco irremediablemente. Hay que tener mucho cuidado para ser
rápidos y seleccionar Solaris antes del "timeout".
Tras ésto, reiniciamos la máquina virtual, para comprobar que todo funciona. Mucho cuidado con seleccionar
rápido Solaris en el menú Grub, para no cargarnos nada.
- Para tener una mejor integración en el Solaris 10 virtualizado es necesario instalar las "Guest Additions".
Realmente no nos
interesa tener red cuando estamos virtualizados, porque esta instalación va a funcionar en modo nativo, pero
puede ser interesante si tenemos problemas y necesitamos algo.
- Tenemos el ISO en "/usr/share/virtualbox/VBoxGuestAdditions.iso", así que creo un enlace simbólico dentro
de mi directorio "/SolarisDVD" para tenerlo todo juntito.
- Ahora le pasamos el DVD a la máquina virtual con
"VBoxManage controlvm Solaris10 dvdattach /SolarisDVD/VBoxGuestAdditions.iso".
- El disco nos aparecerá en la máquina virtual Solaris (podemos verlo con "df -k").
Nos vamos a ese directorio e instalamos las extensiones con el comando "pkgadd -d ./VBoxSolarisAdditions.pkg".
Hacemos un "touch /reconfigure" (para que el kernel Solaris escanee dispositivos) y reiniciamos.
- Se me olvidó activar los interfaces de red en la máquina virtual a la hora de crearla, así que la paramos
y escribirmos "VBoxManage modifyvm Solaris10 --nic1 nat". Hay que hacer un nuevo "touch /reconfigure"
y reiniciar la máquina virtual de nuevo.
- La interfaz de red es "pcn0". Identificamos la interfaz mirando "/var/adm/messages", y buscando
notificaciones de direcciones Ethernet, o mensajes sobre la velocidad de la interfaz.
- El problema es que tengo que configurar toda la red desde cero, lo que es un coñazo. Por ello opto
por reinstalar el sistema una vez más, esta vez con una interfaz de red instalada en el ordenador.
Con ésto todo funciona. Tengo red.
- Tomo nota de los datos de red:
- Interfaz: "pcn0"
- IP: 10.0.2.15
- Ruta por defecto: 10.0.2.2
- DNS: 213.186.33.99 (OVH: domain "ovh.net")
La idea es realizar una instalación "buena" y poder poner estos datos si arrancamos a través de máquina
virtual, y necesitamos la red.
- Ahora volvemos a desactivar la red de la máquina virtual y hacemos otra instalación desde cero. Ésta debe
ser la definitiva, con suerte. Desactivamos la red durante la instalación porque no queremos que nos
quede basurilla de la máquina virtual en la configuración de red. Si necesitamos la red desde la máquina
virtual, echamos mano de los datos recopilados hace un momento.
- Una vez que todo funciona bien, activamos la red de nuevo, reinciamos y comprobamos que activando
las configuraciones de red de forma manual, la red nos funciona. Recordemos que es conveniente hacer un
"touch /reconfigure", antes de reiniciar, por si las moscas.
- Ahora necesitamos saber cual es el driver de red que debemos usar para Solaris, cuando arranca
en modo nativo. Como en dicho modo perdemos el acceso por red, mientras no la configuremos correctamente,
y el vKVM no nos sirve porque arranca una máquina virtual, tenemos que recurrir al siguiente truco:
- Hacemos un "touch /reconfigure" en el Solaris, solo para asegurarnos.
- Nos aseguramos de que el Grub que toma el control es el del Linux. Cambiamos la configuración de su
"menu.lst" para que arranque el Solaris.
- Reiniciamos la máquina. Se deberá arrancar el Solaris. Como no tiene configurada la red, no funcionará
nada. Ésto es normal.
- Esperamos 10 minutos y configuramos el arranque en modo "rescue", vía el panel de control OVH. También
le decimos que reinicie el servidor "a saco". Esperamos a que nos llegue los datos de acceso "rescue"
por correo electrónico.
- Una vez que tenemos los datos de acceso, entramos en el equipo, montamos el disco del sistema y cambiamos
su "menu.lst" para que arranque el Linux normal. Reconfiguramos el panel de control OVH y reiniciamos la máquina.
ATENCIÓN: A la hora de montar la partición, hay que recordar montar "/dev/md1", ya que es un RAID 1 (mirror).
No cometer el error de montar las particiones individuales.
- Una vez que tenemos el Linux funcionando de nuevo, lanzamos el Solaris en la máquina virtual y revisamos
el "/var/adm/messages", buscando indicaciones que nos den una pista sobre la tarjeta Ethernet.
- Una vez localizado el driver, configuramos el sistema para que ponga la IP de la máquina a través de
dicho driver, y la máquina debería responder a los "pings" y estar accesible vía SSH.
Ésto es la teoría. En la práctica... no funciona. Y no funciona por motivos muy misteriosos.
- Activo el arranque por vKVM... y no funciona. No funciona en absoluto. Incluso intentando arrancar
el Linux... Esto empieza a ser un misterio del copón...
- Pruebo a cambiar la partición activa, que era la de Solaris, a Linux. A ver si así vKVM funciona. Pero
nada, sigue sin funcionar. Está claro que en algún momento del camino he hecho algo que no le ha gustado.
- Nuevamente volvemos a empezar desde el principio, con la experiencia ganada. Reinstalamos el sistema
desde cero de nuevo.
- Tras investigar el asunto con detalle, el problema está en vKVM. OVH ha debido tocar algo, y no funciona,
o funciona de forma esporádica, o funciona dependiendo de qué kernel se esté usando. En pocas palabras, no podemos
contar con la funcionalidad vKVM, porque su funcionamiento es irregular y poco confiable.
- Con esta experiencia desastrosa, vuelvo a realizar la instalación completa desde cero, hasta el punto
de poder arrancar el Solaris en modo nativo.
- Nada, no hay forma de arrancar Solaris en modo nativo, aunque funcione perfectamente bajo emulación. Como no
tengo acceso a la pantalla, no tengo ni idea de cual puede ser el problema. Abandono... por ahora.
En caso de que no hubiera habido problema, lo único que quedaría por hacer sería
reconfigurar la máquina
virtual para que use un ISO de arranque por defecto con un GRUB que arranque el Solaris, para evitar el riesgo de arrancar
la máquina virtual y que se inicie Linux de forma inadvertida, lo que corrompería nuestros discos duros
de forma inmediata e irremediable.
Pruebas de instalación bajo VMWARE
Visto que no es posible realizar una instalación nativa, solo queda probar a fondo qué tal funciona
Solaris 10 bajo virtualización. Mi primera elección sería probarlo bajo VirtualBox, por muchos motivos
(por ejemplo, que es lo que mejor conozco y lo que más uso, y que es gratuito y puedo tocar el código fuente),
pero el no poder aprovechar los dos "cores" de la CPU me duele. Podría instalar dos máquinas virtuales Solaris
y repartir los servicios, pero queda el problema de repartir el disco duro, la memoria, etc. Es decir, una máquina
virtual se pasará de recursos y la otra se quedará corta... y el reparto óptimo variaría constantemente.
OVH dispone de varias distribuciones listas para usar virtualización,
si la plataforma hardware utilizada lo permite, que es mi caso.
- Virtuozzo: Esta tecnología es semejante a las "Zonas" Solaris. Es lo más eficiente, pero requiere
un kernel Linux, que no es lo que quiero.
- XEN: Las versiones iniciales de XEN requerían que el sistema operativo virtualizado estuviese
modificado para "colaborar" con el virtualizador. Ésto no es el caso con Solaris 10 (sí con OpenSolaris),
así que tampoco es una opción. Las versiones modernas permiten virtualizar un sistema operativo no colaborador,
si tu hardware lo permite (es el caso), pero la versión Xen de OVH es un poco vieja y la declaran como en
"preproducción".
- VMWARE: Es la opción realmente soportada por OVH. Permite virtualizar Solaris 10 aunque no colabore,
y permite también utilizar los dos cores de la CPU, aparentemente (tengo que probarlo bien). Como puntos
negativos, personalmente no me gusta mucho y, sobre todo, requiere utilizar un cliente específico para
acceder y controlar la instalación. Afortunadamente ya dispongo de dicho cliente en mi máquina, por temas
laborales, aunque me disgusta pensar qué puede pasar si estoy de vacaciones y surge una emergencia
sin mi máquina habitual a mano, en un ordenador prestado, etc.
Los pasos son los siguientes:
- Instalo la distribución VMWARE de OVH. Es un kernel de 32 bits, pero teóricamente es capaz de
ejecutar mi Solaris 10 en 64 bits. Veremos...
- Entro en la máquina. Como antes, elimino el acceso OVH a la máquina.
- "apt-get update", "apt-get upgrade", "apt-get dist-upgrade".
- Es curioso que siendo una distribución pensada para virtualizar, no deje ningún espacio libre
en el disco duro. Elimino la partición "/home", que la emplearé para Solaris. Quito el "/home", actualizo
el "/etc/fstab" y marco apropiadamente las particiones con "fdisk". Reinicio para asegurarme de que todo
funciona.
En el "/home" reside el "home" de VMWARE, que muevo apropiadamente a su nuevo sitio antes
de reutilizar las particiones. Hay que parar también el servicio VMWARE, que arranca por defecto.
Las nuevas particiones no usarán RAID de LINUX; emplearé redundancia ZFS sobre ellas.
Nuevamente me parece muy curioso que el espacio SWAP no se proteja...
- A la hora de crear los discos virtuales, es importante que lo hagamos indicando que son
"independientes", fuera de snapshots VMWARE y similares. Sino no nos dejará alterar su tabla de particiones, amén
de que, en teoría, es más eficiente. En teoría se puede cambiar una vez instalado el disco virtual, pero
en la versión de VMWare que usa OVH ésto no parece funcionar.
- A diferencia de Virtualbox, con VMWARE la máquina virtual ve todo el disco, pero solo puede escribir
en la partición asignada. Es decir, la tabla de particiones debe configurarse con el "fdisk" de Linux.
Hay que afinar un poco, ya que no todas configuraciones de las tablas de particiones son aceptadas por Solaris.
- Creo un directorio en el que residirá el medio de instalación Solaris, etc.
- Es necesario pedir una licencia a VMWARE para crear las máquinas virtuales. La licencia es gratuita, pero
no deja de ser un incordio tener que pasar por el aro, al margen de ir dejando tus datos por ahí... Pido
diez licencias, para curarme en salud.
- Utilizamos el "VMware Server Console" para crear una nueva máquina virtual, 64 bits. Le doy las dos
particiones en los dos discos duros. Le damos dos procesadores (solo tenemos dos Cores; si tuviésemos
más estaríamos en las mismas, ya que VMWare solo soporta una o dos CPUs virtuales). Le doy 3.6 gigas de memoria.
En red, configuro "host-only networking".
- Para poder utilizar la red como dios manda (osea, acceso bidireccional, etc) es preciso
disponer de IPs "failover" de OVH. Dichas IPs no se corresponden a un servidor físico concreto, sino que
se pueden mapear a bocas de los switches arbitrarias, de forma que, en la práctica, podemos mover dichas
IPs de una máquina a otra. Ésto es perfecto para poder montar servicios sobre dichas IPs y, si tenemos los
ordenadores duplicados, simplemente mover la IP a otro ordenador configurado de forma idéntica en caso
de problemas con el original.
En este caso se usan las IPs "failover" para poder dar servicio de red a las máquinas virtuales. No es mala
solución, si podemos mover las máquinas virtuales a otra máquina física. El problema es que solo podemos instalar
tantas máquinas virtuales como IPs failover tengamos. La otra opción es usar NAT, pero no es buena idea
si nuestra máquina virtual va a estar accesible como servidor en Internet.
- Hay que configurar la red del HOST tal y como se describe,
para que la instalación de la máquina virtual sea lo más indolora posible. Si no se hace así, la instalación
detectará IPs duplicadas (debido al "Proxy ARP").
- Ahora procedemos a la instalación del sistema Solaris 10 virtualizado.
A la hora de configurar la red, debemos seguir los pasos del manual ya descrito. En la parte de Solaris,
hay que configurar la ruta por defecto con el comando "route -p add default IPfailover -interface"
- Comprobaciones varias en el Solaris virtualizado:
- Usando el comando "isainfo" compruebo que estamos ejecutando el kernel en modo 64 bits.
- Usando el comando "mpstat", veo que, efectivamente, veo dos CPUs. No estoy seguro de que sean CPUs reales
(es decir, que estén mapeadas a los dos cores), así que creo dos bucles infinitos para comprobar que ambas CPUs
se saturan tanto en el host como en el guest. Efectivamente es el caso.
- Comprobamos que cuando hacemos "flush" a disco realmente se graba en la superficie magnética del
disco duro, y no su caché interna. Para ello usamos el programa python ya indicado con anterioridad.
- Con la experiencia previa, añado un script en el arranque de la máquina Linux para que desactive
la caché de escritura de los discos duros antes de arrancar VMWare. Reinicio y compruebo que se realiza
correctamente.
- Configuro VMWare para que arranque la máquina virtual cuando se arranque el sistema Linux. Funciona bien,
pero hay problemas con la interfaz de red. Aparentemente se arranca la máquina virtual antes de que el kernel
Linux tenga la interfaz de red virtual en funcionamiento. Meto una pausa de 5 segundos entre la activación
de la interfaz de red de VMWare y el arranque de las máquinas virtuales. Parece que es suficiente...
- Reinstalo la máquina virtual de nuevo, asegurándome de configurarlo todo correctamente. Ésta va a ser
la instalación definitiva, que entrará en producción.
Realizo de nuevo todas las comprobaciones anteriores y considero que la instalación está lista para producción.
La pausa de 5 segundos entre levantar la interfaz de red y arrancar la máquina virtual no siempre es
suficiente. En vez de incrementar este tiempo, frenando el arranque sin tener la garantía de que ninguna
cifra funcione siempre, añado el siguiente código al script de arranque, entre levantar la interfaz
y arrancar la máquina virtual.
echo "Pausa para tener red antes de levantar las maquinas virtuales..."
while /bin/true ;
do
/sbin/ifconfig vmnet1 >/dev/null 2>/dev/null;
if [ $? = 0 ]; then
break;
fi;
sleep 1;
done
Lo que hace este código es detenerse hasta que la interfaz esté disponible.
- Pero no lo está: durante la instalación de software nuevo he tenido dos bloqueos del servidor. Entrando por
la consola del VMWare se ven errores de timeout de disco.
- Creo un programa para generar un montón de tráfico de disco, tanto de lectura como de escritura. Dejo
funcionando el programa durante el fin de semana. La máquina funciona a la perfeccion. Mosqueante... En
situaciones así es preferible que las cosas fallen cuanto antes y de forma consistente, no de forma
esporádica y errática...
- Pensando un poco, los cuelgues fueron en momentos de alta carga tanto de disco como de red. Así que me pongo
a copiar ficheros de varios gigabytes de una máquina a otra... Efectivamente, la máquina se cuelga tras un rato.
En la consola se ven errores de timeout de disco, pero tampoco puedo llegar a la máquina virtual por red, así que el
problema real afecta a varios subsistemas. ¡Qué puto desastre!.
- La versión de VMWare que estamos usando es la 1.0.8. Ya hay una 1.0.9, pero parece que los problemas
solucionados son básicamente de seguridad. También hay una versión 2.0.1 que tiene buena pinta, ya que
parece soportar mejor sistemas con virtualización por hardware. Pruebo a instalar la versión 2.0.1 bajo el
sistema OVH "normal", aunque cambiando el virtualizador sería buena idea instalar un kernel propio 64 bits.
Ya me preocuparé de eso si todo funciona bien...
Aparentemente las versiones recientes de Solaris 10 están soportadas de forma oficial en VMWare 2.0.1. Veremos...
La instalación de la actualización no es inmediata,
pero no tiene mucha complicación para alguien experimentado. El mayor problema es que los fuentes que tengo
no se corresponden EXACTAMENTE con el kernel que está funcionando, pero se puede meter a presión. No me preocupa
demasiado, porque ya que estoy tocando tantas cosas, acabaré metiendo Ubuntu LTS con mi propio kernel.
La verdad es que cuesta lo suyo. Además, necesito un cliente nuevo para la administración remota, y toda la
gestión de red ha cambiado. Al final, cansado del asunto, añado un script propio en el arranque del Linux
para que cree la ruta apropiada, manualmente. Tengo que hacer lo mismo con el Proxy ARP, ya que por defecto el
sistema intenta configurarse antes de que la interfaz de red virtual haya sido inicializada.
- Algunas "putadillas":
Al menos parece que la máquina virtual ya no se inestabiliza cuando el tráfico de red es elevado.
Algo es algo.
¿Instalación definitiva?
Con la experiencia ganada es hora de realizar una instalación completa desde cero. Los antecendetes son:
- No conseguimos arrancar Solaris 10 de forma nativa en la máquina. No hay más remedio, por tanto,
que utilizar máquinas virtuales.
- VirtualBox no soporta dos cores en el Guest. Lástima, porque sería mi primera opción.
- Si usamos VMWare, hay que usar la versión Server 1.0.x para que nos permita utilizar particiones físicas de disco.
- Una vez instalado el sistema, podemos migrar a la versión Server 2.0.x, que nos permite usar
la máquina virtual con particiones físicas sin problemas, aunque no nos permita reconfigurarla.
Los pasos a dar van a ser los siguientes:
- Reinstalamos la máquina Linux de nuevo. Usamos Ubuntu Server 8.04 LTS 64 bits. Usamos esta versión
porque es una LTS (Long Time Support). Seleccionamos el particionado por defecto: 10 gigas de "/" (RAID 1),
740 gigas de "/home" (RAID 1) y un giga de Swap (en dos particiones de 512 megas sin redundancia...).
- Eliminamos la clave de acceso de OVH y su código en "/etc/crontab".
- Actualizo el sistema a la última versión a través de "apt-get update", "apt-get upgrade", "apt-get
dist-upgrade". Reiniciamos para asegurarnos de que está todo OK.
- Instalamos GRUB:
- "apt-get install grub".
- "mkdir /boot/grub".
- "update-grub".
- "cat /boot/grub/menu.lst".
title UBUNTU 8.04 (Kernel OVH)
root (hd0,0)
kernel /boot/bzImage-2.6.27.10-xxxx-grs-ipv4-64 root=/dev/md1
- "apt-get install mdadm".
- "grub-install /dev/md1".
Reiniciamos y comprobamos que el sistema arranca correctamente.
- "apt-get install dkms".
- Desmontamos "/home", lo eliminamos de "/etc/fstab". Usamod "fdisk" para marcar la partición (en ambos discos)
como "Solaris" (osea, tipo "bf").
- El kernel OVH no nos sirve, así que hacemos "apt-get install linux-image". Este comando ya
actualiza el "menu.lst" de GRUB. Reiniciamos y nos aseguramos de que funciona y de que ha cargado el
kernel apropiado.
Si faltase algún driver, se puede coger la configuración OVH y recompilar el kernel nuevo con ella,
activando las funcionalidades que necesitamos (especialmente la carga de módulos). En mi caso la
configuración por defecto de la distribución ya soporta todo el hardware que necesito de esta máquina.
- Descargamos la versión 1.0.9 de VMware Server. No hay versión de 64 bits, así que me bajo la de 32.
Espero que los módulos kernel sean compatibles con un kernel de 64 bits... En la documentación dice que
el soporte es "experimental", pero a mí me basta con que permita instalar el Guest, ya que en producción
usaré VMware Server 2.0.1.
- Me bajo el "tar.gz". Los descomprimimos y ejecutamos el instalador.
- Necesitamos varias librerías, varias de ellas de 32 bits. Esto es un problema serio.
- Volvemos a realizar la instalación, pero en esta ocasión instalamos la versión de 32 bits. La idea
es instalar la máquina virtual en 32 bits, y luego reinstalar el sistema de nuevo en 64 bits y reusar la máquina
virtual ya instalada.
- Instalamos el sistema operativo de OVH preparado para VMWare, tal cual. Así no nos tenemos que
preocupar de nada en la primera instalación.
- Tomo nota de los datos de particiones, para ver dónde está todo. Luego desmonto el "/home" (copiando
los datos de vmware que hay dentro). lo elimino del "/etc/fstab" y reconfiguro la tabla de particiones
para asignarla a "Solaris".
Los datos de particiones de ambos discos son iguales, y son:
Device Boot Start End Blocks Id System
/dev/sda1 * 1 2550 20482843+ fd Linux raid autodetect
/dev/sda2 2551 91071 711044932+ fd Linux raid autodetect
/dev/sda3 91072 91201 1044225 82 Linux swap / Solaris
Reinicio la máquina.
- Creo la máquina virtual Solaris, sobre las particiones que le he indicado, pero no instalo nada aún.
Usamos el modo "bridge" de red, y hay que recordar configurar los discos para que
sean persistentes y no hagan caché de escritura. De momento no tocamos la caché de disco duro
del Host porque esta instalación es temporal y vamos a reinstalar el Linux más tarde.
- Una vez configurada la máquina virtual, iniciamos la instalación. Una vez que la instalación empieza
a copiar ficheros, paramos la máquina virtual. Ésto es así porque al reinstalar el Linux vamos a perder
los datos de esta partición, así que realizar la instalación de Solaris es una pérdida de tiempo. Lo que
queremos es comprobar que la tabla de particiones sea válida para Solaris.
Es posible que la instalación requiera cambiar la tabla de particiones de Linux, ya que Solaris es más
"delicado". Si es así, es importante tomar nota de todos los valores finales del "fdisk". También es importante
reiniciar el servidor antes de utilizar la nueva tabla de particiones.
En mi caso debo descartar la última pista del disco duro, asignada al SWAP, así que debo desactivar el SWAP
con "swapoff -a", cambiar el formato con "fdisk" (en ambos discos duros), recrear el swapping mediante
el comando "mkswap" (en ambos discos), reiniciar el ordenador y comprobar que todo está bien con "swapon -s"
y "free".
Es importante comprobar la instalación en este punto por si necesitamos cambiar la tabla de particiones. Si
la instalación de Solaris la hacemos tras reinstalar el Linux a la versión de 64 bits con VMWare Server 2.0.1,
y no le gusta la tabla de particiones, tendremos que empezar de nuevo desde el principio. Adivinad quien
ha pasado por ello... :-)
Al final la configuración que me queda es:
Disk /dev/sda: 750.1 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 2550 20482843+ fd Linux raid autodetect
/dev/sda2 2551 91071 711044932+ bf Solaris
/dev/sda3 91072 91200 1036192+ 82 Linux swap / Solaris
- Una vez abortada la instalación, copiamos el "/home/vmware" (que es donde están configurados los discos virtuales, etc) a otra máquina
distinta.
- Reinstalo otra vez el Ubuntu LTS 64 bits. El punto importante es mantener exactamente el mismo particionado
que en la instalación anterior, para poder utilizar la misma configuración de discos virtuales. Ésto
es fundamental. Dado que el panel de control no permite afinar a nivel de pista de disco duro, se hace lo
posible. El ajuste fino lo hacemos luego con un "fdisk", una vez instalado.
Hay que hacer todos los pasos que hicimos antes, como actualizar el sistema, arrancar con GRUB, etc.
- Copio el "/home/vmware" que habíamos grabado en otra máquina. Ésto nos permite mantener la configuración
de la máquina virtual. Lo volvemos a dejar en su sitio.
- "apt-get install make", "apt-get install linux-source", "cd /usr/src", "tar xvfj linux-source-2.6.24.tar.bz2",
"cd linux-source-2.6.24", "make mrproper", "cp /boot/config-2.6.24-23-generic .config", "make -j 2".
Lo necesitamos para compilar los módulos kernel de VMware Server.
- Instalo VMware Server 2.0.1, versión 64 bits.
- Cuando nos pide el path del código fuente del
kernel, ponemos "/usr/src/linux-source-2.6.24/include". Se nos queja de que esos fuentes no coinciden
con el kernel real que tenemos. Editamos el fichero "/usr/src/linux-source-2.6.24/include/linux/utsrelease.h"
a mano, para encajar las versiones.
- A la pregunta de "In which directory do you want to keep your virtual machine files?", ponemos
"/home/vmware/Virtual Machines", que es donde tenemos la configuración de la máquina virtual que hemos creado
hace un rato.
- Reiniciamos el Linux. Nos aseguramos de que corre el kernel correcto y que existen las interfaces
"vmnet" en el sistema.
- "apt-get install ntp". Es conveniente tener la hora del ordenador de forma correcta. Reconfiguro el
cortafuegos para no exportar mi servicio NTP al exterior.
- Para entrar en la máquina virtual, se puede usar el navegador al puerto 8222 (HTTP) o 8333 (HTTPS), o
bien usamos el "VMware Infraestructure Client", indicando el puerto 8333 (separado con un ":" de la IP).
- Instalamos Solaris 10 virtualizado. La configuración es:
- Activamos compresión en el "pool" ZFS. Hay que usar la compresión por defecto, que es la única
soportada por el arranque GRUB.
- En el dataset "/var" activamos compresión GZIP-9.
- Instalamos el "companion".
- Cambiamos el "/etc/hosts" para quitar el nombre de la máquina.
- Editamos el fichero "/etc/hostname.e1000g0" y ponemos "IPfailover netmask 255.255.255.255".
- Escribimos "route -p add default IPfailover -interface".
- En el host Linux añadimos este fichero de arranque, tras el VMWARE:
#!/bin/sh
/sbin/hdparm -W 0 /dev/sda
/sbin/hdparm -W 0 /dev/sdb
while /bin/true ;
do
/sbin/ifconfig vmnet1 >/dev/null 2>/dev/null;
if [ $? = 0 ]; then
break;
fi;
sleep 1;
done
/sbin/route add IPfailover dev vmnet1
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/vmnet1/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth0/forwarding
echo 1 > /proc/sys/net/ipv4/conf/vmnet1/forwarding
- Reiniciamos, y el Guest ya debería tener red.
- Creamos un dataset nuevo para albergar "/usr/local", y copiamos ahí cosas que tengo instaladas
en otras máquinas.
- En "/etc/profile" ponemos los siguientes paths: "/usr/local/sbin/:/usr/local/bin:/usr/sfw/sbin:/sbin:/usr/sbin:/opt/sfw/sbin:/usr/sfw/bin:/opt/sfw/bin:/opt/sfw/lib/bin/:/usr/openwin/bin:/usr/sadm/bin:/bin:/usr/bin/:/usr/openwin/bin:/usr/sadm/bin:/usr/ucb".
En el mismo fichero cambiamos el path del MAN a "/usr/local/share/man:/usr/local/man:/usr/dt/man:/usr/man:/usr/openwin/share/man:/usr/share/man".
Por último, en el mismo fichero, cambiamos el PAGER a "less".
Añadimos nuevos PATHs para el enlazado dinámico, con
"crle -c /var/ld/ld.config -l /usr/local/lib:/lib:/usr/lib" y
"crle -64 -c /var/ld/64/ld.config -l /usr/local/lib/64:/lib/64:/usr/lib/64".
- Activamos el servicio NTP en Solaris. Su configuración está en "/etc/inet/ntp.conf". Copio una
configuración de otra máquina. Se activa con "svcadm enable ntp". También hay que cerrar el cortafuegos,
por el mismo motivo que en el Host.
- Registro el servidor con Sun, de forma que pueda descargar parches. Es necesario registrarse en Sun, de
forma gratuita.
Para ello creamos un fichero "/z-RegistrationProfile.properties", con el siguiente contenido:
userName=USUARIO
password=CLAVE
hostName=HOST
subscriptionKey=
portalEnabled=false
proxyHostName=
proxyPort=
proxyUserName=
proxyPassword=
Luego ejecutamos "sconadm register -a -r /z-RegistrationProfile.properties".
- Actualizamos el sistema con los últimos parches, con "smpatch update". Ésto puede llevar un buen rato.
- Tras actualizar por completo, y comprobar que todo parece funcionar correctamente, hacemos un "snapshot"
del sistema con "zfs snapshot -r datos/ROOT@20090604-13:48" y "zfs snapshot datos@20090604-13:48". Ésto nos permitirá experimentar sin riesgos, ya
que podemos recuperar el sistema al estado actual con un único comando. Obsérverse que hago un segundo
snapshot de "datos", de forma no recursiva, no solo el sistema operativo en sí. De esta forma protejo también el menú de arranque GRUB de
Solaris, importante para mantener la consistencia si creamos nuevos "Boot Environments".
- Hacemos las pruebas de velocidad de grabación, para asegurarnos de que los "flush" de caché de escritura
de disco duro realmente se están haciendo. Me salen 105 transacciones por segundo, lo que es un pelín bajo
pero razonable para este hardware.
- Haciendo unas pruebas de carga agresivas, la virtualización parece funcionar aceptablemente bien con
la excepción del rendimiento de la red, donde la velocidad es lenta. Otro problema serio es el control del reloj
del Guest, ya que el NTP sufre bastante para mantener el reloj razonablemente sincronizado y no siempre lo consigue.
Y a mí esa me parece una funcionalidad crítica.
- Vamos a intentar actualizar el hardware de la máquina virtual de la versión 4 a la versión 7. Como ésto
es una operación delicada, hacemos copia primero del directorio donde reside la configuración de la máquina virtual,
para poder dar marcha atrás si surgen problemas.
Al actualizar el hardware me desaparece la tarjeta de red e1000 de la máquina virtual.
Tras la actualización, hay configuraciones que no puedo tocar porque el cliente que estoy usando no soporta
la nueva configuración. No hay forma humana de descargar un cliente nuevo, así que paro el sistema y recupero
la copia, para dejarlo todo como estaba.
- Ahora probamos a instalar las "VMWare Tools" en el Guest. No es arriesgado porque hemos hecho un snapshot
ZFS, así que podemos darle para atrás en cualquier momento.
Entre otras cosas se instala un nuevo driver de red, llamado "vmxnet0". Es de suponer que su rendimiento
es mejor que la emulación de una interfaz hardware virtualizada. No obstante, no funciona. El driver está instalado
correctamente en "/kernel/drv/vmxnet" y "/kernel/drv/amd64/vmxnet", pero intentar levantar la interfaz
("ifconfig vmxnet0 plumb") no tiene éxito. Un "dladm show-dev" tampoco tiene éxito.
De todas formas, buscando por Internet parece que el driver "e1000" es la opción recomendada para el
kernel Solaris de 64 bits, así que no me preocupo más del asunto.
Doy para atrás a la instalación de las "Tools" recuperando el snapshot anterior, mediante "zfs rollback".
Tal vez sería buena idea probar la versión 1.0.9 de VMware Server pero instalando estos drivers. Me parece
una versión más pulida que la 2.0.1, tiene fama de ser más rápida, y los problemas que tenía con ella eran
de red... Tal vez estos drivers lo solucionasen. Pero llevo ya tres semanas con este asunto y no puedo perder
más tiempo. Necesitaría una segunda máquina para hacer pruebas en ella mientras ésta está en producción.
- El tema de NTP me preocupa, pero de momento puedo vivir con ello. Es algo que ver en el futuro.
- Otro problema muy feo es el siguiente: VMware Server 1.0.* permite configurar una máquina virtual
como "autoarrancable" cuando se reinicia el Host. Esa funcionalidad, básica, no existe en VMware Server 2.0.*.
Hay que añadir lo siguiente al final del script de arranque del sistema Host que creamos antes:
/usr/bin/vmrun -T server2 -h https://127.0.0.1:8333/sdk/ -u USUARIO -p CLAVE start "[standard] PATH.vmx"
De esta forma la máquina virtual se arranca automáticamente cuando arrancamos el Host.
- Ahora hacemos prueba de carga... y no nos sirve. El rendimiento de la virtualización a nivel de usuario es bueno, pero
cuando la CPU está en modo sistema, el rendimiento es penoso. Eso hace que, por ejemplo, bajo carga
de disco elevada, el rendimiento de la red sea de risa, teniendo tiempos de "ping" de varios segundos...
¡¡dentro de la misma máquina!!. Es evidente que no puedo poner la máquina en producción bajo estas
circunstancias...
Es de señalar que este problema de rendimiento no se da en otros sistemas como, por ejemplo, emulando
MS Windows, ya que su emulación está mucho más refinada (por ser de mayor interés comercial), dispone de
drivers nativos, etc.
- Ya estaba pensando probar VirtualBox (que es de Sun, el fabricante de Solaris) aunque pierda
uno de los "cores", cuando veo que OVH ha añadido la opción de instalar un dispositivo KVM físico real
a las máquinas dedicadas, por un coste mensual razonable. Probémoslo...
Historia
- 02/jun/09: ¿Instalación definitiva?
- 25/may/09: Pruebas de instalación bajo VMWARE.
- 20/may/09: Llegamos a la última parte, donde intentamos que Solaris arranque de forma nativa.
- 13/may/09: Primera versión de esta página.
©2009
jcea@jcea.es
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
Blog personal: El hilo del laberinto
