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.

Proxmox : Pilotes VirtIO pour VM Windows

Dans le premier article, on a monté Proxmox VE 9 dans une machine virtuelle Azure et installé un Windows 11 dedans, en choisissant volontairement du matériel virtuel que Windows reconnaît tout seul : un disque SATA et une carte Intel E1000. Ça marche, c’est reposant, et c’est lent. Cette fois, on refait la même VM en VirtIO de bout en bout, pilotes chargés pendant l’installation, et on termine par le QEMU guest agent.

Si vous n’avez pas encore de nœud Proxmox sous la main, commencez par le premier article, celui-ci reprend exactement là où il s’arrête. Mais vous trouverez également une grande quantité de vidéos sur YouTube qui vous aideront à en savoir un peu plus sur Proxmox et comment le mettre en place :

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

1. VirtIO, pourquoi Windows ne le voit pas tout seul
2. Étape 1 : récupérer et uploader l’ISO virtio-win
3. Étape 2 : créer la VM en VirtIO intégral
4. Étape 3 : vérifier l’ordre de démarrage
5. Étape 4 : charger le pilote vioscsi pendant l’installation
6. Étape 5 : charger NetKVM pendant l’OOBE
7. Étape 6 : installer le QEMU guest agent
8. Étape 7 : vérifier que tout est bien en VirtIO
9. Les pièges à retenir

1. VirtIO, pourquoi Windows ne le voit pas tout seul

Quand un hyperviseur présente un disque ou une carte réseau à un invité, il a deux façons de faire. La première est l’émulation : QEMU imite au bit près un vrai contrôleur qui a existé, un SATA AHCI ou une carte Intel E1000. L’invité croit voir du matériel qu’il connaît depuis quinze ans, il charge son pilote habituel, tout fonctionne. Le prix à payer, c’est que chaque accès disque et chaque paquet réseau doit être traduit par l’hôte, instruction par instruction.

La seconde façon est la paravirtualisation, et c’est ce qu’est VirtIO : plutôt que d’imiter un matériel existant, l’hyperviseur expose une interface conçue pour la virtualisation, avec des files de requêtes partagées entre l’invité et l’hôte. L’invité sait qu’il est virtualisé et parle directement à l’hyperviseur. Beaucoup moins de traduction, beaucoup moins de CPU consommé, nettement plus d’IOPS et de débit.

Le revers est évident : il faut que l’invité connaisse cette interface. Le noyau Linux embarque les pilotes VirtIO depuis des années, donc une VM Debian ou Ubuntu démarre en VirtIO sans que vous ayez rien à faire. Windows non. Le programme d’installation ne contient que des pilotes pour du matériel émulé classique, et c’est précisément pour ça que l’écran de sélection du disque reste désespérément vide quand on lui présente un disque VirtIO SCSI.

Les pilotes existent, ils sont développés dans le cadre du projet virtio-win, distribués sous forme d’une ISO, et signés. Toute la manipulation consiste à les rendre disponibles au bon moment.

Le rôle	Le dossier sur l’ISO	Quand on le charge
Contrôleur de disque VirtIO SCSI	`vioscsi`	Pendant l’installation, à l’écran de sélection du disque
Contrôleur de disque bus VirtIO simple	`viostor`	Même moment, si le disque est déclaré en bus virtio et non scsi
Carte réseau VirtIO	`NetKVM`	Pendant l’OOBE, ou après le premier démarrage
Ballon de mémoire	`Balloon`	Après installation, facultatif
Agent invité QEMU	`guest-agent`	Une fois sur le bureau

Attention : ne confondez pas vioscsi et viostor. Le bon dossier dépend de la façon dont le disque est déclaré dans Proxmox : bus SCSI avec un contrôleur VirtIO SCSI pour le premier, bus VirtIO Block pour le second. Dans cet article, le disque est en SCSI, donc ce sera vioscsi.

2. Étape 1 : récupérer et uploader l’ISO virtio-win

L’ISO se télécharge depuis le dépôt du projet Fedora, qui héberge les binaires signés. Deux versions y cohabitent, la stable et la latest. Prenez la stable.

Attention : votre VM aura le démarrage sécurisé actif, puisque Windows 11 l’exige. Un pilote dont la signature n’est pas reconnue sera refusé sans message d’erreur explicite, vous verrez simplement le pilote ne pas apparaître dans la liste. La build stable évite ce genre de surprise.

Une fois le fichier récupéré, on l’envoie sur le nœud, exactement comme l’ISO Windows dans le premier article.

Dans l’arborescence, sélectionnez le stockage local du nœud, puis ISO Images.
Cliquez sur Upload, choisissez le fichier virtio-win.iso, puis Upload.

Vous pouvez aussi passer par Download from URL si vous préférez que le nœud télécharge lui-même, ou par la ligne de commande dans le répertoire des images.

3. Étape 2 : créer la VM en VirtIO intégral

On relance Create VM. Les onglets sont les mêmes que dans le premier article, seuls trois écrans changent.

Dans General, nommez la machine, puis cliquer sur Suivant :

Dans OS, sélectionnez l’ISO Windows 11, le type Microsoft Windows et la version 11/2022/2025. Cette fois, cochez bien Add additional drive for VirtIO drivers, et surtout choisissez l’ISO virtio-win dans le champ du dessous.

Mon retour terrain : c’est très exactement l’erreur que j’ai commise à mon premier essai. Le champ propose par défaut la seule ISO présente sur le stockage, donc celle de Windows, et rien ne vous signale que le lecteur supplémentaire monte deux fois le même DVD. Vous vous retrouvez à chercher des pilotes qui n’ont jamais été là.

Dans System, rien ne change par rapport au premier article, les pré-requis Windows 11 restent les mêmes.

Machine : q35.
BIOS : OVMF (UEFI), avec Add EFI Disk sur local-1TB et Pre-Enroll keys coché.
Add TPM coché, stockage local-1TB, version v2.0.
SCSI Controller : VirtIO SCSI single.
Cochez Qemu Agent dès maintenant, ça vous évitera d’y revenir plus tard.

Dans Disks, on garde cette fois le disque en SCSI, sur le contrôleur VirtIO SCSI single. Taille 64 Gio, format qcow2, stockage local-1TB. Activez IO thread, qui donne au disque son propre thread d’entrées et sorties, ce qui n’a d’intérêt qu’avec un contrôleur de type single, précisément celui qu’on a choisi.

Les onglets CPU et Memory ne changent pas : un socket, deux cœurs, 8192 Mio.

Dans Network, on garde le modèle VirtIO (paravirtualized) proposé par défaut, sur le bridge vmbr0.

L’écran Confirm permet de tout relire avant de valider. Vérifiez ces lignes.

ide0 pointe sur virtio-win-0.1.302.iso en media=cdrom, donc les pilotes sont bien montés
ide2 porte l’ISO Windows 11
scsi0 est sur local-1TB avec iothread=on
scsihw vaut virtio-scsi-single
net0 commence par virtio
bios vaut ovmf, machine vaut q35, ostype vaut win11
tpmstate0 est en version=v2.0 et efidisk0 en pre-enrolled-keys=1
cores vaut au moins 2, exigence de Windows 11

Attention : la liste du récapitulatif est triée par ordre alphabétique et tient rarement sur un écran. Faites-la défiler jusqu’en haut pour contrôler bios et cores, ce sont les deux valeurs qu’on oublie le plus souvent de vérifier.

4. Étape 3 : vérifier l’ordre de démarrage

Avec deux lecteurs CD sur la même machine, un détail peut vous coûter un quart d’heure : si ide0, le lecteur des pilotes, passe devant ide2 dans l’ordre de démarrage, la VM tente de démarrer sur une ISO qui n’est pas bootable et vous atterrissez dans un shell UEFI sans comprendre pourquoi.

