Étiquette : virtualisation

Ah, les joies de la virtualisation.

Même si je n’ai plus fait de vidéos de présentation de distributions GNU/Linux depuis le mois de novembre 2018 – p’tain bientôt 5 ans ! – je continue d’utiliser régulièrement Qemu avec sa surcouche graphique Virtual Machine Manager alias VMM.

J’ai goûté de nombreuses fois à la ligne de commande avec Qemu et je dois dire que j’adore la simplicité de mise en place apportée par VMM. Évidemment, quand je récupère la dernière DGLFI en date comme la GetFreeOS par exemple (ne me remerciez pas, c’est cadeau), je pars d’une image ISO hybride pouvant être gravée sur un DVD ou écrite sur une clé USB.

En 2023, il est plus fréquent d’utiliser une clé USB prête à l’emploi qu’une galette plastifiée. Mais il reste un point crucial. Comment vérifier que l’écriture de la clé USB s’est bien passée ?

C’est en faisant quelques essais que j’ai réussi à trouver une solution de test basée sur le duo Qemu/VMM. On peut assez facilement indiquer à VMM de démarrer sur une clé USB réelle. J’ai fait une vidéo pour montrer un démarrage sur clé USB.

Je pense qu’il doit exister une ligne de commande pour faire la même chose depuis un terminal, mais je dois dire que je n’ai pas eu le courage de la chercher. Peut-être qu’un jour, je m’y mettrai… Ou pas 🙂

Revenons une ultime fois sur l’utilisation de machines virtuelles pour les présentations et tests de distributions GNU/Linux.

Durant des années, j’ai présenté et testé des distributions GNU/Linux dans le cadre de machines virtuelles, avec toujours la même rengaine : « Tu ne testes pas en dur, ça vaut rien. »

Ouvrons un logiciel de carte heuristique – aussi connue sous le nom de carte mentale – qui permet d’organiser les idées en partant d’un point et en tirant chaque pensée au maximum. Pour cet exercice, j’ai pris freeplane.

Combien faudrait-il d’ordinateurs différents pour couvrir un minimum de points communs, au minimum le trio suivant :

  1. le CPU
  2. le circuit ou la carte graphique
  3. le type de la carte mère, à savoir Bios ou UEFI

Pour le premier point, on a déjà deux options : soit du Intel, soit de l’AMD.

Pour le deuxième point, on a trois options : soit du Intel, soit de l’AMD, soit du Nvidia. Ce qu’on peut décomposer en :

  1. CPU Intel, graphique Intel
  2. CPU Intel, graphique AMD Radeon
  3. CPU Intel, graphique Nvidia
  4. CPU AMD, graphique AMD Radeon
  5. CPU AMD, graphique Nvidia

Soit cinq possibilités ne serait-ce qu’au niveau du duo CPU et graphique. Qu’on multiplie par deux pour les cartes mères à base de Bios et d’UEFI. Ce qui fait déjà dix possibilités. Et encore, je n’ai pas parlé de l’utilisation du support de stockage : disque dur, SSD classique / M2.

Continuer la lecture de « Revenons une ultime fois sur l’utilisation de machines virtuelles pour les présentations et tests de distributions GNU/Linux. »

Vieux Geek, épisode 122 : Connectix Virtual PC 4.0, l’ancêtre des virtualisateurs modernes…

Quand on dit émulation ou virtualisation, un des premiers logiciels qui vient à l’esprit, c’est VirtualBox. D’autres personnes diront VMWare ou encore Qemu pour les plus barbus.

Mais il serait dommage de faire l’impasse sur un des premiers logiciels de cette catégorie du monde PC, j’ai nommé Connectix Virtual PC 4.0. Oui, j’ai bien dit Connectix et non pas Microsoft Virtual PC.

En 2001, Connectix qui s’était déjà fait la main dans le monde Mac décide de proposer une version pour MS-Windows de son logiciel de virtualisation. À l’époque, tout se fait en mode logiciel. Aucune instruction n’est disponible pour virtualiser directement dans les microprocesseurs.

