Je constate que lorsque j'ajoute une photo sur un contact depuis mon smartphone, elle n'apparait pas sur owncloud. Je ne sais pas où se situe le bug, mais ce n'est pas bien grave. Ensuite il n'y a pas de "push" ou dispositif similaire pour les données, par exemple si j'ajoute un rendezvous sur owncloud, il n'apparaitra pas immédiatement sur le téléphone à moins de forcer la synchronisation.

Je n'ai pas rencontré de problème supplémentaire pour le moment, tout se passe bien.

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.

Etant équipé d'un serveur accessible sur internet chez moi j'ai eu l'envie de mettre en place une DMZ. Bien entendu je ne voulais pas d'une pseudo-DMZ fournie par les *box qui sont en fait une simple redirection de ports, mais bien un vrai réseau isolé du reste du lan. J'ai donc opté pour la mise en place d'un solution propre à base de routages mais aussi de VLANs.

Après l'achat d'un switch administrable voici l'infrastructure mise en place :

(Oui, c'est fait avec Visio)

Cela m'a permis aussi d'apprendre beaucoup de choses au sujet des VLANs mais aussi du routage.

Le Routeur

Le routeur est un Alix 1.d, format Mini-ITX, équipé de pfSense, un système d'exploitation basé sur NanoBSD gérant les fonctionnalités de routage, firewalling, et bien d'autres encore. Il ne dispose que d'une interface réseau, mais il supporte le 8021q ce qui lui permet de travailler avec 3 VLANs.

Les switches

Pour le switch core j'ai investi dans un modèle Cisco pour un peu moins d'une centaine d'euros afin de disposer du support des VLANs. On peut les distribuer sur les ports de la manière désirée (tag ou pas...). Je précise que ce switch est un modèle "small business", il est tout petit, n'a pas de ventilateur, et consomme quelques watts seulement.

Pour le switch LAN c'est un netgear le plus basique possible, puisqu'il n'aura pas à gérer de VLAN (le switch core lui distribue le vlan30 non taggué).

Le serveur

Il sera détaillé dans un prochain article, mais il fournit notamment au réseau le rôle de DNS. Le prochain article parlera de LXC donc restez branchés :)

Évolutions futures

Comme le schéma l'indique je compte ajouter un point d'accès wifi afin de placer mon ordinateur portable et mon smartphone dans le VLAN30. Le switch core dispose de fonctions de QoS et peut optimiser le trafic SIP, ce qui ouvre donc la voie à mon imaginaire dans ce sens (VoIP, asterisk...).

A bientôt pour de nouvelles aventures !

• Pas de test d'Openmediavault finalement, j'ai rencontré beaucoup de bugs et il manque tellement de fonctionnalités par rapport à FreeNAS que le but n'est visiblement pas le même.
• Connaissiez-vous les speedrun ? En voici un : Sonic 2 fini en 17min58.
• Un mod The Witcher pour Skyrim, vraiment très impressionnant !
• Les nouvelles fins de Mass Effect 3 sont arrivées. Plutôt décevant car les épilogues ajoutés sont assez similaires, voire totalement identique. Il n'y a que le nouveau choix "refusal" qui semble réellement original.
• VLC sur Android est disponible en version beta, réservé aux processeurs compatibles NEON et armv7. A essayer !

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.