Compatibilité du pilote VirtIO-Win avec les charges de travail MS SQL Server

Problème connu de compatibilité du pilote virtio-win affectant les VM Windows exécutant MS SQL Server sous forte charge d’E/S, y compris la version recommandée, les étapes de vérification et une procédure de rétrogradation propre.

Vue d’ensemble

Points clés

• virtio-win v0.1.285 et v0.1.292 présentent une condition de concurrence dans les vioscsi et viostor pilotes de stockage qui se manifeste sur des VM MS SQL Server fortement chargées
• v0.1.271 est la dernière version avant le commit concerné et constitue la version recommandée pour les invités Windows exécutant des charges de travail de base de données
• Les symptômes sont les plus marqués sur les Windows Server 2025 invités soumis à des E/S parallèles soutenues
• Le correctif amont a été intégré en janvier 2026 ; les versions ultérieures de virtio-win qui l'incluent devraient également être sûres — vérifiez la build avant un déploiement à grande échelle
• Prenez un instantané de la VM et arrêtez les services SQL Server avant de modifier les pilotes de stockage

Les VM Windows exécutant MS SQL Server sur VergeOS peuvent générer un flux d'entrées de journal SQL Server "read-retry" — et dans certains cas un service SQL Server bloqué après quelques jours de charge soutenue — lorsque l'invité utilise virtio-win v0.1.285 ou v0.1.292. La cause racine est une attribution non atomique d'ID SRB dans les vioscsi/viostor miniports Storport qui permet l'émission d'ID en double lorsque Windows répartit les E/S en parallèle sur plusieurs CPU (suivi en amont sous virtio-win issue #1453).

Le comportement est le plus reproductible sur Windows Server 2025 car son implémentation Storport parallélise StartIo de manière plus agressive que les versions antérieures de Windows Server. Les anciens invités Windows sont exposés au même bug, mais le déclenchent moins souvent.

Le fait de rétrograder les pilotes virtio-win de l'invité vers v0.1.271 constitue un contournement stable. Un correctif pour la condition de concurrence sous-jacente a été fusionné en amont et livré dans des builds virtio-win plus récents ; les versions ultérieures qui l'incluent devraient également être sûres — confirmez avec le support VergeOS quelles builds de votre environnement sont éprouvées avant de procéder à une mise à niveau en plein incident.

Symptômes

Si vous soupçonnez ce problème sur une VM Windows VergeOS, recherchez ce qui suit dans le Application journal d'événements et journal d'erreurs SQL Server:

• Messages read-retry où les valeurs attendue et réelle sont identiques, par exemple :

  Une lecture du fichier '*.mdf' à l'offset 0x... a réussi après 1 échec avec l'erreur : somme de contrôle incorrecte (attendue : 0xad4c6778 ; réelle : 0xad4c6778)

  Une lecture du fichier '*.mdf' à l'offset 0x... a réussi après 1 échec avec l'erreur : pageid incorrect (attendue 1:29669944 ; réelle 1:29669944)

• Aucun SRB trouvé pour l'ID entrées provenant de la vioscsi source
• Services SQL Server bloqués après plusieurs jours de charge lourde soutenue

Ces messages peuvent ressembler à une corruption mais ne le sont généralement pas

SQL Server signale le nouvelle tentative résultat, qui réussit au deuxième essai. DBCC CHECKDB revient généralement propre — les pages de la base de données sur le disque sont intactes. Le pilote fournit le mauvais tampon à la première lecture en raison de l'ID SRB en double, et la seconde lecture renvoie les bonnes données. Des nouvelles tentatives persistantes indiquent tout de même un vrai problème et doivent être traitées même lorsqu'aucune corruption n'est détectée.

Prérequis

• Une VM Windows exécutant MS SQL Server (ou une charge de travail de base de données similaire très gourmande en E/S) sur VergeOS
• Un accès administrateur à l'invité Windows
• Un instantané de la VM pris avant toute modification de pilote
• Le ISO virtio-win v0.1.271 téléchargé dans votre environnement VergeOS sous Fichiers. Les ISO archivés sont disponibles dans le archive stable-virtio sur Fedora People

Identifier la version du pilote VirtIO installée

