Reprise du message précédent :
Et pour que les VM aient accès au NET et soit accessible depuis l'extérieur, tu aurais du coup "mappé" le bridge ?

EDIT : jusqu'à quel switch tu parles ?

Ah non, pour que les VM aient accès au net/soient accessibles de l'extérieur, soit je leur colle une seconde patte dédiée, soit je met une VM qui fait NAT/FW/Routeur.
Le switch... Au cul de ton serveur proxmox

Actuellement, elles ont 2 interfaces, une sur vmbr0 sans tag VLAN (du coup, elles ont accès au net), une autre avec tag VLAN toujours sur vmbr0.

Donc si je comprends bien, c'est pas tout à fait ce que je veux. Je peux que ça reste dans le serveur

Donc pour te suivre, je crée une interface vmbr1, sans mettre d'interface physique, et ensuite je crée sur chaque VM une nouvelle carte réseau avec en pont, vmbr1. Et du coup, sur chaque VM, je mets à jour network/interfaces ainsi ::

?

EDIT : bon ça semble fonctionner comme ça

Comment je peux vérifier que je ne ressors pas n'importe où et que ça communique bien JUSTE entre les VM ?

Si y'a pas d'interface réseau physique dans ton bridge, y'a pas de raison que ça sorte directement.
Si ton Proxmox à une IP dans le bridge, et qu'il fait du routage/nat, ça *pourrais* passer par là en fonction de la conf (mais c'est hautement improbable).
 

 
Bon, mes VMs peuvent se parler maintenant, ça fonctionne, thx
 
Du coup, 1 bridge par "VLAN" et zou.

Effectivement, et c'est bien dommage    
 

Oui, j'en suis bien conscient, mais je suis un amateur avec peu de besoin    
Je cuisine sans être un cuistot, certaine personne se font des petit dév. persos sans être dev pro etc. Je pensais donc pouvoir me faire assez facilement une vm ayant un accès au net en pensant que ça serait la base. Visiblement c'est un peu plus chaud que ça.  
 
 
 

Sauf que tu cuisine avec tes plaques électriques lambda, pas avec un piano au gaz de plusieurs 10aines de kw
Proxmox c'est "simple", c'est vrai, mais il faut quand même certaines bases pour réussir à l'utiliser (comme tous les hyperviseurs sur le marché). Surtout autrement que "à la maison" (ton serveur est en datacenter c'est ça ?).
 
Tu veux faire des VMs pour quoi, à la base ?

Si y'a bien un truc qui m'agace régulièrement sur du Proxmox c'est ça
"Non mais hésitez pas, faites la mise à jour via la GUI, c'est fait pour et tout !"
Tu test, ça plante, tu finit en shell à rebooter des services chelou
 
Bordel, je commence comme ça, je vais finir sous mac moi

Easy ça
Enfin, tant que t'a la main sur l'hyperviseur. Sinon t'es mal

Putain... Toujours refresh la page avant de poster quand on cause à c0mm0n

Proxmox 4 beta1 out, au menu :
- integration de lxc
- kernel 3.19 (a terme 4.1)
- nouveau module HA
- basé sur debian jessie

J'espère qu'on vas avoir une méthode de conversion OpenVZ vers LXC.

j'espère surtout que la maj se fera sans trop de casse ^^

pour l'instant pas de méthode pour passer de 3.4 à 4.0 mais ils fourniront un how to dès que la 4.0 seras en version finale.
 
Pour info sur la beta 1 l'intégration de lxc n'est pas complète, donc ça peut merder un peu

T'as lu le wiki ?
 
Un backup OpenVZ pourra servir de référence pour créer un container LXC

Non, j'aurais du, mais j'avais d'autres trucs sur le feu

Je pensait à une migration en live
Sans coupure

Je suppose que lxc est désormais là pour remplacer openvz, et que donc ils (proxmox) ne proposeront pas de kernels récents avec openvz.

j'en déduis la même chose

le probleme vient pas de proxmox lui même mais d'openvz qui fait pas le taff assez vite. J'avais vu une discussion sur le forum de proxmox ou un gars d'openvz affirmait que le projet était encore actif tandis qu'un gars de proxmox disait que le passage de openvz a lxc etait obligatoire au vu de l'inactivité d'openvz.

