Rechercher dans la communauté

Bonjour, J'ai constaté un souci assez étrange avec mes 2 VMs, et trop concomitant avec la MAJ de SWAG (mon reverse proxy) pour ne pas être liés. Tout d'abord le contexte. J'ai deux VM depuis peu dans VMM : Home Assistant OS Promox Backup server Les deux sont en temps normal accessible via leur IP, mais aussi via le nom de domaine que j'ai paramétré dans le reverse proxy SWAG (installé en macvlan, avec interface virtuelle en supplément, merci @.Shad. pour le super tuto 👋🏻). Ce matin, watchtower m'a mis à jour SWAG vers 5h. En me levant je constate que Home Assistant n'est plus accessible via son adresse IP, alors qu'à minuit ça l'était. Je vois que SWAG a été mis à jour, et je tente de trouver pourquoi ça ne fonctionne plus... Sans vrai succès. Je relance les VM, et après un autre reboot pour HA, tout redevient accessible. Entre temps, j'ai relancé mon script de création de l'interface virtuelle, qui n'a pas renvoyé d'erreur, donc mon interface virtuelle avait sauté elle aussi. En temps normal, ça ne devrait avoir d'impact que sur le reverse proxy, et donc les noms de domaines. Donc mon hypothèse est qu'il y a quelque chose qui a fait foirer la connexion LAN du NAS. Ce qui est confirmé par les log dans le centre des journaux : Mon LAN3 est mon interface réseau principale, via un adaptateur USB 2,5GbE connecté sur un swtich 2,5GbE. Le LAN1 est connecté à un autre switch Gb, mais l'interface est désactivée quand LAN3 est fonctionnelle. J'ai un script lancé toutes les 30 minutes par le planificateur de tâche qui s'occupe de vérifier que LAN3 est fonctionnel et désactive les autres interfaces quand c'est le cas, et réactive LAN1 si LAN3 est KO. Et en rédigeant ces lignes, j'ai fait quelques recherches dans les logs de DSM et c'est en réalité vers 2h du matin que ça foiré. Voilà la sortie de mon script lancé vers 2h00:01 : (1) already root => As VMM is installed and Open vSwitch is activated, all physical interfaces will be managed with the virtual one (ovs_ethX). => So when we'll see ethX, ovs_ethX will be managed as well. => eth0, eth1 : will be deactivated if 'eth2' is up and running. Try n°1 package r8152 is turned on , version is 2.17.1-1 pkgctl-r8152 active_status = active pkgctl-r8152 load_status = loaded pkgctl-r8152 enable_status = enabled The driver status is OK ! No need to do something more. gateway is = 192.168.2.1 Gateway 192.168.2.1 IS NOT accessible ! The driver need to be restarted or reloaded ! [pkgctl-r8152] done reload-or-restart. Try n°2 package r8152 is turned on , version is 2.17.1-1 pkgctl-r8152 active_status = active pkgctl-r8152 load_status = loaded pkgctl-r8152 enable_status = enabled The driver status is OK ! No need to do something more. The driver is still not OK on the 2nd try ! That's not good... It means the eth2 isn't working... So let's reactivate the eth0 interface. Reactivation of eth0. Done. Ipv6 on interface ovs_eth0 is already deactivated. Reactivation of eth0 because of Open vSwitch installed with VMM. -> ovs_ should be up now. You can connect the NAS on 192.168.2.200 in order to sort things out... Reactivation of eth1. Done. Ipv6 on interface ovs_eth1 is already deactivated. Reactivation of eth1 because of Open vSwitch installed with VMM. -> ovs_ should be up now. You can connect the NAS on 169.254.26.251 in order to sort things out... => Exiting script now. Sending Gotify Notification... On voit que le script à bien détecté un souci et à réactivé l'interface eth0 (LAN1). 30 min plus tard, le script réactive mon interface LAN3 (eth2) et désactive LAN1 et tout refonctionne (enfin pas les VMs) (Note : je pense qu'il faut que ce script relance la création de l'interface virtuelle si jamais eth2 a été down... sinon mon SWAG ne fonctionnera plus correctement, et ça c'est un autre souci... que je devrais résoudre avec quelques lignes de code supplémentaires) : (1) already root => As VMM is installed and Open vSwitch is activated, all physical interfaces will be managed with the virtual one (ovs_ethX). => So when we'll see ethX, ovs_ethX will be managed as well. => eth0, eth1 : will be deactivated if 'eth2' is up and running. Try n°1 package r8152 is turned on , version is 2.17.1-1 pkgctl-r8152 active_status = active pkgctl-r8152 load_status = loaded pkgctl-r8152 enable_status = enabled The driver status is OK ! No need to do something more. gateway is = 192.168.2.1 gateway 192.168.2.1 is accessible ! No need to do something more. Deactivation of ipv6 on interface ovs_eth2 in 5s... ovs_eth0 is still up and running. Shutting down now. eth0 is still up and running. Shutting down now. ovs_eth1 is still up and running. Shutting down now. eth1 is still up and running. Shutting down now. Le souci est donc localisé entre 2h00:01 et 2h30 ce matin. En fait loin de la MAJ de SWAG comme initialement pensé... L'investigation continue : pourquoi diable ma connexion a sauté ?! Le switch 2,5GbE, récemment mis ? Ça me parait étonnant, car mon autre NAS ne m'a pas rapporté de déconnexion... ni le NUC branché lui aussi dessus... Hmmm... un autre switch du réseau... peu probable... mais le tout abouti donc au routeur. Il n'y a que lui qui peut avoir merdé, et fait que mon interface du NAS récupère une adresse APIPA, donc pas de serveur DHCP... Regardons les logs du routeur. Diantre, mais il a rebooté ce #@$... Et là, je me souviens que j'ai programmé un reboot 😅 Bon bah voilà, fautif trouvé... 🤣 le routeur qui reboot 🫣🙄 Me reste à décaler un peu le reboot entre deux exécutions de mon script de vérification d'interface, et à coder un peu sur le lancement de la recréation de l'interface virtuelle du NAS en cas de réactivation de eth2. Voilà pour ma petite histoire 😆