Sélectionnez la VM, puis Options.
Double-cliquez sur Boot Order.
Placez ide2 en premier, scsi0 en second, et décochez ide0.

Décocher ide0 ne le démonte pas, le lecteur reste accessible depuis Windows. Il n’est simplement plus candidat au démarrage.

5. Étape 4 : charger le pilote vioscsi pendant l’installation

Ouvrez la Console de la VM et démarrez-la. L’installation de Windows 11 commence normalement : langue, clavier, acceptation des conditions.

Puis arrive le moment qu’on attendait. L’écran de sélection de l’emplacement d’installation est vide, et Windows affiche « Install driver to show hardware ». Rien d’anormal : il ne sait pas parler à un contrôleur VirtIO SCSI.

Cliquez sur Browse.
Dans l’arborescence, descendez jusqu’au dossier vioscsi. Il est plus bas que les premiers dossiers affichés, après viorng.
Dépliez vioscsi, puis w11, puis amd64, et validez par OK.
Windows propose alors le pilote « Red Hat VirtIO SCSI controller ». Sélectionnez-le et installez-le :

Mon retour terrain : si le dossier w11 n’existe pas sous vioscsi, prenez w10 en amd64. Les deux branches partagent le même binaire sur les builds récentes, et certaines ne créent pas le dossier w11. Laissez également cochée la case Hide drivers that aren’t compatible, elle vous évite de charger un pilote pour la mauvaise architecture.

L’écran se recharge, et le disque de 64 Go apparaît.

Le reste de l’installation se déroule sans intervention.

6. Étape 5 : charger NetKVM pendant l’OOBE

Après les redémarrages, l’expérience de première ouverture de session démarre, et un second mur vous attend. Windows affiche « Let’s connect you to a network » sans proposer la moindre connexion : même histoire que pour le disque, la carte VirtIO lui est inconnue.

Bonne nouvelle, Windows 11 propose désormais un bouton pour s’en sortir sans bricolage.

Cliquez sur Install driver.
Parcourez le lecteur virtio-win, remontez la liste jusqu’à NetKVM, tout en haut.
Ouvrez NetKVM, puis w11, puis amd64, et validez par Select Folder.

Windows installe « Red Hat VirtIO Ethernet Adapter », la carte apparaît, et elle reçoit son adresse du dnsmasq configuré dans le premier article, dans la plage 10.10.10.100 à 10.10.10.200. L’OOBE enchaîne alors sur la recherche de mises à jour.

Déroulez la fin de l’OOBE normalement :

Jusqu’au moment où le bureau s’affiche :

7. Étape 6 : installer le QEMU guest agent

Dernière brique. L’agent invité n’est pas un pilote de disque ni de carte réseau : c’est un petit service qui tourne dans Windows et dialogue avec l’hôte par un canal série virtuel dédié. Il fait remonter les adresses IP dans l’interface, permet un arrêt propre demandé au système invité, et autorise le gel des écritures pendant un instantané ou une sauvegarde.

Le canal côté hôte existe déjà, puisqu’on a coché Qemu Agent à la création. Reste la moitié invitée. D’ailleurs cela se voit ici car les adresses IP ne remontent pas encore :

On voit d’ailleurs également le pont de communication n’est pas encore correctement reconnu par Windows :

Dans Windows, ouvrez l’explorateur et le lecteur virtio-win.
Entrez dans le dossier guest-agent.
Lancez le paquet en version 64 bits et déroulez l’assistant.

Attendez la fin de l’installation de l’agent :

Vérifiez ensuite dans la console des services que QEMU Guest Agent est démarré et en mode automatique.

Enfin, il faut mettre à jour le pilote au niveau du gestionnaire de périphériques :

Sur l’ISO, choisissez l’arborescence corresponde à votre OS :

Attention : si vous aviez oublié de cocher l’option à la création et que vous l’activez après coup dans Options, un redémarrage demandé depuis Windows ne suffira pas. Il faut un arrêt complet puis un démarrage depuis Proxmox, pour que QEMU recrée la machine avec son canal série. C’est la cause numéro un des agents installés qui ne remontent rien.

Profitez-en pour installer le reste des pilotes, ballon de mémoire compris, avec le programme virtio-win-guest-tools présent à la racine du lecteur. Il pose tout d’un coup.

8. Étape 7 : vérifier que tout est bien en VirtIO

Trois contrôles, deux côté Proxmox, un côté Windows.

D’abord, l’onglet Summary de la VM doit maintenant afficher les adresses IP de l’invité, ce qui prouve que l’agent répond.

Ensuite, depuis le shell du nœud, deux commandes confirment le dialogue. Remplacez 103 par votre VMID.

qm agent 103 ping
qm guest cmd 103 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 rend la configuration réseau vue de l’intérieur de Windows, au format JSON.

Vous pouvez aussi relire la configuration complète de la machine :

qm config 103

Enfin, côté Windows, le gestionnaire de périphériques doit montrer le contrôleur et la carte Red Hat VirtIO, et surtout aucun point d’exclamation jaune.

9. Les pièges à retenir

Le piège	Le symptôme	La parade
Second lecteur pointant sur l’ISO Windows	Aucun pilote disponible au moment de charger	Sélectionner explicitement `virtio-win` dans le champ ISO du lecteur supplémentaire
Mauvais dossier de pilote	Le pilote n’apparaît pas dans la liste	`vioscsi` pour un bus SCSI, `viostor` pour un bus VirtIO Block
Ordre de démarrage	Shell UEFI au lieu du programme d’installation	Placer `ide2` devant, décocher `ide0`
Build latest des pilotes	Chargement refusé silencieusement avec le démarrage sécurisé	Prendre la build stable, signée
Dossier `w11` absent	Rien à sélectionner dans l’arborescence	Utiliser `w10` en `amd64`, c’est le même binaire
Pas de carte pendant l’OOBE	Impossible de terminer la configuration	Bouton Install driver, puis `NetKVM`, `w11`, `amd64`
Guest agent activé à chaud	Aucune adresse IP ne remonte	Arrêt complet puis démarrage depuis Proxmox, pas un redémarrage Windows
Bascule directe SATA vers SCSI	Écran bleu `INACCESSIBLE_BOOT_DEVICE`	Faire connaître le pilote avec un disque temporaire avant de changer le bus
Pas d’instantané avant conversion	Machine morte, rien pour revenir en arrière	Instantané systématique avant de toucher au bus du disque système

Conclusion

Voilà, en sept étapes, vous avez une machine Windows 11 entièrement paravirtualisée, disque et réseau, avec son agent invité qui dialogue avec l’hôte. La différence de confort à l’usage est immédiate : la console répond mieux, les adresses IP remontent dans l’interface, et l’arrêt depuis Proxmox devient un vrai arrêt propre.

Les trois points que je retiens : le lecteur de pilotes doit pointer sur la bonne ISO, sinon toute la suite est un mirage ; vioscsi pour le disque et NetKVM pour la carte, pas l’inverse ; et une conversion après coup se fait toujours avec un instantané et un disque temporaire, jamais en changeant le bus directement.

🤖

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.

🤖

Azure Virtual Desktop Hybride

Pendant longtemps, faire de l’AVD ailleurs que dans Azure, c’était soit du AVD on Azure Local, soit… rien. Pour ceux qui n’avaient pas encore investi dans le HCI mais qui avaient déjà du Hyper-V, du VMware ou du Nutanix qui tournait depuis dix ans en datacenter, l’équation était la même : reverse-proxy + RDS + bricolage maison. Microsoft vient enfin d’ouvrir la porte avec Azure Virtual Desktop Hybrid, en Public Preview depuis le 4 mai 2026.

Cette préversion est le fruit d’un travail continu de la part de Microsoft avant même l’annonce officielle de la fonctionnalité lors du Microsoft Ignite de 2025 à San Francisco.

