Archives pour l'étiquette boot

Faire tourner QEMU en rescue sur un serveur Kimsufi KS-2

Il s’agit ici de faire tourner QEMU dans le mode rescue d’un serveur dédié Kimsufi, en l’occurrence un KS-2, et démarrer sur le disque dur du serveur.

Utiliser QEMU sur un Kimsufi peut avoir plusieurs intérêts, par exemple installer soi-même un OS via QEMU directement sur le disque dur, plutôt que d’utiliser les installations fournies par OVH. Sur les forums Kimsufi, on trouve un exemple avec une installation de Windows.

Une autre utilisation de QEMU est de démarrer depuis le disque dur pour débuguer certains problèmes dans la séquence de démarrage du serveur avec une connexion VNC,  vu qu’on n’a pas de clavier+écran. C’est ce cas de figure qui m’a intéressé. Mon problème était que, suite à l’installation maison d’une distribution sur mon Kimsufi, la machine était bloquée quelque part dans le boot, avant que je puisse avoir une connexion SSH, sans que je puisse savoir où.

Le KS-2 tourne sur un CPU Atom N2800 qui ne supporte pas la virtualisation hardware, on ne pourra donc pas utiliser QEMU avec KVM. En conséquence, ça va être lent : j’ai mis environs 1/2 heure pour démarrer une Ubuntu Server.

Pour commencer :

  • désactiver le monitoring dans le manager Kimsufi (pour éviter les mails d’alerte)
  • sélectionner le démarrage en rescue-pro
  • redémarrer le serveur
  • se connecter en SSH avec le mot de passe reçu par mail

Le rescue est un système Linux complet qui tourne sur le serveur sans toucher au disque dur. Certains répertoires sont montés depuis le réseau et sont en lecture seule, ce qui ne permet pas d’installer des programmes. La première étape est donc de s’en débarrasser en déplaçant tout ça dans un tmpfs en RAM que l’on montera à la place des répertoires réseau :

# mount -t tmpfs -o size=2000m tmpfs /mnt
# mkdir /mnt/var
# mkdir /mnt/var/cache
# mkdir /mnt/var/lib
# mkdir /mnt/var/run
# mkdir /mnt/usr
# mkdir /mnt/lib
# rsync -a /var/cache/ /mnt/var/cache/
# rsync -a /var/lib/ /mnt/var/lib/
# rsync -a /var/run/ /mnt/var/run/
# rsync -a /usr/ /mnt/usr/
# rsync -a /lib/ /mnt/lib/
# mount -B /mnt/var/cache /var/cache
# mount -B /mnt/var/lib /var/lib
# mount -B /mnt/var/run /var/run
# mount -B /mnt/usr /usr
# mount -B /mnt/lib /lib

Note : le KS-2 dispose de 4Go de RAM. Le tmpfs fait 2Go pour garder une bonne marge en particulier pour QEMU.

On peut ensuite mettre à jour et installer QEMU :

# apt-get -y update
# apt-get -y --force-yes upgrade
# apt-get -y install qemu

Tout est prêt ; on peut lancer QEMU :

# qemu-system-x86_64 -net nic -net user,hostfwd=tcp::60022-:22 -m 1024M -alt-grab -localtime -cpu core2duo -smp 2 -usbdevice tablet -hda /dev/sda -vnc :0

Note : l’option hostfwd=tcp::60022-:22 permet de rediriger le port 60022 de l’hôte (le serveur en rescue) vers le port 22 de l’invité (la VM), ce qui peut être utile pour se connecter en SSH sur la VM.

Sur un poste client (Ubuntu Desktop par exemple), on va créer un tunnel SSH entre le port local 5901 et le port 5900 du serveur en rescue. Ce tunnel va permettre de faire transiter la connexion VNC de manière sécurisée entre le client VNC et le serveur.

$ ssh -L 5901:localhost:5900 -XC root@[server-IP]

Dans un autre terminal toujours sur le poste client, on peut lancer le client VNC (Vinagre par exemple sur Ubuntu) :

$ vinagre localhost:5901

Plus le temps est court entre le lancement de QEMU sur le serveur et le lancement du client VNC, plus on arrive tôt dans la séquence de boot.

Pour arrêter la machine virtuelle, un simple CTRL+C sur le terminal où tourne QEMU suffit, mais si c’est possible, arrêter proprement la machine sera plus sain.

Sources :