AVD hybride sur Proxmox

À la fin de mon article sur Azure Virtual Desktop Hybride, je terminais par une question ouverte : et si quelqu’un testait sur un hyperviseur que je n’avais pas couvert, du Proxmox par exemple ? Personne ne m’a répondu. Alors je l’ai fait moi-même. Le résultat tient en une phrase : ça marche, et exactement de la même façon que sur Hyper-V ou vSphere. La VM Windows 11 montée dans le premier article Proxmox sur Azure, jointe à Entra ID, devient un session host Azure Virtual Desktop à part entière. On se connecte dessus depuis la Windows App, et le bureau qui s’affiche tourne dans Proxmox.

Ce qui rend ce lab amusant, c’est l’empilement : un service AVD dans Azure, qui pilote un session host qui tourne dans Proxmox VE, lui-même hébergé dans une machine virtuelle Azure. Trois couches, et tout le monde s’en accommode.

Si vous débarquez ici sans contexte, lisez peut-être d’abord l’article Azure Virtual Desktop Hybride, qui explique ce qu’est cette préversion, ce qu’elle apporte et ses limites. Celui-ci se concentre sur un seul point : le cas Proxmox, et les deux ou trois choses qui diffèrent quand l’hyperviseur n’est pas dans la liste officielle.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Proxmox est-il supporté ?
2. Le point qui mérite d’être posé clairement : Arc dans une VM imbriquée
3. Étape 0 : l’état de départ et les pré-requis
4. Étape 1 : vérifier l’Entra Join du session host
5. Étape 2 : vérifier la sortie réseau du session host
6. Étape 3 : enregistrer les resource providers
7. Étape 4 : créer le host pool et son identité managée
8. Étape 5 : enrôler la VM Proxmox dans Azure Arc
9. Étape 6 : poser l’extension AVD
10. Étape 7 : assigner les utilisateurs et se connecter
11. Ce qui change vraiment avec Proxmox
12. Les pièges à retenir

1. Proxmox est-il supporté ?

La question mérite une réponse honnête, parce qu’elle a deux niveaux.

Dans son annonce, Microsoft cite nommément Hyper-V, Nutanix AHV, VMware vSphere et les serveurs Windows physiques. Proxmox n’y figure pas. Si vous cherchez une ligne de documentation qui écrit le mot Proxmox, vous ne la trouverez pas, et un support Microsoft pourra légitimement vous le rappeler.

Mais la page d’aperçu de la fonctionnalité est nettement plus large, et c’est elle qui décrit la règle réelle.

You can run Azure Virtual Desktop session hosts on your preferred on-premises hypervisor that supports Windows virtual machines.
Source : Azure Virtual Desktop Hybrid Overview, Microsoft Learn

La même page pose la seule contrainte technique qui compte vraiment.

Session hosts must be Azure Arc-enabled. The Azure Arc extension installs the AVD components and registers the device with a host pool.
Source : Azure Virtual Desktop Hybrid Overview, Microsoft Learn

Autrement dit, l’hyperviseur n’est pas un participant de la mécanique, il est juste le meuble sur lequel la VM est posée. Azure Arc parle à un Windows, pas à un hyperviseur. Tant que ce Windows est éligible, qu’il sort en TCP 443 et que l’agent Connected Machine s’installe, le reste suit. C’est très exactement ce que j’avais constaté entre mes trois cas Hyper-V et vSphere : la procédure est rigoureusement identique.

Attention : supporté et fonctionnel ne sont pas synonymes. Proxmox fonctionne, je l’ai vérifié de bout en bout, mais il n’est pas nommé dans la matrice Microsoft. Pour un lab, une démonstration ou un PoC, aucun problème. Pour un déploiement de production, gardez en tête que vous sortez de la liste explicitement citée, ce qui s’ajoute au fait que la fonctionnalité est déjà en préversion.

2. Le point qui mérite d’être posé clairement : Arc dans une VM imbriquée

Il y a une bizarrerie dans ce lab, et je préfère la traiter tout de suite plutôt que de laisser quelqu’un la relever en commentaire.

Azure Arc sert à gérer des machines qui ne sont pas dans Azure. Or mon nœud Proxmox est, lui, une machine virtuelle Azure. On pourrait croire qu’on essaie d’enrôler une VM Azure dans Arc, ce qui n’a pas de sens et n’est pas pris en charge :

Ce n’est pas ce qui se passe. Ce que j’enrôle, c’est la VM Windows 11 qui tourne dans Proxmox, et cette machine n’a rien d’une ressource Azure : elle n’apparaît dans aucun groupe de ressources, elle n’a pas d’identité managée, elle n’atteint pas le service de métadonnées d’instance, et son adresse est une 10.10.10.x distribuée par le dnsmasq du nœud, derrière le NAT nftables mis en place dans le premier article. Du point de vue d’Azure Arc, c’est une machine anonyme quelque part sur Internet qui sort en 443. Exactement le profil d’un serveur de datacenter.

Mon retour terrain : cette nuance n’est pas un détail de présentation, c’est ce qui fait que le lab est représentatif. Si vous refaites l’exercice sur un Proxmox posé sur une vraie machine dans votre garage ou votre salle serveur, vous obtiendrez le même résultat par le même chemin. Azure n’est ici qu’un moyen commode de disposer d’un hyperviseur.

3. Étape 0 : l’état de départ et les pré-requis

Je repars de la machine construite dans les deux articles précédents, sans rien y changer d’autre que l’identité.

Élément	Ce que j’ai
Hyperviseur	Proxmox VE 9, nœud `proxmox-ve`, dans une VM Azure Standard_D16s_v3
Réseau des invités	Bridge `vmbr0` en 10.10.10.0/24, NAT nftables, DHCP et DNS par dnsmasq
Session host	VM Windows 11 Entreprise mono-session, 2 cœurs, 8 Gio, disque de 64 Gio
Identité	Microsoft Entra Join pur, aucun contrôleur de domaine
Licence utilisateur	Microsoft 365, éligible AVD
Abonnement	Un abonnement Azure actif, rôles Azure Connected Machine Onboarding et Desktop Virtualization Contributor

Les pré-requis côté Azure restent ceux de l’article Azure Virtual Desktop Hybride dans leurs grandes lignes, mais la documentation a évolué depuis que je l’ai écrit, et deux points ont changé. Je les signale au fil des étapes.

Pré-requis	Détail
Resource providers	`Microsoft.HybridCompute`, `Microsoft.HybridConnectivity`, `Microsoft.GuestConfiguration`, `Microsoft.DesktopVirtualization`
RBAC	Azure Connected Machine Onboarding, et Desktop Virtualization Contributor
Identité du session host	Entra Join, jointure AD, ou jointure hybride pour un Windows client
Réseau	Sortie TCP 443 vers les URL requises par AVD et vers les endpoints Azure Arc
Agent Arc	Azure Connected Machine agent installé sur chaque session host
Identité managée	À assigner au host pool, avec le rôle Reader sur le groupe de ressources des machines Arc

Attention : un point d’identité que je n’avais pas détaillé dans mon article de mai et que la documentation précise désormais : un session host Windows Server ne peut pas être en Entra Join pur, à cause de la dépendance au serveur de licences Bureau à distance. Il lui faut une jointure AD ou hybride. C’est seulement sur un Windows client, comme le Windows 11 de ce lab, que l’Entra Join seul est accepté.

Attention : un rappel qui vaut pour tous les hyperviseurs et que je répète ici parce qu’il coûte cher : l’identité doit être fixée avant l’enrôlement Arc. Si vous faites l’Entra Join après avoir posé l’agent, il faut désinstaller l’agent et recommencer. Sur une VM neuve, faites l’Entra Join d’abord, Arc ensuite, extension AVD en dernier.

4. Étape 1 : vérifier l’Entra Join du session host

