XenServer on Zwindler's Reflection

Premiers pas avec XCP NG

Mon, 10 Oct 2022 06:00:00 +0200

Introduction

Si vous suivez ce blog, vous savez peut-être qu’après des années de Proxmox VE, j’ai commencé à regarder pour voir ce qui se faisait d’autre sur le marché des hyperviseurs open source.

J’ai rencontré les équipes de Vates et ils m’ont donné l’envie de tester le couple XCP-NG / Xen Orchestra. Ca et aussi le fait que Cécile et Nidouille en ont dit beaucoup de bien.

En particulier, Nidouille a fait plusieurs séries de benchs que je vous conseille et qui montreny de très belles perfs de XCP-ng.

Vous pouvez retrouver les deux articles que j’avais écrits à ce sujet :

Dans cet article, je vais vraiment me limiter aux tout premiers pas. On ira plus loin dans un article ultérieur, notamment pour passer outre les quelques limitations qu’on va rencontrer.

C’est quoi XCP-NG / Xen Orchestra ?

XCP-NG est une distribution clé en main de virtualisation open source, basée sur XenServer (lui-même basé sur Xen). Historiquement Xen était surtout connu en tant que paravirtualiseur (un Dom0 qui partage le même kernel avec les DomU) mais depuis bien longtemps, Xen a fait un gros virage et fourni de la virtualisation complète comme les autres.

XCP-ng is a virtualization platform based on Xen Source and Citrix® Hypervisor (formerly XenServer). XCP-ng stands for Xen Cloud Platform - New Generation and is a tribute to the old Open Source project XCP, which was abandoned when XenServer was open-sourced in 2013.

Xen Orchestra est une webUI open source, permettant d’ajouter des fonctionnalités supplémentaires au-dessus de clusters XenServer et/ou XCP-NG, telles que la gestion de flottes de serveurs, les statistiques, la sauvegarde /restauration de machines…

Si je voulais donner une comparaison simple avec l’écosystème VMware, je dirais que XCP-ng est l’ESXi et que Xen Orchestra est le vCenter.

Choix du lab

A la base, je voulais installer XCP-ng sur des machines peu chères que j’aurais pu louer un mois ou deux. Cependant, contrairement à Proxmox VE qu’il est possible d’installer au-dessus d’un Debian 11, il n’est pas simple d’installer l’hyperviseur d’XCP-ng au-dessus d’une machine existante.

De plus, peu de providers de machines baremetal disposent de templates pour XCP-ng à l’heure actuelle (à priori Ikoula). Rien chez OVH, Scaleway, oneProvider…

J’ai donc changé mon fusil d’épaule et investi pour mon lab dans deux petits Dell micro d’occasion, un 7040 (merci Bosco) et un 3050.

Ce sont deux machines très compactes, qui ne consomment rien (~10w chaque) et qui sont quand même suffisamment puissantes pour pouvoir tester des trucs (i5-6500T + 8 Go de DDR4, extensible).

J’envisage d’ailleurs de me séparer de mon “gros” serveur E3-1220v5 et de son imposant node 304 de Fractal design à terme.

Installation du lab

L’installation est relativement sans surprise. Sur le site de XCP-ng, on a un ISO et on le copie sur une clé USB

wget https://mirrors.xcp-ng.org/isos/8.2/xcp-ng-8.2.1.iso?https=1
dd if=xcp-ng-8.2.1.iso of=/dev/sdX bs=8M oflag=direct

On branche la clé sur le serveur à installer et on boot. Le processus d’installation est un processus classique avec une TUI bleue comme vous en avez surement vu des milliers dans votre vie de vieux sysadmins. C’est un peu oldschool mais ça fonctionne.

Note: il est également possible d’automatiser l’install en PXE/iPXE sur des providers comme Equinix Metal (mais c’est hors budget pour moi).