Today, we’re excited to announce Azure Virtual Desktop for hybrid environments, a new capability for bringing the power of cloud-native desktop virtualization to existing on-premises infrastructure. With this update, on-premises Arc-Enabled Servers can be configured as AVD session hosts. This expands Azure Virtual Desktop’s hybrid capabilities beyond Azure Local to Microsoft Hyper-V, Nutanix AHV, VMware vSphere, physical Windows Servers, or anywhere Arc-Enabled Servers can be deployed on-premises.

Microsoft Tech Coommunity

Et la philosophie de fonctionnement est élégante : Azure Arc enrôle vos VMs on-prem, une extension AVD les transforme en session hosts, et le service AVD continue de vivre dans le cloud comme d’habitude. Bref, pas de nouvelle stack à apprendre, juste une nouvelle case à cocher.

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

Quelle est la nouveauté ?

Comme annoncé en introduction, Microsoft a publié le 4 mai 2026 la préversion publique d’Azure Virtual Desktop Hybrid. Le principe est simple : on prend une VM Windows qui tourne déjà chez vous (sur Hyper-V, VMware, Nutanix ou même un serveur physique), on l’enrôle dans Azure Arc, on lui pose une extension AVD, et hop, elle devient un session host AVD à part entière. L’utilisateur se connecte via la Windows App, exactement comme s’il attaquait un host pool 100 % Azure.

With Azure Virtual Desktop Hybrid, customers can run Azure Virtual Desktop session hosts on-premises using their existing hardware and preferred hypervisor connected through Microsoft Azure Arc. The Azure Virtual Desktop service remains in Azure, while session hosts can be deployed anywhere on-premises Azure Arc-enabled servers are supported. Users can access their desktops through the familiar Windows App.

This matters because it gives customers a phased, lower-risk path to cloud adoption:

Modernize legacy VDI environments at their own pace, preserving investments in datacenters, hardware, and operational tools.

Adopt cloud-managed desktops incrementally, with a clear path to migrate session hosts to Azure when the time is right.

Keep existing partner integrations for virtual machine management and provisioning.

Microsoft Tech Community

Pour rappel, jusqu’ici, faire tourner AVD ailleurs que dans Azure imposait soit AVD on Azure Local (anciennement Azure Stack HCI). Cela exigeait d’investir dans une stack HCI Microsoft – soit de partir sur du bon vieux RDS on-prem, en sacrifiant tout l’écosystème AVD (FSLogix moderne, app groups, Insights, Windows App).

Avec AVD Hybrid, ce dilemme s’efface : la documentation Microsoft Learn confirme que les VMs on-prem se comportent comme de vrais session hosts AVD pilotés depuis le portail Azure.

C’est un vrai changement de philosophie : historiquement, AVD c’était « tu déplaces ta VDI dans Azure, et après on en reparle ». Aujourd’hui, c’est « tu gardes ton hyperviseur, on apporte juste le control plane AVD chez toi ».

Ça ouvre AVD à toute une population qui en avait été tenue à l’écart pour des raisons de souveraineté, de coûts d’egress ou tout simplement parce qu’ils avaient déjà payé leur datacenter.

Est-ce la même chose qu’AVD sur Azure Local ?

C’est le même esprit, mais pas la même mécanique. AVD on Azure Local exige une infrastructure HCI Microsoft certifiée, avec ses nœuds, ses switches, son cluster, son réseau SDN. AVD Hybrid, lui, ne demande qu’une chose : une VM Windows qui peut joindre Azure Arc. Le reste, c’est votre hyperviseur qui le gère, peu importe lequel.

Autrement dit :

Pas besoin de hardware certifié Azure Local
Pas besoin de cluster spécifique – une simple VM Windows suffit
Le control plane AVD reste dans Azure (le service est rendu par Microsoft, comme pour AVD classique)
Les session hosts vivent chez vous, et c’est Azure Arc qui sert de pont

Si vous avez déjà déployé des serveurs Azure Arc-Enabled (par exemple pour bénéficier d’Azure Policy, Defender for Cloud ou Update Manager sur du on-prem), vous êtes déjà à 80 % du chemin. Il ne reste plus qu’à poser l’extension AVD et à brancher le session host sur un host pool.

Quels hyperviseurs sont supportés ?

La réponse de Microsoft est volontairement large : tout endroit où Azure Arc peut s’installer. Concrètement, c’est confirmé pour :

Microsoft Hyper-V (Windows Server, Hyper-V Server)
VMware vSphere (ESXi 7.x / 8.x)
Nutanix AHV
Serveurs Windows physiques (oui, vous pouvez transformer un poste rack en session host)

C’est ce que dit explicitement l’annonce officielle :

On-premises Arc-Enabled Servers can be configured as AVD session hosts. This expands Azure Virtual Desktop’s hybrid capabilities beyond Azure Local to Microsoft Hyper-V, Nutanix AHV, VMware vSphere, physical Windows Servers, or anywhere Arc-Enabled Servers can be deployed on-premises.

Microsoft Tech Community

Côté partenaires de lancement, Microsoft a explicitement nommé Nerdio, ControlUp, LoginVSI et Nutanix comme étant déjà alignés avec la Preview. Si vous utilisez Nerdio Manager for Enterprise, la fonctionnalité est intégrée dès aujourd’hui.

Quels OS et quelles licences sont éligibles ?

C’est le tableau qu’il faut imprimer et coller à côté de l’écran. Voici la matrice officielle issue de la documentation Microsoft Learn :

OS	Déploiement supporté	Licences éligibles
Windows Server 2016 / 2019 / 2022 / 2025	VMs et serveurs physiques	RDS CAL avec Software Assurance, ou RDS User Licenses en souscription
Windows 11 / Windows 10 Enterprise mono-session	VMs uniquement (pas de PC physique)	M365 E3/E5/A3/A5/F3, M365 Business Premium, Windows Enterprise E3/E5, Windows Education A3/A5, Windows VDA per user
Windows 11 / 10 Enterprise multi-session	Non supporté hors Azure	n/a

Le piège classique pour ceux qui font de l’AVD depuis longtemps : Windows 11 Enterprise multi-session n’est PAS supporté en hybride. Cette SKU reste exclusive à Azure. Si vous voulez du multi-utilisateur sur du on-prem, il faudra repasser sur du Windows Server avec le rôle Remote Desktop Session Host. C’est cohérent avec la philosophie multi-session, qui est historiquement liée à un avantage Azure-only.

Concernant la fameuse licence « Windows Cloud Hybrid » annoncée pour la GA : elle n’est PAS exigée pendant la Public Preview. Vous pouvez tester avec vos licences existantes. À la GA, Microsoft annoncera les conditions tarifaires définitives.

Entra Join ou jointure de domaine ?

Tous les modes sont supportés, et c’est une très bonne nouvelle. Mes propres tests le confirment :

Microsoft Entra Join pur : la VM s’enregistre directement dans le tenant. Idéal pour les machines Windows 11 mono-session, surtout dans une logique zéro-trust. Pas besoin de contrôleur de domaine joignable depuis la VM.

Active Directory (jointure de domaine traditionnelle) : fonctionne parfaitement, surtout pour des Windows Server qui ont besoin de Kerberos pour attaquer des serveurs de fichiers SMB on-prem ou des bases SQL avec authentification intégrée.

Active Directory + Microsoft Entra Connect (jointure de domaine traditionnelle, synchronisée vers Entra) :

Mon retour terrain :

Pour Windows 11 mono-session, l'Entra Join pur est plus rapide à mettre en place et évite tout le pataquès du DC à rendre joignable depuis le réseau de l'hyperviseur. 

Pour Windows Server, j'ai gardé le domain-join classique, parce que dans les vrais projets, le serveur de fichiers SMB est très souvent encore en AD on-prem et qu'on veut éviter de mixer les modèles. Les deux cas marchent du premier coup, je le détaillerai plus loin dans les cas pratiques.