Apparement un kernel 3.10 (datant un peu donc) pourrait fonctionner avec open vz mais pas avant plusieurs mois (encore en alpha). A la vue du retard pris le choix de proxmox est largement justifié

je débarque moi (merci Linuxfr!)
 
bon ben je monte une machine de tests de ce pas !

Bah openvz a été dropé non ? Donc en 4.1 faut oublier
 
XaT

Vous ici

J'ai donc installé Proxmox dans mon Gen8 Microserver et visiblement, bien que je passe bien par le SmartArray, quelque chose quelque part fait que les ventilos tournent en permanence entre 30 à 40%...contre +/- 6% pour les OS supportés par le serveur de base. Est-ce qu'il y aurait quelque chose à faire sous Proxmox pour résoudre le problème ou permettre une meilleure détection du hardware ?
 
Merci.

Le problème viens pas de proxmox qui "détecte mal le hardware", proxmox, c'est jamais que Debian avec des choses en plus.
Le problème viens du fait que le driver pour la carte raid n'est pas dispo pour autre chose que Windows et RedHat. A toi de trouver une bidouille (soit ça existe et c'est documenté quelque part, soit c'est possible mais personne ne s'en est donné la peine, soit c'est mort), pour rapporter un de ces drivers sous Proxmox (~Debian).

Ok, merci d'éclaircir les choses qui confirment +/- mes craintes. De manière générale, et de ce que j'ai collecté sur le net, il semble que les OS à base Debian donne des résultats différents sur le Gen8 : des fois ça passe, des fois ça casse.  
 
Je n'ai justement pas réussi à identifier comment tenter d'installer un driver ou voir de l'activer sous Debian/Proxmox. Y'a pas vraiment de doc en ligne, la plupart des sujets finissent dans le silence...
 
Y'a bien ça : http://downloads.linux.hp.com/SDR/downloads/
...mais bonne chance pour trouver ce qu'il faut dans un tel bazar.
 
 
Ça m'emmerderait de devoir lacher Proxmox juste pour ça.

http://downloads.linux.hp.com/SDR/ => MCP => http://downloads.linux.hp.com/SDR/project/mcp/ =>  
 

 
=>  
 

 
=> hpsum + https://wiki.debian.org/HP/ProLiant + https://wiki.debian.org/Firmware
 
http://ximunix.blogspot.fr/2013/08 [...] ebian.html au besoin donne un tuto qui fonctionne et active le repo modeste de HP Debian compliant. Oublie pas d'activer le repo non-free pour avoir les firmware.

Merci, je vais regarder ça. En passant déjà à une nouvelle rom système, les ventilos sont tombés à 19% mais je pense que pour le reste, ça va se passer dans Proxmox effectivement.

J'ai ajouté une tache automatique pour backuper mes VM / CT dans Proxmox. J'ai en gros 10 CT et 3 VM.

Régulièrement, j'ai des CT et des VM qui foirent leur backup, avec deux types de message d'erreur :

C'est un backup sur un stockage NFS, le serveur Proxmox et le serveur NFS ne sont pas hébergés chez les mêmes prestataires. Est-ce que ça viendrait de là ? Genre un réseau foireux ou autre... ?

PS : le pire c'est que les backup fonctionnent de temps en temps pour ces VM, et certains CT ne sont jamais impactés par les foirages...

tu compress tes vm à la volée avec tar? vzbackup le fait de base ^^
 
et si tu passe tes commandes à la main?

La commande est issue du gestionnaire de Proxmox directement, tu peux choisir si tu veux compresser ou non ta sauvegarde : Aucune / LZO / GZIP.
 
Le truc c'est que de temps en temps (la sauvegarde est programmée quotidiennement à 23:30), les sauvegardes fonctionnent correctement. Certains jours non.
 
Donc je verrais bien un soucis réseau ou autre, mais comment tester ça...

Un smokeping du proxmox vers le nfs? Un nagios?

C'est vrai que rien n'est monitoré sur le proxmox actuellement, ça pourrait ne pas faire de mal...
 
A ce sujet, on est en train de revoir tout le système de monitoring de notre "parc" de serveur. On avait un système maison actuellement, et on cherche un truc plus "stable", Nagios n'est pas trop usine à gaz ? D'autres outils comme ça vous passe par la tête ?
 
J'ai testé munin et j'ai pas aimé

@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.