Ma VM Windows 11 a été jointe au tenant pendant l’OOBE, avec l’option Set up for work or school. Si la vôtre est en compte local, faites-le maintenant par Paramètres, Comptes, Accès Professionnel ou Scolaire, puis Connecter et l’option de jointure à Microsoft Entra.

La vérification se fait en une commande, dans une invite en administrateur.

dsregcmd /status

Dans la section Device State, il faut lire AzureAdJoined : YES et DomainJoined : NO. C’est la signature d’un Entra Join pur :

Vérifiez au passage dans le centre d’administration Entra que l’appareil est bien apparu dans la liste, avec son nom d’hôte :

Mon retour terrain : c’est le scénario que je préférais déjà dans mon article AVD hybride, et Proxmox ne change rien à cette préférence. Pas de contrôleur de domaine à rendre joignable depuis le réseau interne de l’hyperviseur, pas de Kerberos, pas de GPO. Avec un bridge NAT comme le nôtre, où les invités sont derrière une translation d’adresses, c’est même un vrai confort : un DC aurait demandé du routage supplémentaire. Gardez juste en tête que ce raccourci n’est ouvert qu’aux Windows client, un Windows Server exigeant une jointure AD ou hybride.

5. Étape 2 : vérifier la sortie réseau du session host

C’est le seul point où la configuration Proxmox de notre lab demande une attention particulière. Les invités sont derrière le NAT nftables du nœud, et l’agent Arc comme les composants AVD ont besoin de sortir en TCP 443.

Un test simple depuis la VM Windows, en PowerShell.

Test-NetConnection -ComputerName login.microsoftonline.com -Port 443
Test-NetConnection -ComputerName management.azure.com -Port 443

Si ces tests échouent, reprenez la configuration réseau du premier article : le routage IPv4 activé, la règle de masquerade dans la table nat, et la chaîne forward qui accepte les flux de 10.10.10.0/24 vers eth0. Côté nœud, une vérification rapide.

sudo nft list ruleset
sysctl net.ipv4.ip_forward

Attention : l’agent Arc et AVD ont besoin d’un flux sortant uniquement. Vous n’avez rien à ouvrir en entrée sur le NSG Azure, et surtout pas de RDP : la connexion utilisateur passe par le service AVD via une passerelle inversée, pas par une exposition directe du port 3389. C’est l’un des vrais bénéfices de la mécanique, et il tombe particulièrement bien dans notre montage où les invités n’ont de toute façon aucune adresse publique.

6. Étape 3 : enregistrer les resource providers

Rien de spécifique à Proxmox ici, mais c’est le préalable à tout le reste. Sur l’abonnement cible.

'Microsoft.HybridCompute','Microsoft.HybridConnectivity','Microsoft.GuestConfiguration','Microsoft.DesktopVirtualization' |
  ForEach-Object { Register-AzResourceProvider -ProviderNamespace $_ }

N’oubliez pas Microsoft.HybridConnectivity, qui porte la connectivité via Arc. Son absence laisse l’enrôlement réussir tout en faisant échouer silencieusement des opérations plus loin.

7. Étape 4 : créer le host pool et son identité managée

Ici, deux choses ont bougé depuis mon article de mai, et la seconde est un vrai piège si vous travaillez de mémoire.

Le host pool, désormais standard

Au lancement de la préversion, seul un host pool marqué comme environnement de validation acceptait un session host hybride. Ce n’est plus ce que dit la documentation, qui demande simplement de créer un host pool ordinaire sans y ajouter de machines.

Follow the Deploy Azure Virtual Desktop instructions to deploy a standard host pool without adding session hosts. Do not add virtual machines to this host pool.
Source : Deploy Azure Virtual Desktop Hybrid, Microsoft Learn

Dans le portail, cherchez Azure Virtual Desktop, puis Host pools et Create.
Dans Basics, nommez le pool, choisissez la région des métadonnées et le type Pooled ou Personal.
Dans Virtual machines, choisissez No, I’ll add VMs later. La machine arrivera par Arc, pas par l’assistant.
Dans Workspace, créez ou rattachez un workspace, puis validez.
Dans Identity, assignez une identité managée. Ne sautez pas cet onglet, la suite en dépend.

L’identité managée et son rôle Reader

C’est la nouveauté qui coûte le plus cher à ignorer. L’identité managée du host pool doit disposer du rôle Reader sur le groupe de ressources qui contient vos machines Azure Arc. La documentation est explicite sur les conséquences.

If the managed identity doesn’t have Reader access to the Arc resource group, a future release will prevent session hosts from becoming available.
Source : Deploy Azure Virtual Desktop Hybrid, Microsoft Learn

Ouvrez le groupe de ressources qui contient vos serveurs Arc.
Allez dans Access control (IAM), puis Add et Add role assignment.
Cherchez Reader, sélectionnez-le, puis Next.
Dans Assign access to, choisissez Managed identity, puis Select members.
Choisissez votre abonnement, le type Host pool, sélectionnez l’identité de votre host pool, et validez.

Attention : cette exigence n’existait pas au lancement de la préversion et n’apparaît donc pas dans mon article de mai. Si vous rejouez une procédure notée il y a quelques mois, c’est très précisément l’étape qui vous manquera, avec un symptôme différé et peu explicite : un session host qui ne devient jamais disponible.

8. Étape 5 : enrôler la VM Proxmox dans Azure Arc

On y est. Dans le portail, allez dans Azure Arc, Machines, Add, puis Add a single server. Renseignez l’abonnement, le groupe de ressources et la région, et téléchargez le script PowerShell d’onboarding généré :

Ouvrez PowerShell ISE puis lancez la commande suivante :

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force

Collez le script d’Azure ARC dans la VM Windows 11 et exécutez-le. Il télécharge AzureConnectedMachineAgent.msi, l’installe, puis lance azcmagent connect avec les paramètres de votre tenant :

Une fenêtre d’authentification s’ouvre pour valider :

Au bout de deux à cinq minutes, la machine apparaît dans Azure Arc, Machines, avec le statut Connected :

Ouvrez la ressource et regardez ses propriétés. C’est l’écran le plus intéressant de tout l’article :

Mon retour terrain : vérifiez la valeur d’azcmagent plutôt que de vous fier au portail seul. Sur la machine, azcmagent show vous donne l’état de l’agent, le statut de la connexion et les endpoints atteints. C’est le premier endroit où regarder si quelque chose coince, et c’est beaucoup plus parlant qu’un statut dans une liste.

azcmagent show

9. Étape 6 : poser l’extension AVD

C’est l’extension Azure Arc qui installe les composants AVD sur la machine et l’enregistre auprès du host pool. La documentation précise au passage ce qu’elle fait selon le système : sur Windows Server, elle active le rôle Hôte de session Bureau à distance, et sur Windows 11, elle active la connexion en RDP.

Attention : sur un Windows Server, l’activation du rôle entraîne un redémarrage de la machine. La documentation conseille d’installer le rôle avant de déployer l’extension pour éviter un redémarrage au milieu de la configuration. Sur notre Windows 11, la question ne se pose pas.

Bonne nouvelle par rapport à mon article de mai : il existe maintenant un chemin portail, sans génération de clé d’enregistrement à la main.

Option 1 : depuis le portail

Dans le portail, cherchez Azure Arc, dépliez Infrastructure et sélectionnez Machines.
Cliquez sur le nom de votre machine, puis dans le menu de gauche dépliez Settings et choisissez Extensions.
Cliquez sur Add, sélectionnez l’extension Azure Virtual Desktop Hybrid, puis Next.
Choisissez l’abonnement, le groupe de ressources et le host pool auquel rattacher le session host.
Validez par Review + Create puis Create.

Option 2 : en PowerShell

Le chemin script reste parfaitement valable, et c’est celui qu’on garde pour industrialiser. Installez les modules, puis connectez-vous en fixant explicitement l’abonnement :

