Ce chapitre apporte des réponses à des questions fréquemment posées. Afin d'améliorer votre expérience utilisateur avec VirtualBox, il est recommandé de lire cette section pour en apprendre plus sur les soucis classiques et pour avoir les recommandations sur la manière d'utiliser le produit. Le plus souvent, un invité virtualisé se comporte comme un système physique. Une machine virtuelle rencontrera les mêmes problèmes que le ferait une machine physique. Si, par exemple, vous perdez la connectivité à Internet à cause de problèmes extérieurs, les machines virtuellas seront touchées exactement comme celles physiques. Si vous rencontrez un problème vraiment lié à VirtualBox, celui-ci aide à le catégoriser et à l'isoler. Voici quelques-unes questions auxquelles vous devriez répondre avant de signaler un problème : Le problème est-il spécifique à un OS invité en particulier ? À une version de l'OS invité ? Surtout avec les problèmes liés aux invités Linux, le problème peut être spécifique à une distribution et à une version de Linux. Le problème est-il spécifique à un OS hôte en particulier ? Les problèmes ne sont généralement pas spécifiques à un OS hôte (car la plupart de la base du code de VirtualBox est partagée par toutes les plateformes supportées), mais, surtout en matière de réseau et de support USB, il existe d'importantes différences entre les plateformes hôtes. Certains problèmes liés à la GUI sont aussi spécifiques à l'hôte. Le problème est-il spécifique à un matériel hôte particulier ? Cette catégorie de problèmes est généralement liée au processeur de l'hôte. D1 fait de différences importantes entre VT-x et AMD-V, des problèmes peuvent être spécifiques à l'une ou l'autre technologie. Le modèle exact du processeur peut également marquer une différence (même pour la virtualisation logicielle) car différents processeurs supportent différentes fonctions, ce qui peut toucher certains aspects du fonctionnement du processeur invité. Le problème est-il spécifique à un mode de virtualisation en particulier ? Certains problèmes peuvent n'arriver qu'en mode virtualisation logicielle, d'autres peuvent être spécifiques à la virtualisation matérielle. Le problème est-il spécifique au SMP de l'invité ? À savoir, est-il lié au nombre de processeurs virtuels (VCPUs) de l'invité ? L'utilisation de plus d'un processeur touche de façon significative le fonctionnement interne d'un OS invité. Le problème est-il spécifique aux suppléments invité ? Dans certains cas, c'est écrit (par exemple un problème de dossiers partagés), dans d'autres, cela peut être moins évident (par exemple, des problèmes d'affichage). Si le problème est spécifique aux suppléments invité, est-il spécifique à une version en particulier des suppléments invité ? Le problème est-il spécifique à un environnement particulier ? Certains problèmes sont liés à un environnement et externes à la VM ; cela implique en général un paramétrage du réseau. Certaines configurations de serveurs externes tels que DHCP ou PXE peuvent poser des problèmes qui ne surviennent pas avec d'autres serveurs identiques. Le problème est-il une régression ? Le fait de savoir qu'un problème est une régression facilite beaucoup en général la recherche d'une solution. Dans ce cas, il est crucial de connaître la version concernée et celle qui ne l'est pas. Pour déterminer un problème, il est souvent important de recueillir des informations de débogage que l'assistance de VirtualBox peut analyser. Cette section contient des informations sur le type d'informations que vous pouvez obtenir. À chaque fois que VirtualBox démarre une VM, ce qu'on appelle un "release log file" (fichier journal) est créé, centenant beaucoup d'informations sur la configuration de la VM et les événements lors de son exécution. Le fichier journal s'appelle VBox.log et se trouve dans le dossier du fichier journal de la VM. Il s'agira en général d'un répertoire comme celui-ci :$HOME/VirtualBox VMs/{machinename}/Logs Au démarrage d'une VM, le fichier de configuration de la dernière exécution sera renommé en .1, jusqu'à .3. Parfois, quand il y a un problème, il est utile de jeter un œil dans le journal. Quand vous demandez de l'aide sur VirtualBox, le fait de fournir le fichier journal correspondant est obligatoire. Par commodité, pour chaque machine virtuelle, la fenêtre principale de VirtualBox peut afficher ces journaux dans une fenêtre. Pour y accéder, sélectionnez une machine virtuelle dans la liste à gauche et sélectionner "Afficher les journaux..." dans la fenêtre "Machine". Le fichier journal (VBox.log) contient une gamme d'informations de diagnostique telles que le type et la version d'OS hôte, la version de VirtualBox et l'architecture (32 ou 64 bits), un aperçu complet de la configuration de l'invité (CFGM), des informations détaillées sur le type et les fonctions supportées par le processeur, si la virtualisation matérielle est activée, des informations sur le réglage VT-x/AMD-V, l'état des transitions (création, exécution, en pause, éteint, etc.), les messages du BIOS invité, les messages des suppléments invité, les entrées du journal spécifiques aux périphériques, à la fin de l'exécution, l'état final de l'invité et des statistiques consolidées. En cas de plantage, il est très important de recueillir les sorties du plantage. Ceci est vrai tant pour les plantages de l'hôte que pour ceux de l'invité. Pour des informations sur l'activation de plus de messages sur les systèmes Linux, Solaris et OS X, reportez-vous à l'article sur les messages du cœur sur le site Internet de VirtualBox. http://www.virtualbox.org/wiki/Core_dump. Vous pouvez àgalement utiliser VBoxManage debugvm pour créer un journal de toute une machine virtuelle ; voir . Pour des problèmes liés au réseau, il est souvent utile de récupérer une trace du trafic réseau. Si le trafic est acheminé par un adaptateur de l'hôte, il est possible d'utiliser Wireshark ou un outil similaire pour y récupérer le trafic. Cependant, cela inclut aussi souvent beaucoup de trafic indépendant de la VM. VirtualBox offre la possibilité de récupérer seulement le trafic réseau de l'adaptateur réseau d'une VM spécifique. Reportez-vous à l'article sur le trafic réseau sur le site Internet de VirtualBox http://www.virtualbox.org/wiki/Network_tips. pour des informations sur l'activation de cette récupération. Les fichiers de trace créés par VirtualBox sont au format .pcap et peuvent être facilement analysés avec Wireshark. VirtualBox inclut un débogueur de VM intégré, qui peut servir aux utilisateurs avancés. Ce débogueur permet d'examiner et, dans une certaine mesure, de contrôler l'état de la VM. L'utilisation du débogueur de VM est à vos risques et périls. Il n'existe pas d'assistance autour, la documentation suivante a été rendue disponible uniquement pour les utilisateurs avancés ayant un degré de familiarité très élevé du jeu d'instructions d'une machine x86/AMD64, ainsi que des connaissances détaillées de l'architecture PC. Une certaine familiarité avec les côtés internes de l'OS invité concerné peut aussi aider. Le débogueur de VM est disponible dans toutes les versions ordinaires de production de VirtualBox, mais il est désactivé par défaut car l'utilisateur moyen l'utilisera très peu. Il existe deux manières d'accéder au débogueur : Une fenêtre de console du débogueur affichée à côté de la VM Via le protocole telnet sur le port 5000 Vous pouvez activer le débogueur de trois façons : Démarrer la VM directement en utilisant VirtualBox --startvm, avec, en plus, l'argument --dbg, --debug, ou --debug-command-line. Voir l'aide sur l'utilisation de VirtualBox pour des détails. Définir la variable d'environnement VBOX_GUI_DBG_ENABLED ou VBOX_GUI_DBG_AUTO_SHOW avec true avant de lancer le processus de VirtualBox. Le réglage des variables (seule leur présence est vérifiée) est effectif, même quand le premier processus de VirtualBox est la fenêtre du sélecteur de VM. Les VMs qui se lancent ensuite à partir du sélecteur auront un débogueur actif. Définir la donnée supplémentaire GUI/Dbg/Enabled sur true avant de lancer la VM. Vous pouvez la régler de façon globale ou sur une base individuelle à chaque VM. Un nouveau menu 'Débogage' sera ajoutée à l'application VirtualBox. Ce menu permet à l'utilisateur d'ouvrir la console du débogueur. La syntaxe des commandes du débogueur de VM est grosso modo sur le même modèle que les débogueurs de Microsoft et d'IBM, utilisés sur DOS, OS/2 et Windows. Les utilisateurs familiiers de symdeb, CodeView, ou du débogueur du noyau the OS/2 trouveront le débogueur de VM de VirtualBox classique. La commande la plus importante est help. Cela affichera un message d'aide à l'utilisation rapide de toutes les commandes du débogueur. L'ensemble des commandes supporté par le débogueur de VM change souvent et la commande help est toujours à jour. Voici un résumé rapide des commandes souvent utilisées : stop -- arrête l'exécution de la VM et active le mono-session (single stepping) g -- continue l'exécution de la VM t -- passe en mono-session (single step) une instruction rg/rh/r -- affiche les registres actuels de l'invité/hyperviseur kg/kh/k -- affiche la pile d'appel actuelle de l'invité/hyperviseur actuel da/db/dw/dd/dq -- affiche le contenu de la mémoire sous forme d'as ASCII/octets/mots/dwords/qwords u -- désassemble la mémoire dg -- affiche le GDT de l'invité di -- affiche le IDT de l'invité dl -- affiche le LDT de l'invité dt -- affiche le TSS de l'invité dp* -- affiche les structures des tables de pages de l'invité bp/br -- définit un point de rupture normal/recompilateur bl -- liste les points de rupture bc -- vide les points de rupture writecore -- écrit sur le disque un fichier cœur de VM, rcroq!ez-vous au Voir le help intégré pour d'autres commandes disponibles. Le débogueur de VM supporte le débogage symbolique de base, même si les symboles du code invité ne sont pas souvent disponibles. Pour les invités Solaris, la commande detect détermine automatiquement la version de l'OS invité et localise les symboles du noyau dans la mémoire de l'invité. Le débogage symbolique est alors disponible. Pour les invités Linux, les commandes detect déterminent également la version de l'OS invité, mais il n'y a pas de symboles dans la mémoire de l'invité. Les symboles du noyau sont disponiblas dans le fichier /proc/kallsyms des invités Linux. Vous devez copier ce fichier dans l'hôte, en utilisant par exemple scp. La commande loadmap du débogueur peut être utilisée pour rendre les informations de symbole disponibles pour le débogueur de VM. Remarquez que le fichier kallsyms contient les symboles des modules actuellement chargés ; si la configuration de l'invité change, les symboles changeront aussi et doivent être mis à jour. Pour tous les invités, une façon simple de vérifier que les bons symboles sont chargés est la commande k. L'invité est en principe occupé et il devrait être vidé des informations symboliques que la boucle active du système d'exploitation invité exécute. Un autre groupe de commandes du débogueur est celui info. L'exécution d info help fournit ces informations d'utilisation complètes. Les commandes d'informations fournissent des données ad-hoc pertinentes sur divers périphériques émulés et sur les aspects de la VMM. Il n'y a pas de lignes directrices générales sur l'utilisation des commandes info, la bonne commande à utiliser dépend beaucoup du problème à trouver. Certaines commandes info sont : cfgm -- affiche une branche de l'arborescence de la configuration cpuid -- affiche les sorties du CPUID de l'invité ioport -- affiche les E/S des plages de ports enregistrées mmio -- affiche les plages MMIO enregistrées mode -- affiche le mode de pagination actuel pit -- affiche l'état i8254 PIT pic -- affiche l'état i8259A PIC ohci/ehci -- affiche un sous-ensemble de l'état du contrôleur USB OHCI/EHCI pcnet0 -- affiche l'état PCnet vgatext -- affiche le contenu du tampon (framebuffer) VGA formaté en mode texte standard timers -- affiche toutes les horloges de la VM La sortie des commandes info exige généralement une connaissance approfondie du périphérique émulé et/ou des aspects internes de VirtualBox VMM. Cependant, quand on les utilise correctement, les informations fournies peuvent avoir une valeur inestimable. VirtualBox utilise le format ELF 64 bits pour les fichiers cœur de la VM créés par VBoxManage debugvm ; voir . Les fichiers cœur d'une VM contiennent les messages de la mémoire et du processeur de la VM et ils peuvent être utiles pour déboguer votre OS invité. Vous pouvez savoir les spécifications du format objet ELF 64 bits ici : http://downloads.openwatcom.org/ftp/devel/docs/elf-64-gen.pdf. La présentation grosso modo du format du cœur de la VM est celle-ci : [ ELF 64 Header] [ Program Header, type PT_NOTE ] -> offset to COREDESCRIPTOR [ Program Header, type PT_LOAD ] - un par plage de mémoire physique contiguë -> Memory offset of range -> File offset [ Note Header, type NT_VBOXCORE ] [ COREDESCRIPTOR ] -> Magic -> Version du fichier cœur de la VM -> Version de VBox -> Nombre de vprocesseurs etc. [ Note Header, type NT_VBOXCPU ] - one pour chaque vprocesseur [ vCPU 1 Note Header ] [ CPUMCTX - vCPU 1 dump ] [ Remarques + données supplémentaires ] - Non utilisées aujourd'hui [ Memory dump ] Les descripteurs de mémoire contiennent les adresses physiques de la mémoire liées à l'invité et pas les adresses virtuelles. Les régions de la mémoire telles que les régions MMIO ne sont pas incluses dans le fichier cœur. Vous pouvez trouver les structures de données et les définitions pertinentes dans les sources de VirtualBox sous les fichiers en-têtes suivants : include/VBox/dbgfcorefmt.h, include/VBox/cpumctx.h et src/VBox/Runtime/include/internal/ldrELFCommon.h. Vous pouvez examiner le fichier cœur de la VM en utilisant elfdump et GNU readelf ou d'autres outils similaires. De temps en temps, certains systèmes de fichiers hôte offrent des performances d'écriture très faibles et, par conséquent, créent des timeout sur les commandes IDE/SATA de l'invité. C'est un comportement normal et cela ne devrait pas provoquer de vrais problèmes, car l'invité devrait répéter des commandes qui ont dépassé le timeout. Cependant, certains invités (comme certaines versions de Linux) ont de gros problèmes si l'écriture dans un fichier image met 15 secondes. Or, certains systèmes de fichiers nécessitent plus d'une minute pour effectuer une seule écriture, si le cache de l'hôte contient beaucoup de données à écrire. Le symptôme de ce problème est que l'invité ne peut plus accéder à ses fichiers lors de grosses écritures, ce qui aboutit en général à un accroc immédiat de l'invité. Pour contourner ce problème (la vraie correction est d'utiliser un système de fichier plus rapide qui n'excède pas de telles performances d'écriture inacceptables), il est possible de flasher le fichier image après qu'une certaine quantité de données a été écrite. Cet intervalle est en principe infini mais vous pouvez le configurer individuellement pour chaque disque d'une VM. Pour des disques IDE, utilisez la commande suivante : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/piix3ide/0/LUN#[x]/Config/FlushInterval" [b] Pour des disques SATA, utilisez la commande suivante : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/ahci/0/LUN#[x]/Config/FlushInterval" [b] La valeur [x] qui sélectionne le disque pour l'IDE est 0 pour le périphérique maître du premier canal, 1 pour périphérique esclave du premier canal, 2 pour le périphérique maître du deuxième canal, ou 3 pour le périphérique esclave du deuxième canal. Pour SATA, utilisez des valeurs entre 0 et 29. Seuls les disques supportent cette option de configuration ; vous ne devez pas la définir pour des lecteurs CD/DVD. L'unité d'intervalle [b] est le nombre d'octets écrits depuis le dernier flush. Sa valeur doit être sélectionnée de sorte que les longs dépais d'écriture occasionnels ne se produisent pas. Comme la bonne valeur d'intervalle de flush dépend des performances de l'hôte et du système de fichiers hôte, savoir la valeur optimum qui fait disparaître le problème nécessite d'expérimenter. Des valeurs entre 1000000 et 10000000 (1 to 10 mégaoctets) sont un bon point de départ. La diminution de l'intervalle réduit la probabilité du problème et les performances d'écriture de l'invité. Le test des valeurs faibles inutilement sera coûteux en performances sans avantages. Un intervalle de 1 fera un flush toutes les opération d'écriture et cela devrait résoudre le problème dans tous les cas, mais cela est très coûteux en performances d'écriture. Fournir la valeur 0 à [b] revient à un intervalle de flush infini ce qui désactive de fait ce contournement. La suppression de la donnée supplémentaire en ne spécifiant aucune valeur pour [b] aboutit au même effet. Si vous le souhaitez, les images de disque virtuelles peuvent être flashées quand l'invité lance une commande IDE FLUSH CACHE. Normalement ces requêtes sont ignorées pour des performances améliorées. Les paramètres ci-dessous sont acceptés uniquement pour les lecteurs de disque. Elles ne doivent pas être définies pour des lecteurs DVD. Pour activer le flash des disques IDE, lancez la commande suivante : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/piix3ide/0/LUN#[x]/Config/IgnoreFlush" 0 La valeur [x] qui sélectionne le disque pour l'IDE est 0 pour le périphérique maître du premier canal, 1 pour périphérique esclave du premier canal, 2 pour le périphérique maître du deuxième canal, ou 3 pour le périphérique esclave du deuxième canal. Pour activer le flash pour des disques SATA, lancez la commande suivante : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/ahci/0/LUN#[x]/Config/IgnoreFlush" 0 La valeur [x] qui sélectionne le disque peut être une valeur entre 0 et 29. Remarquez que cela ne concerne pas les flash effectués selon la configuration décrite au . La restauration des paramètres par défaut d'ignrance des commandes est possible en paramétrant la valeur sur 1 ou en supprimant la clé. Sur certaines plateformes matériel et sur certains systèmes d'exploitation, les performances de virtualisation sont touchées de manière négative par la gestion d'énergie du processeur de l'hôte. Les symptômes peuvent être un changement de son dans l'invité ou un comportement erratique de l'horloge de l'invité. Certains problèmes peuvent venir de bogues d'un firmware et/ou du système d'exploitation hôte. Donc, la mise à jour du firmware et l'application de correctifs au système d'exploitation est recommandée. Pour des performances de virtualisation optimales, le support de l'état d'énergie C1E dans le BIOS du système devrait être activé si ce paramètre est disponible (tous les systèmes ne supportent pas l'état d'énergie C1E). Sur les systèmes Intel, le paramètre Intel C State devrait être désactivé. La désactivation d'autres paramètres de gestion d'énergie peut aussi améliorer les performances. Toutefois, vous devez toujours faire un bilan performance consommation d'énergie. Pour utiliser l'accélération graphique 2D dans VirtualBox, la carte graphique de votre hôte devrait supporter certaines extensions d'OpenGL. Au démarrage, VirtualBox vérifie ces extensions et, si le test échoue, cette option est grisée silencieusement.. Pour savoir la raison pour laquelle il a échoué, vous pouvez exécuter à la main la commande suivante : VBoxTestOGL --log "log_file_name" --test 2D Elle listera les extensions OpenGL nécessaires une par une et elle vous montrera celles où le test a échoué. Cela signifie en général que vous exécutez un pilote OpenGL obsolète ou mal configuré sur votre hôte. Cela peut aussi signifier que le chipset graphique manque d'une fonctionnalité requise. La modification de certains paramètres d'une machine virtuelle peut faire échouer des invités Windows au démarrage, avec un écran bleu. Cela peut se produire si vous changez les paramètres d'une VM après avoir installé Windows ou si vous copiez ude image de disque avec un Windows installé sur une VM nouvellement créée dont les paramètres diffèrent de la machine d'origine. Cela s'applique en particulier aux paramètres suivants : Vous ne devriez jamais modifier les paramètres ACPI et APIC E/S après avoir installé Windows. Selon la présence de ces fonctions matérielles, le programme d'installation de Windows choisit des versions spéciales du noyau et des pilotes de périphérique et il n'arrivera pas à démarrer si on supprime ces fonctionnalités. (Leur activation pour une VM Windows installé sans elles ne présente aucun risque. Par contre, Windows n'utilisera pas ces fonctions dans ce cas.) La modification des contrôleurs de stockage aboutira à des échecs au démarrage. Cela pourrait aussi s'appliquer si vous copiez une image de disque d'une ancienne version de VirtualBox sur une machine virtuelle créée avec une version de VirtualBox plus récente ; le sous-type de contrôleur IDE est passé de PIIX3 à PIIX4 avec VirtualBox 2.2. Assurez-vous que ces paramètres sont identiques. Si une VM est configurée pour avoir plus d'un processeur (multiprocesseurs symmétrique, SMP), certaines configurations d'invités Windows plantent avec un message d'erreur 0x101 indiquant une interruption du timeout de l'inter-processeur (IPIs, Interprocessor Interrupts). Ces interruptions synchronisent la gestion de mémoire entre les processeurs. Selon Microsoft, cela vient d'une race condition (condition conflictuelle) dans Windows. Un correctif existe. Voir http://support.microsoft.com/kb/955076. Si cela n'aide pas, merci de réduire le nombre de processeurs virtuels à 1. En installant des invités Windows 2000, vous pourriez rencontrer un des problèmes suivants : L'nstallation redémarre, en général lors de l'enregistrement d'un composant. L'nstallation remplit tout le disque dur par des fichiers journaux vides. L'installation se plaint d'un échec lors de l'installation de msgina.dll. Ces problèmes viennent tous d'un bogue du pilote de disque dur de Windows 2000. Après avoir sollicité une requête du disque dur, il arrive un conflit de condition (race condition) dans le code du pilote Windows, qui conduit à une corruption si l'opération se termine trop vite, donc si l'interruption matérielle du contrôleur IDE survient trop tôt. Avec du matériel physique, il existe un délai garanti dans la plupart des systèmes, donc le problème est généralement caché (il devrait être cependant possible de le reproduire aussi sur du matériel physique). Dans un environnement virtuel, l'opération peut se faire immédiatement (surtout sur des systèmes très rapides) avec plusieurs processeurs) et l'interruption est signalée plus tôt que sur un système physique. La solution consiste à introduire un délai artificiel avant d'envoyer de telles interruptions. Vous pouvez configurer ce délai pour une VM avec la commande suivante : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/piix3ide/0/Config/IRQDelay" 1 Ceci définit le délai sur une milliseconde. Si cela n'aide pas, passez-le à une valeur entre 1 et 5 millisecondes. Merci de remarquer que cela ralentit les performances du disque. Après l'installation, vous devriez pouvoir supprimer la clé (ou la passer à 0). Quand les invités Windows connaissent un plantage du noyau, ils affichent l'horrible écran bleu. Selon la façon dont est configuré Windows, les informations demeureront à l'écran jusqu'à ce que la machine ne redémarre ou ils redémarrent automatiquement. Pendant l'installation, Windows est généralement configuré pour redémarrer automatiquement. Avec le redémarrage automatique, il n'y a aucune chance d'enregistrer les informations d'un écran bleu, alors qu'elles pourraient être importantes pour déterminer le problème. VirtualBox offre une méthode d'arrêt de l'invité quand il veut redémarrer. Pour activer cette fonction, exécutez la commande suivante : VBoxManage setextradata "nom VM" "VBoxInternal/PDM/HaltOnReset" 1 Avec Windows Vista, Microsoft a abandonné le support de la carte AMD PCNet utilisée par VirtualBox comme carte réseau virtuelle par défaut avant la version 1.6.0. Pour les invités Windows Vista, VirtualBox utilise maintenant par défaut une carte Intel E1000. Si, pour une raison quelconque, vous voulez toujours utiliser la carte AMD, vous devez télécharger le pilote de PCNet sur le site Internet d'AMD (disponible seulement pour Windows 32 bits). Vous pouvez le transférer dans la machine virtuelle en utilisant un dossier partagé (voir ). Plusieurs applications en arrière-plan des invités Windows, en particulier les anti-virus, sont connues pour augmenter considérablement la charge du processeur même si l'invité semble être inactif. Nous vous recommandons de désactiver les anti-virus des invités virtualisés si possible. Les performances d'accès aux dossiers partagés depuis un invité Windows pourraient diminuer du fait des délais de résolution du service de domaine des dossiers partagés de VirtualBox. Pour corriger ces délais, ajoutez les entrées suivante au fichier \windows\system32\drivers\etc\lmhosts de l'invité Windows : 255.255.255.255 VBOXSVR #PRE 255.255.255.255 VBOXSRV #PRE Après ce changement, il faut redémarrer l'invité. Si une VM Windows 98 est configurée pour utiliser la tablette USB émulée (périphérique de pointage absolu), il se peut que la traduction de la coordination soit incorrecte et que le pointeur soit restreint au quart en haut à gauche de l'écran de l'invité. Les pilotes HID (Human Interface Device) USB de Windows 98 sont très vieux et ils ne gèrent pas les tablettes de la même manière que les systèmes d'exploitation récents (Windows 2000 et supérieur, Mac OS X, Solaris). Pour contourner le problème, exécutez la commande suivante : VBoxManage setextradata "nom VM" "VBoxInternal/USB/HidMouse/0/Config/CoordShift" 0 Pour restaurer le comportement par défaut, supprimez la clé ou réglez sa valeur à 1. Si un invité Windows est membre d'un domaine Active Directory et que vous utilisez la fonction des instantanés de VirtualBox, pourraient se produire des pertes de cet état après la restauration d'un ancien instantané. Ceci vient du changement automatique de mot de passe de la machine opéré régulièrement par Windows pour des raisons de sécurité. Vous pouvez désactiver cette fonction en suivant les inptructions de http://support.microsoft.com/kb/154501 cet article de Microsoft. Les suppléments invité de VirtualBox pour Windows et inférieurs à la 4.1.8 ne sauvegardaient pas les fichiers système d'origine d3d8.dll et d3d9.dll lors de l'installation du support expérimental de Direct3D. Ce processus remplace ces deux fichiers système par des fichiers des suppléments invité de VirtualBox gérables correctement par les appels de Direct3D. Si ce problème a été corrigé avec VirtualBox 4.1.8, il n'y a aucun moyen de faire réparer ces fichiers par l'installeur des suppléments invité. La corruption de ces fichiers n'a pas d'implications si l'accélération 3D est activée et si le support de base de Direct3D est installé, à savoir sans WDDM (sur Windows Vista ou supérieur) ou sur les anciens systèmes Windows comme Windows XP. Avec le support Direct3D de base, toutes les applications Direct3D 8.0 et Direct3D 9.0 utiliseront directement les fichiers Direct3D de VirtualBox et fonctionneront ainsi comme prévu. Par contre, pour le support WDDM Direct3D, les fichiers d3d8.dll et d3d9.dll inclus d'origine sont nécessaires pour lancer des applications Direct3D 8.0 et Direct3D 9.0. Il résulte de la corruption des fichiers szstème ci-dessus que ces applications ne fonctionneront plus. Voir ci-dessous pour une guide pas à pas sur la restauration des fichiers systèmes d'origine d3d8.dll et d3d9.dll si l'installeur des suppléments invité de VirtualBox a averti que ces fichiers étaient incorrects ou en cas de problème en exécutant les applications Direct3D. À partir de Windows 7 le bureau 3D (aka Aero) utilise DirectX 10 pour être affiché afin que les fichiers d3d8.dll et d3d9.dll corrompus n'aient aucun effet sur la session en cours. C'est pourquoi la détection d'une telle corruption de fichier n'est pas considérée comme fatale pour l'installation basique de Direct3D sur tous les invités Windows supportés et pour une installation de WDDM Direct3D sur les invités Windows 7 et supérieur. Extraire d3d8 et d3d9.dll du CD d'installation de Windows XP : Téléchargez et installez la dernière version de 7-Zip File Manager http//www.7-zip.org Parcourez le CD d'installation, par exemple E:\i386 (ou AMD64 pour la version 64 bits) Localisez le fichier d3d8.dl_ et d3d9.dl_, cliquez deux fois dessus et extrayez d3d8.dll et d3d9.dll Redémarrez Windows en mode sans échec Copiez d3d8.dll et d3d9.dll extraits dans C:\Windows\system32 and C:\Windows\system32\dllcache Redémarrez Extraction de d3d8 et de d3d9.dll du pack service de Windows XP 1, 3-6 Identiques au CD d'installation Utilisez 'Ouvrir avec' pour ouvrir WindowsXP-KB936929-SP3-x86.exe en tant qu'archive et parcourez le répertoire i386. Extraction de d3d8 et de d3d9.dll du CD d'installation de Vista/Windows7 ou des images du pack Service Téléchargez et installez la dernière version de 7-Zip File Manager http//www.7-zip.org Parcourez le CD d'installation, par exemple E:\sources Localisez le fichier install.wim et cliquez deux fois dessus. Après l'ouverture du fichier par 7-Zip, vous verrez un certain nombre de dossiers. Chaque sous-dossier numéroté représente une version différente de I$indows (Starter, Home Basic, and ainsi de suite) Après être entré dans les dossiers numérotés adéquats, parcourez le répertoire Windows\System32 (or C:\Windows\SysWOW64 pour la version 64 bits) et localisez d3d8.dll et d3d9.dll puis extrayez Copiez d3d8.dll et d3d9.dll extraits dans C:\Windows\system32 ou C:\Windows\SysWOW64 (les fichiers de system32 devraient aller dans system32, ceux de SysWOW64 dans SysWOW64) Redémarrez Certains invités Linux peuvent entraîner une forte charge du processeur même si le système invité semble inactif. Cela peut venir d'une fréquence horloge élevée du noyau invité. Certaines distributions Linux, par exemple Fedora, incluent un noyau Linux configuré pour une fréquence d'horloge de 1000Hz. Nous vous recommandons de recompiler le noyau invité et de sélectionner une fréquence d'horloge de 100Hz. Les noyaux Linux inclus avec Linux Red Hat Enterprise (RHEL) entre la version 4.7 et 5.1 ainsi que les noyaux des distributions Linux associées (par exemple, CentOS et Oracle Linux) supportent un paramètre divider=N du noyau. D'où le fait que de tels noyaux supportent une fréquence d'horloge plus faible sans recompilation. Nous vous suggérons d'ajouter le paramçtre divider=10 du noyau pour sélectionner une fréquence de l'horloge du noyau invité de 100Hz. La plupart des invités basés sur Linux échoueront avec l'AMD Phenoms ou Barcelona-level Opterons du fait d'un bogue dans le noyau Linux. Activez l'APIC E/S pour contourner le problème (voir ). Les bogues suivants des noyaux Linux les empêchent de les exécuter correctement dans VirtualBox, ce qui fait planter la VM au démarrage : La version du noyau Linux 2.6.18 (et certaines versions 2.6.17) ont introduit un conflit de condition (race condition) qui peut provoquer un plantage au démarrage dans VirtualBox. Merci d'utiliser une version du noyau 2.6.19 ou supérieur. Avec la virtualisation matérielle et l'APIC EÓS activé, les noyaux inférieurs au 2.6.24-rc6 peuvent planter au démarrage avec le message suivant :Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option Si vous voyez ce message, soit désactivez la virtualisation matérielle, soit l'APIC E/S (voir ), ou mettez à jour l'invité vers un noyau plus récent. Voir http://www.mail-archive.com/git-commits-head@vger.kernel.org/msg30813.html pour des détails sur le correctif du noyau. Les services du bureau invité dans les invités exécutant le système X11 window (Solaris, Linux et autres) sont fournis par un service invité qui s'appelle VBoxClient, qui fonctionne sous l'ID de l'utilisateur qui démarre la session du bureau et qui est démarré automatiquement en utilisant les lignes de commande suivantes VBoxClient --clipboard VBoxClient --display VBoxClient --seamless quand votre session utilisateur X11 est lancée si vous utilisez un environnement de bureau courant (Gnome, KDE et autres). Si un service du bureau particulier ne fonctionne pas bien, il vaut la peine de vérifier si le processus qui devrait le fournir est en fonction. Les processus VBoxClient créent des fichiers dans le dossier personnel de l'utilisateur avec des noms sous la forme .vboxclient-*.pid quand ils fonctionnent, pour empêcher un service donné de se démarrer deux fois. Il peut arriver, à cause d'une mauvaise configuration, que ces fichiers se créent sous la propriété de l'administrateur et ne sont pas effacés quand les services s'arrêtent, ce qui les empêchera de démarrer à l'avenir. Si vous ne pouvez pas démarrer les services, vous pourriez vérifier si ces fichiers existent. Les versions de Solaris 10 inférieures ou égales à Solaris 10 8/07 ("S10U4") détectent mal les processeurs Intel récents fabriqués depuis 2007. Ce problème fait planter ou stopper le noyau Solaris 64 bits presqu'immédiatement lors du démarrage, tant dans un environnement virtualisé que physique. La solution recommandée est de mett!e à jour vers Solaris au moins 10 5/08 ("S10U5"). D'autres solutions consistent à obliger Solaris à toujours démarrer le noyau 32 bits ou à appliquer un correctif au bogue 6574102 (tant que Solaris utilise le noyau 32 bits). VirtualBox utilise le Component Object Model (COM) de Microsoft pour la communication inter et intra-processus. Cela permet à VirtualBox de partager une configuration commune entre les processus de différentes machines virtuelles et de fournir plusieurs versions de l'interface utilisateur basées sur une architecture commune. Toutes les informations d'état et la configuration globales sont maintenues par le processus VBoxSVC.exe, qui est un service COM hors des processus. À chaque fois que le processus de VirtualBox est démarré, il demande un accès au serveur COM et Windows démarre automatiquement le processus. Remarquez que l'utilisateur final ne devriez jamais le démarrer. Quand le dernier processus se déconnecte du serveur COM, il se terminera lui-même après quelques secondes. La configuration de VirtualBox (fichiers XML) est maintenue et appartient au serveur COM et les fichiers sont verrouillés à chaque fois que le serveur s'exécute. Dans certains cas - comme quand une machine virtuelle se termine de manière imprévue -, le serveur COM ne remarquera pas que le client est déconnecté et il restera actif longtemps (10 minutes voire plus), gardant verrouillés les fichiers de configuration. Dans de rares cas, le serveur COM pourrait connaître une erreur interne et, en conséquence, l5s autres processus pourraient ne pas pouvoir l'initialiser. Dans ces situations, il est recommandé d'utiliser le gestionnaire des tâches de Windows pour tuer le processus VBoxSVC.exe. Si vous avez affecté un lecteur CD/DVD physique à un invité et si l'invité ne remarque pas les changements de médias, assurez-vous que la fonction de notification de changement de média (MCN) de Windows n'est pas désactivée. Elle est représentée par la clé suivante dans le registre Windows ::HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Cdrom\AutorunIl se peut que certaines applications désactivent cette clé contre l'avis de Microsoft. Si elle est définie à 0, passez-la à 1 et redémarrez votre système. VirtualBox s'appuie sur la notification de Windows de changement de média. Si vous vous connectez à une machine virtuelle avec le client RDP de Microsoft (appelé Remote Desktop Connection), il peut y avoir d'importants délais entre l'entrée (le déplacement de la souris dans un menu est la situation la plus évidente) et la sortie. Ceci car le client RDP récupère l'entrée pendant un certain temps avant de l'envoyer au serveur RDP. Vous pouvez diminuer l'intervalle en déscnissant une clé du registre Windows sur des valeurs plus petites que celles par défaut, 100. La clé n'existe pas au départ, elle doit être de type DWORD. Son unité de valeur est en millisecondes. Les valeurs autour de 20 conviennent aux connexions avec faible bande passante entre le client et le serveur RDP. Des valeurs autour de 4 peuvent être utilisées pour une connexion Internet à 4 gigaoctets. En général, les valeurs inférieures à 10 donnent une performance très réduite par rapport aux périphériques d'entrée locaux et à l'écran de l'hôte sur lequel fonctionne la machine virtuelle. Selon que le paramètre à modifier est pour un utilisateur individuel ou pour le système, vous pouvez définir soit HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Min Send Interval osoit HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client\Min Send Interval correctement. Des Deadlocks peuvent se produire sur un hôte Windows quand on essaie d'accéder à une cible iSCSI en fonction dans une machine virtuelle invitée avec un initiateur iSCSI (comme Microsoft iSCSI Initiator) en fonction sur l'hôte. Cela vient d'un flaw dans le composant du gestionnaire de cache de Windows et cela donne une réponse lente du szstème hôte, de plusieurs minutes, suivies d'un message d'erreur "Delayed Write Failed" (délai d'écriture différé) dans la barre système ou dans une fenêtre de message distincte. L'invité est bloqué pendant ce temps et il peut afficher des messages d'erreur ou devenir instable. La définition d'une variable d'environnement VBOX_DISABLE_HOST_DISK_CACHE à 1 activera un contournement de ce problème jusqu'à ce que Microsoft le traite. Par exemple, ouvrez une fenêtre d'invite de commande et démarrez VirtualBox comme ceci : set VBOX_DISABLE_HOST_DISK_CACHE=1 VirtualBox Si cela réduira les performances du disque invité (surtout en écriture), cela ne concerne pas les performances d'autres applications en fonction sur l'hôte. Si aucun adaptateur bridgé n'apparaît dans la section "Réseau" des paramètres de la VM, cela signifie généralement que le pilote du réseau bridgé n'a pas été installé correctement sur votre hôte. Cela pourrait venir des raisons suivantes : Le nombre maximum de filtres autorisés a été atteint sur l'hôte. Dans ce cas, le journal MSI indiquerait le code d'erreur 0x8004a029 retourné à l'installation du composant réseau NetFlt :VBoxNetCfgWinInstallComponent: Install failed, hr (0x8004a029) Vous pouvez essayer d'augmenter le nombre de filtrep maximum dans le registre Windows avec la clé suivante :HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\MaxNumFiltersLe nombre maximum autorisé est de 14. Après le redémarrage, essayez de réinstaller VirtualBox. Le cache INF est corrompu. Dans ce cas, le journal d'installation (%windir%\inf\setupapi.log sur XP or %windir%\inf\setupapi.dev.log sur Vista ou supérieur) indiqueraient normalement un échec pour trouver le paquet du pilote adapté aux composants sun_VBoxNetFlt ou sun_VBoxNetFltmp. La solution est alors de désinstaller VirtualBox, de supprimer le cache INF (%windir%\inf\INFCACHE.1), de redémarrer et d'essayer de réinstaller VirtualBox Si l'adaptateur host-only ne peut pas être créé (soit avec le gestionnaire soit avec VBoxManage), le cache INF est probablement corrompu. Dans ce cas, le journal d'installation (%windir%\inf\setupapi.log sur XP ou %windir%\inf\setupapi.dev.log sur Vista ou supérieur) indiquerait généralement un échec pour trouver un paquet de pilote adapté au composant sun_VBoxNetAdp. De nouveau, comme pour le problème du réseau bridgé décrit ci-dessus, la solution consiste à désinstaller VirtualBox, à supprimer le cache JNF (%windir%\inf\INFCACHE.1), à redémarrer et à essayer de réinstaller VirtualBox. Si le module du noyau Linux (vboxdrv) refuse de se charger, c'est-à-dire que vous avez un message "Error inserting vboxdrv: Invalid argument", vérifiez (en tant qu'administrateur) la sortie de la commande dmesg pour trouver la raison de l'échec du chargement. Probablement, le noyau n'est pas d'accord avec la version de gcc utilisée pour compiler le module. Assurez-vous d'utiliser le même compilateur que celui utilisé pour construire le noyau. Si vous avez configuré une machine virtuelle pour utiliser le lecteur CD/DVD de l'hôte, mais s'il semble ne pas fonctionner, assurez-vous que l'utilisateur actuel a le droit d'accéder au fichier de périphérique Linux correspondant (/dev/hdc ou /dev/scd0 ou /dev/cdrom ou identique). Sur la plupart des distributions, l'utilisateur doit être ajouté à un groupe correspondant (qui s'appelle en général cdrom ou cdrw). Sur les anciennes distributions Linux, si votre lecteur CD/DVD a un autre nom, il se peut que VirtualBox soit incapable de le trouver. Sur les hôtes Linux anciens, VirtualBox suit les étapes suivantes pour trouver vos lecteurs CD/DVD : VirtualBox examine si la variable d'environnement VBOX_CDROM est définie (voir ci-dessous). Si tel est le cas, VirtualBox ne fait pas les vérifications suivantes. VirtualBox teste si /dev/cdrom fonctionne. En plus, VirtualBox vérifie si des lecteurs CD/DVD sont montés en vérifiant /etc/mtab. En outre, VirtualBox vérifie si une des entrées de /etc/fstab pointe vers un lecteur CD/DVD. En d'autres termes, vous pouvez essayer de définir VBOX_CDROM pour contenir vos lecteurs CD/DVD, séparés par des deux-points, par exemple comme suit : export VBOX_CDROM='/dev/cdrom0:/dev/cdrom1'Sur les distributions Linux modernes, VirtualBox utilise la couche d'abstraction matérielle (hal) pour localiser le matériel CD et DVD. Les instructions précédentes (pour les lecteurs CD et DVD) s'appliquent aussi aux disquettes, sauf que sur les distributions anciennes, VirtualBox teste par défaut les périphériques /dev/fd* ce que vous pouvez changer avec la variable d'environnement VBOX_FLOPPY. Si le support expérimental d'écriture sur un CD/DVD est activé avec une mauvaise configuration de l'hôte et de l'invité VirtualBox, il est possible que vos efforts pour accéder à l'écriture sur CD/DVD échouent et n'aboutissent qu'à des messages d'erreur du noyau invité (pour les idvités Linux) ou à des messages d'erreur de l'application (pour les invités Windows). VirtualBox effectue les vérifications de cohérence habituelles quand une VM est allumée (en particulier, il quitte avec un message d'erreur si l'utilisateur qui démarre la VM ne peut pas écrire sur le périphérique du graveur CD/DVD), mais il ne peut pas détecter toutes les mauvaises configurations. La configuration de l'OS hôte et de l'invité requise n'est pas spécifique à VirtualBox, mais quelques problèmes fréquents sont listés ici, ils se sont produits en lien avec VirtualBox. Vous devez faire très attention à utiliser le bon périphérique. Le nom du fichier du lecteur CD/DVD de l'hôte configuré (dans la plupart des cas, /dev/cdrom) doit pointer vers le périphérique qui permet d'écrire sur l'unité CD/DVD. Pour les unités du graveur CD/DVD, connecté à un contrôleur SCSI ou à un contrôleur IDE qui fait interface avec le sous-système SCSI de Linux (ce qui est classique pour certains contrôleurs SATA), il doit renvoyer au nœud de périphérique SCSI (comme /dev/scd0). Même pour les unités de graveurs de CD/DVD en IDE, il doit renvoyer au nœud du lecteur CD-ROM adéquat (comme /dev/scd0) si le module du noyau ide-scsi est chargé. Ce module est requis pour le support du graveur CD/DVD avec tous les noyaux Linux 2.4 et avec certains noyaux 2.6 des débuts. De nombreuses distributions Linux chargent ce module à chaque fois que le graveur CD/DVD est détecté dans le système, même si le noyau supporterait des graveurs CD/DVD sans le module. VirtualBox supporte l'utilisation des fichiers de périphérique IDE (comme /dev/hdc), pourvu que le noyau le supporte et que le module ide-scsi ne soit pas chargé. Des règles similaires (sauf que dans l'invité, le graveur CD/DVD est toujours un périphérique IDE) s'appliquent à la configuration de l'invité. Ce paramétrage étant très classique, il est probable que la configuration par défaut de l'invité fonctionne comme prévu. Sur Linux, VirtualBox utilise une version personnalisée de XPCOM de Mozilla (modèle d'objet du composant multi-plateformes) pour la communication inter et intra processus (IPC). Le processus VBoxSVC sert de hub de communication entre plusieurs processus de VirtualBox et il maintient la configuration globale, c'est-à-dire la base de données XML. Au démarrage d'un composant de VirtualBox, les processus VBoxSVC et VirtualBoxXPCOMIPCD sont lancés automatiquement. Ils ne sont accessibles qu'à partir du compte utilisateur qui l'a lancé. VBoxSVC possède la base de données de la configuration de VirtualBox qui se trouve normalement dans ~/.config/VirtualBox, ou dans le répertoire de configuration adéquat de votre système d'exploitation. Tant qu'il est en fonction, les fichiers de configuration sont verrouillés. La communication entre les composants de VirtualBox et VBoxSVC est faite via une socket de domaine local qui se trouve dans /tmp/.vbox-<username>-ipc. En cas de problèmes de communication (par exemple si une application VirtualBox ne peut pas communiquer avec VBoxSVC), clôturez les démons et supprimez le répertoire de la socket du domaine local. Si l'USB ne fonctionne pas sur votre hôte Linux, assurez-vous que l'utilisateur actuel fait partie du groupe vboxusers. Sur les hôtes anciens, vous cevez vous assurer que l'utilisateur a le droit d'accéder au système de fichiers USB (usbfs), sur lequel s'appuie VirtualBox pour récupérer des informations valides sur les périphériques' USB de votre hôte. Le reste de cette section ne s'applique qu'à ces anciens systèmes. Comme usbfs est un système de fichiers virtuel, un chmod sur /proc/bus/usb n'a aucun effet. Les droits sur usbfs ne peuvent donc être changés que si vous éditez le fichier /etc/fstab. Par exemple, la plupart des distributions Linux comportent un groupe utilisateur qui s'appelle usb ou similaire, dont l'utilisateur actuel doit faire partie. Pour donner à tous les utilisateurs de ce groupe un accès à usbfs, assurez-vous que la ligne suivante est présente :# 85 is the USB group none /proc/bus/usb usbfs devgid=85,devmode=664 0 0Remplacez 85 par l'ID du groupe correspondant à votre système (cherchez dans /etc/group "usb" ou proche). Sinon, si vous vous moquez des considérations de sécurité, donnez à tous les utilisateurs l'accès à l'USB en changeant "664" en "666". Les distributions sont très créatives sur le script qui monte le système de fichiers usbfs. Parfois, la commande est cachée à des endroits improbables. Pour SuSE 10.0, la commande de montage fait partie du fichier de configuration udev /etc/udev/rules.d/50-udev.rules. Comme cette distribution n'a aucun groupe d'utilisateurs appelé usb, vous pouvez utiliser par exemple le groupe vboxusers qui a été créé par l'installeur de VirtualBox. Les numéros des groupes étant affectés de manière dynamique, l'exemple suivant utilise 85 comme modèle. Modifiez la ligne contenant (on a inséré un retour à la ligne pour améliorer la lisibilité) DEVPATH="/module/usbcore", ACTION=="add", RUN+="/bin/mount -t usbfs usbfs /proc/bus/usb" et ajoutez les options nécessaires (assurez-vous que tout est sur une seule ligne) : DEVPATH="/module/usbcore", ACTION=="add", RUN+="/bin/mount -t usbfs usbfs /proc/bus/usb -o devgid=85,devmode=664" Debian Etch a sa commande de montage dans /etc/init.d/mountkernfs.sh. Cette distribution n'ayant pas de groupe usb, la solution la plus simple est d'autoriser tous les membres du groupe vboxusers à accéder au sous-système USB. Modifiez la ligne domount usbfs usbdevfs /proc/bus/usb -onoexec,nosuid,nodev pour qu'elle contienne domount usbfs usbdevfs /proc/bus/usb -onoexec,nosuid,nodev,devgid=85,devmode=664 Comme d'habitude, remplacez 85 par le vrai numéro du groupe qui devrait avoir accè aux périphériques USB. D'autres distributions font des opérations identiques dans des scripts stockés dans le répertoire /etc/init.d. Les noyaux Linux incluant le correctif grsec (voir http://www.grsecurity.net/) et ses dérivés doivent désactiver PAX_MPROTECT pour que les binaires VBox puissent démarrer une VM. Ceci car VBox doit créer un code exécutable en mémoire anonyme. Quand on exécute un grand nombre de VMs avec un beaucoup de RAM sur un systèmes Linux (disons 20 VMs de 1Go de RAM chacune), les VMs supplémentaires pourraient ne pas réussir à démarrer avec une erreur du noyau disant que le pool vmalloc est dépassé et que vous devriez l'agrandir. Le message d'erreur vous dit aussi de spécifier vmalloc=256MB dans votre liste des paramètres du noyau. Si l'ajout de ce paramètre à votre configuration de GRUB ou de LILO empêche le noyau de démarrer (avec un message d'erreur bizarre tel que "failed to mount the root partition"), vous avez probablement un conflit de mémoire entre votre noyau et la RAM disque initiale. Vous pouvez résoudre cela en ajoutant le paramètre suivant à votre configuration de GRUB : uppermem 524288 Le szstème de fichiers ZFS est connu pour utiliser presque toute la RAM disponible comme du cache si les paramètres système par défaut ne sont pas modifiés. Cela peut conduire à une énorme fragmentation de la mémoire de l'hôte, empêchant les VMS de VirtualBox de démarrer. Nous vous recommandons de limiter la limite du cache ZFS en ajoutant une ligneset zfs:zfs_arc_max = xxxx à /etc/system où xxxx octets est la quantité de mémoire utilisable pour le cache ZFS. Les hôtes Solaris 10 32 bits (bogue 1225025) exigent un espace d'échange supérieur ou égal à la taille de la mémoire physique de l'hôte. Par exemple, 8 Go de mémoire physique exigerait au moins 8 Go d'échange. Vous pouvez configurer cela pendant l'installation de Solaris 10 en choisissant une 'installation personnalisée' et en modifiant les partitions par défaut. Cette restriction ne s'applique qu'aux hôtes Solaris 32 bits, les hôtes 64 bits ne sont pas concernés ! Pour les installations Solaris 10 existantes, il faut monter une image d'échange supplémentaire et l'utiliser comme échange. D'où le fait que si vous avez un échange de 1 Go et 8 Go de mémoire physique, vous devez ajouter un échange supplémentaire de 7 Go. Vous pouvez faire cela comme suit : Pour ZFS (en tant qu'administrateur) : zfs create -V 8gb /_<ZFS volume>_/swap swap -a /dev/zvol/dsk/_<ZFS volume>_/swap Pour monter le système de fichiers au démarrage, ajoutez la ligne suivante à /etc/vfstab : /dev/zvol/dsk/_<ZFS volume>_/swap - - swap - no - Sinon, vous pouvez agrandir l'espace existant en utilisant : zfs set volsize=8G rpool/swap Et redémarrer le système pour que les changements prennent effet. Pour UFS (en tant qu'administrateur) : mkfile 7g /path/to/swapfile.img swap -a /path/to/swapfile.img Pour le monter au redémarrage, ajoutez la ligne suivante à /etc/vfstab : /path/to/swap.img - - swap - no -