Que ce soit pour tester de nouvelles distributions, des environnements de production, avoir un WilainOS sous la main en cas de besoin, ou garder son bureau GNU/Linux et malgré tout pouvoir développer en environnement "clientèle", la virtualisation est un outil indispensable aujourd'hui. Il existe de nombreuses solutions fonctionnelles sous Linux pour permettre de virtualiser un environnement. Mais malgré tout le bien que je pense de VirtualBox ou Qemu, VMWare reste de loin le plus stable et le plus efficient de tous. Au point d'avoir pu l'utiliser pendant un an en continu comme station de travail principale pour des développements lourd.

Maintenant VMWare Workstation reste payant. Alors voici comment utiliser VMPlayer qui lui est gratuit pour faire rigoureusement la même chose avec juste un peu plus d'huile de coude.

Introduction

VMWare est un fantastique outil permettant d'exécuter des OS guest sur un OS host. Vous pouvez ainsi lancer Windows dans Linux, Linux dans Linux, ReactOS dans linux, etc...

Contrairement à d'autres systèmes, VMWare n'émule pas le processeur. Le code est exécuté nativement sur l'unité physique permettant des performances totalement comparables à un environnement natif. Le pendant de cette approche est que seul les OS i86 peuvent devenir des guests.

La couche matérielle, est elle émulée. C'est là la principal perte de performance de la plateforme. Perte limitée par l'utilisation des pilotes optimisés contenus sur les Guest Tools. Limitée aussi si l'on utilise un disque physique dédié comme espace de stockage plutôt qu'un disque virtuel.

Installation de VMPlayer

VMPlayer s'installe comme n'importe quel autre logiciel en téléchargeant le paquet et en l'installant via un urpmi VMPlayer.XXX.rpm. Ceci fait, il va nous falloir compiler les modules kernels de VMWare nécessitant le téléchargement préalable des sources du votre kernel. Ensuite, l'installation du rpm provoque la compilation et l'installation des modules nécessares. En effet, depuis la 2.5, il n'est plus nécessaire de lancer vmware-config.pl. L'inconvénient de cette approche apparaît cependant lors d'un changement de kernel, vous obligeant à desinstaller puis réinstaller le RPM. Après cela, VMWare devient le service /etc/init.d/vmware que l'on peut lancer (service vmware start) ou arrêter à loisir.

Création de la machine virtuelle

Pour fabriquer la machine virtuelle, rien de plus simple. Choisissez un emplacement approprié sur votre disque et créez un nouveau dossier. Allez dans ce dossier et créez un fichier vm.vmx que vous pouvez récupérer en version générique ici. Maintenant voyons un peu ce que cela contient.

Définition des options globales

config.version = "8"
virtualHW.version = "6"
uuid.action = "create"


guestOS = "winxppro"

displayName = "VM Native"

Nous avons ici les versions qui indiquent que notre VM est conçue une version 6.x de VMWare Worstation et qu'elle est donc optimum pour VMPlayer 2.x. Placez un virtualHW.version="4" pour une Workstation 5.x.

Suit la définition de l'OS "invité" qui permet officiellement d'optimiser certains paramétrage internes de VMWare. Personnellement je n'ai jamais vu ce que changeait cette valeur. Et comme je peux utiliser le même VMX pour plusieurs OS en multi boot, il semble bien que rien n'empêche un Linux de fonctionner en mode "winxppro".

Enfin nous avons le petit nom à notre VM qui sera affiché dans la barre de titre du player.

Processeur et mémoire

Nous allons ici commencer par définir le nombre de processeurs à simuler. Ce nombre ne peut dépasser 2, et ne doit dans tous les cas pas être supérieur au nombre réel de processeur. Le multi-processeur virtuel n'est pas forcement simulé, VMPlayer va utiliser effectivement les CPU physiques disponibles. Ainsi pour de meilleur performances de la machine hôte il est conseillé de ne pas consacrer plus de la moitié des cores de votre CPU à la VM. Ainsi gardez 1 pour un Dual-Core et dans certains cas vous pouvez passer à 2 pour un Quadri-Core.

