J’ai finalement migré mon serveur Hyper-V, de Windows Server 2008 à Windows Server 2008 R2, pour tomber sur un problème délicat avec des machines virtuelles Linux et la disparition de leur carte réseau.
Je n’ai pas forcément pris le chemin habituel. Certains auraient simplement mis à jour le système après avoir pris soin d’arrêter les machines virtuelles. D’autres auraient exporté les VM, réinstallé le système, puis réimporté les VM. Personnellement aucune de ces deux solutions ne me convenait : je suis réticent aux upgrades de systèmes, préférant repartir à chaque fois sur une installation “propre”. Et le mécanisme d’export/import de VM change la structure de stockage des fichiers sur le disque, ce qui ne me convient pas non plus. A tord !
Bien évidemment, les problèmes que j’ai rencontrés ne me seraient pas arrivés si j’avais suivi l’une ou l’autre des solutions “normales”. J’ai donc procédé comme ceci (ce que je ne recommande donc pas si vous êtes pressé) :
- Vérifier qu’aucune VM n’a de snapshot.
- Eteindre toutes les VM.
- Note : dans ma configuration, le système est sur un disque, les VHD sur un autre, et les sauvegardes sur un troisième.
- Sauvegarder les VHD –à noter que ce sont les seuls fichiers que je conserve dans la manipulation, car j’ai l’intention de définir les nouvelles machines virtuelles avec ces mêmes VHD.
- Noter la définition des VM et des réseaux virtuels.
- Installer Windows Server 2008 R2 comme une nouvelle installation (en supprimant la partition existante sur le disque réservé au système). Installer les mises à jour, les comptes utilisateurs, l’adresse IP, etc.
- Activer le rôle Hyper-V et utiliser le script HVremote pour mettre en place l’administration à distance.
A ce stade, j’ai donc un système 2008 R2 propre sur le disque système, Hyper-V opérationnel, et mes fichiers VHD d’origine sur le disque d’origine qui leur était dédié.
- Réinitialiser les ACL sur tous les fichiers VHD (icacls *.vhd /reset), ceci principalement par souci de détail. Voir ici pour une explication des ACL qu’Hyper-V ajoute sur les VHD. Nettoyer les ACL des permissions laissées par un ancien Hyper-V n’est pas obligatoire, mais c’est une bonne idée, lorsque l’on réutilise un disque sur un nouveau système, de faire le ménage sur les ACL.
- Créer les réseaux virtuels tels qu’ils existaient auparavant.
- Créer chaque VM avec la même configuration qu’auparavant : mémoire, carte réseau (normale ou legacy selon les cas), VHD... Au passage, Hyper-V 2008 R2 inclut par défaut un contrôleur SCSI dans chaque nouvelle VM : on peut le supprimer si la VM n’en avait pas auparavant.
Jusqu’ici tout va bien, il ne reste plus qu’à démarrer les VM.
Premier déboire : un Windows XP nécessite une réactivation, à cause du changement de matériel. Puis, après mise à jour des composants d’intégration, la carte réseau est vue comme une nouvelle carte, paramétrée par défaut en DHCP. Si une adresse fixe est nécessaire, il faut la redéfinir, ce qui produit un avertissement classique :
Ce qui aurait dû me mettre la puce à l’oreille pour le problème des machines Linux...
Venons-en donc à une machine virtuelle Linux, plus exactement un Debian 4.0 (etch). L’erreur est immédiatement visible au boot :
et à la commande ifconfig :
Plus de carte réseau... alors que la commande dmesg montre que le driver Tulip (la carte Legacy network adapter n’a pas changé entre les versions d’Hyper-V) est bien chargé et reconnait bien la carte et sa nouvelle adresse MAC :
Après quelques recherches et essais divers, il s’avère que la nouvelle carte est bien présente, mais le noyau l’a nommé eth1 au lieu de eth0 :
Pour remettre les choses en place, trois solutions sont possibles :
Première possibilité, dans le fichier /etc/network/interfaces, remplacer eth0 par eth1. C’est le plus simple, le plus rapide.
Deuxième possibilité, si l’on souhaite appeler eth0 la nouvelle carte, il faut savoir que Linux maintient une correspondance entre les adresses MAC et les noms d’interfaces. Ce fichier se trouve dans /etc/udev/rules.d. Sur un de mes systèmes il s’appelle 70-persistent-net.rules, sur un autre : z25-persistent-net.rules. La règle semble être que le fichier s’appelle <préfixe>-persistent-net.rules :
On voit bien dans ce fichier l’historique des adresses MAC rencontrées par le système, et comment la nouvelle a été numérotée eth1.
Il suffit alors d’éditer ce fichier pour attribuer le nom eth0 à la nouvelle adresse MAC :
Troisième possibilité : dans Hyper-V, configurer la machine virtuelle pour donner à la carte réseau la même adresse MAC que l’ancienne machine virtuelle... Ce qui explique pourquoi il aurait été judicieux de faire un export et un import de la VM, et conserver l’adresse MAC d’origine.
J’espère que cela évitera des déboires à certains, et dépannera ceux qui perdent leur carte réseau.
Et je remercie mon collègue Youssef, et Bing pour avoir trouvé le fichier 70-persistent-net.rules à la vitesse de l’éclair !
