QEMU on Zwindler's Reflection

Lancer des containers Docker avec Proxmox VE (et LXC)

Mon, 07 Nov 2022 06:30:00 +0200

Introduction

J’ai trouvé plusieurs tutos pour installer Docker (engine) à l’intérieur d’un container LXC sous Proxmox VE pour ensuite lancer des containers Docker dedans. Le souci c’est que vous devez vous logger dans le container LXC avant de pouvoir interagir avec vos containers Docker.

On peut aussi installer Docker directement sur Proxmox VE mais ce n’est pas trop conseillé et on n’a pas la facilité d’usage de LXC avec la GUI de Proxmox.

Et en fait, il se trouve qu’on peut lancer des images Docker comme l’OS d’un container LXC et ainsi avoir des Docker pilotés par Proxmox. On aura donc pas un comportement 100% identique à si vous aviez fait un docker run sur votre machine.

Cependant, on gagnera un échange un container totalement identique à vos autres containers LXC de votre cluster (avec toutes les fonctions associées) mais lancé avec une image Docker.

Mais d’abord je vous propose de revenir un peu en arrière avant de vous montrer comment…

Contexte

Vous le savez, je fais du Proxmox VE depuis un moment. Proxmox VE est une super distribution clé en main et production ready de virtualisation de serveurs (c’est même de l’hyperconvergé si on active la partie Ceph).

Il y a plein de petites choses que j’aime avec Proxmox VE, et l’une d’elle est qu’on peut créer des containers Linux avec LXC plutôt que des machines virtuelles QEMU. J’avais fait un article pour en parler.

A l’usage (sauf paramétrage kernel spécifique) le container LXC se comporte de manière strictement identique à une VM dans Proxmox, mais pour une fraction des ressources ! On a un OS, on installe des applications dessus, comme une VM.

Un frontal nginx pour plusieurs applications. Le container LXC complet ne consomme que quelques Mo

Certes c’est beaucoup moins bien isolé qu’une vraie VM (car c’est un container, on est isolé des autres processus, mais on tourne sur le kernel de l’hyperviseur directement).

Mais avec si peu de besoins en ressources, je peux héberger de nombreuses petites applications dans des contextes différents avec de très petites machines physiques (des Atom 4Go de RAM à 6€ par mois chez OneProviders) ce qui serait impossible avec une vraie VM.

C’est bien, mais pas suffisant

Cependant, LXC n’est pas la techno de containerisation la plus connue/hype. Depuis des années sur le forum, à chaque fois que des gens demande le support de Docker dans Proxmox VE, on les envoie balader. Pas toujours très gentiment d’ailleurs…

Pourtant, il y a plusieurs raisons pour avoir envie de lancer des containers Docker sur son infra Proxmox :

D’abord, Docker n’est pas autant des workloads stateless et/ou éphémères qu’on le croit. Beaucoup d’applications containerisées auraient toute leur place sur un cluster de virtualisation.
Ensuite parce que beaucoup d’éditeurs de logiciels sont devenus faignants. Certains ne gèrent plus les processus d’installation (ou alors juste sur un OS) et fournissent juste une image Docker qu’ils maintiennent mise à jour.

On doit donc se contenter de VMs dans Proxmox pour lancer des containers Docker (cf mon point du début).

LXC supporte les images OCI

Coup de théâtre. Il y a quelques jours, j’ai découvert que LXC, le moteur de containerisation de Proxmox VE, était compatible avec le format OCI.

buzzwrd.me - Creating LXC containers from docker and OCI images

Pour ceux qui ne connaissent pas OCI, il s’agit d’une organisation visant à créer un standard pour unifie la façon de stocker les containers.

The Open Container Initiative is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes. opencontainers.org/

Et Docker respecte ce format : on peut donc théoriquement lancer depuis LXC des containers dont l’image de base est une image Docker.

Je suis profondément choqué (Réf “Jean François Coppé” pour ceux qui n’ont pas le mème)

Bon, quand est-ce qu’on commence ?

Disclaimer: ce qui suit est de la bidouille. Rien n’est supporté et je ne le conseille pas en production. Il est probable qu’il y ait aussi des limitations (notamment pour ce qui est stockage).

D’abord, il manque quelques dépendances pour que la fonction OCI de LXC soit utilisable sous Proxmox VE :

sudo apt install skopeo umoci jq

Ensuite, par défaut, les containers LXC s’attachent à un bridge linux qui s’appelle lxcbr0. Cependant ce bridge n’existe probablement pas sur votre installation de Proxmox VE (pas installé par défaut).

En quick and dirty, on peut juste remplacer le nom par défaut, même si idéalement il faudrait trouver le flag dans la CLI pour changer le bridge. En fonction de comment vous avez configuré le réseau dans votre serveur Proxmox VE, vous allez probablement utiliser vmbr0 ou vmbr1 :

sed -i 's/lxcbr0/vmbr1/g' /etc/lxc/default.conf

Maintenant qu’on a tout, on peut lancer nos containers LXC à partir d’images docker. Ici je lance l’image officielle alpine:latest, mais j’aurais pu prendre n’importe quelle autre :

lxc-create 500 -t oci -- --url docker://alpine:latest

J’ai créé un container appelé “500” (car les VMs et les containers LXC dans proxmox VE sont appelés avec des nombres). L’image est téléchargée puis le container créé :

On peut maintenant le démarrer (avec lxc-execute on lance le container et ouvrir un prompt directement dedans, mais on a aussi lxc-start et lxc-attach)

lxc-execute 500

Tel quel, Proxmox VE ne sait pas que notre container existe et il n’apparaitra pas dans l’UI. Mais ça fonctionne ;-).

Bonus

On peut même tricher et faire croire à Proxmox que c’est un container LXC qu’il a créé lui-même en créant un fichier 500.conf, dans le dossier /etc/pve/lxc/

Les seules lignes obligatoires sont les suivantes :

arch (amd64 sauf si vous êtes sur ARM)
cores (la limite de CPUs à imposer au container)
hostname
memory (la limite de RAM à imposer au container)
ostype
rootfs

Une fois le fichier créé, automatiquement le container apparait dans la liste des VMs de l’hôte. On peut le démarrer et ça fonctionne :)

Le container pourra être démarré, arrêté, etc. Le tout depuis la GUI de Proxmox VE :)

Have fun!

Source

Mieux migrer ses VM de Proxmox VE vers XCP NG (part 2)

Mon, 08 Aug 2022 06:00:00 +0200

Résumé des épisodes précédents

Dans l’article d’il y a 2 semaines (Migrer une VM de Proxmox VE vers XCP NG), j’ai introduit très brièvement de XCP-NG (un OS clé en main pour faire de la virtualisation, sur une base de Xen / XenServer) et déroulé un tuto pour récupérer une VM sur Proxmox VE et l’importer dans XCP-NG.

