Problème de migration VM debian 11.6 sur Hyper-V

Support Debian
,
Tags: #<Tag:0x00007f63e4abce68> #<Tag:0x00007f63e4abc6c0>
#1

Bonjour à tous,

Mon entreprise dispose d’un logiciel libre de gestion de parc informatique (GLPI) et la solution est installée sur une machine virtuelle linux (debian 11.6 avec interface graphique). La machine virtuelle est hébergée sur un Windows 10 professionnel, sous Hyper-V.

Dans la démarche de l’exporter vers un autre serveur, celui-ci en Windows Server 2019 Core, j’ai entrepris de faire l’exportation via le « Gestionnaire Hyper-V » comme je l’ai toujours fait.

Sur la machine source (où est actuellement hébergé la VM) :

Séléctionner la machine > Exporter… > Définir l’emplacement > Exporter > Patienter jusqu’à la fin de l’export indiqué dans « Statut »

Ensuite il suffit juste de copier les fichiers de la VM en incluant les 3 répertoire comportant les données des snapshots, disques et VM sur la machine de destination.

Sur la machine de destination, dans le gestionnaire Hyper-V :

Importer un ordinateur virtuel… > Localiser le dossier > Sélectionner la VM > Choisir le type d’importation > copie ou non selon le type d’importation et réglage réseau > Terminer

Note:J’ai essayer cette manipulation avec tout les type d’importation possible…

Toutes les étapes (3 étapes) se font correctement sans aucun message d’erreur.

Mais pourtant quand vient le moment de lancer la machine virtuelle sur le nouvel hôte, la machine debian affiche un message d’erreur de type :

« Oh mince, quelque chose s’est mal passé, contactez votre administrateur. » (sans code d’erreur bien évidement…)

Cependant je constate que malgré tout la machine fonctionne, je peux la lancer en mode diagnostique et tout les fichiers sont accessibles, et comble de tout le GLPI fonctionne ! Je peux l’utiliser complètement, j’ai juste l’impression que le plantage à lieu au niveau de l’interface graphique.

Voici une liste non-exhaustive de mes tentative afin de faire en sorte que la machine démarre dans le même état que sur la machine sources (en Windows 10 Pro) :

  • Lancer avec le processeur en mode « compatible » (coche : migrer vers un ordinateur physique ayant une autre version de processeur) j’ai remarqué qu’appliquer ses paramètres, fait planter de la même façon la VM sur la machine source…

  • Tout les type d’importation, id unique et copie.

  • Définir manuellement le disque dur VDHX

Bref je ne trouve rien de concrets dans la documentation Microsoft, je pense avoir respecté toute les bonne pratique pour la migration de VM, peut-être que certaines d’entre elle m’échappe, je compte sur vous pour m’instruire si c’est le cas, en vous remerciant par avance ! :slight_smile:

PI : Les ordinateur virtuelles sont de génération 1.

#2

c’est la partie graphique de debian qui a rencontré un souci, la partie graphique fourni par HyperV n’est pas la même.

Connectes-toi en ssh pour vérifier ce que tu peux voir au niveau des logs et tente (si il ne manque pas de firmware/micro code) un :

dpkg-reconfigure xserver-xorg
#3

Bonjour Clochette,

Tout d’abord merci beaucoup pour l’attention portée à mon poste !

J’aurais peut-être dû commencer par là mais je suis novice avec Debian, quel nous intéresse ?

Celle du fichier « dpkg.log.1 » ou de « syslog » ?

la VM tourne sur un environnement bureautique GNOME, et j’ai relevé qu’il y avait des erreurs concernant ceux-ci dans « syslog » :

Autre chose j’ai tenté : sudo dpkg-reconfigure xserver-xorg

la commande est passée mais rien n’a été résolu

Sinon je me sert pas de cette interface graphique, c’était un « miss click » de ma part à l’époque, la plupart du temps je me connecte en SSH… Si on peut la supprimer ça me va très bien !

#4

