Vous avez une machine avec plusieurs systèmes d'exploitation (multi boot) et vous en avez assez de devoir redémarrer pour basculer sur un autre système. A part avoir une autre machine, la solution peut être de virtualiser.
Bien évidement, il est possible de virtualiser entièrement. Ce qui revient à créer une machine virtuelle traditionnelle avec son (ou ses) disque(s) dur(s) virtuel(s). Oui mais alors on perds de la place disque dur physique du fait de l’existence de deux machines : une physique et l'autre virtuelle.
Mais il est également possible d'utiliser un système réel en tant que système virtualisé. Pour information, VMware Workstation le permet et VirtualBox aussi grâce à son support du format de disque virtuel VMDK. Ainsi, plus de perte de place disque dur physique
En résumant, ce tutoriel indique les étapes suivantes :
Ce tutoriel est basé sur la configuration suivante :
Dans la configuration du profil utilisateur de Windows, j'ai déplacé tous les dossiers de travail (Documents, Images, Vidéos, Téléchargement ...) dans SDB2 (DataNTFS). Je procède systématiquement ainsi pour limiter au minimum requis ce qui est dans C. Cette partition SDB2, partition liée à Windows, est donc, de facto, inséparable de SDA1 (Windows).
Dans Mageia, voici la situation des disques en NTFS :
Notez que la partitions SDA5 (Ubuntu) n'est pas montée.
L'idée est de pouvoir virtualiser les installations physiques de Windows (SDA1) et Ubuntu (SDA5) depuis Mageia (SDA2).
Ce tutoriel part du principe que tous les systèmes d'exploitation sont déjà installés et que le sélecteur de système d'exploitation est déjà opérationnel.
Vous adapterez selon votre propre configuration.
Sous root :
# chmod 666 /dev/sda
# chmod 660 /dev/sda1
# chmod 660 /dev/sda5
# chmod 660 /dev/sdb2
Sous root :
# usermod -a -G disk utilisateur
Créons deux coquilles VMDK, soit une pour SDA (Windows et Ubuntu) et l'autre pour SDB (DataNTFS). La première coquille VMDK, soit SDA.vmdk, correspond aux systèmes d'exploitation (Windows et Ubuntu) tandis que la seconde, soit SDB.vmdk, correspond à la partition DataNTFS liée au système Windows.
En tant que simple utilisateur :
$ VBoxManage internalcommands createrawvmdk -filename /home/utilisateur/VirtualBox/SDA.vmdk -rawdisk /dev/sda
$ VBoxManage internalcommands createrawvmdk -filename /home/utilisateur/VirtualBox/SDB.vmdk -rawdisk /dev/sdb
Ce qui renvoie la réponse suivante pour le premier fichier VMDK (réponse identique pour le second VMDK) :
RAW host disk access VMDK file /home/utilisateur/VirtualBox/SDA.vmdk created successfully.
Nous avons notre coquille vide faisant office de pointeur, d'un poids de 630 Ko (pour une partition SDA1 de 58 Go dont 7.25 utilisé). Pas de perte de place
Par contre, nous pouvons remettre les droits sur /dev/sda1 et /dev/sda5 à 600 ainsi que sur /dev/sdb2.
Sous root :
# chmod 666 /dev/sda
# chmod 660 /dev/sda1
# chmod 660 /dev/sda5
# chmod 660 /dev/sdb2
Branchons ces deux fichiers VMDK dans la machine virtuelle, en prenant soin de sélectionner en premier celui de SDA, pour ne pas risquer de perturber ce "pôvre" Windows avec l'ordre des disques. Par contre, vous pouvez également cocher pour chaque disque VMDK l'option "Solid-State Drive" qui est censée booster.
Veuillez noter cependant qu'en suivant ce tutoriel, vous devrez sélectionner le système d'exploitation à démarrer. A ce niveau, toute validation d'un système d'exploitation non "chmodé" préalablement à la création de la coquille VMDK sera sanctionné par un échec de démarrage.
Ne pas oublier d'installer dans ce système virtualisé les Extensions VirtualBox ! Ce qui implique le redémarrage de la machine virtuelle.
Bien évidement, il est possible de virtualiser entièrement. Ce qui revient à créer une machine virtuelle traditionnelle avec son (ou ses) disque(s) dur(s) virtuel(s). Oui mais alors on perds de la place disque dur physique du fait de l’existence de deux machines : une physique et l'autre virtuelle.
Mais il est également possible d'utiliser un système réel en tant que système virtualisé. Pour information, VMware Workstation le permet et VirtualBox aussi grâce à son support du format de disque virtuel VMDK. Ainsi, plus de perte de place disque dur physique
En résumant, ce tutoriel indique les étapes suivantes :
- Installer le système d'exploitation sur partition physique qui sera ensuite virtualisé.
- Créer le fichier VMDK, soit le disque virtuel à utiliser par VirtualBox. En fait une coquille vide pointant vers la partition voulue.
- Création de la machine virtuelle.
- Installation des Additions VBox dans la machine virtuelle.
1- Machine de base et but
Ce tutoriel est basé sur la configuration suivante :
- SDA1 : Windows (NTFS)
- SDA2 : Mageia (Ext4) avec /home dans SDB
- SDA3 : Swap
- SDA5 : Ubuntu (Ext4) avec /home dans SDA5
- SDB1 : Home (Ext4) pour Mageia
- SDB2 : DataNTFS (NTFS)
Dans la configuration du profil utilisateur de Windows, j'ai déplacé tous les dossiers de travail (Documents, Images, Vidéos, Téléchargement ...) dans SDB2 (DataNTFS). Je procède systématiquement ainsi pour limiter au minimum requis ce qui est dans C. Cette partition SDB2, partition liée à Windows, est donc, de facto, inséparable de SDA1 (Windows).
Dans Mageia, voici la situation des disques en NTFS :
- SDA1 Windows : non monté
- SDB2 DataNTFS : auto-monté dans /mnt/DataNTFS
Notez que la partitions SDA5 (Ubuntu) n'est pas montée.
L'idée est de pouvoir virtualiser les installations physiques de Windows (SDA1) et Ubuntu (SDA5) depuis Mageia (SDA2).
Ce tutoriel part du principe que tous les systèmes d'exploitation sont déjà installés et que le sélecteur de système d'exploitation est déjà opérationnel.
Vous adapterez selon votre propre configuration.
2 - Changement des droits
Pour pouvoir exploiter la ou les partitions, il faut changer les droits sur les pseudo-fichiers correspondant. Manipulation à effectuer pour chaque partition désirée (SDAx) mais aussi pour le disque dur lui même (SDA).Sous root :
# chmod 666 /dev/sda
# chmod 660 /dev/sda1
# chmod 660 /dev/sda5
# chmod 660 /dev/sdb2
3 - Groupe disk
L'utilisateur doit faire partie du groupe disk. Cela permet de créer les fichiers VMDK en tant que simple utilisateur.Sous root :
# usermod -a -G disk utilisateur
4 - Création du fichier VMDK
Ce sera le fichier correspondant au disque dur employé par la machine virtuelle. En réalité une coquille vide pointant vers le disque réel désiréCréons deux coquilles VMDK, soit une pour SDA (Windows et Ubuntu) et l'autre pour SDB (DataNTFS). La première coquille VMDK, soit SDA.vmdk, correspond aux systèmes d'exploitation (Windows et Ubuntu) tandis que la seconde, soit SDB.vmdk, correspond à la partition DataNTFS liée au système Windows.
En tant que simple utilisateur :
$ VBoxManage internalcommands createrawvmdk -filename /home/utilisateur/VirtualBox/SDA.vmdk -rawdisk /dev/sda
$ VBoxManage internalcommands createrawvmdk -filename /home/utilisateur/VirtualBox/SDB.vmdk -rawdisk /dev/sdb
Ce qui renvoie la réponse suivante pour le premier fichier VMDK (réponse identique pour le second VMDK) :
RAW host disk access VMDK file /home/utilisateur/VirtualBox/SDA.vmdk created successfully.
Nous avons notre coquille vide faisant office de pointeur, d'un poids de 630 Ko (pour une partition SDA1 de 58 Go dont 7.25 utilisé). Pas de perte de place
5 - Remise en place des droits sur les pseudo-fichiers des disques durs
VirtualBox renvoie une erreur si on ouvre la machine virtuelle en ayant préalablement remis les droits de /dev/sda à 600. Par conséquent, nous ne pouvons pas/plus modifier les droits de /dev/sda qui restent à 666.Par contre, nous pouvons remettre les droits sur /dev/sda1 et /dev/sda5 à 600 ainsi que sur /dev/sdb2.
Sous root :
# chmod 666 /dev/sda
# chmod 660 /dev/sda1
# chmod 660 /dev/sda5
# chmod 660 /dev/sdb2
6 - Paramétrage de la machine virtuelle
Dans les paramétrage de la machine virtuelle, il faut opter pour un disque existant et prendre le fichier VMDK. Pour le choix du connecteur, tout dépend de la machine réelle. Dans mon cas, c'est un connecteur SATA.Branchons ces deux fichiers VMDK dans la machine virtuelle, en prenant soin de sélectionner en premier celui de SDA, pour ne pas risquer de perturber ce "pôvre" Windows avec l'ordre des disques. Par contre, vous pouvez également cocher pour chaque disque VMDK l'option "Solid-State Drive" qui est censée booster.
7 - Démarrage de la machine virtuelle
La machine virtuelle a fonctionné du premier coup, sans autre tracasserie.Veuillez noter cependant qu'en suivant ce tutoriel, vous devrez sélectionner le système d'exploitation à démarrer. A ce niveau, toute validation d'un système d'exploitation non "chmodé" préalablement à la création de la coquille VMDK sera sanctionné par un échec de démarrage.
Ne pas oublier d'installer dans ce système virtualisé les Extensions VirtualBox ! Ce qui implique le redémarrage de la machine virtuelle.
8 - Les avantages de ce type de montage
- Toute mise à jour du système est exploitable que le système soit en virtualisation ou non.
- Pour Windows, plus de problème de licence. Plus besoin d'avoir une version officielle sur disque physique et une version pirate totalement virtualisée.
- Plus besoin de redémarrer pour basculer sur l'autre système d'exploitation.
- Un gain de place car on peut éviter d'avoir deux versions : une sur disque physique et l'autre virtualisée.
9 - Les inconvénients de ce type de montage
- Peut paraitre difficile à mettre en œuvre.
- Astuce inutilisable sous Windows (1) vis à vis des systèmes non Microsoft. Windows ne sait pas gérer les partitions non Windows et il est ainsi impossible d'obtenir une ouverture des droits sur ces partitions.
- Astuce inutilisable sous Windows (2) du fait de son mode de gestion des périphériques. Il n'est pas évident, sous Windows, de savoir comment disques durs et partitions sont numérotés et la génération du fichier VMDK n'est vraiment pas facile.
10 - Avertissements
- Il faut "chmoder" chaque périphérique sur lequel on souhaite pouvoir accéder en virtualisant. Tout oubli sera sanctionné par un échec de démarrage.
- Vous ne devez jamais monter les partitions du système à virtualiser (démontez les éventuellement auparavant).
- Vous pouvez monter les partitions annexes liées à un système Windows tant qu'elles ne contiennent pas le système à virtualiser.
- Vous ne pouvez pas monter les partitions annexes liées à un système non Windows sous peine d'essuyer un échec. Par conséquent, la partition /home du système virtualisé doit être différente de la partition /home du système hôte.
Commentaires
Enregistrer un commentaire