numvcpus="1"

memsize = "1024"
MemAllowAutoScaleDown = "FALSE"
MemTrimRate = "-1"
sched.mem.pshare.enable=TRUE

Ensuite nous indiquons la taille de la mémoire à allouer à VMWare. Comme pour les CPU, Il faut raisonner en fonction de la mémoire physique et en garder suffisamment pour votre OS principal. Il est cependant possible avec MemAllowAutoScaleDown de réduire la mémoire allouée en fonction des besoins. Ainsi si vous avez déclaré un memsize à 1Go, et que vous autorisez le scaleDown, la mémoire réellement consommée peut être moindre. La conte-partie est une éventuelle latence.

Pour compléter, MemTrimRate permet de définir le rythme de désallocation de la mémoire mais je n'ai pas trouvé d'information sur l'unité (seconde, milli ? ).

Enfin, fonctionnalité intéressante, le page sharing consiste pour VMWare à utiliser une seule page mémoire sur le host lorsque le guest en a deux ou plus d'identique. Cela peut réduire la consommation sur le host, mais peut aussi réduire aussi les performances.

Outillage

L'outillage consiste en une série de paramétrages qui ne touche pas directement à la simulation mais à l'ergonomie d'utilisation de l'outil

tools.remindInstall = "TRUE"
tools.upgrade.policy = "upgradeAtPowerCycle"
tools.syncTime = "TRUE"   # Synchronise l'heure entre le guest et le host

isolation.tools.hgfs.disable = "FALSE"    # Permet à la souris de sortir de la VM sans CTRL+ALT
isolation.tools.dnd.disable = "FALSE"    # Autorise le Glisser-Déposer
isolation.tools.copy.enable = "TRUE"    # Autorise le Copier
isolation.tools.paste.enabled = "TRUE"  # Autorise le Coller

tools.remindInstall permet à la VM de vous prévenir si les "Guest Tools" ne sont pas installés, et tools.upgrade.policy si une nouvelle mise à jour de VmPlayer est disponible.

tools.syncTime demande à la VM de se synchroniser en permanence sur l'horloge de la machine physique. Attention cependant, cela ne va synchroniser que l'horloger matérielle. Par exemple sous Linux, au retour d'une pause, il est nécessaire de lancer un hwclock --hctosys pour synchroniser l'horloge système cette fois.

Ensuite nous avons une série de paramétrage bien pratiques avec dans l'ordre la gestion de la sortie du pointeur de souris de l'écran virtuel sans CTRL+ALT (hgfs), l'autorisation du glisser-déposer (dnd), l'autorisation de "copier" dans le VM (copy) et du "coller" (paste).

Carte Son

La configuration de la carte son permet, via virtualdev, d'émuler soit une Ensonic ES1371 (identifiant es1371), soit une bonne vieille Sound Blaster 16 (identifiant sb16) avec l'activation optionnelle de la partie synthétiseur FM (synth.operational).

sound.present = "TRUE"
sound.virtualdev = "es1371"
sound.synth.operational = "TRUE"

Comme pour toutes les configurations hardware qui vont suivre, vous avez ce paramètre present indiquant si le matériel est déclaré comme présent au démarrage ou pas.

Notez enfin que le son ne fonctionne sous VMWare qu'avec les pilotes OSS. Si vous utilisez ALSA, il est donc nécessaire de charger les modules de compatibilité, alsa-oss.

Ports série

Il est possible de configurer deux ports série (RS232C) qui seront reliés à des ports série physiques. L'option filename définit le device qui reçoit les données sur l'OS principal. Ici, avec Auto Detect, nous laissons VMWare le trouver tout seul.

serial0.present = "FALSE"
serial0.fileName = "Auto Detect"
serial0.autodetect = "TRUE"
serial0.hardwareFlowControl = "TRUE"
serial1.present= "FALSE"
serial1.fileName = "Auto Detect"
serial1.autodetect = "TRUE"
serial1.hardwareFlowControl = "TRUE"

