Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
technique:infrastructure:vm [2021/11/22 23:42] – qduchemi | technique:infrastructure:vm [2024/09/05 16:53] (Version actuelle) – [MISC] qduchemi |
---|
| {{indexmenu_n>20}} |
| # Créer une machine virtuelle Picasoft |
| |
| <bootnote critical>Toute l'opération se fait depuis l'interface d'administration de [[technique:infrastructure:install_proxmox|Proxmox]], sur `<machine>.picasoft.net:8006`, *e.g.* `caribou.picasoft.net:8006`. Il faut se connecter avec l'utilisateur `root` de la machine. Les identifiants sont dans le [[asso:tuto:vaultwarden|vaultwarden]].</bootnote> |
| |
| ## Création de la machine |
| |
| La première étape de s'assurer qu'on possède l'ISO du système d'exploitation que l'on souhaite installer. Le fichier ISO, s'il n'existe pas, est à déposer dans le dossier `/var/lib/vz/template/iso/` de l'hôte. |
| |
| <bootnote>Pour la dernière version de Debian, on pourra par exemple récupérer l'[URL de la dernière version stable](https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/), et la récupérer avec un `wget` dans ce dossier. Pour Alpine, on utilisera [Alpine Linux - Extended](https://alpinelinux.org/downloads/), la seule qui supporte une installation sans accès au réseau.</bootnote> |
| |
| <bootnote> |
| Sur Proxmox 7, on peut se rendre dans le stockage `local`, rubrique `ISO Images`, et cliquer sur `Download from URL`. |
| |
| {{ :technique:infrastructure:download_from_url_proxmox.jpg |}} |
| </bootnote> |
| |
| On commence d'abord par lancer l'utilitaire de création d'une machine virtuelle : |
| |
| {{ :technique:capture_d_ecran_de_2016-12-02_18-34-17.png?900 |}} |
| |
| ### Choix du nom |
| |
| {{ :technique:capture_d_ecran_de_2016-12-02_18-34-47.png?direct |}} |
| |
| ### Choix de l'OS |
| |
| On choisit l'image pré-téléchargée ainsi que la bonne version du noyau : |
| |
| {{ :technique:infrastructure:machines_virtuelles:install_vm_os.png?direct |}} |
| |
| ### Choix du contrôleur SCSI |
| |
| On choisit ensuite le contrôleur SCSI. Celui-ci doit impérativement être **VirtIO SCSI**. [SCSI](https://fr.wikipedia.org/wiki/Small_Computer_System_Interface), dans une machine physique, est un type de bus permettant de relier des périphériques à un ordinateur. Chaque type de bus a ses fonctionnalités et son protocole de communication. Ici, il s'agit d'un bus virtuel entre la machine hôte et la machine virtuelle. VirtIO SCSI a plusieurs avantages en matière de performance et de flexibilité. |
| |
| {{ :technique:infrastructure:machines_virtuelles:install_vm_system.png?direct |}} |
| |
| ### Choix du disque virtuel |
| |
| On choisit ensuite la taille du disque dur nécessaire. Le type de disque doit être **SCSI**, qui a l'avantage de supporter le [[technique:old:alice_bob:hotplug_vm|hotplug]], c'est-à-dire l'ajout de disques virtuels à chaud. Le format de l'image devra être QCOW2, qui a l'avantage de [[technique:old:proxmox_raw_to_qcow2|n'occuper que la place réellement occupée par les données]]. |
| |
| On choisira le type de stockage en fonction des besoins de la machine virtuelle (SSD ou HDD). En cas de doute, demander à l'équipe ! ^_^ |
| |
| {{ :technique:infrastructure:machines_virtuelles:install_vm_disk.png?direct |}} |
| |
| ### Choix du CPU |
| |
| On choisit le nombre de cœurs alloué à la machine virtuelle, en fonction des besoins. Une configuration 1 processeur à 2 cœurs est équivalente à mettre 2 processeurs à 1 cœur. Pour information, la plupart de nos machines virtuelles utilisent 2 processus à 2 cœurs. |
| |
| {{ :technique:infrastructure:machines_virtuelles:install_vm_cpu.png?direct |}} |
| |
| <bootnote warning>Contrairement à la capture d'écran, on choisit `host` pour le CPU. On utilise ainsi directement le processeur plutôt que de le virtualiser, on tire des meilleures performances. Voir [ce sujet](https://serverfault.com/questions/876664/kvm-which-cpu-for-vm-host-vs-kvm64-to-use-for-web-load) pour des explications. |
| |
| Pour que les performances soient bonnes, il est **indispensable** de ne pas allouer plus de processeurs ou de cœurs qu'il n'existe en vrai. Dans le cas d'Alice ou Bob, on a un processeur à 4 cœurs, on allouera donc 1 socket et 4 cœurs. |
| </bootnote> |
| |
| ### Choix de la RAM |
| |
| On choisit ensuite la mémoire vive allouée en fonction des besoins. Nos machines virtuelles ont en général entre 4 et 32Go de RAM. |
| |
| {{ :technique:infrastructure:machines_virtuelles:install_vm_ram.png?direct |}} |
| |
| <bootnote web>Voir [ici](https://forum.proxmox.com/threads/why-set-minimum-ram-when-you-have-ballooning-ksm-enabled.79932/) pour une explication sur RAM minimum/maximum/ballooning. En gros l'idée est que si la RAM de l'hôte est utilisée à plus de 80%, il va « voler » de la RAM **non-utilisée** (enfin, utilisée pour le cache) aux VM qui auront activé le ballooning. En pratique, comme sur Caribou, par exemple, la RAM disponible est souvent à moins de 20%, il faut s'attendre à ce que les VM bénéficient effectivement de la valeur minimale ; penser cette valeur comme étant « la valeur bien dimensionnée » et le max comme étant « la valeur de secours ».</bootnote> |
| |
| ### Configuration du réseau |
| |
| Choisir `vmbr0`, l'interface « bridge » de la machine. C'est l'équivalent d'un switch virtuel sur lequel sont connectées toutes les machines virtuelles. |
| |
| On choisira le modèle `VirtIO`, qui évite d'émuler une carte réseau (c'est une carte paravirtualisée, qui "parle presque directement" à l'hôte depuis la machine virtuelle). |
| |
| <bootnote warning>Ne **pas** activer le firewall, que l'on configurera manuellement si on le souhaite, avec `iptables` ou `ufw`, sur la VM.</bootnote> |
| |
| {{ :technique:infrastructure:machines_virtuelles:install_vm_network.png?direct |}} |
| |
| ### Finalisation |
| |
| On confirme les paramètres et on coche le démarrage de la machine virtuelle. |
| |
| Il faut attendre la création de la machine virtuelle. Pour effectuer l'installation, on utilise ensuite la console (présente en haut à droite de l'interface). Exemple : |
| |
| {{ :technique:infrastructure:machines_virtuelles:install_vm_console.png?direct |}} |
| ## Installer l'OS et partitionner |
| |
| Une fois la machine virtuelle créée dans Proxmox, on peut procéder à son installation. On ne détaille pas la procédure d'installation, qui peut dépendre de l'OS. |
| |
| <bootnote warning>Le mot de passe `root` est à renseigner dans le [[asso:tuto:vaultwarden|vaultwarden]].</bootnote> |
| |
| Si possible dans l'installateur, on activera le serveur SSH et on désactivera l'environnement de bureau et le serveur d'impression. |
| |
| Il est préférable de partitionner le disque dur qui a été choisi lors de la création de la machine virtuelle avec LVM, afin de faciliter le rajout de stockage ultérieur et la souplesse du partitionnement. |
| |
| Lors de l'installation, si un outil de partitionnement est intégré, on l'utilisera et on choisira : |
| |
| * Une partition `/dev/sda1`, de type `ext2` et d'environ 200M, avec l'indicateur de boot, montée sur `/boot`, pour contenir les fichiers nécessaires au démarrage. |
| * Une partition `/dev/sda2`, qui occupe le reste de l'espace disponible, de type LVM |
| |
| On utilisera ensuite l'outil de partitionnement LVM de l'installateur Debian (ou équivalent pour d'autres installateurs) pour créer un VG (Volume Group) à partir du PV (Physical Volume) `/dev/sda2`. Sur le VG créé (nom `vg00` par exemple), on créera les Logical Volumes (LV) en fonction des besoins. Pour une machine visant à héberger des services, on aura par exemple : |
| |
| * `root`, `ext4`, monté sur `/`, qui contient le système d'exploitation et ses logiciels |
| * `docker`, `ext4`, monté sur `/var/lib/docker`, qui contient tout ce qui concerne Docker |
| * `swap`, pour le SWAP. |
| |
| La taille de ces LV est en fonction des besoins : on préférera laisser un peu d'espace libre dans le VG au cas où. L'intérêt de ce partitionnement est d'éviter que l'explosion des données Docker paralyse le système, par exemple. |
| |
| <bootnote warning>Si l'installateur n'a pas d'outil de partitionnement intégré, on le fera à la main avec les commandes de la distribution concernée, une fois l'installation terminée, et on créera ensuite les systèmes de fichier. On oubliera pas de renseigner à la main les points de montage des systèmes de fichiers dans `/etc/fstab`.</bootnote> |
| |
| <bootnote>Si on crée une VM pour un besoin spécifique (par exemple une VM destinée à recevoir des backups), on pourra se contenter d'un LV pour `/`, d'un LV pour les backups et d'un LV pour le SWAP.</bootnote> |
| |
| On peut ensuite redémarrer la machine et obtenir un shell via l'interface web Proxmox pour continuer la configuration : |
| |
| {{ :technique:infrastructure:console_proxmox.png |}} |
| |
| ## Configuration réseau |
| |
| <bootnote> |
| Sur Debian 11, tout se fait dans l'installateur graphique! |
| </bootnote> |
| |
| <bootnote warning> |
| Si jamais la configuration réseau semble être écrasée par une configuration IPv6, il est nécessaire de supprimer le paquet `rdnssd` qui fait du DNS discovery pour l'IPv6. Il casse la configuration IPv6 statique, on peut donc le supprimer. |
| ``` |
| apt-get purge rdnssd |
| ``` |
| </bootnote> |
| |
| On modifie le fichier `/etc/resolv.conf` pour ajouter les serveurs DNS de Tetaneutral (ou ceux de [FDN](https://www.fdn.fr/actions/dns/)) : |
| |
| ``` |
| search picasoft.net |
| nameserver 91.224.148.10 |
| nameserver 91.224.149.254 |
| ``` |
| |
| <bootnote learn>Inspiré du [wiki de Debian](https://wiki.debian.org/NetworkConfiguration).</bootnote> |
| On édite le fichier `/etc/network/interfaces` pour configurer l'IP de la machine et l'IP de sa passerelle. Ces adresses dépendent du FAI et sont à voir avec eux (Tetaneutral ou Rhizome actuellement). |
| |
| ``` |
| auto eth0 |
| iface eth0 inet static |
| address <IP> |
| gateway <IP> |
| ``` |
| |
| Si le FAI propose une connectivité IPv6, on ajoutera simplement : |
| |
| ``` |
| iface eth0 inet6 static |
| address <IPv6> |
| gateway <IPv6> |
| ``` |
| |
| Pour rappel, dans cette configuration, `eth0` de la VM est relié à une interface bridge de l'hôte, qui transmet les requêtes à la machine virtuelle. |
| Il suffit de redémarrer l'interface : |
| |
| ```bash |
| ifdown eth0 |
| ifup eth0 |
| ``` |
| |
| et tout devrait fonctionner ! :-D |
| |
| À ce stade, on doit être en mesure de contacter la machine depuis l'extérieur, via un `ping` par exemple. |
| |
| ## Configuration SSH |
| |
| S'assurer que le serveur SSH est installé (sur Debian, c'est le paquet `openssh`). |
| |
| À ce stade, la connexion via l'utilisateur `root` - dont le mot de passe a été configuré à l'installation - est possible. |
| |
| <bootnote critical>C'est **très** dangereux : `root` a tous les droits sur la machine, et l'authentification par mot de passe peut être _bruteforcée_ (essayer de nombreux mots de passe). On ne laisse jamais ce genre de configuration, à part pour le setup.</bootnote> |
| |
| <bootnote question>Et il faut faire quoi du coup ?</bootnote> |
| ## MISC |
| |
| Pour que l'hyperviseur puisse communiquer efficacement avec la machine virtuelle, on va installer un agent dédié avec ces commandes : |
| |
| ```bash |
| sudo apt update |
| sudo apt install qemu-guest-agent |
| sudo systemctl enable --now qemu-guest-agent |
| # On vérifie que tout a bien fonctionné |
| systemctl status qemu-guest-agent |
| ``` |
| |
| Dans les options Proxmox de la VM, activer le « Guest agent », puis arrêter/démarrer la machine. |
| |
| <bootnote web>Plus de documentation ici : https://pve.proxmox.com/wiki/Qemu-guest-agent</bootnote> |
| |
| ## Rendre la machine picasoftienne |
| |
| Direction [[technique:infrastructure:setup_machine|cette page]] pour finir la configuration ! :-) |
| |