Il faudra attendre 2006 pour qu’Intel avec son jeu d’instructions Intel-VT et AMD avec AMD-V pour que des solutions plus puissantes pointent le bout de leurs octets. En 2001, tout est fait par le logiciel de virtualisation, ce qui implique d’avoir un monstre de guerre pour faire tourner l’OS désiré dans un environnement virtualisé.

Avec mon exemplaire virtualisé de MS-Windows XP, j’ai pu installer une version de Connectix 4.0 pour faire un peu mumuse avec.

Continuer la lecture de « Vieux Geek, épisode 122 : Connectix Virtual PC 4.0, l’ancêtre des virtualisateurs modernes… »

Règlement de compte à Linux Corral, deuxième partie : Pourquoi utiliser une machine virtuelle pour tester des distributions GNU/Linux.

Deuxième article de cette petite série de mises au point, entamée le 24 avril 2015. Avant que je ne claque temporairement la porte par lassitude, une remarque qui revient souvent est : « c’est pas bon, c’est pas un test en dur, ça vaut rien ! »

Je peux admettre cette remarque, cependant, il faut prendre en compte un fait précis. Il est « techniquement » impossible de faire un test en dur qui soit vraiment exhaustif.

Pourquoi ? Il n’y a pas de machine idéale qui représente toutes les machines. Si on prend l’ensemble micro-processeurs (CPUs), circuits graphiques, on arrive à quoi ? En se limitant aux marques principales, on a deux types de CPUs (Intel et AMD), trois marques de circuits graphiques (Intel, Nvidia et ATI).

Donc, on aurait besoin au minimum de machines équipées avec :

  1. Un CPU Intel avec un circuit graphique Intel
  2. Un CPU Intel avec un circuit graphique Nvidia
  3. Un CPU Intel avec un circuit graphique ATI
  4. Un CPU AMD avec un circuit graphique Nvidia
  5. Un CPU AMD avec un circuit graphique ATI

5 possibilités. J’ai enlevé l’improbable CPU AMD et circuit graphique Intel. Ensuite, il faudrait voir la marque de la carte mère : Asus, MSI, Gigabyte, autre ? Ensuite, quel circuit ethernet ? Quelle circuit sonore ? Avec ou sans wifi ? Un disque dur ou un SSD ? Quelle quantité de mémoire vive ? Avec ou sans lecteur optique ? Bios ou UEFI ?

On arrive à une bonne cinquantaine au minimum de machines si on veut balayer un tant soit peu l’existant. On va me dire que je suis un obsédé de Distrowatch, mais un des rédacteurs teste des distributions sur une semaine entre une machine virtuelle et sa machine de test qui est la suivante, je copie-colle l’information d’une gazette récente :

* Processor: Dual-core 2.8GHz AMD A4-3420 APU
* Storage: 500GB Hitachi hard drive
* Memory: 6GB of RAM
* Networking: Realtek RTL8111 wired network card
* Display: AMD Radeon HD 6410D video card

Quid des résultats sur une machine à base d’Intel, avec un circuit réseau différent, une quantité de ram plus petite ou plus grande ? Ou avec un circuit vidéo différent ?

Continuer la lecture de « Règlement de compte à Linux Corral, deuxième partie : Pourquoi utiliser une machine virtuelle pour tester des distributions GNU/Linux. »

Utiliser une machine virtuelle pour tester un OS, c’est ne pas l’utiliser vraiment ?

Certaines personnes m’ont fait remarquer que je ne prenais pas la peine d’utiliser une partition réelle de mon disque dur pour tester les distributions Linux, les BSDs et autres OS qu’il m’arrive de présenter. Et que cela n’était pas bien…

Ce qui m’a valu quelques gentillesses, comme celle d’être traité de demi-mots de mythomane sur identi.ca…