Ports parralèle

Comme pour les ports série, deux ports parallèles (CENTRONIC) sont dispo et connectés à vos ports physiques. Le paramétrage est le même que pour le port série

parallel0.present = "FALSE"
parallel0.fileName = "Auto Detect"
parallel0.autodetect = "TRUE"
parallel0.bidirectional = "TRUE"
parallel1.present = "FALSE"
parallel1.fileName = "Auto Detect"
parallel1.autodetect = "TRUE"
parallel1.bidirectional = "TRUE"

Lecteur de disquette

Même concept pour le lecteur de disquette avec une nouveauté que nous retrouverons pour tous le matériel de type "amovible" ou que l'on peut brancher à chaud (ex. USB). Ainsi avec present à true (il y a bien un lecteur), startConnected peut-être à false (pas de disquette dedans). A chaque fois que ce paramètre est présent, il est possible de connecter à chaud le contenu (disquette ou périphérique) par l'interface graphique.

floppy0.present = "FALSE"
floppy0.filename = "Auto detect"
floppy0.startConnected = "FALSE"

HUB USB

La configuration de l'USB est assez simple. Notez la présente du present ET du autoconnect. En effet, comme pour le lecteur de disquette, si ce paramètre est à FALSE, les périphériques qui connectés à l'USB physique de la machine ne sont pas automatiquement prises en charges au démarrage, mais à chaud, par l'interface graphique

usb.present = "TRUE"
usb.generic.autoconnect = "FALSE"

Notez enfin que si le player prend la physiquement main sur une périphérique USB, le host n'en dispose plus. Faites donc attention si vous avez l'idée de connecter votre souris ou clavier par exemple

Accélération 3D

Cette option peut être intéressante dans certains cas, par exemple pour les gammers. Elle permet d'activer la prise en charge de la 3D en mode natif pour DirectX et logiciel pour OpenGL.

mks.enable3d = "FALSE"

Réseau

Il est possible de paramétrer deux cartes réseau selon trois technologies différentes. Via le paramétres virtualdev vous pouvez ainsi émuler une e1000 (Intel Pro Gigabit), une vlance ou une vmxnet (carte VMWare). La dernière est censée être la plus efficace mais dans les faits c'est l'e1000 qui est la plus reconnue sans installation de pilote supplémentaires.

Chaque carte peut être en mode "nat", "bridged" ou "host". Dans le dernier cas la carte est déconnectée du réseau, indépendante. En mode nat, la VM est comme connectée à un routeur NAT lui permettant d'avoir une IP qui n'a rien à voir avec celle de votre réseau physique, d'accéder au NET mais pas de se comporter en serveur (ou ne peut pas pinger la machine de l'extérieur). Le mode "bridged" permet quant à lui de disposer d'une carte qui se comporte comme une carte physique, et qui ira par exemple chercher une adresse IP sur votre serveur DHCP, sera pingable de l'extérieur et pourra donc être utilisé en serveur.

ethernet0.present = "TRUE"
ethernet0.connectionType = "nat"
ethernet0.addressType = "generated"
ethernet0.virtualDev = "e1000"
ethernet0.generatedAddressOffset = "0"
ethernet1.present="TRUE"
ethernet1.connectionType = "bridge"
ethernet1.addressType = "static"
ethernet1.Address = "00:0c:29:59:aa:eb"
ethernet1.virtualDev = "e1000"
ethernet1.generatedAddressOffset = "0"

Lorsque l'on utilise le mode "bridge", il peut être pratique de spécifier une adresse MAC distincte et connue. C'est le rôle de la valeur "static" pour le paramètre addressType. Dans ce cas, votre adresse MAC est à renseigner via le paramètre address.

Dans le cas du "nat", on laisse VMPlayer trouver une adresse qui ne rentre pas en conflit avec d'éventuelles autres machines virtuelles allumées, en spécifiant un addressType à generated. Au lancement de la VM, une nouvelle MAC sera choisie et inséré dans le fichier de configuration avec le paramètre generatedAddress.

