JacquesF

Bonjour, Pas d'expérience du HA en Synology, mais vérifie peut-être le second réseau. Les 2850 sont équipés en Gb, donc un câble droit suffit pour établir une liaison entre les 2 interfaces (pour du 10/100Mo, il faut un câble croisé). Toutefois, le câble doit être complet, avoir les 8 fils de câblés donc. Vérifie la connexion par un ping via la console entre chaque serveur, étant donné que tu n'as pas d'autres machines sur le réseau. Bons tests Jacques

Bonsoir, Si je comprends bien, ton NAS est dans une machine virtuelle (VirtualBox). Dans ce cas, ce n'est pas la peine d'essayer de modifier le matériel avec un utilitaire pour flasher le bios "physique" d'un PC. Dans VirtualBox, il faut aller dans les paramètres de la VM (via l'interface), cliquer sur la partie Réseau, choisir la carte 1 (par défaut), vérifier qu'elle est activée (case cochée), puis cliquer sur le lien "Avancé". On accès à la configuration de la carte, et on peut saisir une adresse MAC. Je ne crois pas qu'Oracle interdise de mettre une adresse dans uen autre plage que 08:00:27:xx:xx:xx, contrairement à VmWare (00:0c:29 ou 00:50:56). Mets l'adresse que tu veux, mais pas surtout pas uneadresse existante sur le réseau local. Jacques

Bonsoir, Personnellement, j'ai eu un problème de mise à jour sur cette même machine en bootant avec la clef USB 5.2 et en choisissant Update dans le menu. Rien d'autre qu'une proposition d'installation avec l'assistant. Un démarrage en mode normal, avec la clef 5.2 et une version 5.1, puis la mise à jour dans l'interface a réglé le problème. Mais le réseau fonctionnait correctement. Si tu n'as plus de connexion réseau, regarde si le bios active bien les deux interfaces, si tu es bien branché sur la prise 1 (eth0) éventuellement. Autrement, les disques ne sont en principe pas touchés, donc une nouvelle installation devrait régler le problème. Si tout est OK, une sauvegarde de cette configuration de base, puis tenter de restaurer l'ancienne configuration et redémarrer. Si le reboot reste bloqué, un Arrêt/Marche règle le problème en général. Pas trop d'expérience sur le produit, mais avec une sauvegarde, je préfèrerais personnellement repartir de 0. Jacques

Bonsoir, Comment se fait le réveil du PC ? par le bios directement ? ou pas du WoL ? En principe, les paramètres de disques ne changement pas d'un mode à l'autre, et la pile ne sert à conserver que l'heure, les bios de ces machines sont plutôt sur la mémoire flash. Surle HP/Compaq, il y a souvent 2 versions de ROM, il est possible que les deux ne soient pas synchronisées, et que ce soit celle de secours qui soit utilisée en ce cas, avec une configuration par défaut. Il doit y avoir une option dans le bios pour recopier la configuration courante dans l'autre si c'est le cas, au sinon dans les options de démarrage. En toute hypothèse, si c'est bien le cas, soit la configuration actuelle est incorrecte quelque part, soit effectivement la pile ne permet pas de maintenir l'horloge, et une erreur d'incohérence est détectée au boot, provoquant le basculement sur l'autre ROM. Pas d'autre idée pour le moment. Jacques

Bonjour, Non, pas tout perdu, photo était visible dans le gestionnaire de fichiers du DSM, par contre tous les disques étaient visibles en console (via fdisk -l). Comme rien n'avait été formaté, je ne me suis pas vraiment inquiété Je ne me souviens plus si on voyait les volumes dans le gestionnaire de disques, je ne crois pas en effet. Après la mise à niveau via l'interface du DSM (boot en mode standard sur l'image via la clef USB, idem si c'est sur une ISO pour une VM), choix de la mise à niveau du DSM dans l'interface et un reboot, tout était OK. Même pas eu besoin de restaurer la configuration. Ensuite, mise à jour du patch 1, blocage au redémarrage (à première vue erreur fréquente vus les posts), nouveau redémarrage, depuis tout est OK. Pas encore mis le patch 2 via l'interface, mais ça ne devrait pas trop tarder. Jacques