Il te faudra stopper gdm à la main et procédez à la désinstallation de gnome de cette manière :

tasksel remove desktop

Vérifie quand même ce qu’il vire (fais un snapshot avant depuis ton hyperviseur) et valide après coup avec un redémarrage.

#5

Encore merci pour ta réponse !

C’est-à-dire ?

Ne t’en fait pas je travail sur une copie de la VM, la VM en production est éteinte et sur la machine source ! :slight_smile:

#6

par exemple :

systemctl stop gdm.service
#7

Alors du coup j’ai essayé avec une autre commande pour stopper gdm

sudo service gdm stop

J’ai ensuite fait la commande :

tasksel remove desktop

Cependant, tu avait vu juste ça à l’air de faire un grand nettoyage car après coup les commande sudo sont indisponible :open_mouth: J’ai du les réinstaller pour faire mon reboot…

Par contre l’interface graphique se lance encore au redémarrage avec le fameux « oh mince… » :laughing:

#8

Quand tu fait un tasksel remove desktop tu te retrouves avec une minimaliste (hors packages ajoutés à la main, sauf dependances).
Et sudo ne fait pas partie de l’installation minimaliste.

#9

Bonjour Zargos merci pour ces précision c’est ce que j’ai plus comprendre en effet !

Cela n’empêche que malgré tout l’interface cherche à se lancer coûte que coûte…

Ce problème va me rendre zinzin !

#10

Pour l’interface:

    systemctl stop gdm
    systemctl disabled gdm

le premier pour l’arrêter, le second pour l’empecher de redemarrer automatiquement.

#11

Très étonnant que gdm ne soit justement pas virer lors du remove.

que donne :

tasksel --list-tasks

Ainsi que :

apt policy gnome-shell gdm3 gnome
#12

Merci Zargos et Clochette pour votre aide précieuse je suis finalement parvenu à enlever l’interface graphique, effectivement j’avais oublié :

systemctl disable gdm

Après quoi le redémarrage s’est fait sans problème, en mode minimale (sans interface)

Je ne pense pas que la commande :

tasksel remove desktop

Impacte plus que ça mon GLPI, j’ai juste besoin des packets mariadb, php8.2 et SSL et vu que j’avais malgré l’interface graphique pas ajouté d’autre packet à part ceux susnommé, de plus je constate qu’il sont encore listé. (dpkg --list)

Je vais quand même laisser tourner mon GLPI, comme ça dans une période d’essai, pour être sûr de son bon fonctionnement.

En tout cas je me souviendrais que la migration Hyper-V sous Debian est un peu casse-gueule, notamment au niveau de l’interface graphique.

Finalement la solution c’est de se passer de cette foutue interface :slight_smile:

Je vais répondre malgré tout à ça pour la science :

root@GLPI62710:~# tasksel --list-tasks
u desktop       environnement de bureau Debian
u gnome-desktop GNOME
u xfce-desktop  Xfce
u gnome-flashback-desktop       GNOME Flashback
u kde-desktop   KDE Plasma
u cinnamon-desktop      Cinnamon
u mate-desktop  MATE
u lxde-desktop  LXDE
u lxqt-desktop  LXQt
u web-server    serveur web
u laptop        ordinateur portableME Flashback

root@GLPI62710:~# apt policy gnome-shell gdm3 gnome
gnome-shell:
  Installé : 3.38.6-1~deb11u1
  Candidat : 3.38.6-1~deb11u1
 Table de version :
 *** 3.38.6-1~deb11u1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
gdm3:
  Installé : 3.38.2.1-1
  Candidat : 3.38.2.1-1
 Table de version :
 *** 3.38.2.1-1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
gnome:
  Installé : 1:3.38+3
  Candidat : 1:3.38+3
 Table de version :
 *** 1:3.38+3 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status
1 J'aime
#13

Effectivement ton interface graphique est toujours présente, apparement taskel remove ne désinstalle pas le bureau.

Tu peux sans doute virer les paquets cités.

#14

il a peut etre suffit que le package soit mis à jour à la main?