Reprise du message précédent :
https://www.frameip.com/
Bonne lecture

 
Merci
 
Ça a l'air très complet comme site.

Oui, je le trouve plutôt sympa
 
XaT

Le probleme n'est pas le multicast en lui meme (quoique on t'apprend pas ca partout) mais c'est surtout que beaucoup font un cluster proxmox sans lire la doc et ne se souci pas du multicast et ca marche forcement moyennement.
Et après ils viennent dire que proxmox c'est pas fait pour de la prod.

Perso je faisais parti de ces gens jusqu'a ce que j'aille faire un formation proxmox ou j'ai vraiment appris plein de choses.

Bonjour à tous,
 
Nouveau sur proxmox. Je viens d'installer un node sous pve 5.2.
J'ai toujours besoin d'un windows en version 8.1 max pour un soft particulier.
Après avoir un peu galéré, j'arrive à tout installer y compris les drivers virtio.
Le problème c'est que dès que j'active le driver balloon j'ai le process wmi host provider qui bouffe tout le temps cpu.
 
Avec les virtio 0.1.1.141, j'avais le cpu tout le temps à 100%
avec les 0.1.1.160 ça oscille entre 50 et 100%.
En plus même si le service balloon tourne, le driver est bien installé et le device balloon activé dans l'hote, la quantité de ram mesurée dans l'hôte est fausse.
Je n'ai rien trouvé de probant sur les forums.
 
Vous auriez une piste?
 
edit: j'ai un truc bizarre.
Dans la console services.msc je vois bien le service balloon demarré
Dans le gestionnaire de périphériques je vois le periph systeme balloon driver actif et fonctionne normalement
Dans information systeme je vois balloon service en demarrage manuel et arreté.

voila le sever est la, j'ai déjà créé une vm OMV dessus pour tests, déploiment ok !
Je viens de migrer une vm peu importante de mon esxi vers prxmox, si on fait ça dans l'ordre ça passe crème
 
Mon Nas qui servira de cible ISCSI devrait arriver dans la semaine, la config prend forme. (IX4-300D avec 4*3TO)
Dans le server je vais laisser 2SSD en raid 1 (sur ma H700 ou géré via proxmox vous feriez quoi?) et 3/4hdd de 2to (idem mais pour du raid5)
 
par contre j'ai du mal à avoir les remontées de l'agent qemu-guest, sur l'omv j'ai fait un shutdown/restart de la vm et je l'ai eu, sur celle venant de l'esxi (vmtools supprimés) j'ai toujours pas la remontée de l'IP

edit : hum j'étais en mode pas attentif, j'ai activé le qemu agent dans les options de la vm, et ça remonte

Tu voudrais faire un raid sous ZFS ou mdadm ?

Avec ZFS si tu veux suivre les bonnes pratiques, il faut une bonne quantité de RAM ECC et un accès direct au disque (mode HBA). https://pve.proxmox.com/wiki/ZFS_on_Linux

Pour mdadm, la carte raid sera plus intéressant a mon sens. A moins que tu es besoin de la carte raid dans une autre machine.

merci pour la réponse;
non je ne compte pas utiliser ZFS, donc en effet je vais rester sur ma carte raid c'est encore plus simple je pense (hé oui j'ai des backups )

J'ai des soucis avec l'interface web de Proxmox et Firefox 62.0.3 (Windows). Par exemple, je ne peux plus déployer le contenu de mes hosts. ça vous est arrivé ?

même chose en 'navigation in private'?

Tu n'as pas installé un bloqueur de script un peu trop ... Zélé ?

Oui c'est pareil en navigation privée.
Je n'ai pas le problème sur linux j'ai les mêmes add-on :-/

Shift+f5 ?

Je les ai désactivés un par un, ça n'a rien changé. Je remarque que même les boutons "logout", "create VM" sont inactifs.
C'est même plus simple que ça : tout est inactif sauf le lien vers proxmox.com.
Shift+F5 ? Tu veux dire F12 ? Et bien ?

Non shift+F5 rafraîchir la page et le cache avec.

et avec un autre navigateur sur ce même PC ça passe?

Oui avec chrome sur ce même poste Windows, pas de soucis.

