Pourquoi qcow2 ? raw est généralement plus performant non ?

  Guillaume Hilt

Petite précision pour le cas proxmox.

SI on fait du iSCSI, le disque présenté aux serveurs proxmox devra être en LVM. Et il y aura un LV par VM.

Ce qui est naze, c'est qu'en faisant cela, on a pas de snapshot de VM niveau proxmox. On pourrait utiliser le LVM Thin, qui autorise les snapshot de VM,

sauf que le disque lv thin est considéré comme local (normal dans la logique lvm, un volume thin provisionning est un LV (qui en contient d'autre), donc actif à un instant T sur une seule ressource ...)

Donc dans ce cas, impossible de migrer la VM sur un  autre host.

Donc si tu n'as pas besoin de snapshot de VM, part sur iscsi / LVM, sinon, un nfs avec des disques qcow2 par VM, c'est très bien. Après; le iscsi, ca peut être galère au début, y'a plein de pièges dans le quel il ne faut pas tomber, mais ca c'est un autre débat :-D

Reno.

Le 24/06/2017 à 21:01, Colin J. Brigato a écrit :

Pour du container alors la par contre je dirais ni l'un ni l'autre ; un 
container ne devrait pas avoir besoin de stockage persistent, ou alors 
du stockage objet (S3 like).

:s,container,container\ Docker, 

Sans animosité aucune mais les “containers” existent depuis bien avant l’usage spécifique "Dockeresque"d’aujourd’hui, et ceux-ci méritaient en général tout autant un stockage persistant, du coup.

Et sinon pour le “ou alors du stockage objet”, ca reste une couche de présentation :  si c’est que ca qui chiffonne et qu’on à de vieilles habitudes : s3fs, riofs, ou meme goofys – pour l’empreinte plus "container-rationel” même s’il est lent, pour ne citer qu’eux.

P’tet meme qu’on peut stocker des images disques pour [insérez une techno de virtu ici] et monter du S3 sur l’hyperviseur. Juste pour rire.

--Colin

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/