Pour faire court, les étapes étaient les suivantes :

Récupération du disque virtuel sur Proxmox VE
Transformer le disque virtuel en VHD
Le transférer sur le serveur XCP-NG
Créer un disque dans XenOrchestra (l’UI de XCP-NG, pour faire simple)
Importer le contenu du VHD dans le disque vide qu’on a créé dans l’UI
Créer une VM dans l’UI et lui affecter le disque

Faire mieux

Dans le cadre d’un PoC avec une poignée de VMs, ça me parait totalement acceptable comme méthodologie (même si c’est un peu fastidieux) mais dans le cadre d’une migration, c’est difficilement scalable.

Note : Vates (l’entreprise qui édite XCP-NG) accompagne ses clients pro dans cette étape. A ma connaissance, ils travaillent également sur de l’outillage pour faciliter les transferts, mais Proxmox VE ne sera probablement pas la première “plateforme source” qui sera supportés par ce genre d’outils.

Dans cet article, je vais donc vous parler d’une méthode alternative qui m’a été conseillée par les gens de chez Vates pour faciliter cette migration, et plus particulièrement les étapes suivantes :

Le transférer sur le serveur XCP-NG
Créer un disque dans XenOrchestra (l’UI de XCP-NG, pour faire simple)
Importer le contenu du VHD dans le disque vide qu’on a créé dans l’UI

Because I’m API 🎶

Clap along if you feel like that’s what you wanna do

Vous l’avez deviné, on va passer par l’API de Xen Orchestra pour se faciliter la tâche. En effet, on va pouvoir rassembler les 3 actions ci dessus en seul appel via cURL !

Même s’il y a un petit prérequis (à faire une fois), ça sera quand même beaucoup plus scalable pour bouger plusieurs VMs.

You token to me?

[EDIT] Depuis la version 5.72 de Xen Orchestra, il est possible de récupérer un token directement dans la Web UI (cf ce post)

En lisant la documentation de la REST API (paragraphe authentication), on apprend, sans surprise, que la première chose à faire est de récupérer un token permettant d’authentifier nos futures requêtes.

On comprend ensuite que pour faire ça, on va avoir besoin d’un tool qui s’appelle xo-cli.

Si on suit la doc, il “suffit” d’installer ce module via npm.

npm install xo-cli

Bon… moi j’ai pas envie d’installer npm sur mon poste donc j’ai fais une image Docker cracra pour ça ;-).

FROM node

WORKDIR /app

RUN npm install --global xo-cli

ENTRYPOINT ["xo-cli"]

Le Dockerfile est disponible ici et l’image docker buildée est disponible là.

Depuis son poste (en remplaçant évidemment @IP.Xen.Orchestra par l’IP de votre serveur XenOrchestra, admin@admin.net par votre login)

docker run -it xo-cli --createToken --allowUnauthorized @IP.Xen.Orchestra admin@admin.net Password: ************
Successfully logged with admin@admin.net
Authentication token created xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Si tout s’est bien passé, on récupère un token qu’on garde précieusement pour nos futures requêtes.

champion de cURLing

De retour sur la documentation de l’API REST (paragraphe VDI import), on trouve tout ce qu’il nous faut pour “crafter” notre requête cURL.

A minima, on va avoir besoin de UUID de notre storage. Pour rappel, vous pouvez trouver ça dans l’UI.

Si vous avez la flemme, vous pouvez aussi utilisez l’API REST pour récupérer les IDs des storages avec la requête suivante :

curl \
 -k -b authenticationToken=xxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxx \
 https://@IP.Xen.Orchestra/rest/v0/srs\?fields=name_label
[
 ...
 {
 "name_label": "Local storage",
 "href": "/rest/v0/srs/bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
 }
]

Depuis votre machine Proxmox VE (ou tout autre machine ayant directement accès au disque à exporter/importer), vous pouvez donc maintenant directement lancer la commande suivante :

~# curl -X POST -k -b authenticationToken=xxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -T toto.vhd 'https://@IP.Xen.Orchestra/rest/v0/srs/bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb/vdis?name_label=testexport.vhd' | cat

A l’issue de l’opération, vous allez récupérer l’UUID du disque sur XCP-NG, déjà disponible pour la construction de la VM côté Xen Orchestra.

Conclusion

Avec cette méthode, une fois qu’on a un token, l’opération d’export/import Proxmox VE => XCP-NG devient donc suivante :

Récupération du disque virtuel sur Proxmox VE (en gros retrouver le disque)
Transformer le disque virtuel en VHD
Importer et créer le disque dans XCP-NG via un cURL
Créer une VM dans l’UI et lui affecter le disque

C’est déjà beaucoup plus sympa si vous avez plusieurs VMs à bouger. L’axe d’amélioration suivant est, à mon avis, de créer directement la VM avec le bon disque.

A date, ce n’est pas possible avec l’API REST (vu avec Vates), mais ça serait possible avec l’API JSON-RPC (sur laquelle se base l’UI de XenOrchestra et xo-cli). Ca sera donc mes prochaines investigations ;).

D’ici là, have fun :)

Bonus - Importer des RAW directement

Depuis la toute dernière version de Xen Orchestra, il est aussi possible d’importer directement des disques au format RAW (en rajouter le paramètre “raw” dans l’appel à l’API).

Dans mon cas, c’est mon format de disques puisque tout est stocké en RAW sur mon storage ZFS Proxmox VE, donc en théorie on peut sauter une étape de plus, à savoir :

Transformer le disque virtuel en VHD

Avec la requête suivante :

curl -X POST -k -b authenticationToken=xxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -T toto.img 'https://@IP.Xen.Orchestra/rest/v0/srs/bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb/vdis?raw&name_label=testexport.raw' | cat

Attention aux limitations, cependant :

Après le soucis du raw c’est que tu vas pas pouvoir profiter du copy on write, donc exit les snapshots (en l’état actuelle de la stack de storage, smapiv1)

Migrer une VM de Proxmox VE vers XCP NG

Sun, 24 Jul 2022 12:00:00 +0000

Retour de la virtualisation

Ca fait quelques mois que je n’ai pas parlé de virtualisation donc forcément, ça me démange un peu ;).

Si vous suivez ce blog depuis quelque temps, vous savez pourtant que j’ai pas mal roulé ma bosse avec Proxmox VE, un OS clé en main de virtualisation KVM (mais aussi de containerisation LXC, on en parle tellement peu). Sans aller jusqu’à dire que j’en ai fait le tour (a-t-on jamais fait le tour d’une techno ?), je commence à manquer de choses à tester avec mon lab perso.

L’an dernier, j’ai discuté avec les équipes de Vates SAS à OSXP 2021, une boite qui publie une autre distribution open source dédiée à la virtualisation : XCP-NG (mais basée sur XenServer).

J’en avais déjà entendu parler sur Twitter (coucou Cécile) donc j’étais un peu curieux. Mais j’étais aussi un peu sceptique, ma dernière expérience de XenServer datant de 2011.

Dans cet article, je ne vais pas rentrer dans une comparaison des fonctionnalités ni des avantages et inconvénients de XCP-NG par rapport à Proxmox VE. Je n’ai pas encore assez testé pour me faire une idée pertinente (ça viendra).

En revanche, je peux vous donner un premier avant goût de la solution via un petit tuto pour vous aider à migrer des VMs de l’un à l’autre, si jamais l’envie vous prend de tester.

Prérequis

Dans ce tutoriel, je pars du principe que vous avez :

d’un côté, une machine virtuelle QEMU, hébergée par un Proxmox VE, à copier/migrer
de l’autre, un serveur sous XCP-NG, dans le même LAN, gérée par XenOrchestra (l’équivalent du vCenter de VMware, pour ceux à qui ça parle)

Note: sauf erreur de ma part, on a pas de solution clé en main pour migrer un container LXC vers XCP-NG (même si XenServer gère les containers Xen, aussi appelé virtualisation PV). Trouver comment migrer ces workloads LXC sera peut-être l’objet d’un prochain article.

Pour le reste du tutoriel, on va grosso modo suivre la documentation officielle disponible ici, mais avec quelques modifs et surtout un peu plus de détails.

Option ZFS

Note: J’installe mes serveurs Proxmox VE avec ZFS comme stockage. Ca a plein d’avantages, notamment celui de me donner la possibilité de faire, à peu de frais, un PRA avec une réplication asynchrone des machines virtuelles de mon cluster. Cela induit par contre une petite difficulté complémentaire (vous allez voir c’est léger). Vous pouvez sauter cette étape si vous n’utilisez pas ZFS.

Pour rappel (je ferai aussi un article dédié à ça), avec ZFS j’ai 2 types de disques.

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 213G 15.9G 112K /rpool
rpool/ROOT 6.32G 15.9G 96K /rpool/ROOT
rpool/ROOT/pve-1 6.32G 15.9G 6.32G /
rpool/data 2.84G 15.9G 2.84G /rpool/data
rpool/subvol-201-disk-0 3.43G 4.57G 3.43G /rpool/subvol-201-disk-0
rpool/subvol-301-disk-0 604M 15.9G 604M /rpool/subvol-301-disk-0
rpool/vm-100-disk-0 3.79G 15.9G 3.79G -
rpool/vm-213-disk-0 184G 148G 38.2G -

Des disques de type “Filesystem” qui sont directement montés à la racine de mon espace de stockage ZFS (chez moi /rpool, mais on a aussi /tank comme convention chez les aficionados de ZFS) pour les containers LXC.

# zfs get type rpool/subvol-301-disk-0
NAME PROPERTY VALUE SOURCE
rpool/subvol-301-disk-0 type filesystem -
# zfs get mountpoint rpool/subvol-301-disk-0
NAME PROPERTY VALUE SOURCE
rpool/subvol-301-disk-0 mountpoint /rpool/subvol-301-disk-0 default

Pour les VMs KVM/QEMU en revanche, je ne peux pas directement trouver un fichier toto.raw ou toto.qcow2 dans l’arborescence /rpool. Côté ZFS, ces volumes sont des volumes de type “volume” (lol).

Mais c’est un détail, car c’est presque encore plus facile puisqu’on peut aller directement dans /dev/zvol/rpool et les retrouver en tant que “special file” dans /dev.

ls -l /dev/zvol/rpool/vm-100*
lrwxrwxrwx 1 root root 10 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0 -> ../../zd16
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part1 -> ../../zd16p1
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part2 -> ../../zd16p2
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part5 -> ../../zd16p5

Dans l’étape suivante, /dev/zvol/rpool/vm-100-disk-0 remplacera donc notre image disque “input” (toto.img).

Générer un VHD

Souvent sous Proxmox, vous allez avoir des disques au format RAW ou au format QCOW2.

Dans les deux cas, XCP-NG n’accepte pas ces formats. Heureusement, l’utilitaire qemu-img, inclus dans notre distribution de Proxmox VE sait faire les conversions.

Dans le cas d’un disque RAW :

qemu-img convert -f raw toto.img -O vpc toto.vhd

Dans le cas d’un disque QCOW2 :

qemu-img convert -f qcow2 toto.qcow2 -O vpc toto.vhd

Avant d’importer le VHD dans XCP-NG

La partie un peu moins “fun” de la procédure est qu’on doit faire une partie des actions en GUI (si on suit la doc, mais je teaserai qu’on peut faire mieux en fin d’article).

La première chose qu’on va devoir faire, c’est aller dans la WebUI Xen Orchestra pour retrouver notre espace de stockage et créer manuellement un disque.

Il faut aller retrouver la liste de nos espaces de stockages (le plus simple, c’est de passer par “home”), puis, dans cet espace, créer un nouveau disque. Prenez garde à le créer de la bonne taille, en faisant attention à la différence Go/Gio. La documentation officielle conseille d’ajouter 1 Go de marge pour éviter ce genre de problématiques, mais je n’en ai pas eu besoin lors de mes tests.

Note: chaque disque et chaque “datastore” a son propre UUID. Ici, j’ai souligné en rouge celui du datastore “Local”, il nous servira plus tard (quand on passe la souris dessus, XOA nous propose de le copier dans le presse-papier).

Une fois le disque créé à la bonne taille, on récupère son UUID aussi.

VHD vers XCP-NG

Maintenant qu’on a d’un côté un VHD valide, et de l’autre un disque dur virtuel vide prêt à accueillir les données, on peut se lancer !

On envoie le VHD sur le serveur XCP-NG (via scp ou un montage NFS, par exemple) et on se connecte dessus en SSH.

Si on est pas confiant, on peut tester que le VHD est valide sur XCP-NG grâce à l’utilitaire suivant :

# vhd-util check -n /nfs/toto.vhd
 /nfs/toto.vhd is valid

Ensuite, on utilise le binaire xe qui permet d’interagir en CLI avec XCP-NG pour lancer l’import :

# xe vdi-import filename=/nfs/toto.vhd format=vhd --progress uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
 [|] ######################################################> (100% ETA 00:00:00)

On aura évidemment remplacé le paramètre uuid=aaaa par l’UUID du disque virtuel, que je vous ai demandé de récupérer plus tôt !

Créer la VM

Normalement, à l’issue de l’opération, on a un disque tout beau tout propre. La dernière étape est de créer une VM et à lui attacher ce disque.

Là encore, on peut repartir de “Home” puis aller dans le menu VM.