Install-Module -Name Az.DesktopVirtualization
Install-Module -Name Az.ConnectedMachine

Connect-AzAccount
Set-AzContext -Subscription '<SubscriptionId>'
Get-AzContext

Générez une clé d’enregistrement pour le host pool :

$HostPoolRG   = '<VotreResourceGroupHostPool>'
$HostPoolName = '<VotreHostPool>'

$expiresUtc = (Get-Date).ToUniversalTime().AddHours(24).ToString('yyyy-MM-ddTHH:mm:ss.fffffffZ')
$regInfo    = New-AzWvdRegistrationInfo -ResourceGroupName $HostPoolRG -HostPoolName $HostPoolName -ExpirationTime $expiresUtc
$token      = $regInfo.Token

Puis posez l’extension sur la machine Arc :

$settings          = @{ isCloudDevice = $false }
$protectedSettings = @{ registrationToken = $token }

$ResourceGroupName = '<VotreResourceGroupArc>'
$MachineName       = '<NomDeLaMachineDansArc>'
$Region            = '<RegionDuResourceGroupArc>'

New-AzConnectedMachineExtension `
    -Name 'Microsoft.AzureVirtualDesktop.CloudDeviceExtension' `
    -ResourceGroupName $ResourceGroupName `
    -MachineName $MachineName `
    -Location $Region `
    -Publisher 'Microsoft.AzureVirtualDesktop' `
    -ExtensionType 'CloudDeviceExtension' `
    -Setting $settings `
    -ProtectedSetting $protectedSettings

isCloudDevice = $false est le drapeau qui indique le mode hybride. Sans lui, rien ne fonctionne.
MachineName est le nom de la ressource dans Azure Arc, pas forcément le nom d’hôte Windows brut.
Location est la région du groupe de ressources Arc, pas l’endroit où tourne physiquement la machine.
La clé d’enregistrement a une durée de vie limitée, générez-la juste avant de jouer le script.

Vérifier le résultat

Dans la vue Extensions de la machine Arc, la colonne de statut de Microsoft.AzureVirtualDesktop.CloudDeviceExtension doit afficher Succeeded.

Les différentes applications commencent à faire leur apparition dans le gestionnaire des programmes Windows :

Puis, dans le host pool, la machine apparaît dans la liste Session hosts avec le statut Available :

Mon retour terrain : ne paniquez pas si le session host n’apparaît pas immédiatement après le Succeeded de l’extension. La documentation annonce jusqu’à quinze minutes de délai entre les deux, et c’est exactement le genre d’attente pendant laquelle on relance inutilement un script qui avait très bien fonctionné.

Attention : si vous partez sur le chemin PowerShell et obtenez une erreur du type machine introuvable, vérifiez Get-AzContext. Avec plusieurs abonnements rattachés au compte, l’applet va chercher la ressource Arc au mauvais endroit et le message d’erreur n’aide pas beaucoup. C’est le piège sur lequel j’avais déjà perdu du temps lors de mes premiers tests.

10. Étape 7 : assigner les utilisateurs et se connecter

Dernière ligne droite. Ouvrez l’application group, allez dans Assignments et ajoutez l’utilisateur ou le groupe Entra qui doit pouvoir se connecter :

Puis, côté utilisateur, ouvrez la Windows App et connectez-vous avec ce compte. Le bureau publié par le host pool apparaît :

Cliquez, et le bureau s’ouvre :

Pour le plaisir de la démonstration, ouvrez côté Proxmox la console de la même VM et regardez les deux écrans côte à côte. C’est la capture que je trouve la plus parlante de tout ce lab : le même Windows, vu par son hyperviseur et vu par le service AVD :

11. Ce qui change vraiment avec Proxmox

Après ce test, la réponse honnête est : presque rien du côté d’AVD, et un peu plus du côté de l’exploitation.

Sujet	Sur Hyper-V ou vSphere	Sur Proxmox
Enrôlement Arc	Script d’onboarding standard	Identique, l’agent ignore l’hyperviseur
Extension AVD	Depuis le portail, ou `CloudDeviceExtension` en PowerShell	Identique
Identité	Entra Join ou jointure de domaine	Identique, Entra Join testé ici
Connexion utilisateur	Windows App	Identique
Support Microsoft	Hyperviseurs nommés dans l’annonce	Non nommé, couvert par la formulation générale de l’aperçu
Gestion de l’alimentation	Console de l’hyperviseur	Interface Proxmox ou `qm start` et `qm shutdown`
Arrêt propre du session host	Services d’intégration ou VMware Tools	QEMU guest agent, à installer
Provisionnement en série	Templates et outils partenaires	Modèles Proxmox, `qm clone`, éventuellement Terraform

Les deux dernières lignes sont les seules qui demandent un vrai effort d’adaptation, et elles découlent toutes les deux d’une limite de la préversion : AVD hybride ne pilote ni l’alimentation ni le cycle de vie des machines. Ce n’est pas propre à Proxmox, c’est documenté.

Azure Virtual Desktop Hybrid doesn’t provision or manage virtual machine state, so the following capabilities aren’t supported: Power management, Autoscale, Start VM on Connect, Session Host Configuration.
Source : Azure Virtual Desktop Hybrid Overview, Microsoft Learn

Concrètement, si vous vouliez industrialiser, c’est du côté de Proxmox que se ferait le travail : un modèle de VM Windows préparé et généralisé, un clone par session host, et un script qui enchaîne l’enrôlement Arc et la pose de l’extension. La bonne nouvelle est que l’API de Proxmox se prête bien à l’exercice, la moins bonne est qu’aucun des partenaires cités au lancement de la préversion ne couvre Proxmox aujourd’hui.

Mon retour terrain : n’oubliez pas le QEMU guest agent sur vos session hosts, dont je parle dans le second article sur les pilotes VirtIO. Sans lui, l’ordre d’arrêt envoyé depuis Proxmox n’est pas relayé proprement au Windows, et vous finissez par couper l’alimentation d’une machine qui avait des sessions utilisateurs ouvertes. Sur un hôte AVD, c’est exactement ce qu’on ne veut pas.

12. Les pièges à retenir

Le piège	Le symptôme	La parade
Entra Join après l’enrôlement Arc	Session host qui ne s’enregistre pas correctement	Fixer l’identité avant de poser l’agent Arc, sinon désinstaller et recommencer
`Microsoft.HybridConnectivity` oublié	Enrôlement réussi mais échecs silencieux ensuite	Enregistrer les quatre resource providers avant de commencer
Identité managée sans rôle Reader	Session host qui ne devient jamais disponible	Assigner une identité managée au host pool et lui donner Reader sur le groupe de ressources Arc
Windows Server en Entra Join pur	Non supporté, dépendance au serveur de licences RDS	Jointure AD ou hybride pour un Windows Server, Entra Join réservé au client
Impatience après le Succeeded	On relance un script qui avait marché	Attendre jusqu’à quinze minutes avant de conclure à un échec
`isCloudDevice` absent ou à `$true`	L’extension se pose mais n’enregistre rien	Passer explicitement `isCloudDevice = $false`
Mauvais abonnement dans le contexte	Erreur de machine introuvable	Vérifier `Get-AzContext` après le `Set-AzContext`
Sortie 443 bloquée par le NAT	L’agent Arc n’arrive pas à se connecter	Vérifier la chaîne forward nftables et le routage IPv4 sur le nœud
Windows 11 multi-session	Non éligible hors Azure	Mono-session, ou Windows Server avec le rôle RDS
Pas de guest agent sur le session host	Arrêts brutaux depuis Proxmox	Installer le QEMU guest agent sur chaque session host
Clé d’enregistrement expirée	L’extension échoue à enregistrer la machine	Générer le token juste avant de lancer le script

Conclusion