Mais passons outre cette polémique de propos qui ressemble à ceux d’une époque digne d’Oncle Joe et venons en au coeur du problème : pourquoi utiliser une machine virtuelle plutôt qu’une partition en dur ?

Pour plusieurs raisons :

  1. Car c’est plus simple de créer une image disque que de partitionner un disque dur. En cas d’erreur, on efface le fichier et on recommence. Tandis qu’avec une partition…
  2. Car le matériel émulé depuis l’arrivée des instructions KVM (AMD-V, Intel VT) est aussi rapide que le matériel réel, au moins sur le plan puissance de calcul du microprocesseur).
  3. Bien que le matériel émulé ne puisse pas de manière simple accéder aux ressources poussées (comme les fonctionnalités 3D des circuits graphiques) cela permet toujours d’avoir un matériel classique et fonctionnel).
  4. Pas besoin de rajouter / sortir les os installés dans le gestionnaire de démarrage

En gros, c’est largement plus simple d’accès. Certains puristes hurlent à la mort – tel des loups devant la pleine lune – car j’ose utiliser un virtualiseur dans mes présentations… Et me font comprendre qu’en dur, le résultat serait différent.

Continuer la lecture de « Utiliser une machine virtuelle pour tester un OS, c’est ne pas l’utiliser vraiment ? »

Petit truc pour faire fonctionner un Xorg Server 1.8 dans une machine virtuelle Qemu / KVM

Grand « testeur » de distributions linux devant l’éternel, je suis souvent confronté à un problème récurrent : avoir une résolution exploitable avec Xorg-Server, en clair du 1024×768 au lieu du 800×600 habituel.

Même si dans un article récent, j’ai eu une partie de la solution au problème, c’est en lisant le wiki d’Archlinux que j’ai eu la réponse : voici le fichier 50-monitor.conf à insérer dans /etc/X11/xorg.conf :

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
HorizSync 30-70
VertRefresh 50-160
EndSection


Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1280x1024" "1024x768" "800x600"
EndSubSection
EndSection

Et au prochain démarrage de Xorg, une résolution en 1024×768 est disponible. Un petit truc à connaitre, surtout pour le logiciel de virtualisation libre qu’est Qemu / Kvm.

Y a pas eu que Mozilla Firefox 3.5 aujourd’hui… VirtualBox 3.0 est sorti aussi.

L’outil de virtualisation de Sun d’Oracle est sorti aujourd’hui en version 3.0.

VirtualBox 3.0

Un paquet sur AUR permet une installation simplifiée sur ArchLinux.

Un simple yaourt virtualbox_bin (il peut y avoir un conflit avec la version 2.2.4 disponible sur le dépôt ArchLinux.fr permets d’installer le paquet.

Les consignes post-installation sont simples :

  1. Ajouter le module vboxdrv à la ligne MODULES dans /etc/rc.conf
  2. Ajouter le groupe vboxusers à l’utilisateur avec un petit : sudo gpasswd -a utilisateur vboxusers
  3. Si on veut le support de l’USB, il suffit de rajouter la ligne suivant dans le fichier /etc/fstab :

none /proc/bus/usb usbfs auto,busgid=108,busmode=0775,devgid=108,devmode=0664 0 0'

Un petit redémarrage plus tard, et Virtualbox est prêt à l’emploi. Coté nouveautés ? Principalement :

  • support du multiprocesseurs, jusqu’à 32.
  • l’opengl 2.0 (support de la 3D) pour les versions linux, windows et solaris
  • direct3D 9 est supporté par pour les hôtes Windows, bien que ce soit encore expérimental.

Cependant, je vais rester fidèle à kvm pour plusieurs raisons :

  1. C’est libre.
  2. On peut utiliser 1 GiO de mémoire en virtuel, contrairement à VirtualBox qui hurle dans ce cas.
  3. C’est plus simple à mettre en oeuvre, même si l’USB manque ainsi qu’une interface graphique
  4. Pas d’obligation de devenir un « abonné » pour utiliser le logiciel.

Quelques captures : l’abonnement au premier lancement, ou encore les deux processeurs vus sous une Ubuntu Linux 9.04 :

Bref, que du bon sous le capot 😉

NetBSD 5.0 : impossible à tester dans un émulateur ?

NetBSD 5.0 est sorti il y a environ 15 jours. C’est le BSD libre le plus porté (une cinquantaine d’architectures matérielles sont supportés)… Sauf les émulateurs comme qemu / Kvm et VirtualBox.

Ma première tentative a été avec Qemu 0.10.4 (dont la version pour archlinux contient l’émulation KVM), ce qui donne en ligne de commande :

fred ~/download $ qemu-img create -f qcow2 nb5.img 32G
Formatting 'nb5.img', fmt=qcow2, size=33554432 kB

Lancement :

fred ~/download $ qemu --enable-kvm -m 1024 -soundhw all -k fr -localtime -hda nb5.img -cdrom amd64cd-5.0.iso -boot d &

Et le démarrage plante toujours au même moment, quelque soit l’option prise avec cet écran laconique…

plantage de NetBSD 5.0 dans Qemu/Kvm

Pour VirtualBox ? Pas mieux. Une machine virtuelle avec 768 Mo dédié à un NetBSD se plante au tout début du démarrage…

plantage de NetBSD 5.0 dans VirtualBox

Ca fait du bien une coupure :)

