Forum

Reprise du message précédent

J'ai suivi tes conseils :

1) Suppression de l'erreur de copié / collé de la fin (le plus facile)

2) Refonte du chapitre 5 concernant la remise en place des droits sur les pseudo-fichiers des disques durs

Ce qui donne ceci :



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



Par contre, il faut noter les points suivants :

En partant de Mageia sur SDA2 avec /Home (Mageia) sur SDB1:

* SDA1 Windows non monté + SDB2 DataNTFS monté : OK : fonctionne

* SDA5 GNU/Linux (peu importe laquelle) non monté avec /Home inclu dans SDA5 : OK : fonctionne

* SDA5 GNU/Linux (peu importe laquelle) non monté avec /Home sur SDB1 (avec un login différent) : non testé

Édité par teutates Le 18/04/2015 à 14h33

Petit complément :

J'ai fait le test suivant :
* SDA2 Mageia = /
* SDA6 = Fedora = /
* SDB1 = Home

Pour /home, les deux distributions sont sur la même partition, avec des noms utilisateurs différents. L'idée est de vérifier la fonctionnalité de l'astuce avec le même home pour les deux distributions.

J'ai fait ma petite cuisine pour créer mes deux VMDK pour tester ce type de montage.

Une fois la machine virtuelle constituée selon cette nouvelle approche, voilà l'historique des résultats :
1) La première fois, la virtualisation de Fedora a fonctionné. J'ai écrit un court fichier texte pus j’éteins cette Fedora virtualisée.
2) Depuis Mageia, je tente alors de visualiser mon fichier texte créé depuis Fedora virtualisé. Echec. Si je me connecte sous root (en console) pour avoir une idée, la commande ls me donne bien le nom de ce fichier texte mais me prévient auparavant d'une erreur d'entrée/sortie.
3) Je revirtualise la Fedora pour tomber sur un échec. Impossible de monter SDB1 (Home). Même en "chmodant" à nouveau /dev/sdb1 à 660 (ce qui correspond à laisser telle quelle la petite cuisine pour préparer la création du VMDK correspondant).
4) Suite à cela, si je tente de démarrer Mageia ou Fedora normalement, donc sans virtualiser, le démarrage est impossible car SDB1 ne peut être monté. J'ai du redémarré la machine sur PartedMagic pour faire un fsck /dev/sdb1 et réparrer afin de pouvoir démarrer Mageia ou Fedora.

Finalement, cette manipulation m'aura plutôt flingué l'intégrité de SDB1 (home). Pourquoi ?