Quels sont les prérequis à respecter ?

Avant de se lancer, il faut cocher quelques cases. Voici le récap :

Prérequis	Détail
Souscription	Une souscription Azure active
Resource providers	`Microsoft.HybridCompute`, `Microsoft.HybridConnectivity`, `Microsoft.GuestConfiguration`, `Microsoft.DesktopVirtualization`
RBAC	Azure Connected Machine Onboarding + Desktop Virtualization Contributor
Identité	Microsoft Entra ID (Entra Join ou AD synchronisé)
Réseau	Sortie TCP 443 vers Azure Arc + endpoints AVD
OS	Windows Server 2016+ ou Windows 11/10 Enterprise mono-session
Hyperviseur	Hyper-V, VMware, Nutanix AHV, ou serveur physique
Host pool	Validation host pool obligatoire pendant la Preview

Le piège classique : oublier le resource provider Microsoft.HybridConnectivity, qui est nécessaire pour la connectivité SSH/RDP via Arc. Si vous l’oubliez, l’enrôlement Arc passe, mais certaines opérations downstream peuvent silencieusement échouer. Croyez-en quelqu’un qui a passé une bonne demi-heure à se demander pourquoi 🙃.

Qu’est-ce qu’un « validation host pool » ?

Un validation host pool est un host pool AVD marqué comme environnement de validation (case à cocher dans le portail). Microsoft le réserve aux features en preview, et c’est actuellement le seul mode supporté pour AVD Hybrid pendant la Public Preview. La documentation est explicite :

Azure Virtual Desktop Hybrid is currently in Public Preview and is only supported with validation host pools. If you deploy a production host pool then you will need to redeploy once Windows Cloud Hybrid is Generally Available.

Microsoft Learn

Ne mettez pas en prod votre validation host pool. Servez-vous-en pour piloter, valider votre architecture, former l’équipe, mais prévoyez le redéploiement quand la GA sortira.

Quelles fonctions ne sont PAS supportées en Preview ?

Comme toute préversion qui se respecte, il y a des trous dans la raquette. Microsoft liste explicitement :

Power management dans le portail Azure (start/stop/deallocate sur les VMs)
Auto-Scale
Start VM on Connect
Session Host Configuration

C’est logique : ces fonctions reposent toutes sur le control plane Azure pour piloter les VMs (les démarrer, les arrêter, les redimensionner). Or, en hybride, c’est votre hyperviseur qui contrôle l’alimentation et le lifecycle des VMs. Microsoft ne peut pas démarrer une VM Hyper-V chez vous… à moins de passer par des extensions Arc dédiées, ce qui n’est pas encore en place.

Attention : l’absence d’Auto-Scale signifie que vous devez prévoir vous-même la scalabilité (provisioning manuel ou via votre orchestrateur d’hyperviseur). Pour des populations de plusieurs centaines d’utilisateurs, ce sera vite un bloqueur si vous comptiez sur AVD pour faire ça à votre place.

Combien ça coûte pendant la Preview ?

Pendant la Public Preview, vous payez :

Vos licences Windows / RDS CAL / M365 (rien de neuf, ce sont les mêmes qu’avant)
L’enrôlement Azure Arc (gratuit pour les serveurs Arc-Enabled de base, payant pour certaines features Defender / Update Manager / Policy avancées)
Le service AVD lui-même (pas de coût supplémentaire spécifique au mode hybride à ce stade)

À la GA, une licence Windows Cloud Hybrid sera très probablement requise pour les session hosts hybrides. Microsoft n’a pas encore communiqué les tarifs définitifs, mais le pattern habituel sur les « extensions cloud d’AVD » laisse penser à un modèle per user / month aligné sur les RDS User License Souscriptions.

Étape 0 : rappel des prérequis

Avant tout test, assurez-vous que :

Vous avez une souscription Azure active
Votre VM on-prem (Hyper-V, VMware, Nutanix…) est installée, à jour, et joignable en TCP 443 sortant vers Internet
Votre identité (Entra Join ou jointure AD) est déjà configurée avant l’enrôlement Arc
Que vous disposiez du rôle Azure Connected Machine Onboarding pour créer et gérer les ressources Azure Arc :

Que vous disposiez du rôle Contributeur à la virtualisation des postes de travail pour la gestion des pools d’hôtes Azure Virtual Desktop.

Étape 1 : enregistrer les resource providers

Sur la souscription cible, ouvrez Subscriptions > [votre sub] > Resource providers, puis vérifiez ou enregistrez si nécessaire :

Microsoft.HybridCompute
Microsoft.HybridConnectivity
Microsoft.GuestConfiguration
Microsoft.DesktopVirtualization

Vous pouvez aussi le faire en PowerShell :

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

Étape 2 : valider la readiness AVD

C’est l’étape clé documentée par Microsoft. L’objectif : confirmer que votre pool d’hôtes AVD de test peut être utilisé pour le test :

Ouvrez le portail Azure.
Cherchez Azure Virtual Desktop dans la barre.
Allez dans Host pools > Create.
Dans l’onglet Basics, cochez « Validation environment: Yes »

Attention : ne confondez pas validateavd (l’onglet sur la doc Microsoft, qui parle bien d’AVD) avec validatearc. Ce sont deux choses différentes : validateavd est ce qu’on cherche ici. La validation côté Arc (vérifier les resource providers, les rôles RBAC) se fait en parallèle.

Si vous ne disposez pas encore d’un pool d’hôtes AVD, veuillez le créer dans l’étape 3.

Étape 3 : créer le validation host pool, le workspace et l’application group

Si le pool d’hôtes AVD n’est pas encore créé dans votre environnement Azure, commencez par la base via l’assistant de création du host pool AVD :

Basics : nom (par exemple HP-AVDHybrid-Lab), région du metadata (dans mon cas Europe), type Pooled ou Personal selon votre besoin, et validation environment: Yes.
Virtual machines : choisir « No, I’ll add VMs later ». Les VMs seront ajoutées via l’enrôlement Arc + extension AVD, pas par le wizard Azure.
Workspace : créez-en un nouveau (par exemple WS-AVDHybrid-Lab) ou attachez-en un existant.
Tags et Review + create : validez.

Si cela n’est pas déjà le cas non plus, créez ensuite un application group (Desktop ou RemoteApp) et liez-le au workspace. C’est ce qui sera publié à l’utilisateur :

Étape 4 : onboarder la VM on-prem dans Azure Arc

Sur la VM on-prem, on va installer l’agent Azure Connected Machine, qui est le pont entre votre datacenter et Azure :

Dans le portail Azure, allez dans Azure Arc > Machines > Add.
Choisissez « Add a single server » (pour le lab) ou « Add multiple servers » (pour générer une clé partagée).
Renseignez la souscription, le group de ressources, la région.
Téléchargez le script d’onboarding PowerShell généré automatiquement.
Exécutez-le en administrateur sur la VM on-prem.

Le script télécharge l’agent (AzureConnectedMachineAgent.msi), l’installe, puis lance azcmagent connect avec les paramètres de votre tenant.

Au bout de 2 à 5 minutes, la VM apparaît dans Azure Arc > Machines avec un statut Connected.

Attention : la VM doit être déjà jointe à votre identité cible (Entra Join OU jointure de domaine) avant l’enrôlement Arc. Si vous changez de modèle d’identité après coup, il faut désinstaller l’agent Arc et tout recommencer. Ne sautez pas cette étape.

Étape 5 : installer l’extension AVD Azure Arc et enregistrer le session host

C’est ici que les deux mondes se rejoignent, et c’est l’étape qui m’a le plus surpris. Contrairement à ce qu’on pourrait croire, l’enregistrement du session host hybride ne se fait pas via le bouton « + Add » du host pool dans le portail.