J’ai parlé sur mon autre blog de ma coupure sur le plan non technique. Maintenant, au tour du plan technique 😉

A vrai dire, cela s’est surtout résumer à faire surchauffer mon pauvre logiciel de virtualisation, j’ai nommé VirtualBox.

  • ArchLinux 2009.02, qui est une des premières distributions stable à offrir le support de l’ext4fs. L’article au vitriol de Cyrille concernant la distribution résume bien le fond de ma pensée.
  • Kubuntu Jaunty Jackalope qui offre un KDE 4.2, et je dois avouer que l’ensemble commence à me plaire pas mal. Vais-je passer de l’autre coté de la barrière après plusieurs années d’utilisation de Gnome ?
  • DragonFlyBSD 2.2.0 qui bloque au démarrage 🙁
  • Debian Lenny, histoire de ne pas mourir idiot. Pas mal, mais dommage que certains logiciels accusent leur age 🙁
  • MS-Windows 7 beta 1 que l’on m’a passé. Et bien, je n’ai pas été déçu du voyage : toujours aussi lourd, même si la bête semble un peu mieux répondre avec seulement 768 Mo de mémoire vive. Et même s’il y a toujours la grosse erreur de conception : le premier utilisateur créé a des droits administrateurs par défaut !

Le premier compte créé lors de l'installation de Windows 7 a toujours des droits administrateurs !

Bon, je vous laisse, je me replonge dans « Leviathan » de Paul Auster !

Arrivée de VirtualBox 2.0.6

Ce matin, lançant le duo quotidien de commandes pour mettre à jour ma distribution Ubuntu Linux 8.10 – à savoir : sudo aptitude update ; sudo aptitude safe-upgrade, j’ai eu le plaisir de voir s’afficher cette série d’information dans mon terminal :

Installation de la mise à jour 2.0.6 de VirtualBox

Il faut dire que j’ai ajouté le dépôt officiel de VirtualBox comme indiqué sur cette page du site du logiciel de virtualisation.

Au menu des nouveautés ?

  • Un meilleur support des OS en 64 bits (dont Windows 64 bits)
  • Un support amélioré de Solaris, l’OS de Sun (aussi bien en tant qu’OS émulé qu’OS d’installation)
  • Un meilleur support du SATA, de l’USB
  • Des correctifs pour Windows.

En clair, une version de maintenance dans les plus pures règles. Et la mise à jour a été naso-digitale, le programme d’installation s’occupant de toutes les opérations techniques dont la recompilation du module du noyau pour ma distribution linux.