|
|
[[_TOC_]]
|
|
|
|
|
|
# Création de VM
|
|
|
|
|
|
Voir [la page dédiée](Création d'une VM).
|
|
|
|
|
|
# Migration à chaud d'une VM
|
|
|
|
|
|
## Explications
|
|
|
|
|
|
**But :** déplacer une VM d'un hyperviseur à l'autre, sans éteindre la VM
|
|
|
|
|
|
**Avantages :**
|
|
|
|
|
|
- c'est complètement transparent pour la VM, elle reste allumée lors de la migration (pas de coupure)
|
|
|
- on peut migrer la VM vers un pool de stockage différent (par exemple d'un pool HDD vers un pool SSD). Attention, l'intégralité de l'espace disque alloué sera copié dans ce cas, cf. ci-dessous.
|
|
|
|
|
|
**Inconvénients :**
|
|
|
|
|
|
- il faut copier la RAM de la VM, ce qui peut être un peu long selon la quantité de RAM de la VM, son activité, et la vitesse du réseau. Mais vu que la VM reste allumée, ce n'est pas trop gênant.
|
|
|
- **si la VM n'a pas de stockage répliqué** : l'intégralité de l'espace disque alloué doit être copié. Une VM avec 100 GB alloué nécessitera de copier 100 GB sur le réseau, même si la VM n'en utilise que 5 GB. Et copier 100 GB, ça va être très long.
|
|
|
|
|
|
**Si la VM a un stockage répliqué :** Proxmox est intelligent et réutilise la copie de disque existante sur l'hyperviseur de destination. Il va donc uniquement copier ce qui a été modifié depuis la dernière réplication, et ça va aller beaucoup plus vite.
|
|
|
|
|
|
## Manipulation
|
|
|
|
|
|
- Vérifier que la VM est allumée.
|
|
|
- Vérifier qu'il y a bien une réplication en place, et que la dernière réplication est récente. Regarder vers quel hyperviseur la réplication a lieu.
|
|
|
- Si il n'y a pas de réplication en place : mettre en place une règle de réplication, et attendre qu'elle finisse. *Il est possible de sauter cette étape, la copie sera alors faite en même temps que la migration. Ce sera généralement bien plus long.*
|
|
|
- Cliquer sur "Migrate" et choisir l'hyperviseur de destination.
|
|
|
- Suivre la progression
|
|
|
|
|
|
# Migration à froid d'une VM
|
|
|
|
|
|
**But :** déplacer une VM éteinte d'un hyperviseur à l'autre
|
|
|
|
|
|
**Avantage :**
|
|
|
|
|
|
- il n'y a pas besoin de copier l'intégralité de la RAM
|
|
|
- seuls les blocs disques vraiment utilisées sont copiés (si une VM utilise 5 GB sur 100 GB alloués, seuls 5 GB seront copiés)
|
|
|
|
|
|
**Inconvénient :**
|
|
|
|
|
|
- la VM subit une coupure le temps de la migration
|
|
|
- la copie ne peut se faire que vers un pool ZFS du même nom (HDD vers HDD, ou bien SSD vers SSD)
|
|
|
|
|
|
Dans l'ensemble, c'est moins intéressant que réplication + migration à chaud. Ça peut être utile pour des VMs qu'il n'est pas possible d'allumer pour la migration.
|
|
|
|
|
|
# Maintenance sur un serveur
|
|
|
|
|
|
Pour bricoler sur un serveur, commencer par migrer toutes les VMs vers un autre hyperviseur.
|
|
|
|
|
|
# Mise à jour Proxmox
|
|
|
|
|
|
Pour les mises à jour courante, c'est comme sous Debian, à coup de `apt-get`.
|
|
|
|
|
|
Pour les mises à jour majeure, c'est plus complexe et il faut suivre les instructions de la doc Proxmox. |
|
|
\ No newline at end of file |