VBoxSDL est une interface graphique (GUI) simple qui élimine le support du clicodrome fourni par VirtualBox, notre principale GUI. VBoxSDL est utilisé actuellement d'abord pour déboguer VirtualBox, donc il n'est pas officiellement supporté. Vous pouvez quand même le trouver utile pour des environnements où les machines virtuelles ne sont pas nécessairement contrôlées par la même personne qui utilise la machine virtuelle. VBoxSDL n'est pas disponible sur la plateforme hôte Mac OS X. Comme pous pouvez le voir sur l'impression d'écran suivante, VBoxSDL ne fournit vraiment qu'une fenêtre simple ne contenant que la machine virtuelle "pure", sans menus ni contrôleurs sur lesquels cliquer et sans indicateurs supplémentaires sur l'activité de la VM : Pour démarrer une machine virtuelle avec VBoxSDL au lieu de l'interface graphique de VirtualBox, tapez ce qui suit sur une ligne de commanees :VBoxSDL --startvm <vm> où <vm> est, comme d'habitude dans les paramètres en ligne de commande de VirtualBox, le nom ou l'UUID d'une machine virtuelle existante. Quand vous lancez des systèmes d'exploitation invités en mode plein écran, le système d'exploitation invité a en général le contrôle de tout l'écran. Cela pourrait représenter un risque de sécurité car le système d'exploitation invité pourrait, pour l'utilisateur, lui faire croire qu'il est vraiment dans un autre système (qui pourrait avoir un haut niveau de sécurité), ou lui faire assimiler des messages à l'écran comme provenant du système d'exploitation hôte. Afin de protéger l'utilisateur contre les risques de sécurité précités, on a développpé la fonction d'étiquetage de sécurité. L'étiquetage de sécurité n'est actuellement disponible que pour VBoxSDL. S'il est activé, une partie de la zone d'affichage est réservée à une étiquette où est affiché un message défini par l'utilisateur. La hauteur de l'étiquette est définie à 20 pixels dans VBoxSDL. La couleur de la police et de l'arrière-plan de l'étiquette peuvent éventuellement être définies en valeurs de couleurs RGB hexadécimales. On utilise la syntaxe suivante pour activer l'étiquettage de sécurité : VBoxSDL --startvm "nom VM" --securelabel --seclabelfnt ~/fonts/arial.ttf --seclabelsiz 14 --seclabelfgcol 00FF00 --seclabelbgcol 00FFFF Outre l'activation de l'étiquette de sécurité, il faut fournir une police TrueType Pour utiliser uoe autre taille de police que 12 points, utilisez le paramètre --seclabelsiz. Vous pouvez définir le texte de l'étiquette avec VBoxManage setextradata "nom VM" "VBoxSDL/SecureLabel" "L étiquette" Une modification ce cette étiquette prendra effet immédiatement. En général, les résolutions du plein écran sont limitées à certaines géométries "standards" telles que 1024 x 768. Une augmentation de vingt lignes n'est en général pas faisable, donc dans la plupart des cas, VBoxSDL choisira la résolution suivante la plus élevée comme 1280 x 1024 et l'écran de l'invité ne couvrira pas toute la zone d'affichage. Si VBoxSDL ne peut pas choisir de résolution plus élevée, l'étiquette de sécurité sera dessinée en haut de la zone de l'écran de l'invité. Pour surmonter le problème selon lequel le bas de l'écran de l'invité est caché, VBoxSDL peut fournir des modes graphiques personnalisés à l'invité, réduits par la hauteur de l'étiquette. Pour les invités Windows et ceux Solaris et Linux récents, les suppléments invité de VirtualBox fournissent automatiquement les modes graphiques réduits. De plus, le BIOS VESA a été ajusté pour dupliquer sa table en mode standard avec des résolutions ajustées. Les IDs du mode ajusté se calculent en utilisant la formule suivante : reduced_modeid = modeid + 0x30 Par exemple, pour démarrer Linux avec 1024 x 748 x 16, le mode standard 0x117 (1024 x 768 x 16) est utilisé de base. Le paramètre du noyau Linux du mode graphique se calcule alors en faisant : vga = 0x200 | 0x117 + 0x30 vga = 839 On duplique les modes standards au lieu de ne fournir que les modes ajustés car la plupart des systèmes d'exploitation invités ont besoin des modes VESA standards figés et ils refusent de démarrer avec d'autres modes. Quand vous utilisez le pilote VESA de X.org, il faut calculer les modes personnalisés et les ajouter à la main à la configuration (en général, dans /etc/X11/xorg.conf. Vous pouvez trouver un outil à la main pour déterminer les entrées des modes sur http://www.tkk.fi/Misc/Electronics/faq/vga2rgb/calc.html.) Quand vous basculez d'un terminal virtuel (VT) X à un autre en utilisant Ctrl-Alt-Fx pendant que la fenêtre VBoxSDL contient le focus d'entrée, l'invité recevra les événements d'appui sur Ctrl et Alt sans recevoir les événements de relâchement correspondant de la touche. C'est une limite liée à l'architecture de Linux. Pour réinitialiser les touches modificatrices, il est possible d'envoyer SIGUSR1 au fil principal de VBoxSDL (première entrée de la liste ps). Par exemple, quand vous basculez vers un autre VT et quand vous enregistrez la machine virtuelle à partir de ce terminal, la séquence suivante peut être utilisée pour s'assurer que la VM sauvegardée avec des modificateurs bloqué : kill -usr1 <pid> VBoxManage controlvm "Windows 2000" savestate VirtualBox fournit des modules invité supplémentaires pour Windows, Linux et Solaris pour activer l'identification automatique dans l'invité. Quand on lance un système d'exploitation dans une machine virtuelle, il pourrait être souhaitable d'effectuer des identifications automatiques et coordonnées en utilisant des autorisations issues d'un système d'identification maître. (Avec les "autorisations", on se réfère aux informations d'identification qui consistent dans le nom d'utilisateur, le mot de passe et le nom de domaine, où chaque valeur pourrait être vide.) Depuis Windows NT, Windows fourni un sous-système d'identification modulaire ("Winlogon") qu'on peut utiliser et étendre par ce qu'on appelle des modules GINA (Graphical Identification and Authentication). Avec Windows Vista et Windows 7, les modules GINA ont été remplacés par un nouveau mécanisme appelé "fournisseurs d'autorisations". Les suppléments invité de VirtualBox pour Windows sont fournis à la fois avec un module GINA et un fournisseur d'autorisations, ils permettent donc à n'importe quel invité Windows d'effectuer des identifications automatiques. Pour activer le module GINA ou fournisseur d'autorisations des suppléments invité de VirtualBox, installez les suppléments invité en utilisant le paramètre /with_autologon en ligne de commande. Toutes les étapes manuelles suivantes exigés pour installer ces modules se feront via l'installeur. Pour installer à la main le module GINA de VirtualBox, extrayez les suppléments invité (voir ) et copiez le fichier VBoxGINA.dll dans le répertoire Windows SYSTEM32. Puis, dans le registre, créez la clé suivante : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GinaDLL avec la valeur VBoxGINA.dll. Le module GINA de VirtualBox est implémenté sur le module GINA standard de Windows (MSGINA.DLL). En conséquence, il ne fonctionnera vraisemblablement pas avec des modules GINA tiers. Pour installer à la main le module fournisseur d'autorisation de VirtualBox, extrayez les suppléments invité (voir ) et copiez le fichier VBoxCredProv.dll dans le répertoire Windows SYSTEM32. Puis, dans le registre, créez les clés suivantes :HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ Authentication\Credential Providers\{275D3BCC-22BB-4948-A7F6-3A3054EBA92B} HKEY_CLASSES_ROOT\CLSID\{275D3BCC-22BB-4948-A7F6-3A3054EBA92B} HKEY_CLASSES_ROOT\CLSID\{275D3BCC-22BB-4948-A7F6-3A3054EBA92B}\InprocServer32 avec pour valeurs celles par défault (la clé nommçe (Default) dans chaque clé) définies sur VBoxCredProv. Après quoi, il faut créer une nouvelle chaîne nommée HKEY_CLASSES_ROOT\CLSID\{275D3BCC-22BB-4948-A7F6-3A3054EBA92B}\InprocServer32\ThreadingModel avec une valeur de Apartment. Pour définir les autorisations, utilisez la commande suivante sur une VM en fonction : VBoxManage controlvm "Windows XP" setcredentials "John Doe" "secretpassword" "DOMTEST" Pendant que la VM est en fonction, vous pouvez hercher les autorisations accordées par les modules d'identification de VirtualBox (GINA ou fournisseur d'autorisation) en utilipnt le pérphérique des suppléments invité de VirtualBox. Quand Windows est en mode "déconnecté", les modules d'identification chercheront constament les autorisations et si elles existent, il tentera une identification. Après avoir récupéré les autorisations, les modules d'identification les écraseront pour que la commande ci-dessus doive se répéter pour les identifications consécutives. Pour des raisons de sécurité, les autorisations ne sont pas stockées de façon permanente et vous les perdrez quand vous redémarrerez la VM. En outre, les autorisations sont en "écriture seule", c'est-à-dire qu'il n'y a aucun moyen de récupérer les autorisations côté hôte. Vous pouvez réinitialiser les autorisations côté hôte en définissant des valeurs vides. Selon la variante particulière de votre invité Windows, les restrictions suivantes s'appliquent : Pour les invités Windows XP, le sous-système d'identification doit être configuré pour utiliser la boîte de dialogue classique d'identification car le module GINA de VirtualBoxu ne supporte pas la boîte de dialogz de bienvenue à la XP. Pour les invités Windows Vista, Windows 7 et Windows 8, le sous-système d'identification ne supporte pas ce qu'on appelle la Secure Attention Sequence (CTRL+ALT+DEL). Il s'en suit que les paramètres des règles du groupe de l'invité doivent être modifiés pour ne pas utiliser la Secure Attention Sequence. De plus, le nom d'utilisateur donné n'est comparé qu'au vrai nom d'utilisateur, pas au nom convivial d'utilisateur. Cela veut dire que quand vous renommez un utilisateur, vous devez aussi fournir le nom d'utilisateur originel (en interne, Windows ne renomme jamais les comptes utilisateurs). La gestion de l'identification automatique du Windows Remote Desktop Service (connu jadis sous le nom Terminal Services) est désactivée par défaut. Pour l'activer, créez la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Oracle\VirtualBox Guest Additions\AutoLogon avec une valeur DWORD de 1. La commande suivante oblige VirtualBox à garder les autorisations après leur lecture par l'invité et au redémarrage de la VM : VBoxManage setextradata "Windows XP" VBoxInternal/Devices/VMMDev/0/Config/KeepCredentials 1Remarquez que c'est un risque de sécurité potentiel car une application mavrc,llante en fonction sur l'invité pourrait solliciter ces informations en utilisant la bonne interface. À partir de la version 3.2, VirtualBox fournit un module PAM personnalisé (Pluggable Authentication Module) qu'on peut utiliser pour effectuer des identifications automatiques dans l'invité sur des plateformes qui supportent cet environnement. Virtuellement, toutes les distributions Linux/Unix modernes s'appuient sur PAM. Pour des identifications automatiques sur des distributions Ubuntu (ou dérivées d'Ubuntu), qui utilisent le gestionnaire d'affichage LightDM, merci de voir . Pour des identifications automatiques sur des distributions Ubuntu (ou dérivées d'Ubuntu), qui utilisent le gestionnaire d'affichage LightDM, merci de voir . Le module pam_vbox.so lui-même ne fait pas de vérification effective des autorisations passées à l'OS invité ; il s'appuie plutôt sur d'autres modules tels que pam_unix.so ou pam_unix2.so dans la pile PAM pour faire la validation effective en utilisant les autorisations récupérées par pam_vbox.so. Dès lors, il faut que pam_vbox.so soit en haut de la liste d'authentification du service PAM. pam_vbox.so ne supporte que le auth primitif. D'autres primates tels que account, session ou password ne sont pas supportés. Le module pam_vbox.so est inclu dans les suppléments invité mais il n'est pas installé et/ou activé par défaut sur l'OS invité. Afin de l'installer, il faut le copier de /opt/VBoxGuestAdditions-<version>/lib/VBoxGuestAdditions/ dans le répertoire des modules de sécurité, en général /lib/security/ sur les invités Linux 32 bit ou /lib64/security/ sur ceux 64 bits. Merci de vous reporter à la documentation de votre OS invité pour le bon répertuire du module PAM. Par exemple, pour utiliser pam_vbox.so avec un OS invité Linux Ubuntu et GDM (le GNOME Desktop Manager) pour identifier les utilisateurs automatiquement avec les droits passés par l'hôte, l'OS invité doit être configuré comme ce qui suit : Le module pam_vbox.so doit être copié dans le répertoire des modules de sécurité, dans ce cas, c'est /lib/security. Éditz le fichier de configuration de PAM avec GDM qui se trouve dans /etc/pam.d/gdm, en ajoutant la ligne auth requisite pam_vbox.so au début. En outre, dans la plupart des distributions Linux, il existe un fichier appelé /etc/pam.d/common-auth. Ce fichier est inclut dans de nombreux services (comme le fichier GDM indiqué ci-dessus). Vous devez y ajouter la ligne auth requisite pam_vbox.so. Si vous voulez une authentification contre la base de données shadow en utilisant pam_unix.so ou pam_unix2.so, l'argument try_first_pass de pam_unix.so ou use_first_pass pour pam_unix2.so est nécessaire pour passer les autorisations du module VirtualBox au module d'authentification de la base de données shadow. Pour Ubuntu, il faut ajouter cela à /etc/pam.d/common-auth, à la fin de la ligne référençant pam_unix.so. Cet argument dit au module PAM d'utiliser les autorisations déjà présentes dans la pile, à savoir celles fournies par le module PAM de VirtualBox. Une pile PAM mal configurée peut vraiment vous empêcher de vous connecter à votre système invité ! Pour faciliter le déploiement, vous pouvez passer l'argument debug juste après la ligne pam_vbox.so. La sortie du journal de débogage sera enregistrée en utilisant syslog. Par défaut, pam_vbox n'attendra pas les autorisations venant de l'hôte, en d'autres termes : quand une invite de connexion s'affiche (ppar exemple via GDM/KDM ou la console texte) et quand pam_vbox n'a pas encore les autorisations, il n'attend pas qu'elles viennent. Le module suivant de la pile PAM (selon la configuration de PAM) aura une chance d'authentification. À partir de VirtualBox 4.1.4 pam_vbox supporte plusieurs paramètres de propriétés d'invité résidant tous dans /VirtualBox/GuestAdd/PAM/. Ces paramètres permettent à pam_vbox d'attendre que les autorisations soient fournies dans l'hôte et, éventuellement, il peut afficher un message tout en les attendant. Les propriétés d'invité suivantes peuvent être définies : CredsWait : Définissez sur "1" si pam_vbox devrait commencer à attendre jusqu'à ce que les autorisations viennent de l'hôte. En attendant, aucune autre méthode d'authentification comme la connexion à la main ne sera disponible. Si cette propriété est vide ou effacée, les autorisations ne seront pas attendues et pam_vbox comme avant (voir le paragraphe ci-dessus). Cette propriété doit être définie en lecture seule pour l'invité (RDONLYGUEST). CredsWaitAbort : Annule l'attente des autorisations si une valeur est définie. Elle peut être définie à partir de l'hôte et de l'invité. CredsWaitTimeout : Timeout (en secondes) pendant lequel il faut laisser pam_vbox attendre les autorisations. Si aucune autorisation ne vient dans ce délai, l'authentification de pam_vbox sera définie comme échouée et le prochain module PAM de la chaîne sera appelé. Si vous ne spécifiez pas cette propriété, ou que vous la réglez sur "0" ou sur une valeur invalide, on utilisera un timeout infini. Cette propriété doit être paramétrée en lecture seule pour l'invité (RDONLYGUEST). Pour personnaliser davantage pam_vbox, il existe les propriçtés invité suivantes : CredsMsgWaiting : message personnalisé affiché pendant que pam_vbox attend les autorisations de l'hôte. Cette propriété doit être réglée en lecture seule pour l'invité (RDONLYGUEST). CredsMsgWaitTimeout : message personnalisé affiché pendant l'attente de la fin du timeout des autorisations de pam_vbox, par exemple si elles ne sont pas arrivées à temps. Cette propriété doit être réglée en lecture seule pour l'invité (RDONLYGUEST). Si une propriété pam_vbox est définie avec de mauvais drapeaux (RDONLYGUEST), cette propriété sera ignorée et - selon la propriété - une valeur par défaut sera utilisée. Il peut s'en suivre que pam_vbox n'attendra pas les autorisations. Consultez le fichier syslog adéquat pour plus d'informations et utilisez l'option debug. À partir de la version 4.2.12, VirtualBox est fourni avec son propre module greeter, qui s'appelle vbox-greeter et qu'on peut utiliser avec LightDM 1.0.1 ou supérieur. LightDM est le gestionnaire d'affichage par défaut depuis Ubuntu 10.11 et on peut donc l'utiliser également pour des identifications automatiques sur l'invité. vbox-greeter n'a pas besoin du module pam_vbox décrit ci-dessus pour fonctionner -- il est fourni avec son propre mécanisme d'authentification fourni par LightDM. Cependant, pour offrir le maximum de flexibilité, vous pouvez utiliser les deux modules ensemble sur le même invité. Comme pour le module pam_vbox, vbox-greeter est fourni avec les suppléments invité mais il n'est pas installé et/ou activé par défaut sur l'OS invité. Pour installer vbox-greeter automatiquement pendant l'installation des suppléments invité, utilisez le paramètre --with-autologon au lancement du fichier VBoxLinuxAdditions.run : # ./VBoxLinuxAdditions.run -- --with-autologon Pour une installation manuelle ou différée, le fichier vbox-greeter.desktop doit être copié de /opt/VBoxGuestAdditions-<version>/shared/VBoxGuestAdditions/ dans le répertoire xgreeters, généralement /usr/share/xgreeters/. Merci de vous reporter à la documentation de votre OS invité pour le bon répertoire de LightDM greeter. Le module vbox-greeter lui-même a été installé par l'installeur des suppléments invité de VirtualBox et il se trouve dans /usr/sbin/. Pour activer vbox-greeter en tant que module greeter standard, le fichier /etc/lightdm/lightdm.conf doit être modifié : [SeatDefaults] greeter-session=vbox-greeter Il faut complètement relancer le serveur LightDM afin que vbox-greeter soit utilisé comme greeter par défaut. En tant qu'administrateur, exécutez un service lightdm --full-restart sur Ubuntu, ou redémarrez tout simplement l'invité. vbox-greeter est indépendant de la session graphique choisie par l'utilisateur (comme Gnome, KDE, Unity etc). Néanmoins, il exige FLTK 1.3pour afficher sa propre interface utilisateur. De noubreuses propriétés invité peuvent être utilisées pour personnaliser davantage l'identification de l'utilisateur. Pour identifier automatiquement les utilisateurs, s'appliquent les mêmes propriétés qu'avec pam_vbox, voir . Outre les propriétés invité indiquées ci-dessus, vbox-greter permet davantage de personnalisation de son interface utilisateur. Ces propriétés invité spéciales se trouvent toutes dans /VirtualBox/GuestAdd/Greeter/ : HideRestart : Réglez-le sur "1" si vbox-greeter doit masquer le bouton de redémarrage de l'invité. Vous devez définir cette propriété en lecture seule pour l'invité (RDONLYGUEST). HideShutdown : Réglez-la à "1" si vbox-greeter doit masquer le bouton d'extinction de l'invité. Vous devez définir cette propriété en lecture seule pour l'invité (RDONLYGUEST). BannerPath : Chemin vers un fichier .PNG à utiliser comme bannière en haut. La taille de l'image doit être de 460 x 90 pixels, quelle rue soit la profondeur de bit. Vous devez définir cette propriété en lecture seule pour l'invité (RDONLYGUEST). UseTheming : Définissez-la à "1" pour activer les options de thème suivantes. Vous devez définir cette propriété en lecture seule pour l'invité (RDONLYGUEST). Theme/BackgroundColor : Couleur RRGGBB hexadécimale du fond. Vous devez définir cette propriété en lecture seule pour l'invité (RDONLYGUEST). Theme/LogonDialog/HeaderColor : Couleur d'avant RRGGBB hexadécimale pour le texte d'en-tête. Vous devez définir cette propriété en lecture seule pour l'invité (RDONLYGUEST). Theme/LogonDialog/BackgroundColor: Couleur en RRGGBB hexadécimale du fond de la boîte de dialogue d'identification. Vous devez définir cette propriété en lecture seule pour l'invité (RDONLYGUEST). Theme/LogonDialog/ButtonColor : Couleur de fond RRGGBB hexadécimale du bouton de la boîte de dialogue d'identification. Vous devez définir cette propriété en lecture seule pour l'invité (RDONLYGUEST). Les mêmes restrictions des propriétés invité ci-dessus s'appliquent comme celles indiquées dans la section pam_vbox. À partir de Windows NT 4.0, Microsoft offre un outil "préparation système" (en bref : Sysprep) pour préparer un système Windows à être déployé ou redistribué. Si Windows 2000 et XP sont inclus avec Sysprep sur leur média d'installation, l'outil est également disponible en téléchargement sur le site Internet de Microsoft. Dans une installation standard de Windows Vista et 7, Sysprep est déjà inclu. Sysprep consiste principalement dans un exécutable qui s'appelle sysprep.exe qui est appelé par l'utilisateur pour passer l'installation Windows en mode préparation. À partir VirtualBox 3.2.2, les suppléments invité offrent un moyen de lancer une préparation du système sur le système d'exploitation invité de manière automatisée et contrôlée depuis le système hôte. Pour faire cela, voir pour utiliser la fonction avec l'identifiant spécial sysprep pour que le programme s'exécute avec le nom d'utilisateur sysprep et le mot de passe sysprep des autorisations. Sysprep se lance avec les droits système requis. La spécification de l'emplacement de "sysprep.exe" n'est pas possible -- les chemins suivants seront plutôt utilisés (basés sur le système d'exploitation) : C:\sysprep\sysprep.exe pour Windows NT 4.0, 2000 et XP %WINDIR%\System32\Sysprep\sysprep.exe pour Windows Vista, 2008 Server et 7 Les suppléments invité utiliseront automatiquement le chemin adapté pour exécuter l'outil de préparation système. Les suppléments invité de VirtualBox contiennent plusieurs pilotes. Si, pour une raison quelconque, vous ne souhaitez pas les installer, vous pouvez installer les suppléments invité en utilisant la commande suivante : sh ./VBoxLinuxAdditions.run no_setup Après quoi, vous devrez au moins compiler les modules noyau en lançant la commande /usr/lib/VBoxGuestAdditions/vboxadd setup en tant que root (vous devrez remplacer lib par lib64 sur certains invités 64 bits), et sur les anciens invités sans service udev, vous devrez ajouter le service vboxadd au niveau d'exécution par défaut pour vous assurer que les modules sont chargés. Pour régler le service de synchronisation du temps, lancez la commande /usr/lib/VBoxGuestAdditions/vboxadd-service setup et ajoutez le service vboxadd-service au niveau d'exécution par défaut. Pour paramétrer la partie X11 et OpenGL des suppléments invité, lancez la commande /usr/lib/VBoxGuestAdditions/vboxadd-x11 setup (vous n'avez pas besoin d'activer un service). Pour recompiler les modules noyau invité, utilisez cette commande : /usr/lib/VBoxGuestAdditions/vboxadd setup Après la compilation, vous devriez redémarrer votre invité pour vous assurer que les nouveaux modules sont bien utilisés. Cette section suppose que vous êtes familier de la configuration de votre serveur X.Org en utilisant xorg.conf et éventuellement les méhanismes récents en utilisant hal ou udev et xorg.conf.d. Sinon, vous pouvez apprendre à les utiliser en étudiant la documentation fournie avec X.Org. Les suppléments invité de VirtualBox sont fournis avec les pilotes pour les versions X.Org X11R6.8/X11R6.9 et XFree86 version 4.3 (vboxvideo_drv_68.o et vboxmouse_drv_68.o) X11R7.0 (vboxvideo_drv_70.so and vboxmouse_drv_70.so) X11R7.1 (vboxvideo_drv_71.so and vboxmouse_drv_71.so) Serveur X.Org versions 1.3 et later (vboxvideo_drv_13.so et vboxmouse_drv_13.so et ainsi de suite). Par défaut, vous pouvez trouver ces pilotes dans le répertoire /opt/VBoxGuestAdditions-<version>/lib/VBoxGuestAdditions et les bonnes versions du serveur X sont liées de façon symbolique aux répertoires du pilote de X.Org. Pour que l'intégration graphique fonctionne correctement, le serveur X doit charger le pilote vboxvideo (beaucoup de versions récentes du serveur X le cherchent automatiquement si elles voient qu'elles sont sur VirtualBox) et pour uneexpérience utilisateur optimale, les pilotes du noyau invité doivent être chargés et l'outil des supplçments invité VBoxClient doit être en fonction en tant que client dans la session X. Pour que l'intégration de la souris fonctionne correctement, les pilotes du noyau invité doivent être chargés et, au surplus, dans les serveurs X de X.Org X11R6.8 à X11R7.1 et dans XFree86 version 4.3, le bon pilote vboxmouse doit être chargé et associé à /dev/mouse ou /dev/psaux ; dans le serveur X.Org 1.3 ou supérieur, un pilote de souris PS/2 doit être chargé et le bon pilote vboxmouse doit être associé à /dev/vboxguest. Le pilote graphique invité de VirtualBox peut utiliser n'importe quelle configuration graphique pour laquelle la résolution rentre dans la mémoire graphique affectée à la machine virtuelle (moins une petite quantité utilisée par le pilote invité) comme décrit au . Le pilote offrira une gamme de nœuds standards allant au moins jusqu'à la résolution invité par défaut pour tous les écrans invités. Dans le serveur X.Org et supérieur, le mode par défaut peut être modifié en définissant la propriété de sortie VBOX_MODE sur "<width>x<height>" pour tout écran invité. Quand VBoxClient et les pilotes du noyau sont actifs, cela se fait automatiquement quand l'hôte demande une modification du mode. Le pilote des anciennes versions ne peut recevoir de nouveaux modes qu'en demandant à l'hôte les requêtes à intervalles réguliers. Avec les serveurs X pre-1.3, vous pouvez également ajouter vos propres modes dans le fichier de configuration du serveur X. Vous devez simplement les ajouter à la liste des "Modes" de la sous-section "Display" de la section "Screen". Par exemple, la section affichée ici a un mode de résolution personnalisé de 2048x800 : Section "Screen" Identifier "Default Screen" Device "VirtualBox graphics card" Monitor "Generic Monitor" DefaultDepth 24 SubSection "Display" Depth 24 Modes "2048x800" "800x600" "640x480" EndSubSection EndSection Quand des machines virtuelles fonctionnent sur des szstèmes d'exploitation serveurs modernes, VirtualBox supporte le montage à chaud de processeur. Le support du montage de processeur à chaud a été introduit avec VirtualBox 3.2. Alors que, sur un ordinateur physique, cela voudrait dire qu'un processeur peut être ajouté ou supprimé pendant que la machine fonctionne, VirtualBox supporte l'ajout et le retrait de processeurs virtuels pendant que la machine is virtuelle est en fonction. Le montage à chaud de processeur ne fonctionne qu'avec les systèmes d'exploitation invités qui le supportent. Jusque-là, il ne s'applique qu'à Linux et Windows Server 2008 x64 édition Data Center. Windows ne supporte que l'ajout à chaud alors que Linux supporte l'ajout et le retrait à chaud., mais pour utiliser cette fonction avec plus de 8 processeurs, il faut un invité Linux 64 bits. Pour l'instant, le branchement à chaud d'un processeur exige d'utiliser l'interface en ligne de commandes VBoxManage. Tout d'abord, il faut activer le branchement à chaud pour une machine virtuelle :VBoxManage modifyvm "nom VM" --cpuhotplug on Ensuite, l'option --cpus spécifie le nombre maximum de processeurs que peut avoir la machine virtuelle :VBoxManage modifyvm "nom VM" --cpus 8Quand la VM est désactivée, vous pouvez ajouter et supprimer des processeurs virtuels avec les sous-commandes modifyvm --plugcpu et --unplugcpu, qui prend le nombre de processeurs virtuels en paramètre, comme ceci :VBoxManage modifyvm "nom VM" --plugcpu 3 VBoxManage modifyvm "nom VM" --unplugcpu 3Remarquez que le processeur 0 ne peut jamais être supprimé. Pendant que la VM est en fonction, les processeurs peuvent être ajoutés avec les commandes controlvm plugcpu/unplugcpu :VBoxManage controlvm "nom VM" plugcpu 3 VBoxManage controlvm "nom VM" unplugcpu 3 Voir et pour des détails. Avec des invités Linux, ce qui suit s'applique : Pkur empêcher d'éjecter alors que le processeur est utilisé, il doit être éjecté de l'invité au préalable. Les suppléments invité pour Linux contiennent un service qui reçoit les événements de retrait à chaud et ils éjectent le processeur. De plus, après qu'un processeur a été ajoutà à la VM, il n'est pas utilisç automatiquement par Linux. Le service des suppléments invité pour Linux s'en chargera s'il est installé. Sinon, vous pouvez démarrer un processeur avec la commande suivante :echo 1 > /sys/devices/system/cpu/cpu<id>/online Sur des hôtes Linux, avec un noyau assez récent (au moins la version 2.6.31), le passthrough de périphériques PCI expérimental est disponible. Le support expérimental pour le passthrough PCI a été introduit avec VirtualBox 4.1. Le module PCI passthrough est inclu comme un paquet d'extension de VirtualBox, qui doit être installé séparémeq. Voir pour plus d'informations. Cette fonction vous permettra essentiellement d'utiliser directement les périphériques PCI physiques de l'hôte sur l'invité même si l'hôte n'a pas de pilote pour ce périphérique particulier. Tant les cartes PCI normales que certaines cartes PCI express sont supportées. L'AGP et certaines cartes PCI Express ne sont pas supportées pour l'instant si elles s'appuient sur l'unité de programmation GART (Graphics Address Remapping Table) pour la gestion des textures vu qu'il fait plutôt des opérations non triviales avec l'association de pages qui s'interfacent avec IOMMU. Il se peut que cette limite soit surmontée dans les prochaines versions. Pour être totalement opérationnel, le support PCI passthrough de VirtualBox dépend d'une unité matérielle IOMMU qui n'est pas encore trop largement disponible. Si le périphérique utilise le bus mastering (à savoir qu'il fait sa propre DMA sur la mémoire de l'OS), une IOMMU est requise, sinon de telles transactions DMA peuvent écrire sur la mauvaise adresse physique de la mémoire car le moteur DMA du pçriphérique est est programmé pour utiliser un protocole spécifique au périphérique pour faire des transactions avec la mémoire. Les fonctions IOMMU comme traduction des unités correspondant à la mémoire physique accèdent aux requêtes du périphérique en utilisant la connaissance de l'adresse physique de la mémoire de l'invité via les règles de traduction d'adresse shysique de l'hôte. La solution d'Intel pour IOMMU est vendue sous le nom "Intel Virtualization Technology for Directed I/O" (VT-d), et celle d'AMD s'appelle AMD-Vi. Merci donc de vérifier si le modèle de votre carte mère comporte la technologie adaptée. Même si votre matériel n'a pas d'IOMMU, certaines cartes PCI peuvent fonctionner (comme des adaptateurs série PCI), mais l'invité affichera un avertissement au démarrage et l'exécution de la VM s'achèvera si le pilote invité essaie d'activer le bus mastering. Très couramment, le BIOS ou l'OS hôte désactive par défaut l'IOMMU. Donc avant d'essayer de l'utiliser, merci de vous assurer que Votre carte mère a une unité IOMMU. Votre processeur supporte l'IOMMU. L'IOMMU est activé dans le BIOS. La VM doit fonctionner avec VT-x/AMD-V et la pagination nested doit être activée. Votre noyau Linux a été compilé avec le support IOMMU (y compris la réassociation du DMA, voir l'option de compilation CONFIG_DMAR). Le pilote PCI stub (CONFIG_PCI_STUB) est requis aussi. Votre noyau Linux reconnaît et utilise l'unité IOMMU (l'option (de démarrage intel_iommu=on pourrait être nécessaire). Cherchez DMAR et PCI-DMA dans le journal du démarrage. Une fois que vous êtes sûre que le noyau hôte supporte l'IOMMU, la prochaine étape est de sélectionner la carte PCI et de l'attacher à l'invité. Pour visualiser la liste des périphériques PCI disponibles, utilisez la commande lspci. La sortie ressemblera à ceci : 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450] 01:00.1 Audio device: ATI Technologies Inc Manhattan HDMI Audio [Mobility Radeon HD 5000 Series] 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) 03:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller (rev 03) 03:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 Serial ATA Controller (rev 03) 06:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8500 GT] (rev a1) La première colonne est une adresse PCI (au format bus:device.function). Cette adresse pourrait être utilisée pour identifier les périphériques pour aller plus loin. Par exemple, pour attacher un contrôleur réseau PCI du système listé ci-dessus, au second bus PCI de l'invité, en périphériqz 5, la fonction 0, utilisez la commande suivante : VBoxManage modifyvm "nom VM" --pciattach 02:00.0@01:05.0 Pour détacher ce même périphérique, utilisez VBoxManage modifyvm "nom VM" --pcidetach 02:00.0 Merci de remarquer que l'hôte et l'invité pourraient librement affecter une autre adresse PCI à la carte attachée à l'exécution, donc ces adresses ne s'appliquent qu'à l'adresse de la carte au moment d'être attaché (hôte), et lors de l'initialisation du PCI de BIOS (invité). Si la machine (irtuelle a un périphérique PCI attaché, certaines limitations s'appliquent : Seules les cartes PCI aux interruptions non partagées (telles que l'utilisation de MSI sur l'hôte) sont supportées pour le moment. On ne peut pas sauvegarder/restaurer de façon fiable l'état de l'invité (car l'état interne de la carte PCI ne pourrait pas être récupéré). La téléportation (migration en direct) ne fonctionne pas (pour la même raison). Aucune couche d'affectation de mémoire physique. L'hôte préaffectera toute la RAM nécessaire au démarrage de la VM (vu que nous ne pouvons pas relier les accès physiques au matériel à la mémoire physique). Outre les résolutions VESA standards, le BIOS VESA de VirtualBox vous permet d'ajouter jusqu'à 16 modes graphiques personnalisés qui seront signalés au système d'exploitation invité. Quand on utilise des invités Windows avec les suppléments invité de VirtualBox, un pilote graphique personnalisé sera utilisé à la place de la solution VESA de repli, donc ces informations ne s'appliquent pas. Vous pouvez configurer des modes graphiques supplémentaires pour chaque VM en utilisant la fonction de données supplémentaires. La clé des données supplémentaires s'appelle CustomVideoMode<x> avec x étant un numéro de 1 à 16. Merci de remarquer que les modes seront lus de 1 au numéro suivant non défini ou jusqu'à 16. L'exemple suivant ajoute un mode graphique correspondant à la résolution d'affichage native de nombreux ordinateurs notebook : VBoxManage setextradata "nom VM" "CustomVideoMode1" "1400x1050x16" Les IDs du mode VESA pour les modes graphiques personnalisés commencent à 0x160. Afin d'utiliser le mode graphique personnalisé ci-dessus, vous devez donner à Linux la ligne de commande suivante : vga = 0x200 | 0x160 vga = 864 Pour les systèmes d'exploitation ayant les suppléments invité, vous pouvez définir un mode graphique personnalisé en utilisant la fonction d'astuce du mode graphique. Quand on démarre des systèmes invités ayant les suppléments invité installés en utilisant l'interface graphique (l'application normale de VirtualBox), ils ne seront pas autorisés à utiliser des résolutions d'écran supérieures à la taille de l'écran de l'hôte sauf si l'utilisateur les redimensionne à la main en utilisant la fenêtre, en basculant en mode plein écran ou transparent ou en envoyant une astuce de mode graphique utilisant VBoxManage. Ce comportement est celui que la plupart des utilisateurs voudront mais si vous avez d'autres besoins, il est possible de le modifier en exécutant une des commandes suivantes sur la ligne de commandes : VBoxManage setextradata global GUI/MaxGuestResolution any supprimera toutes les limites des résolutions de l'invité. VBoxManage setextradata global GUI/MaxGuestResolution >width,height< spécifie à la main une résolution maximum. VBoxManage setextradata global GUI/MaxGuestResolution auto restaure les paramètres par défaut. Remarquez que ces paramètres s'appliquent globalement à tous les systèmes invités, pas seulement à une seule machine. À partir de la version 1.4, plutôt que d'utiliser des images de disques virtuels (comme décrit en détail au ), VirtualBox peut aussi présenter aux machines virtuelles soit des disques durs entiers, soit des partitions sélectionnées, comme des disques virtuels. Avec VirtualBox, ce typed'accès s'appelle "l'accès au disque dur brut" ; il permet à un système d'exploitation invité d'accéder à son disque dur virtuel sans passer par le système de fichiers de l'OS hôte. La différence de performance finale entre les fichiers images et les disques bruts varie beaucoup selon l'overhead du système de fichiers hôte et le dynamisme de la croissance des images, et enfin des stratégies de mise en cache de l'OS hôte. La mise en cache concerne aussi indirectement d'autres aspects tels que le comportement en cas d'échec, à savoir si le disque dur contient toutes les données écrites avant un OS hôte ne plante. Consultez la documentation de votre OS hôte pour les détails à ce sujet. L'accès au disque dur brut est réservé aux utilisateurs experts. Une utilisation incorrecte ou d'une configuration obsolète peut provoquer une perte totale des données du disque physique. Surtout, n'essayez pas de démarrer la partition avec le système d'exploitation hôte actuellement en fonction dans un invité. Cela entraînera une grave corruption de données. L'accès au disque dur brut -- tant entiers qu'aux partitions individuelles -- est implémenté comme support du format image VMDK. Il s'en suit que vous devrez créer un fichier image VMDK qui définit l'endroit où les données seront stockées. Après avoir créé une image VMDK spéciale, vous pouvez l'utiliser comme un disque virtuel normal. Par exemple, vous pouvez utiliser le gestionnaire VirtualBox () ou VBoxManage pour affecter l'image à une machine virtuelle. Si cette variante est la plus simple à paramétrer, vous devez avoir à l'esprit que cela donnera au système d'exploitation invité un accès total et direct à tout un disque dur. Si votre système d'exploitation hôte démarre aussi sur ce disque, merci de faire particulièrement attention à ne pas accéder à la partition avec l'invité. Côté positif, le disque physique peut être repartitionné de façon arbitraire sans devoir recréer le fichier image qui donne accès au disque brut. Pour créer une image qui représente un disque dur physique entier (qui ne contiendra pas de vraies données physiques vu qu'elles seront stockées sur le disque physique), sur un hôte Linux, utilisez la commandeVBoxManage internalcommands createrawvmdk -filename /chemin/vers/fichier.vmdk -rawdisk /dev/sdaCeci crée l'image /chemin/vers/fichier.vmdk (il doit être absolu), et toutes les données seront lues et écrites à partir de /dev/sda. Sur un hôte Windows, plutît que de spécifier le périphérique comme ci-dessus, utilisez par exemple \\.\PhysicalDrive0. Sur un hôte Mac OS X, utilisez plutît, par exemple, /dev/disk1. Remarquez que sur OS X, vous ne pouvez avoir d'accès à tout un disque que si aucun volume n'est monté à partir de là. La création de l'image exige un accès en lecture/écriture au périphérique donné. L'accès en lecture/écriture sera aussi nécessaire plus tard lors de l'utilisation de l'image d'une machine virtuelle. Sur certaines plateformes hôtes (comme Windows Vista et supérieur), l'accès au disque brut peut être restreint et non autorisé par l'OS hôte dans certaines situations. Comme avec les images de disque normales, ceci n'attache pas automatiquement l'image nouvellement créée à une machine virtuelle. Ceci peut se faire avec, par exemple, VBoxManage storageattach WindowsXP --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /path/to/file.vmdkQuand cela se fait, la machine virtuelle démarrera depuis le disque physique spécifié. Ce "support de partition brut" est très semblable à l'accès au "disque dur complet" décrit ci-dessus. Cependant, dans ce cas, toutes les informations de partitionnement seront stockées dans l'image VMDK, donc vous pouvez par exemple installer un autre chargeur d'amorçage dans le disque dur virtuel sans toucher les informations de partitionnement de l'hôte. Si l'invité pourra svoir toutes les partitions existantes sur le disque physique, l'accès sera filtré de sorte que la lecture des partitions pour lesquelles aucun accès n'est autorisé ne contiendra que des zéros et que toutes les écritures dessus soient ignorées. Pour créer une image spéciale pour le support d'une partition brute (qui contiendra une petite quantité de données, comme déjà indiqué), sur un hôte Linux, utilisez la commandeVBoxManage internalcommands createrawvmdk -filename /chemin/vers/fichier.vmdk -rawdisk /dev/sda -partitions 1,5 Comme vous pouvez le voir, la commande est identique à celle pour l'accès "au disque dur brut", sauf le paramètre supplémentaire -partitions. Cet exemple créerait l'image /chemin/vers/fichier.vmdk (qui, de nouveau, doit être absolu), et les partitions 1 et 5 de /dev/sda deviendraient accessibles à l'invité. VirtualBox la même numçrotation de partitions que votre hôte Linux. Il s'en suit que les numçros donnés dans l'exemple ci-dessus se référeraient respectivement à la première partition primaire et au premier lecteur logique de la partition étendue. Sur un hôte Windows, au lieu de spécifier le périphérique comme ci-dessus, utilisez par exemple \\.\PhysicalDrive0. Sur un hôte Mac OS X, utilisez plutôt par exemple /dev/disk1. Remarquez que sur OS X, vous ne pouvez utiliser que des partitions non montées (éjectez d'abord les volumes concernés). Les numéros de partition sont les mêmes sur les hôtes Linux, Windows et Mac OS X. Vous pouvez prendre les numéros dans la liste des partitions dans la sortie deVBoxManage internalcommands listpartitions -rawdisk /dev/sdaLa sortie liste les types et les tailles des partitions pour donner à l'utilisateur assez d'informations pour identifier les partitions nécessaires à l'invité. Les images donnant accès aux partitions individuelles sont spécifiques à un paramétrage de disque particulier à un hôte. Vous ne pouvez pas transposer ces images à un autre hôte ; et à chaque fois que le partitionnement de l'hôte change, l'image doit être recréée. La création d'une image exige l'accès en écriture sur le périphérique donné. L'accès en lecture/écriture sera également nécessaire plus tard pour utiliser l'image à partir d'une machine virtuelle. Si ce n'est pas faisable, il existe une variante spéciale de l'accès à une partition brute (disponible aujourd'hui uniquement sur les hôtes Linux) qui évite de devoir donner à l'utilisateur actuel l'accès à tout le disque. Pour faire une telle image, utilisezVBoxManage internalcommands createrawvmdk -filename /chemin/vers/fichier.vmdk -rawdisk /dev/sda -partitions 1,5 -relativeUtilisée depuis une machine virtuelle, l'image ne se réfèrera pas à tout le disque mais seulement aux partitions individuelles (dans l'exemple /dev/sda1 et /dev/sda5). Par conséquent, l'accès en lecture/écriture n'est requis que pou! les partitions concernées, pas pour tout le disque. Mais lors de la création, un accès en lecture seule à tout le disque est nécessaire pour avoir les informations de partitionnement. Dans certaines configurations, il peut être nécessaire de modifier le code du MBR de l'image créée, par exemple pour remplacer le chargeur de démarrage Linux utilisé sur l'hôte par un autre chargeur de démarrage. Cela permet, par exemple, à l'invité, de démarrer directement sur Windows, alors que l'hôte démarre sur Linux sur le "même" disque. Pour obtenir cela, le paramètre -mbr vous est offert. Il spécifie un nom de fichier à partir duquel il faut prendre le code du MBR. La table des partitions n'est pas modifiée, donc on peut utiliser un fichier MBR d'un système ayant un partitionnement totalement différent. Un exemple estVBoxManage internalcommands createrawvmdk -filename /chemin/vers/fichier.vmdk -rawdisk /dev/sda -partitions 1,5 -mbr winxp.mbrLe MBR modifié sera stocké dans l'image, pas sur le disque hôte. L'image créée peut être attachée à un contrôleur de stockage dans une configuration de VM, comme d'habitude. VirtualBox signale les données liçes au fabricant du produit de ses disques durs virtuels, consistant dans le numéro de série du disque dur, le numro de révision du firmware et du modèle. Vous pouvez modifier ces données en utilisant les commandes suivantes : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/ahci/0/Config/Port0/SerialNumber" "serial" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/ahci/0/Config/Port0/FirmwareRevision" "firmware" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/ahci/0/Config/Port0/ModelNumber" "model" Le numéro de série est une chaîne alphanumérique de 20 octets, la Révision du firmware est une chaîne alphanumérique de 8 octets et le numéro de modèle est une chaîne alphanumàrique de 40 octets. Au lieu de "Port0" (qui renvoie au premier port), spécifiez le port SATA désiré du disque dur. Les commandes ci-dessus s'appliquent aux machines virtuelles ayant un contrôleur AHCI (SATA). Les commandes pour les machines virtuelles ayant un contrôleur IDE sont : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/piix3ide/0/Config/PrimaryMaster/SerialNumber" "serial" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/piix3ide/0/Config/PrimaryMaster/FirmwareRevision" "firmware" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/piix3ide/0/Config/PrimaryMaster/ModelNumber" "model" Pour les disques durs, il est aussi possible de marquer le lecteur comme ayant un média non rotationnel avec : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/ahci/0/Config/Port0/NonRotational" "1" Trois paramètres supplémentaires sont nécessaires pour que les lecteurs CD/DVD signalent les données produit du fabricant : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/ahci/0/Config/Port0/ATAPIVendorId" "vendor" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/ahci/0/Config/Port0/ATAPIProductId" "product" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/ahci/0/Config/Port0/ATAPIRevision" "revision" L'id du fabricant est une chaîne alphanumérique de 8 octets, l'id du produit est une chaîne alphanumérique de 16 octets, la révision est une chaîne alphanumérique de 4 octets. À la place de "Port0" (qui renvoie au premier port), spécifiez le port du disque dur SATA désiré. En fonctionnalité expérimentale, VirtualBox permet d'accéder à une cible iSCSI d'une machine virtuelle en fonction configurée pour utiliser le mode réseau interne. Merci de voir le  ;  ; et pour avoir des informations supplémentaires. La pile IP d'accès au réseau interne doit être configurée dans la machine virtuelle qui accède à la cible iSCSI. Vous devez choisir une IP statique libre et une adresse MAC non utilisée par d'autres machines virtuelles. Dans l'exemple ci-dessous, adaptez le nom de la machine virtuelle, l'adresse MAC, la configuration IP et le nom du réseau interne ("MyIntNet") selon vos besoins. Les huit commandes suivantes doivent être d'abord lancées :VBoxManage setextradata "nom VM" VBoxInternal/Devices/IntNetIP/0/Trusted 1 VBoxManage setextradata "nom VM" VBoxInternal/Devices/IntNetIP/0/Config/MAC 08:00:27:01:02:0f VBoxManage setextradata "nom VM" VBoxInternal/Devices/IntNetIP/0/Config/IP 10.0.9.1 VBoxManage setextradata "nom VM" VBoxInternal/Devices/IntNetIP/0/Config/Netmask 255.255.255.0 VBoxManage setextradata "nom VM" VBoxInternal/Devices/IntNetIP/0/LUN#0/Driver IntNet VBoxManage setextradata "nom VM" VBoxInternal/Devices/IntNetIP/0/LUN#0/Config/Network MyIntNet VBoxManage setextradata "nom VM" VBoxInternal/Devices/IntNetIP/0/LUN#0/Config/TrunkType 2 VBoxManage setextradata "nom VM" VBoxInternal/Devices/IntNetIP/0/LUN#0/Config/IsService 1 Enfin, le disque iSCSI doit être attachée avec l'option --intnet pour dire à l'initiateur iSCSI d'utiliser le réseau interne :VBoxManage storageattach ... --medium iscsi --server 10.0.9.30 --target iqn.2008-12.com.sun:sampletarget --intnet Par rapport à une configuration iSCSI "ordinaire", l'adresse IP de la cible doit être spécifiée comme un adaptateur IP numérique, vu qu'il n'y a pas de résolveur DNS pour le réseau interne. La machine virtuelle ayant la cible iSCSI devrait être démarrée avant que la VM qui l'utilise ne soit allumée. Si vous démarrez une machine virtuelle qui utilise un disque iSCSI sans que la cible iSCSI ne poit allumée, elle peut mettre jusqu'à 200 secondes avant de détecter cette situation. La VM ne pourra pas s'allumer. $ Les hôtes Linux ont un nombre figé d'IDs de sémaphores IPC par processus qui empêche les utilisateurs de lancer énormément de VMs. Le nombre exact peut varier selon la distribution Linux. En essayant de lancer trop de VMs, vous verriez s'afficher une erreur "Cannot create IPC semaphore". Pour lancer plus de VMs, vous devrez augmenter la limite d'IDs de sémaphore du processus VBoxSVC. Cherchez les limites du sémaphore imposé par le noyau en exécutant en tant que root :#/sbin/sysctl kernel.sem kernel.sem = 250 32000 32 128 Le paramètre "kernel.sem" rassemble 4 valeurs, celle qui nous intéresse s'appelle "SEMMNI", le nombre maximum d'IDs de sémaphore, qui est de 128 dans l'exemple ci-dessus. Augmentez cette limite d'ID de sémaphore en exécutant en tant que rooténbsp;:echo "kernel.sem = 250 32000 32 2048" >> /etc/sysctl.conf /sbin/sysctl -p Les commandes ci-dessus ajouteront les nouvelles limites au fichier de configuration, prolongeant l'effet au cours des redémarrages, et elles activeront les nouvelles limites dans le noyau en cours d'exécution. Les hôtes Linux ont un nombre figé d'IDs de sémaphores IPC par processus qui empêche les utilisateurs de lancer énormément de VMs. En essayant de lancer trop de VMs, vous verriez s'afficher une erreur "Cannot create IPC semaphore". Pour lancer plus de VMs, vous devrez augmenter la limite d'IDs de sémaphore du processus VBoxSVC. Exécutez, en tant qu'administrateur, la commande prctl comme indiqué ci-dessous pour le processus VBoxSVC actuellement en fonction. Vous pouvez savoir l'ID du processus en utilisant la commande ps. prctl -r -n project.max-sem-ids -v 2048 <pid-of-VBoxSVC> Cela augmentera immédiatement la limite sémaphore du processus VBoxSVC actuellement en fonction et vous permettra de lancer davantage de VMs. Cependant, cette modification ne reste pas au redémarrage de VBoxSVC. Si l'utilisateur qui lance VirtualBox est l'administrateur, exécutez la commande suivante : prctl -n project.max-sem-ids -v 2048 -r -i project user.root À partir de là, le démarrage de nouveaux processus tiendra compte de la limite de 2048. Vous pouvez alors vous reconnecter ou fermer toutes les VMs et redémarrer VBoxSVC. Vous pouvez vérifier la limite actuelle d'ID de sémaphore pour VBoxSVC en utilisant la commande suivante : prctl -n project.max-sem-ids -i process <pid-of-VBoxSVC> Si l'utilisateur qui exécute VirtualBox n'est pas administrateur, vous devez ajouter la propriété au projet par défaut de l'utilisateur. Créez le projet par défaut et réglez la limite en exécutant en tant qu'administrateur : projadd -U <nomutilisateur> user.<nomutilisateur> projmod -s -K "project.max-sem-ids=(priv,2048,deny)" user.<nomutilisateur> Remplacez "<nomutilisateur>" avec le nom d'utilisateur exécutant VirtualBox. Puis reconnectez-vous sous le nom de cet utilisateur qui pourra exécuter plus de 120 VMs. À partir de la version 1.4, VirtualBox fournissait le support les ports série virtuels qui, pour l'instant, était plutôt compliqué à paramétrer avec la séquence des commandes VBoxManage setextradata. Depuis la version 1.5, cette façon de paramétrer les ports série n'est plus nécessaire et obsolète. Pour paramétrer les ports série virtuels, utilisez les méthodes décrites maintenant au . Pour être rétro-compatible, les anciennes commandes setextradata, dont la description ci-dessous est issue de l'ancienne version du manuel, restent valables côté de la nouvelle façon de configurer les ports série. Il s'en suit que si la première méthode de configuration des ports série ne marche pas, assurez-vous que la VM en question ne contient pas d'anciennes données de configuration actives telles que écrites ci-dssous. L'ancienne séquence de configuration d'un port série utilisait les 6 commandes suivantes : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/serial/0/Config/IRQ" 4 VBoxManage setextradata "nom VM" "VBoxInternal/Devices/serial/0/Config/IOBase" 0x3f8 VBoxManage setextradata "nom VM" "VBoxInternal/Devices/serial/0/LUN#0/Driver" Char VBoxManage setextradata "nom VM" "VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Driver" NamedPipe VBoxManage setextradata "nom VM" "VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Config/Location" "\\.\pipe\vboxCOM1" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/serial/0/LUN#0/AttachedDriver/Config/IsServer" 1 Cela définit un port série dans l'invité avec les paramètres par défaut de COM1 (IRQ 4, adresse E/S 0x3f8) et le paramètre Location suppose que cette configuration est utilisée sur un hôte Windows, car on utilise la syntaxe de tuyau (pipe) nommé Windows. Gardez à l'esprit que sur les hôtes Windows, un tuyau nommé doit toujours commencer par \\.\pipe\. Sur Linux, s'appliquent les mêmes paramètres de configuration, sauf que vous pouvez choisir le nom du chemin de Location plus librement. Les sockets du domaine local se mettent n'importe où, pourvu que l'utilisateur qui exécute VirtualBox ait le droit de créer un nouveau fichier dans le répertoire. La dernière commande ci-dessus définit que VirtualBox agit comme un serveur, c'est-à-dire qu'il crée lui-même le tuyau nommé au lieu de se connecter à un autre qui existe déjà. En mode NAT, on affecte à l'interface réseau de l'invité une plage IPv4 10.0.x.0/24 par défaut, où x correspond à l'instance d'une interface NAT +2. Donc, x vaut 2 quand il n'y a qu'une instance NAT d'active. Dans ce cas, l'invité se voit affecter l'adresse 10.0.2.15, la passerelle est définie sur 10.0.2.2 et on peut trouver le serveur de noms sur 10.0.2.3. Si, pour une raison quelconque, vous devez modifier le réseau NAT, ce qui se fait avec la commande suivante : VBoxManage modifyvm "nom VM" --natnet1 "192.168/16" Cette commande réserverait les adresses réseaux de 192.168.0.0 à 192.168.254.254 à la première instance réseau NAT de "nom VM". On affecterait à l'invité l'IP 192.168.0.15 et on pourrait trouver la passerelle par défaut sur 192.168.0.2. Pour un amorçage réseau en mode NAT, VirtualBox utilise par défaut le serveur TFTP inclu, qui se trouve à l'adresse 10.0.2.4. Ce comportement par défaut devrait très bien fonctionner pour les scénari de démarrage à distance courants. Cependant, il est possible de modifier l'IP du serveur d'amorçage et l'emplacement de l'image de démarrage avec les commandes suivantes : VBoxManage modifyvm "nom VM" --nattftpserver1 10.0.2.2 VBoxManage modifyvm "nom VM" --nattftpfile1 /srv/tftp/boot/MyPXEBoot.pxe La performance de la pile NAT de VirtualBox est souvent déterminée par son interaction avec la pile TCP/IP de l'hôte et la taille de plusieurs tampons (SO_RCVBUF et SO_SNDBUF). Pour certaines configurations, les utilisateurs pourraient vouloir ajuster la taille des tampons pour une meilleure performance. Vous pouvez faire cela en utilisant les commandes suivantes (les valeurs s'expriment en kilo-octets peuvent varier de 8 à 1024) : VBoxManage modifyvm "nom VM" --natsettings1 16000,128,128,0,0 Cet exemple illustre le peaufinage des paramètres NAT. Le premier paramètre est le MTU, puis la taille du tampon d'envoi de la socket et la taille du tampon de réception de la socket, la taille initiale de la fenêtre d'envoi TCP, et enfin, la taille initiale de la fenêtre de réception TCP. Remarquez que la spécification de zéro revient à se rabattre sur la valeur par défaut. Chacun de ces tampons a une taille par défaut de 64Ko et un MTU par défaut de 1500. Par défaut, le moteur NAT de VirtualBox dirigera les paquets TCP/IP via l'interface par défaut affectée par la pile TCP/IP de l'hôte. (La raison technique en est que le moteur NAT utilise des sockets pour la communication.) Si, pour une raison quelconque, vous voulez changer ce comportement, vous pouvez dire au moteur NAT d'associer à une interface en particulier une adresse IP. Utilisez la commande suivante : VBoxManage modifyvm "nom VM" --natbindip1 "10.45.0.2" Après cela, le trafic sortant sera envoyé par interface ayant l'adresse IP 10.45.0.2. Merci de vous assurer que cette interface est active et en fonction avant cette affectation. Le moteur NAT offre par défaut les mêmes serveurs DNS à l'invité que ceux configurés sur l'hôte. Dans certains scenari, il peut être souhaitable de cacher les IPs du serveur DNS à l'invité, par exemple quand ces informations peuvent changer sur l'hôte après l'expiration des baux DHCP. Dans ce cas, vous pouvez dire au moteur NAT d'agir comme un proxy DNS en utilisant la commande suivante : VBoxManage modifyvm "nom VM" --natdnsproxy1 on Pour résoudre les noms de réseau, le serveur DHCP du moteur NAT offre une liste de serveurs DNS enregistrés de l'hôte. Si pour une raison quelconque, vous devez cacher cette liste de serveurs DNS et utiliser les paramètres du serveur DNS de l'hôte, forçant ainsi le moteur NAT de VirtualBox à intercepter les requêtes DNS et à les rediriger sur le résolveur de l'hôte, utilisez la commande suivante : VBoxManage modifyvm "nom VM" --natdnshostresolver1 on Remarquez que ce paramètre est identique au mode proxy DNS, cependant alors que le mode proxy ne redirige que les requêtes DNS sur les serveurs appropriés, le mode résolveur interprètera les requêtes DNS et utilisera l'.API DNS de l'hôte pour prendre les informations et les retourner à l'invité. Dans certains cas, il pourrait être utile d'intercepter le mécanisme de résolution de noms, en fournissant une adresse IP définie par l'utilisateur pour une requête DNS en particulier. Le mécanisme d'interception permet à l'utilisateur d'associer non seulement un hôte, mais aussi des domaines et même des conventions de nommage plus complexes si nécessaire. La commande suivante définit la règle d'association d'un nom et d'une IP spécifiée : VBoxManage setextradata "nom VM" \ "VBoxInternal/Devices/{pcnet,e1000}/0/LUN#0/Config/HostResolverMappings/ \ <nom uniq de la règle d'interception>/HostIP" <IPv4> VBoxManage setextradata "nom VM" \ "VBoxInternal/Devices/{pcnet,e1000}/0/LUN#0/Config/HostResolverMappings/ \ <nom uniq de la règle d'interception>/HostName" <nom de vhôte> La commande suivante définit une règle pour associer un échantillon de nom à une IP spécifiée : VBoxManage setextradata "nom VM" \ "VBoxInternal/Devices/{pcnet,e1000}/0/LUN#0/Config/HostResolverMappings/ \ <nom uniq de la règle d'interception>/HostIP" <IPv4> VBoxManage setextradata "nom VM" \ "VBoxInternal/Devices/{pcnet,e1000}/0/LUN#0/Config/HostResolverMappings/ \ <uniq name of interception rule>/HostNamePattern" <échantillonhôte> L'échantillon hôte peut inclure "|", "?" et "*". Cette exmple démontre la façon de demander au mécanisme du résolveur de l'hôte de résoudre tout le domaine et probablement des mirroirs du site www.blocked-site.info avec l'IP 127.0.0.1: VBoxManage setextradata "nom VM" \ "VBoxInternal/Devices/e1000/0/LUN#0/Config/HostResolverMappings/ \ all_blocked_site/HostIP" 127.0.0.1 VBoxManage setextradata "nom VM" \ "VBoxInternal/Devices/e1000/0/LUN#0/Config/HostResolverMappings/ \ all_blocked_site/HostNamePattern" "*.blocked-site.*|*.fb.org" Le mécanisme de résolution de l'hôte devrait être activé pour utiliser les règles d'association définies par l'utilisateur (merci de voir pour plus de détails). Par défaut, le cœur de NAT utilise des alias et des ports aléatoires quand il génère un alias pour la connexion. Cela fonctionne bien pour la plupart des protocoles comme SSH, FTP et ainsi de suite. Mais certains protocoles pourraient nécessiter un comportement plus transparent ou dépendre du vrai numéro de port pour envoyer un paquet. Il est possible de modifier le mode NAT avec l'interface VBoxManage avec les commandes suivantes : VBoxManage modifyvm "nom VM" --nataliasmode1 proxyonly and VBoxManage modifyvm "Linux Guest" --nataliasmode1 sameports Le premier exemple désactive les alias et passe NAT en mode transparent, le deuxième exemple renforce la préservation des numéros des ports. Ces modes peuvent se combiner si nécessaire. Vous pouvez changer les données DMI que VirtualBox fournit aux invités pour une VM spécifique. Utilisez les commandes suivantes pour configurer les informations DMI du BIOS : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor" "fabricant BIOS" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVersion" "Version BIOS" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSReleaseDate" "date publication BIOS" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSReleaseMajor" 1 VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSReleaseMinor" 2 VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSFirmwareMajor" 3 VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSFirmwareMinor" 4 VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor" "Fabricant Système" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemProduct" "Produit système" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVersion" "Version système" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemSerial" "Numéro de série système" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemSKU" "System SKU" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemFamily" "Famille système" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemUuid" "9852bf98-b83c-49db-a8de-182c42c7226b" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBoardVendor" "Fabricant carte" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBoardProduct" "Produit carte" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBoardVersion" "Version carte mère" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBoardSerial" "Série carte" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBoardAssetTag" "Tag Board" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBoardLocInChass" "Emplacement carte" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiBoardBoardType" 10 VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiChassisVendor" "Fabricant Chassis" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiChassisType" 3 VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiChassisVersion" "Version Chassis" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiChassisSerial" "Série Chassis" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiChassisAssetTag" "Tag Chassis" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiProcManufacturer" "GenuineIntel" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiProcVersion" "Pentium(R) III" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiOEMVBoxVer" "vboxVer_1.2.3" VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiOEMVBoxRev" "vboxRev_12345" Si une chaîne DMI n'est pas définie, la valeur par défaut de VirtualBox est utilisée. Pour définir une chaîne vide, utilisez "<EMPTY>". Remarquez que dans la liste ci-dessus, tous les paramètres cités (DmiBIOSVendor, DmiBIOSVersion mais pas DmiBIOSReleaseMajor) sont censés être des chaînes. Si la chaîne est un nombre valide, le paramètre est traité comme un nombre et la VM refusera probablement de démarrer avec une erreur VERR_CFGM_NOT_STRING. Dans ce cas, utilisez "string:<valeur>", par exemple, VBoxManage setextradata "nom VM" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemSerial" "string:1234" La modification de ces information cans peut \avérer nécessaire pour donner les informations DMI de l'hôte à l'invité afin d'empêcher Windows de demander une nouvelle clé du produit. Sur les hôtes Linux, vous pouvez obtenir les informations de BIOS DMI avec with dmidecode -t0et les informations du système DMI avec dmidecode -t1 VirtualBox peut être configuré pour présenter à l'invité une table ACPI personnalisée. Utilisez la commande suivante pour la configurer : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/acpi/0/Config/CustomTable" "/chemin/vers/table.bin" La configuration d'une table ACPI personnalisée peut empêcher Windows Vista et Windows 7 de demander une nouvelle clé du produit. Sur les hôtes Linux, on peut lire une des tables de l'hôte dans /sys/firmware/acpi/tables/. Par défaut, VirtualBox synchronise toutes les sources de l'heure dans une source d'heure unique, l'heure de l'hôte monotonic. Cela reflète les suppositions de nombreux systèmes d'exploitation invités qui s'attendent à ce que toutes les sources d'heure reflètent l'heure "la pendule". Dans des circonstances spéciales, il peut être cependant utile de faire en sorte que le TSC (time stamp counter) de l'invité reflète le temps effectif passé à exécuter l'invité. Ce mode de gestion spécial du TSC peut s'activer individuellement par VM et, pour de meilleurs résultats, il ne faut l'utiliser qu'en association avec la virtualisation matérielle. Pour activer ce mode, utilisez la commande suivante : VBoxManage setextradata "nom VM" "VBoxInternal/TM/TSCTiedToExecution" 1 Pour inverser le mode de gestion TSC par défaut, utilisez : VBoxManage setextradata "nom VM" "VBoxInternal/TM/TSCTiedToExecution" Remarquez que si vous utilisez le mode de gestion TSC spécial avec un système d'exploitation invité qui est très strict quant à la cohérence des sources de l'heure, il se peut que vous receviez un message d'avertissement ou d'erreur lié à l'incohérence de l'heure. Cela peut aussi rendre l'heure non fiable avec certains systèmes d'exploitation invités en fonction de leur utilisation du TSC. Pour certains objectifs, il peut être utile d'accélérer ou de ralentir l'horloge virtuelle de l'invité. Vous pouvez le faire comme suit : VBoxManage setextradata "nom VM" "VBoxInternal/TM/WarpDrivePercentage" 200 L'exemple ci-dessus doublera la vitesse de l'horloge de l'invité alors que VBoxManage setextradata "nom VM" "VBoxInternal/TM/WarpDrivePercentage" 50 ralentira l'horloge de l'invité. Remarquez que la modification du rythme de l'horloge virtuelle peut perturber l'invité et même provoquer un comportement anormal de l'invité. Par exemple, une vitesse plus élevée signifie des timeouts plus courts pour les périphériques virtuels, provoquant un délai de réponse légèrement accru du périphérique virtuel, à l'origine d'une augmentation de la charge de l'hôte qui peut provoquer des échecs de l'invité. Notez aussi que tous les mécanismes de synchronisation du temps essaieront souvent de resynchroniser l'heure de l'invité sur l'heure de référence (qui est celle de l'hôte si les suppléments invité de VirtualBox sont actifs). Donc, toutes les synchronisation du temps devraient être désactivés si vous modifiez la vitesse de l'horloge invité comme indiqué ci-dessus (voir ). Les suppléments invité de VirtualBox garantissent que l'heure du système invité se synchronise avec l'heure de l'hôte. Plusieurs paramètres peuvent être personnalisés. Vous pouvez définir les paramètres pour une VM spécifique en utilisant la commande suivante : VBoxManage guestproperty set "nom VM" "/VirtualBox/GuestAdd/VBoxService/PARAMETER" VALUE où PARAMETER est un des suivants : --timesync-interval Spécifie l'intervalle entre deux synchronisations de l'heure invité par rapport à l'hôte. Par défaut, il est de 10000 ms (10 secondes). --timesync-min-adjust Valeur absolue minimum du débit mesuré en millisecondes pour faire les ajustements. Par défaut, c'est 1000 ms sur OS/2 et 100 ms ailleurs. --timesync-latency-factor Le multiplicateur de latence de demande de temps pour calculer le temps minimum ajusté dymamiquement. Il est par défaut de 8 fois, ce qui veut dire en détails : mesurer le temps mis pour déterminer l'heure de l'hôte (l'invité doit contacter le service hôte de la VM, ce qui peut prendre du temps), multiplier cette valeur par 8 et n'ajuster que si la différence d'heure entre l'hôte et l'invité dépasse cette valeur. Sinon, ne pas ajuster l'heure. --timesync-max-latency La latence de demande de l'horloge max acceptée. Par défaut, il s'agit de 250 ms. --timesync-set-threshold Début du débit absolu donné en millisecondes, où doit commencer le réglage de l'heure, plutôt que d'essayer de l'ajuster tout simplement. Il s'agit par défaut de 20 minutes. --timesync-set-start Définit l'heure à laquelle démarrer le service de syncchro du temps. --timesync-set-on-restore 0|1 Règle l'heure après que la VM a été restaurée d'un état sauvegardé si vous mettez 1 en paramètre (par défaut). Désactivez-le en mettant 0. Dans ce dernier cas, l'heure sera ajustée tout simplement, ce qui peut mettre du temps. Vous pouvez aussi spécifier tous ces paramètres comme options de la ligne de commandes du service BoxService. Une fois installés et démarrés, les suppléments invité de VirtualBox essaieront de synchroniser l'heure de l'invité avec celle de l'hôte. Vous pouvez l'empêcher en interdisant le service de l'invité de lire l'horloge de l'hôte : VBoxManage setextradata "nom VM" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1 À partir de VirtualBox 4.1, VirtualBox inclut un nouveau pilote de filtre réseau qui utilise la fonction Crossbow de Solaris 11. Par défaut, ce nouveau pilote est installé pour les hôtes Solaris 11 (construction 159 ci-dessus) qui le supportent. Pour obliger l'installation de l'ancien pilote de filtre réseau basé sur STREAMS, exécutez en tant qu'administrateur la commande suivante avant d'installer le paquet VirtualBox : touch /etc/vboxinst_vboxflt Pour obliger l'installation du pilote de filtre réseau basé sur Crossbow, exécutez en tant qu'administrateur la commande suivante avant d'installer le paquet VirtualBox : touch /etc/vboxinst_vboxbow Pour vérifier le pilote actuellement utilisé par VirtualBox, exeécutez : modinfo | grep vbox Si la sortie contient "vboxbow", cela indique que VirtualBox utilise le pilote de filtre réseau Crossbow, alors que le nom "vboxflt" indique que l'ancien pilote de filtre réseau STREAMS est utilisé. VirtualBox supporte des échantillons VNIC (Virtual Network Interface) pour configurer des VMs via des VLANs. Le support du réseau bridgé basé sur Crossbow a été introduit avec VirtualBox 4.1 et il exige Solaris 11 construction 159 ou supérieur. Un échantillon VNIC de VirtualBox est un VNIC dont le nom commence par "vboxvnic_template". Voici un exemple de la façon d'utiliser un échantillon VNIC pour configurer un VLAN pour des VMs. Créez un échantillon VNIC de VirtualBox en exécutant, en tant qu'administrateur : dladm create-vnic -t -l nge0 -v 23 vboxvnic_template0 Cela créera un VNIC temporaire par l'interface "nge0" avec l'ID de VLAN 23. Pour créer des échantillons VNIC résistant aux redémarrages de l'hôte, sautez le paramètre -t dans la commande ci-dessus. Vous pouvez vérifier l'état actuel des liens en utilisant : $ dladm show-link LINK CLASS MTU STATE BRIDGE OVER nge0 phys 1500 up -- -- nge1 phys 1500 down -- -- vboxvnic_template0 vnic 1500 up -- nge0 $ dladm show-vnic LINK OVER SPEED MACADDRESS MACADDRTYPE VID vboxvnic_template0 nge0 1000 2:8:20:25:12:75 random 23 Une fois que l'échantillon VNIC est créé, toutes les VMs ayant besoin de faire partie du VLAN 23 par l'interface physique "nge0" pourront utiliser le même échantillon VNIC. Cela simplifie et rend plus efficace la gestion des VMs sur des VLANs car les détails du VLAN ne sont pas stockés dans la configuration de chaque VM mais récupérés dans le modèle VNIC qve vous pouvez modifier n'importe quand en utilisant dladm. Outre l'ID du VLAN, des traductions VNIC peuvent être créées avec des propriétés supplémentaires telles que les limites de bande passante, le fanout du processeur, etc. Reportez-vous à la documentation du réseau de votre Solaris pour savoir comment faire cela. Ces propriétés supplémentaires, s'il y en a, s'appliquent aussi aux VMs qui utilisent l'échantillon VNIC. Par défaut, VirtualBox vous offre une interface réseau host-only L'ajout de davantage d'interfaces réseaux host-only sur les hôtes Solaris exige une configuration manuelle. Voici comment ajouter deux interfaces réseaux host-only supplémentaires. Vous eevez d'abord arrêter toutes les VMs en fonction et désactiver toutes les interfaces "vboxnet". Exécutez les commandes suivantes en tant qu'administrateur : ifconfig vboxnet0 unplumb Après vous être assuré que toutes les interfaces vboxnet sont désactivées, supprimez le pilote en utilisant : rem_drv vboxnetpuis éditez le fichier /platform/i86pc/kernel/drv/vboxnet.conf et ajoutez une ligne pour les nouvelles interfaces : name="vboxnet" parent="pseudo" instance=1; name="vboxnet" parent="pseudo" instance=2;Ajoutez autant de lignes comme celles-ci que nécessaire et assurez-vous que le nombre d'"instance" soit implémenté de façon unique. Ensuite, rechargez le pilote vboxnet en utilisant : add_drv vboxnetMaintenant, activez toutes les interfaces en utilisant ifconfig vboxnetX plumb (où X peut être 0, 1 ou 2 dans ce cas) et une fois activée, vous pouvez alors configurer l'interface comme n'importe quelle interface réseau. Pour que les paramètres de vos nouvelles interfaces réseaux persistent entre les redémarrages, vous devrez éditer les fichiers /etc/netmasks, utilisez NWAM /etc/nwam/llp et ajoutez les entrées adéquates pour définir le masque réseau et l'IP statique de chacune de ces interfaces. L'installeur de VirtualBox ne met à jour ces fichiers de configuration que pour l'interface "vboxnet0" qu'il crée par défaut. VirtualBox est capable de produire ses propres fichiers cœur pour un débogage étendu si quelque chose ne va pas. Cela n'est actuellement disponible que sur les hôtes Solaris. On peut activer le CoreDumper en utilisant la commande suivante : VBoxManage setextradata "nom VM" VBoxInternal2/CoreDumpEnabled 1 Vous pouvez spécifier le répertoire à utiliser pour y mettre les fichiers cœur avec cette commande : VBoxManage setextradata "nom VM" VBoxInternal2/CoreDumpDir <chemin-du-répertoire>Assurez-vous que le répertoire que vous spécifiez se trouve sur un volume ayant un espace disque suffisant et où le processus VirtualBox a assez de droits pour écrire des fichiers dans ce répertoire. Si vous sautez cette commande et si vous ne spécifiez aucun répertoire où mettre les fichiers cœur, le répertoire actuel de l'exécutable de VirtualBox sera utilisé (ce qui échouerait vraisemblablement au moment de l'écriture des cœurs car ils sont protégés par des droits administrateur). Il est recommandé que voks définissiez explicitement un répertoire d'envoi des fichiers cœur. Vous devez spécifier le moment où les CoreDumper de VirtualBox devraient être récupérés. Cela se fait en utilisant les commandes suivantes : VBoxManage setextradata "nom VM" VBoxInternal2/CoreDumpReplaceSystemDump 1 VBoxManage setextradata "nom VM" VBoxInternal2/CoreDumpLive 1Vous devrez passer au moins une des deux commandes ci-dessus si vous avez activé les CoreDumper. Le réglage de CoreDumpReplaceSystemDump prévoit que la VM outrepasse le mécanisme cœur de l'hôte et en cas de de plantage, seul le de VirtualBox produirait le fichier cœur. Le réglage de CoreDumpLive demande à la VM de produire des cœurs à chaque fois que le processus de la VM reçoit un signal SIGUSR2. Après avoir produit le fichier cœur, la VM ne sera pas interrompu et continuera de fonctionner. Vous pouvez ainsi récupérer des cœurs du processus de la VM en utilisant : kill -s SIGUSR2 <VM-process-id> Les fichiers cœur produits par le CoreDumper de VirtualBox ont la forme core.vb.<ProcessName>.<ProcessID>, par exemple core.vb.VBoxHeadless.11321. Il existe plusieurs paramètres de personnalisation avancés pour déverrouiller le gestionnaire de VirtualBox, c'est-à-dire pour supprimer des fonctionnalités que l'utilisateur ne devrait pas voir. VBoxManage setextradata global GUI/Customizations OPTION[,OPTION...] où OPTION est un des mots-clés suivants : noSelector N'autorise pas le démarrage du gestionnaire de VirtualBox. Ceci affichera une fenêtre contenant un vrai message d'erreur. noMenuBar Les fenêtres de la VM ne contiendront pas de barre de menus. noStatusBar Les fenêtres de la VM ne contiendront pas de barre d'état. Pour désactiver toutes les personnalisations du gestionnaire de VM, faites VBoxManage setextradata global GUI/Customizations Les paramètres de données supplémentaires suivants sont disponibles, par machine, pour modifier le comportement de la fenêtre du sélecteur de VM selon certaines VMs : VBoxManage setextradata "VM name" PARAMETRE true où PARAMETRE peut être : GUI/HideDetails N'affiehe pas la configuration de VM d'une VM en particulier. Les fenêtre des détails sera tout simplement vide si on sélectionne cette VM. GUI/PreventReconfiguration Ne permet pas à l'utilisateur d'ouvrir la boîte de dialogue des paramètres d'une VM en particulier. GUI/PreventSnapshotOperations Empêche de prendre des instantanés d'une VM avec la GUI, pendant son exécution ou quand on coupe la VM. GUI/HideFromManager Cache une VM en particulier dans la fenêtre du sélecteur de VM. GUI/PreventApplicationUpdate Désactive la vérification automatique des mises à jour et cache l'élément de menu correspondant. Merci de remarquer que ces paramètres n'empêchent pas l'utilisateur de reconfigurer la VM avec VBoxManage modifyvm. Vous pouvez désactiver (c'est-à-dire black-lister) certaines entrées de l'onglet des paramèt!es globaux dans le sélecteur de VM : VBoxManage setextradata global GUI/RestrictedGlobalSettingsPages OPTION[,OPTION...] où OPTION est un des mots-clés suivants : General N'affiche pas l'onglet Général des paramètres. Input N'affiche pas l'onglet Entrée des paramètres. Update N'affiche pas l'onglet Mise à jour des paramètres. Language N'affiche pas l'onglet Langue des paramètres. Display N'affiche pas l'onglet AAffichage des paramètres. Network N'affiche pas l'onglet Réseau des paramètres. Extensions N'affiche pas l'onglet Extensions des paramètres. Proxy N'affiche pas l'onglet Proxy des paramètres. C'est un paramètre global. Toutes les combinaisons de ce qui précède est possible . Pour restaurer le comportement par défaut, utilisez VBoxManage setextradata global GUI/RestrictedGlobalSettingsPages Vous pouvez désactiver (c'est-à-dire black-lister) certaines actions du menu dans la fenêtre de la VM : VBoxManage setextradata "nom VM" GUI/RestrictedRuntimeMenus OPTION[,OPTION...] où OPTION est l'un des mots-clés suivants : All N'affiche pas de menu dans la fenêtre de la VM. Machine N'affiche pas le menu Machine dans la fenêtre de la VM. View N'affiche pas le menu Vue dans la fenêtre de la VM. Devices N'affiche pas le menu Périphéhiques dans la fenêtre de la VM. Help N'affiche pas le menu Aide dans la fenêtre de la VM. Debug N'affiche pas le menu Débogage dans la fenêtre de la VM. Le menu de débogage n'est visible que si on démarre la GUI avec des paramètres spécial en ligne de commandes ou des paramètres de variables d'environnement particulières. C'est un paramètre spécifique à chaque VM. Toute combinaison de ce qui précède est possible. Pour restaurer le comportement par défaut, lancez : VBoxManage setextradata "VM name" GUI/RestrictedRuntimeMenus Vous pouvez désactiver (c'est-à-dire black-lister) certains éléments de la barre d'état : VBoxManage setextradata "nom VM" GUI/RestrictedStatusBarIndicators OPTION[,OPTION...] où OPTION est un des mots-clés suivants : HardDisks N'affiche pas l'icône du disque dur dans la barre d'état de la fenêtre de la VM. Par défaut, l'icône de disque dur ne s'affiche que si la configuration de la VM contient un ou plusieurs disques durs. OpticalDisks N'affiche pas l'icône du CD dans la barre d'état de la fenêtre de la VM. Par défaut, l'icône du CD ne s'affiche que si la configuration de la VM contient un ou plusieurs lecteurs CD. FloppyDisks N'affiche pas l'icône du lecteur amovible dans la barre d'état de la fenêtre de la VM. Par défaut, l'icône du lecteur amovible ne s'affiche que si la configuration de la VM contient un ou plusieurs lecteurs amovibles. Network N'affiche pas l'icône du réseau dans la barre d'état de la fenêtre de la VM. Par défaut, l'icône de réseau ne s'affiche que si la configuration de la VM contient un ou plusieurs adaptateurs réseaux. USB N'affiche pas l'icône de l'USB dans la barre d'état. SharedFolders N'affiche pas l'icône des dossiers dans la barre d'état. VideoCapture N'affiche pas l'icône de la capture vidéo dans la barre d'état. Features N'affiche pas l'icône des fonctions du processeur dans la barre d'état. Mouse N'affiche pas l'icône de la souris dans la barre d'état. Keyboard N'affiche pas l'icône du clavier dans la barre d'état. C'est un paramètre individuel à chaque VM. Toutes les combinaisons de ce qui précède est possible. Si vous spécifiez toutes les options, aucune icône n'est affichée dans la barre d'état de la fenêtre de la VM. Pour restaurer le comportement par défaut, utilisez VBoxManage setextradata "VM name" GUI/RestrictedStatusBarIndicators Vous pouvez désactiver (c'est-à-dire blacklister) certains modes visuels de la VM : VBoxManage setextradata "nom VM" GUI/RestrictedVisualStates OPTION[,OPTION...] où OPTION est un des mots-clés suivants : Fullscreen Ne pas autoriser le passage de la VM en mode plein-écran. Seamless Ne pas autoriser le passage de la VM en mode transparent. Scale Ne pas autoriser le passage de la VM en mode échelonné. C'est un paramètre individuel à chaque VM. Vous pouvez combiner n'importe comment ce qui précède. Pour restaurer le comportement par défaut, utilisez VBoxManage setextradata "nom VM" GUI/RestrictedVisualStates Pour désactiver toutes les combinaisons de touches de l'hôte, ouvrez les préférences et modifiez la touche hôte sur Aucune. Cela pourrait être utile lors de l'utilisation de VirtualBox en mode kiosk. Pour redéfinir ou désactiver certaines actions de la touche hôte, utilisez la commande suivante : VBoxManage setextradata global GUI/Input/MachineShortcuts "FullscreenMode=F,...." La liste suivante montre les actions possibles avec la touche hôte ainsi que leur raccourci par défaut avec la touche hôte. Le paramétrage d'une action sur Aucune désactivera cette action de la touche hôte. Action Touche par défaut Action TakeSnapshot T prend un instantané TakeScreenshot E fait une impression d'écran MouseIntegration I bascule l'intégration de la souris TypeCAD Del envoie Ctrl+Alt+Supp TypeCABS Backspace envoie Ctrl+Alt+Effacement Pause P Met la VM en pause Reset R réinitialisation (brutale) de l'invité SaveState enregistre l'état de la VM et ferme la VM Shutdown H appuie sur le bouton ACPI (virtuel) d'alimentation PowerOff coupe la VM (sans sauvegarder son état !) Close Q affiche la boîte de dialogue de fermeture de la VM FullscreenMode F passe la VM en plein écran SeamlessMode L passe la VM en mode transparent ScaleMode C passe la VM en mode échelonné GuestAutoResize G redimensionne automatiquement la fenêtre de l'invité WindowAdjust A redimension automatique de la fenêtre invité PopupMenu Home affiche un menu en mode plein écran/transparent SettingsDialog S ouvre la boîte de dialogue des paramètres de la VM InformationsDialog N affiche la fenêtre d'informations sur la VM NetworkAdaptersDialog affiche la boîte de dialogue des adaptateurs réseaux SharedFoldersDialog affiche la boîte de dialogue des dossiers partagés de la VM InstallGuestAdditions D mounte l'ISO contenant les suppléments invité Pour désactiver le mode plein-écran ainsi que le mode transparent, utilisez la commande suivante : VBoxManage setextradata global GUI/Input/MachineShortcuts "FullscreenMode=None,SeamlessMode=None" Vous pouvez interdire (c'est-à-dire blacklister) certaines ctions quand la VM s'arrête. Pour interdire des actions spécifiques, tapez : VBoxManage setextradata "nom VM" GUI/RestrictedCloseActions OPTION[,OPTION...] où OPTION est l'un des mots-clés suivants : SaveState N'autorise pas l'utilisateur à sauvegarder l'état de la VM quand elle s'arrête. Shutdown N'autorise pas l'utilisateur à éteindre la VM en envoyant l'événement ACPI couper à l'invité. PowerOff N'autorise pas l'utilisateur à couper la VM. Restore N'autorise pas l'utilisateur à revenir au dernier instantané lors de l'extinction de la VM. Il s'agit d'un paramètre individuel à chaque VM. Toutes les combinaison de ce qui précède est possible. Si vous spécifiez toutes les options, la VM ne pourra pas être éteinte. Le service Web de VirtualBox (vboxwebsrv) est utilisé pour contrôler VirtualBox à distance. Il est documenté en détails dans le Software Development Kit (SDK) de VirtualBox ; merci de voir . Comme la base client qui utilise cette interface grossit, nous avons ajouté des scripts de démarrage pour les systèmes d'exploitation que nous supportons. Les sections suivantes décrivent la manière de les utiliser. Le service Web de VirtualBox ne démarre jamais automatiquement suite à une installation standard. Sur Linux, le service web peut être démarré automatiquement au démarrge de l'hôte en ajoutant les paramètres adéquats au fichier /etc/default/virtualbox. Un paramètre est obligatoire, VBOXWEB_USER, qui doit être défini sur l'utilisateur qui démarrera alors les VMs. Les paramètres du tableau ci-dessous commencent tous par VBOXWEB_ (VBOXWEB_HOST, VBOXWEB_PORT etc.) : Paramètre Description Par défaut USER L'utilisateur sous lequel fonctionne le service web HOST L'hôte où on doit chercher le service web localhost PORT Le port où on doit chercher le service web 18083 SSL_KEYFILE Fichier de clé et du certificat du serveur, format PEM SSL_PASSWORDFILE Nom du fichier mot de passe de la clé du serveur SSL_CACERT Fichier de certificat CA, format PEM SSL_CAPATH Chemin du certificat CA SSL_DHFILE Nom du fichier DH ou longueur de la clé DH en octets SSL_RANDFILE Fichier contenant seed en générateur de nombre aléatoire TIMEOUT Timous de la session en secondes ; 0 désactive le timeouts 300 CHECK_INTERVAL Fréquence des vérifications des timeout en secondes 5 THREADS Nombre maximum de session simultanées possibles 100 KEEPALIVE Nombre maximum de requêtes avant de fermer une socket 100 ROTATE Nombre de fichiers journaux ; 0 désactive la journalisation 10 LOGSIZE Taille maximum d'un fichier journal en octets à récupérer 1Mo LOGINTERVAL Délai maximum en secondes pour ratraper l'enregistrement des journaux 1 day La définition du paramètre SSL_KEYFILE active le support SSL/TLS. L'utilisation de chiffrement est fortement recommandée, car sans cela, tout (même les mots de passe) sera transféré en clair. Sur les hôtes Solaris, le démon du service Web de VirtualBox est intégré à l'environnement SMF. Vous pouvez modifier les paramètres mais vous n'êtes pas obligé si ceux par défaut ci-dessous correspondent déjà à vos besoins :svccfg -s svc:/application/virtualbox/webservice:default setprop config/host=localhost svccfg -s svc:/application/virtualbox/webservice:default setprop config/port=18083 svccfg -s svc:/application/virtualbox/webservice:default setprop config/user=root Le tableau de la section précédente montrant le nom des paramètres et leurs réglages par défaut s'applique également à Solaris. Vous devez passer le nom des paramètres en minuscules et ajouter le préfixe config/, par exemple config/user ou config/ssl_keyfile. Si vous avez changé quelque chose, n'oubliez pas de lancer la commande suivante pour que les changements aient un effet immédiat :svcadm refresh svc:/application/virtualbox/webservice:default Si vous oubliez la commande ci-dessus, les paramètres ci-dessus seront utilisés au moment de l'activation du service. Vérifiez les réglages actuelles des propriétés avec :svcprop -p config svc:/application/virtualbox/webservice:default Lorsque tout est bien configuré, vous pouvez démarrer le service web de VirtualBox avec la commande suivante :svcadm enable svc:/application/virtualbox/webservice:default Pour plus d'informations sur SMF, merci de vous reporter à la documentation de Solaris. Sur Mac OS X, on utilise launchd pour démarrer le service web de VirtualBox. Vous pouvez trouver un fichier exemple de configuration dans $HOME/Library/LaunchAgents/org.virtualbox.vboxwebsrv.plist. Vous pouvez l'activer en changeant la clé Disabled de true en false. Pour démarrer manuellement le service, utilisez la commande suivante : launchctl load ~/Library/LaunchAgents/org.virtualbox.vboxwebsrv.plist Pour des informations supplémentaires sur la façon dont vous pourriez configurer les services de launchd, voir http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPSystemStartup/BPSystemStartup.html. À partir de VirtualBox 4.2, le service de ballon de mémoire, connu jadis comme le VBoxBalloonCtrl, a été renommé en VBoxWatchdog, ce qui intègre à présent plusieurs services de l'hôte qui sont conçus pour fonctionner dans un environnement serveur. Il s'agit des services : Contrôle du ballon de mémoire, qui prend en charge automatiquement d'un ballon de mémoire configuré pour une VM (voir pour une présentation du jeu de ballon avec la méom:re). Cela est surtout utile pour les environnements serveurs où les VMs peuvent solliciter de manière dynamique plus ou moins de mémoire pendant leur fonctionnement. Le service vérifie régulièrement que le ballon actuel d'une VM et sa RAM invitée disponible et il ajuste automatiquement le ballon de mémoire actuel en l'augmentant ou le réduisant selon le cas. Cette gestion ne s'applique qu'aux VMs en fonction ayant installé des suppléments invité éecents. La détection d'un isolement de l'hôte, qui offre un moyen de détecter si l'hôte ne peut plus atteindre une instance en particulier du serveur VirtualBox et qui prend les mesures appropriées telles que l'extinction, la sauvegarde de l'état actuel, voire la coupure de certaines VMs. Vous pouvez spécifier toutes les valeurs de configuration soit en ligne de commande, soit par des données supplémentaires globales, tandis que les valeurs en ligne de commandes ont toujours une priorité élevée si on las définit. Certaines des valeurs de configuration peuvent être également spécifiées sur une base individuelle par VM. Donc, l'ordre pour regarder les paramètres est : ligne de comande, données supplémentaires pour chaque VM (s'il y en a), données supplémentaires globales. Le contrôle des ballons de mémoire augmente ou réduit le ballon de mémoire des VMs à partir de la mémoire disponible sur les VMs et de la taille maximale désirée d'un ballon. Pour régler le contrôle du jeu de ballons mémoires, il faut paramétrer la taille que peut atteindre une VM. Vous pouvez le faire en ligne de commande avec --balloon-max <Taille en Mo>, individuellement pour chaque VM avec les données supplémentaires avec VBoxManage setextradata <VM-Name> VBoxInternal2/Watchdog/BalloonCtrl/BalloonSizeMax <Taille en Mo> ou en utilisant une donnée supplémentaire globale avec VBoxManage setextradata global VBoxInternal2/Watchdog/BalloonCtrl/BalloonSizeMax <Taille en Mo> Si vous ne spécifiez pas de taille maximale du ballon avec au moins un des paramètres ci-aessus, vous ne pourrez faire aucun jeu de ballon. Vous pouvez régler la taille incrémentale d'un ballon, en Mo, soit en ligne de commandes avec --balloon-inc <Taille en Mo>, soit en utilisant une donnée supplémentaire globale avec VBoxManage setextradata global VBoxInternal2/Watchdog/BalloonCtrl/BalloonIncrementMB <Taille en Mo> La taille d'incrémentation par défaut est de 256 Mo si vous ne spécifiez rien. La même chose marche pour une taille minimale incrémentée de ballon : en ligne de commande avec --balloon-dec <Taille en Mo> ou en utilisant une donnée supplémentaire globale avec VBoxManage setextradata global VBoxInternal2/Watchdog/BalloonCtrl/BalloonDecrementMB <Taille en Mo> La taille minimale incrémentale d'un ballon par défaut est de 128 Mo si vous n'indiquez rien. Pour définir la limite inférieure d'un ballon en Mo, c'est en ligne de commande avec --balloon-lower-limit <Taille en Mo> ou par une donnée supplémentaire globale avec VBoxManage setextradata global VBoxInternal2/Watchdog/BalloonCtrl/BalloonLowerLimitMB <Taille en Mo>. La limite inférieure par défaut est de 128 si vous n'indiquez rien. Pour détecter si l'hôte va être isolé, c'est-à-dire qu'il ne va plus pouvoir atteindre la session du serveur VirtualBox, l'hôte doit régler une valeur dans une donnée supplémentaire pour une période de temps. Si cette valeur n'est pas définie dans le délai du timeout, une fois ce délai dépassé, ce qu'on appelle une réponse à l'isolement de l'hôte sera envoyée aux VMs gérées. Vous pouvez contrôler les VMs gérées en définissant des groupes de VM et en affectant des VMs à ces groupes. Par défaut, aucun groupe n'est défini, ce qui veut dire que toutes les VMs du serveur seront gérées lorsqu'aucune réponse hôte ne sera reçue dans les 30 secondes. Pour définir en ligne de commandes les groupes gérés par la détection de l'isolement de l'hôte : --apimon-groups=<string[,stringN]> ou utilisez une donnée supplémentaire globale avec VBoxManage setextradata global VBoxInternal2/Watchdog/APIMonitor/Groups <chaîne[,chaîneN]> Pour définir le timeout d'isolement de l'hôte en ligne de commandes : --apimon-isln-timeout=<ms> ou utilisez une donnée supplémentaire globale avec VBoxManage setextradata global VBoxInternal2/Watchdog/APIMonitor/IsolationTimeoutMS <ms> Pour régler la réponse d'isolement finale en ligne de commandes : --apimon-isln-response=<cmd> ou en utilisant une donnée supplémentaire globale avec VBoxManage setextradata global VBoxInternal2/Watchdog/APIMonitor/IsolationResponse <cmd> Les commandes de réponse suivantes sont disponibles : none, qui ne fait rien. pause, qui met en pause l'exécution d'une VM. poweroff, qui éteint la VM en appuyant sur le bouton d'alimentation de la VM. La VM n'aura aucune chance de sauvegarder des données ou de lancer le processus d'extinction. save, qui enregistre l'état actuel de la machine et qui coupe ensuite la VM. Si la sauvegarde de l'état de la machine échoue, la VM sera mise en pause. shutdown, qui éteint la VM gentiment, en envoyant un événement ACPI d'extinction au système d'exploitation de la VM. L'OS a alors une chance de s'éteindre proprement. Pour des options et des paramètres plus avancés comme la vérification de la verbosité de la journalisation, l'aide intégrée à la ligne de commande est accessible avec --help. Sur Linux, vous pouvez démarrer automatiquement le service watchdog lors du démarrage de l'hôte en ajoutant les paramètres adéquats au fichier /etc/default/virtualbox. Un paramètre est obligatoire, VBOXWATCHDOG_USER, vous devez le personnaliser avec l'utilisateur qui démarrera les VMs. Pour une rétro compatibilité, vous pouvez spécifier également VBOXBALLOONCTRL_USER Les paramètres du tableau suivant comment tous par VBOXWATCHDOG_ (VBOXWATCHDOG_BALLOON_INTERVAL, VBOXWATCHDOG_LOGSIZE etc., et pour les paramètres qui existaient précédemment, vous pouvez utiliser les paramètres VBOXBALLOONCTRL_INTERVAL etc) : Paramètre Description Réglage par défaut USER L'utilisateur sous lequel fonctionne le service watchdog ROTATE Nombre de fichiers journaux ; 0 désactive la gestion des journaux 10 LOGSIZE Taille maximum du fichier journal, en octets, pour faire la gestion 1Mo LOGINTERVAL Intervalle de secondes maximum en secondes pour faire la rotation des journaux 1 day BALLOON_INTERVAL Intervalle de la vérification de la taille du ballon (msec) 30000 BALLOON_INCREMENT Incrémentation de la taille du ballon (Mo) 256 BALLOON_DECREMENT Diminution de la taille du ballon (Mo) 128 BALLOON_LOWERLIMIT Limite la plus basse de la taille du ballon (Mo) 64 BALLOON_SAFETYMARGIN Mémoire libre nécessaire pour diminuer la taille du ballon (Mo) 1024 Sur les hôtes Solaris, le démon du service watchdog de VirtualBox est intégré à l'environnement SMF. Vous pouvez modifier les paramètres, mais ce n'est pas obligatoire si ceux par défaut correspondent déjà à vos besoins :svccfg -s svc:/application/virtualbox/balloonctrl:default setprop config/balloon_interval=10000 svccfg -s svc:/application/virtualbox/balloonctrl:default setprop config/balloon_safetymargin=134217728 Le tableau de la section précédente expliquant les noms des paramètres et les réglages par défaut s'applique également à Solaris. Vous devez passer les noms des paramètres en minuscules et ajouter un préfixe config/, par exemple config/user ou config/balloon_safetymargin. Si vous avez fait un changement, n'oubliez pas de lancer la commande suivante pour donner aux changements un effet immédiat :svcadm refresh svc:/application/virtualbox/balloonctrl:default Si vous oubliez la commande ci-dessus, les paramètres précédents seront utilisés lors de l'activation du service. Vérifiez les paramètres des propriétés actuels avec :svcprop -p config svc:/application/virtualbox/balloonctrl:default Quand tout est configuré correctement, vous pouvez démarrer le service watchdog de VirtualBox avec la commande suivante :svcadm enable svc:/application/virtualbox/balloonctrl:default Pour plus d'informations sur SMF, merci de vous reporter à la documentation de Solaris. À partir de VirtualBox 4.2.0, il existe un autre pack d'extension, VNC, open source et qui remplace l'intégration précédente du protocole d'accès à distance VNC. C'est du code expérimental et il ne sera d'abord disponible que dans le paquet du code source de VirtualBox. Une grande partie du code est issue de contributions d'utilisateurs et elle n'est en aucun cas supportée par Oracle. La gestion du clavier est très sérieusement limitée et seul la couche du clavier américain fonctionne. Les autres plans de clavier auront au moins quelques touches, qui produiront de mauvais résultats (avec des effets souvent très surprenants), et pour les plans ayant des différences significatives avec le plan de clavier américain, ils sont très probablement inutilisables. Il est possible d'installer à la fois le pack d'extension VirtualBox d'Oracle VM et VNC, mais on ne peut activer qu'un module VRDE à la fois. La commande suivante passe en module VRDE de VNC dans VNC : VBoxManage setproperty vrdeextpack VNC La configuration de l'accès à distance fonctionne de la même façon que VRDP (voir ), avec quelques limites : VNC ne supporte pas la spécification de plusieurs numéros de ports et l'authentification se fait différemment. VNC ne peut gérer que l'authentification par mot de passe et il n'y a aucune possibilité d'utiliser le hachage de mots de passe. Il ne reste pas d'autre choix que de donner un mot de passe en clair dans la configuration de VNC, ce qu'on peut faire avec la commande suivante :VBoxManage modifyvm "nom VM" --vrdeproperty VNCPassword=secret L'utilisateur est responsable du secret de son mot de passe et vous devriez le supprimer quand vous donnez la configuration d'une VM à quelqu'un d'autre, quelle que soit la finalité. Certains serveurs VNC prétendent qu'ils gardent le mot de passe "chiffré dans leur configuration. Ce n'est pas du vrai chiffrement, ce ne sont que des mots de passe, ce qui est exactement aussi sécurisé que les mots de passe en clair. La commande suivante revient à VRDP (s'il est installé) : VBoxManage setproperty vrdeextpack "Oracle VM VirtualBox Extension Pack" À partir de VirtualBox 4.2.0, il est possible de démarrer des VMs automatiquement à l'amorçage du système sur Linux, Solaris et Mac OS X, pour tous les utilisateurs. Sur Linux, le service autostart s'active en définissant deux variables de /etc/default/virtualbox. La première est VBOXAUTOSTART_DB, qui contient un chemin absolu vers le répertoire de la base de données existante. Tous les utilisateurs devraient avoir un accès en écriture au répertoire pour démarrer automatiquement des machines virtuelles. En outre, vous devriez donner au répertoire le bit sticky. La deuxième variable est VBOXAUTOSTART_CONFIG, qui fait pointer le service vers le fichier de configuration d'autostart utilisé lors du démarrage pour déterminer s'il faut autoriser des utilisateurs individuels à démarrer une VM automatiquement et les délais de démarrage de la configuration.Vous pouvez mettre le fichier de configuration dans /etc/vbox et il contient plusieurs options. Une s'appelle default_policy qui contrôle si le service autostart autorise ou non les utilisateurs non dans la liste d'exceptions à démarrer des VMs. La liste d'exceptions commence par exception_list et elle contient une liste de nom d'utilisateurs séparée par des virgules.De plus, vous pouvez configurer un délai de démarrage propre à chaque utilisateur pour éviter une surcharge de l'hôte. Une configuration modèle est présentée ci-dessous : # La politique par défaut est d'interdire le démarrage d'une VM, l'autre # choix étant "allow". default_policy = deny # Bob est autorisé à démarrer des machines virtuelles, mais chacun à intervalle # de 10 secondes bob = { allow = true startup_delay = 10 } # Alice n'est pas autorisé à démarrer des machines virtuelles, utile pour # exclure certains utilisateurs si la politique par défaut est allow. alice = { allow = false } Tout utilisateur voulant activer autostart pour des machines en particulier doit définir le chemin du répertoire de la base de données autostart avec VBoxManage setproperty autostartdbpath <Autostart directory> Sur les hôtes Solaris, Le démon autostart de VirtualBox est intégré à l'environnement SMF. Pour l'activer, vous devez faire pointer le service vers un fichier de configuration existant qui est au même format que sur Linux (voir ) : svccfg -s svc:/application/virtualbox/autostart:default setprop config/config=/etc/vbox/autostart.cfg Quand tout est bien configuré, vous pouvez démarrer le service autostart de VirtualBox avec la commande suivante :svcadm enable svc:/application/virtualbox/autostart:default Pour plus d'informations sur SMF, merci de vous reporter à la documentation de Solaris. Sur Mac OS X, on utilise launchd pour démarrer le service autostart de VirtualBox. Vous pouvez trouver un fichier de configuration exemple dans /Applications/VirtualBox.app/Contents/MacOS/org.virtualbox.vboxautostart.plist. Pour activer le service, copiez le fichier dans /Library/LaunchDaemons et passez la clé Disabled de true à false. Par ailleurs, remplacez le deuxième paramètre par un fichier de configuration existant et qui est au même format que sur Linux (voir ). Pour démarrer le service à la main, utilisez la commande suivante : launchctl load /Library/LaunchDaemons/org.virtualbox.vboxautostart.plist Pour avoir des informations supplémentaires sur la façon dont les services launchd pourraient se configurer, voir http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPSystemStartup/BPSystemStartup.html. Si le modèle d'instantané de VirtualBox ne suffit pas, il est possible d'activer un mode spécial qui permet de configurer des connexions de supports de stockage pendant que la VM est en pause. L'utilisateur doit être sûr que les données du disque restent cohérentes pour l'invité car, tout comme avec le montage à chaud, l'invité n'est pas informé des médias déconnectés ou nouvellement connectés. Vous pouvez activer le mode de gestion experte du stockage pour chaque VM en exécuting : VBoxManage setextradata "nom VM" "VBoxInternal2/SilentReconfigureWhilePaused" 1 Vous pouvez reconfigurer les connexions de supports de stockage pendant que la VM est en pause en utilisant : VBoxManage storageattach ...