JacquesF

Bonjour, Dommage... peut-être vérifier dans la ligne de commande (via un ps et je ne sais plus si l'option -w passe avec busybox, j'en doute) auels paramètres sont utilisés lors du téléchargement, si c'est visible. Autrement dans /proc/PIDduProgramme on peut trouver la ligne de commande. Bons tests Jacques

Bonjour, Un paramètre qui peut être intéressant dans le man de lftp (et qui doit pouvoir se fixer dans un fichier de config) : ftp:ssl-protect-data (boolean) if true, request SSL connection for data transfers. This provides privacy and trans‐ mission error correction. Was cpu-intensive on old CPUs. Default is true. Si le téléchargement est en https (la quasi totalité des serveurs le sont), ça pourrait expliquer le délai et la charge CPU. Bons tests Jacques

Bonjour, Je n'ai pas d'idée où trouver les informations sur ce fichier, peut-être la partie consacrée aux développeurs sur le site de Synology. En revanche, pour éviter de réinstaller en cas de blocage, il est préférable d'utiliser une VM et de prendre un snapshot de l'installation avant les tests. En cas, de problème, on restaure le snapshot et on retrouve la configuration d'origine. Jacques

Bonjour, Déjà indiquée à plusieurs reprises sur ce forum, ainsi que dans l'aide sur le site Synology, la méthode pour accéder aux données d'un volume RAID (SHR ouo non) passe par le boot d'un linux live (CD/USB). À partir des indications données, il est possible de transposer les commandes pour monter les volumes raid (et LVM). Les partitions 1 et 2 correspondent probablement à celle du DSM et au swap (respectivement). La taille de la partition 3 semble incorrecte pour un volume venant du NAS, ou le disque a été repartitionné. Si c'est le cas, sous linux les données ne sont pas perdues mais cela commence à être un peu plus complexe à récupérer. Un outil comme photorec peut aider à retrouver le partitionnement d'origine, Partition Magic ou un outil similaire aussi probablement. Jacques

Bonjour, Le extra.lzma doit être placé dans la deuxième partition de la clef, celle où ne se trouve pas justement le grub. Il suffit juste qu'il soit présent pour qu'il soit chargé par le loader. Si un fichier existe déjà, le renommer suffira pour le désactiver ex : extra.lzma.jun.unused Bons tests Jacques

Oui ce sont dans ces dossiers que la configuration est rangée (si le développeur ne prend pas des libertés). Ensuite, tu peux naviguer dans chaque dossier correspondant à une appli pour voir s'il n'y a pas des liens pointant vers un autre emplacement (SFTP est pratique pour ça). Pour conserver les droits des fichiers, le mieux est de faire un tar du dossier à sauvegarder (de mémoire, WinSWP le permet par un clic droit sur un dossier). Une archive ZIP ne contiendra pas les permissions associées. Bonne sauvegarde. Jacques

La plupart des options de configurations des applications se trouvent dans le dossier de l'application et éventuellement le dossier avec un @ devant. Ceci sous-entend que si on réinstalle les applications, il faut les placer dans le même volume, à moins de rechercher les paramètres dans les fichiers de configuration (un "grep -R "chemin/vers/appli" *" lancé depuis le dossier de l'application devrait permettre de trouver les fichiers concernés). Mais HyperBackup pourra aider ensuite s'il devait y avoir une prochaine fois. Jacques

Bonjour, Pour moi : Option 1 : je ne le ferai pas, écrire sur un volume instable ne fait qu'augmenter le risque de détruire des données ou de perdre un disque lors de l'opération. Option 2 : d'après les logs de mon Xpenology (en 6.2), la détection du raid est automatique, donc le nom des disques n'entre pas réellement en ligne de compte. À moins qu'un contrôleur puisse être défectueux sur la carte mère ou la carte SATA, ce qui est douteux puisqu'un changement pour réparer semble avoir été fait, cela ne changera rien dans les faits pour moi. Option 3 : je doute que cela change grand chose, si le DSM a réussi à remonter le volume, c'est que les informations de configuration des disques sont accessibles, donc utiliser un autre OS ne changera probablement pas grand chose. Ce genre d'opération est plutôt prévue lorsque DSM (ou la machine) ne démarre plus du tout. Je me répète (pour le point 1), mais ma procédure personnelle serait : 1) sauvegarder tout ce qui peut l'être 2) lancer un test étendu de chaque disque avec SMART (au besoin via le panneau de contrôle du DSM) 3) remplacer le ou les disques trouvés douteux par SMART 4) selon la configuration du ou des disques changés, laisser le raid se réparer ou si ce n'est pas possible, réinstaller le tout, recréer les volumes nécessaires et réinstaller les sauvegardes. Attention, le DSM ne présente pas tous les dossiers via SMB ou NFS (entre autres ceux contenant la configuration des applications). S'il faut tout réinstaller, prendre la précaution avant de bien sauvegarder tous les dossiers utiles. Jacques