A noter enfin que les débits entre la machine physique et la machine virtuelle sont excellent, bien au delà de ce que permet une liaison physique. Dans mes tests, j'atteins ainsi sans peine 1go en monté ET en descente pour une e1000 en mode "bridge".

Lecteurs CD/DVD

Concernant le contrôleur de disques, il était possible de choisir entre SCSI et IDE. Cependant ne vous attendez aucune différence de performance entre les deux types d'interface. Autant donc prendre le mode le plus reconnu, l'IDE.

ide1:0.present = "TRUE"
ide1:0.deviceType = "cdrom-raw"
ide1:0.startConnected = "FALSE"
ide1:0.fileName = "auto detect"
ide1:0.autodetect = "TRUE"
ide1:1.present = "TRUE"
ide1:1.fileName = "cdrom.iso"
ide1:1.deviceType = "cdrom-image"
ide1:1.startConnected = "FALSE"

Nous disposons comme sur une machine classique, de 4 ports IDE réparties en deux paires maître-esclave. Ici nous paramétrons la seconde paire pour prendre en charge deux lecteurs de CD-ROM, l'un connecté à un lecteur physique (devicetype à cdrom-raw), l'autre est sur une image iso (devicetype à cdrom-image). Le reste du paramétrage est maintenant connu. Notez que le fait de placer ces ports IDE en mode "CD-ROM" les rends accessibles à chaud sur l'interface de vmplayer. Il est ainsi possible de connecter, déconnecter, et changer la destination (physique ou iso) de chacun d'entre eux.

Disques durs

Nous arrivons enfin au plus important, le disque de stockage. Cette fois nous utilisons la première paire IDE. Notez que contrairement au monde physique, maître et esclave ne rentrer ici pas en conflit lorsqu'utilisé simultanément.

ide0:0.present = "TRUE"
ide0:0.fileName = "hda.vmdk"
ide0:0.mode = "independent-persistent"
ide0:0.deviceType = "rawDisk"
ide0:0.redo = ""
ide0:0.writeThrough = "TRUE"
ide0:0.startConnected = "TRUE"
ide0:1.present = "FALSE"
ide0:1.fileName = "hdb.vmdk"
ide0:1.mode = "independent-persistent"
ide0:1.deviceType = "rawDisk"
ide0:1.redo = ""
ide0:1.writeThrough = "TRUE"
ide0:1.startConnected = "TRUE"

Création de l'espace de stockage

Utilisation d'un disque virtuel

Cette approche est sans doute la plus simple. L'avantage du disque virtuel est qu'il n'occupe que la place utilisée par le guest. Ainsi à sa création, il n'occupe que 1.4mo.

Pour créer ce disque nous allons utiliser l'utilitaire qemu-img provenant du paquet du même nom. La syntaxe est trés simple :

qemu-img create -f vmdk hda.vmdk 10G

Et voilà, nous avons cré un disque de 10G qui pour l'instant en occupe beaucoup moins vu qu'il est vide.

A partir de là, notre VM est déjà utilisable, et nous pouvons la lancer par un

vmplayer vm.vmx

Votre machine virtuelle devrait normalement démarrer sans encombre. Vous pouvez alors aller (F2) dans le BIOS pour régler les priorités sur les disques pour démarrer sur un CD-ROM et commencer une installation.

A ce stade CTRL+ALT permette de dégager la souris de la fenêtre du player, CTRL+ALT+Entrée permet de basculer en plein écran et CTRL+ALT+ESPACE, relâchement d'espace suivi de F1, permet de simuler le CTRL-ALT-F1.

Maintenant, un disque virtuel n'est pas ce que l'on fait de mieux pour une utilisation quotidienne de VMPlayer. En effet, soit parce que l'on désire utiliser une installation physique existante, soit pour des raisons de performances, nous pouvons préférez un bon vieux disque physique.

Utilisation d'un disque dédié