Voilà, en sept étapes, une machine Windows 11 qui tourne dans Proxmox et qui se comporte comme un session host Azure Virtual Desktop à part entière, avec sa Windows App, son identité Entra et son host pool dans le portail.

Concrètement, ça donne quoi ? Ça confirme ce que je pressentais en écrivant mon article sur AVD hybride : la mécanique ne s’intéresse pas à votre hyperviseur. Azure Arc parle à un Windows, l’extension AVD parle à Azure Arc, et ce qu’il y a en dessous est votre affaire. Microsoft a nommé quatre plateformes dans son annonce, mais la formulation de l’aperçu est délibérément plus large, et le test le vérifie.

Les trois points que je retiens : la procédure est strictement celle des autres hyperviseurs, sans le moindre ajustement ; l’Entra Join pur reste le chemin le plus court, surtout derrière un réseau NAT où un contrôleur de domaine aurait compliqué les choses ; et l’absence de gestion d’alimentation, qui est une limite de la préversion et pas de Proxmox, est ce qui demanderait le plus de travail si on voulait industrialiser.

Foncez tester, et dites-moi en commentaire si vous l’avez fait sur un hyperviseur encore différent. La dernière fois que j’ai posé la question, personne n’avait essayé Proxmox, alors j’ai fini par m’en charger.

🤖

Contenu assisté par IA Cet article a été rédigé avec l’assistance d’une intelligence artificielle et relu par l’auteur. Conformément à l’AI Act (UE) en vigueur depuis le 2 août 2026.

Testez Proxmox grâce à Azure

Proxmox, vous en entendez parler partout depuis quelques mois, vous savez vaguement que c’est un hyperviseur open source qui monte, mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On part d’un abonnement Azure et d’un portail vide, et on va dérouler, capture après capture, jusqu’à un bureau Windows 11 qui tourne dans Proxmox VE, lui-même hébergé dans une machine virtuelle Azure.

Je suis MVP Microsoft depuis 2024, je passe mes journées dans Azure, AVD/Windows 365 ou Copilot, mais regarder ce que fait le reste du monde m’a jamais fait de mal. Azure est d’ailleurs le lab le plus rapide à monter pour ça : pas de serveur à acheter, pas de clé USB à graver, pas de machine à démonter dans le garage. Une VM, une soirée devant vous, et vous supprimez le groupe de ressources à la fin.

Il existe déjà beaucoup de vidéos YouTube qui vous montrent Proxmox :

Ce que je voulais avoir pour tester de mon côté, c’était un premier-à-pas complet sur Azure, avec les vrais pièges du réseau imbriqué et les écrans que vous allez réellement voir. C’est ce que vous trouverez ci-dessous, avec en prime les concepts Proxmox expliqués avec des mots d’admin Azure.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

1. Proxmox VE, c’est quoi au juste ?
2. Pourquoi le tester sur Azure, et ce que ça implique
3. Étape 0 : les pré-requis
4. Étape 1 : créer la machine virtuelle Azure
5. Étape 2 : ouvrir le port 8006 dans le NSG
6. Étape 3 : vérifier la virtualisation imbriquée et préparer Debian
7. Étape 4 : installer Proxmox VE 9
8. Étape 5 : vérifier que les services répondent
9. Étape 6 : préparer le disque de 1 To
10. Étape 7 : le réseau, la partie qui change tout sur Azure
11. Étape 8 : première connexion à l’interface web
12. Étape 9 : déclarer le stockage local-1TB
13. Étape 10 : voir vmbr0 dans l’interface et appliquer la configuration
14. Étape 11 : uploader l’ISO Windows 11
15. Étape 12 : créer la machine virtuelle Windows 11
16. Étape 13 : installer Windows 11 jusqu’au bureau
17. Étape 14 : activer le QEMU guest agent
18. Les pièges à retenir

1. Proxmox VE, c’est quoi au juste ?

Proxmox VE, c’est une distribution Debian sur laquelle l’éditeur autrichien Proxmox Server Solutions a posé trois choses : KVM pour les machines virtuelles complètes, LXC pour les conteneurs système, et une interface web qui pilote le tout sur le port 8006. Pas d’agent à installer sur un poste d’administration, pas de console lourde : un navigateur suffit.

Proxmox

Le vocabulaire est la première marche à franchir, parce qu’il ressemble à celui que vous connaissez sans vouloir dire exactement la même chose.

Le nœud est un serveur qui exécute Proxmox VE. Dans cet article, il s’appelle proxmox-ve et il n’y en a qu’un.
Le datacenter n’est pas un bâtiment, c’est le niveau logique au-dessus des nœuds. C’est là que l’on déclare les stockages, les utilisateurs, les permissions, les sauvegardes et les règles de pare-feu communes.
Le cluster réunit plusieurs nœuds qui partagent leur configuration à travers un système de fichiers répliqué, pmxcfs, monté sur /etc/pve. Sur un nœud isolé comme ici, le service tourne quand même : c’est pour ça que pve-cluster doit être actif même sans cluster.
Le stockage se déclare au niveau du datacenter, avec un type (Directory, LVM, ZFS, NFS, Ceph, et d’autres) et une liste de contenus autorisés (ISO, disques de VM, sauvegardes, modèles de conteneurs).
Le bridge, nommé vmbr0, vmbr1 et ainsi de suite, est un commutateur Linux auquel on raccorde les cartes réseau des invités.

Proxmox VE est un outil open source gratuit, mais qui proposera également différentes formules de souscriptions payantes selon vos souhaits et vos besoins de support :

Enfi, si vous venez du monde Microsoft, la table de correspondance suivante vous évitera de traduire mentalement à chaque écran :

Objet Proxmox	Ce que c’est	L’équivalent que vous connaissez
Datacenter	Le niveau logique qui regroupe nœuds, stockages et utilisateurs	La console de gestion, le périmètre d’administration
Nœud	Un serveur qui exécute Proxmox VE	Un hôte Hyper-V
Cluster	Plusieurs nœuds qui partagent leur configuration	Un cluster de basculement
Stockage	Un emplacement déclaré, avec des types de contenus autorisés	Un volume partagé de cluster, un partage SMB
vmbr0	Un commutateur Linux pour les cartes des invités	Un commutateur virtuel Hyper-V
QEMU / KVM	Une machine virtuelle complète, avec son BIOS ou son UEFI	Une VM Hyper-V de génération 1 ou 2
LXC	Un conteneur système qui partage le noyau de l’hôte	Un conteneur Windows en mode process

Mon retour terrain : ne cherchez pas l’équivalent d’un groupe de ressources ou d’une souscription dans Proxmox : il n’y en a pas. La séparation se fait avec les pools de ressources et les permissions, pas avec une hiérarchie de conteneurs de facturation. Au mieux, il existe différentes vues possibles

2. Pourquoi le tester sur Azure, et ce que ça implique

Pour faire tourner Proxmox, il faut un processeur qui expose ses extensions de virtualisation. Dans une VM Azure, cela s’appelle la virtualisation imbriquée, et toutes les tailles ne la proposent pas. La série que j’ai utilisée ici, la Dsv3, la prend en charge, tout comme le stockage Premium dont on a besoin pour le disque de données.

Virtualisation imbriquée : Soutenu
Source : Série de tailles Dsv3, Microsoft Learn

La même page documente la taille que j’ai prise, Standard_D16s_v3, avec ses 16 processeurs virtuels et ses 64 Gio de mémoire. C’est confortable, et c’est surtout ce qui permet de donner 8 Gio et 2 cœurs à une VM Windows 11 sans que la machine hôte ne s’écroule.

Pour rappel, jusqu’ici, monter un lab Proxmox voulait dire trouver une machine physique. Là, il vous faut un abonnement, une taille de VM correcte, et une heure.

