Passer le menu

Auteur Sujet: Xen  (Lu 1356 fois)

mdouke

  • Recensé
  • *
    • Voir le profil
Xen
« le: 02 mai 2019 à 19:35:19 »
Bonjour,
Nous avons un serveur sous Xen 4.0 qui date de 2012.
Suite à une copie de machine virtuelle, il y a un soucis quand on souhaite administrer la machine
Tout d'abord il semble que Xend ne soit plus lancé puisque que lorsqu'on fait rmp qa xend, on n'obtient rien.
Idem si on fait xm list, il n'y a pas de retour et plus inquiétant, la session ssh est déconnectée.
Si quelqu'un a une piste ?
Merci;
mdouke

Zatalyz

  • La Papesse
  • Orateur émérite
    • Voir le profil
Re : Xen
« Réponse #1 le: 02 mai 2019 à 20:47:19 »
xm list ou xl list ? De notre côté on utilise xl, donc il va probablement falloir adapter ce que je raconte... Pour info, notre hyperviseur est en 4.8.4 sur une base Debian donc on va probablement avoir des différences dans certains trucs.

Je ne suis pas sûre de bien comprendre, je vais reprendre et tu me corriges si je me trompe. Votre hyperviseur est donc avec Xen 4.0.  Déjà, de ce côté, il tourne bien ? Il répond ?  Oublions les VM pour le moment, tant qu'il ne fais pas de message d'erreur et affiche dom0/Domaine-0 avec xl list, c'est déjà bon. Nous avions eu des soucis à un moment parce que le grub redémarrait sur le mauvais noyau (donc sans Xen) et à partir de là, forcément, rien ne marchait. De ce que je comprends, c'est déjà un premier souci si xm list ne marche pas ? Par contre c'est étrange que ça déconnecte la session ssh ; ça voudrait dire un gros plantage.

Je t'avoue aussi mon ignorance sur la commande "rmp qa xend", elle est sensée faire quoi ? Tu as le droit de me renvoyer sur la bonne entrée de manuel, hein ;) mais ça clairement, on n'a pas eu l'occasion de jouer avec.

Si jamais c'est l'hyperviseur qui a un souci (et non la VM, même si ça peut être lié), tout dépend de ce qui est en cause. Avec un peu de chance, c'est juste grub (ou autre bootloader) qui est sur la mauvaise entrée, ce qui est à vérifier en premier, et je crois qu'on avait noté les manip dans le tuto sur le wikhan (mais pour être honnête on avait galéré un moment). Les options de notre hébergeur pour monter le disque en chroot avait bien aidé parce qu'on avait réussi à bloquer le démarrage...


Rollniak

  • Sysadmin
  • Citoyen du Khanat
  • *
    • Voir le profil
Re : Xen
« Réponse #2 le: 03 mai 2019 à 12:32:05 »
Bonjour,

Il manque quelques informations pour pouvoir te répondre :
Sur quel système d'exploitation tourne ton Xen ?
Quelle est la version de ton système d'exploitation ?
Que retourne la commande uname -a ?

Nota: attention toutefois, ta version de Xen n'est plus maintenue depuis 2015, la préparation et l'exécution d'une mise à niveau est plus que recommandé. :)
https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases

Nota 2: Le passage de Xen 4.0 a Xen >= 4.1 entraîne le changement des commandes de Xen.
https://wiki.xenproject.org/wiki/Migration_Guide_To_Xen4.1%2B#Toolstack_upgrade_notes
Système d’exploitation : OpenSuSE, FreeBSD
Éditeur de texte : NeoVim

mdouke

  • Recensé
  • *
    • Voir le profil
Re : Xen
« Réponse #3 le: 03 mai 2019 à 15:39:19 »
Salut les gars,
Merci pour vos réponses.
C'est un serveur qui est sous Debian 6.0.10. Oui je sais c'est très très vieux avec un Xen 4.0. A vrai dire, on n'a jamais fait de migration de peur de tout casser car dessus on a une VM qui gère les noms de domaines et une autre pour les mails et une autre pour une app.
Alors pour répondre à vos interrogations :

uname -a renvoie:
Linux xxxx 2.6.32-5-xen-amd64 #1 SMP Fri May 10 11:48:05 UTC 2013 x86_64 GNU/Linux