Note: pour passer le menu de création de VM, il faut impérativement choisir soit ISO/DVD ou PXE dans Install settings, sinon CREATE est grisé. J’ai également supprimé le disque par défaut proposé par le wizard (puisqu’on va lui en attacher un) et dans Advanced, j’ai décoché Boot VM after creation puisque de toute façon je dois lui attacher le disque avant de booter.

Une fois créé, on clique sur la VM pour lui attacher le disque qu’on a importé.

On peut maintenant booter la VM !

Lors du redémarrage, la seule chose que j’ai eu à changer était la configuration réseau, un peu différente entre mon cluster Proxmox VE et mon lab XCP-NG, ainsi que le nom d’interface qui était différent suite au passage à Xen (ens18 => eth0).

J’ai également ajouté le “Management agent” pour bénéficier d’infos dans l’UI (et probablement d’autres trucs chouettes que je n’ai pas encore exploré).

Conclusion

Voilà pour ces premiers pas avec XCP-NG. Comme vous avez pu le constater, l’opération nécessite plusieurs étapes, dont certaines peuvent être améliorées (notamment l’automatisation de certaines tâches côté XCP-NG grâce à l’API, on en reparlera, car j’ai déjà quelques résultats).

Cependant, ça permet déjà de se faire une première impression et de se familiariser avec les menus.

Dans les semaines qui viennent, je vais continuer de jouer avec, histoire de me faire une opinion un peu plus construite de XCP-NG (notamment par rapport à ce que je fais avec Proxmox). S’il y a des points que vous voulez que je creuse en particulier, n’hésitez pas à me “ping” sur les divers réseaux sociaux pour m’en parler.

D’ici là, have fun :)

Un cluster Proxmox VE en 5 minutes avec Ansible

Mon, 22 Jul 2019 11:45:34 +0000

Cool on va (encore) déployer du Proxmox VE !!!

Petit tuto aujourd’hui, massivement facilité par l’usage d’Ansible : on va déployer un cluster de machines Proxmox VE via le cloud provider Scaleway.

A noter : Si jamais vous ne voulez pas utiliser Scaleway, les playbooks ont été découpés de manière à ce que la partie d’installation de Proxmox ainsi que l’installation de tinc et la mise en cluster puissent être réalisés à part. Vous pouvez donc tout à faire partir de machines sous Debian 9 via ces playbooks.

Pourquoi Scaleway me direz vous ? Tout simplement parce qu’ils ont, contrairement à d’autres, une très bonne API, qui a permis à un de leurs employés de faire de très bons modules Ansible, notamment un module permettant de gérer l’inventaire dynamique (pas besoin de renseigner un fichier hosts pour Ansible, c’est directement l’API qui nous liste les VMs).

J’ai d’ailleurs utilisé ce provider à plusieurs reprises pour cette raison (voir mon article sur k3s et Ansible ou mon talk à BDX I/O Ami développeur, deviens un ops sans effort avec Ansible).

Proxmox VE 5.4 ? Pourquoi pas 6.0 ?

La deuxième question, tout aussi légitime, repose donc sur “pourquoi diantre monter un cluster Proxmox VE 5.4 alors que tu viens de nous faire un article qui vante les bienfaits de la version 6.0 qui vient de sortir ?”

Et là j’ai deux raisons (une bonne et une mauvaise). La mauvaise, c’est simplement que l’article trainait dans mes brouillons et que je n’ai pas cliqué sur “Poster”… La “bonne” raison, c’est que la version 10 de Debian, qui est la base de Proxmox VE 6, n’est pas encore disponible sur Scaleway, ce qui complique un peu l’installation.

Lorsqu’elle le sera, je ne manquerais pas de faire un petit refresh de l’article ainsi que des playbooks Ansible ;)

Déployer les VMs avec Ansible

Je l’ai dis juste avant, le gros avantage de Scaleway, c’est de pouvoir spawner des VMs à la volées avec Ansible et surtout d’avoir l’inventaire dynamique.

Petite (grosse?) limitation : comme il s’agit de VMs, il ne sera évidemment pas possible de faire tourner des VMs de type KVM/qemu sur ces machines (sauf moyennant un hack de type nesting de VM dans une VM).

Cependant, depuis quelques temps, je n’utilise plus du tout les VMs (je n’ai pas de workload Windows) et j’utilise plutôt des containers LXC.

C’est vraiment plus léger en terme d’empreinte mémoire (je n’ai jamais été embêté côté CPU mais côté RAM, chaque Mo compte) et ça se gère (install, gestion, sauvegarde) de la même façon qu’une VM, contrairement à Docker qui nécessite une gymnastique mentale complémentaire.

Bon, on fait ça comment ?

Maintenant que j’ai posé le décor, on peut commencer le tuto. L’idée va être de :

Créer des VMs
Récupérer leurs informations (IP publique, surtout)
Installer les prérequis de Proxmox VE (puis les rebooter pour passer sur le kernel PVE)
Installer les prérequis et configurer tinc, le VPN qui va nous permettre d’initier le cluster et de laisser passer les trames multicast, nécessaires au clustering

A l’issue de ces étapes, on arrêtera là l’automatisation et on passera sur quelques (rapides) étapes manuelles.

Ok, j’avoue que c’est dommage que tout ne soit pas automatisé. Mais le gros du boulot, c’est vraiment les étapes précédentes. Pour s’en convaincre, vous pouvez lire l’article que j’avais écris pour la version 5.2 (mais avec OpenVPN) ou tout simplement lire le contenu des playbooks.

Prérequis

Et oui, il y a quand même quelques prérequis à ce tuto. Il faudra :

Avoir un compte sur Scaleway
Avoir une clé SSH, avoir la clé publique à la racine du projet, et l’appeler admin.pub
Installer les package pip

pip install jinja2 PyYAML paramiko cryptography packaging

Installer Ansible depuis les sources (>= 2.8)
Installer jq

J’aurai pu faire aussi un playbook pour ça, mais comme c’est très dépendant de votre distribution Linux (ou Windows ahaha), …

You token to me ?

Créez un token sur le site de Scaleway pour les accès distants et le stocker dans un fichier scaleway_token sur votre machine avec Ansible :

export SCW_API_KEY='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

Puis sourcez le fichier :

source scaleway_token

A partir de maintenant, vous avez le pouvoir tout puissant du cloud au bout de vos doigts (et de votre CB) !

Générer les machines

Là, on tire totalement parti du travail de Rémy Léone sur https://github.com/scaleway/ansible et des modules Ansible pour Scaleway, intégrés au repo officiel.

On va donc utiliser le playbook create_proxmox_vms.yaml pour :

récupérer l’ID d’organisation du compte Scaleway (votre identifiant unique)
récupérer un ID d’une image disque compatible debian Stretch (de la bonne taille)
ajouter si nécessaire la clé SSH de l’admin dans le portail Scaleway, qui sera injectée dans vos VMs à leur création
créer autant de machines que nécessaire