Attention : cette taille n’est pas gratuite. Le portail affichait 700,80 $ par mois sur ma capture, ce qui fait à peu près 1 $ de l’heure. Arrêtez et désallouez la VM dès que vous avez fini de jouer, et supprimez le groupe de ressources quand le lab ne sert plus. La facture d’un lab oublié est le pire souvenir que l’on puisse ramener d’un article de blog.

Trois limites à connaître avant de commencer, pour ne pas les découvrir en cours de route : le réseau des invités ne pourra pas être ponté directement sur la carte Azure, il faudra passer par du NAT, on y revient en détail plus bas ; les performances resteront celles d’un hyperviseur dans un hyperviseur, donc correctes pour un lab et pas pour de la production ; et un cluster Proxmox multi-nœuds sur Azure demanderait un travail supplémentaire, la découverte du cluster reposant sur des mécanismes réseau que le cloud n’aime pas beaucoup.

3. Étape 0 : les pré-requis

Avant de continuer les étapes de cet article, assurez-vous que vous disposez bien d’une souscription Azure active.

4. Étape 1 : créer la machine virtuelle Azure

Rien d’exotique dans cet assistant, mais quatre champs méritent votre attention.

Dans Project details, créez un groupe de ressources dédié. Le mien s’appelle proxmox-rg : tout sera dedans, donc tout partira en une seule suppression.
Dans Instance details, nommez la VM proxmox-ve, choisissez votre région, laissez Security type sur Standard et prenez l’image Debian 13 « Trixie » x64 Gen1.
Dans Size, sélectionnez Standard_D16s_v3. C’est le champ le plus important de tout l’assistant.

Dans Administrator account, j’ai gardé l’authentification par mot de passe avec l’utilisateur. La clé SSH reste évidemment le bon choix si vous comptez garder la machine.
Dans Public inbound ports, choisissez Allow selected ports puis SSH (22). Le portail vous prévient que la règle sera ouverte à tout Internet : on la resserrera à l’étape suivante.

L’onglet Disks est celui qui prépare le stockage des futures VM. Le disque système de 30 Gio suffit largement pour Debian et les paquets Proxmox, mais il ne suffira pas pour les disques des invités.

Laissez le disque OS à Image default (30 GiB) en Premium SSD.
Cliquez sur Create and attach a new disk et créez un disque de 1024 Gio en Premium SSD LRS. C’est lui qui deviendra local-1TB dans Proxmox.

L’onglet Networking se contente des valeurs par défaut : un réseau virtuel neuf, un sous-réseau en 172.16.0.0/24, une adresse IP publique et un groupe de sécurité réseau en mode Basic. Retenez bien le plan d’adressage du sous-réseau, il ne devra surtout pas chevaucher le réseau interne que l’on créera dans Proxmox.

Lancez la création, prenez un café, et récupérez l’adresse IP publique dans la vue d’ensemble de la VM.

5. Étape 2 : ouvrir le port 8006 dans le NSG

L’interface web de Proxmox écoute en HTTPS sur le port 8006. Comme ce port n’existe dans aucun modèle du portail, il faut ajouter la règle à la main dans le groupe de sécurité réseau de la carte.

Ouvrez la VM, puis Networking et Network settings.
Cliquez sur Create port rule puis Inbound port rule.
Source : IP Addresses, et saisissez votre adresse IP publique. Destination : Any. Port de destination : 8006. Protocole : TCP. Action : Allow. Nommez la règle, la mienne s’appelle ProxmoxControlPlane.
Profitez-en pour resserrer la règle SSH sur la même source.

Attention : n’ouvrez jamais 8006 en source Any. Vous exposeriez à Internet une console d’administration d’hyperviseur avec un formulaire de connexion root, et les robots d’analyse de ports mettent quelques minutes à la trouver. Source restreinte, ou Azure Bastion, ou rien.

Gardez l’adresse IP publique sous la main, elle apparaît dans les propriétés de la machine.

6. Étape 3 : vérifier la virtualisation imbriquée et préparer Debian

Connectez-vous en SSH sur l’adresse publique, avec le compte azureuser. Première chose à faire, avant même de penser à installer quoi que ce soit : vérifier que le processeur expose bien ses extensions de virtualisation et que le périphérique KVM existe.

egrep -c '(vmx|svm)' /proc/cpuinfo
ls -l /dev/kvm

La première commande doit renvoyer un nombre supérieur à zéro, 32 dans mon cas, ce qui correspond aux cœurs logiques qui exposent vmx. La seconde doit afficher le périphérique /dev/kvm. Si l’une des deux échoue, inutile d’aller plus loin : votre taille de VM ne prend pas en charge la virtualisation imbriquée, changez-la.

On regarde ensuite dans quoi on met les pieds :

cat /etc/os-release
hostnamectl
ip addr

Trois informations à retenir de cet écran : la distribution est bien une Debian 13 « Trixie », hostnamectl annonce Virtualization: microsoft puisque nous sommes déjà invités d’un hyperviseur, et la carte eth0 porte l’adresse privée 172.16.0.4.

Vient ensuite la manipulation la plus discrète et la plus importante de tout l’article. Par défaut, le fichier /etc/hosts d’une image Azure ne contient pas de ligne associant le nom d’hôte à l’adresse IP privée.

cat /etc/hosts

Il faut ajouter cette ligne, avec votre adresse privée et votre nom d’hôte, avant d’installer Proxmox.

echo '172.16.0.4 proxmox-ve' | sudo tee -a /etc/hosts

Attention : cette étape n’est pas cosmétique. Proxmox VE résout le nom du nœud au démarrage de pve-cluster pour construire l’arborescence de /etc/pve. Si le nom d’hôte ne se résout pas vers l’adresse privée, l’installation se passe mal et l’interface web refuse de s’afficher correctement. Adaptez l’adresse et le nom à votre machine.

7. Étape 4 : installer Proxmox VE 9

On commence par mettre la Debian à niveau. Les images Azure sont propres, mais rarement à jour au jour près.

sudo apt update

sudo apt full-upgrade -y

On ajoute ensuite la clé de signature du dépôt Proxmox pour Debian 13.

sudo wget https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg \
  -O /usr/share/keyrings/proxmox-release-trixie.gpg

Puis le dépôt lui-même. J’utilise ici pve-no-subscription, celui qui ne demande pas de clé d’abonnement.

echo "deb [signed-by=/usr/share/keyrings/proxmox-release-trixie.gpg] http://download.proxmox.com/debian/pve trixie pve-no-subscription" | sudo tee /etc/apt/sources.list.d/pve-install-repo.list

Attention : le dépôt pve-no-subscription n’est pas destiné à la production. Il reçoit les paquets avant le dépôt entreprise et sert justement aux labs et aux tests. Pour une plateforme sérieuse, prenez un abonnement Proxmox et le dépôt qui va avec.

sudo apt update

Place à l’installation !

sudo apt install proxmox-ve

APT annonce la couleur : 603 paquets à installer, 829 Mo à télécharger, 3,6 Go d’espace disque. On valide et on laisse travailler.

En cours de route, deux écrans bleus de configuration de paquet vont vous interrompre. Ils méritent chacun une réponse réfléchie.

Le premier concerne /etc/default/grub, qu’Azure a modifié pour la console série. Choisissez keep the local version currently installed :

Le second demande sur quel périphérique installer GRUB. Cochez /dev/sda, le disque système, et rien d’autre.

Attention : ne cochez surtout pas /dev/sdc dans cet écran. C’est votre disque de données de 1 To, il n’a rien à faire dans la chaîne de démarrage.

La fin de l’installation défile ensuite toute seule, avec la génération de la configuration GRUB et la mise en place des services Proxmox.

8. Étape 5 : vérifier que les services répondent

Avant de toucher au stockage et au réseau, on vérifie que les trois services principaux sont bien démarrés. C’est aussi une bonne occasion de comprendre qui fait quoi.

pveproxy est le serveur d’API et le frontal web, celui qui écoute sur 8006.