Une fois l’installation terminée, on reboot et on se retrouve avec une interface que j’ai là aussi vu des dizaines de fois : le menu de XenServer :

Dans le ventre

De la bouche des devs de XCP-ng, on ne devrait pas avoir à se connecter sur les hyperviseurs. J’ai quand même été voir ce qu’ils avaient dans le ventre :-p.

Une fois connecté, on se rend vite compte qu’il s’agit d’une base RHEL, Centos pour être plus précis. Ca n’est pas vraiment une grande surprise, sachant que c’est la même base que XenServer que j’avais testé il y a 12 ans (j’en avais parlé ici)…

Première surprise, l’OS basé sur CentOS… en version 7… 😬

Ca commence à dater un peu, la sortie du premier CentOS 7 date de 2014, et la toute dernière version mineure (7.9) est sortie en 2020.

Surtout quand on connaît les dramas qui ont eu lieu autour de centOS / RHEL, j’aurais pas choisi cette OS.

On 8 December 2020, the CentOS Project announced that the distribution would be discontinued at the end of 2021 in order to focus on CentOS Stream. The community’s response to this announcement was overwhelmingly negative. https://en.wikipedia.org/wiki/CentOS

Vates justifie ce choix technique dans ce billet de blog.

Nous n’utilisons CentOS que pour les paquets “user land”. Xen et le noyau Linux sont des builds custom avec certains patches. Concernant le drama CentOS nous sommes peu/pas affecté justement pour ces raisons

Niveau kernel, c’est pas fou non plus.

uname -a
Linux xxx.zwindler.fr 4.19.0+1 #1 SMP Thu Jan 13 12:55:45 CET 2022 x86_64 x86_64 x86_64 GNU/Linux

Le 4.19 est le dernier LTS de la branche 4, avec certes un support jusqu’en 2024 mais on se prive quand même de pas mal d’améliorations de perfs de la branche 5, notamment pour le matoss récent… Dommage.

Enfin bon c’est toujours mieux que le kernel shippé avec CentOS 7 (3.10, LOL), mais à côté de ça, Proxmox VE 7.2 tourne en Bullseye avec un kernel custom en 5.15.

Xen Orchestra

C’est là où ça devient un peu moins naturel. Si vous allez sur le site pour installer Xen Orchestra xen-orchestra.com/#!/xoa (que je vais abrévier XOA), on va vous demander de rentrer une IP, un login (root) et un mot de passe.

Eeeeeuh, what?

Heureusement, la petite mention juste en dessous nous explique que tout sera fait en local et qu’il n’y a rien qui partira chez Vates 😏. En réalité, la page se connecte directement à votre host et déploie une VM appliance contenant Xen Orchestra prêt à l’emploi.

Bon… j’ai vérifié les trames envoyées sans rentrer mon vrai mot de passe et ça a l’air safe… Mais j’ai quand même préféré déployer la VM XOA via un script ou l’import d’un XVA 😏 :

Note: 8.8.8.8 en DNS par défaut… bof bof.

A l’issue de l’opération, vous avez donc déployé sur un de vos hosts XCP-ng une appliance XOA qui va vous permettre de piloter votre cluster.

~~Note: XOA est une appliance Debian 9 😬😬😬~~ Après vérification, je ne sais pas pourquoi j’avais écris ça dans mes notes. C’est du Debian 11 donc RAS.

Premiers pas dans XOA

Voilà à quoi ressemble le menu principal une fois loggué. On arrive sur une page avec la liste de nos VMs :

Un peu perturbant, par défaut un filtre est appliqué et n’affiche QUE les VMs allumées. Personnellement j’aurais préféré voir aussi celles qui ne le sont pas et je le désactive tout le temps.

Niveau UI, le style tranche avec celui de Proxmox VE. Certains reprochent à XOA d’avoir un style “UI playskool” et je comprends un peu où ils veulent en venir…