Bonsoir, Depuis une fenêtre DOS sous Windows 7 (Démarrer, exécuter, ou Menu démarrer, accessoires), ou une console linux (en root) faire : ping @IP du nas arp -a @IP du nas L'adresse MAC est retournée avec une séparation des 6 octets par des - sous Window, des : sous linux. Sinon, avec un accès en root sur le NAS (via SSH), la commande ifconfig -a retourne les données de toutes les interfaces, voir le champ hwaddr (en anglais) Jacques

Sous linux, et XPenology donc, il est possible de fixer une adresse MAC à une carte au démarrage de celle-ci. Pour le bonding, c'est la même chose. De mémoire : ifconfig eth0 down ; ifconfig eth0 hwaddr 00:01:02:03:04:05 up Maintenant, pour le WOL, c'est bien de l'adresse réelle de la carte dont il s'agit, celle-ci n'étant pas gérée par l'OS à ce moment. Il existe des possibilités pour faire "passer" un paquet magique de mise en route via un routeur, mais cela dépend fortement des capacités du routeur (ou du modem donc) si on veut éveiller la machine depuis le vaste internet. Jacques

Ben oui... c'est plus un serveur qu'un NAS en effet. L'intérêt des VM, c'est bien sur les snapshot, même si cela peut vite mener à gaspiller de l'espace disque. De mémoire, il est aussi possible de faire un snapshot sur ext4, et sur LVM. Le raid SHR est un mélange de raid soft et de LVM, donc il doit être possible de réaliser des images du NAS en instantané, et de revenir en arrière... A tester avant bien sur. Jacques

Bonjour, Pour rajouter un peu, la virtualisation ne permet pas toujours d'accéder aux périphériques de la machine hôte... Le matériel présenté aux VM est souvent générique, certains systèmes permettent d'accéder directement à un périphérique (mode PCI pass-trough) mais cela dépend aussi de l'architecture de la machine hôte. Bref, utiliser un NAS pour héberger les "disques" des VM, c'est prévu pour on dira, mais virtualiser les applications d'un NAS qui accédera aux disques de ses VM (si j'ai bien compris les disques seront sur l'autre NAS) en WiFi, c'est la garantie de performances médiocres. La virtualisation du type VmWare, c'est conçu pour un environnement professionnel. Virtualbox est plus léger, mais si les accès disques sont via le réseau, la qualité de celui-ci est primordiale. Jacques