systemctl status pveproxy --no-pager

pve-cluster porte le système de fichiers de configuration pmxcfs, monté sur /etc/pve. Même sur un nœud isolé, s’il ne tourne pas, rien ne fonctionne.

systemctl status pve-cluster --no-pager

pvedaemon exécute les tâches demandées par l’API, du démarrage d’une VM à la création d’un disque.

systemctl status pvedaemon --no-pager

Dernière vérification, l’écoute effective du port.

sudo ss -lntp | grep 8006

Mon retour terrain : sur ma machine, pveproxy affichait un ExecStartPost en échec, lié à la mise à jour du catalogue d’abonnement. Le service tournait très bien malgré tout : c’est une conséquence normale du dépôt sans abonnement, pas un problème d’installation.

9. Étape 6 : préparer le disque de 1 To

Le disque de données attaché à l’étape 1 est là, mais il est vierge. Première commande, et surtout ne formatez rien avant de l’avoir lue.

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL

Trois disques apparaissent. sda de 30 Go porte le système, sdb de 128 Go est monté sur /mnt, et sdc de 1 To est notre disque de données, encore sans partition.

Attention : sdb est le disque temporaire d’Azure. Son contenu peut disparaître à chaque désallocation ou opération de maintenance de la plateforme. Il est tentant de l’utiliser parce qu’il est déjà monté et rapide, mais n’y placez jamais un disque de machine virtuelle. Le disque à utiliser est sdc.

On vérifie une dernière fois que sdc ne contient aucune signature de système de fichiers, puis on le partitionne.

sudo wipefs -n /dev/sdc
sudo apt install -y parted
sudo parted /dev/sdc --script mklabel gpt mkpart primary ext4 0% 100%
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS /dev/sdc

Puis on formate la partition en ext4.

sudo mkfs.ext4 /dev/sdc1

Reste à créer le point de montage et à le rendre permanent. Relevez l’UUID affiché par blkid et reportez-le dans /etc/fstab, l’UUID ci-dessous est le mien.

sudo mkdir -p /mnt/pve-data
sudo blkid /dev/sdc1
echo 'UUID=111c8254-c5e6-43f1-811f-497fe6a1513c /mnt/pve-data ext4 defaults 0 2' | sudo tee -a /etc/fstab
sudo mount -a
df -h /mnt/pve-data

Attention : montez toujours par UUID, jamais par /dev/sdc1. L’ordre d’énumération des disques d’une VM Azure n’est pas garanti d’un démarrage à l’autre, et un /etc/fstab qui pointe sur le mauvais périphérique donne une machine qui ne redémarre pas.

10. Étape 7 : le réseau, la partie qui change tout sur Azure

Voilà la section pour laquelle j’ai écrit cet article. Sur un Proxmox physique, la configuration réseau par défaut crée un bridge vmbr0 qui embarque la carte physique du serveur : les VM invitées se retrouvent directement sur le réseau de l’entreprise, avec une adresse du même plan que l’hôte. Sur Azure, cela ne fonctionne pas.

La raison est simple : une carte réseau Azure est associée à une configuration IP et à une adresse MAC connues de la plateforme. Une trame émise par une VM imbriquée, avec sa propre adresse MAC et sa propre adresse IP, n’est pas routée par le réseau virtuel. La documentation Microsoft sur la virtualisation imbriquée décrit d’ailleurs le même symptôme côté Hyper-V, avec le NAT comme réponse.

Network connectivity issues in nested VMs
Source : Troubleshooting guide: Hyper-V nested virtualization, Microsoft Learn

La réponse côté Proxmox tient en trois briques comme on pourrait faire tourner un serveur Hyper-V sur Azure : un bridge isolé sans port physique, du NAT pour la sortie, et un service DHCP et DNS interne pour que les invités reçoivent une configuration sans intervention.

On commence par regarder comment la VM est câblée aujourd’hui.

ip -br addr
cat /etc/network/interfaces
networkctl status eth0
which ifupdown2
sudo cat /etc/netplan/50-cloud-init.yaml

Constat : eth0 est piloté par netplan et systemd-networkd, avec une adresse obtenue en DHCP auprès d’Azure, et /etc/network/interfaces ne contient presque rien. Proxmox, lui, s’appuie sur ifupdown2 pour appliquer les changements réseau depuis l’interface web.

sudo apt install -y ifupdown2
sudo ifquery --list
sudo ifreload -a --dry-run

Attention : on ne touche pas à eth0. C’est votre seule voie d’accès à la machine : si vous la basculez sous ifupdown2 et que la configuration est mauvaise, vous perdez le SSH et il ne reste plus que la console série du portail Azure pour réparer. On laisse netplan gérer eth0 et on se contente d’ajouter vmbr0.

On déclare donc un bridge isolé, en 10.10.10.1/24, sans aucun port attaché. Ce sera la passerelle des VM invitées.

sudo tee /etc/network/interfaces > /dev/null <<'EOF'
# network interface settings; autogenerated

auto lo
iface lo inet loopback