Il faut exécuter manuellement un script PowerShell, qui va poser l’extension Microsoft.AzureVirtualDesktop.CloudDeviceExtension sur le compte Arc de la machine. C’est cette extension et non l’agent AVD classique qui réalise l’enregistrement.

Pré-requis : il faut avoir installé soit l’extension Azure CLI desktopvirtualization, soit le module PowerShell Az.DesktopVirtualization. Microsoft documente le détail dans Use the Azure CLI and Azure PowerShell with Azure Virtual Desktop. Personnellement, j’ai utilisé PowerShell, donc voici la séquence que j’ai jouée.

D’abord, installez les modules suivants :

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

Ensuite, connectez-vous à Azure et basculer explicitement sur la bonne souscription :

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

Attention : si vous oubliez le Set-AzContext et que votre compte est rattaché à plusieurs souscriptions, le New-AzConnectedMachineExtension ira chercher la VM Arc dans la mauvaise souscription et vous tombera sur une erreur « machine not found » très peu parlante. Toujours vérifier avec Get-AzContext avant d’enchaîner.

Générez une clé d’enregistrement du pool d’hôtes AVD via ce script PowerShell :

$HostPoolRG = "AVD_HostPool_RG"
$HostPoolName = "avd-hybrid-hp3"

$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

Enfin, lancez l’extension AVD sur la machine Arc :

# Settings
$settings          = @{ isCloudDevice = $false }
$protectedSettings = @{ registrationToken = $token }
$ResourceGroupName = "Arc_Servers_RG"
$MachineName = "WIN-8C8AQIS3DUL"
$Region = "westeurope"

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

Quelques précisions utiles :

$token = la registration key générée a une durée de vie limitée (max 27 jours), donc générez-la juste avant de jouer le script
ResourceGroupName et MachineName = ceux de la ressource Arc dans Azure (pas le hostname Windows brut, mais le nom sous lequel la VM apparaît dans Azure Arc > Machines)
Location = la région Azure du resource group de la machine Arc (francecentral, westeurope, etc.), pas la « localisation physique » de votre datacenter
isCloudDevice = $false est essentiel : c’est ce flag qui dit à l’extension qu’on est en mode hybride, et pas sur une VM Azure native
La registration key passe en protectedSettings, elle n’apparaîtra donc pas en clair dans la définition de l’extension

L’extension met 3 à 5 minutes à se déployer :

En coulisses, elle installe les composants AVD nécessaires (équivalent de l’agent et du bootloader sur les VMs Azure natives) et enregistre la machine auprès du host pool grâce au token.

Au bout de quelques minutes, la VM apparaît dans la liste Session hosts du host pool, avec un statut Available. Du point de vue d’AVD, c’est une VM « comme les autres » et c’est tout l’intérêt de la mécanique d’Azure Arc.

Comme pour les machines AVD hébergées dans Azure, des contrôles réguliers sont appliquées afin de vérifier leur disponibilité :

Un échec dans les contrôles AVD rendra la machine indisponible pour recevoir de nouvelles sessions utilisateurs :

Étape 6 : assigner les utilisateurs AVD

Dernière ligne droite :

Ouvrez votre application group (Desktop ou RemoteApp).
Allez dans Assignments et ajoutez les utilisateurs ou groupes Microsoft Entra qui doivent pouvoir se connecter.

Étape 7 : test de connexion AVD

Côté utilisateur : ouvrez la Windows App (web ou client lourd) et connectez-vous avec le compte Entra ID assigné.
Le desktop publié par votre validation host pool hybride apparaît. Cliquez, c’est parti.

Et voilà : vous êtes connecté à un Windows qui tourne chez vous, mais piloté par AVD dans le cloud. Première fois que je l’ai vu marcher, ça m’a clairement fait sourire 😅

Cas n°1 : Hyper-V + Windows Server domain-joined

Premier cas testé dans mon lab : une VM Windows Server 2022 qui tourne sur un nœud Hyper-V standalone, jointe à mon AD on-prem (lui-même synchronisé vers Entra ID via Microsoft Entra Connect).

OS : Windows Server 2022 Standard
Hyperviseur : Hyper-V (Windows Server 2022)
Identité : jointure de domaine AD on-prem + sync Entra Connect
Licence : Windows Server + RDS CAL

Déroulé : enrôlement Arc nickel en 3 minutes, extension AVD posée en 5 minutes, session host visible Available dans le host pool. Connexion via la Windows App avec un user du domaine sync vers Entra : OK, RDP qui négocie en 2 secondes, le bureau s’affiche. Aucun ajustement particulier nécessaire. C’est le scénario le plus « facile » car on retrouve une cinématique classique RDS, juste branchée sur AVD.

Mon retour : c’est le scénario à privilégier pour migrer un parc RDS existant. Vous gardez votre AD, vos GPO, vos profils, votre serveur de fichiers SMB, et vous échangez juste votre broker / gateway / web access RDS contre AVD. Le gain est majeur : vous récupérez la Windows App, FSLogix moderne, l’intégration Entra ID, les Insights, sans toucher à votre infra serveur.

Cas n°2 : Hyper-V + Windows 11 mono-session Entra-joined

Deuxième cas, plus moderne et plus zéro-trust : une VM Windows 11 Enterprise mono-session qui tourne aussi sur Hyper-V, mais cette fois sans aucune jointure AD, uniquement Microsoft Entra Join.

OS : Windows 11 Enterprise 24H2 (mono-session)
Hyperviseur : Hyper-V
Identité : Microsoft Entra Join pur (pas d’AD)
Licence : Microsoft 365 Business Premium

Déroulé : avant tout, j’ai pris soin de faire l’Entra Join AVANT l’enrôlement Arc (via Settings > Accounts > Access work or school). Une fois la VM jointe au tenant, l’agent Arc s’installe normalement, l’extension AVD se pose, et le session host apparaît dans le host pool. Connexion via la Windows App avec un user Entra : OK, single sign-on transparent grâce à Entra Join.

Mon retour : c’est le scénario qui me plaît le plus pour des nouveaux projets. Pas de DC à exposer au réseau de l’hyperviseur, pas de Kerberos, pas de GPO – juste Entra ID, les policies Intune, et c’est tout. Pour des cabinets, des équipes projet, des labs, ou tout ce qui n’a pas besoin de Kerberos vers du legacy, c’est la voie royale. Pour rappel : Windows 11 multi-session reste interdit en hybride, donc pour cette population, c’est mono-session ou rien.

Cas n°3 : VMware vSphere + Windows Server

Troisième cas, et celui qui intéressera beaucoup d’entreprises encore très VMware-centric : une VM Windows Server 2025 sur VMware vSphere 8, jointe au domaine.

OS : Windows Server 2025 Standard
Hyperviseur : VMware vSphere 8 (ESXi 8.0 U2)
Identité : jointure de domaine AD on-prem
Licence : Windows Server + RDS CAL

Déroulé : identique au cas n°1, à 100 %. C’est exactement ça qui est bluffant. Du point de vue d’Azure Arc et d’AVD, qu’il y ait du Hyper-V ou du vSphere en dessous ne change strictement rien. Tant que l’agent Connected Machine s’installe et que la VM peut sortir en TCP 443, c’est jeu. J’ai posé l’agent Arc, lancé l’extension AVD, le session host est apparu en Available, et un utilisateur du domaine s’est connecté via la Windows App sans broncher.

Mon retour : c’est le cas le plus politique. Pour beaucoup de DSI, « passer chez Microsoft » voulait jusqu’ici dire « abandonner VMware ». AVD Hybrid permet exactement l’inverse : garder vSphere, ne pas refaire toute son infra, et bénéficier quand même du control plane AVD moderne. Pour les organisations qui ont investi dans vSphere récemment (et il y en a beaucoup, surtout après les bouleversements de licensing VMware), c’est un message fort de Microsoft : pas besoin de tout casser pour profiter d’AVD.