Les tailles des polices sont différentes d’un menu à l’autre, sans réelle cohérence, les boutons sont colorés, ya des tableaux jamais pareil d’un menu à l’autre … C’est très déstabilisant de premier abord et donne une impression pas très “pro”, à l’opposé des capacités de l’outil.

Heureusement, une version plus léchée devrait faire son arrivée dans les mois qui viennent (cf le blog de XOA). J’ai vraiment hâte de voir ce que ça donne car ça fait beaucoup plus sérieux sur les captures.

Version gratuite limitée ?

Un autre point déstabilisant de Xen Orchestra est que quand on navigue dans les menus, une petite moitié des menus et des fonctionnalités sont réservés à la version payante de l’outil. Certains menus ne manquent pas forcément pour un démarrage. Mais d’autres, c’est carrément problématique.

Typiquement, l’UI pour mettre à jour les serveurs n’est pas accessible sans licence. On a un panneau rouge pour nous informer qu’un serveur doit être MAJ, mais on ne peut pas le faire…

J’ai failli arrêter mon test, la première fois que j’ai vu ça… Un hyperviseur que je ne peux pas mettre à jour via l’UI, c’est no-go.

Je trouve ce point hyper frustrant, car en réalité on peut contourner cette limitation, puisque l’outil est entièrement open source. C’est même volontaire et assumé de la part des devs de XOA/XCP-ng (lien cassé, Nicolas n’est plus sur Twitter) : il faut “juste” le builder soit même.

Sauf qu’en attendant, beaucoup d’admins qui auront rapidement testé l’outil auront eu l’impression d’un freeware hyper bridé alors que ce n’est pas vraiment le cas. Je trouve qu’il y a un vrai manque au niveau communication et de clarté de ce côté.

Conclusion

Voilà pour ces premières impressions avec XCP-NG. Je m’arrête ici alors que je n’ai fait une présentation rapide de mon lab et des premiers menus, car on dépasse déjà les 11000 signes.

Globalement, l’UI/UX a vraiment besoin d’être retravaillée et ça tombe bien que Vates soit en train de travailler là-dessus car l’impression que donne l’outil n’est pas en phase avec ses capacités.

Au-delà de l’aspect visuel, les fonctionnalités semblent présentes, mais sont cachées par la mise en avant du support pro. Pour des gens comme moi qui cherchent une solution de lab perso ou de gens qui ne chercheraient pas à comprendre quelles sont les alternatives à la version payante, ça peut être repoussant.

~~Dernier point, certains choix techniques me paraissent très bizarres (CentOS 7, Debian 9) et il faudra que j’en reparle avec l’équipe de Vates…~~

Dans les prochains articles, je m’attaquerai à la partie utilisation (par exemple les sauvegardes ou la réplication, une création de VM puis migration à chaud) et probablement aussi au test de XOA non bridé.

Dites-moi ce qui vous intéresse en premier, histoire que je mette l’accent là-dessus tout de suite

En attendant, have fun !

Bonus

Pour automatiser les mises à jour, en attendant d’avoir débridé XOA, j’ai ajouté l’utilitaire yum-cron

yum -y install yum-cron
systemctl start yum-cron systemctl enable yum-cron
cd /etc/yum/ vim yum-cron.conf
cd /var/log/ cat cron | grep yum-daily

Sources

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 :)

Création d’un template CentOS 5.5 pour XenServer 5.6

Tue, 15 Feb 2011 21:46:29 +0000

Depuis quelques temps, ma solution de virtualisation est en place, mes VMs ronronnent, et je me suis lancé un peu plus profondément dans la supervision et tout ce qui s’en approche. Ceux qui lisent mes lignes de temps à autres sauront que j’avais déjà travaillé sur EyesOfNetwork et Nagios, mais j’ai voulu m’attaquer à quelque chose de nouveau et (à mon avis) mieux pensé.

