Configuration d’un serveur DNS-DHCP avec Zentyal

Chap 1. Configuration d’un serveur DNS-DHCP avec Zentyal
Chap 2. Installation de vSphere 6.5 dans Proxmox

Chap 1. Configuration d’un serveur DNS-DHCP avec Zentyal

La configuration de Zentyal comme serveur DNS/DHCP est assez intéressante, surtout si l’on opère sur son propre réseau local qui est en même temps son réseau domestique. Par « intéressante », je veux dire que c’est un petit « challenge ». Avant de parler des soucis que j’ai rencontrés en adoptant cette configuration, je vais tout d’abord vous expliquer le contexte.

Je me suis acheté un micro-serveur pour créer un lab « VMware » pour me préparer à leurs certifications. Cependant, pour me simplifier la vie, mon lab se trouve dans le même réseau que mes autres appareils connectés à internet. Et oui, c’est pas malin! Mais par contre, c’est pratique puisqu’il n’y a pas moyen de créer une route statique via le routeur de mon FAI. Et plus tard, une fois tout configuré, je déplacerai le lab vers la DMZ.
Le serveur DNS, je l’utiliserai surtout pour résoudre les noms de domaine en local, mais surtout pour en profiter pleinement de la fonctionnalité de « recherche de domaine » qui me permet de ne pas taper le nom de domaine entier (http://monserveur.mylab.local), mais juste son alias (http://monserveur). Par la même occasion, il est possible de faire un ping vers le nom d’hôte directement à partir du même réseau, sans passer donc ni par l’adresse IP ni le nom de domaine.

Ne confondez pas « nom d’hôte » et « alias ». Je vais vous montrer où il faut configurer l’alias dans Zentyal, un peu plus loin dans ce chapitre.

Si vous n’êtes pas habitué à configurer un serveur DNS, vous risquez de foutre le bordel sur votre réseau, mais ce n’est pas si grave que çà. Au pire, le temps de résolution d’un nom de domaine peut être très lent, ou peut ne pas se faire du tout. Petit conseil pour vous prémunir contre ce genre d’inconvénience, c’est d’ajouter manuellement un serveur DNS fonctionnel dans les configurations de réseau de vos machines directement connectées à internet. Pour les autres machines qui doivent se connecter au lab, il n’y a rien à faire.

Avant d’avancer dans la configuration de Zentyal comme serveur DNS/DHCP, je tiens à préciser que je n’ai pas réussi à installer l’OS à partir du CD d’installation téléchargé sur le site. Ceci probablement du au fait que je l’installe comme machine virtuelle, malgré plusieurs tentative de modification des différents paramètres comme le type de disque, etc. Du coup, je suis parti sur une base Ubuntu 16.04.

I. Préparation de la machine virtuelle

OS
Type: Linux 4.X/3.X/2.6 Kernel

Hard Disk
Bus/Device: VirtIO
Format: QEMU
Disk1 size: 8GB
Disk2 size: 20GB
Cache: Default
Discard « coché » (si vos disques durs physiques sont des disques SCSI)

CPU
Sockets: 1
Cores: 1
Type: Default (kvm64)

Memory
Use fixed size memory: 2048MB

Network
Bridged mode
Model: VirtIO (paravirtualized)

Configuration du serveur Zentyal

Installer Ubuntu 16.04, puis créer un fichier /etc/apt/sources.list/zentyal.list pour y ajouter un lien vers l’archive du site.

$ sudo vim /etc/apt/sources.list.d/zentyal.list
deb http://archive.zentyal.org/zentyal 5.0 main

Récupérer la clé publique

$ wget -q http://keys.zentyal.org/zentyal-5.0-archive.asc -O- | sudo apt-key add -

Procéder ensuite à l’installation de zentyal et de ces différents modules. Ceux qui m’intéressent sont zentyal-dns, zentyal-dhcp puis zentyal-ntp.

$ sudo apt update
$ sudo apt upgrade

$ sudo apt install zentyal

$ sudo apt install zentyal-ntp zentyal-dhcp zentyal-dns zentyal-common

Note: pendant l’installation, vous devrez donner un mot de passe pour l’administrateur Root de MySQL. Gardez bien ce mot de passe quelque part, puisque vous ne risquez pas de l’utiliser tant que vous n’avez pas de problèmes de bases de données.

II. Configuration du DNS et du DHCP

L’identifiant et le mot de passe par défaut si vous êtes dans une machine Ubuntu, pour accéder à votre session Zentyal – https://localhost:8443  – sont les mêmes que ceux utilisés pour la même session Ubuntu.

  1. Activer les modules DNS et DHCP
  2. Configurer l’interface en mode statique
    Note: ne cochez surtout pas l’option WAN, sinon vous n’aurez pas accès à cette interface ensuite via le réseau LAN
  3. Configurez votre gateway, qui est l’adresse IP locale du routeur de votre FAI, si vous faites une connection directe
  4. Ajouter votre nom de domaine
  5. Configurer le serveur DNS

    Ici, je trouve que cette page n’est pas du tout ergonomique, puisqu’il n’y a pas moyen de vérifier visuellement ce qu’on a configuré sans cliquer sur le bouton de configuration. De plus, il n’y a pas de bouton pour revenir à la page précédente une fois les informations de configuration ajoutées. Bref, voici mes options.Domain: mylab.local (le nom de domaine que j’ai choisi à l’étape 4)
    Domain IP Address: 192.168.1.20 (l’adresse IP du serveur, cf. étape 2)
    Hostname: xxx (ici, il faut rentrer un nom que vous avez choisi pour identifier une serveur. Ce nom peut être le même que celui de l’hote, mais ce n’est pas une obligation)
    Dans cet exemple, vous devriez pouvoir accéder à l’interface de configuration de Zentyal via son nom d’hôte https://dc-zentyal.mylab.local ou son alias https://zentyal.mylab.local.
  6. Configurer le server DHCP

    Dans l’onglet « Common options »Dans l’onglet « Dynamic DNS options »
    Dans l’onglet « Advanced options », il n’y a pas grand chose à modifier.

III. Configuration du routeur FAI et vérification


Comme je le disais au tout début de cet article, afin d’éviter d’avoir des problèmes d’accès à internet à cause d’un problème de résolution de nom, mieux vaut ajouter par précaution d’autres serveurs DNS comme 8.8.8.8 et 8.8.4.4, qui sont des serveurs DNS de google.
Concernant l’ajout d’un deuxième serveur DHCP, la règle c’est celui qui répond en premier à une requête DHCP qui attribuera une adresse IP à la machine qui en fait la demande. Du coup, il n’y pas pas de soucis à avoir deux serveurs DHCP sur le même réseau.

Pour finir, effectuons une petite vérification pour voir que le DNS fonctionne correctement.

Pour en savoir un peu plus sur la configuration de Zentyal, je vous renvoie à leur wiki.

Références:

En/5.0/Zentyal 5.0 Official Documentation
Zentyal installation (Ubuntu documentation)

Publicités

Installation de vSphere 6.5 dans Proxmox

Chap 1. Configuration d’un serveur DNS-DHCP avec Zentyal
Chap 2. Installation de vSphere 6.5 dans Proxmox

Chap 2. Installation de vSphere 6.5 dans Proxmox

L’installation de vSphère 6.5 dans proxmox n’est peut être pas évident pour tout le monde. C’est pour celà que j’écris cet article.

Avant d’aller plus loin, je tiens à préciser quelques points.

Primo, vous pouvez télécharger gratuitement la suite vSphère sur le site de VMware. Noter que le produit nécessite une license, une fois la période d’essai gratuite de 60 jours terminée.
Secondo, il n’est plus nécessaire d’installer vCenter dans un serveur Windows. Il faut l’installer comme une machine virtuelle à part entière.
Tertio, je tiens à rappeler que j’utilise debian 9.1 sur un macbook pro. Du coup, j’ai rencontré des soucis lorsqu’il fallait appuyer sur la touche F11 du clavier pour valider l’installation de l’ESXi. Bizarrement, c’est la seule touche en combinaison avec fn, qui n’est pas reconnue, puisque F2 et F9 le sont. Même soucis avec un clavier externe attaché au Mac. Il m’a fallut utiliser un PC/linux pour continuer et terminer l’installation.

I. Préparation est installation du serveur ESXi

Je pars du principe que vous avez installé Proxmox sur un ordinateur ou un serveur dédié avec au moins 16GB de mémoire physique.

Créez une machine virtuelle principale pour acceuillir le serveur ESXi, avec les spécifications suivantes.

CPU >= 2 (type: host)
RAM >= 10GB
Local disk0 >= 2GB (format VMDK)
Local disk1 >= 25GB (format VMDK)
Network: VMXNET3
OS: Other OS types

Ajouter un deuxième disque dur pour l’installation du serveur vCenter.


Ici, j’ai pris la taille du disque proposée par défaut, qui est de 35GB.

Une fois la machine virtuelle prête, vous pouvez vous lancer dans l’installation du serveur ESXi.

Concernant les adresses IP à appliquer aux serveurs, il est fortement conseillé d’utiliser une adresse IP statique.

Une fois l’installation terminée, formater le deuxième disque afin qu’il soit utilisable pour l’installation de vCenter. Pour celà, il suffit de taper l’adresse IP du serveur ESXi dans votre navigateur internet.

II. Installation du serveur vCenter

Comme je le disais dans le titre, il est maintenant possible d’installer vCenter à partir d’une machine tournant sous linux, mais cependant pas avec n’importe quelles distributions. Il faut utiliser Ubuntu ou Suse linux.

Je me suis donc créé une machine virtuelle Ubuntu dans Proxmox, puis j’ai lancé le fichier d’installation de vCenter. Ce; tte étape peut se faire en deux étapes. Une fois la première étape terminée, vous pouvez poursuivre l’installation à une date ultérieure, puis de reprendre à partir de la deuxième étape en entrant dans l’URL de votre navigateur l’adresse IP du serveur vCenter.

Étape 1:


En production, il est fortement recommandé d’ajouter un serveur via son nom de domaine au lieu de l’adresse IP. Je vous explique comment faire à la troisième partie de ce chapitre.

Comme je n’ai pas configuré de serveur DNS lors de cette manipulation, et surtout que c’est un lab, je peux donc me permettre d’utiliser l’adresse IP comme solution temporaire.


Note: Je viens de terminer un article expliquant comment configurer un serveur DNS. Je vous renvoie sur cette page pour voir comment procéder.


Étape 2:
Accéder à l’interface du vCenter à partir de son adresse IP. Vous allez constater qu’il vous faut du flash! Et oui, sans flash vous pouvez toujours utiliser l’interface en HTML5, mais avec des fonctionnalitées limitées.

Heureusement, le problème avec flash sera définitivement résolu d’ici 2020, finalement! Adobe a annoncé officiellement que flash sera retiré du marché après cette date:

« as open standards like HTML5, WebGL and WebAssembly have matured over the past several years, most now provide many of the capabilities and functionalities that plugins pioneered and have become a viable alternative for content on the web. (…) Adobe is planning to end-of-life Flash. Specifically, we will stop updating and distributing the Flash Player at the end of 2020 and encourage content creators to migrate any existing Flash content to these new open formats. »

III. Note concernant l’installation du vCenter via Ubuntu, une fois le serveur DNS/DHCP configuré

Dans la première partie de cet article, je vous ai expliqué comment installer un serveur vCenter lorsqu’on n’a pas de serveur DNS en place. Dans cette partie, nous allons en tenir compte de la présence de Zentyal, qui sera notre serveur DNS sur le réseau (cf. chap 1).

Avant de procéder à l’installation du serveur vCenter, je tiens à rappeler que j’utilisez un nom de domaine en .local (mylab.local). Celà pose un problème lorsqu’on utilise la version bureau de Ubuntu qui, utilise un serveur DNS en local (Avahi), et qui, lui aussi traduit les noms de domaines du type le-nom-de-mon-hote.local en adresse IP.

administrator@budgie:~$ ping debian.local
PING debian.local (192.168.1.10) 56(84) bytes of data.
64 bytes from 192.168.1.10 (192.168.1.10): icmp_seq=1 ttl=64 time=2.36 ms
64 bytes from 192.168.1.10 (192.168.1.10): icmp_seq=2 ttl=64 time=1.31 ms
^C
--- debian.local ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.317/1.838/2.360/0.523 ms

Par contre,

administrator@budgie:~$ ping esxi-01.mylab.local
ping: esxi-01.mylab.local: Name or service not known

 

Et ceci, malgré le fait que la résolution de noms se fait sans problème.

administrator@budgie:~$ host esxi-01.mylab.local
esxi-01.mylab.local has address 192.168.1.51

Si vous vous décidez tout de même à lancer l’installation de vCenter sans prendre compte les alertes ci-dessus, vous allez recevoir un message d’erreur de type:

error: Could not get certificate fingerprint from host, esxi01.mylab.local: Error: getaddrinfo ENOTFOUND esxi01.mylab.local esxi01.mylab.local:443

Pour comprendre ce problème, jettons un coup d’oeil au fichier /etc/nsswitch.conf. Si je m’intéresser à ce fichier, ce n’est pas par hasard puisque les services comme dig, host, nslookup, etc. y font référence pour résoudre les noms de domaines via la commande getaddrinfo.

Si je reprends l’explication de Wikipedia concernant le fichier NSS (Name Service Switch), ce fichier « autorise le remplacement des traditionnels fichiers Unix de configuration (par exemple /etc/passwd, /etc/group, /etc/hosts) par une ou plusieurs bases de données centralisées ».

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname

La partie qui nous intéresse dans ce fichier est la partie au niveau de la ligne hosts. La recherche d’information via les commandes comme ping, nslookup, etc., se fait en lisant la ligne de gauche à droite.

  1. files traduit les noms d’hôtes statics via le fichier /etc/hosts
  2. mdns4_minimal traduit les noms de domaines en passant par le multicast DNS (mDNS)
  3. [NOTFOUND=return] signifie que, si la requête juste avant cette commande (ici, une requête mDNS) renvoie une réponde de type notfound, alors le système n’essaie pas d’autre méthode pour résoudre le nom de domaine
  4. dns, comme vous pouvez vous en doutez, traduit les noms de domaine à la façon traditionnelle

Le problème que j’ai rencontré plus haut s’explique par le fait que la recherche du nom de domaine est enclenchée par mDNS, puisque c’est la première requête DNS rencontrée au niveau de la ligne host. Puis la recherche s’arrête net et sans passer par notre serveur DNS puique, si l’on regarde le fqdn qui est esxi-01.mylab.local, mDNS recherche dans sa base de donnée s’il n’y a pas un nom d’hôte ayant pour nom esxi-01.mylab. Comme il n’y a rien de tel, la recherche s’arrête et ne va pas plus loin que [NOTFOUND=return].

Pour régler ce problème, placer dns avant mdns.

hosts: files dns [NOTFOUND=return] resolve [!UNAVAIL=return] mdns4_minimal myhostname

C’est une méthode parmis tant d’autre, et c’est ce que je recommande vivement de suivre.

Pour plus d’information concernant le multicast DNS, je vous renvoie à ces articles:

https://wiki.archlinux.org/index.php/avahi
https://doc.ubuntu-fr.org/zeroconf
https://fr.wikipedia.org/wiki/Avahi_(logiciel)

Migration de VMs VirtualBox vers Proxmox

Comment migrer des machines virtuelles de VirtualBox vers Proxmox?

Je vais essayer de vous aider à le faire, à travers ce chapitre. Ce n’est pas difficile à faire, une fois qu’on a compris le principe.

I. Préparation des VMs sous virtualbox

« Clonezilla est un logiciel libre de restauration de données, de clonage de disque, et de création d’image de disque. » (wikipedia)

Voici un petit récapitulatif des matériaux et logiciels utilisés pour cette migration.

– Serveur Physique (HP Proliant Gen 8, OS: Proxmox)
– Machine hôte (Macbook Pro 2010, OS: Debian, serveur SSH activé, Virtualbox)
– VMs (OS: Debian) à migrer
– Live CD (clonezilla-live-2.5.0-25-amd64.iso)

1. Connection SSH

Noter l’adresse IP de la machine hôte, puisqu’on va s’en servir pour une connection SSH à partir de la machine virtuelle, ainsi qu’à partir de Proxmox.

20170522-074707

De ce fait, vérifier que le serveur SSH est installé sur votre ordinateur. Si ce n’est pas le cas, faites le.

# apt-get install openssh-server

Puis vérifier que SSH est activé.

# service ssh status
# service ssh start

Ensuite, configurer ssh pour autoriser l’accès à partir de n’importe quel machine de votre réseau.

$ sudo vim /etc/ssh/sshd_config
PasswordAuthentication yes
PermitRootLogin yes

$ sudo service ssh restart

Notez bien que cette étape n’est pas la bonne pratique à utiliser avec SSH. Pour plus d’information sur comment sécuriser votre accès SSH, je vous renvoir à ce chapitre.

2. Préparation des machines virtuelles

Démarrer la machine virtuelle à migrer, puis vérifier que vous pouvez accéder à la machine hôte en SSH.

Si telnet n’est pas installé sur cette VM, les deux méthodes suivantes permettent de vous confirmer si le port 22 (SSH) est ouvert ou non.

$ cat < /dev/tcp/192.168.1.10/22
SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
^C

$ nc -zv 192.168.1.10 22
[192.168.1.10] 22 (ssh) open

Arrêter ensuite la machine virtuelle pour la suite.

3. Clonezilla

Créer un dossier du même nom que l’outil utilisé, Clonezilla par exemple, dans lequel vous allez placer les images créées par cet outil. Ceci vous permettra d’y accéder plus tard en SSH, en tant qu’utilisateur et non en tant que root.

$ mkdir /home//Clonezilla

Télécharger ensuite le live CD de clonezilla que vous pouvez trouver ici, puis démarrer la machine virtuelle à migrer avec.

J’ai omis certaines captures d’écran, dont les options sont restées par défaut, afin de ne garder que l’essentiel.

Une fois arrivé au niveau de la page « Mount Clonezilla Image directory » choisissez SSH pour accéder à la machine hôte, pour y placer l’image créée par Clonezilla.

Choisissez le mode DHCP afin de ne pas vous prendre la tête à configurer la carte réseau de cette VM.

Taper ensuite l’adrese IP de la machine hôte.

Et enfin, entrez le chemin pour accéder au dossier /home//Clonezilla créé précédement.

Taper « yes » pour continuer, puis entrer le mot de passe de l’utilisateur.

La connection SSH étant établi, Clonezilla peut maintenant se lancer dans la création d’une copie de l’image du VM. Le mode Beginner (débutant) est amplement suffisant. Par contre pour clôner le VM, il faut choisir le mode Expert, que nous allons voir plus loin dans ce chapitre. Donc patience!

Pour le nom de l’image, je vous conseille de choisir quelque chose qui peut vous indiquer la nature du VM, et plus particulièrement si vous avez plusieurs VMs à migrer, afin de savoir laquelle fait quoi.

Une fois l’image créée, il n’y a aucune raison d’allumer la machine virtuelle dans Virtualbox.

Au niveau de l’écran suivant, taper sur la touche « Entrée »pour continuer, puis entrer « y ».

Et voilà, la création de l’image du VM est lancée. La procédure peut prendre du temps en fonction de la taille du disque à copier.

Entre temps, vous pouvez vous occuper de la création de la machine virtuelle sous Proxmox.

II. Préparation de la machine sous Proxmox

Dans le disque local de Proxmox, télécharger une copie de du live CD de clonezilla, qu’on va utiliser pour démarrer la nouvelle machine virtuelle.

Concernant cette nouvelle VM, il faut qu’elle ait la même taille auquel il faut ajouter quelques Go d’espace supplémentaire.

Vérifions dans ce cas, les informations de notre VM dans le Virtualbox.

Comme vous pouvez le voir, ma VM fait 20Go. Il va falloir que je créee une machine avec Promox, de 21Go au moins.

1. Préparation de la nouvelle VM

Créer une machine virtuelle en cliquant en haut à droite sur « Create VM ».

Dans l’écran de création du VM, vous avez plusieurs onglets, dont le premier vous demande de renseigner les informations concernant cette nouvelle machine(Nom de la machine, etc.).

Dans l’onglet « General », il n’y a que le nom du VM à remplir. Cette case peut être laissée vide, mais Proxmox va choisir un nom générique pour votre machine.

Dans l’onglet OS, choisissez le système d’exploitation ou la version du noyau pour les machines sous linux.

Dans l’onglet CD/DVD, sélectionner l’image ISO du live CD de Clonezilla.

Dans l’onglet « Hard Disk »,
– Choisissez l’option VirtIO
– Valider la taille du disque de la VM (20Go + 1Go)
– Cocher la case « Discard » si vous utilisez des disques physiques SSD. Si ce n’est pas le cas, donc nul besoin de cette option

Dans l’onglet CPU, l’option par défaut me convient.

Dans l’onglet Memory, j’ai choisi une taille de mémoire moins importante que celle de ma machine virtuelle dans virtualbox.

Dans l’onglet Network, j’ai gardé les informations par défaut.

Pour information, VirtIO est l’équivalent du GuestOS avec la technologie de vmware.

Et voilà, la VM est prête. Si plus tard, vous n’êtes pas satisfait de votre configuration, vous pouvez toujours modifier les informations des VMs (taille de la mémoire, nombres de processeurs, etc.) comme avec Virtualbox.

2. Migration du/des VMs

Lancer la VM dans proxmox.

Pareil que dans la première étape de création de l’image, connectez vous en SSH à la machine hôte, pour récuperer l’image de la VM créée par Clonezilla.

Puis passer en mode expext pour installer cette image vers la nouvelle destination.

Choisissez ensuite l’option « restoredisk » qui, comme son nom l’indique, permet de restaure un disque. Ce n’est pas tout à fait notre cas, mais ceci pour vous dire que c’est la même procédure à suivre pour restaurer un disque à partir d’une sauvegarde, ou pour la migration de VMs.

Ensuite, il vous sera posée la question de quelles VMs vont être restaurer. D’où l’intérêt d’avoir choisi un nom d’image bien spécifique afin de pouvoir choisir le bon parmi la liste des images dans le même dossier.

Vous ne devriez pas avoir à choisir l’emplacement de la cible.

Dans cette partir, laisser les options choisis par défaut.

De même pour la suivante.

Finalement, choisissez de redémarrer la VM une fois la migration terminée, et de vérifier que tout est bon.

Et voilà, la migration commence.

Taper « y » pour continuer.


Une fois le processus de migration terminée, la VM va redémarrer.

Si tout s’est bien déroulé, la VM devrait démarrer sans problème.

Je n’ai eu aucun problème pour migrer les VMs tournant sous Debian, comme vous pouvez le voir ci-dessus. Par contre, j’ai eu droit à un écran noir avec la machine tourant sous Manjaro. Je n’ai pas chercher à comprendre d’où vient le problème, mais je préfère prévenir au cas où.

Sources

SSH – Debian wiki
How to user SSH to connect to a Remote Server in Ubuntu
Sécuriser votre rpi
Test if a port on a remote system is reachable (without telnet)
Proxmox « no backup », « discard », « iothread »
Proxmox options for Hard disk and CPU tab
how to use clonezilla to backup hard drive and create recovery iso image
restore an image of a hard drive using clonezilla

Comment modifier le nom d’hôte d’un serveur sous Proxmox

Suite à mon acquisition d’un micro-serveur (HP Proliant Gen 8) sur lequel a été pré-installé le serveur Proxmox, je vais me lancer dans la partie de modification du nom de Node, c’est à dire le nom de l’hôte du serveur Debian, qui est la base du système Proxmox.

Les commandes que je vais suivre n’ont rien d’exceptonnelles à part l’application directe des informations fournies par le site officiel ainsi qu’une petite partie de troubleshoot.

1. Assurez vous d’avoir éteint toutes les machines virtuelles. Faites de même pour les différents containers si vous en avez installés.

20170514-220419

2. Editez les fichiers /etc/hostname et /etc/hosts ainsi que /etc/postfix/main.cf, pour y remplacer le nom de l’ancien hôte par le nouveau. Vous devriez avoir quelque chose de similaire à ci-dessous.

# vim /etc/host
127.0.0.1 localhost.localdomain localhost
192.168.X.X <nouveauNode> pvelocalhost

# vim /etc/hostname
<nouveauNode>

# vim /etc/postfix/main.cf
myhostname=<nouveauNode>.monServeur.lab

3. Vérifier que dbus est installé sur votre serveur

20170514-215500

Puis lancer la commande

# hostnamectl set-hostname <nouveauNode>

Cette commande ne marche qu’avec systemd.

4. Redémarrer ensuite les différents services proxmox

# service pveproxy restart

# service pvedaemon restart

5. Vous devriez maintenant voir deux Nodes au lieu d’un, l’ancien et le nouveau, dans la liste de menu du Datacenter. Ces nodes sont déconnectés, mais il n’y a pas de quoi s’inquiéter, on va les reconnecter plus tard.

20170514-223724

 

6. Déplacer ensuite les machines virtuelles ainsi que les différents containers s’il y en a, vers le dossier du nouveau Node

# mv /etc/pve/nodes/<ancienNode>/qemu-server/<VM>.conf /etc/pve/nodes/<nouveauNode>/qemu-server/

Dans le cas où vous ne pouvez pas accéder au contenu de /etc/pve, et que vous avez un message d’erreur de type « proxmox pvce transport endpoint is not connected »,

20170514-223813

 

Démonter /etc/pve puis redémarrer le service pve-cluster

# umount -l /etc/pve
# service pve-cluster restart

7. Supprimer ensuite la référence à l’ancien node

# rm -rf /etc/pve/nodes/<ancienNode>
# service pveproxy restart

8. Si malgré celà, vous avez toujours une croix rouge au niveau du nom de votre node, il ne vous reste plus qu’à redémarrer complètement le serveur

9. Après redémarrage, n’oublier pas de relier vos disques au nouveau node

20170514-234246

Noter qu’il est préférable de ne pas mettre de majuscules dans les noms d’hôtes de serveurs sous Linux.

Sources:

Proxmox node name change
HowToChangeHostname
How to set the hostname for a Debian Jessie system?

SDB:Why should username, hostname and domainname be written