Le résumé visuel de mes trois cas :

Cas	Hyperviseur	OS	Identité	Résultat
1	Hyper-V	Windows Server 2022	AD domain-join	OK – idéal pour reprise RDS
2	Hyper-V	Windows 11 mono-session	Entra Join pur	OK – idéal pour green-field zéro-trust
3	VMware vSphere 8	Windows Server 2025	AD domain-join	OK – idéal pour parcs vSphere existants

Et la conclusion qui me semble importante : les trois cas suivent rigoureusement la même procédure. La doc Microsoft est tenue à la lettre, les scripts d’onboarding fonctionnent à l’identique, l’extension AVD se pose pareil. Aucune divergence d’OS ou d’hyperviseur n’a nécessité de bricolage particulier. C’est rare et c’est notable.

Les limitations et pièges à connaître

Parce qu’on est en Public Preview, il y a quelques verrues à garder en tête :

Limitation	Impact
Validation host pool obligatoire	Tout passage en prod nécessitera un redéploiement à la GA
Windows 11 multi-session non supporté hors Azure	Multi-utilisateur obligatoire = Windows Server
Auto-Scale absent	Provisioning manuel ou via votre orchestrateur d’hyperviseur
Start VM on Connect absent	Les session hosts doivent être déjà allumés côté hyperviseur
Power management Azure portal absent	Le start/stop se fait dans votre console d’hyperviseur, pas Azure
Session Host Configuration absent	Pas de « build automatique » du session host depuis le portail
Identité à fixer AVANT Arc	Changer d’identité après onboarding = désinstaller / réinstaller
Pas de date de GA annoncée	À tester en pilote, pas à passer en prod critique

Et comme toujours avec les previews Microsoft, la feature peut encore évoluer avant la GA (interface, intégrations supplémentaires, prise en charge du multi-session, modèle de licence Windows Cloud Hybrid). À surveiller de près.

Conclusion

C’est clairement l’une des évolutions que beaucoup de monde attendait, et pas juste les fans de la marque AVD (comme moi 😅). AVD Hybrid règle un vrai point bloquant : pour faire du AVD ailleurs que dans Azure, il fallait jusqu’ici passer par Azure Local et son hardware certifié, ce qui excluait de fait toutes les entreprises encore en VMware ou Nutanix. Avec cette préversion, Microsoft signe un geste d’ouverture rare : votre hyperviseur, peu importe lequel, peut héberger des session hosts AVD pilotés par Azure Arc.

Ce qui me plaît particulièrement : la cohérence de la procédure entre les trois cas que j’ai testés (Hyper-V Server domain-joined, Hyper-V Windows 11 Entra-joined, VMware vSphere domain-joined), la simplicité du branchement via Azure Arc (les admins qui pratiquent déjà Arc sur du Defender for Cloud ou de l’Update Manager seront en territoire connu), et le fait qu’on retrouve l’écosystème AVD complet (Windows App, Entra ID, FSLogix, Insights) plutôt qu’une version dégradée.

Ce qui mérite vigilance : le statut Public Preview qui impose des validation host pools, l’absence d’Auto-Scale qui peut bloquer pour les gros parcs, l’interdiction du multi-session hors Azure qui force à repenser certains designs, et le flou sur la licence Windows Cloud Hybrid qui arrivera à la GA. Je l’intègre dès maintenant dans mes projets PoC, mais avec un pilote propre avant toute généralisation.

En tout cas, si vous avez du Hyper-V, du VMware ou du Nutanix qui tourne en datacenter, foncez tester : Azure portal > Azure Virtual Desktop > Host pools > Create, cochez Validation environment: Yes, puis enrôlez vos VMs via Azure Arc et posez l’extension AVD.

La documentation officielle est claire et la procédure marche du premier coup. Et dites-moi dans les commentaires ce que vous en pensez, surtout si vous avez essayé sur un hyperviseur que je n’ai pas couvert (Proxmox ? KVM ? Hyper-V Azure Local ?), je suis curieux de vos retours !

Azure Virtual Desktop sur Azure Local

Bonne nouvelle ! Azure Local 23H2 est maintenant disponible en GA. La 23H2 simplifie grandement la configuration et le déploiement des clusters HCI. Autre bonne nouvelle, AVD est aussi en GA sur Azure Azure Local ! Si tester Azure Virtual Desktop via une solution cloud hybride et sans acheter quoi que ce soit vous intéresse, cet article est fait pour vous !

Un premier article avait déjà été écrit sur ce blog à propos d’Azure Local. La solution proposée par Microsoft vous permet de disposer d’une infrastructure hyperconvergée basée sur les technologies Azure :

Peut-on tester Azure Local sans investir dans du matériel physique ?

La réponse est oui grâce à Azure Arc Jumpstart ! Vous pouvez recréer un cluster Azure Local directement dans Azure. L’article précédemment écrit proposait la même approche, mais Jumpstart simplifie grandement le processus.

Qu’est-ce qu’Azure Arc Jumpstart ?

Il s’agit de solutions de type bac à sable proposées par Microsoft :

L’univers de l’Arc Jumpstart. Vous souhaitez explorer plusieurs environnements et découvrir toute l’étendue de Jumpstart ? Obtenez des scénarios automatisés de zéro à héros pour les serveurs compatibles avec Arc, Kubernetes compatible avec Arc, et plus encore. Parcourez les scénarios. Explorez des scénarios du cloud à la périphérie conçus pour répondre à des besoins sectoriels spécifiques.
Azure Arc Jumpstart

Comme le montre la page suivante, beaucoup de scénarios y sont proposés :

Mais qu’est-ce qu’HCIBox ?

En quelques mots : il vous permet d’essayer Azure Local directement dans Azure :

HCIBox est une solution clé en main qui fournit un bac à sable complet pour explorer les capacités d’Azure Local et l’intégration du cloud hybride dans un environnement virtualisé. HCIBox est conçu pour être complètement autonome au sein d’un seul abonnement Azure et d’un seul groupe de ressources, ce qui permettra à un utilisateur de se familiariser facilement avec Azure Local et la technologie Azure Arc sans avoir besoin de matériel physique.
Azure Arc Jumpstart

Combien coûte le service HCIBox ?

Les ressources HCIBox entraînent des frais de consommation Azure, qui dépendent des ressources Azure sous-jacentes telles que le calcul central, le stockage, le réseau.

Voici une idée de ce que peut représenter une HCIBox fonctionnant en 24/7 pendant 31 jours et hébergée en Suisse :

Enfin, une FAQ de la HCIBox est disponible juste ici.

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice Azure Virtual Desktop fonctionnant grâce à un Azure Local construit dans une HCIBox elle-même hébergée sur Azure :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

Un tenant Microsoft
Une souscription Azure valide

Etape I – Préparation de l’environnement Azure :

Afin de pouvoir déployer les ressources Azure liées à la HCIBox, il est nécessaire d’avoir un quota CPU suffisant pour une famille particulière de machines virtuelles.

Pour cela, ouvrez votre souscription Azure, puis rendez-vous sur le menu suivant afin de vérifier que le quota de la famille ESv5 est au minimum de 32 cœurs :

Note : Si cela n’est pas le cas, le stylo à droite vous permet de créer une demande de modification de quota. Cette demande sera traitée automatiquement ou génèrera un ticket de support chez Microsoft.

Ouvrez ensuite Azure Cloud Shell via le bouton situé dans la barre en haut de votre portail Azure :

Si l’ouverture d’Azure Cloud Shell est une première sur votre environnement Azure, il vous sera demandé de créer un compte de stockage comme le montre l’exemple ci-dessous :