Je parle bien évidemment de l’épopée Shinken, démarrée par un gars de la région, qui a aussi fait mon école, et dont je suis la progression depuis maintenant un moment (pratiquement le début en fait, même si ca à souvent été d’un œil distrait). Seulement voilà, pour pouvoir tester Shinken au maximum de ses capacitées, j’ai besoin de plusieurs VM vierges.

Fini l’époque bénie des VMs construites sur l’envie du moment : j’en ai marre! Il à donc bien fallut s’y résoudre : Créer des templates pour déployer rapidement (et proprement) un réseau complet.

Donc rien de bien « techniquement agressif » (comme dirait l’autre) aujourd’hui, je vous propose un petit tuto pour créer de bout en bout un template CentOS 5.5 sur un XenServer 5.6 (qui ne supporte théoriquement que CentOS jusqu’à 5.4 même si nous verrons que ce n’est vraiment pas un problème).

La première chose à faire pour créer un template c’est de commencer par créer la VM qui nous servira de modèle. Ceux qui auront toujours la même version 5.6 de XenServer que moi s’apercevront qu’il n’y a pas de template prédéfini pour CentOS 5.5. Nous prenons donc un 5.4, ça ne pose pas de problèmes dans le cas d’une installation par le Net (ce que je présenterai ici). Dans le cas d’une installation par l’iso, je crois que c’est plus problématique, et qu’il n’y a pas vraiment de solution à par installer via un DVD 5.4 puis changer de version par la suite (à vérifier).

Comme je l’ai sous-entendu plus haut, je vais profité du fait qu’il est possible d’installer CentOS via HTTP pour pouvoir disposer directement d’une version CentOS 5.5 dans ma VM.

Dans le cas où vous passez par un DVD, il est possible de réaliser cette installation par le net de la même façon, en sélectionnant le média FTP ou HTTP lors de l’installation.

URL : mirrors.centos.org
Directory : centos/5.5/os/x86_64

CentOS se met donc à s’installer sur la VM, une fois que vous avez répondu à toutes les questions. Pour tous les paramètres réseaux, comme il s’agit d’un template, il vaut mieux se contenter de garder des paramètre simple : Si possible, laisser le DHCP, on pourra reconfigurer l’IP de la VM au cas par cas sans risquer de provoquer de conflit d’IP lors de gros déploiement.

Si tout se passe bien, il fini par rebooter au bout d’un moment. La première chose à faire une fois que la VM est fonctionnelle, c’est d’installer les XenServer-Tools. En effet, ce sont eux qui permettent à la VM d’être complètement « consciente » de son état de VM et donc d’atteindre ~~l’ataraxie~~ la paravirtualisation (gain de performance et gain en contrôle sur la VM). Par défaut, ces XenServer Tools sont situées dans un iso que l’on monte donc sur la VM.

Et on lance les commandes suivantes pour monter et exécuter le programme d’installation :

mkdir /mnt/cdrom
mount /dev/xvdd /mnt/cdrom
/mnt/cdrom/Linux/install.sh

Une fois le programme installé, un reboot s’impose! Selon les gouts « shutdown -r now » ou « init 6 ». Une fois que c’est fait, il faut mettre son système à jour avec « yum upgrade », et pourquoi pas installer tous les produits et logiciels indispensable à tout votre parc? Pourquoi pas non plus ajouter des repos additionnels tant qu’on y est (cf cette page du wiki.centos.org (lien mort, remplacé par Internet Archive))?

wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
rpm -K rpmforge-release-0.5.2-2.el5.rf.*.rpm
rpm -i rpmforge-release-0.5.2-2.el5.rf.*.rpm

yum list htop

pour vérifier que l’importation à bien fonctionné (d’ailleur il y a la base des rpms dispo qui devrait se reconstruire dans la foulée)