Avant de modifier quoi que ce soit, confirmez quelle build virtio-win l'invité exécute actuellement.

1. Ouvrir le Gestionnaire de périphériques

   • Cliquez avec le bouton droit sur le menu Démarrer et sélectionnez Gestionnaire de périphériques.
2. Localiser le contrôleur de stockage VirtIO

   • Développez Contrôleurs de stockage.
   • Cliquez avec le bouton droit Contrôleur Red Hat VirtIO SCSI (pour vioscsi) ou Contrôleur Red Hat VirtIO SCSI pass-through / Périphérique de disque Red Hat VirtIO SCSI (pour viostor) et choisissez Propriétés.
3. Vérifier la version et la date du pilote

   • Passez à l'onglet Pilote .
   • Notez les champs Version du pilote et Date du pilote .
4. Recouper avec l'ISO source

   • L'empreinte de version du pilote suit un format 100.<minor>.<build>.<revision> , où le composant de révision final est construit à partir de la version de l'ISO virtio-win. Par exemple, un pilote vioscsi de virtio-win 0.1.285 se termine généralement par .28500; 0.1.271 se termine généralement par .27100.
   • Si vous ne savez pas quelle ISO a produit le pilote installé, montez l'ISO candidate dans l'invité et comparez son vioscsi.inf / viostor.inf DriverVer avec la valeur affichée dans le Gestionnaire de périphériques.

Vérifier à la fois vioscsi et viostor

Le bogue en amont affecte à la fois les pilotes vioscsi (Virtio SCSI) et viostor (Virtio block). Si la VM utilise un type de bus pour le disque système et l'autre pour les disques de données, vérifiez les deux contrôleurs.

Versions recommandées

Version	tuile
v0.1.271	Solution de contournement recommandée. Dernière version avant le commit concerné ; confirmée stable sous forte charge SQL.
v0.1.285	À éviter. Contient la vioscsi/viostor condition de concurrence sur l'ID SRB ; produit des erreurs read-retry sur les VM SQL très sollicitées.
v0.1.292	À éviter. Même défaut que v0.1.285.
Builds après le correctif amont (à partir de janv. 2026)	Devraient être sûres en principe. Confirmez la build précise avec le support VergeOS avant le déploiement.

Les téléchargements de l'ISO stable virtio-win sont disponibles dans le dépôt Fedora People stable-virtio, et les anciennes versions dans le répertoire archive-virtio.

Rétrogradation vers virtio-win v0.1.271

Prendre d’abord une capture instantanée

Avant de modifier un pilote virtio dans l'invité, prenez un instantané VergeOS de la VM. La pile de stockage est critique au démarrage — l'instantané est votre point de retour en arrière si le changement de pilote empêche Windows de monter ses disques.

1. Arrêter les services MS SQL Server dans l'invité

   • Depuis un PowerShell élevé ou la console Services, arrêtez le service SQL Server (MSSQLSERVER) et tout service dépendant éventuel (SQL Agent, texte intégral, Reporting Services, etc.) afin de mettre les E/S au repos avant de changer le pilote de stockage.
2. Monter l'ISO virtio-win v0.1.271

   • Dans VergeOS, modifiez la VM et attachez virtio-win-0.1.271.iso comme périphérique CD/DVD.
   • Confirmez que l'ISO est visible dans Windows (généralement la prochaine lettre de lecteur disponible).
3. Désinstaller les outils invités virtio-win actuels

   • Ouvrez Paramètres → Applications et fonctionnalités (ou Programmes et fonctionnalités dans le Panneau de configuration) dans l'invité.
   • Localisez Virtio-win-guest-tools et choisissez Désinstaller. Suivez les invites et redémarrez si demandé.
   • Si la désinstallation échoue ou revient en arrière avec l'erreur 0x80070643 (un problème connu lors de la suppression de virtio-win-guest-tools), utilisez l'outil Microsoft Program Install and Uninstall troubleshooter pour nettoyer l'enregistrement avant de continuer.
4. Redémarrez la VM

   • Redémarrez Windows afin que les fichiers de pilote en cours d'utilisation soient libérés. La VM devrait toujours démarrer — Windows conserve les binaires du pilote de stockage jusqu'à l'installation du nouveau package.