Bonsoir, Pas lu le post en anglais, mais dans ton message, tu indiques qu'un de tes disques est reparti en réparation. Il est donc manquant dans la grappe raid, et dans ce cas la perte de n'importe lequel de tes autres disques entraînera la perte définitive des données (à moins que ce soit un raid avec 2 disques de redondance, SHR2 ou Raid6). Donc, ce n'est pas maintenant qu'il faut jouer à réorganiser les disques. De plus, le raid étant logiciel, en principe si le nom des disques n'a pas changé (et même ainsi ça doit réussir à retrouver ces petits), le raid soft est capable de lire les étiquettes ajoutées en fin de disque pour retrouver les identifiants de chaque membre du ou des groupes raid. Donc, en ce moment, l'urgence est de sauvegarder les données sensibles, dans la mesure du possible par partage SMB ou NFS, ce sera plus rapide que le SFTP, mais si la connexion coupait souvent, c'est probablement parce que les accès disques doivent être difficiles. Ensuite, une fois les données à l'abri, réorganiser les disques, les remplacer, réinstaller, etc. sera possible et sans trop de risques. Jacques

Bonjour, Juste une idée qui vient : le firewall est-il ouvert pour la configuration de backup sur l'interface VPN ? Et de manière corollaire, le service de backup est-il à l'écoute sur l'interface VPN ? La plupart du temps, les applications non joignables par VPN rencontrent l'un, ou les deux, de ces problèmes. J.

Bonjour, Un simple script lançant wget avec une liste d'URL via une tache cron devrait faire l'affaire à mon avis. Pas besoin d'une application dédiée. Et si on programme un peu, perl ou python offrent de multiples méthodes pour extraire des données d'une page web. Jacques

Bonjour, Est-ce que le fichier grub.cfg de la clef USB a été modifié ? l'adresse MAC de la (ou des cartes) réseau est à indiquer dedans pour que le système démarre correctement. Si la clef est la même, c'est peut-être là que ça bloque... à vérifier. Jacques

Bonjour, Pas assez d'expérience en récupération de raid pour te conseiller une des méthodes. L'option --zero-superblock réinitialise le disque au point de vue de la grappe raid, ce qui fait qu'il est vu comme un nouveau disque, et donc vierge !!! La réponse de mdadm n'est pas encourageante, /dev/md/3 assembled from 11 drives - not enough to start the array Cela indique clairement qu'il manque un disque pour restaurer les données sur le disque vide. Dans ce contexte, la récupération des données me parait relever d'une structure spécialisée dans ce type d'opération, et ce n'est pas garanti que tout puisse être récupérer puisque les données de parités réparties sur les 13 disques manquent sur un. Pose la question sur un forum de développeurs mdadm, tu auras peut-être une autre piste, mais là je sèche. Jacques