Voilà, on a maintenant le parfait candidat pour un template! Pour pouvoir le créer, on doit éteindre la VM. Pour créer ce template, on a plusieurs possibilités. D’abord, on peut créer une Appliance, qui est en fait un template destiné à être exporté sur le web dans un format standardisé (.ovf). Typiquement, ce mécanisme est utilisée par des personnes qui fournissent une VM fournissant un service préinstallé, ou, dans le cas de la virtualisation VMware, par les utilisateurs de ESXi sans vCenter pour contourner l’absence de cette fonctionnalité :-p (je ferai un article là dessus bientôt).

Sinon on peut aussi convertir la VM en un template (opération « définitive ») et elle n’apparaitra plus dans la liste comme une VM mais bien comme un template. C’est ce que je vais faire ici.

Il est désormais possible de créer très rapidement des VMs à partir de ce template. Les seules choses à modifier une fois le déploiement terminés sont donc

le hostname (bah oui, c’est quelque chose d’unique!)
supprimer l’interface eth0.bak créée par XenServer lors du déploiement
et éventuellement modifier les infos IP de la machine

rm /etc/sysconfig/networking/devices/ifcfg-eth0.bak
rm /etc/sysconfig/network-scripts/ifcfg-eth0.bak
system-config-network
service network restart

[Test] XenServer 5.6, du solide mais de petites déceptions

Fri, 10 Dec 2010 17:05:42 +0000

Dans l’article précédent relatant la théorie et l’installation de XenServer, j’avais fais deux constats :

XenServer ce n’est pas Xen (on est pas loin d’un ESXi pour toute la couche de présentation, l’OS qui sert d’hyperviseur, et l’architecture de type Serveurs d’un côté, console de gestion unifiée de l’autre)
XenServer ça s’installe TRES vite et TRES simplement.

N’allez pas croire que je sous-entend que c’est vraiment un avantage par rapport aux concurrents. On s’en sort très bien pour installer un ESX(i) ou un Hyper-V sans aucune difficulté (il faut avoir une culture « Systèmes », quand même!) et en peu de temps, mais bon, j’ai quand même été bluffé.

Contrairement à d’autre blogs spécialisés de gens qui peuvent se permettre de présenter en détails toutes les fonctionnalités des licences payantes, je me contenterai de présenter ce que je peux voir, avec ma pauvre petite licence Express.

A partir de maintenant, on entre dans le vif du sujet, l’utilisation jour après jour des serveurs, piloté par l’intermédiaire du XenCenter.

Première chose à faire une fois le XenServer installé sur le serveur, et XenCenter sur la machine d’administration, c’est de lier le serveur au XenCenter. Ceci se fait de manière assez triviale en cliquant sur les boutons qui vont bien (Add New Server »).

De la même manière, la gestion des fermes de serveurs (on appèle ça des Pools chez Citrix) peut se faire assez facilement, en créant une ferme et en y affectant des serveurs. Attention cependant, j’ai cru comprendre qu’il fallait des serveurs identiques au sein d’une même ferme pour que cela fonctionne bien (même versions, ça c’est sûr, même hardware, je n’en suis plus certain mais ça me parait prudent).

Pour chaque serveur ou Pool, il vous est donc possible en très peu de clics de créer des VMs, mais aussi des Storages. Ce qui est plutôt chouette selon moi c’est qu’au dela des divers moyens de stocker des disques virtuels sur le réseaux (NFS, iSCSI, HBA, Advanced StorageLink), il est possible de monter des partages contenant vos isos en NFS et en CIFS (contre juste NFS pour VMware, aux dernières nouvelles). Même s’il n’est pas bien compliqué de monter un partage NFS pour un admin système, il peut être pratique d’avoir juste à créer un partage Windows depuis la machine d’administration (pour les archi de type maquette par exemple) et soyons honnête, ça ne coute pas cher à ajouter comme fonctionnalité!

L’affichage des VMs présentent sur le serveur se fait d’une manière assez classique : Un bandeau menu avec toutes les fonctionnalités disponibles, un volet de gauche qui liste les serveurs et leurs VM et un volet central qui se découpe enonglets permettant de gérer de façon plus spécifique l’élément sélectionné.