Bonjour, Il est possible d'installer Docker et Virtual Machine Manager sur les DS418Play et probablement sur les DS416Play (pas testé) qui sont en fait respectivement des versions 4 baies des DS218+ et DS216+II bridés logiciellement. 1- Docker DSM6 et DSM7: Pour docker c'est simple il suffit de l'installer manuellement, seul limitation, les MAJ ne seront pas proposées, il faudra donc les faire manuellement. (c'est aussi valable pour d'autres paquets comme CMS). Pour l'obtenir: https://www.synology.com/fr-fr/support/download/DS218+?version=7.0#packages ou https://archive.synology.com/download/Package/Docker (A noter, même si ce n'est plus d'actualité (max DSM 6.2.3), DDSM était aussi possible, mais il fallait aussi activer Open vSwitch, donc voir méthode Virtual machine manager) 2- Virtual Machine Manager sur DSM7: Pour Virtual Machine manager, c'est un peu moins simple, car il faut activer Open vSwitch. Et donc il faut modifier le fichier "/etc.defaults/synoinfo.conf" pour autoriser open vSwitch. Ce qui n'est pas anodin et peut comporter des risques. Sur DSM 7 la ligne support open vSwitch est déjà présente mais marqué comme "no", il faut donc remplacer "no" par "yes". Puis on pourra activer Open vSwitch, dans Panneau de configuration > Réseau > Interface réseau > gérer > Paramètres d'Open vSwitch. Comme les MAJ de DSM risque de remettre le fichier "/etc.defaults/synoinfo.conf" à zéro, ça ne pose normalement pas de problème, une fois Open vSwitch activé il le reste. Donc le plus simple pour modifier, c'est de créer un tache déclenché au démarrage avec l'utilisateur root: sed -i 's/support_ovs="no"/support_ovs="yes"/g' /etc.defaults/synoinfo.conf Ou en SSH et en root, remplacer "no" par "yes" de la ligne support_ovs="no" du fichier /etc.defaults/synoinfo.conf Puis de l'exécuter manuellement, normalement en quittant le panneau de configuration et en rafraichissant la page, le menu Open vSwitch apparaitra dans Panneau de configuration > Réseau > Interface réseau, si ce n'est pas le cas redémarrer le NAS. Après il faudra télécharger Virtual Machine Manager, puis l'installer manuellement, le paquet Virtual machine manager nécessite le paquet "réplication service", qu'il bien faut installer avant. Et comme pour Docker les MAJ, ne seront pas proposées, il faudra les faire manuellement. Pour l'obtenir: https://www.synology.com/fr-fr/support/download/DS218+?version=7.0#packages ou https://archive.synology.com/download/Package/Virtualization (A noter, c'est aussi possible sur DSM6, mais la ligne support_ovs="no" n'existe pas, il faut donc ajouter une ligne support_ovs="yes" dans le fichier /etc.defaults/synoinfo.conf en SSH et en root)

Bonjour, Je souhaiterai transférer une VM que j'ai faite sur VMWare directement sur VMM, pensez vous que cela est c'est possible ? Si oui par quel procédé ? J'ai essayé d'importer un .VMDK mais du coup j'ai pas les configs liés au VMX. Sinon est-ce possible de fournir un VMX à notre machine virtuelle sur VMM ? Cordialement.

Bonjour à tous, Je constate que VMM est en fait ultra limité en nombre de VM. J'ai créer 4 VM... et à la cinquième, j'ai eu un message d'avertissement (pas fait d’imprime écran 😣). Résultat j'ai été "obligée" de prendre la licence pro d'évaluation pour ma 5éme VM.... Sauf qu'elle est "d’évaluation" et donc limité dans le temps (1 mois)... Puis j'ai un peu cherché... Et franchement Synology fidèle a un marketing bien sournois, n'est absolument pas clair sur cette limitation.... Par exemple, le DS1821+ n'est même pas listé sur cette page et entre les CPU physiques, les vCPU et les threads, pour savoir combien on le droit de faire tourner de VM sur son Nas, franchement rien de mieux pour embrouiller le consommateur. https://kb.synology.com/fr-fr/DSM/tutorial/How_many_virtual_machines_can_I_run_on_my_Synology_NAS Bref, savez s’il existe une solution de contournement pour faire tourner plus de 4 machines sur un Nas et sans limitation ? J'ai pensé a un vrai hyperviseur sur une machine dédié et les VM stocké sur le Nas mais je suppose que les VM vont utiliser les ressources de l'hyperviseur et pas celle du Nas... Et je voudrais vraiment utiliser les ressources (CPU et Mémoire) du Nas. J'ai entre aperçu, (je ne sais plus ou !) que DSM 7 avait changé son mode de licence pour VMM et qu'il allait passer a 32 VM max sans limitation ? Pouvez vous me le confirmer ? Merci d'avance.