Une fois Azure Cloud Shell ouvert en PowerShell, exécuter la commande suivante afin de recréer le référentiel Azure Arc Jumpstart sur votre compte de stockage :

git clone https://github.com/microsoft/azure_arc.git

Vérifiez la version installée d’Azure CLI avec la commande ci-dessous. Celle-ci doit être supérieure ou égale à la version 2.56.0 :

az --version

Dans le cas où plusieurs souscriptions Azure sont en place sur votre tenant, utilisez la commande suivante afin d’identifier la souscription actuellement sélectionnée :

az account list --query "[?isDefault]"

Utilisez la commande suivante et disponible ici pour changer au besoin la souscription :

az account set

Utilisez la commande suivante afin de vérifier le bon changement de sélection :

az account list --query "[?isDefault]"

Utilisez la commande suivante afin de vérifier que les quotas liés à la région Azure et à la famille de VMs soient suffisants :

az vm list-usage --location westeurope --output table

Créez un principal de service Azure (SP) disposant d’un contrôle d’accès (RBAC) de propriétaire sur la souscription Azure, prenez soin de sauvegarder les 3 valeurs en sortie :

az ad sp create-for-rbac -n "JumpstartHCIBox" --role "Owner" --scopes /subscriptions/$subscriptionId

Vérifiez cette création depuis la page des droits RBAC de votre souscription Azure :

Profitez-en pour Enregistrer le fournisseur de ressources suivant sur votre souscription Azure :

Le statut du fournisseur de ressources change durant cette phase :

Environ 30 secondes plus tard, le statut du fournisseur de ressources change encore une fois :

De retour sur Azure Cloud Shell, mettez à jour la dernière version de Bicep

az bicep upgrade

Récupérez l’identifiant d’objet du fournisseur de ressources Azure Local de votre tenant :

az ad sp list --display-name "Microsoft.AzureStackHCI Resource Provider"

Votre environnement est maintenant configuré pour commencer le déploiement des ressources Azure de votre HCIBox.

Etape II – Déploiement des ressources Azure :

Pour cela, récupérez le template au format JSON disponible à cette adresse afin de modifier les informations suivantes :

spnClientId : Votre identifiant de principal de service Azure
spnClientSecret : Votre secret de principal de service Azure
spnTenantId : Votre identifiant de tenant Azure
spnProviderId : Votre identifiant de fournisseur de ressources Azure Local
WindowsAdminUsername : Nom d’utilisateur de l’administrateur
windowsAdminPassword : Mot de passe de l’administrateur
logAnalyticsWorkspaceName : Nom unique pour l’espace de travail HCIBox Log Analytics
deployBastion : Option pour déployer ou non Azure Bastion

Téléversez le fichier template au format JSON modifié sur Azure :

Déplacez le fichier template dans le dossier Bicep :

mv ./main.parameters.json ./azure_arc/azure_jumpstart_hcibox/bicep/

Positionnez-vous également dans ce même dossier :

cd ./azure_arc/azure_jumpstart_hcibox/bicep/

Lancez la commande suivante afin de créer un groupe de ressources dans la région Azure de votre choix :

az group create --name "jlohci"  --location "westeurope"

Lancez la commande suivante afin de déployer les ressources Azure de votre HCIBox :

az deployment group create -g "jlohci" -f "main.bicep" -p "main.parameters.json"

Suivez le déploiement des ressources Azure depuis le nouveau groupe de ressources créé :

Environ 30 minutes plus tard, les ressources Azure de votre HCIBox sont enfin déployées :

Les ressources Azure servant à votre HCIBox sont maintenant en place :

L’étape suivante va consister à déployer différents serveurs nécessaires à votre Cluster Azure Local. Pour cela, nous utiliserons un script PowerShell déjà préparé.

Etape III – Déploiement des nœuds connectés via Azure Arc :

Pour lancer ce script, nous devrons ouvrir une session RDP sur la machine virtuelle hôte. Pour cela recherchez la machine virtuelle suivante, puis cliquez sur celle-ci :

Démarrez une session RDP via le service Azure Bastion en utilisant les identifiants renseignés dans le template JSON :

Une fois que vous vous êtes connecté en RDP, le script PowerShell s’ouvre automatiquement :

Ce script prendra au total entre 1 et 2 heures avec 10 différentes étapes.

Téléchargement des fichiers VHDX de l’OS Azure Local :

Configuration de la virtualisation :

Création de la VM de management sous Hyper-V :

Création des 2 VMs représentants les 2 nœuds Azure Local :

Démarrage des 3 machines virtuelles :

Configurations réseaux et stockages :

A l’intérieur même de la machine virtuelle de management, déploiement d’une autre VM dédiée au réseau :

Finalisation du déploiement de l’infrastructure Azure LocalAzure Local dont l’enrôlement de nos 2 serveurs sur Azure via Azure Arc:

Comme indiqué plus haut, le script PowerShell se ferme automatiquement à la fin :

Si le script vous affiche une ou plusieurs erreurs, différents journaux d’évènements sont disponibles dans le dossier suivant :

C:\HCIBox\Logs\

Il existe également une page officielle de Troubleshoot juste ici :

Log file	Description
C:\HCIBox\Logs\Bootstrap.log	Output from the initial bootstrapping script that runs on HCIBox-Client.
C:\HCIBox\Logs\New-HCIBoxCluster.log	Output of New-HCIBoxCluster.ps1 which configures the Hyper-V host and builds the HCI cluster, management VMs, and other configurations.
C:\HCIBox\Logs\Generate-ARM-Template.log	Log output of the script that builds the hci.json and hci.parameters.json file
C:\HCIBox\Logs\HCIBoxLogonScript.log	Log output from the orchestrator script that manages the install
C:\HCIBox\Logs\Tools.log	Log output from tools installation during bootstrap

Afin de bien vérifier la connexion à Azure, recherchez le service Azure Arc via la barre du portail Azure :

Vérifiez que les deux nœuds HCI sont présents dans Azure Arc :

Vérifiez que les deux nœuds ont correctement installé avec succès les trois extensions suivantes :

TelemetryAndDiagnostics
AzureEdgeLifecycleManager
AzureEdgeDeviceManagement

Vérifiez également sur le second nœud la présence de ces 3 extensions :

Enfin comme le montre l’image ci-dessous, votre Cluster Azure Local n’est pas encore déployé :

Azure Local utilise un processus en 2 étapes pour valider et déployer des clusters dans Azure à l’aide d’un modèle ARM.

Etape IV – Déploiement du cluster Azure Local :

Avant cela, commencez par ajouter à votre compte Entra ID les 2 rôles Entra ID suivants :

Administrateur Key Vault
Contributeur au compte de stockage

Retournez sur la session RDP ouverte via Azure Bastion, ouvrez l’explorateur de fichiers, faites un clic droit sur le dossier HCIBox, puis ouvrez-le dans VSCode :

Cliquez-ici pour continuer :

Vérifiez que le fichier hci.parameters.json est correct et sans valeurs de paramètre -staging :

Toujours sur la machine virtuelle hôte, ouvrez le portail Azure avec votre identifiant Entra ID, puis rechercher le service suivant :

Sélectionnez Construire votre propre modèle dans l’éditeur :

Collez le contenu du fichier hci.json dans l’éditeur, puis cliquez sur Enregistrer :

Cliquez sur Editer les paramètres :

Collez le contenu de hci.parameters.json dans l’éditeur, puis cliquez sur Enregistrer :

Renseignez votre groupe de ressources, puis lancez la validation Azure :

Une fois la validation Azure réussie, exécutez le template ARM :

Attendez que ce dernier soit terminé :

Environ 15 minutes plus tard, cliquez-ici pour ouvrir à nouveau votre groupe de ressources :

Cliquez sur la nouvelle ressource Azure représentant votre cluster Azure Local :

