Maniatux's Blog

Welcome to the internet

Virtualization

Installer VMware Workstation sous Fedora

Rédigé par Xavier - - Aucun commentaire

L'installation de VMware Player/Workstation sous Linux est assez simple puisqu'il suffit de lancer le package fourni en root. Or sous Fedora la compilation des modules ne passe pas, il y a quelques manipulations à faire.

Dépendances

# yum install kernel-devel* make gcc

Installation VMware

# ./VMware-Workstation-Full-9.0.1-894247.x86_64.bundle

Compilation des pilotes

Ci dessous un petit fix sinon la compilation échouera :

# cp /usr/src/kernels/`uname -r`/include/generated/uapi/linux/version.h \
/lib/modules/`uname -r`/build/include/linux

Puis on lance la génération des pilotes :

# /usr/bin/vmware-modconfig --icon="vmware-workstation" --appname="VMware"

La compilation des pilotes (fix + modconfig) est à faire à chaque mise à jour du kernel Fedora.

Windows 8 sur Linux-KVM et Virt-Manager

Rédigé par Xavier - - Aucun commentaire

Si vous essayez d'installer Windows 8 dans Linux-KVM vous allez rencontrer le bug suivant :

Your PC needs to restart.
Please hold down the power button
Error Code: 0x0000005D
Parameters:
0x03060203
0x756E6547
0x49656E69
0x6C64746E

Il s'agit d'une réaction au type de CPU affiché par Linux-KVM (Qemu Processur), la solution consiste à copier la configuration du CPU hôte afin que ce dernier s'y retrouve. Pour cela ouvrez les paramètres de votre VM, allez dans "Processor" puis "Configuration" et cliquez sur "Copier la configuration CPU de l'hôte".

Vous pouvez maintenant virtualiser Windows 8 sous Linux sans devoir installer VirtualBox ou VMware !

Merci à Regardt van de Vyver

Aperçu de oVirt

Rédigé par Xavier - - Aucun commentaire

J'ai souvent parlé de Linux-KVM en citant parfois des défauts qui peuvent lui être préjudiciables. Ils ne se trouvent pas dans la technologie elle-même mais plutôt dans les outils d'administration peu fiables (virt-manager) voir inexistants qui demandent alors beaucoup de bidouilles lorsque l'on veut s'en servir sérieusement et durablement.

Red Hat travaille beaucoup sur l'amélioration de l'écosystème KVM et semble avoir compris les problématiques et les enjeux. En effet pour pouvoir lutter contre les solutions VMware qui sont pour beaucoup des références, ils créent des nouveaux outils dans le but de faire de KVM une solution d'entreprise et non de bidouilleur.

Présentation

oVirt est la branche opensource et gratuite de RHEV (RedHat Enterprise Virtualization). Cette solution offre un système de gestion d'un cluster de virtualisation similaire à VMware vCenter. Il utilise des technologies connues : VirtIO, libvirt, kvm, spice. L'interface utilisateur est une application JBoss (accessible en web) utilisant une base de données postgresql.

oVirt est défini en deux parties : engine qui est l'application elle-même, et node qui est en fait un hyperviseur membre du cluster que nous mettons en place. Schématiquement, voici ce que cela donne :

Les instructions d'installation peuvent être trouvées sur cette page et ce PDF. Le plus simple est d'utiliser Fedora 16 sur la machine où nous allons installer oVirt Engine, tout simplement car un dépôt rpm est proposé et facilite grandement les choses. Concernant oVirt Node, il suffit de récupérer une image ISO et de l'installer sur la machine qui servira d'hyperviseur. Voici un aperçu de l'interface oVirt (cliquez pour agrandir) :

Le stockage se fait sur un serveur NFS ou une baie SAN (connexion iScsi). La documentation détaille tout.

Fonctionalités

Cette page liste les fonctionnalités proposées à l'heure actuelle. Je passe sur les détails techniques comme le nombre de vcpu pour parler plutôt des services fournis.

Datacenter

  • Administrer un cluster d'hyperviseurs
  • Proposer une interface graphique complète
  • Faciliter la mise en place des machines virtuelles et leur migration à chaud
  • Assurer si besoin une haute disponibilité
  • Faciliter la centralisation du stockage des supports
  • Faciliter le p2v

Utilisateur

  • Proposer un portail utilisateur pour se connecter à son bureau (plugin SPICE mozilla)
  • Virtualisation desktop pour clients légers grâce au protocole SPICE (support USB)
  • Technologies d'optimisation du réseau pour limiter les latences dans l'affichage

Ma conclusion