xm list renvoie:
Error: Unable to connect to xend: Connection refused. Is xend running?
(ou xl list c'est pareil)

Et si je fais un simple xend --version, il se déconnecte de la session ssh.

Nous ne saurions pas faire une migration. Si vous connaissez quelqu'un qui pourrait le faire, moynnant rémunération, ça peut nous intéresser.
Merci,
Mdouke

Zatalyz

  • La Papesse
  • Orateur émérite
    • Voir le profil
Re : Xen
« Réponse #4 le: 03 mai 2019 à 16:45:07 »
Citer
Salut les gars,
Y'a aussi des filles :P

Y'aurais pas le mail, je te proposerais de faire moi-même la migration :D Mais il y a moyen de migrer l'hyperviseur en laissant les VM avec de vieilles versions d'OS (pour commencer).

Bon, déjà, c'est assez sûr, Xen n'est pas lancé. Ça c'est le tout premier point. D'ailleurs... Du coup les mails et l'app ne fonctionnent pas ? ou si ? Si oui, il se passe un truc réellement étrange (mais je ne connais pas votre archi, si vous avez plusieurs serveurs par exemple qui font de la redondance ?)

Je ne sais pas combien tu as d'utilisateurs qui risquent d'être impactés par les bidouilles. Si c'est du genre petite asso, que les mails, app et site soient indisponibles quelques heures voir quelque jours est acceptable, s'il y a des "clients" ou beaucoup de monde ça sera plus délicat. Quoi qu'il arrive, communique en amont parce qu'il va y avoir des interruptions de service, c'est assez sûr. Ça passera mieux si les gens sont prévenus. Sans entrer dans les détails techniques forcément (la plupart des gens n'y comprennent rien et s'en moquent), mais donne une durée potentielle pour les "troubles" et prévoit large.

Ensuite, vu les bidouilles à faire, la première chose à vérifier est que ton système de backup marche bien.

Une fois la partie "backup" vérifiée, et les utilisateurs prévenus, on va pouvoir passer aux bidouilles en tout genre.

Là, je te conseillerais bien de tester en local ou sur un second serveur d'installer une debian+Xen à jour, puis de transférer des clones de tes VM, de les lancer et de voir si ça tourne (sans faire de mise à jour sur les VM même, encore une fois ; y'aura que l'hyperviseur à jour).

Si vous avez des sous, prendre un second serveur est vraiment le meilleur plan, vous résilierez le précédent à la fin si tout se passe bien.

Les noms de domaines ne seront pas bons sans les redirections DNS (et à ce stade osef), donc il y aura des erreurs, mais voir si côté système tout marche, déjà : xen se lance, les vm se lancent, elles ont un lot d'erreur "logiques", elles arrivent à communiquer avec le reste d'internet. Si c'est le cas, double allelluia : ça supportera l'upgrade, ce qui veut dire un hyperviseur qui ne sera plus exposé à diverses failles de sécurités, et tu auras un truc fonctionnel en backup. Et quelque part, ta migration aura commencé sans en avoir l'air. Mais pour cloner une VM, il faut l'éteindre... Si Xen est down en principe elles ne sont donc pas lancées. J'espère qu'elles utilisent LVM, parce que dans ce cas, il suffit de suivre ce tuto (et il y a probablement plus élégant, mais chez nous ça a marché).

Note qu'en gros je te conseille de faire une migration en mode pas à pas ;) mais je pense vraiment que c'est le mieux à faire ; il y a vraiment pas mal de trucs de sécu corrigés dans les dernières versions de Debian et de Xen (et avec ssh aussi, arghhhh). Il est possible que vos soucis viennent de l'exploitation d'une faille : on ne va pas psychoter sur ça (y'a pleins de raisons possibles), mais le mieux est de mettre à jour sans transférer d'éventuels trucs compromis, donc de partir d'un hyperviseur neuf, où tu vas remettre tes règles iptables en regardant bien ce qui est ouvert et pourquoi, transférer les éventuels scripts en vérifiant qu'ils ne sont pas corrompus, et laisser tout ce qui est système sur l'ancien serveur. Cette partie là n'est pas complexe, promis, il faut juste prendre le temps de vérifier au fur et à mesure que tout marche comme attendu.

Si ces étapes-là fonctionnent bien, on pourra voir pour mettre aussi les VM à jour. C'est le passage le plus délicat. Celle dont tu dis "qui gère les noms de domaines" j'imagine que c'est le proxy ; s'il est bien pensé, ça sera facile à mettre à jour et augmentera considérablement la sécurité de l'ensemble. Par contre, le mail, je ne touche pas, je sais juste que c'est complexe. Et l'app, suivant le langage et ce qu'elle fait, idem, ça peut être facile ou complexe. Mais là aussi, il y a des astuces pour tenter une mise à jour sans tout casser irrémédiablement, grâce aux snapshots et clones. Pour te donner un ordre d'idée, nous avons eu un souci similaire avec notre site internet, qui héberge divers CMS. L'upgrade risquait de mettre un bazar monstrueux. Nous avons donc laissé tourner l'ancienne VM, et à côté nous avons créé une seconde VM, où on a installé tous les CMS, puis transférer les données. Lorsque cette seconde VM a été opérationnelle (et à jour), on a mis la précédente en lecture seule, fait une dernière synchronisation des données, changé la redirection et hop ! c'était à jour. Bon, avec les moyens de bénévoles sans trop de temps et pas toujours toutes les compétences, mettre cette VM en place aura demandé quasi un an de tâtonnement... mais on y est arrivé ;)

Bon courage, on reste présent pour aider. N'hésite pas sur toutes les questions, si ça va trop vite, ou au contraire si on te dit des trucs un peu trop évident. On peut aussi solliciter un réseau de sysadmin pour voir si quelqu'un serait dispo pour vous faire ça, mais uniquement si ça te semble la chose à faire : personnellement je n'aime pas que les inconnus puissent tripatouiller mes serveurs et tous les sysadmins de Khaganat ont mis du temps avant d'accéder à nos machines, le temps de bien se connaître.

shepeng

  • Administrateur
  • Citoyen du Khanat
  • *****
    • Voir le profil
Re : Xen
« Réponse #5 le: 03 mai 2019 à 17:37:12 »
moi je pense qu'à ce stade, le plus simple est de faire les migrations directement sans s'occuper de xen dans un premier temps :

1 - désinstaller xen et ne garder que des noyaux non xen
2 - migrer squeeze->wheezy->jessie->stretch
3 - installer xen
4 - réparer les VM
« Modifié: 03 mai 2019 à 18:02:13 par shepeng »

shepeng

  • Administrateur
  • Citoyen du Khanat
  • *****
    • Voir le profil
Re : Xen
« Réponse #6 le: 03 mai 2019 à 18:08:27 »
Utilisez-vous lvm ?

Reste-t-il de la place sur le disque ?

Essayez de lancer vos commandes dans un screen ou un tmux comme ça s'il casse la session c'est le screen ou le tmux qui déconnecte et pas la connexion ssh.

Que disent les logs quand vous essayez de lancer xend ?

shepeng

  • Administrateur
  • Citoyen du Khanat
  • *****
    • Voir le profil
Re : Xen
« Réponse #7 le: 03 mai 2019 à 18:13:01 »
Je connais pas la commande rmp, c'est sensé faire quoi  rmp qa xend ?

mdouke

  • Recensé
  • *
    • Voir le profil
Re : Xen
« Réponse #8 le: 05 mai 2019 à 10:50:19 »
Bon alors là mille pardons  :balai:
Cela correspond tout à fait à ce que l'on envisage de faire. A savoir, enlever le serveur sous Debian 6 et migrer sur une autre machine
@shepeng
rmp permet de voir si un paquet est installé et si il tourne : https://www.system-linux.eu/index.php?post/2008/12/21/Commande-rpm
Merci,
Mdouke

Rollniak

  • Sysadmin
  • Citoyen du Khanat
  • *
    • Voir le profil
Re : Xen
« Réponse #9 le: 06 mai 2019 à 00:40:55 »
Bonsoir :search:,
Citation de: mdouke
rmp permet de voir si un paquet est installé et s'il tourne : https://www.system-linux.eu/index.php?post/2008/12/21/Commande-rpm

Il s'agit de la commande rmp rpm, elle est dédié aux systèmes d'exploitations à base de Red Hat, il faut regarder de la commande dpkg sous Debian. Essaye ceci :

dpkg-query -L *xen*
Citer
Cela correspond tout à fait à ce que l'on envisage de faire. À savoir, enlever le serveur sous Debian 6 et migrer sur une autre machine
En ce qui concerne les machines virtuelles, je vous conseille de faire un essai en laboratoire (environnement de test) afin de vérifier le bon fonctionnement de ses dernières sur la nouvelle installation de votre hyperviseur.

Si vous avait un accès physique a vos serveurs de test et de prod, je vous invite à regarder le projet suivant : https://xcp-ng.org/

Bonne soirée
Système d’exploitation : OpenSuSE, FreeBSD
Éditeur de texte : NeoVim

Tags: