Au lancement d’une VM Ubuntu sous Hyper‑V, le message « 0x800705b4 – Time‑out de l’opération » apparaît et la machine ne démarre pas ? Suivez ce guide pas‑à‑pas pour trouver la cause, corriger rapidement et stabiliser définitivement votre environnement.
Sommaire
Vue d’ensemble de la question
Un utilisateur tente de lancer une VM Ubuntu sous Hyper‑V et obtient systématiquement le code d’erreur 0x800705b4 (« Time‑out de l’opération »). Après plusieurs essais infructueux, il cherche une solution. Ce guide propose un chemin de diagnostic clair, des actions concrètes (interface graphique et PowerShell) et des bonnes pratiques pour éviter les récidives.
Comprendre l’erreur 0x800705b4
Le code 0x800705b4 correspond à l’erreur Win32 1460, qui signale qu’une opération n’a pas abouti avant l’expiration du délai. Dans Hyper‑V, ce message apparaît typiquement lorsque :
- le firmware UEFI/BIOS de la VM est mal configuré (génération ou Secure Boot incompatible) ;
- la VM demande des ressources (RAM/CPU/IO) que l’hôte ne peut pas réserver à temps ;
- un composant Hyper‑V (service, pilotes, fichiers système) est obsolète ou corrompu ;
- la configuration de la VM est défectueuse, ou le disque virtuel (VHDX) pose problème ;
- des paramètres de virtualisation matérielle (VT‑x/AMD‑V, IOMMU) sont désactivés dans l’UEFI du PC hôte.
Objectif : réduire l’incertitude, tester les hypothèses dans le bon ordre, et rétablir un démarrage fiable.
Résumé des solutions (diagnostic en un coup d’œil)
| Axe de diagnostic | Actions recommandées | Pourquoi ? |
|---|---|---|
| Configuration de la VM | – Vérifier/Réduire la mémoire vive attribuée (désactiver la mémoire dynamique si nécessaire). – S’assurer que la génération de la VM (Gen 1 / Gen 2) est compatible avec l’image Ubuntu et, sur Gen 2, désactiver Secure Boot ou choisir le gabarit « Microsoft UEFI Certificate Authority ». | Un paramétrage excessif ou incompatible empêche le chargeur de démarrer avant que le délai de watchdog expire. |
| Ressources de l’hôte | – Fermer d’autres VMs ou processus lourds. – Vérifier dans le Gestionnaire des tâches que la RAM et le CPU laissent une marge suffisante pour Hyper‑V. | Si Hyper‑V ne parvient pas à réserver les ressources demandées à temps, il lève l’erreur 0x800705b4. |
| Mise à jour et intégrité de Windows | – Installer les dernières mises à jour Windows (y compris les correctifs Hyper‑V). – Exécuter SFC /scannow puis DISM /Online /Cleanup-Image /RestoreHealth pour corriger d’éventuels fichiers système endommagés. | Des composants Hyper‑V obsolètes ou corrompus provoquent des échecs au démarrage de VM. |
| Recréation de la VM | – Créer une nouvelle VM propre et y rattacher le disque VHDX existant. – Tester le démarrage sans VHDX pour isoler un problème éventuel de disque. | Permet de distinguer un problème de configuration Hyper‑V d’une corruption du disque virtuel. |
| Vérifications supplémentaires | – Activer la virtualisation matérielle (Intel VT‑x/AMD‑V) et l’IOMMU (VT‑d/AMD‑Vi) dans l’UEFI. – Regarder l’Observateur d’événements → Applications et services\ Hyper‑V‑Worker pour une trace précise. – Mettre à jour les « Linux Integration Services » si la distribution n’est pas récente. | Ces éléments influent sur la stabilité et la compatibilité de la VM. |
Plan d’action rapide
- Arrêter la VM si elle est en état « Démarrage en cours ». Attendez l’arrêt complet du service concerné.
- Réduire la mémoire initiale à 2 Go (désactiver la mémoire dynamique) et allouer 1 ou 2 vCPU maximum.
- Si la VM est en Gen 2 : dans le firmware, désactiver Secure Boot ou sélectionner « Microsoft UEFI Certificate Authority ».
- Vérifier le support de démarrage : ordre de boot et contrôleur (SCSI pour Gen 2, IDE pour Gen 1).
- Alléger l’hôte : fermer les applications lourdes et suspendre d’autres VMs, puis relancer la VM Ubuntu.
- Redémarrer les services Hyper‑V :
Restart-Service vmms(en PowerShell administrateur). - Mettre à jour Windows puis exécuter
SFCetDISM. - Créer une nouvelle VM « propre » et attacher le VHDX existant pour tester.
- Consulter les journaux Hyper‑V pour cibler la cause exacte.
- Valider la virtualisation au niveau UEFI (VT‑x/SVM et VT‑d/AMD‑Vi) si tout le reste échoue.
Étapes détaillées – interface graphique et PowerShell
Configuration de la VM
Mémoire et CPU. Pendant le diagnostic, privilégiez la simplicité : désactivez la mémoire dynamique, fixez 2 Go de RAM au démarrage et limitez le nombre de vCPU à 2. Une configuration trop ambitieuse allonge la phase d’initialisation et déclenche le time‑out.
# Afficher l'état mémoire et la génération
Get-VM -Name "Ubuntu" | Select-Object Name, State, Generation
# Désactiver la mémoire dynamique et fixer 2 Go
Set-VMMemory -VMName "Ubuntu" -DynamicMemoryEnabled \$false -StartupBytes 2GB Génération et Secure Boot. Ubuntu démarre très bien en Gen 2, mais uniquement si Secure Boot est compatible. Deux options : désactiver Secure Boot ou utiliser le gabarit « Microsoft UEFI Certificate Authority ».
# Désactiver Secure Boot (recommandé pour tester)
Set-VMFirmware -VMName "Ubuntu" -EnableSecureBoot Off
# Alternative : garder Secure Boot mais avec le bon gabarit
Set-VMFirmware -VMName "Ubuntu" -EnableSecureBoot On \`
-SecureBootTemplate "MicrosoftUEFICertificateAuthority" Ordre de démarrage et contrôleur. En Gen 2, le disque système doit être sur le contrôleur SCSI et configuré comme premier périphérique de boot.
# Forcer le disque dur comme premier périphérique de démarrage
$disk = Get-VMHardDiskDrive -VMName "Ubuntu"
Set-VMFirmware -VMName "Ubuntu" -FirstBootDevice $disk
Cartes réseau et périphériques. Déconnectez temporairement la carte réseau pour écarter un blocage lié au switch virtuel ou au PXE. Évitez d’ajouter des périphériques superflus pendant le diagnostic.
Ressources de l’hôte
Un time‑out survient souvent lorsque l’hôte est saturé (RAM, CPU, I/O disque). Avant de relancer la VM :
- fermez les navigateurs, IDEs, compilations, jeux ou autres VMs ;
- vérifiez la pression mémoire et CPU dans le Gestionnaire des tâches ;
- assurez-vous que le stockage où réside le VHDX n’est pas saturé (disque externe lent, chiffrement, antivirus).
# Vue rapide de l'hôte et des VMs
Get-VMHost | Select-Object ComputerName, LogicalProcessorCount, MemoryCapacity
Get-VM | Select-Object Name, State, CPUUsage, MemoryAssigned
Mise à jour et intégrité de Windows
Les composants Hyper‑V s’appuient sur des services et fichiers système sensibles. Réparez l’image et redémarrez les services :
# PowerShell en administrateur
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
# Redémarrer le service de gestion des VMs Hyper-V
Restart-Service vmms -Force
# Vérifier vmms et vmcompute
Get-Service vmms, vmcompute | Format-Table -Auto Vérifiez aussi que l’hyperviseur se lance bien au démarrage :
bcdedit /set hypervisorlaunchtype Auto
Recréation de la VM pour isoler la configuration
Si le doute persiste, recréez la VM avec des paramètres sains et rattachez le VHDX existant :
# Exemple : création d'une nouvelle VM Gen2 minimale sans VHD
New-VM -Name "UbuntuFix" -Generation 2 -NoVHD -MemoryStartupBytes 2GB
# Rattacher le disque existant en SCSI
Add-VMHardDiskDrive -VMName "UbuntuFix" -ControllerType SCSI \`
-Path "D:\VMs\Ubuntu\Ubuntu.vhdx"
# Démarrer en verbosité pour observer les étapes
Start-VM -Name "UbuntuFix" -Verbose Astuce : démarrez temporairement la VM sans son VHDX (ou avec un ISO d’installation Ubuntu connu) pour distinguer un problème « configuration Hyper‑V » d’un souci « contenu du disque ».
Vérifications supplémentaires
- Virtualisation matérielle : dans l’UEFI du PC hôte, activez Intel VT‑x/SVM et VT‑d/AMD‑Vi. Sans cela, Hyper‑V est instable.
- Journaux Hyper‑V : ciblez les logs « Microsoft‑Windows‑Hyper‑V‑Worker / Admin » et « Hyper‑V‑VMMS / Admin ». Repérez les messages juste avant le time‑out.
# Récupérer les derniers événements utiles
Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-Worker/Admin" -MaxEvents 50 |
Select-Object TimeCreated, Id, LevelDisplayName, Message
- Linux Integration Services (LIS) : les noyaux Ubuntu récents intègrent les drivers Hyper‑V. Pour des distros anciennes, mettez à jour le kernel et les outils d’intégration si nécessaire.
- Switch virtuel : si une VM reste bloquée au lancement avec PXE/DHCP, testez un autre vSwitch (Interne/Privé) pour écarter un problème réseau.
# Créer un switch interne de test et y connecter la VM
New-VMSwitch -Name "TempSwitch" -SwitchType Internal
Connect-VMNetworkAdapter -VMName "Ubuntu" -SwitchName "TempSwitch"
Bons réglages Hyper‑V pour Ubuntu (référence)
| Paramètre | Valeur conseillée | Symptômes d’un mauvais réglage |
|---|---|---|
| Génération | Gen 2 (UEFI) | Écran noir, « No bootable device », GRUB absent |
| Secure Boot | Désactivé ou « Microsoft UEFI Certificate Authority » | Time‑out, boot bloqué avant GRUB |
| Mémoire | 2 Go minimum au démarrage, dynamique désactivée pendant le debug | Lenteurs extrêmes, expiration du délai |
| CPU | 1–2 vCPU pour tester | Saturation hôte, démarrage instable |
| Disque système | SCSI (Gen 2), IDE (Gen 1) ; VHDX sur SSD si possible | Erreur de boot, I/O très lentes |
| Ordre de boot | Disque dur en premier | Essais PXE intempestifs, délais supplémentaires |
Cas particuliers côté Ubuntu
- GRUB/Initramfs n’apparaît pas : assurez-vous que Secure Boot est compatible (gabarit Microsoft UEFI CA) ou désactivé. En Gen 1, préférez un contrôleur IDE et vérifiez que l’ISO d’installation est intègre.
- Démarrage très lent puis time‑out : réduisez la mémoire initiale, débranchez la carte réseau, et testez sur un vSwitch interne. Les négociations réseau ou le ballooning mémoire peuvent retarder l’initialisation.
- Blocage après une mise à jour kernel : attachez un ISO Ubuntu et passez par le mode « Rescue » pour régénérer GRUB, ou amorcez un noyau antérieur via le menu avancé.
Exemples de commandes utiles (pense‑bête)
| Objectif | Commande | Interprétation |
|---|---|---|
| Redémarrer les services Hyper‑V | Restart-Service vmms -Force | Réinitialise le gestionnaire de VMs, libère les verrous temporaires |
| Vérifier Secure Boot | Get-VMFirmware -VMName "Ubuntu" | Contrôler EnableSecureBoot et le gabarit choisi |
| Basculer le boot sur le disque | Set-VMFirmware -VMName "Ubuntu" -FirstBootDevice (Get-VMHardDiskDrive -VMName "Ubuntu") | Évite le PXE et réduit les délais |
| Désactiver mémoire dynamique | Set-VMMemory -VMName "Ubuntu" -DynamicMemoryEnabled $false -StartupBytes 2GB | Stabilise la phase d’initialisation |
| Contrôler l’état des VMs | Get-VM | Select Name, State, CPUUsage, MemoryAssigned | Repère rapidement les VMs consommatrices |
| Vérifier l’image Windows | SFC /scannow puis DISM /Online /Cleanup-Image /RestoreHealth | Répare les composants requis par Hyper‑V |
Procédure guidée (pas à pas)
- Sauvegarder le VHDX. Copiez le fichier du disque système de la VM pour éviter toute perte de données.
- Débrancher le réseau. Dans les paramètres de la VM, mettez la carte réseau sur « Non connecté » et réessayez.
- Revenir à des réglages sobres : 2 Go, 1–2 vCPU, pas de périphériques additionnels, Gen 2 + Secure Boot désactivé.
- Relancer la VM. Si elle démarre, réactivez progressivement (carte réseau, mémoire dynamique) pour identifier le facteur déclenchant.
- Si échec : redémarrez le service
vmmset contrôlez les journaux Hyper‑V‑Worker/VMMS. - Créer une nouvelle VM en Gen 2 minimale, rattacher le VHDX existant et définir le disque comme premier boot.
- Si la nouvelle VM échoue aussi : testez avec un ISO Ubuntu sain. Si l’ISO démarre, le VHDX est en cause ; sinon, revoyez la configuration de la VM/hôte.
- Mettre à jour l’hôte (Windows Update), puis SFC/DISM. Redémarrez l’ordinateur hôte.
- Valider l’UEFI hôte : activer VT‑x/SVM et VT‑d/AMD‑Vi. Désactiver temporairement toute option exotique limitant la virtualisation.
- Stabiliser : une fois la VM opérationnelle, créez un checkpoint. Notez les paramètres qui ont débloqué la situation.
Prévention et bonnes pratiques
- Checkpoints réguliers avant les mises à jour majeures d’Ubuntu et avant toute modification de la configuration Hyper‑V.
- Ressources réalistes : évitez d’allouer toute la RAM disponible à une seule VM. Prévoyez une marge de 20–30 % pour l’hôte.
- Stockage : placez les VHDX sur SSD NVMe quand c’est possible ; les I/O lentes accentuent les risques de time‑out.
- Standardiser les modèles de VM (Gen 2 + gabarit « Microsoft UEFI CA », 2 Go initiaux, SCSI) pour gagner du temps lors de nouvelles créations.
- Surveiller l’hôte : un outil de monitoring basique (PerfMon, Resource Monitor) signale vite les goulots CPU/RAM/Disque.
Information complémentaire utile
- Le code 0x800705b4 est l’alias hexadécimal de l’erreur Win32 1460, signalant qu’une opération n’a pas abouti avant l’expiration du délai imposé par Hyper‑V.
- En pratique, la majorité des cas se résolvent soit en réduisant la mémoire initiale de la VM (par exemple 2 Go au lieu de 4 Go) soit en réinstallant la VM avec Secure Boot désactivé (ou réglé sur « Microsoft UEFI Certificate Authority »).
- Après réparation, il est conseillé de créer un point de contrôle (checkpoint) pour revenir rapidement à un état fonctionnel en cas de nouveau problème.
Résumé exécutable (en bref)
- Désactivez la mémoire dynamique et ramenez la VM à 2 Go / 2 vCPU.
- En Gen 2, coupez Secure Boot ou basculez sur le gabarit « Microsoft UEFI CA ».
- Forcez le disque système comme premier boot (contrôleur SCSI).
- Allégez l’hôte et relancez
vmms. - Réparez Windows (SFC + DISM) puis, si besoin, recréez la VM et rattachez le VHDX.
- Consultez Hyper‑V‑Worker/VMMS pour l’événement qui précède le time‑out.