bonsoir,
je suis nouveau dans le monde de la virtualisation depuis 2 semaines et je viens de découvrir l’écran ci dessous où il semble qu’il y ai pas mal de mise a jour a faire.
ceci choque t il les spécialistes ? dois je les faire impérativement ? pas d’autre choix que de les faire en masse ?
merci de vos lumières …
Hello
Bon, comme il n’y a pas la capture dont tu parles, en voici une :
Dans le cas du 2ème bouton, ça ouvre une console
oups, effectivement, quel couillon je fais. Je l’ai sous la forme ci dessous et j’applique toutes les mises a jour sans me poser de questions ? (j’ai sauvegardé les VM pendant que je tapais le msg précédent)
C’est un choix personnel : si tu es courageux, capable de réparer, ou si tu as des soucis alors oui. Sinon c’est pas indispensable tant que tout fonctionne : non
Sauf à exporter tes VM sur un autre filesystem/disque pour être certain de pouvoir en faire un truc en cas de souci : ça sert à rien. La mise à jour concerne l’hyperviseur…
Bonsoir,
Tu peux faire la mise à jour. C’est comme pour tout OS/logiciel, les mises à jour permettent de corriger des bugs, de combler des failles de sécurité. Tu n’es pas obligé de les faire, c’est à toi de voir.
courageux : non
capable de réparer : non
soucis non
tout fonctionne : oui
ca répond a ma question…
mes VM se sauvegardent sur mon NAS
les mises a jour ne sont donc jamais sans risques, ce qui me surprend, c’est de ne pouvoir les faire que toutes en meme temps …
merci de vos lumières
Les faire toutes ou aucune, ça assure la compatibilité… Tu prendrais le risque d’en faire 1 sur 2 sans avoir vérifié les dépendances et le changelog entre chaque ?
vu comme ca … forcément ! lol
je suis incapable de vérifier les dépendances sauf sous jeedom où ca s’affiche en rouge quand c’est pas bon. l’idée était plutôt de les faire une a une en ayant le temps de voir si tout marche entre chaque comme je fais maintenant sous jeedom avec les sauvegardes qui vont bien, enfin j’espère
Tu mélanges les concepts … Là il a 3 niveaux !!! Hyperviseur => VM => Jeedom
c’était juste pour te confirmer que je ne sais rien faire en ligne de commande
je comprend bien les 3 points que tu expliques mais comme je me suis fais bannaner par des mises a jour ces temps ci, j’y réfléchis a deux fois mais ca ne change rien, si j’appuie sur « mettre a jour » et que ca foire … ben restaure, etc, etc. a se demander s’il ne vaut pas mieux attendre que tout plante faute de MAJ pour remonter un truc propre (en prenant soin de faire sauvegardes et sauvegardes…)
J’avais déjà répondu dans ce sens sur le sujet de ta bascule pi vers nuc :
C’est pas parce que tu as un nuc que ça te sauve… Les soucis sont les même : fausse manip, backup pourri, erreur du débutant (la complexité en plus pour les VM/hyperviseur)… La restauration en un clic, c’est pas toujours aussi simple, si la ‹ chaine › marche, pas c’est mort
Cliquer sans réfléchir ou ne pas cliquer, c’est une méthode aussi inutile l’une que l’autre : ça reviens à faire un marathon sans préparation, ou pas de sport du tout…
pour ma bascule, il y a 2 raisons :
*la vitesse et là, y a pas photo, je gagne en confort
*la sécurité dans le sens où je sauvegarde tous les jours jeedom et les vm contenant jeedom.
un point que je ne voyais pas si important : la ou les machines d’essai pour, justement des mises a jour a ceci près que lorsque ca concerne des usb, je m’oblige a arrêter le jeedom de prod pendant les essais
que veux tu dire par la restauration en un clic n’est pas toujours aussi simple ? j’ai fais quelques essais de restauration de vm et ca marche plutôt bien, long mais bon …
par contre si je devais reinstall proxmox puis restaurer, etc, je suppose que ca se complexifie… tu peux me confirmer des points qui me tomberont dessus le jour où ?
Cliquer sans réfléchir ou ne pas cliquer, c’est une méthode aussi inutile l’une que l’autre : ça reviens à faire un marathon sans préparation, ou pas de sport du tout…<
je suis bien d’accord mais faut il avoir les moyens d’y réfléchir…je veux dire par là que j’ai un cerveau (pas forcément performant mais présent) mais c’est tout !!!. En gros, je suis bien obligé de faire confiance aux développeurs puisque je ne peux rien contrôler. la seule solution pour moi n’est elle pas de créer un point auquel je peux revenir en cas de crash avant toute modif ? s’il en existe une autre je suis preneur car c’est lourd !!
après, peut être que jeedom n’est pas pour moi et qu’il doit rester élitiste … qu’en dis tu ?
Bonjour,
Sur le dépôt community de Proxmox, et sur le dépôt debian tu n’as pas plus de risques à faire les MAJ que sous win 10. C’est à dire quil faut être conscient que quelque chose peut mal se passer mais que cela reste de l’ordre de l’exception (hors coupure de courant bien sûr !).
Il existe par ailleurs un script pour « sauvegarder » Proxmox. Ce n’est pas une sauvegarde totale : il faudra réinstaller Proxmox, mais cela sauvegarde les fichiers de configuration. Et je ne peux pas garantir que cela fonctionne à 100 %. Faut être un minimum à l’aise avec la ligne de commande. Et savoir suivre un tuto pas à pas.
Oui, même si un pi bien configuré ça marche pas mal non plus.
2 types de sauvegardes, c’est bien, mais 1 seul emplacement de sauvegarde ça gache tout…
Ouais, à force de venter la virtualisation comme LA solution, on en arrive à ne pas tenir compte des fondamentaux : pour tester, il faut être en mesure de reproduire fidèlement les conditions de l’expérience… USB c’est compliqué sauf à avoir plusieurs matériels, et dans le cas de l’appairage, c’est pas possible.
Donc au choix, tout en double (et bonjour le budget) ou on dépouille l’environnement de production (avec les risques que ça implique)
Là non plus pas de solution miracle : si tu as pas un backup qui marche tu es coincé, si tu as pas 2 disques dans proxmox, c’est plus compliqué
C’est bien pour ça que proxmox ne propose pas d’autre alternative que mise à jour complète ou rien du tout. Tu dois faire confiance au contenu ou pas.
Maintenant, comme tu as pas moyen de faire une copie complète de proxmox avant la mise à jour et de la restaurer en cas de souci, ça limite les options à celles juste au dessus.
Le souci de backup est le même peu importe le contenu (proxmox, jeedom, debian)
Toutes proportions gardées, jeedom c’est compliqué, linux, c’est compliqué et la virtualisation aussi…
Donc si on est pas à l’aide à un niveau, c’est pas dit que la solution soit de rendre les choses encore plus dépendantes en ajoutant proxmox. Il y a pas de secret, il faut se former au fur et à mesure.
Personnellement, je sais faire de la trottinette, je conduit plutôt bien, mais si on me colle une F1 sur un circuit, je suis quasi certain de finir dans les graviers au premier virage… J’ai donc pris l’option d’avoir une voiture adaptée à mes capacités, plus je roule et plus je progresse. Le jour ou il faudra que j’affronte un vrai pilote, j’aurai peut-être une chance
jamais eu de pb d’accès au nas que ce soit avec jeedom ou avec proxmox, je vérifie régulièrement la présence de mes sauvegardes. d’ailleurs, faudrait que je pense a automatiser cette vérif si toutefois leur seule présence suffit …
le nas est en raid 1
oui, voilà le pb que je rencontre, je clone donc régulièrement la vm de mon jeedom pour essayer mais je n’ose pas avec la clé z wave qui contient pas mal de données sensibles…les essais sont limités mais c’est mieux que rien va t on dire
1 seul disque dans proxmox. Je dis une connerie si je dis que si tout plante, je réinstalle proxmox et je récupère les sauvegardes de mes vm, c’est bon ? veux tu parler d’un systeme genre raid1 pour proxmox ?
est il possible de copier ou cloner le disque de proxmox en automatique sur le nas ?
compliqué, compliqué, oui, je progresse, j’apprend mais je me rend compte que je suis quelques fois des tutos sans bien comprendre ce que je fais. Pour transposer ta comparaison au monde moto dans lequel je suis plus a l’aise, j’aime bien l’expression qui dit « ce ne sont pas les 200 chevaux du moteur qui sont dangereux mais l’âne qui est assis dessus ». de toute façon, pour utiliser jeedom, il faut une couche de linux, donc il faut bien se jeter dans le bain a un moment, non ?en ce qui me concerne, je considère la virtualisation principalement comme une seconde « couche » de sauvegarde, peut être que je prend ca trop a la légère …
merci pour le lien mais voilà typiquement là où je bloque : « nag », « community repo », sur 4 lignes, 2 termes me sont inconnus.
ok, je peux chercher et en savoir un peu plus mais je vais finir par suivre un tuto bêtement et donc dangereusement …
C’est une collection d’outils donc il y en a plusieurs.
Nag c’est le popup. Et community tu as déjà dû faire l’opération si tu as suivi les bons tutos. Donc pas d’intérêt pour toi.
Celui qui t’intéresse est « backup », mais en effet si tu ne comprends pas du tout il vaut mieux s’abstenir en effet, c’est plus prudent.
C’était pour indiquer qu’il est possible de faire un pseudo backup de Proxmox.
Je ne connais pas Proxmox plus que ça.
Je suis plutot partisan de VMWare et ESXi
Mais il faut relativiser.
Avez vous vu déjà des mises à jours hyperviseurs mal se passer ?
Je parle en tous cas de Vmware, ce sont des environnements maintes fois testés et eprouvés.
Et je n’ai jamais vu une mise à jour planter le système.
L’important au final sont les données, donc les VM.
Si tes VM sont exportés ailleurs tu à peu de risques…
Au pire du pire réinstaller un hyperviseurs et réintégrer tes VMs… Ce n’est pas insurmontable.
Quand on se lance dans la virtualisation, il faut en effet en maitriser les quelques principes de bases et tester ses modes dégradés et sa restauration.
Moi franchement aujourd’hui sur ESXi, même si le pc venait à flamber, je pense qu’il faudrait moins de 2h pour tout remonter.
De nos jours avec les risques Cybers, les bugs, …
Je pense qu’il y a plus de risque à ne pas mettre à jour que le faire.
À titre pro oui et plusieurs fois.
Globalement les conséquences sont limitées puisque les vm sont migrées ailleurs le temps de la manipulation. N’empêche qu’on se retrouve avec une infrastructure amputée.
Et c’est là que tu es bien content de payer le support pour avoir un bon coup de main et sécuriser un peu la correction
À titre personnel, c’est moins courant parce que c’est pas aussi complexe au niveau de l’infra et que dans le pire des cas, on reconstruit sans perdre de données mais avec une interruption de service