Par exemple quand on sélectionne une serveur ou un pool, on dispose d’une liste des VMs hébergées que l’on peut trier par nom, usage CPU, usage mémoire, moyenne d’accès disque ou réseau, adresse IP, uptime… Simple mais efficace. Chaque élément dispose d’un onglet Performance, qui retrace l’évolution de la métrologie dans le temps (temps relativement court dans la version Express). Un onglet Users permet de joindre un domaine AD pour accorder des droits sur les VMs, et un onglet Log permet de tracer les opérations du serveur.

Dans l’ensemble, tout ce qui est nécessaire au bon fonctionnement d’un serveur bien dimensionné et dans des conditions normale d’utilisation me semble vraiment bien ficelé. Pour tout vous dire, ma machine ainsi que ses VMs tournent depuis plusieurs mois sans problèmes, et je l’ai mise à jour, j’ai supprimé des VMs, j’en ai créé d’autre, … (oui, je n’écris l’article que maintenant)

Mais comme je l’ai dis dans le titre, tout n’est malheureusement pas rose. XenServer est clairement un produit très aboutis et qui propose gratuitement certaines fonctionnalités bien utiles (voire vitales? La gestion de serveurs en ferme et le LiveMotion gratuit, c’est vrai que ça fait envie) que VMware ne propose qu’avec un vCenter (et la licence qui va bien), et des caractéristiques techniques de même niveau sur de nombreux points (pour un avis un peu moins partial que les sites des éditeurs, voir la comparaison de VMGuru (lien mort, j’utilise Internet Archive)). En grattant un peu, on voit bien que certains points sont plus aboutis chez VMware.

La liste des systèmes d’exploitation invités supportés, par exemple. Là où j’ai eu très peu de difficultés à créer des VMs avec des OS peu courants sous ESXi, on sent bien que XenServer est plus réticent. La liste des OS supportés et vraiment faible actuellement (v5.6), proposant Windows, du Debian et du RedHat (et autres dérivés artificiels pratiquement identiques).Et encore, certaines versions uniquement (il arrive que les noyaux ‘de base’ de certaines versions récentes supportent mal XenServer)!

Autre déconvenue, quand on clique sur l’onglet Memory d’un serveur, on se retrouve malheureusement face à un message du type « Upgrade XenServer to enable Dynamic Memory Control ». Oui, la mémoire n’est pas attribuée dynamiquement. Il est donc très important de bien gérer sa RAM. J’ai très vite atteint mes 8 Go sur ma machine de test!

De la même façon, le Thin Provisionning pour l’espace disque semble ne pas être aisé à mettre en place avec la version 5.6 (et pas possible sur la 5.5 sauf tour de passe passe de sioux), qui devra être attribué avec parcimonie et justesse (la taille des disques peut être modifiée une fois les VMs éteintes, mais attention à ce que les OS le supportent!). Cependant il semblerait que le FP1 de la 5.6 corrigera bientôt ce problème (A l’installation… je pense que c’est trop tard une fois installé).

Et enfin, peut être un problème mineur la plupart du temps, mais l’utilitaire de customisation de la machine virtuelle est beaucoup plus complet sous ESX(i). Sous XenServer, c’est même minimaliste. On peut modifier les composants vitaux (CPU, HDD, RAM, cartes réseaux), mais guère plus. C’est rare, mais pourtant des fois c’est utile de pouvoir définir rapidement le nombre de ports COM de la machine virtuelle…

Voilà donc un petit tour d’horizon de mon ressenti…

[Test] Premiers pas sous XenServer & co : la théorie et ce que j’en attendais

Wed, 06 Oct 2010 17:32:33 +0000

