ℹ️ À savoir · En bref
Avec PVS, les machines n'ont pas de disque système : elles démarrent sur le réseau et lisent leur disque (le vDisk) en flux depuis les serveurs Provisioning. Des centaines de machines partagent un seul vDisk en lecture seule.
Les écritures vont dans un cache d'écriture local (RAM + disque) effacé au redémarrage : chaque redémarrage repart d'une image propre.
Objectifs de la fiche
- Comprendre l'architecture et le démarrage d'une cible.
- Gérer les vDisks : modes, versions, fusion.
- Choisir et dimensionner le cache d'écriture.
- Savoir quand choisir PVS plutôt que MCS.
Architecture
| Composant | Rôle |
|---|---|
| Ferme | Ensemble de serveurs, magasins et vDisks partageant une base de données SQL |
| Serveur PVS | Stream Service : diffuse les vDisks aux cibles ; plusieurs serveurs pour la répartition et la haute disponibilité |
| Magasin (store) | Emplacement des fichiers vDisk (VHDX) : disque local de chaque serveur (répliqué) ou partage |
| Collection de machines | Regroupement des cibles (par catalogue, par site) |
| Console / PowerShell | Administration ; assistants de création de machines pour Citrix (Citrix Virtual Desktops Setup Wizard) |
Démarrage d’une cible
| Méthode | Principe | Remarque |
|---|---|---|
| PXE + TFTP | DHCP indique le serveur de démarrage, la cible charge le chargeur PVS par TFTP | Simple, dépend du DHCP et du réseau (relais entre VLAN) |
| BDM (Boot Device Manager) | Petit disque ou ISO de démarrage qui contient les adresses des serveurs | Pas de PXE/TFTP ; recommandé quand le réseau est contraint |
| UEFI | Pris en charge (PXE UEFI ou BDM) | Vérifier Secure Boot et la compatibilité des certificats |
| Flux | Ports |
|---|---|
| Streaming des vDisks | UDP 6890 à 6909 (et 6910 pour la connexion) |
| TFTP / PXE | UDP 69 ; 67 et 4011 |
| Console et SOAP | TCP 54321 et 54322 |
| Base de données | TCP 1433 (SQL Server) |
Les vDisks
| Notion | Définition |
|---|---|
| Mode standard | Partagé, en lecture seule, avec cache d'écriture : le mode de production |
| Mode privé | Lecture / écriture par une seule machine : pour créer ou réparer une image |
| Version de maintenance | Nouvelle version démarrée en écriture par une machine de maintenance pour installer les mises à jour |
| Test puis production | La version est promue en test (machines de test) puis en production (au prochain redémarrage des cibles) |
| Fusion (merge) | Consolide les versions en une nouvelle base pour éviter une chaîne trop longue |
| Licences en volume | Propriété du vDisk « KMS » pour réarmer correctement Windows et Office |
Le cache d’écriture
| Type | Usage |
|---|---|
| RAM avec débordement sur disque (recommandé) | Écritures en mémoire, puis débordement des blocs les moins utilisés sur un disque local (format VHDX différentiel) |
| RAM seule | Très rapide, mais la machine plante si la RAM du cache est pleine |
| Sur le serveur | Déconseillé : charge disque et réseau sur les serveurs PVS |
⚠️ Piège
Prévois un disque de cache local suffisant : s'il est plein, les entrées-sorties du vDisk s'arrêtent et la machine se fige.
La RAM du cache s'ajoute à la mémoire nécessaire aux sessions : 256 Mo à 1 Go pour un bureau, 2 à 4 Go pour un serveur multisession sont des points de départ courants, à mesurer.
MCS ou PVS ?
| Critère | MCS | PVS |
|---|---|---|
| Infrastructure en plus | Aucune | Serveurs PVS, base SQL, réseau de démarrage |
| Cloud public (Azure, AWS) | Natif, recommandé | Possible mais plus complexe |
| Grand nombre de machines sur site | Stockage partagé sollicité | Très efficace, peu de stockage |
| Physique | Non | Oui (machines physiques en streaming) |
| Mise à jour d'image | Snapshot + mise à jour du catalogue | Versions de vDisk, retour arrière immédiat |
Dépanner
| Symptôme | Cause probable | Parade |
|---|---|---|
| La cible ne démarre pas | PXE / TFTP (DHCP, relais), BDM obsolète | Capturer le démarrage, mettre à jour la BDM, vérifier les options DHCP |
| Démarrage lent, nouvelles tentatives | Réseau (MTU, perte de paquets), serveur saturé | Statistiques de la cible (« retries »), répartition entre serveurs |
| Machine figée après quelques heures | Disque de cache plein | Agrandir le disque, chercher l'application qui écrit beaucoup |
| Windows non activé | Licences en volume mal configurées sur le vDisk | Mode KMS sur le vDisk, procédure de réarmement |
| vDisk différent selon le serveur | Réplication des magasins incomplète | Vérifier la réplication (console : état de réplication) |
🔷 En contexte Citrix
Dans un projet Azure, MCS est le choix naturel ; PVS reste pertinent sur site pour de très grands parcs ou des machines physiques.
Avant de mettre à jour vers Secure Boot avec les nouveaux certificats Microsoft (UEFI CA 2023), vérifie la compatibilité de ta version PVS et de la BDM.
À retenir
- Pas de disque système : démarrage réseau (PXE/TFTP ou BDM) et vDisk en flux.
- Mode standard en production, privé pour réparer ; versions maintenance → test → production.
- Cache d'écriture : RAM avec débordement sur disque, disque local suffisant.
- Ports : UDP 6890-6910, TFTP 69, SOAP 54321-54322.
- MCS pour le cloud, PVS pour les grands parcs sur site et le physique.
Auto-évaluation
Q1. Que se passe-t-il si le disque de cache d'écriture est plein ?
→ Les entrées-sorties du vDisk s'arrêtent : la machine se fige. Il faut un disque de cache suffisant.
Q2. Comment appliquer les mises à jour Windows à un vDisk sans interruption ?
→ Créer une version de maintenance, la démarrer sur une machine de maintenance, installer, promouvoir en test puis en production ; les cibles l'utilisent au redémarrage suivant.
Q3. Pourquoi utiliser la BDM plutôt que PXE ?
→ Pour ne pas dépendre de PXE/TFTP et du DHCP, notamment sur des réseaux segmentés ou contraints.
Q4. Dans quel cas PVS est-il préférable à MCS ?
→ Grands parcs sur site, machines physiques, besoin de réduire fortement le stockage.