5. Installer virtio-win-guest-tools depuis l'ISO v0.1.271

   • Depuis l'ISO v0.1.271 montée, exécutez virtio-win-guest-tools.exe (ou virtio-win-gt-x64.msi) en tant qu'administrateur.
   • Terminez l'installation avec la sélection de composants par défaut. Cela réinstalle vioscsi, viostor, NetKVM et l'agent invité en build v0.1.271.
6. Redémarrez à nouveau la VM

   • Redémarrez Windows pour que les piles de stockage et réseau se rechargent avec les pilotes rétrogradés.
7. Vérifier la nouvelle version du pilote

   • Retournez à Gestionnaire de périphériques → Contrôleurs de stockage, ouvrez Propriétés → Pilote de l'onglet du contrôleur VirtIO, et confirmez que Version du pilote reflète maintenant la build v0.1.271 (se terminant généralement par .27100).
   • Répétez l'opération pour tout autre contrôleur VirtIO et pour la Adaptateur Ethernet Red Hat VirtIO sous Cartes réseau.
8. Démarrer les services MS SQL Server

   • Démarrez le service SQL Server et ses dépendants, puis confirmez que les bases de données s'ouvrent correctement.
9. Surveiller sous charge

   • Reprenez les charges de travail normales et surveillez le journal d'erreurs SQL Server ainsi que le journal d'application Windows pour les messages read-retry décrits ci-dessus. Un fonctionnement soutenu sans nouvelles tentatives est le critère de réussite.

Dépannage

Problèmes courants

• Le programme d'installation signale « une version plus récente est déjà installée » — Le MSI virtio-win n'effectue pas de rétrogradation sur place. Terminez l'étape de désinstallation (et redémarrez) avant d'exécuter l'installateur v0.1.271.
• La désinstallation échoue avec l'erreur 0x80070643 — Un comportement connu de virtio-win-guest-tools. Utilisez l'outil Microsoft Program Install and Uninstall troubleshooter pour effacer l'état de l'installateur en échec, redémarrez, puis réessayez l'installation v0.1.271.
• La VM ne démarre pas après le changement de pilote — Restaurez l'instantané pris dans les prérequis et recommencez la procédure en ayant d'abord complètement arrêté les services SQL Server.
• Le contrôleur de stockage affiche un point d'exclamation jaune dans le Gestionnaire de périphériques — Le pilote ne s'est pas chargé correctement. Cliquez avec le bouton droit sur le contrôleur, choisissez Mettre à jour le pilote → Parcourir mon ordinateur, puis pointez vers le dossier de l'ISO v0.1.271 correspondant à votre version de Windows (par exemple vioscsi\2k25\amd64 pour Windows Server 2025).
• Les messages read-retry persistent après la rétrogradation — Vérifiez que les deux vioscsi et viostor (quel que soit celui utilisé par la VM) affichent maintenant la build v0.1.271 dans le Gestionnaire de périphériques. Si c'est le cas et que les messages continuent, capturez un nouvel échantillon du journal d'application et du journal d'erreurs SQL Server et contactez le support VergeOS.
• Une version plus récente de virtio-win est disponible — Les versions publiées après janvier 2026 peuvent inclure le correctif amont et être un meilleur choix à long terme que de rester en v0.1.271. Confirmez la build précise avec le support VergeOS avant de la déployer sur les VM de base de données de production.

Ressources supplémentaires

• Chargement des pilotes Virtio dans la console de récupération Windows
• Bonnes pratiques pour les bases de données
• Captures instantanées et restaurations de VM
• virtio-win issue #1453 — rapport amont de la condition de concurrence de l'ID SRB
• Téléchargements ISO stables de virtio-win
• Téléchargements ISO archivés de virtio-win

Retour

Besoin d’aide ?

Si vous constatez des messages read-retry ou de l'instabilité sur une VM Windows MS SQL et que vous ne savez pas quelle version de virtio-win est installée — ou vers quelle build effectuer la mise à niveau — veuillez contacter le l’équipe de support VergeOS avant d'apporter des modifications de pilote en production.