source /etc/network/interfaces.d/*

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
EOF

Le paramètre qui compte ici est bridge-ports none : aucune carte physique n’est rattachée au commutateur. On active ensuite le bridge et le routage IPv4.

cat /etc/network/interfaces
sudo ifup vmbr0
ip -br addr show vmbr0
sudo sysctl -w net.ipv4.ip_forward=1

Pour que le routage survive au redémarrage, on l’écrit dans un fichier sysctl dédié, et on installe nftables.

sudo apt install -y nftables
sudo nft list ruleset
sudo tee /etc/sysctl.d/99-proxmox-nat.conf > /dev/null <<'EOF'
net.ipv4.ip_forward=1
EOF
sudo sysctl --system

Puis le cœur du sujet : la translation d’adresses. La table nat masque le réseau 10.10.10.0/24 derrière l’adresse de eth0, et la table filter n’autorise que ce qui doit l’être, à savoir les flux sortants des invités et les réponses associées.

sudo tee /etc/nftables.conf > /dev/null <<'EOF'
#!/usr/sbin/nft -f

flush ruleset

table ip nat {
    chain postrouting {
        type nat hook postrouting priority srcnat;
        oifname "eth0" ip saddr 10.10.10.0/24 masquerade
    }
}

table inet filter {
    chain forward {
        type filter hook forward priority filter; policy drop;

        iifname "vmbr0" oifname "eth0" ip saddr 10.10.10.0/24 accept
        iifname "eth0" oifname "vmbr0" ct state established,related accept
    }
}
EOF

sudo nft -c -f /etc/nftables.conf
sudo nft -f /etc/nftables.conf
sudo nft list ruleset
sudo systemctl enable --now nftables
sudo systemctl status nftables --no-pager

Dernière brique, le service DHCP et DNS des invités. Sans lui, il faudrait configurer une adresse IP fixe dans chaque VM créée, ce qui est vite pénible.

sudo apt install -y dnsmasq
sudo tee /etc/dnsmasq.d/proxmox-vmbr0.conf > /dev/null <<'EOF'
interface=vmbr0
bind-interfaces
no-resolv
server=168.63.129.16
dhcp-range=10.10.10.100,10.10.10.200,255.255.255.0,12h
dhcp-option=3,10.10.10.1
dhcp-option=6,10.10.10.1
EOF
sudo dnsmasq --test
sudo systemctl restart dnsmasq

Deux détails de cette configuration valent une explication. bind-interfaces limite l’écoute à vmbr0, donc votre DHCP ne partira jamais polluer le sous-réseau Azure. Et l’adresse 168.63.129.16 déclarée comme serveur amont n’est pas une adresse au hasard : c’est l’adresse IP virtuelle de la plateforme Azure, celle qui rend entre autres le service de résolution de noms aux machines virtuelles.

L’adresse IP Azure 168.63.129.16 est une adresse IP publique virtuelle qui facilite les canaux de communication vers les ressources de la plateforme Azure.
Source : Vue d’ensemble de l’adresse IP Azure 168.63.129.16, Microsoft Learn

Attention : choisissez pour vmbr0 un plan d’adressage qui ne chevauche pas celui de votre réseau virtuel Azure. Mon sous-réseau Azure est en 172.16.0.0/24 et mon réseau interne en 10.10.10.0/24 : aucune ambiguïté de routage possible.

11. Étape 8 : première connexion à l’interface web

Le moment de vérité. Ouvrez votre navigateur sur l’adresse publique de la VM, en HTTPS, port 8006.

https://VOTRE-IP-PUBLIQUE:8006

Le certificat est auto-signé, votre navigateur va râler, c’est normal. Connectez-vous avec l’utilisateur root, son mot de passe système, et le realm Linux PAM standard authentication.

Attention : si vous n’avez jamais défini de mot de passe pour root sur cette machine, faites-le en SSH avec sudo passwd root avant d’essayer de vous connecter. Les images Azure livrent un compte root verrouillé.

Vous serez accueilli par la boîte de dialogue la plus célèbre de Proxmox. Elle vous rappelle simplement que vous utilisez le dépôt sans abonnement.

Et voilà l’interface, avec l’arborescence Datacenter puis nœud à gauche, et le résumé du nœud au centre.

Mon retour terrain : regardez la ligne Kernel Version de ce résumé. Sur ma capture, la machine tournait encore sur le noyau cloud de Debian et pas sur le noyau pve, le redémarrage n’ayant pas encore eu lieu. Tout fonctionne quand même pour un lab, mais prévoyez un sudo reboot après l’installation pour démarrer sur le bon noyau.

12. Étape 9 : déclarer le stockage local-1TB

Le disque de 1 To est monté sur /mnt/pve-data, mais Proxmox ne le connaît pas encore. Un stockage se déclare au niveau du datacenter, pas du nœud, même quand il n’est physiquement présent que sur une seule machine.

Allez dans Datacenter, Storage, puis Add et choisissez Directory.

Renseignez l’ID local-1TB, le répertoire /mnt/pve-data, et le contenu Disk image.
Laissez Nodes sur All et cochez Enable, puis validez avec Add.

Vous vous retrouvez avec deux stockages. local, sur le disque système, garde les ISO, les sauvegardes et les modèles de conteneurs. local-1TB accueillera les disques des machines virtuelles.

13. Étape 10 : voir vmbr0 dans l’interface et appliquer la configuration

Le bridge créé en ligne de commande apparaît maintenant dans l’interface, avec un avertissement en bas de page signalant des modifications en attente. Proxmox n’applique pas la configuration réseau à chaud sans votre accord, il vous montre d’abord le différentiel entre /etc/network/interfaces et le fichier .new qu’il a préparé.

Sélectionnez le nœud, puis System et Network.
Relisez le bloc Pending changes en bas de la vue, ligne par ligne.
Cliquez sur Apply Configuration.

Après application, eth0 et le Linux Bridge vmbr0 en 10.10.10.1/24 cohabitent proprement.

Attention : c’est le seul moment de tout l’article où vous risquez de perdre l’accès à la machine. Relisez vraiment le différentiel avant de cliquer, et assurez-vous qu’aucune ligne ne touche à eth0.

14. Étape 11 : uploader l’ISO Windows 11

Pour installer un invité, il faut son image. Proxmox sait télécharger une ISO depuis une URL, mais pour Windows 11 vous passerez par l’upload depuis votre poste.

Dans l’arborescence, sélectionnez le stockage local du nœud, puis ISO Images.
Cliquez sur Upload, choisissez votre fichier, puis Upload à nouveau.

Attention : l’upload transite par /var/tmp sur le nœud, comme la boîte de dialogue le signale. Avec une ISO de 8,13 Gio et un disque système de 30 Gio, ça passe, mais de justesse si vous en montez plusieurs. Surveillez l’espace libre, ou déclarez un second stockage de type Directory autorisant le contenu ISO image sur votre disque de 1 To.

15. Étape 12 : créer la machine virtuelle Windows 11

Cliquez sur Create VM en haut à droite. L’assistant compte huit onglets, et trois d’entre eux conditionnent la réussite de l’installation.

Dans General, donnez un nom à la VM, le mien est vm-w11-test, et notez le VMID proposé, 101 dans mon cas. Ce numéro est l’identifiant que vous retrouverez partout : dans l’arborescence, dans les noms de fichiers de disques, dans les journaux.

Dans OS, sélectionnez l’ISO sur le stockage local, puis le type d’invité Microsoft Windows et la version 11/2022/2025. Proxmox propose de monter un second lecteur contenant les pilotes VirtIO, ce que je n’utiliserai pas pour ce premier article :

Dans System, on entre dans le dur. Windows 11 exige un démarrage UEFI, le démarrage sécurisé et un module de plateforme sécurisée.

Machine : q35, le jeu de puces moderne avec PCI Express.
BIOS : OVMF (UEFI), et cochez Add EFI Disk en le plaçant sur local-1TB.
Cochez Pre-Enroll keys pour que les clés Microsoft soient présentes dès le départ.
Cochez Add TPM, stockage local-1TB, version v2.0.
SCSI Controller : VirtIO SCSI single, la valeur par défaut, que l’on gardera même si notre disque sera en SATA.

Attention : sans OVMF (UEFI) et sans TPM 2.0, le programme d’installation de Windows 11 s’arrête sur le message « This PC can’t run Windows 11 ». Ces deux cases ne sont pas facultatives, et il est bien plus simple de les cocher maintenant que de les ajouter après coup.

Dans Disks, l’assistant propose par défaut un disque scsi0 sur le contrôleur VirtIO SCSI. Le piège classique : sans les pilotes VirtIO, le programme d’installation de Windows ne verra tout simplement aucun disque, et vous resterez bloqué sur un écran de sélection vide.

Je bascule donc le Bus/Device sur SATA, taille 64 Gio, format qcow2, stockage local-1TB :

Les onglets CPU et Memory sont sans surprise. Un socket, deux cœurs, ce qui est le minimum demandé par Windows 11.

Et 8192 Mio de mémoire, largement supportables sur une VM hôte qui en a 64 Gio.

Dans Network, même logique que pour le disque. Le modèle VirtIO (paravirtualized) proposé par défaut est le plus performant, mais Windows n’en a pas le pilote.

Je choisis donc Intel E1000, sur le bridge vmbr0, en laissant le pare-feu coché. Windows embarque ce pilote depuis toujours, la carte sera donc opérationnelle dès le premier démarrage, et elle recevra son adresse de notre dnsmasq :

L’onglet Confirm récapitule le tout. Vérifiez la présence de bios: ovmf, machine: q35, ostype: win11, du disque sata0 et de net0 en e1000, puis validez.

Mon retour terrain : le choix SATA plus E1000 est un compromis de confort. Vous perdez en performances par rapport à VirtIO, ce qui est sans importance pour un lab, et vous gagnez une installation qui se déroule sans jamais chercher un pilote. Sur ma capture de l’onglet OS, le second lecteur censé porter les pilotes pointait d’ailleurs sur ma propre ISO Windows et pas sur une ISO virtio-win : aucun pilote n’était donc réellement disponible. Basculer un invité Windows en VirtIO après coup mérite son propre article, j’y reviendrai.

16. Étape 13 : installer Windows 11 jusqu’au bureau

Sélectionnez la VM 101 dans l’arborescence, ouvrez l’onglet Console et cliquez sur Start Now.

La console noVNC s’affiche dans votre navigateur, et le programme d’installation de Windows 11 démarre.

Déroulez l’installation normalement. L’écran de sélection du disque est celui qui valide tous les choix de l’étape précédente. Le disque de 64 Go apparaît sans avoir eu à charger le moindre pilote. Le pari est gagné :

Lancez l’installation de Windows 11 :

Attendez plusieurs minutes :

La VM redémarre plusieurs fois, puis enchaîne sur l’expérience de première ouverture de session.

La recherche de mises à jour est un excellent test réseau : si cet écran passe, c’est que votre chaîne bridge, NAT et DHCP fonctionne de bout en bout.

Nommez votre machine Windows 11 :

Définissez le type de compte Windows à créer :

Attendez la fin de configuration de Windows 11 :

Attendez encore la fin du téléchargement puis de l’installation des mises à jours OS :

Et au bout du compte, un bureau Windows 11 complet, qui tourne dans Proxmox VE, qui tourne dans une machine virtuelle Azure. La console fonctionne dans un simple onglet de navigateur, sans client RDP.

17. Étape 14 : activer le QEMU guest agent

Votre Windows tourne, mais Proxmox ne sait presque rien de lui. Dans l’onglet Summary de la VM, la ligne des adresses IP reste désespérément vide, et un clic sur Shutdown se contente d’envoyer un signal ACPI en espérant que l’invité l’écoute. Le QEMU guest agent règle ces deux points.

Concrètement, c’est un petit service qui tourne dans l’invité et qui dialogue avec l’hôte par un canal série virtuel dédié. Il ne remplace aucun pilote de disque ni de carte réseau : votre VM continue de démarrer sur son disque SATA et de communiquer par sa carte E1000. C’est justement ce qui le rend sans risque, et c’est pour ça que je le traite ici plutôt que dans un article dédié à VirtIO.

Ce qu’il apporte, une fois en place :

les adresses IP de l’invité remontent dans l’interface, ce qui évite d’ouvrir la console pour savoir quelle adresse dnsmasq a distribuée
l’arrêt et le redémarrage depuis Proxmox deviennent un arrêt propre demandé au système invité
les instantanés et les sauvegardes peuvent geler les écritures le temps de la copie, donc obtenir un état cohérent du système de fichiers
vous pouvez interroger l’invité depuis le shell du nœud, sans passer par le réseau

L’activation se fait en deux moitiés, et il faut les deux.

Côté Proxmox : ajouter le périphérique

Sur la capture de l’onglet System de l’étape 12, la case Qemu Agent était décochée, comme par défaut. On rattrape ça dans les options de la VM.

Sélectionnez la VM, puis Options.
Double-cliquez sur QEMU Guest Agent et cochez Use QEMU Guest Agent.
Validez.

Attention : cocher cette option ajoute un périphérique à la machine virtuelle. Un redémarrage demandé depuis Windows ne suffit pas, il faut un arrêt complet puis un démarrage depuis Proxmox pour que QEMU recrée la VM avec son canal série. C’est la raison numéro un des « j’ai installé l’agent et il ne remonte toujours rien ».

Côté Windows : installer le service

Le programme d’installation de l’agent est livré sur l’ISO virtio-win, la même que celle des pilotes. Uploadez-la dans le stockage local comme vous l’avez fait pour Windows :

Puis montez-la dans la VM avec Hardware, Add, CD/DVD Drive :

Dans Windows, ouvrez le gestionnaire des périphériques afin de mettre à jour le driver suivant :

Choisissez le dossier correspondant à l’OS de votre VM :

Attendez le succès de l’installation :

ouvrez le lecteur et lancez le paquet du dossier guest-agent, en version 64 bits. Il installe uniquement le service QEMU Guest Agent, visible ensuite dans la console des services, et ne touche ni au contrôleur de disque ni à la carte réseau :

Mon retour terrain : c’est le seul morceau de l’ISO virtio-win que j’installe dès le premier jour sur un invité Windows. Le reste, pilotes de disque et de carte réseau, demande une procédure plus prudente et fera l’objet d’un article à part, parce qu’un disque système basculé trop vite en VirtIO SCSI vous accueille au redémarrage avec un écran bleu INACCESSIBLE_BOOT_DEVICE.

Vérifier que ça marche

Retournez sur l’onglet Summary de la VM : les adresses IP de l’invité doivent maintenant s’afficher, avec l’adresse distribuée par votre dnsmasq dans la plage 10.10.10.100 à 10.10.10.200 :

Depuis le shell du nœud, deux commandes confirment le dialogue.

qm agent 101 ping
qm guest cmd 101 network-get-interfaces

La première ne renvoie rien quand tout va bien, ce qui est la définition d’un bon silence :

La seconde vous rend la configuration réseau vue de l’intérieur de Windows, au format JSON :

18. Les pièges à retenir

Le piège	Le symptôme	La parade
Mauvaise taille de VM Azure	`/dev/kvm` absent, Proxmox ne démarre aucune VM	Prendre une taille qui prend en charge la virtualisation imbriquée, Dsv3 par exemple
Port 8006 fermé	L’interface web ne répond pas alors que le service écoute	Ajouter une règle entrante dans le NSG, limitée à votre adresse IP
Nom d’hôte non résolu	Installation bancale, interface web incomplète	Ajouter la ligne adresse privée et nom d’hôte dans `/etc/hosts` avant d’installer
Mauvais disque dans GRUB	Chaîne de démarrage incohérente	Cocher `/dev/sda` uniquement dans l’écran bleu grub-pc
Utilisation de `sdb`	Disques de VM perdus après une désallocation	Ne stocker que sur le disque de données, monté par UUID
Bridge sur la carte Azure	Les invités n’ont aucune connectivité	Bridge isolé avec `bridge-ports none`, plus NAT et dnsmasq
Plans d’adressage qui se chevauchent	Routage imprévisible entre invités et réseau Azure	Sous-réseau Azure et réseau interne dans deux plages distinctes
Disque en VirtIO SCSI	Aucun disque proposé par le programme d’installation Windows	Basculer le disque en SATA, ou charger les pilotes VirtIO
Pas de TPM ni d’UEFI	« This PC can’t run Windows 11 »	OVMF, disque EFI, Pre-Enroll keys et TPM 2.0 dès la création
Guest agent activé sans arrêt complet	L’agent est installé mais aucune adresse IP ne remonte	Arrêter puis démarrer la VM depuis Proxmox, pas un simple redémarrage Windows
Dépôt sans abonnement	Avertissement jaune et boîte de dialogue à chaque connexion	Parfait pour un lab, à remplacer par le dépôt entreprise en production
VM Azure laissée allumée	Une facture désagréable en fin de mois	Arrêter et désallouer, puis supprimer le groupe de ressources

Conclusion

Voilà, en quatorze étapes, vous avez un hyperviseur Proxmox VE 9 complet, avec son stockage dédié, son réseau interne routé, son interface web accessible, et une machine virtuelle Windows 11 qui tourne dedans, agent invité compris. Le tout sans acheter un seul serveur.

Concrètement, ça donne quoi ? Vous avez de quoi vous former sur Proxmox, tester des scénarios de migration, comparer honnêtement ce que fait la concurrence avec ce que vous connaissez déjà, et tout détruire d’un clic quand vous avez fini. Pour quelqu’un qui vit dans Azure toute la journée, c’est la façon la moins coûteuse de sortir de sa zone de confort.

Les trois points que je retiens de ce lab : la taille de la VM Azure décide de tout dès le premier écran, le réseau imbriqué se traite par du NAT et pas par du bridge, et le couple SATA plus E1000 fait gagner un temps fou sur l’installation d’un invité Windows.

Foncez tester, et n’oubliez pas de désallouer la VM en partant. Le prochain article sera consacré au passage en VirtIO d’un invité Windows déjà installé, disque et carte réseau : c’est le gain de performances évident de ce lab, mais c’est aussi la manipulation qui casse le plus de machines quand on la fait dans le mauvais ordre. On ira voir ensuite les instantanés et les sauvegardes.

🤖