Et oui, je fais des infidélités à VMware. Je ne vous l’avais pas dis, mais ça fait un moment déjà que j’ai arrêté de jouer sous ESXi. Je me suis lassé de devoir bidouiller pour pouvoir faire fonctionner ESXi sur du matériel non supporté, de devoir bidouiller pour trouver des workaround pour éviter les limitations de la version gratuite.

Pour être parfaitement honnête, la goûte d’eau a été le fait que ma carte réseau fonctionnait très mal (à cause du fait que j’utilisais un pilote équivalent à première vue, mais pas adapté en réalité). Sous Windows, certaines cartes virtuelles (E1000 et Flexible) ne fonctionnaient pas, et sous FreeNAS, c’était carrément impossible de faire fonctionner le réseau. Après avoir tenté d’autres OEM modifiés avec d’autres pilotes réseau, j’ai fini par abandonner (temporairement? le temps d’acheter du matériel plus pro, peut être?).

Après avoir passé pas mal de temps à étudier les concurrents, je me suis mis en tête d’installer XenServer, en espérant que mon matériel soit mieux supporté. Et je n’ai pas été déçu…

Commençons par le commencement, un peu de théorie. J’ai connu XenServer en faisant des recherches sur Xen, le paravirtualiseur libre. Depuis quelques temps, XenSource a été vendu à Citrix, qui est parti de cette base pour faire sa propre solution de virtualisation.

Les architectures de ce type fonctionnent de la façon suivante : Les diverses machines virtuelles fonctionnent au DIRECTEMENT au dessus du matériel (domU dans la terminologie Xen). Cependant, comme un seul OS peut avoir le droit d’utiliser le matériel, les ressources disponibles sont distribués à l’essemble de VMs par un OS un peu spécial, à mis chemin entre une machine virtuelle et un OS hôte (le dom0). Il s’agit souvent un noyau linux modifié, installé sur l’OS hôte initial de la machine.

La GROSSE différence entre les hyperviseurs qui font de la « virtualisation complète » (VMware) et la paravirtualisation tient du fait que dans ces derniers, les machines virtuelle non privilégiées sont « conscientes » d’être des machines virtuelles, et font donc appel au chef d’orchestre dès qu’elles ont besoin d’une ressource.

Pour éclaircir un peu mes propos, je vous propose un graphique de wikipedia, tiré de l’article parlant de Xen (ici).

Mais ce fonctionnement n’est pas aussi idéal qu’on pourrait le penser. Les noyaux de ces VMs doit être modifiés pour permettre cette « conscience ». Du coup, avec Xen, c’est surtout les noyaux linux qui fonctionnaient le plus souvent avec Xen, les sources de Windows (ou autres) étant beaucoup moins accessibles (Même si des versions récentes de Xen n’ont plus ces limitations, mais pour ne pas vous embrouiller, je n’en parlerai pas).

A l’opposé, VMware est (historiquement) plutôt partisan d’une autre approche de la virtualisation : la virtualisation complète, et plus récemment avec un hyperviseur. Contrairement à la paravirtualisation, les machines virtuelles ne sont pas directement au-dessus du matériel, elles sont séparées de celui-ci par une fine couche logicielle (l’hyperviseur) qui se charge de distribuer les ressources. L’avantage de cette technique est que les machines virtuelles n’ont alors pas besoin d’être consciente de leur virtualisation, et donc n’ont pas besoin d’un noyau modifié. L’inconvénient est que théoriquement, les performances sont un peu moindres, à cause de « l’empilage ». De ce que j’en ai compris, ce choix technique est surtout poussé par les premières versions des serveurs VMware, qui ressemblait pas mal à des émulateurs, à installer au-dessus d’un serveur Windows (VMware GSX & VMware Server 2).

Mais assez de théorie, passons à du tangible!

Pour découvrir XenServer, j’ai bêtement cliqué sur un lien nous vantant les mérites de XenDesktop (lien mort). Parce que OUI, pour tenter de prendre des parts de marché à VMware, Citrix est prêt à vous donner gratuitement :

