Principe de la migration à chaud
Le projet propose une première version fonctionnelle de la migration à chaud des machines virtuelles bhyve sous FreeBSD 15.1. Un invité amd64 peut être déplacé entre deux hôtes via TCP tout en continuant son exécution, la pause ne survient que pendant la phase finale de stop‑and‑copy. Le mécanisme s’appuie sur le support expérimental BHYVE_SNAPSHOT et sur un suivi des pages sales implémenté dans le module vmm. Le protocole de migration, intégré à bhyvectl et à bhyve, transmet d’abord un snapshot initial, puis, à chaque itération, un bitmap des pages modifiées depuis le scan précédent.
Implémentation actuelle et performances
Le processus démarre par une phase de pré‑copie : la mémoire de l’invité est envoyée, puis seules les pages marquées comme sales sont retransmises. La boucle s’arrête dès que le nombre de pages sales correspond à l’objectif de temps d’arrêt configuré (entre 138 ms et 171 ms pour un invité de 512 MiB) ou lorsqu’une limite de tours est atteinte. À ce moment, bhyve suspend l’invité et ses périphériques, envoie les dernières pages sales ainsi que l’état du snapshot (vCPU, noyau, périphériques émulés), puis attend le message GO du récepteur avant de valider la migration.
Le protocole gère le nombre de vCPU : le handshake transmet le compte, et le récepteur refuse toute discordance. Les tests publiés ont surtout utilisé un invité à un seul vCPU, ce qui laisse la validation du stress multi‑vCPU à un stade ultérieur. La cohérence mémoire est vérifiée par un workload qui réécrit la mémoire et signale toute page manquante ou obsolète. De même, une charge d’écriture disque intensive (fsync à chaque écriture, vérification de sommes de contrôle) confirme la bonne pause, vidage et restauration des périphériques de stockage.
En cas d’échec avant le commit, le système reprend l’invité source, garantissant qu’aucune perte de service ne survient. Le socket de migration est ouvert par bhyvectl puis passé à bhyve, permettant à ce dernier de rester dans son sandbox Capsicum.
Limites et perspectives d’évolution
Le prototype reste limité à l’architecture amd64 et dépend du support snapshot des périphériques émulés ; la migration de PCI passthrough n’est pas encore prise en charge. Plusieurs points bloquants doivent être résolus avant une intégration officielle. Le suivi des pages sales doit être prouvé exempt de perte d’écriture, notamment sous charge concurrente et avec plusieurs vCPU. Un contrat de compatibilité complet est requis : le récepteur devra vérifier l’identité de l’invité, les capacités CPU, les formats de snapshot, la topologie des périphériques et la cohérence du stockage partagé.
Le transport TCP actuel ne propose ni authentification ni chiffrement, et le protocole natif manque de spécifications de format, de limites de messages, de négociation de version et de mécanismes de récupération après perte d’accusé de réception. La frontière entre le commit et les effets côté périphérique doit être clarifiée pour éviter toute opération visible avant la validation du commit. Enfin, une stratégie de tests intégrée, couvrant différents nombres de vCPU, tailles de mémoire, types de périphériques et scénarios de panne, est indispensable pour obtenir l’aval des mainteneurs.
