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, via sa reconnaissance du format 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 :
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
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).
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
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 :
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. Idem pour SDB.
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 600 /dev/sda1
# chmod 600 /dev/sda5
# chmod 600 /dev/sdb2
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 (IDE ou 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.
La machine virtuelle fonctionne 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 ensuite d'installer dans ce système virtualisé les Extensions VirtualBox ! Ce qui implique le redémarrage de la machine virtuelle.
Veuillez noter impérativement que le fait de virtualiser une installation de Windows sur machine physique entraîne obligatoirement une réactivation de la licence. Même si cette licence est officielle et déjà activée. Cela s’explique par le fait que Windows voit un changement de machine puisqu'avec la virtualisation on passe d'une carte mère physique à une carte mère virtualisée.
Il en découle qu'il existe un choix à faire :
Car il faut bien être conscient que si on active la licence pour la machine virtuelle, il faudra à nouveau activer cette même licence dès que ce système sera démarré en réel, sans virtualiser.
Et au final, qui ne sera pas emmerdé ? Ceux qui utiliserons une version pirate, sans vouloir faire l'apologie des versions pirates.