ansible-playbook create_proxmox_vms.yml

Bon, je vous ai pas menti, c’est quand même hyper simple non ?

A noter, actuellement le script traite les demandes de création de machines séquentiellement. Pour 3 VMs, comptez environ 3 minutes.

Cependant, si vous avez un gros besoin, sachez qu’il est possible de modifier le script pour les lancer en parallèle (déjà fait dans mon repo ansible-deploy-azure sur Github) via la fonction async d’Ansible.

Mise en place de l’inventaire dynamique

J’arrête pas de vous en parler depuis tout à l’heure, normalement dans Ansible, maintenant que nos VMs sont créées, pour pouvoir nous y connecter, on devrait créer un fichier texte “inventory” contenant la liste des hôtes et de leur IP (a minima). C’est fastidieux, surtout si vous avez beaucoup de VMs.

Et là, on a juste un fichier inventory.yml, contenant le nom du plugin, la région utilisée (Paris dans mon script) et le tag des machines générées :

plugin: scaleway
regions:
- par1
tags:
- proxmoxve

A partir de là, on peut vérifier le retour de la commande ansible-inventory

ansible-inventory --list -i inventory.yml
{
"_meta": {
"hostvars": {
"x.x.x.x": {
"arch": "x86_64",
"commercial_type": "DEV1-S",
"hostname": "test3",
[...]
"proxmoxve": {
"hosts": [
"x.x.x.x",
"y.y.y.y",
"z.z.z.z"
]
}

Petite hack SSH : comme Ansible se connecte en SSH aux hôtes distants, à la première connexion on va bloquer sur l’acceptation de la fingerprint.

Un moyen de bypasser ça en une ligne de commande est d’utiliser la commande ssh-keyscan et de coller tout ça dans votre known_hosts. On peut le faire avec ce petit oneliner :

ansible-inventory --list -i inventory.yml | jq -r '.proxmoxve.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts

Ce n’est évidemment pas recommandé en production !!! Mais dans le cadre d’un test temporaire, vous me pardonnerez cette liberté.

Ajoutez votre clé SSH dans l’agent, puis vérifiez que vous pouvez vous connecter à tous les serveurs :

eval `ssh-agent`
ssh-add myprivate.key

ansible proxmoxve -i inventory.yml -u root -m ping
x.x.x.x | SUCCESS => {
"changed": false,
"ping": "pong"
}
y.y.y.y | SUCCESS => {
"changed": false,
"ping": "pong"
}
z.z.z.z | SUCCESS => {
"changed": false,
"ping": "pong"
}

Préparation du serveur

Ok ! Maintenant, on a 3 (ou plus) VMs Debian 9. A partir de là, j’ai créé un playbook Ansible qui suit la doc d’installation officielle de Proxmox sur un Debian Stretch.

ansible-playbook -i inventory.yml -u root proxmox_prerequisites.yml

A l’issue de l’installation, il est nécessaire de rebooter les serveurs (manuellement ou via ansible), pour passer sur le kernel de PVE.

Installation et configuration de tinc

C’est piou-piou.

Une fois que vos serveurs sont revenus à la vie, vous avez installé Proxmox. Pas mal hein ?

Cependant, chez Scaleway (et tous les autres providers que je connais), le multicast est coupé entre vos VMs. Et ça c’est la loose car tout notre clustering va passer par des trames multicast.

Pour bypasser ce souci de taille, le plus simple est de passer par un VPN, de créer un réseau privé virtuel entre toutes nos instances, qui lui ne filtrera rien.

Dans les articles précédents, j’avais utilisé OpenVPN (parce que c’est ce que je connais le mieux). Le souci d’OpenVPN c’est qu’il fonctionne sur un base client-serveur. Or, dès qu’on dépasse les 3 serveurs, on se retrouve avec 1 serveur maitre et 2 (ou plus clients), et donc un SPOF…

L’avantage avec tinc, c’est qu’on a pas cette notion de client/serveur. Tous les tincs sont connectés à tous les tincs, dans un genre de gros maillage qui nous évite donc tout SPOF.

L’installation de tinc n’est en soit pas follement complexe (cf le playbook), mais là encore, l’automatiser c’est toujours sympa.

ansible-playbook -i inventory.yml -u root tinc_installation.yml

Etapes additionnelles manuelles

Une fois que vous en êtes là, on arrive dans les tâches non triviales à automatiser.

Actuellement, il n’est pas possible de créer un cluster Proxmox VE sans avoir un mot de passe root. Or, lors de la création des VMs, Scaleway utilise notre clé SSH (ce qui est beaucoup mieux). Nous allons donc devoir nous connecter sur l’ensemble des machines et réinitialiser le mot de passe du compte root.

root@test1:~# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully

Créer un cluster

Cette partie aurait pu être automatisée. Dans le tutoriel précédent, je le faisais en ligne de commandes, à cause d’une limitation dans le wizard de création de cluster. En effet, dans les précédentes versions de Proxmox, on ne pouvait pas sélectionner sur quelle interface réseau on souhaitait utiliser, et donc mon cluster ne passait pas par le VPN et les trames multicast ne passaient jamais.

Pour autant, maintenant on peut profiter du beau wizard tout neuf et le faire via la GUI :

Se connecter à l’UI de Proxmox avec un des noeuds (le premier, au hasard)
Dans Datacenter (à gauche), sélectionner Cluster puis cliquer sur “Create Cluster”
Donner un nom au cluster, mais surtout, donner comme adresse ring0 l’adresse VPN (10.10.10.1 si on est sur le noeud 1)
Une fois l’opération terminée, cliquer sur “Join Information”, dans le même menu, et copier les informations en cliquant sur “Copy Information”

Joindre le cluster

Se connecter sur l’UI de la 2ème machine
Dans Datacenter, sélectionner Cluster puis cliquer sur “Join Cluster”
Dans le champ “Information”, coller les données récupérée lors de l’étape précédente. Les informations de connexion devraient automatiquement être remplies, SAUF le Corosync ring0, qu’il faut positionner à 10.10.10.2", et le mot de passe root du noeud 1. Cliquer sur “Join”.
Si l’opération réussie, un message doit s’afficher pour dire de recharger la page

Répéter l’opération pour les noeuds suivants (3, voire ++)

Et en attendant la même chose avec la v6, amusez vous bien :)

Sortie de Proxmox VE 6.0, les nouveautés

Tue, 16 Jul 2019 16:00:23 +0000

Proxmox VE 6.0

Ce n’est pas la première fois que j’écris un article sur les mises à jour de Proxmox VE, une distribution Linux pour faire de la virtualisation qui me tient pas mal à cœur car très simple et très efficace. Aujourd’hui, Proxmox VE 6.0 vient de sortir !

Pour info, le blog ainsi que d’autres services fonctionnent depuis des années sur un hyperviseur Proxmox, ce qui pour moi est un exemple de stabilité et de simplicité, même dans des usecases très simples (sinon je serai passé à autre chose). M4vr0x et moi avons beaucoup écrit sur le sujet.

Mais avant ça ?

La dernière fois que j’avais écris un article sur une release de Proxmox c’était la 5.2 il y a un an, qui avait sorti pas mal de choses sympas.

Depuis, je ne vous ai pas parlé de la 5.3 et de la 5.4, quelques modifs sympas (mais que je n’ai personnellement pas utilisé).

Ceph Luminous LTS installable depuis la GUI (5.4)
Ajout d’un QDevice pour gérer le quorum dans un cluster à 2 hyperviseurs (5.4)
U2F dans l’interface web (5.4)
Nesting (faire des containers dans des containers) de containers privilégiés ou pas (5.3)
Emulation de VMs ARM sur hyperviseur x86_64 (5.3)

Et Proxmox VE 6.0 ???

Comme toute majeure, il faut s’attendre à pas mal de modifs.

La liste des modifications est longue comme le bras, et les ajouts sont à la fois amenés par la mise à jours des composants principaux et par des améliorations sur les composants internes.

Les composants tiers

D’abord, Proxmox VE 6.0 se base sur la toute nouvelle Debian 10.0 (aka Buster). C’est logique pour l’équipe de Proxmox de partir sur le tout dernier OS, puisque la branche 6.x va durer quelques années.

On tire donc un kernel Linux plus récent que celui PVE 5 (c’était le 4.15) et on passe sur un 5.0. De quoi tirer profit des dernières améliorations du Kernel, notamment pour le stockage (on y reviendra) et le réseau.

Ensuite, les gros composants. Proxmox VE étant une plateforme de virtualisation VM + containers, on va évidemment s’intéresser aux 2 composants qui fournissent ça, à savoir qemu et lxc ont bien évidemment droit à une mise à jour (respectivement 4.0.0 et 3.1). Pour LXC (les containers) je n’ai pas su trouver les améliorations. Pour qemu 4.0.0, on a droit à une majeure mais qui ajoute surtout la compatibilité vers de nouveaux matériels et de nouveaux flags CPU (pour des usecases bien précis).

Une plus grosse modif vient peut être de corosync, le composant qui permet de gérer une grosse partie du clustering, qui passe en version 3 avec Kronosnet. Ça, c’est très impactant. J’ai écris plusieurs articles sur le clustering de serveurs Proxmox avec des machines dédiées chez des cloud providers et j’étais souvent gêné par le fait que corosync utilise du multicast, systématiquement bloqué par les providers. Kronosnet utilise de l’unicast ce qui devrait énormément simplifier les futurs setups de clusters (AKA, plus obligatoirement besoin d’un VPN) !!!

Côté stockage, on passe de Ceph 12 vers Ceph 14 et de ZFS (on Linux) en 0.8.1 (encryption des pools + trim, support de ZFS dans l’UEFI)

Les modifs internes

Voilà pour les mises à jour de packages. Maintenant, les features que j’ai hâte de tester. La plupart sont des améliorations de la GUI :

Migration des VMs à chaud depuis l’interface, même si on est sur du local storage. On retrouve une promesse déjà présente en 5.x, qui marchait partiellement en ligne de commande, mais qui devrait être ENFIN disponible dans la GUI (cf ce post sur le forum).
Améliorations au niveau du Wizard pour créer des clusters. On peut maintenant sélectionner plus facilement quelle(s) interface(s) doit être utilisée pour la communication Corosync. Une amélioration légère par rapport à ce qu’on pouvait faire en 5.4 avec tinc (article qui n’est jamais sorti car je ne l’avais pas terminé… oups). Dans tous les cas, c’est beaucoup plus simple que ce que j’avais pu montrer en 5.2 ou en 5.0.
Encore des améliorations pour gérer Ceph dans la GUI. Je ne peux pas trop en parler car je n’avais pas de machines suffisamment proches et puissantes pour monter un cluster Ceph sur mes machines Proxmox VE. Cependant, je pense tester dans les jours qui viennent, profitant du fait que les clusters sont plus simple à créer (donc à tester sur des machines temporaires chez Kimsufi par exemple).
Possibilité de configurer les backups non plus par VM/container mais par pool entier (nice to have)

Tu nous montres ?

Une fois de plus, je suis assez enthousiaste quant à cette nouvelle version, qui apporte plein de bonnes choses. Je vais très probablement faire des articles dans les semaines qui viennent sur le sujet, en premier lieu la migration de la 5.4 (sur laquelle je suis actuellement) vers la 6.0.

Wait and see !!

Sources

Migration CentOS + KVM vers Proxmox VE

Sat, 21 Nov 2015 11:30:53 +0000

Juste après avoir sorti un article qui traite de la migration de KVM/Ubuntu vers KVM/RHEL, voilà que je migre ENCORE pour ProxMox !?! Mais c’est parce qu’en fait j’avais juste beaucoup de retard sur ces précédents articles ;-).

Présentation de la solution

Cette fois ci, il s’agit donc de vous donner les clés pour migrer sans stress votre serveur sous KVM (Ubuntu, Debian, RHEL, Whatever …) vers Proxmox VE.

Pour ceux qui ne connaissent pas Proxmox VE, il s’agit d’une distribution Debian adaptée pour faire de la virtualisation full (qemu/KVM) et par conteneur (anciennement via openVZ, maintenant via LXC). LE gros plus de la solution, c’est l’interface graphique et l’installation clé en main d’un hyperviseur disposant de fonctionnalités qu’on retrouve chez les grands du marché.

Pour être honnête, j’étais très content de mon KVM pour ce qui est des performances et de la consommation de ressources (point faible d’un ESXi à la maison), mais pas du tout satisfait des manières que j’avais pour l’administrer. J’ai testé plusieurs interfaces graphiques (web ou pas) sans jamais en trouver une à ma convenance (même les usines à gaz comme oVirt, la base de RedHat Entreprise Virtualisation).

Installation

Comme beaucoup d’hyperviseur clés en main, l’étape d’installation est particulièrement soignée pour être simple et rapide. On récupère un ISO, on le copie sur une clé USB, on boot dessus. Quelques écrans et moins de 5 minutes plus tard le serveur reboot et on nous invite à nous connecter à la console web.

Ah ! Ça fait du bien !

La première chose à faire est de créer des pools de stockages (un local est créé par défaut). On peut choisir s’il s’agit d’un pool dédié aux VMs, à la sauvegarde, aux fichiers ISOs. C’est assez pratique.

RAID logiciel MDADM

Sous ProxMox, le RAID logiciel via MDADM Linux n’est pas supporté (voir wiki officiel). Seuls les RAID Hardware sont supportés.

Dans l’interface, vous ne pourrez donc pas le configurer (ni même pendant la phase d’installation). Depuis la version 3.4, vous pouvez cependant installer ProxMox sur un espace ZFS, avec notamment tous les niveaux de RAID/RAIDZ que vous souhaitez. Mais mon petit doigt me dit qu’il s’agit probablement de ZFSonLinux et j’ai déjà donné ;-).

Cette absence de RAID logiciel est une des raisons pour lesquels j’étais initialement réfractaire à ProxMox par rapport à un linux classique avec qemu. Cependant, ce n’est pas parce ce n’est pas supporté que vous ne pouvez pas le faire ! Après tout, il s’agit d’une Debian customisée donc il n’y a rien qui vous retient.

Voici deux articles que j’ai sélectionnés qui vous guideront pas à pas pour le faire (à vos risques et périls, comme d’habitude).

[Edit]

Attention : la partie amorçage ne fonctionnera pas si vous avez un boot EFI (Proxmox 4+). Il faudra trouver une autre technique. Vous pouvez lire cet article qui explique comment faire en général sur Debian :

www.debian-fr.org/t/raid-logiciel-linux-et-amorcage-en-uefi/64655

La partie du tutoriel traitant de lvm pour ProxMox (3ème partition) contenant le / et les données importantes peut par contre bien être suivie. C’est vraiment uniquement le boot EFI qui va nous enquiquiner.

[/Edit]

Migrer ses VM existantes

Nous voici maintenant dans le vif du sujet. Selon la documentation officielle, voici ce qu’on doit faire pour migrer une machine KVM dans ProxMox.

D’abord, on nous dit de créer une nouvelle machine virtuelle. Jusque là tout va bien. On lui affecte les options par défaut et pas de CD-ROM dans le lecteur.

Ensuite ça se gâte. En effet, on veut supprimer le disque dur par défaut puis ajouter notre disque importé de l’ancien système KVM. On va donc dans les propriétés de la machine virtuelle nouvellement créée.

Et là, blague… Pas de bouton « Parcourir » pour aller chercher notre disque virtuel à importer !

On peut trouver la solution assez vite sur les forums, mais c’est quand même assez frustrant, surtout quand on voit la malheureuse ligne donnée dans le wiki en guise de procédure…

Dans ce thread et ce thread, on apprend que pour chaque banque de données, chaque VM dispose d’un dossier dans lequel il faut déposer le disque. Dans le bon dossier ! Par exemple :

pour le stockage local, la VM avec l’id 100 a un dossier /var/lib/vz/images/100/
pour le stockage NFS nommé de manière originale NFS_VM, il y a un dossier /mnt/pve/NFS_VM/images avec des sous dossiers pour chaque VM qui dispose d’un disque sur ce partage NFS.

A partir de là, on copie donc nos fichiers dans les bons dossiers en fonction de ce qu’on veut faire. Dans le cas présent je copie les fichiers sur le stockage local, dans un premier temps.

cp MaVM.qcow2 /var/lib/vz/images/100/

Une fois que c’est fait, les disques apparaissent dans la page spécifique de la banque de données.

Mais le disque virtuel n’apparaît toujours pas dans la machine virtuelle. Il faut aller éditer à la main le fichier de configuration de la VM, situé dans /etc/pve/nodes/xxx/qemu-server/[VMID].conf.

vi /etc/pve/nodes/xxx/qemu-server/100.conf
bootdisk: ide0;
cores: 2
ide2: none,media=cdrom
memory: 1024
name: bck-xxx-xxx
net0: e1000=7A:FA:D6:DC:06:70,bridge=vmbr0
numa: 0
ostype: l26
smbios1: uuid=ae5d66d6-724f-46cd-a85b-24eda7b9ecec
sockets: 1
ide0: local:100/xxx-xxx-flat.vmdk
ide1: local:100/xxx-xxx_1-flat.vmdk
unused0: local:100/vm-100-disk-1.vmdk
unused1: local:100/vm-100-disk-2.qcow2,size=32G

A partir de là, les disques apparaissent dans la VM au niveau de ide0 et ide1 dans mon cas. On progresse.

Cas des disques QCOW2

Dans le cas des disques QCOW2 (et les QCOW2 uniquement, pas les RAW), il sera nécessaire d’ajouter également un argument « taille » du disque, sans quoi la VM peut ne pas démarrer. Il faudra rajouter en fin de ligne la taille du disque (xxx,size=yyG).

Astuce : si vous ne la connaissez pas, supprimez le disque de la VM (qui passera en inutilisé), puis éditer le (edit) pour l’ajouter à nouveau. Le fichier de configuration devrait se recréer avec les bonnes options automatiquement.

Cas des disques RAW

A l’inverse, la taille du disque en argument dans la configuration d’une VM pour une image RAW ne semble pas nécessaire.

Par contre, pour les disques raw, il faut savoir qu’il faut ABSOLUMENT les nommer en « .raw » pour qu’ils soient visibles dans la liste des disques (mes disques provenant de KVM étaient nommés par défaut en « .img »).

Si vous ne les renommez pas, les disques seront présents dans la VM, mais elle refusera de démarrer avec l’erreur suivante :

unable to parse volume filename

Il faudra prendre soin de tous les renommer, puis de modifier la configuration de la machine virtuelle en tenant compte de cette modification.

Bug : unable to execute QEMU command ‘cont’ sous KVM et RHEL/CentOS

Sat, 10 Oct 2015 10:30:00 +0000

Cet article est encore un vieil article que je n’ai jamais pris le temps de sortir. Voilà maintenant c’est fait ;-)

