Reprise du message précédent :
Je suis assez d'accord avec vous, inutile de faire une usine à gaz pour rien, mais il ne faut pas non plus céder à la facilité de tout mettre sur le même serveur si on peut isoler un peu les instances entre-elles, surtout si ce sont des clients différents.

Pour Kaari, j'ai peut-être pas bien saisi la problématique mais des prods à base de VM, je ne vois pas le problème

J'ai le cas d'un système en prod, les VMs sont très pratiques pour le scaling :
- le soft du système tourne sur 2 serveurs qui font le même job, sur 2 sites géographiques différents. On peut perdre l'un ou l'autre sans aucun dommage, on pourrait même rajouter un 3ème site géographique en parallèle des 2 premiers. Idem on peut faire une maintenance, ou évoluer le hardware (cpu, ram, migrer d'hyperviseur...) d'un côté puis l'autre sans coupure du service.
- le système s'appuie sur une base de données qui tourne sur un cluster mongodb sharded, lui-aussi géographiquement redondant, et là c'est super facile d'augmenter les perfs en read juste en rajoutant de nouvelles VM shards. Pour la redondance on a coupé un site entier, c'est passé crème, et rien à faire pour resynchroniser le site une fois la connectivité rétablie.

On a d'autres VMs liées à d'autres services divers et variés, qui tournent la plupart du temps 1 gros service seul, sauf pour ceux ayant une BDD, qui peut parfois se retrouver sur une autre VM dédiée. Ça dépend vraiment des cas.
Si le but c'est d'avoir un petit service qui tourne dans son coin, ou bien s'il faut pouvoir rajouter facilement du CPU, de la RAM ou des I/O disque, on fait les choses différemment.

Quand depart dit "je loue un dédié" ça pourrait très bien se traduire par "je configure une nouvelle VM" De mon côté on s'assure d'avoir tout à double voire triple en cas justement de souci sur un site ou un hyperviseur, mais on a des contraintes de disponibilité des services qu'une PME n'aura pas.

Je bosse pour un grand compte français, donc je rentre pas dans le détail, mais on tourne avec du VMware + k8s pour les projets web.  
Je pense que dans quelles années K8s ou équivalent sera présent à 90% dans le milieu pro. Donc si c’est pour monter en compétences c’est la voix à suivre.  
Si c’est pour du @home un Proxmox avec un backup et c’est bon, avec du Docker dans un kvm si container.

L'intérêt du dédié ou de la VM c'est la possibilité de de garantir la réservation de ressources pour la facturation car sinon comment vous évaluez la charge d'un client au sein d'un seul serveur web ? L'intérêt des VPS ou des dédiés c'est d'avoir la garantie que les ressources que vous louez ne sont utilisées que par vous. Si vos client n'ont pas le budget pour de la ressource garantie alors la mutualisation a du sens mais ce n'est du coup pas au même tarif...

 
Je vois des défauts aux 2 positions extrêmes (tout centraliser ou tout séparer), ensuite, j'ai bien du mal à affirmer qu'il faut absolument positionner le curseur à tel endroit ce qui dépendra fortement du client, de ses besoins et accessoirement des préférences du sysop.

 
C'est comme si c'était fait...

Cela reste une histoire de marketing et visibilité sur le marché. Il est evident que VMware est devant puisque dans toutes les ecoles d'ingé ou de BTS informatique on voit du VMware car une petite subvention a été donné afin de bourrer le crane des etudiants ( un peu comme Cisco avec leur CCNA) comme ca ils sont sur que le lot quelques moutons faible ne se poseront pas la question.

Blague a part proxmox est largement stable pour de la prod meme si des vies sont en jeux. Tu ne connais clairement pas bien le produit pour douter de lui.

Perso je ne travaille pas chez M6 mais j'ai passé une certification proxmox dans la boite qui heberge des sites du groupe M6 et la disponibilité affichée de l'infra proxmox n'avait pas a rougir face a une infra VMware.
Sachant qu'il n'avait aucun produit propriétaire que du libre que ce soit pour les switch, les postes ou l'infra de virtu.

Bref il faut arreter de penser que le plus visible est le meilleur et il faut tester...

PS: J'ai l'air d'un fan boy mais j'utilise les 2 tout de meme, ils ont chacun leur defaut.
J'ai connu et utilisé Proxmox 1.0 donc l'evolution du produit je la connais egalement.

k8s dans les infras petites ou moyennes ça n'a pas vraiment de sens C'est le genre de techno qui nécessite un changement de paradigme dans la tête des admins et des devs, donc seule une grosse infra avec la compétence en interne (ou des prestas €€€) aura un retour sur investissement
 
En tout cas, dans l'état actuel des choses.

Quelqu'un saurait pourquoi certains containers ( le 100 dans mon cas ) ne peut pas être lancé ni supprimé? Dans l'urgence je l'ai cloné et la possibilité de le lancer est apparue mais j'aimerais bien comprendre ce qui s'est passé.

Ptete un bug d'affichage et le container est running ?

Non il ne tourne pas et rafraîchir l'interface ne change rien. Pas bien grave mais je ne peux as non plus le supprimer et ça c'est embêtant. Je débute avec Proxmox et fais donc plein d'erreur, j'ai donc des containers qui occupent de l'espace pour rien.

tu as rebooté l'hote qui le faisait tourner?

Sinon tu va en ssh sur ton hôte et t'essais de le démarrer a la main pour voir d'où ça viens.
Pour la commande, cherche tes autres conteneurs dans un ps aux

Merci pour vos conseils. Le problème venait de la conversion en template. Le ps aux permet bien sûr de trouver les containers.

Question :  
imaginons un serveur dédié (genre OVH kimsufi ou équivalent) avec une seule ip.
1 hôte + plusieurs VM, c'est la porte ouverte pour toutes les galères imaginables ou vous avez des trucs qui fonctionnent ?
Notamment plusieurs VM avec chacune un serveurs web par exemple, une chance que ça fonctionne ? Il faut se faire une VM reverse proxy et des ip non routables pour les VM serveurs web ?
Même chose avec plusieurs serveurs de mails, c'est chercher les problèmes ?

Il faut jouer avec les DNS/Virtualhost pour tes serveurs web.
Meme chose pour tes serveurs mail (enregistrement MX)

gné ?
ça c'est très bien pour plusieurs sites sur 1 machine, mais il reste qu'en terme de DNS, un nom-> 1 ip routable
Donc en gros
toto.com -> 123.231.213.132 qui va être l'ip de l'hyperviseur en gros
Ensuite pour que ça redirige vers une VM plutôt qu'une autre... ???

Oui, reverse proxy. Sur ton RP tu vas déclarer tes vhost qui pointeront vers tes VM hébergeant le site. Tu pourras aussi faire du load balancing pour que ton vhost pointent vers plusieurs VM.

Du load balancing sur plusieurs VMs sur un seul hôte, c'est juste pour le plaisir d'avoir des conf baroques.

pourquoi ?
Il fera de la haute dispo si besoin

Le plus simple avec ce genre de scénario, c'est de prendre une IP publique supplémentaires :
- Une pour l'hyperviseur,
- Une pour un firewall qui nat vers des vm loadbalancer/rproxy (ou qui le fait lui même, genre utm sophos)
Comme ça, si t'a un plantage de l'hyperviseur et que ton rproxy/fw remonte pas, t'a quand même un accès a l'hv pour remonter.
Et c'est plus facile a migrer.

spam !

y'a pas moyen sinon d'utiliser l'ipv6 pour l'hv et la v4 pour une vm fw ?

 
De la haute dispo sur un hôte unique?  
 
Rappelons que le cloisonnement des systèmes linux existent déjà avec les utilisateurs/droits, avec les chroot et autres "jail", au sein d'un serveur web qui fait du virtual hosting, au sein d'un serveur de base de données qui gère plusieurs bases, etc. Il y a donc déjà un cloisonnement même si la porosité est plus grande qu'entre 2 systèmes virtualisés. Comme les ressources (RAM CPU stockage) d'un hôte isolé sont limitées et que l'hyperviseur et la virtualisation bouffent aussi de la ressource et que chaque VM a elle même des besoins minimums, il ne faut pas le faire pour le plaisir mais bien parce que l'étanchéité apportée par le système est nécessaire.
 
Mais, le load-balancing consistant à remutualiser des ressources qu'on avait séparé est contre productif: il est plus simple et efficace dans ce cas de gonfler les ressources mises à disposition du service et d'en changer les paramètres. Ca c'est si une des VM devait planter parce que saturée (le load balancing pur). Si on parle de failover, ça ne change rien: si une machine plante suite à une attaque, la seconde qui aura les même tares plantera aussi surement et s'il s'agit d'une défaillance matérielle, comme l'hôte est seul tout tombera.
 
Bref, pour qu'il y ait haute dispo, load balancing, failover, il faut qu'il y ait plusieurs hôtes, sinon, c'est intellectuellement intéressant mais techniquement beaucoup moins.

t'es parti loin...je te demandais juste pourquoi avoir 1 LB qui loadbalance vers plusieurs VM c'est "avoir des conf baroque" ?
Je pensais que tu sous entendais que 1 seul LB c'était pas sécure mais j'ai pas du comprendre le sens de ta phrase

parce que le load balancing balance la charge, la si ton hote est trop chargé, tu balancera sur ce meme hote trop chargé.
 
Idéalement quand il y a LB, les vm de destinations sont sur plusieurs hotes

Même si en effet un load balancer à peu de sens  (c'est une sorte de redondance et sur le même hyperviseur... bah...), pourquoi pas dans un environnement de staging ?
 
Ne pas oublier aussi que ça protège toujours d'un kernel panic (lol), chose qu'un container ne permet pas.
 
Attention, je ne fait pas partisan d'une telle solution, je suis d'ailleurs du même avis que ilium.
 
En ce qui concerne les ip. Oui, une ip pour l'hyperviseur et une ip pour la gateway nat de ton réseau de vm est le plus simple en tout point, mais tu peux faire avec une ip. En connectant ton hyperviseur à ton réseau de VM. Le côté un peu chiant c'est que si tu as un problème avec ta vm routeur, c'est le kvm pour accéder à ton hyperviseur xP

 
Voilà. Et il est beaucoup plus simple et intéressant d'avoir 1 VM de double puissance que 2 VM de simple puissance (s'il n'y a qu'un hôte évidemment).

Ok je comprends mieux ou tu voulais en venir, tu parlais de l'architecture en elle meme et je suis completement d'accord avec toi.

Pour migrer un serveur c'est bien plus simple également... J'ai changé 4 fois de serveur en 9 ans pour ma feu offre d'hébergement web et avec une VM c'est bien plus simple (juste diminuer le TTL de ta zone DNS et toutes les IP des serveurs DNS et des virtualhost mais ça se fait à coup de grep/sed/awk)...

Maintenant, avec la containerisation, je ferais certainement différemment avec un orchestrateur...

 
Ok donc si je comprends bien :
- mon hyperviseur je lui attribue un port pour le ssh et l'admin via https
- tout le reste je reroute vers 1 VM précise avec par exemple un nginx ou apache pour faire un reverse proxy
- ce reverse proxy dispatche les virtual hosts vers les ip/ports qui vont bien sur les autres VM.
 
1) Du coup mes VM "serveurs web", elles ont des ip non routables ?
2) C'est pas un peu le bronx pour les certificats SSL ? il faut qu'ils soient sur le reverse proxy (et chaque serveur web), donc il faut des scripts pour les dupliquer/transférer ?
3) pour l'accès ssh des VM serveurs web ça se passe comment ? on mappe sur des ports au pif de l'ip publique ?
4) et pour tout ce qui n'est pas du service http (genre mail par ex), on peut faire du reverse proxy aussi ?

