Aller au contenu

jojo

Membres confirmés
  • Compteur de contenus

    14 347
  • Inscription

  • Dernière visite

  • Jours gagnés

    181

Tout ce qui a été posté par jojo

  1. d'après le lien de @Krikroff et les instructions d'installation du firmware, non => je tente le tout pour le tout
  2. cette mise à jour d'ILO nécessite-t-elle de redémarrer le serveur, et donc d'arrêter avant toutes les VMs ?
  3. c'est quoi ce brol ? ILO devient Windows spécifique. J'ai une version WEB, que je trouve PARFAITE.
  4. esxcli system module set --enabled=false --module=vmw_ahci mais il faut avoir un HPGen8, sinon ça marche moins bien
  5. j'ai installé sur une autre clé un Esxi 6.5 J'ai fait le downgrade (en oubliant la dernière commande avant le reboot) J'ai arrêté le serveur Je l'ai rebooté sur la clé 6.5 U1 et j'ai constaté les dégats. Toujours sur 6.5U1, J'ai re-désinstallé le driver 088 Je l'ai réinstallé en faisant bien la dernière commande. Reboot final(sur 6.5 U1) et tout ok
  6. toutes les autres fois, je l'avais fait en 6.5U1. Puis une fois en 6.5 (celle où j'ai loupé la dernière commande) Puis j'ai recommencé en 6.5 U1. Je suis entrain de le demander si la procédure ne serait pas : Downgrade complet. Restart SANS la dernière commande. Recommancer l'opérationavec la dernière commande avant reboot final
  7. j'avais fais à l'époque un VD pour @charles0 qui modifiait la consigne du ZXT120 en fonction de la consigne d'un Nest. Cherche sur le forum (mais où ?) cela devrait t'inspirer.
  8. et la vitesse semble au rdv: je suis monté jusqu'à de 87 MB/S
  9. je nne touche plus à rien, car à force de serrer les fesses comme çà, je vais finir par avoir la chiasse
  10. oui, mais toutes les autres fois, je l'avais bien fait !
  11. ouf, @jojo, tu es vraiment un gros nul. C'est à cause de mes grosses mains pleines de doigts ... En fait j'avais supprimé dans ma doc la dernière instruction que @Krikroff avait dit qu'il fallait faire ... Donc j'ai re-tout recommencé, avec cette dernière instruction et : je suis toujours en 5.5.0.088 j'ai retrouvé mes VM : ouf ! Je vais tester maintenant la rapidité de mes disques
  12. il m'a viré mon Datastore , je n'ai plus rien
  13. je deviens fou. Il a tout fait, SANS erreur (en v6.5) et il m'indique toujours que je sui en 5.5.0.102 [root@HPGen8:/tmp] unzip hpvsa-5.5.0-88.zip Archive: hpvsa-5.5.0-88.zip inflating: index.xml inflating: vendor-index.xml inflating: metadata.zip inflating: scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib [root@HPGen8:/tmp] cp scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib /var/log /vmware/ [root@HPGen8:/tmp] cd /var/log/vmware/ [root@HPGen8:/var/log/vmware] ls journal scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib [root@HPGen8:/var/log/vmware] esxcli software vib remove -n scsi-hpvsa -f Removal Result Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective. Reboot Required: true VIBs Installed: VIBs Removed: HPE_bootbank_scsi-hpvsa_5.5.0.102-1OEM.550.0.0.1331820 VIBs Skipped: [root@HPGen8:/var/log/vmware] ls journal scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib [root@HPGen8:/var/log/vmware] esxcli software vib install -v file:scsi-hpvsa-5.5 .0-88OEM.550.0.0.1331820.x86_64.vib --force --no-sig-check --maintenance-mode Installation Result Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective. Reboot Required: true VIBs Installed: Hewlett-Packard_bootbank_scsi-hpvsa_5.5.0-88OEM.550.0.0.1331820 VIBs Removed: VIBs Skipped: et là c'est ok. Je fais un reboot du serveur pour être sûr. Alors pourquoi les autres fois ça n'a pas marché ????? Peut-être parce que le serveur a eu peur en me voyant décrire tout ce que j'avais fait, pour prouver que c'était bon, et que cet imbévile ne voulait rien entendre ... Je sors du mode maintenance, relandes mes VM et fais un gros backup pour voir la vitesse des disques
  14. ce que je suis entrain de faire : j'installe Esxi 6.5 sur une autre clé. Je fais le downgrade du driver Puis je redémarre sur ma clé 6.5 U1 pour voir
  15. jojo

    Portier Doorbird

    à vous entendre, je suis de plus en plus content de mon revendeur qui a validé mon Doorbird avant de me l'envoyer. Le premier qu'il avait reçu avait également des problèmes de micro. Peut-être que la politique de Doorbird n'est pas de communiquer directement avec les clients finaux, mais qu'ils doivent passer par leur revendeur ?
  16. mais on est d'accord @Krikroff que la commande que tu as donnée à faire avant le premier reboot du serveur, est bien uniquement pour le premier reboot ? Après avec les reboot suivant, cela reste ok ?
  17. c'est peut-être ça mon problème. Merci. Je me fait un Esxi 65 et je regarde
  18. jojo

    Portier Doorbird

    C'est vrai que attendre 14 mois pour remonter un défaut de "conception", ce n'est pas top. Ceci dit, la garantie légale est de 2 ans. Tu peux toujours ire qu'il a bien fonctionné pendant 13 moi, et que maintenant c'est la catastrophe, et que tu le renvoie en usine pour investigation. Je ne sais pas ce qu'ils pourraient faire à distance. Ton cas me fait penser à un problème HW, et pas soft (soft, qui est le seul qu'on peut régler à distance). Alors une pièce peut bien fonctionner qques mois, puis mourir ... C'est pour cela que la garantie est de 2 ans
  19. non, on a bien créé un VM sous Esxi avec Xpeno, qui (comme l'explique @mprinfo) n'est qu'un bootloader (50MB sur le datastore) du DSM qui se trouve sur les disques "data" (=non datastore)
  20. merci, je suis rassuré, puisque @sebcbien arrive dans 20 min. Je vois que tu n'es pas le seul à survoler certains posts...
  21. depuis que je suis passé en 6.51, le client lourd Windows ne veut plus fonctionner. Il veut faire une mise à jour en cherchant à se connecter à l'adresse 0.0.0.0 => erreur. Avez-vous observé également le problème?
  22. jojo

    Google Home

    merci pour l'info, mais malheureusement, entre le moment où j'ai posé la question et maintenant, j'i"n ai touché un mot à ma femme, et c'est un NON catégorique pour la GH ...
×
×
  • Créer...