Bug unable to execute QEMU command ‘cont’

Aussi rare que cela soit, après ma migration de KVM sur Ubuntu a KVM sur CentOS, je suis tombé sur un bug du Kernel Linux qui affectait directement ma capacité à faire fonctionner des machines virtuelles sous Windows 7 ou Windows 2008 ! Mais toutes les autres fonctionnaient normalement.

Symptôme

Lorsqu’on démarre la VM ou qu’elle démarre seule au boot, elle se met en pause. Si on essaye de la sortir du mode pause on reçoit l’erreur suivante.

Error unpausing domain: internal error unable to execute QEMU command ‘cont’: Resetting the Virtual Machine is required<

L’erreur en elle même n’est pas très explicite. Dans le log de la machine virtuelle en question, on a un message plus long mais guère plus évocateur :

/var/log/libvirt/qemu/[maVM]
kvm: unhandled exit 80000021
kvm_run returned -22
If you’re running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.

Bien évidemment, toutes les autres VMs sous Linux fonctionnent parfaitement donc on ne peut pas accuser Qemu de ne pas fonctionner correctement.

Solution

En théorie, j’ai lu à plusieurs endroits que le bug était censé être corrigés sur des patchs des kernels de CentOS 5 ou 6 (toujours présent en 2.6.32-431.3.1.el6.x86_64 par exemple) et même pour Ubuntu.
Dans la pratique, même en mettant l’OS CentOS à jour, impossible de faire fonctionner cette VM.
La seule vrai solution que j’avais trouvé à l’époque était de forcer le passage à un kernel plus récent, à savoir au moins 3.+.