Le serveur lui-même (XenServer, en version 5.5, même si j’utilise la 5.6, après l’avoir mis à jour)
Le poste de pilotage (XenCenter)
Les ISOs contenant les programmes nécessaires pour monter un VDI (XenDesktop), c’est-à-dire la distribution de postes de travail comme un service (jusqu’à 10 utilisateurs, avec la plupart des fonctionnalités, dont les plus utiles).

La première chose qu’on peut dire, c’est qu’on n’est pas vraiment perdu. Citrix propose une infrastructure proche de celle de VMware, avec des serveurs pilotés conjointement par un vCenter, contrairement à Xen qui se pilotait directement depuis le serveur, sans passer par l’intermédiaire d’un poste de pilotage. Vous aurez peut-être remarqué que les noms sont également très proches, par pure coïncidence certainement ;-).

Après avoir rempli quelques informations sur moi-même sur le site de Citrix, j’ai pu télécharger l’archive contenant le tout, puis commencer l’installation. Pour rappel, je dispose d’un PC de bureau qui fonctionne avec un I7 et 8Go de RAM pour la partie serveur, et un portable qui me sert de XenCenter.

Pour ce qui a été de l’installation du serveur en elle-même j’ai trouvé tout ça très intuitif. A force d’installer des distrib Linux, on finit par être habitué au beau menu texte tout bleu! Pour ceux qui voudraient plus de précision, voici un walkthrough des plus complets ici. En quelques minutes, XenServer était installé, configuré, prêt à l’emploi.

Mais ce qui choque le plus, une fois que notre XenServer a passé le boot, c’est la console de configuration…

Remplacez le bleu par du jaune, et le noir par du gris… Ça ne vous rappelle rien? Et oui, vous aurez bien sûr reconnu l’interface de configuration de VMware ESXi… Enfin bon, du coup ce n’est pas dur de s’y retrouver. D’autant plus qu’il n’y a pas vraiment de différences d’utilisation entre cette console et celle de ESXi (un peu plus fournie pour XenServer), car elle ne vous servira qu’à configurer le strict minimum, puisque le gros de l’utilisation se fera depuis le XenCenter.

Léger avantage, peut être, XenServer propose un accès à la console direct, et non pas camouflé comme VMware. J’ose donc en déduire que l’accès à la console est « autorisé », même si probablement pas supporté, au même titre que la Technical Console de VMware (l’ex « hidden console »). Vous pouvez aussi avoir un aperçu de la charge utilisée par vos VMs, mais bon, tout ça est un peu superflux une fois qu’on a ajouté l’hôte au sein du poste de commande, je trouve.

Ce qui est intéressant, ce n’est pas l’interface graphique, mais bien ce qu’il y a dessous. Et bien justement, en dessous, on est très proche d’un ESX ou d’un ESXi… Quand on explore la console, on se rend compte qu’on a affaire à un Redhat modifié pour être le plus léger possible. Alors « OUI », il s’agit ici d’un dom0, au sens OS privilégié du terme chez XenSource, mais bon, au final, on se rend compte que ce que notre XenServer fait, c’est surtout de la virtualisation complète, comme ESX(i), le Redhat ultra léger de XenServer servant d’hyperviseur « bare metal » au dessous des VMs…

Au final, en cherchant à trouver les différences techniques entre XenServer et ESXi, j’ai surtout trouvé des similitudes. Le gros point fort pour moi, c’est que ça marche parfaitement sur ma machine de test. Cependant, ce n’est pas vraiment un critère utile pour la plupart des gens qui peuvent se permettre (dans un contexte plus professionnel) d’acquérir du matériel supporté par VMware. Comme ça commence à faire un peu long comme article, j’aborderai mes impressions sur XenServer dans sa réelle utilisation (via une administration XenCenter) dans un prochain article.