JacquesF

Members
  • Content Count

    177
  • Joined

  • Last visited

  • Days Won

    3

JacquesF last won the day on March 17

JacquesF had the most liked content!

Community Reputation

11 Good

About JacquesF

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Bonjour, Typiquement cela ressemble à un problème réseau. Plusieurs possibilités (en vrac) : - Carte réseau désactivée dans le bios - Connecteur HS (le voyant doit s'allumer à la connexion du câble au switch, autant côté PC que côté switch) - Echec de l'auto-négociation du débit par la carte vers le switch, dans ce cas tenter de forcer le débit au niveau du switch (ou de la box) - Chipset réseau différent entre le matériel décrit dans le post indiqué et le tien (le début de l'adresse MAC (en principe visible sur la carte mère ou le chassis) permet de trouver le fabricant) - Mauvaise adresse MAC dans le fichier de configuration de la clef USB, mais en principe ça ne joue pas pour la détection du NAS au premier démarrage sauf erreur de ma part Sinon, tenter le coup avec une carte réseau supplémentaire si possible. Bon courage Jacques
  2. Ceci dit, tu peux ajouter une partie du disque de 2 To pour le DSM et utiliser le reste pour une autre VM. Dans ce cas, le plus simple est de créer un datastore sur ce disque, et ensuite de créer des disques virtuels pour tes VM en les plaçant sur ce DS. Inconvénient : aucune sécurisation par du raid, donc à réserver à des machines pouvant être reconfigurées from scratch rapidement ou des données redondantes. Jacques
  3. Bonjour Sabrina, Comme indiqué dans mon post, je parle de ESXi. Ensuite, une fois le DSM installé, tu fais ce que tu veux de ton NAS, avec ou sans docker. Si une seule machine virtuelle (VM) est installée sur l'hyperviseur (ESXi), dans ce cas l'intérêt est de s'affranchir de la couche matérielle du serveur (sous réserve de compatibilité avec ESXi) et d'être à peu près certain que le prochain loader sera compatible avec le matériel utilisé dans la VM. Si on veut faire tourner d'autres OS en plus de DSM, il faut prévoir les ressources en RAM et en processeurs suffisantes pour les différentes VM. La virtualisation est un vrai métier, mais faire tourner 3 u 4 VM sur un ESXi reste relativement simple. Jacques
  4. Je trouve tout de même dommage que les cartes internes de ce serveur (extrêmement courant à priori dans les configurations trouvées ici) ne soient pas systématiquement incluses avec le loader. Dans mon cas, le slot d'extension est utilisé pour une carte SATA donc je ne peux pas migrer vers une version 6.2 Jacques
  5. Bonjour, L'utilisation de ESXi permet essentiellement de faire tourner plusieurs VM sur le même serveur, mais offre aussi la possibilité d'avoir une compatibilité relativement plus stable qu'avec le serveur tout seul. En principe, si on installe la VM avec DSM comme recommandé, seul le boot est sur un disque virtuel dédié. Toutes les données (et le DSM) sont placées sur les disques durs qui sont accédés via RDM, donc directement comme un disque connecté physiquement. Résultat, avec ce type de configuration, les données sont récupérables de la même façon qu'avec une installation baremetal. Jacques
  6. Bonjour, Très bonne idée de mettre la procédure en français. Juste une petite correction sur le rôle des commandes 4 & 5 : La 4, c'est pour détruire les informations liées au RAID sur le disque (on efface le bloc de données où mdadm enregistre l'appartenance du disque au groupe raid). La 5, c'est effectivement pour ajouter le disque au groupe md2, ce qui entraîne sa reconstruction automatique. Jacques
  7. Bonsoir, En principe, en ligne de commande c'est possible d'arrêter l'ESXi, donc il est possible de le faire via la crontab. Et (là c'est juste une piste à creuser), étant donné que le DSM est programmé pour s'arrêter, pourquoi ne pas créer un script sur le DSM qui se connecte en SSH (via clefs) sur l'hyperviseur pour lancer un shutdown programmé via la commande at (at now +10 minutes par exemple , c'est de mémoire pour la syntaxe) et qui fait ensuite l'arrêt du DSM. De cette manière, quelque soit l'heure où on programme l'arrêt du DSM, on est certain que l'ESXi suivra. J'espère avoir été assez clair Jacques
  8. Bonjour, Il y a quelques années, quand je bossais encore..., j'avais imposé pour toutes les VM de mon labo le principe d'inclure l'adresse IP de la machine (sous la forme des 6 derniers chiffres de l'adresse au format XXX.XXX) dans la partie variable de l'adresse MAC. Il est tout à fait possible de forcer l'adresse MAC d'une machine, elle commence alors (si ma mémoire est bonne et que VMware n'a pas changé de plage) par 00:50:56:XX:XX:XX dans le fichier de configuration de la VM. Mettre ensuite à jour le fichier de grub du disque de boot pourrait se faire soit via un montage en loop sous linux (utilisation de mount et de sed pour corriger le fichier). Pour Windows, je sais pas si OFSmount permet de monter le disque en ligne de commande, auquel cas cela pourrait être la solution (sed existe sous windows, ou sinon VB ou PowerShell). Il serait peut-être aussi possible de faire cela sur l'ESXi en shell via SSH directement dans le fichier grub.cfg, mais les commandes linux sous ESXi sont un peu restreintes si je me souviens bien. Ce n'est pas idéal, mais ça pourrait être une piste à creuser. Jacques
  9. Bonjour, À moins que ce ne soit la cas par défaut, il faut autoriser le NAS à renvoyer les paquets d'une interface IP vers l'autre. Ceci se fait dans le pseudo fichier /proc/sys/net/ipv4/ip_forward. La valeur 0 interdit le routage, la 1 l'autorise. Pour le rendre permanent, il faut modifier la configuration par défaut via sysctl (et éventuellement un script pour forcer la valeur au redémarrage du NAS). Voir cette page pour plus de détail. Après, il faut comme le dit Nicoueron configurer les machines pour avoir ton PC sur le LAN avec comme passerelle le NAS (sur l'interface LAN) Et contrairement à ce que dit Marcos, ne pas mettre le NAS en DHCP, sinon son adresse risque de changer au reboot et en ce cas la passerelle ne serait plus la bonne sur ton PC. Jacques
  10. Bonjour, Je confirme tout à fait ce que dit Thouve, les serveurs les plus récents sont équipés en standard de 1 ou 2 slots SD pour enregistrer l'OS de virtualisation (en fait quasiment toujours ESXi en entreprise) sur la carte (raid ou pas avec le 2ème slot). ESXi n'écrit quasiment rien sur le disque, et à part les logs que dans ce cas on a tout intérêt à externaliser via un serveur Syslog. Si la carte est trop petite, on perd le bénéfice de la partition de crash pour l'analyse du problème mais rien n'empêche le fonctionnement de la virtualisation. En principe, les datastores sont sur des SAN externes pour permettre le déplacement des VM à chaud entre différents ESXi (partageant les mêmes espaces de stockage). Donc, il n'y a rien sur le serveur physique, à part les processeurs, la RAM et l'hyperviseur. En fait, le plus souvent, même les ESXi sont virtualisés (les "physiques" sont les ressources) et il est ainsi possible de déménager à chaud toute l'infrastructure. Jacques
  11. Bonjour, Juste une remarque qui me passe par la tête... Trafic entrant sur le PC ==> analyse possible par l'antivirus... et ça c'est lent. En le désactivant pour tester (après avoir fermé tout ce qui est navigation sur le web par sécurité), ce sera facile de voir si c'est lui qui est en cause. Ensuite, si c'est le cas, faudra trouver comment lui expliquer de ne pas scanner tous les fichiers qu(il voit passer. Ça vaut le coup d'être essayé je pense. A+ Jacques
  12. Pas obligatoirement des guillemets, on peut aussi utiliser le caractère d'échappement devant chaque espace (en principe le \ ) ce qui est le cas ici entre Aurore et 6.2 : /vmfs/volumes/datastore1/Aurore\ 6.2/Samsung500.vmdk Ceci dit, les espaces ne sont pas toujours bien gérés dans les OS, mais ça a quand même fait du progrès depuis que les américains pensaient que tous les pays se mettraient à l'anglais, UTF-32 / 16 / 8 a bien forcé tout le monde à traiter les caractères spécifiques. Jacques
  13. +1 Il est impératif que le switch gère le 802.3ad (LACP) pour bénéficier d'une bande passante agrégée, sinon c'est de l'équilibrage de charge ou de la redondance. De plus, il faut aussi tenir compte des clients du NAS, si un seul client se connecte à la fois (ou quasiment à chaque fois), disposer de 4Gb en départ du NAS ne servira vraiment que si le client en dispose d'au moins 2 ports 1Gb ou plus connectés en LACP aussi, sinon aucun intérêt. En conséquence, investir dans un switch capable de LACP n'est utile qu'en cas de clients simultanés, ou si on possède soi-même plusieurs ports sur sa machine. Si c'est pour se connecter en WiFi au NAS, autant économiser son argent et le placer dans des disques supplémentaires à mon avis. Jacques
  14. Et si en créant tout simplement un nouveau compte depuis la version 6.1 et en essayant de se connecter avec ? Tu peux aussi modifier facilement ton adresse IP sur ton PC, ça permettra de vérifier l'hypothèse plutôt que rechercher un fichier dont l'existence est incertaine. Jacques
  15. - Outcome of the installation/update: SUCCESSFUL - DSM version prior update: DSM 6.1.7-15284 u2 - Loader version and model: JUN'S LOADER v1.02b - DS3615xs - Using custom extra.lzma: YES - Installation type: BAREMETAL - Microserver Gen8 - Additional comments: Need Reboot