Pour ceux qui se sentiraient un peu perdu, le plus simple est de changer de version de CentOS ou d’Ubuntu. Sur les dernière version le bug n’est plus présent.

Cependant, si vous avez un système en place et qu’une migration n’est pas à l’ordre du jour, voici la marche à suivre pour installer un kernel plus récent. Voici la procédure que j’ai utilisée pour installer un 3.13 sur lequel la VM fonctionne à nouveau (3.11 fonctionne aussi, je ne sais pas avant).

yum install gcc ncurses ncurses-devel
yum update
wget https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.13.1.tar.gz
tar xzf linux-3.13.1.tar.gz -C /usr/src/
cd /usr/src/linux-3.13.1/
make menuconfig
make
make modules_install install

N’oubliez pas de vérifier que votre kernel est bien choisi en premier dans le boot loader, ce qui n’est souvent pas le cas par défaut (modifier la valeur default dans le grub.conf pour correspondre à la bonne entrée) sinon le problème ne sera pas résolu au reboot.

vi /etc/grub.conf
default=X
[...]
root (hd0,0)
kernel /vmlinuz-3.13.1 ro root=/dev/mapper/vg_root-lv_root rd_LVM_LV=vg_root/lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_MD_UUID=8f43b4fe:e72ed9aa:2da568b5:5f43b223 SYSFONT=latarcyrheb-sun16 crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=fr-latin9 rd_LVM_LV=vg_endeavour/lv_swap rd_NO_DM rhgb quiet
initrd /initramfs-3.13.1.img