Salut,
 
J'avais eu des soucis avec noVNC suite a un update, problème résolu après vidage du cache de FF. Par contre, j'avais aucun soucis avec les boutons logouts, create VM,...

C'est donc ton profile FF qui est en cause. Avec un nouveau profile ça fonctionne ?

Je ne connaissais pas cette notion de profil Firefox.
"firefox.exe -profilemanager" ne donne rien.
 
Et j'ai bien trouvé un 'Firefox account' dans les options et plus loin 'manage account' mais rien pour créer un nouveau profil.

firefox -p sous windows

Hum, c'est un peu dommage de faire 0 recherches :  
https://support.mozilla.org/en-US/k [...] x-profiles

nas IX4-300D arrivé, je vais pouvoir monter ma cible ISCSI

 
Vraiment pas cool et rabaissant d'écrire '0 recherches' alors que je parle de -profilemanager comme si je l'avais inventé. Oui, j'ai fait des recherches !  
Mais bref c'est HFR il y a toujours des donneurs de leçon.
 
Après la création du nouveau profil, ça ne change strictement rien. Les liens ne sont toujours pas cliquables.  
Le passage à la nouvelle version de Firefox j'a rien changé non plus...

Suis sous W10 pro, FF 63.0 et aucun soucis avec le webgui ...

 
Je donne pas de leçon, ca m'a pris 30 sec sur google pour avoir cette page... Il y a plusieurs façon de faire et a priori tu n'étais pas tombé dessus. Bref tant pis...
Faut pas s'énerver pour ça non plus sinon tu risque de baisser les bras bien vite dans tes envies de proxmox XD
 
Tente un autre profil windows à tout hasard.

Bonjour à tous,
Je suis en train de réaliser un petit lab-test d'un cluster de 3 noeuds Proxmox. Le cluster est fonctionnel et j'utilise un stockage iSCSI. (LUN hébergée sur un Synology) Les VMs sur les 3 noeuds sont donc toutes stockées sur la LUN via un volume LVM.
L'objectif est de mettre en place du HA sur les VMs. J'ai donc créé un HA Group et rajouté mes VMs dedans. Le fonctionnement du HA est plutôt prometteur à un détail prêt :
Lorsque je coupe volontairement un des 3 noeuds sur lequel tournait une VM, celle-ci est bien migrée vers un des 2 autres noeuds, mais elle ne récupère pas l'état dans lequel elle se trouvait. (Elle redémarre complètement, donc perte possible de données)
Je cherche donc à faire en sorte que l'état de la VM soit conservé. Pour ça je pense que la RAM des VMs doit être synchronisée régulièrement entre les noeuds, mais j'ignore si cela est possible.
Si quelqu'un a des informations sur ce sujet-là, je suis preneur, merci.

Bonjour
 
Je connais pas suffisament bien proxmox pour te certifier que c est pas possible mais sous vmware ou hyper v il n y a que le replica / fault tolerance qui permet ca. Ce n est pas le cluster en lui meme. Le fonctionnemenr clyster de vm est exactement ce que tu as la comme resultat. Sinon c est le service qu il faut mettre en cluster.

Alors c'est un comportement "normal" de Proxmox.
 
Je dis "normal" car c'est voulu par les développeurs. J'en ai longuement discuté avec eux, mais ils considèrent qu'éteindre volontairement un nœud est une opération d'administration réfléchie. Donc si les VM n'ont pas été migrées "live" au préalable vers d'autres nœuds, elles sont stoppées proprement et redémarrées par le service HA sur un autre nœud du groupe. Donc avant de stopper un nœud pour maintenance, il faut manuellement bouger les VMs "live" puis les remettre dessus une fois le serveur revenu.
 
Maintenant si tu espères que les images RAM des VMs soient répliquées en temps ~réel sur les autres nœuds du groupe et que tu puisses stopper (à la dure) un serveur sans interruption de service, ce n'est 1 pas encore possible dans Proxmox et 2 demandera une infra réseau dédiées minimum en 40Gbps (10Gbps pour des tests) pour être viable.

