-
Posts
2,350 -
Joined
-
Last visited
-
Days Won
51
Posts posted by nicoueron
-
-
J'en ai peur oui!
Moi j'ai un HP N54L et HP met à disposition des images ESXi avec leurs drivers donc pas trop de pb de ce coté. Regarde chez le constructeur de ta carte mère si il la propose.
A défaut tu peux investir dans une carte réseau (10-15€) compatible. Ou encore mieux rester sur ESXi 6.0.2 voire ESXi 5.5 (entre nous, la dernière version d'ESXi n'apporte pas grand chose)
-
oui tu peux faire comme ça.
-
La VM n'est qu'une coque dans ce cas là. Si elle est cassée, il suffit de la recréer et de rajouter les fichiers vmdk correspondant au mapping de tes disques et DSM se remet de suite en route. Par contre si s'est DSM qui plante, tu fais comme si s'était un vrai syno pour le réinstaller.
-
Salut,
Pour faire comme un vrai Synology avec ESXi le seul moyen est de dédier les disques durs que tu veux pour ton DSM en RDM : https://www.synergeek.fr/utiliser-disque-en-raw-device-mapping-rdm-pour-xpenology
Résultat des performances excellentes et un RAID géré 100% par DSM. Par contre chez moi, je n'ai jamais réussi à avoir l'état du SMART dans le DSM. Mais sinon c'est ça qu'il faut faire plutôt que de créer un disque virtuel dans le datastore de VMware.
-
Je me rappelle une fois eu le pb suite à une mise à jour, pour faire un downgrade j'avais dû faire une modif du fichier de version (je ne sais plus lequel) et réinstaller DSM avec la version opérationnelle. Il doit y avoir des tutos sur le sujet dans le coin. L'objectif de cette manip étant de ne pas perdre ses données évidemment!
-
Salut,
Ayant eu par le passé quelques déboire avec les dernières mises à jour inférieures à 6.1, je me demandais si quelqu'un avait tenté l'upgrade vers la 6.0.3-8754 ?
Si oui quels sont vos retours ?
Merci par avance
-
Je rejoins Albaret.
Apres si ton usage c'est plus qu'un simple NAS, alors oui ta config est bien plus puissante. Par contre je doute qu'une alim de 300w soit nécessaire sauf si tu bosses chez EDF...
-
Essaie les différentes options de Samba via le panneau de configuration.
Au pire regarde les logs associées à SMB dans /var/log/samba/....
-
Ah ça y est j'a trouvé mon pb! Ma Freebox avait un connecteur RJ45 qui était "bloqué" à 100Mbits au lieu de gigabits... Un reboot et c'est reparti.
Bon courage pour ton pb
-
Salut,
Je rencontre quasiment le même pb que toi en ce moment. Moi avant j'étais à 110Mo/s et maintenant je plafonne à 11,8Mo/s...
Après investigation, il semble que lors d'un transfert SMB (partage de fichiers depuis Windows) le démon smbd consomme 100% de la CPU du NAS lors du transfert. Autant dire que si j'ai plusieurs de transferts en parallèle, le débit devient vite ridicule.
Je n'arrive pas à comprendre pourquoi. Je suis passé à la dernière update 11 pour voir si ce n'était pas un bug mais non c'est pareil. Plusieurs reboot et idem...
[EDIT-1] J'ai le même pb lors d'un transfert en SSH. La consommation CPU associé au service s'emballe à 100%
[EDIT-2] J'ai essayé en changeant le type de carte réseau de la VM (E1000 et VMXNET3) sans résultat
[EDIT-3] J'ai essayé d'arrêter TOUS les autres services et de ne laisser que SAMBA et/ou SSH, mais pareil.
[EDIT-4] L'indexation multimédia se lance souvent à mon gout et prend bcp de temps et de ressources. Est-ce que ce ne serait pas là le pb ?
HELP !
-
Salut,
Hélas je pense que ton controleur RAID HP (ultra-propriétaire) n'est pas géré. En d'autres terme le driver n'est pas embarqué dans XPEnology. Il faudrait que tu trouves le moyen d'inclure le driver dans l'image, mais je ne sais pas comment faire. Sinon tu peux tenter une installation d'ESXi sur ton serveur (là je suis sûr que ça marchera). Ma recommandation étant dans ce cas de dédier un ou deux disques (pour faire du RAID1) de 36G à ESXi (avec son datastore) et une VM XPenology associé aux 4 autres disques en RDM.
-
Je n'ai jamais testé. Mais je me dis que de toute façon la proba que tu perds tes données est faible car au pire si DSM ne retrouve pas le bon disque au bon endroit tu peux toujours le remettre sur l'ancien port sata. Tu auras au pire à reconsolider tes données.
-
Salut,
Dans l'application DSFile, spécifie le numéro de port dans le nom du serveur avec les ':'
Et merci par avance de te relire pour corriger un minimum de fautes d'orthographe.
-
Merci pour ta réponse, je regarde ça ce soir.
A distance ça lag trop c'est peut être pour ça que je rate la première étape du boot pour sélectionner l'option ESXI.
Pour le coup, le message ne s'affiche qu'une à deux secondes; donc effectivement il faut être TRES rapide!
-
Si tu souhaites te lancer dans cette migration de 5.2 vers 6 il faut juste que tu comprennes bien qu'il n'y a pas de mise à jour à proprement parler du hack. C'est du "annule-et-remplace". En gros ton XPEnoboot que tu utilises pour le DSM 5.2, tu dois repartir de zéro afin d'utiliser le nouveau loader de June car c'est le seul compatible avec DSM6.
Dans 90% des cas ==> 1 version d'XPEnoboot = 1 version de DSM <==
Dès lors que tu te lances dans cette procédure, sache que l'installation ou la migration vers DSM 6 implique d'utiliser le loader 1.01 de June et que la seule différence pour ton cas sera de choisir "migrer les données" lors de l'installtion du DSM.
-
Bonjour à tous,
Avez vous un nouveau lien pour le package ovf puisque le premier lien est dead.
J'ai essayé directement avec le loader jun's mais impossible de détecter avec Synology Assistant...
Merci
Le fichier ovf est situé dans le zip, non ?
-
- 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.
Je n 'ai pas de réponse officielle mais c'est peut-être possible que Synology ai implémenté cela par dé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!
- 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 ?
Le fichier synoboot.vmdk contient le hack de Juno ET seulement le hack - rien d'autre. L'objectif étant de faire croire au DSM que le matos est bien compatible.
- 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.
L'architecture de DSM fait que l'OS est réparti sur tous les disques composant le(s) volume(s) - donc dans ton cas sur NAS.vmdk. En aucun cas DSM vient toucher aux fichiers situés dans le synoboot.vmdk. D'ailleurs il ne le voit pas et c'est là tout l'intérêt. Pour résumer NAS.vmdk contient le DSM avec la version que tu as mise à jour + tes données + ta config
-
c'est la manière la plus longue mais de loin la plus sûre donc je ferai pareil que Terzo13 !
-
Tout à fait d'accord avec mon homologue breton
Pour une telle bête, juste DSM en bare metal me parait un peu luxueux... Un hyperviseur type ESXi me semble plus adapté ce qui t'assure en plus une meilleure prise en charge de DSM et t'assure toujours le direct mapping de périphérique sur une VM (compte tenu que c'est du Xeon) et surtout te laisse voir venir pour des usages futurs.
Il ne faut pas oublier le principe de DSM : faire du NAS, là tu arrives avec une Ferrari pour rouler sur l'autoroute A7 au mois de Juillet si tu vois ce que je veux dire...
A bon entendeur !
-
Et je peux vous dire que la dernière saison de la maison de mickey, ben, on ne la trouve pas comme ca....
et ça t'étonne? Mes enfants vont sur Youtube pour les voir... après ils s'en fichent un peu de savoir si c'est la dernière saison!
-
Je vois 2 approches :
- Soit tu continues à utiliser le servie Apache fourni par DSM6, auquel cas tu passes par le panneau de configuration et tu crées un nouveau virtual host. Mais je n'ai jamais testé.
- Soit (comme moi) tu mets en place un HAproxy. Perso je l'ai déployé via un conteneur Docker fourni par DSM. Il se lance au démarrage et consomme 5Mo. Si tu n'y arrives pas je te filerai ma config si tu veux.
-
Je pense que ton Jeedom partage le même numéro de port que WebStation à savoir le 80 ou/et 443. Essaie de changer la config de jeedom afin qu'il utilise un autre numéro de port
-
Mon retour d'expérience :
J'ai une veille Avermedia http://www.01net.com/tests/avermedia-avertv-volar-black-hd-a850-fiche-technique-9089.html en USB aussi et relié aussi à mon antenne de toit. Çà marche plutôt bien mais ça bouffe du CPU la HD! Fut un temps où je l'avait relié à ma VM DSM pour tester avec VideoStation, le résultat n'est pas terrible, CPU > 80% lenteur et plantage de VideoStation regulier, bref je l'ai remis sur mon PC lui-même branché à mon videoproj et là ça marche très bien!
Après mis-à-part regarder du sport en direct, je ne vois pas vraiment l'intérêt d'avoir la TV (poubelle) sur un NAS! il est plus simple de télécharger ou streamer un film depuis Internet. ce n'est que mon avis
-
De rien
Pour info et par mesure de sécurité j'ai poussé le sujet un peu plus loin chez moi. En gros je n'ai que 2 ports ouverts sur Internet : le 80 et le 443. Chacun étant respectivement redirigé vers un même reverse-proxy et c'est lui qui réaiguille vers les différents services en fonction du sous-domaine saisie dans l'url.
Après c'est vrai que ça fait un SPOF, mais au cas-où j'ai un serveur VPN qui me permet de me connecter à distance sur demande et corriger l'éventuel problème.
Connection xpenology derrière un VPN
in Paquets, mods & fonctionnalités DSM
Posted
Bonjour,
Je vais être franc, je n'ai pas compris grand chose. Mais ce que je peux dire c'est que si ton VPN est actif et que tu t'y connectes depuis l'extérieur (jusque là c'est le fonctionnement normal) c'est normal que l'IP retournée soit celle de ton domicile, c'est le principe du VPN.
Quel type de serveur VPN as-tu installé et sur quel machine ? une VM? ta box ?