7 à 4 (!)

Dans Proxmox, quand on sélectionne une machine virtuelle, on a à sa disposition quelques actions possibles sur l’état de cette machine virtuelle : « Start » (si la machine n’est pas démarrée), « Shutdown« , « Stop » et « Reset« .

Je ne m’étendrai pas sur l’action « Start » (ça serait douloureux pour elle ), ça démarre une machine virtuelle arrêtée.

L’action « Shutdown » permet d’arrêter proprement une machine virtuelle (l’équivalent par exemple de Démarrer -> Arrêter des Windows, ou de shutdown -h now d’un Unix).

L’action « Stop » correspondant à une coupure électronique de la machine virtuelle, un arrêt inconditionnel et brutal, pouvant dégrader le système de fichiers.

L’action « Reset« , comme son nom l’indique, réalise un équivalent d’une pression sur le bouton « Reset » d’une machine physique provoquant un redémarrage inconditionnel et brutal (là aussi, cela peut dégrader le système de fichiers).

poursuivre la lecture…

Bonjour-zà-tous,

Vous vous souvenez certainement (ou pas) du billet du 24 avril 2010, où j’exposais une liste de jalons (terme de gestion de projet, un peu pompeux, mais finalement adapté) à atteindre pour faire évoluer mon Lab. Revenons sur chacun d’eux :

Jalon 1 : Serveur de virtualisation dédié

poursuivre la lecture…

Ca y est. C’est officiel. OpenSolaris, en tout cas tel qu’il a existé ces dernières années, n’est plus.

Oracle a tiré un trait sur cette version communautaire de Solaris. A voir comment Solaris va pouvoir (ou pas) prendre la relève.

Il est fort probable que le fork récent (Illumos) soit la seule alternative à tous ceux qui ont investi du temps et des espoirs dans OpenSolaris. J’avoue que je n’ai pas souhaité poursuivre l’aventure personnellement, inquiet que j’ai été de l’annonce du rachat de Sun par Oracle à l’époque (et j’avais raison d’être inquiet, manifestement), et je suis revenu dans un environnement Linux plus classique pour mon serveur de virtualisation (pour les données, c’est maintenant Synology et une saupoudrée de Mac OS X).

Que nous réserve Oracle pour l’avenir ? Des inquiétudes à avoir sur Java, NFS ou autres technologies « offertes » par Sun en son temps ?

Après la migration de toutes les machines virtuelles basées sur Linux, je me suis attaqué à la migration de l’unique machine virtuelle qui fait tourner Windows. J’ai suivi la marche à suivre décrite ici, et ça s’est passé tout en douceur.

Pour résumer, avant la migration, il faut désinstaller les VMware Tools, ce qui provoque un reboot, puis appliquer le contenu de cet article de la Knowledge Base de Microsoft pour préparer le support des disques IDE, arrêter la machine virtuelle VMware, puis suivre la même procédure que celle que j’ai décrite pour une machine Linux. Et-c’est-tout.

Franchement, je suis plutôt impressionné par ce que propose Proxmox, que ce soit les fonctionnalités (somme toute disponibles sur toutes les distributions Linux récentes, mais assez bien exposées par l’interface Web de Proxmox) ou la documentation (pas exagérément abondante mais d’une pertinence réjouissante, en tout cas me concernant).

J’attends avec impatience les améliorations à venir de Proxmox.

Pour migrer une machine virtuelle Linux VMware vers Proxmox/KVM, voici comment procéder :

1. VMware peut utiliser des fichiers disque qui grossissent suivant le besoin (ce qui n’est pas grave), mais qui peuvent aussi être découpé en tronçons de 2 Go (ce qui est plus embêtant). Si c’est le cas, il faut avant tout convertir le(s) fichier(s) disque dans un format compatible avec la suite :

$ vmware-vdiskimage -r <fichier>.vmdk -t 0 <nouveau fichier>.vmdk

Cela va faire en sorte que le fichier disque résultant soit unique (pas découpé en parties de 2 Go).

Note : On pourrait me faire remarquer, à raison, que je peux éviter l’étape de la conversion en RAW (point 3), en utilisant plutôt « -t 2″ pour obtenir un fichier non extensible, qu’on pourra ensuite utiliser directement sans l’étape de conversion au format RAW par qemu-img (quoi que je n’ai pas essayé, donc je n’ai pas de certitude sur ce point). Cependant, l’option « -t 2″ génère 2 fichiers, un xxx.vmdk qui décrit le fichier disque, et un fichier xxx-flat.vmdk qui correspond au données réelles. Je trouve cela « confusant », je préfère ne pas avoir à me poser de question lors du transfert de fichier, je m’en tiens donc à l’option « -t 0″.

2. On copie les fichiers disque (éventuellement nouvellement convertis) vers le serveur KVM

poursuivre la lecture…