Un bandeau vous indique que la validation est réussie mais que le déploiement n’est pas encore effectué. Cliquez-ici pour le lancer :

La mise en place du template ARM vous amène directement sur l’onglet suivant, lancez la validation Azure :

Une fois la validation Azure réussie, lancez le déploiement des ressources, puis attendez :

Suivez l’avancement du déploiement du cluster Azure Local via le menu suivant :

Environ 2 heures plus tard, cette même page vous indique la fin du déploiement du cluster Azure Local :

Retournez sur la page principale de votre cluster Azure Local afin de lancer au besoin les mises à jour disponibles (2402) :

Lancez la mise à jour 2402 comme ceci :

Cliquez sur Suivant :

Lancez l’installation de la mise à jour :

Suivez l’avancement de la mise à jour de votre cluster via le menu suivant :

Environ 2 heures plus tard, cette même page doit vous indiquer la fin de la mise à jour sur de votre cluster Azure Local :

Votre cluster Azure Local est enfin installé et à jour. Nous allons maintenant pouvoir nous intéresser à son contenu, à savoir :

les images OS
les réseaux logiques

Etape V – Images OS et réseaux logiques d’Azure Local :

Avant de pouvoir créer des machines virtuelles sur votre cluster HCI à partir du portail Azure, vous devez créer des images de VM qui peuvent être utilisées comme base. Ces images peuvent être importées de la place de marché Azure ou fournies directement par l’utilisateur.
Azure Arc Jumpstart

Cliquez-ici pour importer une image à partir de la Marketplace d’Azure :

Dans mon exemple, j’importe les deux images OS suivantes :

Windows 11 Enterprise multisession + Microsoft 365 Apps, version 23H2
Windows Server 2022 Datacenter: Azure Edition

La première étape consiste à télécharger sur votre cluster les deux images OS :

Environ 2 heures plus tard, le téléchargement des 2 images est terminé :

Comme nous le rappelle Azure Arc Jumpstart, Le réseau de la HCIBox comprend un sous-réseau 192.168.200.0/24 étiqueté VLAN200 :

Network details
Subnet	192.168.200.0/24
Gateway	192.168.200.1
VLAN Id	200
DNS Server	192.168.1.254

Ce réseau est conçu pour être utilisé avec les VMs Arc sur HCIBox. Pour utiliser ce réseau préconfiguré, vous devez créer une ressource réseau logique qui correspond à ce sous-réseau.

Depuis la VM hôte ouverte en RDP, ouvrez le script PowerShell suivant afin de créer le réseau logique sur votre cluster Azure Local :

Une fois le script correctement exécuté, le réseau logique est visible sur le portail Azure juste ici :

Les information de sous-réseau, de passerelle et de serveur DNS sont bien reprises :

Tous les éléments de configuration sont maintenant en place pour commencer la création de machines virtuelles dans votre cluster Azure Local.

Avant de déployer un environnement Azure Virtual Desktop, je vous propose de créer une machine virtuelle fonctionnant sous Windows Server 2022.

Etape VI – Déploiement d’une machine virtuelle Windows Server 2022 :

Depuis la page de votre cluster Azure Local, cliquez-ici pour créer votre première machine virtuelle :

Choisissez un groupe de ressources, donnez un nom à votre VM, puis sélectionnez Standard pour le type de sécurité :

Sélectionnez l’image Windows Server que vous avez téléchargée précédemment, puis définissez sa taille et sa mémoire :

Cochez la case suivant, puis définissez un compte administrateur local :

Joignez la VM au domaine AD créé pour votre Azure Local, puis cliquez sur Suivant :

Inutile d’ajouter d’autres disques de données, cliquez sur Suivant :

Cliquez-ici pour ajouter une carte réseau :

Nommez la carte réseau, sélectionnez le réseau logique créé précédemment, choisissez la méthode d’allocation sur Automatique, puis cliquez sur Ajouter :

Cliquez sur Suivant :

Ajoutez au besoin des tags, puis cliquez sur Suivant :

Cliquez sur Créer :

Comme pour une ressource Azure classique, vous pouvez suivre toutes les étapes du déploiement :

Environ 20 minutes plus tard, cliquez-ici pour apercevoir les propriétés de votre VM :

Copiez l’adresse IP privée de votre nouvelle VM :

Depuis la session ouverte via Azure Bastion, ouvrez une session Hyper-V sur la machine virtuelle de management :

Utilisez le compte suivant :

Ouvrez une session RDP via l’adresse IP privée de votre nouvelle VM tout en utilisant un compte de domaine :

Constatez la bonne ouverture de session sur votre machine virtuelle Windows Server 2022 :

Le test d’une machine virtuelle individuelle fonctionne bien. Il ne nous reste plus qu’à tester le déploiement d’un environnement Azure Virtual Desktop sur votre cluster Azure Local.

Etape VII – Déploiement d’Azure Virtual Desktop :

Avant de pouvoir déployer votre environnement Azure Virtual Desktop. Il est conseillé de synchroniser les identités Active Directory avec Entra ID.

Pour cela, ouvrez une session Hyper-V à votre contrôleur de domaine de démonstration :

Utilisez le compte de domaine suivant :

Créez une nouvelle OU, des utilisateurs de test et un groupe dédié à Azure Virtual Desktop :

Téléchargez et installez Microsoft Entra Connect via ce lien direct :

Depuis la page des utilisateurs d’Entra ID, vérifiez la bonne synchronisation de vos utilisateurs et votre groupe AVD :

Retournez sur la page de votre cluster Azure Local, puis cliquez-ici pour déployer votre environnement Azure Virtual Desktop :

Renseignez les informations de base de votre pool d’hôtes Azure Virtual Desktop, puis cliquez sur Suivant :

Ajoutez un ou des VMs Azure Local à votre AVD en reprenant l’image Windows 11 Enterprise multisession :

Définissez sa taille, sa mémoire et son réseau logique :

Joignez-la au domaine Active Directory, renseignez le compte d’administrateur local, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources :

Attendez environ 1 heure :

L’image ci-dessous vous montre l’apparition des VMs AVD :

Seulement, et contrairement au déploiement de la première VM sous Windows Server 2022, le management invité n’est pas automatiquement installée sur les VMs AVD :

Afin d’éviter un échec de votre déploiement AVD, actualiser la page de votre machine virtuelle AVD régulièrement afin d’activer le management invité dès que cela est possible :

Attendez environ 2 minutes le temps de la préparation :

Copiez le script suivant pour sa mise en place :

Récupérez l’adresse IP privée de votre VM AVD :

Depuis la VM de management, ouvrez une session RDP avec le compte administrateur local :

Collez le script sur la VM AVD :

Sur le portail Azure, activez le management invité de votre VM dès que cela est possible :

Suivez l’activation du management invité par le menu suivant :

Rafraichissez la page plusieurs fois si nécessaire :

Environ 30 minutes plus tard, le déploiement de votre AVD doit se terminer :

Consultez votre pool d’hôtes AVD depuis le portail Azure :

Vérifiez également la bonne apparition de vos VMs AVD dans votre Active Directory :

Ajoutez votre groupe Entra ID synchronisé à votre AVD en tant qu’utilisateurs AVD :

Démarrez votre client Remote Desktop, puis ouvrez une session AVD sur un utilisateur de test :

Renseignez à nouveau le mot de passe de votre utilisateur :

Attendez quelques secondes l’ouverture de votre session Azure Virtual Desktop :

Conclusion

Grâce à la HCIBox, nous avons rapidement et facilement pu se rendre compte de l’écosystème hybride proposé par Microsoft pour une de leurs solutions phares : Azure Virtual Desktop.

Important : Attention tout de même à ne pas trop dépenser de crédits pour votre HCIBox. pensez à supprimer ou éteindre vos ressources une fois vos tests terminés :