Cloonix est un couple client(s)-serveur dont le serveur lance et pilote une grappe de machines virtuelles KVM sur demande d’un client cloonix. Ce serveur peut inter-connecter ces machines virtuelles formant ainsi un petit réseau comportant jusqu’à 50 KVM par instance de serveur cloonix.

Cloonix

La version 33 est un saut pour plusieurs raisons :

  • Décision de faire une vraie gestion de configuration, sous Github.
  • Après plusieurs années de licence RPL (Reciprocal Public License) retour à la GPLv3.
  • Grosses modifications dans la façon d’installer cloonix, maintenant très simple.
  • Nettoyage de l’objet réseau ayant le rôle de cable, le lan est maintenant un process brassant les flux d’octets par sockets Unix uniquement ; l’option shared memory a été effacée, code trop complexe amenant moins d’un facteur 2 de gain de performance, l’atout de cloonix est son côté pratique, pas sa performance.
  • Creation du client hyperzor, un soft gtk qui supervise et controle plusieurs serveurs cloonix.
  • Api enfin stabilisée, pour les clients : cloonix_cli, cloonix_gui, cloonix_zor, cloonix_ssh, cloonix_scp et pour le serveur cloonix_net.
  • Création de l’objet réseau a2b qui se met en coupure sur un lien et contrôle les flux entre 2 réseaux.
  • L’objet c2c qui joint 2 cloonix distants par TCP possède maintenant les performances d’une connexion TCP, un bug en diminuait le débit.

UK GitHub cloonix

UK Documentation de cloonix

UK Création de qcow2


Pourquoi avoir choisi KVM ?

Quelques rappels sur la virtualisation, à ne pas confondre avec les containers dont les mots clefs sont : docker, lxc, lxd, Systemd Nspawn. Les principaux acteurs de la virtualisation et le nom des produits sont :

  • VMWare ESX/i,
  • Microsoft Hyper-V,
  • Citrix Xen,
  • Oracle VirtualBox,
  • Redhat KVM

Les deux premiers sont propriétaires et parmi les trois suivants il y a une boite qui fait beaucoup plus que les autres pour l’open-source: Redhat. Rien que pour cela la KVM doit être choisie le plus souvent possible, mais pas que pour cette raison: Linux est le cœur de l’open-source et ce cœur a choisi pour nous car le module kvm est dans le noyau de base. L’applicatif qemu-kvm se connecte à ce module afin d’avoir un accès aux processeurs virtuels fournis à la fois par le module kvm et la techno hardware VT-x.

Ayant maintenant l’obligation morale d’utiliser qemu-kvm pour soutenir la virtualisation choisie par Linus lui-même (aussi auteur de git !), voyons comment utiliser qemu sans écrire de longues lignes de commandes bien complexes : Pour ceci, il y a libvirt/virt-manager, base utilisant la kvm et utilisé par : openstack, cloudstack, ovirt… Mais ce libvirt/virt-manager qui était le passage obligé des utilisateurs de qemu a un concurrent : cloonix, une API scriptable limpide, une installation simplissime et le doux ronronnement d’un logiciel efficace et précis :)

Autour de Cloonix

Un autre projet accompagne cloonix, c’est un ensemble de petits scripts qui permettent la création des qcow2 des principales distributions. Les qcow2 sont les fichiers représentant les disques durs des machines virtuelles. C’est utile comme accessoire au projet cloonix dont le code est compilé et testé dans chacune de ces distributions tournant en “nested” dans un cloonix de niveau supérieur.