Retour d'expérience sous Proxmox

Rédigé par Fenix - - 5 commentaires

(Dis comme ça, on dirait le nom d'une nouvelle drogue... mais non !)

Si ces dernières années il y a bien un outil dont je suis tombé amoureux, c'est bien Proxmox (bon, ZFS aussi, mais ça fera l'objet d'un autre article).

Pour ceux qui ne connaissent pas, Proxmox est un hyperviseur : il permet de créer et gérer des machines virtuelles, de les répartir sur des clusters de 2, 3... 60 serveurs, de les migrer à chaud, etc. C'est un environnement à mettre sur le même plan que VMWare ESX, oVirt, Xen, ou encore Microsoft Hyper-V.

Enfin, pas tout à fait : si Proxmox se démarque, à mon sens, c'est pour tout un tas de raisons que je vais tenter d'évoquer ici avec une forte subjectivité assumée (sinon, à quoi bon en faire un article de blog ?). J'ai eu l'occasion de travailler un peu sur tous ces différents environnements, mais pour certains ça date d'il y a plusieurs années : je risque donc de passer à côté de quelques nouveautés/améliorations, mais l'essence devrait rester la même.

Avant de démarrer, je tourne sous Proxmox depuis maintenant 5-6 ans, depuis la version 2. J'ai vu le produit évoluer et gagner en maturité, les forums se peupler, et de plus en plus de DSI s'y intéresser. Je ne prétends absolument pas être un expert, simplement un utilisateur un peu avancé qui en a déployé un certain nombre, dans des contextes matériels et humains variés.

Et donc, pour ceux qui ne connaitraient pas, Proxmox ça ressemble à ça :


 

Proxmox : Virtualization is Magic !

 

Installation et maintenance


Le premier point que je voudrais souligner est la simplicité de déploiement et de mise à jour de Proxmox : ça se greffe par-dessus une Debian, et c'est tout. Un dépot, un apt install, et ça tombe en marche. Et si vous voulez créer un cluster, ça tient en une commande.

Pour les mises à jour, un upgrade/dist-upgrade, et c'est plié.

Quand je vois les difficultés qu'on peut rencontrer, en 2018, pour mettre à jour des plateformes VMWare, ça me laisse songeur. Il faut mettre à jour le vCenter, PUIS les ESX, faire gaffe à ses configurations (notamment côté sauvegardes/réplications), vérifier 10 foix l'upgrade path pour être sûr de pas exploser des VM/fonctionnalités en cours de route... Je comprends parfaitement pourquoi des experts certifiés sont demandés pour ce genre de plateforme : ce sont des usines à gaz. Littéralement. Et c'est bien conçu pour le rester et emprisonner les utilisateurs. Encore dernièrement, j'ai vu une mise à jour d'un VMWare vCenter Appliance nous semi-pêter entre les mains : l'update se fait via un ISO qu'on monte à distance, puis une série de commandes mal documentées qui nous retournes des sorties qui ne correspondent pas à ce que la procédure indique, et après le reboot on se retrouve avec une interface de management en vrac. Obligé de relancer tous les services à la main en CLI (et avec un shell limité, bien sûr), toujours sans documentation bien entendu... Ou encore les mises à jour "mineures" qui modifient le comportement du produit, et qui obligent à réinstaller une version antérieur (là encore, VMWare je t'aime). Combien ça coûte, déjà, ces machins ?

Même côté oVirt, au moins, on clique-droit sur l'hôte à mettre à jour, il migre ses VM et se met en maintenance tout seul, fait sa mise à jour, reboot, et réintègre la production. Tout seul.
 

Le modèle économique


Proxmox est distribué via deux canaux : un dépôt gratuit, et un payant. Celui-ci, en plus de donner accès aux dépôts "pros" (stables), permet bien entendu de faire appel au support de l'entreprise derrière Proxmox, qui d'après les retours que j'ai pu avoir est plutôt pas mal. Petit calcul rapide : si on part sur l'offre Basic (à mon sens amplement suffisante pour 90% des usages en production), on est sur du 20€/mois/CPU, soit 40€/mois pour la plupart des serveurs (bi-processeurs, indépendamment du nombre de coeurs), ou 480€/an. Si on compare avec le coût d'un VMWare ou d'un Hyper-V complet (ou du moins fonctionnel), qui se chiffrent en milliers d'€ (voire en dizaines), ça fait réfléchir (sans compter les innombrables fonctionnalités à acheter en plus, pour la réplication, l'administration en HA...). Ah et sauf erreur de ma part, côté M$/VMWare, on facture au coeur (logique) de CPU, histoire de faire exploser la facture davantage tous les ans...