Pour se donner une idée des performances d'un disque physique contre un disque virtuel, il faut garder tête que pour un disque physique ayant un débit en lecture sur le host de 59MB/s, donnera utilisé en virtuel environ 12MB/S. Le même disque physique mais utilisé à travers la VM donnera 34MB/s. Il est donc clairement plus performant de dédier un disque à VMWare dés que l'on utilise cet outil pour travailler sur du long terme.

L'autre cas d'utilisation d'un disque physique peut être de virtualiser une installation existante. Personnellement j'ai adopté la double approche d'un disque physique dédié qui est donc bootable en directe par la machine physique et utilisable en virtualisé par VMPlayer. Sur ce disque j'installe tranquillement toutes mes VM, chacune sur sa ou ses partitions avec un GRUB pour gérer le multi-boot.

Quel que soit votre usage, le travail préalable reste le même et consiste à créer un fichier vmdk qui va reprendre les caractéristiques du disque physiques.

En simplifiant un peu, un disque dur est composé de plateaux avec une têtes pour chacun. Les plateaux sont découpés en cercles concentriques, les pistes (tracks). Une même piste forme un cylindre pour l'ensemble des plateaux. La piste est découpée en secteurs, historiquement de 512 octets. Le nombre de cylindres, le nombre de secteur par piste, et le nombre de têtes (et donc de plateaux) par cylindre, forment la géométrie du disque.

Pour connaître cette géométrie, le mieux est d'utiliser l'utilitaire parted. Par exemple si l'on désire utiliser le disque /dev/hda, cela nous donne :

root#parted /dev/hda

(parted)unit cyl

(parted)print

ST3200822A (ide)

Disque /dev/hda : 24321cyl

Taille des secteurs (logiques/physiques): 512B/512B

BIOS cylindre,tête,secteur géométrie : 24321,255, 63 Chaque cylindre est 8225kB.

(parted) 

récupération des informations sur le disque natif

Les valeurs peuvent surprendre. 255 têtes impliquent 255 plateaux, cela semble un peu volumineux pour un si petit disque... En fait, pour des raisons un peu longuètes à expliquer, le disque ne donne jamais son véritable nombre de têtes, pour préférer quelque chose de plus assimilable par la couche logicielle. Et au fond, on s'en moque, la chose importante à notre est le triplet 24321,255,63. Notre disque dispose donc de 255 têtes, 63 secteurs par piste, et 24321 cylindres. Ce qui nous donne un espace disque de 512 (taille d'un secteur) x 255 (têtes par cylindre) x 63 (secteurs par piste) x 24321 (cylindres) = 200Go. Le compte est bon

Maintenant ce qu'il nous faut, c'est la taille du disque en secteurs. Pour cela, nous allons encore utiliser parted mais cette fois en changeant l'unité de cylinder à sector.

(parted)unit s

(parted)print

ST3200822A (ide)

Disque /dev/hda : 390721968s

(parted)q

root#

root# 

récupération des informations sur le disque natif

Maintenant nous avons la taille du disque exprimé en nombre de secteurs (390721968). Il ne nous reste donc plus qu'à reporter ces informations pour créer notre fichier hda.vmdk

version=1
CID=400b3894
parentCID=ffffffff
createType="fullDevice"
RW 390721968 FLAT "/dev/hda" 0
ddb.geometry.cylinders = "24321"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.virtualHWVersion = "4"
ddb.adapterType = "ide"
ddb.toolsVersion = "6530"

contenu du fichier hda.vmdk

Notez qu'il est possible de faire des fichiers vmdk beaucoup plus évolués que celui-là en créant un disque composé de partitions qui ne se suivent pas, et même d'images de partitions sockés sur le disque sous la forme d'un fichier. Mais même si vous n'utilisez cette technique que pour une seule partition, autant inclure le disque en entier, secteur de démarrage compris. Le seul risque de cette approche est que la machine virtuel aura un accès en écriture sur l'ensemble du disque, c'est à vous de voir.