Bonsoir, Vu le descriptif de la panne, ça ne sent pas trop bon pour la sécurité des données, il n'y a plus aucune marge de sécurité avec le disque remplacé et vide. SHR est une combinaison Raid soft et LVM par dessus, ce qui veut dire concrètement qu'il y a 2 niveaux d'abstraction concernant les données. Le premier niveau est le raid (commandes md*) qui permet d'assembler la matrice raid qui supporte le LVM ensuite. Le second niveau est la gestion des volumes logiques (LVM) qui permet de regrouper plusieurs matrices raid si besoin est (ce n'est pas le cas dans ta configuration, mais la couche LVM est présente). Une fois le raid assemblé, il faut remonter le volume (dans le lien donné avec la procédure de récupération c'est avec vgchange). Ton cas devrait correspondre à la colonne "SHR with single volume" dans le tableau de cette procédure. Dans ce cas, il faut recréer le volume et ensuite seulement le monter. Autrement, les données de peuvent pas être retrouvées pour déterminer le type de montage à faire. Comme indiqué dans la procédure, la commande lvs devrait permettre d'identifier les volumes à réassembler puis à monter. Je te donne un exemple de la sortie de ces commades sur mon NAS perso (5 disques de 4x4To et 1x1To, avec 1 volume SHR avec les 4x4To et un volume SHR sans redondance sur le disque de 1To). root@Maison:~# cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [raidF1] md2 : active raid5 sda5[0] sdd5[3] sdc5[2] sdb5[1] 11706562368 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] md3 : active raid1 sde3[0] 971940544 blocks super 1.2 [1/1] [U] md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3] sde2[4] 2097088 blocks [12/5] [UUUUU_______] md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4] 2490176 blocks [12/5] [UUUUU_______] unused devices: <none> root@Maison:~# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert syno_vg_reserved_area vg1 -wi-a----- 12.00m volume_1 vg1 -wi-ao---- 10.90t root@Maison:~# pvs PV VG Fmt Attr PSize PFree /dev/md2 vg1 lvm2 a-- 10.90t 0 root@Maison:~# vgs VG #PV #LV #SN Attr VSize VFree vg1 1 2 0 wz--n- 10.90t 0 root@Maison:~# mount -t ext4 -t btrfs /dev/md3 on /volume2 type btrfs (rw,relatime,synoacl,nospace_cache,metadata_ratio=50) /dev/mapper/vg1-volume_1 on /volume1 type btrfs (rw,relatime,synoacl,nospace_cache,metadata_ratio=50) md0 est le DSM, md1 le swap, md2 le volume 1 (via LVM) et md3 le volume 2 (sans redondance, donc accès direct sans LVM). Jacques