(Quand je pense aux stacks VMWare + Windows + Oracle + ARS +... qu'on trouve dans pas mal de grandes structures (dont du public), j'ai mal à mon portefeuille et à mes impôts... mais ceci fera sûrement l'objet d'un autre article).

Et si on préfère rester sur la version gratuite, on a les forums : c'est actif, les réponses sont pertinentes et les gars de Proxmox répondent et prennent en compte les remontées d'erreur rapidement (on a souvent droit à des fix en live, reportés après validation dans les dépôts). Je mets toutefois un petit bémol ici : j'ai souvent constaté que le dialogue pouvait être compliqué avec les "admins" de chez Proxmox (en tout cas ceux qui interviennent sur les forums), à savoir "c'est comme ça et pas autrement". Disons, pour simplifier, que la roadmap de leurs équipes n'est pas toujours celle souhaitée par les utilisateurs (des dépôts gratuits).

Ceci étant, en parlant de roadmap, force est de constater que le produit évolue vraiment bien ces dernières années : davantage de backends de stockage supportés, une interface d'aministration qui s'étoffe tout en restant accessible (n'est-ce pas, oVirt ?), une hyperconvergence assumée avec Ceph... On pourrait s'attarder sur le débat OpenVZ/LXC qui a eu lieu (et persiste) au passage de Proxmox 4, car nous avons notamment perdu la possibilité de migrer à chaud des conteneurs, mais il faut aussi voir que c'est l'écosystème dans son ensemble qui doit évoluer (dont le kernel, ici).

Et pour ceux qui veulent contribuer, on peut : Bugzilla + Git + Wiki
 

Du stockage, encore du stockage !


Proxmox supporte nativement plusieurs "backends" de stockage (plusieurs technologies) pour stocker les VM et les conteneurs : des répertoires locaux, du LVM, des exports NFS, des volumes GlusterFS, des pools ZFS, des LUN présentés en iSCSI, ainsi que du Ceph. En gros, tout ce qui peut exister aujourd'hui, ou presque. Petite pensée émue pour HyperV qui ne supporte pas grand chose, ou encore oVirt qui, si je ne me trompe pas, se limite à du local, du NFS et du iSCSI... Certaines fonctionnalités vont également être implémentées différemment selon le backend, pour tenir compte des spécificités de chacun : je pense par exemple aux snapshots, qui utiliseront les fonctionnalités offertes par LVM ou ZFS quand disponibles, et qui à l'inverse pourront être indisponibles pour les conteneurs LXC stockés dans des répertoires locaux ou des exports NFS. ZFS permettra aussi de compresser de manière transparente les VM/conteneurs, ce qui peut être un véritable argument économique (j'ai personnellement des ratios de compression de 2 en moyenne, sur des jeux de données et des environnements applicatifs variés (hormis multimédia)).

Concernant Ceph, il s'agit d'un véritable parti pris par la société Proxmox elle-même, qui mise sur une solution hyperconvergée, fusionnant les couches de "computing" (CPU, RAM) et de stockage en un tout unifié et évolutif. Bien que je n'ai pas suffisamment de recul sur cette solution, ni sur Ceph d'ailleurs, je trouve cette approche intéressante, car elle permet vraiment de tirer partie de toutes les ressources disponibles (souvent, les disques d'un hyperviseurs sont "perdus", se limitant à l'OS). Concernant les prérequis physiques, on pourrait se dire que Ceph va être gourmand côté réseau, mais comme nous sommes en 2018, vous aurez de toute façon un réseau 10G dédié pour votre stockage, n'est-ce pas ? :)
 
 

KVM + LXC = miam !


Autre intérêt de Proxmox, c'est qu'il offre nativement de la virtualisation traditionnelle (basée sur KVM), pour faire tourner des Linux, des Windows, ou tout autre machin exotique, ainsi que de la conteneurisation (LXC). L'avantage est ici que les 2 technologies sont disponibles au sein du même environnement, administrées depuis la même interface, et ça, c'est méga méga cool (argument technique pointu @inside). Plus besoin donc d'avoir deux (ou plus) infrastructures pour héberger nos services ! Attention toutefois, Docker n'est par exemple pas supporté, mais qui met du Docker en production de toute façon ? (je troll si j'en ai envie, je suis chez moi). Si ce besoin est clairement identifié, il sera toujours possible de s'appuyer sur des VM pour en héberger.

Et donc, qu'en est-il de du côté des autres produits ? oVirt : KVM only ; VMWare ESX : virtualisation traditionnelle only ; HyperV, idem. Oui, on peut greffer des produits supplémentaires pour amener ce genre de fonctionnalités, mais ça n'est pas embarqué nativement (donc surcoût + complexification).
 

J'aime mon manager


Alors là, THE argument en faveur de Proxmox (en plus de tous les autres "THE argument" évoqués jusqu'ici) : l'interface d'administration de nos clusters n'est pas un SPOF ! (Single Point Of Failure). C'est simple : sur VMWare ou oVirt, par exemple, vous avez UN manager (de base (et même si vous pouvez quand même vous connecter sur chacun des ESX individuellement au cas où)). Si vous ne mettez pas en place une solution de repli ou si vous ne payez pas la licence qui va bien pour en déployer un autre, débrouillez-vous le jour où le manager tombe en panne et où un incident se produit à ce même instant sur votre production. Bonne chance pour essayer d'intervenir, les minutes de restauration de votre manager vont vous paraître affreusement longues... Et arrêtez tout de suite avec vos analyses de risque ou vos taux de probabilité : la loi de Murphy, c'est la SEULE qui importe dans un datacenter.

Proxmox, dans sa génialitude, offre une interface d'administration distribuée : chaque hôte intégré au cluster offre la même interface, et peut contrôler tous les autres. En cas de perte d'un hôte... Et bien on s'en fout, on utilise les autres. JUSTE MA-GIQUE. Ah, et j'ai mentionné que l'interface est accessible via un simple navigateur ? Pas de client lourd, pas d'outil à distance (sauf SSH, si vous préférez la CLI), pas de Java, pas de Flash... Console virtuelle pour les VM/LXC, monitoring des ressources, gestion des droits utilisateurs, des pools de ressources, des mises à jour... tout y est, sans rien à installer. Encore une pensée émue pour VMWare vCenter, où la DERNIERE version de Flash est indispensable, celle que même le Chrome disponible sous Linux n'embarque pas...
 

Power up !


Bon, de ce côté-là c'est d'une difficulté insurmontable : on Debian-ise un nouveau serveur, on lui greffe Proxmox (en 5 min chrono), on l'intègre au cluster, et c'est tout. On peut déjà profiter des nouvelles ressources, migrer nos VM, etc. Toujours sans coûts de licence supplémentaires, sans modification d'une quelconque configuration (si vous avez bien pensé en amont vos backends de stockage et vos configurations réseaux).

Ah oui, petit apparté sur un sujet qui me sort un peu par les oreilles : nous sommes en 2018, arrêtez d'utiliser des bridges Linux ! Juste, STOP ! OpenVSwitch, c'est stable, ça juste marche, et c'est infiniment plus simple à maintenir ! Avec des bridges Linux, chaque hôte doit être configuré à la main, tout nouveau VLAN doit être monté à la main sur tous les membres du cluster... Et ne me parlez pas d'automatisation, c'est clairement mettre un pansement sur une architecture old-school de vos clusters. Vous aggrégez (bonding) vos interfaces de production, vous en faites un OVS, et basta. Par défaut, c'est un trunk, c'est-à-dire que tous vos VLAN sont autorisés (du moins ceux que vous laissez passer depuis vos switchs de distribution) : aucune configuration à modifier pour un ajout ou une suppression, déployez juste vos VM, assignez-leur des interfaces taguées (ou non, si vous voulez le gérer dans vos VM), et zou. KEEP-IT-SIM-PLE ! (alors oui, la sécurité nianiania, tous les hôtes sont connectés dans tous les VLAN, #ceylemal : alors non, désolé, mais c'est à vous de ne délivrer que les VLAN pertinents à vos hôtes de virtu, configurez vos switchs, automatisez-les avec Ansible, faites du SDN si ça vous tente, mais vos hôtes de virtu sont JE-TABLES. Vous les déployez, en 5 min c'est opérationnel, vous les décommissionnez en 5 min aussi, ça doit se limiter à ça).

Aparté n°2 : ça, c'est dans le cas d'un backbone layer2 traditionnel. Pour un backbone layer3 (avec de l'OSPF ou du BGP, as you want) + VxLAN par exemple, ça sera un poil plus compliqué niveau configuration. Je rêve de travailler sur ce type d'architecture, d'entrer dans le 21e siècle... :'(
 

Je t'aime moi non plus


Fonctionnalité offerte par je suppose la plupart des produits évoqués jusqu'ici : l'affinité des VM, c'est-à-dire les règles de leur répartition sur les noeuds de vos clusters. Exemple simple : vous avez 3 hôtes et 3 frontaux Web dessus, vous les configurez pour qu'ils ne tournent jamais sur le même hôte au même moment et ainsi garantir un minimum la disponibilité de votre service en cas de perte d'un hôte. Enfin, sur Proxmox c'est plutôt une préférence que vous définissez : vous préférez que les VM XX, YY et ZZ tournent sur l'hôte 1, puis sur l'hôte 2 si perte du 1, puis sur l'hôte 3 si perte du 2, et vous préférez que les VM XX2, YY2 et ZZ2 fassent l'inverse (l'hôte 3 en priorité, etc). Les VM sont donc à la fois réparties selon vos préférences, et également redémarrées automatiquement en cas d'incident sur un hôte : c'est 2 en 1 !

Petit bémol toutefois : il faut BIEN penser cette configuration pour ne pas tout transformer en usine à gaz. Personnellement, je trouve que ça mérite une sacrée gymnastique des neurones pour répartir toute une production sur ce schéma, et que Proxmox gagnerait en accessibilité sur ce point en permettant de juste définir des affinités/répulsivités entre 2 VM, et que le cluster se débrouille tout seul pour les mettre sur deux hôtes différents. Peut-être un jour sur la roadmap ?
 
 

Le côté obscur de Proxmox


Mais tout n'est pas rose pour autant dans le merveilleux monde des Bisounours qui tournent sous Proxmox. Passons à ce qui fâche (toujours d'après mon humble avis).
 

Live-migration or not live-migration ?


Alors, le premier truc vraiment dommageable (même si plus haut j'ai dédouané Proxmox pour ce choix, oui j'aime me contredire moi-même) : depuis Proxmox 4 et le passage d'OpenVZ à LXC, il n'est plus possible (pour le moment ?) de migrer à chaud des conteneurs d'un hôte à l'autre. Ce qui nécessite tout de même de sérieusement revoir certaines architectures.

Je vais toutefois nuancer ce point, comme déjà fait plus haut :
  • d'une part, cette problématique part déjà du constat que les kernels supportés par OpenVZ avaient un sacré retard, et que Proxmox voulaient aller de l'avant ;
  • ensuite, [argument invalide car je ne suis pas du tout un expert LXC/OpenVZ, donc je me tais et passe au suivant] ;
  • et enfin, si on a une archi haute dispo avec plusieurs frontaux, plusieurs BDD, etc, on peut se permettre une interruption de quelques secondes sur l'un d'entre eux (hormis si vous avez des BDD de plusieurs centaines de Go, là ça risque de prendre un petit moment au reboot/à la resynchro...). Bon, semi-argument dédouanant, ça reste un impact à considérer sur sa production. Sinon, mettez le plus critique sur du KVM.
 

LXC, c'est bien mais... non, en fait rien


Un truc qui pouvait être pratique aussi avec OpenVZ, c'était le montage des conteneurs dans l'arborescence des hôtes : vous pouviez les gérer en mode fichier à l'envie, et pour la sauvegarde ça pouvait se révéler pratique (on pouvait sauvegarder l'hôte et les conteneurs en même temps, même si je n'aime pas cette méthode). Depuis LXC (sous Proxmox), les conteneurs sont en mode "RAW", c'est-à-dire que vous avez juste devant vous un fichier image, bien dur, bien opaque. Ou un volume ZFS, ou un VG, selon vos backends de stockage. Mais dans tous les cas, vos conteneurs ne sont plus accessibles en "mode fichier", ce qui a amené pas mal de personnes à rouspéter. Personnellement, je n'en ai cure. Vraiment. Je gère mes LXC en SSH, comme n'importe quelle VM, ça ne change pas ma vie.

Donc bon, critique légère car je ne me sens pas vraiment concerné.
 

Renommer un node


Ah, en voilà un exercice sympathique : renommer un node Proxmox dans un cluster ! Alors, un bon conseil : NE le faites PAS. Juste, non, JAMAIS. Virez le du cluster, réinstallez-le au propre sous un autre nom et réintégrez-le, ça vous économisera un temps précieux. Dans les cas où ce n'est pas possible, préparez-vous à pas mal de manipulations audacieuses, des renommages de fichiers, des modifications dans des bases SQLite, les services de clustering qui ne redémarrent pas correctement car l'ID du node est en conflit avec un autre du cluster qui nianianiania.... Il y a eu plusieurs procédures sur le Wiki de Proxmox pour cette opération au fil des ans, mais aucune n'était 100% safe, tout dépendait de vos versions de Debian/Proxmox, de la chronologie de vos manipulations, etc.

(Après, je suis à peu près sûr que cette manipulation est tout autant déconseillée (voire impossible) sous du oVirt/VMWare).
 

Gratuit = instable ?


Dépôt gratuit oblige, vous aimez vivre dans la peur. Chaque mise à jour est peut-être celle de trop, celle qui flinguera irrémédiablement vos VM, votre production, vos nuits (que vous passerez à restaurer...).

#oupas. Bien que gratuits, les dépôts sont toutefois suffisament stables pour de la production, pour peu que vous preniez quand même la peine de les valider sur un environnement de test pendant quelques jours, mais comme toute mise à jour qui se doit. Si vous utilisez les dépôts de "test", alors là oui bien sûr, mais c'est un choix à assumer :)

Il m'est toutefois arrivé de vivre certaines périodes... disons "intenses" avec Proxmox, en particulier suite à des mises à jour du kernel (il faut savoir que c'est un kernel "custom", les équipes de Proxmox backportant certains patchs depuis des sources RedHat, ou compilant en amont les modules ZFS, par exemple). Il y a ainsi eu des périodes où mes machines KVM crashaient systématiquement sans raison, où mes conteneurs pouvaient ne pas démarrer... Périodes qui donnaient généralement lieu à des fix en "live" sur les forums, testés par la communauté puis reportés dans les dépôts, justement. Ca permet de rapprocher un peu les administrateurs et la communauté, on peut le voir comme ça !

Mais encore une fois, si on valide ça en environnement de test, qu'on évite les dépôts de test et qu'on surveille les forums durant les quelques jours qui précèdent/suivent nos mises à jour, ça reste tout à fait correct (pas plus compliqué que toute distribution Linux, quoi).
 

Répartition auto-magique des VM


Un point en passant sur la gestion des "spares" (hôtes gardés de côté en cas d'incident, pour absorber la production) et de la maintenance des hôtes. Sur Proxmox, quand on souhaite vider un hôte pour effectuer une maintenance (mise à jour, par exemple), on migre toutes ses VM sur un autre. Il n'est pas possible, comme sur oVirt par exemple, de répartir automatiquement les VM sur le reste du cluster, simplement et sans jouer au Tetris.

Un petit quelque chose qui changerait pourtant grandement la vie... :'(
 

La sauvegarde, ce n'est pas accessoire


Allez, cet article est déjà suffisament long comme ça, un petit dernier pour la route : la gestion des sauvegardes des VM.

Alors, points positifs : c'est inclus nativement dans la solution, et ça marche. En revanche, si vous n'avez pas réfléchi et/ou consulté la doc avant de monter votre cluster, vous pouvez parfaitement vous retrouver à faire des sauvegardes de vos conteneurs en mode snapshot (par exemple), et qu'à chaque fois ceux-ci soient éteints puis rallumés pour que la sauvegarde s'effectue... Pourquoi le mode snapshot ne fonctionne pas ? Parce que vous n'avez pas le bon backend de stockage ! Eh oui, il faudra y penser avant, quand vous construirez vos clusters. Mais sinon, ça fonctionne juste out-of-the-box.

Et donc, me direz-vous, qu'est-ce qui ne va pas avec cette solution de sauvegarde ? Deux choses, d'après moi :
  • Premièrement, il n'est pas possible (nativement) de faire de l'incrémental. On sauvegarde donc l'intégralité de chaque VM à chaque fois, ce qui est ultra-couteux en terme de temps, de volumétrie, et de bande passante. Et ce sujet est conflictuel depuis plusieurs années : c'est une demande de la communauté qu'on retrouve régulièrement sur les forums, la librairie utilisée par Proxmox en est parfaitement capable... Mais non. Du coup, on peut quand même trouver un script qui active cette "incrémentalité" (oui, je trouvais que ça sonnait bien), mais il faut le réappliquer à chaque mise à jour. J'avoue ne pas du tout comprendre le pourquoi du comment de cette histoire : ça ne coûterait rien aux équipes de Proxmox, et ça ravirait tous ceux qui utilisent cette solution... Bref.
  • Et la seconde, c'est du côté de la rétention des sauvegardes : bien qu'il soit possible de définir autant de jeux de sauvegarde qu'on le souhaite, pour toutes ou partie des VM, il n'est pas possible de définir la rétention pour chacun de ces jeux. Elle est définie AU NIVEAU DU BACKEND DE STOCKAGE !!! Je... Je n'ai jamais compris cette logique... Qu'est-ce que ça amène de le faire à ce niveau ? RIEN. Et ça empêche JUSTE de créer des jeux de sauvegarde adaptés à nos besoins, à nos différents envionnements... Même point que précédemment, ça fait des années que c'est remonté, mais aucune évolution. Juste, POUR-QUOI ?
 
 
 

En conclusion


Bref, quoiqu'il en soit, Proxmox reste un excellent produit. C'est simple, ça marche, c'est "beau", et ça convient à une très grande variété d'usages. Je connais des environnements de production qui s'appuyent dessus depuis plusieurs années, ça ne bronche pas (enfin, pas plus que d'autres). Malgré les quelques points négatifs évoqués en seconde partie de l'article, je recommande chaudement l'étude de cette solution à tous ceux qui ne la connaissent pas, ou à ceux qui hésite depuis longtemps. Mettez-là en concurrence avec vos oVirt, vos ESX, vos Hyper-V. Oui, il y aura des différences, mais il est parfaitement possible que les fonctionnalités manquantes (s'il y en a) ne soient au final pas indispensables, ou facilement compensables.

Si vous avez eu une autre expérience de cette solution ou si vous avez un point de vue différent, je suis tout ouïe ! Je crois vraiment en celle-ci, j'aimerais la voir se développer davantage dans les catalogues de services des DSI et venir proposer une alternative crédible et simple aux malheureusement trop répandus et onéreux M$/VMWare, notamment dans le public.

Qui sait ? :)

 

5 commentaires

#1  - kida a dit :

je confirme. beaucoup de retard sur l'actualité ovirt (hyperconvergence avec glusterfs), hôte de gestion virtuel, exports stats avec grafana (bon ça c'est vraiment récent), gestionnaire réseau bien mieux qu'avant. Pour les FS c'est bien plus varié qu'avant.

Répondre
#2  - Fenix a dit :

Je dois avouer aussi que je n'ai eu que très récemment la possibilité de découvrir un oVirt 4.2... (on tournait essentiellement sur du 3.X)
Ceci étant, j'avais bien suivi la convergence avec Gluster, mais hormis ça, du NFS ou du iSCSI je ne vois pas trop de nouveautés côté stockage. J'ai même cru comprendre (je le prends avec des pincettes) que Ceph était à exclure d'un environnement oVirt, ce que je trouve dommageable (si c'est bien le cas).
Mais en effet, la dernière version a amené en tout cas une belle refonte du manager, ça devient plus simple de s'y retrouver :)

Répondre
#3  - bounaberdi a dit :

Merci pour cet article,
Pour qu'un conteneur utilise le file system du host, il faut déclarer une taille 0 à la création.

Répondre
#4  - rikar a dit :

Ici dans le «public», en particulier en recherche médicale, nous utilisons Proxmox (6 à 10 noeuds pour une trentaine de VM).

On héberge du Linux, du Windows et du OpenBSD. Pour le stockage on utilise nas4free. Je n'aime pas trop ZFS.

Répondre
#5  - Walter a dit :

HERETIQUEEEEEEE !!!!!!!
bonjour,
qu'est ce que tu n'aimes pas dans ZFS ?

Répondre

Fil RSS des commentaires de cet article

Écrire un commentaire

Quelle est la quatrième lettre du mot jbmevv ?