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

Zwindler’s reflection

Wed, 21 Apr 2010 17:54:47 +0000

Bonjour,

Pour faire dans l’original, j’ai ouvert un compte Free pour créer mon blog perso d’informaticien, histoire de faire partager mes découvertes et mes réflexions « extraordinaires » sur tout un tas de sujets passionnants tels que :

La vie d’un Sysadmin adepte du « Do It Yourself »
La virtualisation, parce que la virtualisation, c’est la vie
Linux sous toutes ses formes
Windows et les joies liées à l’administration d’un groupe d’utilisateurs ~~mécontents~~ épanouis
Des applications Open Source -ou pas-
Du scripting -orienté sysadmin, bien sûr-
Du hardware parce que ça déborde chez moi

L’idée n’est généralement pas d’attirer le chaland avec des tutos bourrés de screenshots sur des sujets abordés X fois ailleurs (avec X tendant vers +l’infini), mais plutôt de donner des astuces sur des sujets plus confidentiels pour lesquels j’ai eu du mal à trouver des réponses facilement et/ou rapidement.

C’est sûr, ça fait moins d’audimat ;-)

Zwindler

PS : Pour le fun: xkcd.com/705

[Edit]Après avoir été longtemps limité par la faible capacités des pages perso Free, je me suis résolu à passer sur wordpress.com, conscient des limites que ça allait m’imposer[/Edit]

[Edit2]Et j’ai finalement craqué, et j’ai déplacé le blog une nouvelle fois, mais sur un hébergement un peu plus sérieux => OVH[/Edit2]