Jump to content
XPEnology Community

joinman

Member
  • Posts

    21
  • Joined

  • Last visited

Everything posted by joinman

  1. Donc je n'utilise pas de RDM ! ça fonctionne quand même très bien.
  2. Je n’en ai aucune idée. @claude75 a effectivement mentionné cela. Perso, j’ai fait comme écrit dans mon post. Désole.
  3. Merci à tous. Je me suis planté une première fois, car comme dit @nicoueron, il faut aller très vite pour sélectionner le boot ESXi. Donc j'ai loupé cette étape, il a démarré normalement et en plus j'ai quand même essayé d'installer le DSM. Là plantage, c'est dire qu'il me dit "Echec du formatage". J'ai donc redémarré en réussissant à sélectionner le boot ESXi. Là idem. Je pense que j'ai dû "abîmer" le synoboot.vmdk, car je viens de tout refaire comme indiqué par @claude75, puis en choisissant l'option ESXi, et là ô miracle tout fonctionne. Je vais quand même refaire une tentative complète histoire d'assurer le coup avant de passer en prod Alors petit REX quand même. - Suppression des anciens fichiers de la VM sauf mon <Nom du NAS>.vmdk. - Création d'une nouvelle VM et suppression du disque dur existant. Donc c'est une création sans disque dur - Dans le répertoire créé, upload des fichiers (obtenu grâce à l'utilitaire Starwind V2V Converter et le fichier synoboot.img) dans l'ordre suivant. Au fait pourquoi ne pas avoir conservé le système avec un fichier ZIP contenant les bons VMDK et autres fichiers. Je suis sous MAC, et j'ai dû dépoussiérer ma VM Windows pour installer l'utilitaire ! - synoboot-flat.vmdk - synoboot.vmdk (à noter que le fichier synoboot-flat.vmdk n'est plus affiché dans le répertoire) Comme indiqué par @claude75, je n'ai pas copié le fichier synoboot.img - modification de la VM en ajoutant les deux disques dans l'ordre (en mode dépendant) - synoboot.vmdk en SATA0:0 - <Nom du NAS>.vmdk en SCSI0:0 - Démarrage de la VM. Là pour chopper la bonne option, une méthode imparable. j'indique à la VM de rentrer dans le BIOS au premier démarrage, ce qui me laisse le temps de lancer ma console, et de choisir l'option ESXi ! - là, nouveauté, il me demande soit de migrer, soit de repartir "from scratch". C'est un peu bizarre, d'habitude l'installation DSM se fait sans ce message un peu anxiogène ! - Installation ok - Je trouve mon NAS sur le réseau car il part en DHCP - Je me loggue, tout va bien. A noter que le NAS reste en DHCP (comme d'hab), il faut le repasser en IP fixe et faire la mise à jour vers l'update 2 qui se déroule très bien. Pour info, j'ai pris pour habitude de télécharger manuellement mes DSM en local, de les contrôler le hash via "md5". Merci à tous pour le temps passé avec moi ! Allez, une dernière question si j'osais...c'est pour le bien de la communauté Pensez vous que mon premier crash était dû au mauvais choix d'option lors de la séquence de boot de la VM ? Et donc les problèmes suivants à une altération du synoboot.vmdk ?
  4. Merci à @fireman013 et à @nicoueron ! J'ai du mal à vous suivre. Voici ce que j'ai actuellement en "prod" (fichiers les plus importants à mon sens) - ds3615.vmx : config de la VM avec un lien vers les deux disques VMDK - <Nom du NAS>.vmdk : DD virtuel qui contient le DSM + toutes mes données ( en Contrôleur SCSI 0:0) - synoboot.img : loader précédent (en 6.0.2) - synoboot.vmdk : DD virtuel pour "émuler le sybno" ( en Contrôleur SATA 0:0) Donc j'ai bien deux virtuals disk : un contenant le synoboot et l'autre DSM+mes données et malgré tout l'erreur... A l'époque, l'ancien loader (celui de la 6.0.2) contenait plusieurs fichiers (ds3615.vmx, synoboot.img et synoboot.vmdk). Donc j'avais tout remplacé, plus rallumer ma VM et fait mes mise à jour. Maintenant, le dernier loader (Jun 1.02b) ne contient qu'un fichier : synoboot.img. Si je ne remplace que celui là j'ai mon erreur de formatage. J'ai lu aussi sur le forum qu'il fallait Donc ok, mais celui signifie quoi exactement ?. @fireman013 , c'est ce que tu sous-entends avec ça ? => Au fait, il y a l'équivalent pour MAC OS X ? Si je le fais, je vais avoir un nouveau fichier synoboot.vmdk. Je vais devoir mettre les deux dans ce cas, c'est à dire : - le synoboot.img, celui de Jun 1.0.2b - synoboot.vmdk, donc le même synoboot.img converti avec Starwind V2V Je ne sais pas si j'ai été clair Merci !
  5. Hello Comment as tu procédé STP ? J'ai la même erreur que toi. Par contre, je suis sur un NAS en version 6.0.2. Le problème est que dans le nouveau loader de Jun, il n'y a que le fichier "synoboot.img". J'ai essayé deux manipulations ... sans succès - Eteindre VM - remplacer mon ancien synoboot.img par celui se trouvant dans le loader 1.02b - redémarrage - et là lors de l'installation, le message "echec de formatage disque 35" Donc j'ai procédé à la deuxième manipulation - Eteindre VM - remplacer mon ancien synoboot.img par celui se trouvant dans le loader 1.02b - remplacer mon ancien synoboot.vmdk par celui se trouvant dans le loader 1.02a (car dans le répertoire du 1.02b), il n'y est pas. - redémarrage - et là encore la même erreur... Quelqu'un pourrait-il m'aider ? Pour info je suis sous ESXi6.5 avec un HP Gen8, et donc un proc. Intel. Pas de panique, car tous mes essais sont sur des VM de test. Pour le moment, je n'ai pas migré mon Syno de Prod ! Merci à vous.
  6. Merci pour cette réponse. J'attends donc avec impatiente le retour d'experts étant sous ESXi... Apparemment @topaze ne l'est pas...je me trompe ? Encore merci pour votre travail qui me facilite la vie au quotidien : 3 DSM installés sur mon ESXi le tout dans 3 VRF sur mon LAN avec 3 niveau de sécurité. Du bonheur
  7. Bonsoir Je suis en DSM 6.0.2-8451 Update 9. Je tourne sous ESXi 6.5, j'ai donc les fichiers suivants : - synoboot.img - synoboot.vmdk - MON-NAS.vmdk En parallèle, j'ai téléchargé : - le fichier PAT en 6.1.3 (15152) - l'update 3 - le loader 1.02b Je ne comprends pas trop bien la manip avec grub.cfg... Pour info, j'ai un MAC et donc impossible de trouver le client OSFMount. Ne puis-je pas faire la manipulation suivante : - arrêt de la VM - suppression de l'ancien synoboot.vmdk - copier dans le même répertoire le nouveau loader de Jun 1.02b (donc un seul fichier synoboot.vmdk) - redémarrage de la VM - Mise en prod de la version 6.1.3 - update direct vers l'update 3 Qu'en pensez vous ? Quelques questions : - peut-on monter en update 3 directement dès la fin de la mise à jour en 6.1.3 ? (en plus j'ai lu que l'update 2 était déconseillé) - peut-on mettre en update 4, dans ce cas peut-on le faire directement dès la fin de la mise en prod en 6.1.3 où doit-on passer en U3 avant. Merci à vous ! Bonne soirée.
  8. Je n 'ai pas de réponse officielle mais c'est peut-être possible que Synology ai implémenté cela par de faut lors d'une migration de version majeure afin que le NAS reste joignable sur le réseau - ou alors c'est un bug de DSM! Merci beaucoup nicoueron ! Tes réponses sont très claires. Bonne soirée
  9. Bonjour Juste un petit up pour ce post Merci à la communauté.
  10. Sur les serveurs de Synology: https://usdl.synology.com/download/DSM/criticalupdate/update_pack/8451-9/synology_bromolow_3615xs.pat NE PAS METTRE A JOUR A DSM 6.1 Super merci beaucoup pour cette réponse rapide. En fait j'allais dans release et non critical update. C'est noté !
  11. Bonsoir Savez vous où l'on peut télécharger la version DSM 6.0.2 update 9 ? J'ai réussi à avoir l'update 8 sur le forum mais c'est tout. Je suis en U8 sur une de mes VMs (les autres ont été mises à jour avant la sortie de la 6.1 et sont en U9), et maintenant il me propose la 6.1 dans la mise à jour système. Merci à vous.
  12. Bonjour Tout d'abord, je souhaiterais tous vous remercier pour vos échanges. Il m'ont permis de migrer avec succès de la DSM 5.2 au DSM 6.0.2 update 9. Bon toujours un petit souci au passage de U8 à U9, il a fallu faire un arrêt forcé de la VM (arrêt élec.) car cette dernière est restée bloquée à la fin de la mise à jour. Depuis tout fonctionne correctement. Maintenant, je me pose quelques questions de compréhension générale (j'aime bien comprendre ce que je fais et pourquoi ça fonctionne ) J'avais une VM NAS qui tournait à merveille en 5.2 dans un autre répertoire (que je nommerais A pour la compréhension) J'ai donc créé un nouveau répertoire (que je nommerais B) ,en suivant toute la procédure de terzo13 - merci à lui ! - et j'ai copié les trois fichiers "ds3516.vmx, synoboot.img et synoboot.vmdk" (avec au passage une petite modif. du ds3615.vmx) Puis j'ai ajouté un nouveau disque scsi0:0 qui pointe vers le fichier NAS.vmdk qui est resté dans le répertoire A. Ensuite lorsque j'ai démarré, j'ai dû terminer avec l'assistant Syno. J'ai récupéré au final la conf de mon syno et mes documents. Plusieurs questions : - Je suppose que mes documents sont dans le fichier NAS.vmdk. Dans ce cas, si la conf du syno est dans le même fichier, comment se fait-il que le syno effectue son premier démarrage (après la migration en DSM 6.0) en DHCP, et qu'ensuite la configuration réseau (adressage statique dans mon cas) a disparu ? Il a fallu que je lui remette son IP d'origine. - Que contient dans ce cas le fichier synoboot.vmdk ? Quand j'ai mis à jour vers l'update 9, la dernière version du DSM est-elle dans synoboot.vmdk ou dans NAS.vmdk ? - Dans ce cas, on aurait => synoboot.vmdk qui contiendrait l'OS à proprement parlé (DSM) + la conf. réseau => NAS.vmdk contiendrait la configuration du syno (base de comptes, dossiers partagés et droits, services activés : SSH, FTP, SMB, ...) et mes documents. Est ce exact ? Si tel est le cas, comme j'ai deux autres VM à monter de version, pourrais-je copier le fichier synoboot.vmdk à jour (update 9) à la place de Jun 1.01 et le mettre (avec en plus ds3516.vmx, synoboot.img) avec mes autres fichiers vmdk ? (NAS1.vmdk et NAS2.vmdk) dans leur répertoire spécifique ? Avec ce sytème je ne risque donc jamais de perdre mes données. au pire je remappe mon DD NAS.vmdk sur mon ancienne VM en version 5.2 (dans le répertoire A) et je repars avec un syno fonctionnel en 5.2. Désolé du post assez long, mais c'est très intéressant. Bonne journée.
  13. Bonsoir j'ai téléchargé le XPEnoboot 5.2-5592 pour VM. J'ai pris comme d'hab le fichier sous VMDK. D'habitude il s'agit d'un ZIP (ex. pour la 5565) avec deux fichiers distincts à ajouter séquentiellement dans ESXi (XXX-flat.vmdk et XXX.vmdk). Dans le cas de la 5592, seul un fichier est présent le XXX.vmdk. Peut-on en conclure que cela suffit ? Merci pour vos retours !
  14. Bonsoir Quelques news. je viens d'acheter les deux DD 2To WD Red. Pour la RAM, je galère un peu. On dirait que la KTH-PL316E/4G n'est plus disponible. Apparemment la KTH-PL316ES/4G est compatible. je vais tenter...croisons les doigts
  15. Bonjour à tous amis du forum ! Je serais bientôt un des vôtres, mon G8 devrait arriver sous peu. Je vais commander en plus un mini clé USB, 2x4 Go de RAM (KTH-PL316E/4G) et deux disques de 2To Western Digital Red (WD20EFRX) Normalement avec tout ce que j'ai lu cela devrait être compatible. La configuration que j'envisage, à base de VM sur un ESXi6.0 - Un "Syno" pour mes DATA dans une VRF sans aucune connexion à Internet, sans route par défaut exactement (Bon j'ai aussi un routeur qui va bien - Un "Syno" pour le multimédia - Un "Linux" pour héberger certains services du type : serveur SYSLOG, DNS, .... - Une VM "Windows", ça peut servir du fait que je suis sous Mac - Toujours arrêtée sauf besoin. - une VM "Syno" vide, juste pour tester des uprade avant de passer "en production" ! - Là encore toujours arrêtée sauf besoin. J'ai téléchargé les soft suivants : - XPEnoboot_DS3615xs_5.1-5022.3.vmdk - XPEnoboot_DS3615xs_5.1-5022.3-flat.vmdk - DSM_DS3615xs_5022.pat Pour info, j'ai eu l'occasion de tester cette configuration sur un ESX déjà installé, tout fonctionne. J'ai même pu upgrader en version 4. Par contre, pour que je comprenne bien : Une version de XPEnoboot correspond à un train principal de version côté Syno. Ici la version de DSM 5.1. Donc la même version de XPEnoboot, servira pour la DSM 5.1 et toute les upgrades suivants. Le passage en DSM 5.2, nécessitera un nouvel XPEnoboot. Dans le cas d'une utilisation sous ESX, il faudra que je boot la VM sur le nouveau fichier XPEnoboot_DS3615xs_5.x-zzzz.t.iso, puis que je sélectionne install/upgrade. Et c'est là que je m'y perds.... Il va donc modifier le boot de la VM avec la MAJ ? j'ai remarqué que dans une VM il y a avait deux volumes qui étaient créés. Un qui contient le bootloader et un autre DSM. Est ce exact ? Dernière question : ceux qui ont un Syno sur une VM dans ESX, ont ils réussi à monter les ports USB ? Si oui, comment ont-ils procédé ? Ca peut être pratique, car sur mon NAS actuel (WD Mybook world), dès que je mets un DD USB, ce dernier le monte automatiquement et je peux l'atteindre depuis mon poste de travail. Autrement si il y en qui ont besoin de conseils en réseau, je suis votre homme ! Chacun son métier Merci PI : après discussion avec des admins serveurs dans ma boutique, il s'avère qu'il vaut mieux faire "porter" le RAID par la carte embarquée du G8, et donc présenter qu'un volume à l'ESX, plutôt que de faire cela via le Syno. Vous, de votre côté qu'en pensez vous ? A+
×
×
  • Create New...