Reprise du message précédent :
@work j'ai du EyesOfNetwork : une suite avec du nagios, un outil de conf pour nagios, cacti, ... Un peu lourd mais plus simple qu'un nagios nu.
@home j'ai... la flemme.
Un pote @work ne jure que par centreon.
Sinon y'à shinken aussi.

Mais smokeping, c'est vraiment pour surveiller la stabilité du ping entre tes deux serveurs que pour faire de la vrais sup complète.

shinken pas mal si tu arrives a l'installer.
zabbix, centreon.

edit: burned

@work cacti/nagios que l'on est entrain de migrer vers Zabbix
@home munin que je viens de remplacer par Observium

nagios vers zabbix, why?

Observium :

Juste un peu buté...

 
ne correspond plus au besoin, manque des fonctionnalités ...  
et niveau perf on commençait à avoir trop de matériel à checker.  
 
la nouvelle infra de supervision, c'est plusieurs serveurs core, des noeuds déportés et un cluster pgsql dédié.
c'était pas évident de faire la même chose avec Nagios.    

shinken était envisageable alors, vous gardiez vos modules etc, et vous pouviez séparer vos poller and co et gagner en puissance.
 
Y me semble que c'est Grao qui en parlait sur un autre topic de la scalabilité du bordel

Shinken a été envisagé et mis en parallèle avec d'autres solution lors de l'étude des besoins, mais n'a pas été retenu  à la fin de la première partie du projet.
 
là me demande pas pourquoi j'ai pas suivis le truc  
 
Pis y avait déjà des compétences sur Zabbix dans l'équipe, donc on part pas de 0.

ceci explique cela alors ^^
 
merci

Nagios + weathermap... et ça suffit pour voir l'état de saturation d'un lien réseau    
Smokeping perso je l'utilise pour la partie chez moi vers web, ça permet de voir les coupures.
 
D'un proxmox vers un nfs autrement il y a bmon et monitorix (pas testé ce dernier... mais sympathique), et vnstat/vnstati que j'installe systématiquement : un cron pour remonter les stats en graphique et affichage dans une page web. Il me semble avoir vu vnstat justement sur une version de ddwrt...

Si t'a la main sur le lien. Sinon...
Le smokeping, il te permet de visualiser un peu l'état d'un lien/d'une suite de lien/de réseaux sans avoir la main dessus, juste en regardant la variation du ping.

J'ai finalement "corrigé" mon problème de backup en prenant un serveur de stockage chez le même prestataire que le serveur proxmox.
 
ça marche du feu de Dieu

Je trouve la solution un peu facile
Mais l'important, c'est que ça marche

J'ai pas trop le temps de faire des tâches d'admin sys Mais j'aimerais bien mieux me former !

Yop,
 
Tite question: je souhaite faire du chiffrement de partition avec luks (cryto-setup) cependant les cipher qui sont présent dans une vm kvm sont vraiment faible
 
moyen d'en rajouter?
 
J'ai ca de base:

 
sur une debian 8.1
 
merci
 

Lorsque l'on met un CT en bridge, pour définir une @IP, est ce qu'il y a plus propre que de modifier directement le fichier de conf dans /var/lib/vz/root<ctid>/etc/... ?
Je ferai bien du salement propre en générant ce qu'il faut via SALT.

Perso, c'est ce que je fais à chaque fois. Je suis preneur d'une autre méthode.

Perso je le boot, et je modifie la conf directement dedans. Dans intervalle, évidement, il n'a pas d'IP. Pour faire un truc vraiment clean via SALT, je le mettrait sur un bridge dédié, avec un petit DHCP qui n'accepterais de donner une IP qu'a lui (en plus de la passerelle), le booterais dessus, editerais sa conf via SALT, puis le rebooterais en le changeant de bridge.

J'avais pensé à une solution similaire mais en utilisant les IP routées d'OpenVZ plutot qu'un DHCP

Mais je pense que je vais finir par faire un mini module SALT pour créer le conteneur via l'API REST de proxmox puis aller modifier en "dur" les fichiers de configuration du CT pour initialiser une pré-configuration.

Il n'existe pas de script de post-install avec OpenVZ utilisable avec proxmox ? (au final cela ferait la même chose, mais ça utiliserait des utilitaires embarqués )

Au final pour l'instant, ce n'est pas tout à fait ça, mais ça semble faire le taff: https://github.com/bougie/salt-proxmox-vz

Proxmox 4 beta 2 sortie :
- kernel 4.2
- qemu 2.4
- une pléthore de bug lxc corrigés
- conversion CT openvz vers lxc

