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.

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.

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é.

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.

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 :

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

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

1. Dans le portail, cherchez Azure Virtual Desktop, puis Host pools et Create.
2. Dans Basics, nommez le pool, choisissez la région des métadonnées et le type Pooled ou Personal.
3. Dans Virtual machines, choisissez No, I’ll add VMs later. La machine arrivera par Arc, pas par l’assistant.
4. Dans Workspace, créez ou rattachez un workspace, puis validez.
5. 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

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

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 :

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.

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

1. Dans le portail, cherchez Azure Arc, dépliez Infrastructure et sélectionnez Machines.
2. Cliquez sur le nom de votre machine, puis dans le menu de gauche dépliez Settings et choisissez Extensions.
3. Cliquez sur Add, sélectionnez l’extension Azure Virtual Desktop Hybrid, puis Next.
4. Choisissez l’abonnement, le groupe de ressources et le host pool auquel rattacher le session host.
5. 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 :

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.

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.

12. Les pièges à retenir

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.