Bonjour, Sur le fait de créer 13 points de montage, j'ai des doutes... Il en faudra plutôt un par partitions existantes sur le groupe raid au final. Je ne sais pas s'il existe plusieurs groupes raid dans l'ensemble des 13 disques, mais (je prends la discussion en cours) il faut déjà savoir si c'est du raid SHR (ou SHR2) ou simplement du raid 5 ou 6. Dans le cas du SHR, on a besoin de LVM (les commandes vg*) pour recréer les volumes. Le scan des disques par mdadm est la meilleure chose à faire pour le moment, pour voir quelle est la structure du raid. La procédure donnée dans le lien me semble sans erreur (ce qu'on peut espérer de la part de Synology tout de même) mais je n'ai pas l'impression à lire le message qu'elle ait été suivie à l'exact (on parle de créer autant de point de montage que de volumes, pas de disque comme je le disais plus haut). Je pense que refaire cette procédure pas à pas est la chose à faire actuellement, ensuite si ça ne marche pas rechercher les volumes avec LVM (commandes vg*) puis le raid avec mdadm (md*). Dans le cas d'un démarrage impossible, seule la 1ere partition (premier ensemble raid en principe : md0) est à réparer, les données étant sur les autres groupes raid. Et, règle de base sur un crash disque, on prend son temps et on ne fait rien trop tard le soir, ou tôt dans la nuit, si on est pas totalement reposé... Jacques

Le raid SHR est une combinaison de raid logiciel (périphériques /dev/mdX) et de LVM (gestion de volumes logiques). Le LVM permet d'accroître dynamiquement la taille d'un disque (et optimise donc l'usage de ceux-ci en minimisant la place perdue) et le Raid permet d'assurer la redondance des données au niveau inférieur pour la sécurité. Donc ça ne pose aucun problème de fonctionnement, puisque DSM 6 le gère sans soucis, mais ça complique un peu l'accès aux données si le volume est réparti sur plusieurs disques. Pour pouvoir accéder aux données depuis un système externe, il faut monter le raid et éventuellement le volume (le DSM par exemple est éclaté en raid sur tous les disques mais n'utilise pas de LVM) pour accéder aux données (en principe en SHR, le LVM est systématique pour les volumes DATA créés avec de la redondance). Pour changer un paramètre (et donc modifier le contenu d'un fichier de configuration), il faut pouvoir accéder aux données du DSM, donc monter le raid (le premier trouvé en principe) en accédant depuis un autre système d'exploitation. Autre possibilité, installer un seul disque dans un PC capable de lire et écrire sur le système de fichiers utilisé pour le DSM (en principe ext4, ce qui implique un OS Linux ou un drivers spécifique sous Windows) et modifier les fichiers, puis n'utiliser que ce disque pour redémarrer le NAS (le volume de DATA passera en faute, mais si on ne formate rien lors de la réinstallation du DSM, on le retrouvera en remettant tous les disques une fois l'installation terminée et le DSM réparé. Dernière option possible que je vois, réinstaller tout le DSM et restaurer ensuite une sauvegarde de la configuration précédente (puis adapter les options qui ne sont pas sauvegardées et il peut y en avoir pas mal). Attends confirmation d'autres personnes sur ce forum pour la marche à suivre et tiens nous au courant de la méthode utilisée et du résultat. Jacques

Bonjour, En principe, si aucune action de formatage n'a été faite durant la migration, les données sont toujours accessibles et intactes au niveau disque. Maintenant, revenir à une version plus ancienne est un procédé déjà décrit dans le forum mais nécessite (de mémoire) de modifier la valeur de la version dans un fichier. On en revient à un accès au NAS. Je te conseille d'attendre la réponse d'autres personnes plus au fait que moi de ces procédures, mais pour récupérer un accès SSH (et modifier le fichier), il me parait possible de booter sur une clef contenant un Linux (SystemRescueCD est un outil que j'aime beaucoup car à peu près tout ce dont on peut avoir besoin dans ce genre de cas est directement présent au boot), de rechercher le raid et de le monter (voir le site de Synology pour la procédure de récupération des données). Pour le DSM, il est installé dans /dev/md0 ce qui dans le cas d'une réparation sera probablement /dev/md127 car le raid n'est pas configuré pour cette machine. Ensuite, réactiver le SSH devrait pouvoir se faire en éditant le fichier /etc.defaults/synoinfo.conf et modifier la valeur de supportssh à "yes". root@Maison:/etc.defaults# grep ssh /etc.defaults/synoinfo.conf supportssh="yes" Maintenant, reste le problème de l'authentification en espérant que les mots de passes sont restés intacts. Sinon, il faudra réitérer la procédure de boot pour installer des clefs de chiffrement permettant une authentification directe (et modifier le fichier /etc/ssh/sshd_config - et probablement aussi celui dans /etc.defaults/ssh - pour valider la connexion de root et les clefs). Pas d'autres pistes pour le moment, mais je ne peux que déconseiller les migrations à 2h du matin, pour avoir migré plus d'une centaine de système la nuit, il vaut mieux commencer plus tôt et se faire surveiller par quelqu'un passé une certaine heure... les erreurs sont trop faciles avec la fatigue. Jacques

Bonsoir, Pour l'édition du fichier, la procédure est donnée dans les tutos d'installation. Il faut monter la partition (me souviens plus de l'outil Windows, pas de soucis pour Linux utilisé pour mes machines) puis éditer le fichier (Wordpad à utiliser, ou PsPad, bref tout éditeur qui respecte le format de fin de ligne Linux). Jacques

Bonjour, ESXi est un système d'exploitation à part entière dédié à l'hyperviseur Vmware. Contrairement à des VM fonctionnant dans Docker ou une autre mécanisme de virtualisation, on gagne en performance et en stabilité puisqu'on ne transcrit pas les requêtes de la VM en commandes qui vont être transmises au système par DSM mais directement transcrite vers le système. De plus ESXi est un OS professionnel spécialement conçu pour de très grosses architectures de virtualisation, donc faire tourner 3 ou 4 VMs en local avec un usage perso ne va pas l'épuiser... (il est même possible de virtualiser ESXi ce qui permet de le déplacer d'un serveur physique à un autre dynamiquement, avec la licence qui va bien ainsi que l'architecture ad-hoc). Dans ton cas, il faudrait installer ESXi sur un disque, un SSD ou même une carte microSD (le boot sur SD est prévu sur un Gen8), puis créer un datastore. Selon le nombre et le type de VM à installer sur ESXi, il peut être sur un disque SSD, la carte SD (voir dans les 2 cas le tuto que j'ai fait) ou un disque dédié, ou encore un autre espace de stockage situé sur ton réseau local (Gb/s minimum). C'est principalement les performances en I/O de la VM vers les disques qui jouera pour déterminer le support à utiliser. Ensuite, une VM permettant de faire tourner le DSM (dans ce cas, le disque de boot n'est plus utilisé une fois DSM lancé, donc la VM peut être sur la carte SD) et rattacher les autres disques du Gen8 en tant que RDM pour avoir un accès direct depuis le DSM (performances maxi et compatibilité avec un Syno (baremetal ou un vrai) OK). Et Jeedom comme autre VM avec son espace de stockage sur le datastore que tu as choisi. Et d'autres VM possibles pour des tests ensuite. La quantité dépendra des performances (RAM, CPU, disque) de ton Gen8 et de leur usage simultané ou non. Jacques

Tout comme Nicoueron, je ne connaissais pas l'outil. J'ai lâché le monde Windows (à titre perso depuis plus de 15 ans, et professionnellement la majorité des serveurs sont sous Linux). Je partage entièrement son avis, soit virtualiser la machine de déploiement, qui ne fait de toute façon pas grand chose d'autres que du trafic réseau sauf erreur, soit transcrire le tout via un boot PXE sous Linux, mais il est vrai que dans ce cas, la personnalisation ne se fera pas à travers une interface graphique, mais via les fichiers de config si le chargement automatique n'a pas trop changé, ou sinon créer la personnalisation sur une machine Windows quelconque et positionner la configuration obtenue sur le serveur PXE ensuite. Ces liens peuvent peut-être t'aider : https://www.it-connect.fr/pxe-sur-linux-windows-et-pourquoi-pas-les-deux/ https://nbailey.ca/post/mdt-linux/ https://blog.ricosharp.com/posts/2019/Windows-deployment-with-Linux-Initial-Setup (ce dernier lien correspond à première vue à la solution que j'évoque en dernier lieu ci-dessus) Jacques

Tout à fait d'accord avec Nicoueron... Les évolutions importantes en v7 : https://www.mchelgham.com/vsphere-7-toutes-les-nouveautes/ En gros pas d'intérêt pour un usage personnel. Jacques

Forcer l'adresse au moment du boot, je ne crois pas que le loader offre une option pour ça. La forcer dans la configuration du DSM, c'est possible, mais pour ça la VM doit démarrer... Je pense que le mieux est d'arrêter cette VM et d'en recréer une autre depuis le fichier OVF de Nicoueron, en suivant pas à pas la procédure qui l'accompagne. Ensuite, au moment du premier démarrage, si l'ESXi pose une question demandant si la VM a été copiée ou déplacée, répondre que c'est un déplacement ce qui devrait éviter que l'adresse MAC soit modifiée (peu-être est-ce la cause ?). Autrement, on peut éditer le fichier de configuration de la VM pour vérifier que la MAC address est bien celle prévue à l'origine dans le modèle. Recréer une VM est simple, il n'est même pas nécessaire de lui affecter d'autre disque pour le moment que le fichier de boot puisque le test est d'arriver à lancer cette VM et qu'elle se connecte au réseau. Une fois ça en place, rajouter les disques durs en RDM se fera tranquillement. Bref, recommencer from scratch un nouveau déploiement du fichier OVF et contrôler à chaque étape la conformité avec le tutoriel est à mon avis le plus rapide. Jacques

La démarche est bonne, le serveur ESXi fonctionne correctement. Sauf erreur de ma part, même en absence de disque (il y a une règle pour connecter le disque synoboot sur le contrôleur Sata 0 je crois, et les disques de données sur le 1 mais je ne dis ça que de mémoire). Il y a le tuto de Nicoueron qui est très bien fait pour utiliser son modèle de VM et ce point y est précisé. Donc, à moins que le boot ne fonctionne pas du tout (et vérifier le checksum du fichier peut être une bonne chose (commande md5sum sur l'ESXi)) l'interface réseau e1000e est supportée par le loader. La suggestion que j'ai faite plus haut d'installer Wireshark sur une machine du réseau pour voir si les requêtes DHCP de la VM partaient bien est toujours valable. Si rien ne sort de la VM (donc de l'interface du serveur ESXi), alors c'est que la VM ne boote pas correctement. Les messages sont en principe bien dans le fichier serial.out, il est possible d'utiliser des pipes entre 2 VM pour tracer le démarrage d'une machine (chaque machine redirige son port série vers un pipe, l'une en mode maître et l'autre en mode esclave. Un programme comme Putty (ou minicom sous linux) permet de se connecter au port série sur la 2ème VM et de voir ce qui se passe sur le port de l'autre VM en direct, et même de répondre aux questions éventuelles. Il y a des exemples de configuration sur le site de Vmware dans la documentation, ou probablement des tutos sur le net. Mais avant de faire ça, je vérifierai l'état du serveur DHCP (au besoin reboot) et je jetterai un œil sur le réseau avec un analyseur. Jacques

Si la VM semble bien se connecter au switch, cela ne veut pas dire que la carte est en service au niveau du loader. De mémoire, il y a un 3 choix au boot, le dernier concerne la configuration ESXi, est-ce bien celui qui est activé ? Autrement, redémarrer le service DHCP est installer un sniffeur comme Wireshark sur un des PC du réseau. Il ne pourra pas suivre l'intégralité des échanges (le réseau d'une box est switché) mais les trames DHCP devraient être affichées. S'il n'y en a aucune avec l'adresse MAC de la VM, c'est que le loader ne gère pas la carte (voir le choix de démarrage), si on les trouve alors l'analyse des échanges sera instructif. Jacques

Je vais essayer d'être plus clair. Pour répondre à ta question, on ne peut pas le garantir. Tu peux te connecter depuis ton PC à google, pourtant tu n'es pas sur le même réseau. Maintenant, dans le cas d'un LAN personnel, on peut penser que les machines sont bien dans le même sous-réseau, oui. ESXi est connecté au réseau de manière physique, par le biais d'une ou plusieurs interfaces réseaux raccordées physiquement au LAN (et vers la box qui fait office de serveur DHCP). La VM est connectée par le biais d'une interface virtuelle (la e1000e) à un réseau virtuel, qui aboutit sur un switch (virtuel lui aussi). Ce switch inclus une ou plusieurs interfaces physiques qui sont elles connectées à un ou plusieurs LAN (tout dépend de la config). En entreprise, on trouve fréquemment un LAN pour la gestion du serveur ESXi, un LAN pour la connexion au datastore (situé sur un NAS ou un SAN) et un LAN pour le trafic des VM vers le réseau de l'entreprise, ou pourquoi pas uniquement entre des VM. Dans ton cas, il faut vérifier (mais en principe c'est la config de base pour la 1ère interface réseau si je me souviens bien) que l'interface physique qui est raccordée au LAN (vers la box) est bien active dans le switch virtuel utilisé par la carte e1000e présentée à la VM. Maintenant, la remarque de Nicoueron reste valable, et ta réponse n'est pas suffisamment claire pour exclure le problème potentiel. Si la VM est sur un autre serveur (le portable) mais qu'elle est démarrée sur le réseau, alors si la configuration n'a pas changée, la VM présente sur le serveur ESXi a donc la même adresse MAC. Dans ce cas, l'attribution d'une adresse IP (par DHCP ou de manière statique) ne peut pas aboutir, les trames IP ne pouvant joindre la VM (adresse MAC identique et active, le serveur DHCP redonne la même adresse IP en principe, qui sera refusée pour cause de doublon sur le réseau). Pour mémoire, une application utilise un couple Adresse IP / N° de port, une interface réseau est identifiée de manière logique par une ou plusieurs adresses IP et de manière physique par son adresse MAC. Dans le cas d'un ESXi avec une seule carte réseau, cette interface répond à toutes les adresses IP utilisées sur le serveur (celle de l'ESXi, et toutes celles des VM qui sont reliées au réseau physique). Donc si les 2 VM sont actives en même temps, il faut modifier l'adresse de la seconde et le fichier grub.cfg en conséquence. Si une seule est active à la fois, et que la ou les interfaces physiques du serveur ESXi sont bien connectées au switch virtuel utilisé par la VM sur l'ESXi, alors la connexion devrait se faire. Jacques