En résumé, la cuisine valable pour Windows est indigeste pour les autres. Soit, pour le moment (jusqu'à trouver une solution) :
* Ne jamais monter la partition du système à virtualiser, quel que soit le système d'exploitation
* Toute partition NTFS liée à un Windows virtualisé peut être monté sur le système hôte
* Toute partition non-NTFS liée à un système non Windows virtualisé ne peut être monté sur le système hôte

Édité par teutates Le 18/04/2015 à 21h42

Bonjour,

après une ré-install toute fraîche de Win 7 64b et Mageia 5 64b sur un SSd tout neuf, j'ai donc la configuration suivante :



Je n'ai pas comme toi de répertoire "Documents utilisateur" Windows séparé, celui est intégré à Win7 comme une install normale.

Mon grub est bien installé et le lancement de Win7 à partir de celui-ci fonctionne sans pbs.

J'ai suivi ton excellent tuto pour créer le disque virtuel attaché à ma partition contenant Win7 et au lancement de la machine virtuelle je tombe bien sur le grub, et si je lance Windows, celui démarre et affiche le message d'erreur suivant puis reboot :



J'ai bien vérifié, mon sda1 contenant Win 7 est démonté. Par contre avant de le démonter j'ai vérifié ses droits avec Dolphin et il appartient à root, est-ce pour ça que ne fontionne pas ?

J'ai pourtant suivi à la lettre les différents chmod indiqués...

Une idée ?

Édité par Sylv_01 Le 07/05/2015 à 07h45

</div>

Je n'ai pas comme toi de répertoire "Documents utilisateur" Windows séparé, celui est intégré à Win7 comme une install normale.

Mon grub est bien installé et le lancement de Win7 à partir de celui-ci fonctionne sans pbs.

J'ai suivi ton excellent tuto pour créer le disque virtuel attaché à ma partition contenant Win7 et au lancement de la machine virtuelle je tombe bien sur le grub, et si je lance Windows, celui démarre et affiche le message d'erreur suivant puis reboot :



J'ai bien vérifié, mon sda1 contenant Win 7 est démonté. Par contre avant de le démonter j'ai vérifié ses droits avec Dolphin et il appartient à root, est-ce pour ça que ne fontionne pas ?

J'ai pourtant suivi à la lettre les différents chmod indiqués...

Une idée ?</div>



Se pourrait-i que ce soit les réglages de ta machine virtuelle ? Ton disque VMDF placé sur un connecteur IDE alors qu'en réalité ce devrait être un connecteur SATA ? Je crois que Windows est très sensible à cela.

Salut et désolé pour cette réponse tardive, le beau temps et les vacances m'appellent à ne pas rester trop coincé devant mon PC...

En fait j'ai vérifié par rapport à une autre machine virtuelle Win7 (présente sur mon 2nd disque SSD sous Mageia4), avec Win7 installé dans la Virtualbox, et qui fonctionne parfaitement.

Les 2 configurations sont identiques, excepté évidemment le disque (le fichier .vmdk pointant sur sda pour l'install en réelle pour la 1ère, et le fichier .vdi correspondant au disque de l'install virtuelle dans la 2nde).

Non, je penche plus pour un pb de droits d'accès, un chmod qui se fait pas ou mal, etc.

Pourrait-on comparer nos 2 fichiers .vmdk, puisque nos config ont l'air relativement similaire ?

Voici ce qui est écrit dans le mien (il suffit de l'éditer avec kwrite...):





D'ailleurs, c'est bizarre : dans la VirtualBox, le disque SDA apparaît en totalité (soit 237 go), alors que Win7 n'est installé que sur la partition sda1, de 60 go...

Édité par Sylv_01 Le 12/05/2015 à 18h57

Bonjour,



Voici le contenu de mon fichier VMDK (édité avec Kwrite) :







A priori, tout est identique (sauf les UUID évidément).



Dans mon cas, aussi ce disque VMDK apparait dans VirtualBox pour 80Go et c'est normal puisque c'est la totalité du disque, toutes partitions confondues.

YESSSSSSSSSSS !
J'y suis enfin arrivé
En fait tu avais raison : un Win 7 installé en dur et virtualisé n'aime pas le contrôleur SATA, il faut lui indiquer un contrôleur IDE, et dans mon cas ni de type PIIX3 ni PIIX4 mais ICH6...
Après s'être lancé et avoir fait les vérifications d'usages, mon Win7 est à présent opérationnel dans ma VB !
Dernier petit soucis à régler (mais loin d'être grave) : pas de son..
Encore merci à toi pour ton aide précieuse...

Euh !?! Tu m'intérresse fortement. Chez toi, ca passe avec un contrôleur IDE mais bloque avec le contrôleur SATA ? Je pensais que si la machine de base utilisait le SATA (comme la quasi totalité des machines actuelles, je suppose), il fallait prendre le SATA.



Pour le moment, j'ai tout fait via une machine virtuelle. J'ai d'ailleurs un projet en cours basé dessus en complément. Je dois très bientôt prendre des vacances et j'en profiterai pour mettre en pratique la virtualisation de Windows installé sur SDA1 par SATA (technologies moderne oblige). Ca complétera.



Pour info, dans ma machine virtuelle de tests, tous les disques virtuels sont sur connecteur SATA et la sous-machine pour virtualiser Windows a aussi le disque VMDK en connexion SATA. Ce qui m'amène à une autre question. Dans la machine virtuelle, le disque virtuel où est installé Windows (en SDA1) est sur le connecteur SATA (0). Dans la sous-machine virtuelle, le disque VMDK est également sur le connecteur SATA (0). Je suppose qu'une possibilité d'ennuis peut venir de là : mettre sur SATA(2), par exemple, au lieu de SATA (0). Évidement, en machine virtuelle, la numérotation est vite repérée. En machine réelle, soit on tatonne, soit on ouvre les entrailles de la machine et on regarde la doc de la carte mère.



Je vais tenter de trafiquer ma machine virtuelle pour mettre mon VMDK sur SATA (1) et voir le résultat.



Pour le son : as-tu installé les Extensions VBox ?

Édité par teutates Le 13/05/2015 à 19h42

En fait c'est étrange : effectivement en hardware mon SSD est bien en SATA.

La 2nd machine Win7 installée en virtuelle fonctionne bien en SATA.

Par contre lorsque je virtualise mon install réelle (pourtant elle aussi sur un disque SATA), je suis obligé de mettre un contrôleur IDE pour que ça fonctionne.

Pour rappel, le fichier SDA.vmdk dit ceci :



C'est ce qui ma fait tilter et mettre le contrôleur IDE dans la config de ma machine virtuelle.

Tu crois que si je change en "sata" dans le fichier .vmdk, je pourrais mettre un contrôleur SATA dans la config ? (je pense qu'il faut que les 2 soient identiques...)

Pour le son oui les extensions sont bien installées, il doit s'agir d'un pb de config également...

As-tu testé en éditant le fichier VMDK pour remplacer ide par sata ?

Oui, je viens de le faire : j'ai remplacé ide par sata dans le fichier .vmdk et dans la config j'ai remplacé le contrôleur IDE par un SATA : ça ne fonctionne pas (même erreur que précédemment).
J'ai remis un contrôleur IDE tout en laissant sata dans le fichier .vmdk : ça fonctionne.
Donc mon hypothèse qui tend à penser qu'il faut que les 2 soient identiques pour que ça fonctionne n'est pas la bonne...
Pour le son c'est ok, en fait le driver dans Win7 n'était pas correctement installé, maintenant c'est ok...

Je reviens sur le sujet. Profitant de mes (derniers) jours de congés, j'ai mis en pratique mon propre tutoriel sur ma configuration réelle. C'était le but, que je sache.

Ma configuration réelle est la suivante, avec tout en SATA (machine neuve oblige) :
* SDA1 Windows
* SDB Grub
* SDC2 Data
* SDD2 Ghost (images TrueImage)
Je n'ai noté (par simplification que les seules partitions NTFS. Le sélecteur de système Grub2 est sur SDB (SSD).

Ma machine virtuelle est ainsi constituée :
1) Système 64 bits
* 6 Go de RAM (sur 16Go en tout)
* 2 processeurs
2) Affichage
* 128 Mo vidéo
* Accélération 2D et 3D
3) Stockage
* Connecteur IDE : lecteurs CD/DVD
* Connecteur SATA :
-> Port SATA 0 : SDA.vmdk
-> Port SATA 1 : SDB.vmdk
-> Port SATA 2 : SDC.vmdk
-> Port SATA 3 : SDD.vmdk

J'avoue ne pas m'être cassé la tête pour l'ordre de branchement des disques VMDK. J'ai suivi l'ordre en me rappelant que, lorsque j'ai monté ma tour, j'avais alors fait très attention de suivre déjà ce même ordre (ayant tout planifié en profondeur).

Cette minutie a payé. La machine ainsi virtualisée fonctionne immédiatement. Je rappelle que j'ai virtualisé sous Mageia (SDB1) mon installation réelle de Windows sur SDA1.

Encore quelques bricoles à apporter mais des bricoles qui passent par l'installation des Extensions VirtualBox pour avoir les bons pilotes. Pas sorcier. Je ne me suis pas occupé du son puisque j'ai d'abord une grosse mise à jour de Norton à effectuer bien que le son dépende des extensions VBox.

Par contre, à noter que Acronis TrueImage voit un changement de machine (logique). De ce côté, je peux m'en accommoder. Car il y a pire. La licence Windows !

Cette licence Windows 7 est, initialement, donc sur la machine réelle (soit sur SDA1), tout à fait officielle. Évidemment, à avoir payé cette licence Windows 7, je l'ai activé depuis longtemps, soit depuis fin mars 2012. Or, éclair de lucidité, je pense à vérifier l'état de la licence Windows. Et, paf, dans les dents ! Plus que 3 jours pour activer cette licence ! Donc, 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. Je comprends que 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 (autre) carte mère virtualisée.

Il en découle qu'il existe un choix à faire :
* soit activer à nouveau Windows et ne servir désormais que de la version virtualisée,
* soit abandonner la virtualisation.
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.

Edit :
J'ai modifié en conséquence le tutoriel :
* 10 Avertissements généraux : penser à inclure éventuellement le disque où se situe Grub
* 11 Avertissement sur la licence Windows

Édité par teutates Le 30/05/2015 à 20h12

</div>



</div>

Effectivement : Alien ! Merci de m'y faire penser. Bien qu'ayant trouvé une autre solution, davantage passe partout de fait, je retenterai l'affaire quand j'aurais un peu de temps (le temps de remonter une machine virtuelle de test entre autre).