Pas encore dispo sur Proxmox. Il y a une fonctionnalité dans Qemu/kvm, mais c'est pas encore considéré comme assez fiable pour être dispo dans Proxmox.
Je rejoint Matteu : à ce niveau il faut penser HA des services.

explication claire et limpide, je n'en suis pas encore la mais je me serai posé aussi la question donc je te remercie déjà

C'est surtout que c'est techniquement casse-gueule de répliquer la RAM.
 
La raison principale vient d'un problème d'ordre de grandeur de latence réseau vs latence RAM. Tu peux pas répliquer pareil des bits de RAM comme tu le fais pour des blocks de disque (DRBD par exemple). C'est beaucoup plus difficile.
 
Un papier des mecs du projet COLO sur la question : https://54e57bc8-a-62cb3a1a-s-sites [...] 3-dong.pdf (le papier date mais la problématique est toujours vraie )
 
Bonne lecture

Merci beaucoup pour vos informations, j'y vois plus clair. En effet je me doutais bien que l'une des causes principales était l'écart de performances/latences entre le réseau et la RAM.
Je m'apprêtais à faire un second lab-test avec cette fois-ci Ceph avec stockage local. (pas d'iSCSI) Mais le résultat lors d'une panne d'un noeud risque d'être le même : reboot de la machine guest sur un autre noeud.

Si ta besoin de pas perdre la RAM en cas de coupure, c'est que sois tu fais un truc ultra critique et faut dépenser cher en infra pour éviter, ou tout simplement tu compenses coté software (par exemple une BDD répliquée).
 
Mais pose toi surtout la question dans l'autre sens : quels sont les vrais besoin de prod. Un reboot de VM ça prend 30 secondes, ton RPO et RTO vont être déjà très bon.
 
D'ailleurs dans 80% des cas la HA (même de base) complique plus les choses qu'elle n'aide…

Bien sûr, je suis entièrement d'accord avec toi. Ce fonctionnement me conviendra. Ne connaissant pas encore parfaitement Proxmox, je me posais ces questions davantage dans un esprit de "défi technologique/informatique" si on peut appeler ça comme ça. Mais après réflexions et après ce que vous m'avez dit, j'ai bien conscience que dans la pratique ça peut devenir complexe. Et je suis d'accord aussi sur le fait que la HA peut compliquer les choses j'en ai fais l'expérience ...

J'aurais besoin d'une petite confirmation concernant un aspect du stockage iSCSI. J'entends souvent qu'il ne faut pas connecter plusieurs initiateurs à une seule et même cible iSCSI. (risque de corruption de données lors d'écritures simultanées), sauf si on utilise un clustered file system. Me concernant, j'utilise un volume LVM monté au dessus ma LUN iSCSI. Je stocke ainsi plusieurs VMs dessus, et elles tournent en même temps et sur plusieurs nœuds de mon cluster. Vous me confirmez que je ne prend pas de risque à pratiquer comme ça ? Le stockage LVM sur iSCSI est compatible avec des accès simultanés depuis plusieurs hôtes ?

Hormis pour les snapshots de ta LUN côté SAN/NAS pourquoi être parti la dessus ? Personnellement, j'aurai fait un "simple" stockage NFS sur le NAS qui est tout aussi rapide que le iSCSI (limité par l'infra) sans tous les inconvénients. Et qui est de type "shared" par défaut, NFS étant fait pour gérer les accès simultanés.

J'aurais tendance à dire que c'est bon, tant que tu t'amuses pas a présenter la cible iscsi en elle même a une vm mais que tu présente le lv via l'hyperviseur.

Je rejoins l'avis de deadlock. Fervent defenseur du iscsi il y a encore 3 ans depuis que je monte toutes mes baies SAN en nfs je n'y vois que des avantages d'autant que couche filesystem nfs est native pour la plupart des hyperviseurs et des baies.

Pour info c'est lors d'un deploiement de baies netapp que l'ingénieur netapp ma fortement deconseillé le iscsi avec mon infra vmware et ma démontré la simplicité de mise en oeuvre du NFS et les performances similaires voir meilleures dans certains cas.

ha vous m'intéréssez la, je pensais faire du ISCSI sur mon IX4-300d, mais je ne suis pas contre une remise en questions