Bonsoir Pour ESXi, il faut disposer de 2 ressources pour pouvoir installer ensuite des VM : 1) Un disque de démarrage pour l'OS (clef USB, target iSCSI, carte SD, etc...) 2) Un espace de stockage (datastore) pour enregistrer la configuration des VM Selon la taille du disque où l'OS est installé, le datastore est créé dessus ou non. J'avais fait l'essai avec une micro-SD de 16Go je crois, et aucun datastore n'avais été créé. Résultat, il faut disposer d'un autre disque dur pour stocker la configuration des VM, configuration qui ne prendra qu'une place très réduite. En principe (à moins de jouer avec les snapschots), une VM XPenology (qu'on me corrige si je dis une bêtise) est constituée du fichier .vmx qui décrit la machine, du fichier .vmdk qui décrit le disque dur (ou les disques durs, disques qu'on utilise en mode RAW access, c'est à dire que le fichier ne contiendra que le chemin vers les disques physiques dédiés au NAS) et les quelques fichiers pour le bios, l'état de la mémoire et les logs de la VM. Tout ceci ne prend qu'une place très réduite et peut facilement être archivé sur un autre support (machine à l'arrêt), il suffit de copier le répertoire associé à la VM depuis le datastore vers le disque du PC utilisant le client vSphere. Seule la VM est à réinstaller en cas de perte du datastore, les disques durs en mode RAW contenant le raid et supportant en fait aussi le NAS. Il est même possible de réinstaller le NAs en conservant ces disques, puisque c'est ce que fait la VM, elle ne fait qu'accéder aux disques physiques directement. Pour le démarrage, il faut effectivement activer l'ISO de boot en permanence dans le lecteur de CD virtuel, et modifier le bios de la VM pour que celle-ci démarre sur le CD en priorité. J'espère que ce sera un peu plus clair ainsi. Jacques

Bonjour, Je suppose, vu le forum, qu'il s'agit d'un NAS sur un serveur autre qu'en provenance de Synology. Pour éteindre le NAS, c'est l'OS qui est configuré pour faire un shutdown à une heure régulière. Pour le réveiller, il faut allumer le serveur, recevoir un paquet spécifique sur le réseau (WOL), ou configurer le bios pour le faire. L'accès au bios d'un serveur de Synology par leur OS est prévu (via l'interface justement), mais leur demander de paramétrer spécifiquement cette option dans le bios d'une machine inconnue, c'est peut être pousser le bouchon un peu loin. Bref, pour allumer le serveur, l'interface ne sert à rien, il faut le mettre manuellement dans le bios du serveur, ou le mettre sous tension via le réseau, depuis une machine qui ne s'éteint pas, ou une box éventuellement si elle possède cette option. Jacques

Bonjour, Pas rencontré le problème, mais dans le bios des machines capables de jouer un rôle de serveur, il y a souvent une option du style "source d'amorçage". C'est ici qu'il faut préciser si on veut que le redémarrage se fasse via le disque dur, ou un autre périphérique, dans ce cas une clef USB. C'est peut-être un peu caché, mais c'est souvent regroupé avec les options de boot. Jacques

Bonsoir, Je ne peux pas répondre clairement à ta question, mais dans l'image de la 4.3.3827, il y a un fichier de boot pour des controleurs SCSI ou SAS (synoboot-3827-pre-v1.1_v8_hba.img). Cela semblerait aller dans le sens d'une image modifiée pour gérer un bon nombre de disques. Jacques PS : Si tu sais comment identifier une configuration modifiée (présence d'un fichier sur le NAS par exemple), il est assez facile d'explorer l'archive (le fichier .pat est en fait une archive TAR, on peut donc l'ouvrir facilement et naviguer à l'intérieur) pour regarder si c'est présent.

En principe, le boot d'une VM se fait via une ISO. Il faut modifier le bios de la VM pour forcer le démarrage sur l'ISO en premier, sinon c'est le disque dur qui est utilisé. Comme logiquement on installe le DSM sur une partie du raid des disques utilisés en accès direct (RAW access dans la configuration Vmware), il n'y a pas de démarrage sur XPenoboot. Pas de Vcenter sous la main pour regarder la configuration, mais il faut aller dans les propriétés de la VM, choisir l'onglet Avancé (ou un libellé approchant) et cocher la case : Forcer l'accès au bios au prochain démarrage, ou quelque chose du même style. Ensuite, mettre le CD en premier dans l'ordre de démarrage (sachant que l'image ISO doit être accessible pour la VM et qu'il ne faut pas oublier de cocher les cases concernant le CD virtuel (actif au démarrage et l'autre dont je ne me souviens plus). Jacques

Bonsoir, Idem pour le HP 1610GT, la micro-sd est vue comme un boot USB (ce doit d'ailleurs être le chipset USB qui présente la carte au bios). Pas testé à l'époque avec Xpenoboot, mais avec ESXi, aucun soucis, choix des priorités avec USB en premier et démarrage sur la carte. Seul inconvénient pour Xpenoboot, les micro-SD ne sont pas verrouillables en écriture (les SD si en revanche). Jacques

Bonjour, Pour faire de l'aggrégat en 802.3ad, il faut un switch manageable capable de le faire lui aussi. Ce n'est pas possible sur un switch basique, la seule configuration dans ce cas est le mode actif/veille (en 5.1), et en 5.2 si on va dans les paramètres de l'interface bond0, on dispose aussi du mode Load balancing. Tout ce qui est 802.3ad nécessite de la configuration sur les ports du switch (soit en dynamique via LACP, soit en statique pour la balance XOR). Bonne soirée Jacques

Bonjour, Merci de la réponse, c'est effectivement ce que j'ai fait, comme indiqué dans la seconde partie du message. Il y a une incohérence dans la détectin des disques dans le menu upgrade, mais si on démarre directement avec le boot DSM 5.2, le NAS peut être mis à jour sans soucis via l'interface web (sans l'assistant donc). Seul soucis avant la mise à jour, le FileStation ne montrait plus que le répertoire photo... plus les autres. Mais c'est juste un soucis d'interfac, les données ne sont pas perdues et reviennent après la mise à jour manuelle. Ma question était plutôt : Est-ce un problème connu, et si non comment le remonter. Bonne soirée Jacques

Bonjour, Je débute dans XPenology, mais pas dans linux et le réseau. J'ai un NAS installé via cet execellent outil sur un Proliant Gen8 G1610t avec la version DSM 5.1 update 5 (5.1-5022 u5). J'ai suivi le tuto de mise à jour décrit ici et mis à niveau ma clef USB avec la version 5.2 de Xpenoboot. Démarrage du NAS sur la clef (comme d'habitude), choix de l'option Install/Upgrade. Recherche du NAS avec l'assistant, l'adresse IP proposée était fausse (adresse APIPA sur échec DHCP), mais le NAS était bien joignable sur son adresse IP habituelle. Remplacement de l'adresse fournie par l'assistant dans l'URL par celle du NAS et connexion à la page d'installation (page web_index.html sur le port 5000). Là, au lieu d'avoir la possibilité de faire un upgrade, je ne peux que jaire une nouvelle installation avec comme raison le message suivant (avec les fautes d'origine) : "Nous avons détecté que les disques durs de votre DS3615xs actuel a été supprimée à partir d'un précédent DS3615xs et l'installation d'un tout nouveau DSM est demandée avant de continuer." J'ai annulé l'installation, et en suivant une autre procédure trouvée sur le forum, j'ai démarré le NAS normalement sur la clef USB de la version 5.2, fait la mise à jour manuellement en fournissant le fichier .pat de la 5.2 via l'interface Synology , le NAS a redémarré, tout était OK. La mise à jour en 5.2u1 s'est faite via l'interface, échec du redémarrage initial, marche/arrêt du serveur et tout est à jour maintenant. Si quelqu'un connait la cause de l'échec de la procédure de mise à niveau, je suis intéressé. De même, s'il s'agit d'un bug, merci de m'indiquer comment en informer les développeurs. Comme piste possible pour la "détection" du changement de NAS, le serveur a été renommé après installation des disques et création des volumes et du raid (type SHR). Par expérience, certains outils de création des partitions RAID soft indique dans le label des partition le nom de la machine suivi du numéro du périphérique "md". Le nom par défaut (à la création du raid) était donc DiskStation. Il est possible que cette information soit inscrite dans les disques, mais la commande blkid n'est pas disponible sur le NAS. Si c'est la cause du problème, il est possible que l'installation ne détruise pas les disques... mais je n'ai pas voulu réessayer Si c'est un bug de la clef Xpenoboot, cela vaudrait le coup de le corriger, ou de mettre un avertissement avec la procédure à suivre. Si c'est une restriction, autant l'indiquer dans le tutoriel. S'il n'y a pas d'autre solution que la mise à jour via l'interface en démarrant sur la clef comme je l'ai fait, eh bien les infos données ici permettront peut-être à certains de s'en sortir sans casse. Merci encore pour le travail réalisé. Jacques