oVirt est clairement de la catégorie artillerie lourde puisqu'il faut pas moins de 3 serveurs physiques au minimum pour mettre en place l'infrastructure. De plus, l'engine (qui propose l'interface web) est très gourmand en mémoire, les spécifications recommandent 4GB. Celui qui a besoin d'un unique hyperviseur se tournera donc vers des solutions plus légères et mieux adaptées comme Proxmox.

Néanmoins, pour une entreprise qui veut virtualiser une dizaine (ou plus) de serveurs, oVirt semble une excellente solution. Il est possible de se tourner vers RHEV pour obtenir la version commerciale avec du support pour plus de pérennité.

J'espère grandement avoir un jour l'occasion de travailler avec oVirt/RHEV en situation réelle.

OpenBSD : p2v

Rédigé par Xavier - - Aucun commentaire

Voici une petite bidouille pour transférer un serveur OpenBSD physique vers une machine virtuelle (VMware dans mon cas, mais cela devrait fonctionner avec tous).

A moins de faire une mauvaise commande, il n'y a aucun risque pour le serveur car on ne modifie rien dessus.

Etape 1 : installation de la VM

Ici, rien de particulier. Récupérez une ISO d'OpenBSD et effectuez l'installation dans une machine virtuelle. Configurez le réseau afin d'avoir un accès SSH.

Etape 2 : lister l'essentiel sur le serveur physique

Si je liste ce que contient mon serveur, voilà ce que j'obtiens :

$ ls /
altroot boot    bsd.mp  dev     home    obsd    sbin    sys     usr
bin     bsd     bsd.rd  etc     mnt     root    stand   tmp     var

Mon serveur fait tourner OpenSMTPD dont la config se trouve dans /etc et les messages dans /home. Vient ensuite dovecot installé à partir des ports, ses fichiers se situent dans /usr (et la config dans /etc). Et pour finir, prosody qui vient lui aussi des ports et exploite une base de données située dans /var. La liste des répertoires à transférer est donc :

  • /etc
  • /home
  • /usr
  • /var

Etape 3 : sauvegarde des répertoires

On utilise un bon vieux tar (vous pouvez utiliser la compression en rajoutant l'argument z) :

# tar -pcvf etc.tar /etc/
# tar -pcvf home.tar /home/
# tar -pcvf usr.tar /usr/
# tar -pcvf var.tar /var/

Attention à ne pas travailler dans le répertoire /home lorsque vous faites la deuxième commande ! Sinon cela ne terminera jamais (il va archiver le fichier d'archive nouvellement créé, etc).

Etape 4 : transfert des archives sur la VM

Le plus simple est d'utiliser le protocole sftp (actif du moment que sshd est actif sur vos systèmes). Cela peut-être fait depuis Filezilla sur une tierce machine (avec les comptes root).

Etape 5 : Rétablissement des utilisateurs

Pour des raisons de sécurité, le fichier contenant les utilisateurs du système et leurs mots de passe est en lecture seule, même pour root (voir cette page). Vous devez utiliser l'outil vipw pour les importer.

Ouvrez vipw sur l'ordinateur hôte, copiez toutes les lignes situées après la ligne "nobody", et collez-là à la suite dans le vipw de la VM (vous pouvez faire cette opération depuis un ordinateur tiers et des connexions SSH).

Etape 6 : installation sur la VM

La procédure est classique, sauf qu'il faut penser à sauvegarder le fichier fstab car le partitionnement peut différer :

# tar -pxvf var.tar -C /
# tar -pxvf usr.tar -C /
# tar -pxvf home.tar -C /
# cp /etc/fstab /root/
# tar -pxvf etc.tar -C /
# cp /root/fstab /etc/
# reboot

Pensez à revoir la configuration du rc.conf, notamment le nom d'hôte et le réseau qui peuvent différer.

Le réseau "bridged" facilement sur KVM depuis Fedora 17

Rédigé par Xavier - - Aucun commentaire

Si il y a une chose qui a toujours été compliquée sur la virtualisation KVM, c'est de faire un pont-réseau (Bridge) c'est à dire faire comme si votre machine virtuelle était branchée physiquement au réseau (on peut ainsi mettre une IP sur le même réseau que les autres et se passer de NAT ou routage). Il fallait faire des manipulations sur l'hôte pour mettre en place le pont, cela changeait selon les OS, bref c'était un peu fastidieux.

Depuis Fedora 17, une nouvelle fonctionnalité, "macvtap" qui permet d'automatiser toute cette opération un peu comme sur VirtualBox. Il suffit de sélectionner, en périphérique source, Périphérique hôte p4p1 : macvtap en remplaçant p4p1 par le nom de votre carte réseau.

Une excellente chose qui va faciliter la vie de beaucoup de gens !