1- Evidemment, elles ne sont pas en adressage public.
2- Les certifs sont sur le reverse proxy uniquement. Le dialogue entre reverse et site peut se faire en http, c'est même plus simple.
3- Soit rebond, soit des ports si tu veux un accès direct (ce qui n'est pas forcément conseillé puisque tu fais ça pour cloisonner).
4- Ca dépend des services: les mails, ce sera du transport par exemple depuis un frontal.

J'ai proxmox virtualisé par vmware sur une machine windows. Il y a un moyen d'exporter mon backup tar.lzo sur l'hote windows? J'ai essayé avec scp mais je n'obtiens qu'un shell >, et je ne trouve pas de bouton dans le gui pour télécharger ce backup.

Si tu n'y arrives pas en scp en ligne de commande, pourquoi tu fait pas un filezilla/winscp ?

Je note le coup du filezilla, merci pour l'idée. Dans la mesure où le gui est en html5 je pense qu'il y a forcement un moyen de télécharger le backup avec ce gui non?

Euh, j'ai pas souvenir non. Et le fait que ce soit en HTML5, je vois pas trop le rapport

Ça manque un peu alors cette option. Quand tu listes tes fichiers sur un navigateur tu peux les télécharger, ça serait bien que Proxmox fasse de même avec les backups.

Pour toi utilisateur sur une VM avec des petites vms dedans.
Sur les cluster de 10 hôtes que j'ai pu voir, dont certaines vms a plusieurs To, j'aurais pas vraiment eu l'usage. Faut pas l'oublier, mais Proxmox vise un public pro, qui en général dispose d'un stockage déporté pour les sauvegardes...
Mais si tu codes la fonctionnalité, je t'invite à la proposer

Ce ne sont même pas des VM mais des CT puisque je virtualise proxmox car je le teste simplement. Ne t'inquiète pas, mes serveurs de prod sont hors de portée de proxmox mais quand on est libriste on ne peut pas ignorer cette solution libre. Quand je vois le mal et le peu d'info que je trouve sur comment effacer un CT ou le déplacer ce n'est pas demain la veille que je mettrai Proxmox en prod, peut-être après demain  

Vu le nombre de Proxmox que j'ai vu en prod, j'aurais tendance a dire que c'est plus un problème de connaissances du produit qu'un problème du produit en lui même

Un hfrien avait posté ça : https://blog.debugo.fr/tuto-virtual [...] -debian-9/
C'est un peu hardcore mais ça semble correspondre à ce que tu veux.

 
Tu as de la chance, dans mon entourage c'est Hyper-V et Vmware, rien d'autre. Il est certain que je manque cruellement de connaissances sur proxmox et bien plus encore de lecture pour m'améliorer mais je ne désespère pas.