Et vous pouvez vérifier que vous êtes sur le bon kernel avec un uname.

reboot
uname -r

Erreur/bug Error starting virt-manager

En bonus track, je voudrais aussi ajouter un petit bug de plus pour la route, sur l’utilisation de l’interface graphique virt-manager cette fois ci.

Pour une raison obscure, lorsque je voulais lancer ma GUI virt-manager, il m’est arrivé une ou deux fois de suivre la procédure décrite sur le blog de nutanix lorsque je recevais l’erreur suivante :

Error starting virt-manager

dbus-uuidgen --get
cat /var/lib/dbus/machine-id
dbus-uuidgen > /var/lib/dbus/machine-id

Migration KVM Ubuntu vers Redhat et problème /usr/libexec/qemu-kvm: No such file or directory

Sun, 04 Oct 2015 19:20:58 +0000

Je suis en train de migrer de KVM vers ProxMox. Et du coup, je ressors de mes tiroirs tous les articles que je n’ai pas eu pris le temps d’écrire à propos des problèmes que j’ai pu rencontrer, notamment lors de ma migration VMware ESXi vers KVM/Uubuntu puis KVM/Ubuntu vers KVM/CentOS.

Processsu de migration (à froid)

On pourrait penser que migrer une machine virtuelle KVM Ubuntu vers une machine virtuelle KVM sous RHEL/CentOS ne pose pas de problème particulier puisqu’il s’agit d’une même technologie : qemu. Et pourtant !

Lorsque j’ai voulu passer sous CentOS pour des questions d’habitude d’administration (et aussi parce que la philosophie RHEL me plait plus que celle d’Ubuntu), je me suis rendu compte que ça n’est pas tout à fait vrai.

Voici la procédure que j’ai suivi pour migrer :

copie de mes machines virtuelle sur un volume séparé, ainsi que dump de leur fichiers de configuration
réinstallation from scratch de l’OS de l’hyperviseur, j’en ai profité pour passer sur un OS installé en RAID1 pour plus de sécurité
récupération des machines virtuelles et réimport de leur configuration

Pour ceux qui ne sont pas familier avec l’import/export de configuration de machines virtuelles via virsh, voici un petit aparté sur la marche à suivre :

virsh list #affiche la liste des machines virtuelles actives sur le serveur
virsh list --all #affiche toutes les VMs enregistrés sur l'hôte, même celles inactives
virsh dumpxml GuestID > guest.xml #dump XML du fichier de configuration pour sauvegarde ou import futur
virsh define guest.xml #réimporter le fichier de configuration XML (sans démarrer la VM à la suite)

En cas d’erreur No such file or directory lors de l’import

Lors qu’on importe la machine virtuelle, on peut avoir l’erreur suivante :

virsh define MaVM.xml
error: Failed to define domain from MaVM.xml
error: Cannot find QEMU binary /usr/bin/kvm: No such file or directory

La première chose à vérifier bien entendu est que tous les packages sont bien installés mais dans mon cas c’était bien le cas (le package qemu contenant l’émulateur KVM était bien installé).

Sur Ubuntu, l’émulateur est stocké dans le binaire /usr/bin/kvm. A l’inverse, sur RHEL ou CentOS, il n’est pas situé dans le même dossier, et ne s’appelle même pas kvm mais /usr/libexec/qemu-kvm !

On doit donc passer sur chaque fichier XML de configuration de machine virtuelle pour modifier le chemin vers le binaire. On en profitera également pour mettre à jour le chemin vers le disque dur virtuel si jamais l’arborescence de stockage n’est pas la même entre les deux serveurs.

vim MaVM.xml
<emulator>/usr/bin/kvm</emulator>

A partir de là, vous pouvez importer correctement vos VMs et les démarrer !

Pour aller plus loin

A noter, par défaut sous RHEL/CentOS les fichiers sont répartis de la façon suivante :

/etc/libvirt/qemu/ pour tous les fichiers de configuration VM, storage, etc.
/var/log/libvirt/qemu/ pour les fichiers journaux des machines virtuelles
/var/run/libvirt/qemu/ contient les fichiers de fonctionnement de la machine, à avoir le .pid pour stocker le PID du process maitre de ma VM, ainsi qu’un fichier XML contenant une copie de la configuration de la VM en fonctionnement
/var/lib/libvirt/qemu/ contient des fichiers permettant de suivre les performances de la VM, de stocker les éventuels dump/snapshots/sauvegardes

Un peu de documentation clairement expliquée sur l’utilisation de virsh sur la communauté Ubuntu : Virsh

Et pour aller plus loin dans le Troubleshooting, voici un guide de RedHat listant les erreurs courantes avec Qemu/KVM.