Normalement, le disque /dev/hda (ou quel que soit le votre) n'est pas accessible en écriture (et même en lecture d'ailleurs) à un utilisateur Lambda. Et comme me l'a très justement fait remarquer Malic, lancer VmPlayer en root n'est pas une idée de génie. La solution consiste donc à changer les droits de /dev/hda pour les mettre en accord avec le ou les utilisateurs amenés à utiliser cette machine.

Sous Mandriva, les disques appartiennent à root et au groupe disk. Dans ce cas, une version simple consiste à modifier /etc/group et à ajouter le ou les utilisateurs à la fin de la ligne correspondante.

Ensuite, il faut donner les droits d'écritures sur le disque au groupe en question par la commande chmod g+rw /dev/hda. Ceci fait, il devrait suffire d'ouvrir une nouvelle console au nom de l'utilisateur cible pour pouvoir lancer VmPlayer. Le souci avec les distributions modernes, c'est qu'il y a un nouveau démon, console-kit-daemon, dont le but dans la vie est d'unifier les accès aux consoles (à ce que j'ai compris) et qui empêche du coup, de récupérer les bons droits directement. La seule parade que j'ai trouvée est de quitter X, puis se re-connecter pour bénéficier du nouveau groupe ainsi pouvoir lancer la VM sans problèmes.

Passer d'une installation physique à une installation virtuelle

S'il s'agit simplement de convertir un disque complet en son équivalent VMWare, rien de plus simple, et c'est encore qemu-img qui va nous y aider :

gaston$qemu-img convert -f raw /dev/hda -O vmdk hda.vmdk

gaston$ 

conversion d'un disque complet

A partir de là vous disposez d'un disque virtuel hda.vmdk parfaitement utilisable sans modification qui s'intègre à la machine virtuelle que nous avons définie plus haut.

Maintenant s'agissant d'extraire une seule partition d'un disque physique, cela se corse un peu. En effet, qui dit partition, dit table de partition. Il va donc nous falloir dealer avec les fameux 63 secteurs au début du disque qui définissent, entre autre, son organisation logique. La recopie telle-quelle de ces secteurs est exclue car vous hériteriez d'une mauvaise taille de disque ainsi que d'un partitionnement en partie faux.

Pour arriver à nos fins sans passer par un outil de type "ghost", nous avons deux solutions. Soit passer par qemu-img pour convertir la fusion de 63 secteurs de zéros (faciles à créer avec dd) suivi du contenu de notre partition physique, soit nous créons directement un nouveaux disque virtuel que nous remplirons après configuration avec les données physiques.

Dans les deux cas nous allons devoir utiliser fdisk pour recréer le partitionnement et, s'il s'agit d'une partition amorçable, un outil spécialisé pour implanter un MBR. La différence étant que dans le cas "fusion", fdisk sera lancé de la machine hôte sur le fichier avant conversion, tandis que pour la version "virtuelle" cette opération se fait dans la machine virtuelle. Et comme dans les deux cas nous aurons besoin de l'image ISO d'un CD-ROM de réparation pour recréer le MBR, la solution "virtuelle" est finalement plus simple à mettre en oeuvre.

Il nous faut donc commencer par créer un disque virtuel vierge tel que nous l'avons appris plus haut, d'une taille supérieur à la partition physique. Si elle est beaucoup plus grande, vous devrez par la suite utiliser un outil de redimensionnement pour profiter de l'espace supplémentaire.

Une fois le disque créé, nous allons par la technique donnée plus haut, ajouter à la machiner virtuelle le second disque physique contenant notre partition source. On finit donc avec une machine virtuelle configurée pour utiliser deux disques, l'un virtuel (hda.vmdk) et le second physique (hdb.vmdk). N'oubliez pas de bien activer les deux disques dans vm.vmx.

Avant de la redémarrer, nous allons devoir nous munir de l'image ISO du CD-ROM de réparation. L'outil idéal pour cette manoeuvre est Ultimate Boot CD qui contient à la fois fdisk, dd et des utilitaires de réparation de MBR.

Une fois l'ISO téléchargée, il est temps de démarrer la machine virtuelle en prenant bien soin de faire pointer le CD-ROM sur l'ISO d'UBCD et de régler dans le BIOS l'ordre des médias de démarrage pour le placer en première position. Une fois arrivé sur le menu d'UBCD, allez dans la section DOS/Linux Boot Disks/Linux Boot Disks/Tom's Boot Disk. Cela va débucher sur un petit Linux bien sympathique qui contient tout ce qu'il nous faut.

La première chose à faire est d'utiliser fdisk pour recréer la structure de la partition à recopier. Lancez une première fois fdisk /dev/hdb, puis p et notez le nombre de têtes, le nombre de secteur, et le secteur de fin de la partition. Quittez par q.

Relancez-le, mais cette fois sur le disque virtuel /dev/hda. Utilisez p pour vérifier que le nombre de têtes et le nombre de secteurs soient bien les mêmes que hdb. Si ce n'est pas le cas, passez en mode avancé (x), changez le nombre de têtes (h) et/ou le nombre de secteurs (s). Ceci fait, revenez en mode "standard" par r.

Il ne nous reste plus maintenant qu'à créer (n) notre partition primaire contenant très exactement le même nombre de secteurs que la partition d'origine. Ceci fait, rendez cette partition amorçable (a) puis changer son type (t suivi du numéro d'identification). Maintenant vous pouvez sauvegarder votre disque avec w et quitter avec q.

Maintenant il ne nous reste plus qu'à recopier nos données :

root#dd if=/dev/hdb1 of=/dev/hda1 bs=1024

root# 

Si la partition n'a pas pour but d'être amorçable, vous pouvez vous arrêter ici, sinon, il nous faut ajouter un MBR qui fonctionne. S'il s'agit d'installer d'une partition GNU/Linux, le mieux est sûrement de rebooter sur le CD de secours de votre distro pour ré-installer GRUB. Il y a sûrement moyen de le faire avec UBCD mais je n'ai pas bien cherché.

S'il s'agit d'une partition Windows, redémarrez la machine virtuelle pour retomber sur le menu UBCD et sélectionnez cette fois Filesystem Tools/Partition Tools/MBRWork. Prenez l'option de démarrage par défaut, validez une demi-douzaine de fois et vous déboucherez sur un bon vieux menu DOS des familles. L'option 5 est celle qui nous intéresse ici, elle installe un MBR valide. Ceci fait vous pouvez redémarrer la VM en prenant soin de dégager avant l'ISO d'UBCD. Windows devrait démarrer tranquillement.

Installation des Guest Tools

Les guest tools sont des images ISO, une par OS host donc, permettant l'installation d'utilitaires et de pilotes DANS la VM. Le problème est que ces ISO ne sont pas fournies avec le player. La solution est donc simplement de retourner sur le site de VMWare, télécharger la version d'évaluation de VMWare Workstation en rpm. Plus de décompresser le paquet par la commande suivante :

mkdir tmp
cd tmp
rpm2cpio VMWare-XXXX.rpm | cpio -div `*.spec`
find . -name "*.iso"

La commande find, est une recherche simple des fichiers .iso qui nous permet de découvrir une série de fichier avec des noms d'OS (windows.iso, linux.iso, etc...). Ce sont les ISO Guest Tools. Il suffit alors de recopier ses fichiers où bon vous semble. Ensuite vous devez monter le fichier correspondant à l'OS host sur le lien du CD-ROM. Une fois le tout installé, les performances sont transfigurées.

La même opération est réalisable, dans l'autre sens, pour rendre physique, une installation virtuelle.

Conclusion

Comme je le disais en introduction, j'ai utilisé pendant 1 ans VMWare comme environnement principal de développement, et ce pour faire du Delphi/COM/DCOM. Pas réputé pour être d'une grande légèreté. Cet outil m'est devenu aujourd'hui absolument indispensable.

Dernier truc avant de partir, ma découverte du jour, Ext2 IFS For Windows. Un pilote natif Windows qui permet d'attaquer en lecture ET en écriture des partitions ETX2/EXT3 et EXT4. Le tout avec les mêmes performances que sous Linux, très bon