la suite http://forum.proxmox.com/threads/2 [...] -released!

Perso j'suis en train de tester la 4 béta 1 sur mon dédi@SYS.
Pas de grand changement openVZ<>LXC, sauf peut être l'impossibilité d'avoir un serveur ou un client NFS dans le container.
Après, j'ai pas encore eu le temps de tout tester

je teste aussi sur mon dédié mais ca merdouille au boot du serveur il n'arrive pas a monter mon pool zfs en raid 1.

donc pas de démarrage je maitrise pas des masses zfs donc je vais voir pour me dépatouiller

drapal! Sur un hp gen8, proxmox ne pose pas de soucis de ventilateur qui tournerais à plus de 6% en idle ?

Le contenu de ce message a été effacé par son auteur

Pas de soucis de mon coté en tout cas

Perso, je tourne jamais en-dessous de 19% malheureusement...
Jamais trouvé comment descendre plus bas.

bon le dernier proxmox 4 j'arrive à rien sur les dernières rev....
 
pour debian dans le novnc j'ai ce message: guest has not initialized the display (yet) (kvm64 comme archi cpu)
 
et pour du freebsd: impossible de démarrer la vm:

(qemu64 pour le cpu)
 
En kvm64 j'ai le même message que la debian.
 
Tout ca sur du stockage zfs.
 
Une idée du soucis? car d'après ma recherche google (peut être pas avec les bons termes certes) pas de réponses probantes
 
Merci

Y'a quoi dans les logs système ?
T'es à quelle révision ? Béta1 ? Béta2 ?
Perso j'ai pas de soucis sur du Debian, mais j'ai pas le temps de tester plus en détails.
Commence par tenter avec un stockage local standard peut être ?
Moi je me pencherais sur :  

Si je m'avance un peu, j'en déduirais bien que quemu64 à besoin de ces deux jeux d'instructions, dont tu ne dispose pas

pour installer du freebsd j'ai utilisé qemu64 effectivement, mais je peux ne pas l'utiliser et utiliser kvm, hors avec kvm j'ai ce message sur le display.
 
J'ai essayé sur le stockage local en ssd, que ce soit en .raw ou qcow2 toujours pareil, j'ai essayé de changer le driver d'affichage, pareil.
 
Pour la version: 4.0Beta-36
 
niveau log quand je boot une vm debian:
 
syslog

 
pas de soucis avec xenserver, proxmox 3.4 ou esxi

Bah tient, solution simple : compare la commande qemu entre ton proxmox 3.4 et ton proxmox 4
Tu lance la vm, tu fait un ps avec les arguments qui vont bien pour récupérer un truc qui ressemble à ça :

Et après, tu compares
 

ouaip vais regarder ca
 
j'ai un template de freebsd sur mon 3.4, je vais voir si je peux l'exporter et l'importer sur le 4 voir si ca change quelque chose

déjà, la comparaison:
 
Proxmox 3.4

 
Proxmox 4

 
Déjà, niveau instruction cpu passée elles sont pas pareils, mais je dirais normal vu que pour le 3.4 c'est un L5520 et le 4 c'est un 3450 derrière.
 
après entre les deux, j'ai rien qui me saute aux yeux

Pareil, rien qui me choc. Ce qui me ferais dire que le problème viendrais de qemu ?
Si tu remplace l'argument -cpu du proxmox 4 par celui du proxmox 3.4, et que tu lances la commande à la main, ça boot ?

j'étais en train de tester ^^  
 
même résultat: guest has not initialized the display (yet)

Version de qemu:

Proxmox 4
qemu-server 4.0-23
pve-qemu-kvm 2.4-5

Proxmox 3.4
qemu-server 3.4-6
pve-qemu-kvm 2.2-10

edit: je vais mettre 3.4 sur le même serveur et comparer les instructions cpu qui sont passées pour voir

Bon avec une 3.4 sur le même serveur ca donne ca:
 

 
donc y a une différence d'instructions cpu.
 
Si je colle celles données par proxmox 4 ca me dit qu'elles sont pas supportées. Donc soit kvm dans le 4 en supporte plus, soit il veut en passer des non supportées.

Je suppose qu'il y a un topic dédié sur le forum Proxmox quand à la version 4, essais de poster là-bas avec les logs et les commandes qemu.
 

fait mais pas vu de section dédiée au 4.

edit: le lien avec une réponse:
http://forum.proxmox.com/threads/2 [...] al-machine