Lazer

euh.... cherches ubuntu + azerty + esxi sur google parce que là j'ai pas d'idée. la dimension de la clé importe peu, l'espace est assez grand. J'ai une Sandisk Cruzer Blade qui rentre très largement.

Voilà , j'ai une nouvelle VM avec DSM 5.0 Build 4482 qui fonctionne. Le visuel de l'interface change par rapport à DSM 4.3, mais ça part ça tout semble identique. Donc Fredo, pour toi : Tu installes ESXi selon ce tutoriel : http://informatique-beaujolaise.blogspot.fr/2013/09/installer-vmware-vsphere-esxi-51-sur.html Tu installes DSM selon ce tutoriel : http://cyanlabs.co.uk/tutorials/synology-dsm-4482-gnoboot-to-nanoboot Et tu ne devrais pas avoir de problème.

Si, la 5.5 est bien, mais elle consomme plus de RAM. Tu sais, je ne suis pas forcément un amateur des dernières nouveautés, je préfère un système stable, éprouvé, et qui répond au besoin, plutôt qu'un mouton à 5 pattes boiteux. Après c'est toi qui voit, si tu veux la dernière version, ça fonctionnera aussi, heureusement Avec VMware sur ton Mac, tu dois aussi pouvoir monter l'ISO directement.

vSphere 5.1 U2 Feb 2014

vSPhere Client est gratuit, c'est juste l'interface d'administration de ESXi. vSphere Infrastructure est payant. Subtile différence

64 bits. Pas besoin de graver le CD. Tu télécharges l'ISO et tu la copie dans le datastore en utilisant le client vSphere (que tu installeras lorsque tu accèderas à ESXi). Ensuite, tu montes l'ISO sur la VM, et tu fais ton installation à partir du lecteur de CD virtuel. La magie de la virtualisation, pas besoin de lecteur de CD Oui, sur le Mac et la Freebox tu dois pouvoir lire tes disques.

Oui, OSX et Freebox sont sur base de BSD et de Linux respectivement, donc ils savent lire le format EXT4. Ensuite ta Freebox effectue un partage via le réseau, donc Windows peut accéder aux données. Mais ce n'est pas Windows qui lit le disque, c'est bien le Linux de la Freebox. Voilà pourquoi ça fonctionne. Pour Linux, je te conseille Ubuntu, c'est la plus simple et user friendly. Moi j'utilise RedHat, parce que c'est ce qu'on a au boulot sur les serveurs, et c'est supporté par les éditeurs de logiciels pro (mon objectif étant de me monter une plateforme d'outils pro à la maison). Mais pour un usage personnel, Ubuntu est bien mieux. Tu peux faire une VM avec 20 Go ça devrait être suffisant. Mais tu peux aussi faire plus, et en cochant la case Thin Provisionning, seul l'espace réellement utilisé par la VM sera utilisé sur disque.

Non, Windows ne peux pas monter une partition ext4. L'USB est juste le moyen physique de transport, comme le SATA, le SCSI, le SAS, ou le Fibre Channel... Si tu veux vraiment tester, télécharge et grave un LiveCD sous Linux pour tester de monter ton disque.

Ici tu trouveras le vmdk nanoboot pour esxi : https://drive.google.com/a/gadz.org/folderview?id=0B8WTs1D6D3VIWUFubjNFODhmU3c&usp=sharing# L'image ne fait que 16 Mo, c'est tout petit ! Ca me donne envie de tester, tiens, aller hop c'est parti, je me crée une nouvelle VM

Western DIgital RED => parfait pour un NAS, c'est le top. La VM pour Xpenology est toute petite, normalement il faut 32 Mo (oui oui, Mega-octets) Par contre, ton lien Nico donne un fichier img à écrire sur une clé USB, mais c'est pas bon, car toi tu veux mettre Xpenology dans une VM. Donc il faut trouver un fichier vmdk, je ne sais pas si Nanoboot fonctionne sous ESXi ??? Pour une VM Windows, je pense que 50 Go peuvent suffire si tu n'installes pas trop de logiciels dedans. Pour les disques du Readynas sous Windows, c'est normal, les partitions sont formatées en ext3 ou ext4, format que Windows ne sais pas lire. C'est le filesystem standard sous Linux.

ESXi il faut l'installer sur une clé USB de 1 ou 2 Go comme je te l'ai indiqué. Le disque de 250 Go contiendra le datastore, c'est àdire les VM. Si tu n'as pas de nouveau disque, oublie ce que j'ai dis avec la VM Linux. Tu peux faire ta sauvegarde sur ton PC puis reformater tes 2 disques. (Lors de l'installation de DSM il te proposera de les formater.) Ça sera plus simple.

Je te propose au autre chemin de migration : - installation physique du N54L avec un gros disque vierge, et tes 2 anciens disques de 2 To (parce que 2 Go, ça m'étonnerait ) - install ESXi - création VM Xpenology avec le gros disque vierge en RDM - création VM Linux avec tes 2 anciens disques en RDM - dans la VM Linux, montage des filesystems des 2 anciens disques - copie via le réseau interne de ESXi entre les 2 VM des données, via un montage NFS Ca ira beaucoup plus vite au niveau débit, et tu comprendras ainsi la souplesse de la virtualisation. Moi j'ai transféré 1,5 To comme ça.

Ah intéressant cette fonction, merci

Avec mon 3ème exemple de script, justement je n'ai pas de code d'erreur. Je veux dire que j'ai toujours le retour (status==200 and errorCode==0), et ne rentre jamais dans le cas de figure else. Pour mon explication : 1 - j'ai supposé que les ressources ne sont pas correctement libérées, même si les variables locales sont déclarées dans la fonction. En fait, j'insinue que les variables locales ne sont pas détruites. Ou plutôt un gabage collector qui ne fait pas son boulot correctement. Après je peux me tromper, je ne suis pas développeur, j'ai juste quelques notions... 2 - Ton Update Notifier utilise Net.FHttp et je l'ai vu tomber dans le cas que je mentionne dans mon 2nd exemple de script. Oui ton LUA Framework est une solution, mais j'essaie de faire avec les fonctions de bases

ah ok. En tout cas, dans mon dernier exemple de script, ça fonctionne bien comme ça chez moi, bug JSON ou pas. Je n'ai pas d'explication alors...

Ah mais t'es aussi tordu que lui en fait

Un renommage marketing. En fait, ESXi à la base, c'est juste l'hyperviseur à installer sur chaque serveur physique à virtualiser. Ensuite, il y a vSphere Intrastructure, qui est l'ensemble de tous les ESXi regroupés ensemble au sein d'un cluster. Quand tous les ESXi accèdent à un stockage partagé (baie NAS ou SAN), tes VM peuvent se balader dynamiquement d'un serveur physique à un autre, de façon transparente pour l'utilisateur. On parle alors de vMotion, DRS, etc... bon là pour le coup, ce n'est plus gratuit du tout.... mais c'est ce qui fait la force de l'offre VMware en entreprise.

Tu lui donnes un nom différent, comme ça pas d’ambiguïté

euh.... je veux bien, mais alors pourquoi la fonction Web:GET() renvoie un statut vide, alors même qu'on n'a pas encore fait un appel au Json pour parser le résultat ?

Ca m'a l'air pas mal. Par contre il utilise ESXi 5.5, je te conseille la 5.1. Au pire plus tard tu feras la migration 5.1 vers 5.5 sans souci, mais d'ici à ce que t'en aies besoin, de l'eau aura coulée sur les ponts. Ah et aussi il utilises Xpenology Gnoboot, qui n'est pas la toute dernière, car je crois qu'on ne peut pas installer les dernières mises à jour. Il faut partir sur Nanoboot, mais je n'ai pas encore testé ça... Regardes là : http://cyanlabs.co.uk/tutorials/synology-dsm-4482-gnoboot-to-nanoboot Si tu veux un tuto en français pour ESXi, tu peux suivre celui que j'ai donné sur le site de l'informatique beaujolaise (quel drôle de nom...)

Voici quelques résultats de mes recherches sur les Main Loop d'un périphérique virtuel, en espérant que ça puisse aider les développeur de super modules. Le code LUA d'une Main Loop tourne en boucle avec un sleep de 3s. Si la main loop bouffe trop de ressources (allocation de variables locales à répétition), la HC2 finit par tuer le processus, et on est obligé de relancer la main loop en sauvegardant à nouveau le Virtual Device. Une solution a été trouvée par Krikroff, en gros, le principe est de créer une fonction et d'appeler celle-ci à chaque boucle, afin de ne pas ré-allouer les variables à chaque passage. Il faut s'inspirer de ses Virtual Device pour comprendre (genre Update Notifier). Malgré cela j'ai découvert que le module Update Notifier est affecté par un bug qui finit par arriver au but de plusieurs jours (en fonction de la fréquence de rafraichissement). C'est la fonction Net.FHttp() qui est responsable, car trop gourmande en ressources. Démonstration : Dans un premier temps, on crée une main loop toute simple, avec des lignes de codes qui s’enchainent, un un fibaro:sleep() à la fin, sachant que le temps d'attente total fera 3 secondes de plus, car le code interne de la HC2 effectue automatiquement un sleep de 3s : -------------------------------------------------- -- Exemple de Main loop -------------------------------------------------- -- System variables local selfID = fibaro:getSelfId() local ip = fibaro:get(fibaro:getSelfId(), 'IPAddress') local port = fibaro:get(fibaro:getSelfId(), 'TCPPort') local Web = Net.FHttp(ip, port) -- Main code local payload = "/url/a/appeler?avec&des&parametres" response, status, errorCode = self.Web:GET(payload) if tonumber(status) == 200 and tonumber(errorCode) == 0 then if (response ~= nil) then -- Actions à effectuer -- ... else fibaro:debug('Error : Can not connect to Web server, empty response') end else fibaro:debug('Error : Can not connect to Web server, status='..status..', errorCode='..errorCode) end -- Wait 60s fibaro:sleep(60*1000) Normalement, cette main loop sera tuée au bout de quelques heures, car les variables ne sont pas libérées, et surtout réallouées à chaque passage dans la boucle, donc on fini par dépasser une limite de mémoire utilisée. Dans un second temps, on applique la recette de Krikroff, en créant une sorte d'objet qui est défini une seule fois. Cet objet contient des variables (elles sont également définies une seule fois), et une ou plusieurs fonctions. La fonction principale est appelée à chaque passage dans la boucle : -------------------------------------------------- -- Exemple de Main loop -------------------------------------------------- if (MyObject == nil) then MyObject = { -- System variables ip = fibaro:get(fibaro:getSelfId(), 'IPAddress'), port = fibaro:get(fibaro:getSelfId(), 'TCPPort'), -- Main code main = function(self) local Web = Net.FHttp(self.ip, self.port) local payload = "/url/a/appeler?avec&des&parametres" response, status, errorCode = Web:GET(payload) if tonumber(status) == 200 and tonumber(errorCode) == 0 then if (response ~= nil) then -- Actions à effectuer -- ... else fibaro:debug('Error : Can not connect to Web server, empty response') end else fibaro:debug('Error : Can not connect to Web server, status='..status..', errorCode='..errorCode) end -- Wait 60s fibaro:sleep(60*1000) end } fibaro:debug("Function successfully loaded in memory") end -- Start MyObject:main(); Malgré tout, on finira par arriver à une situation où la boucle n'est pas tuée, mais la fonction Net.FHttp() renvoie les valeurs errorCode=<vide> et errorCode=2. C'est en tout cas ce que j'ai constaté sur le module Update Notifier, et sur mes propres essais. Donc il semblerait qu'encore une fois, bien que la variable Web soit située dans la fonction main(), la mémoire ne soit pas correctement libérée. Pour finir, en 3ème étape je pense avoir trouvé une solution stable, qui tourne depuis une 15zaine de jours chez moi, avec un passage dans la boucle toutes les 60 secondes, donc assez intensif. L'idée est de définir la variable Web une seule fois, et non plus dans le code de la fonction : -------------------------------------------------- -- Exemple de Main loop -------------------------------------------------- if (MyObject == nil) then MyObject = { -- System variables Web = Net.FHttp(fibaro:get(fibaro:getSelfId(), 'IPAddress'), 80), -- Main code main = function(self) local payload = "/url/a/appeler?avec&des&parametres" response, status, errorCode = self.Web:GET(payload) if tonumber(status) == 200 and tonumber(errorCode) == 0 then if (response ~= nil) then -- Actions à effectuer -- ... else fibaro:debug('Error : Can not connect to Web server, empty response') end else fibaro:debug('Error : Can not connect to Web server, status='..status..', errorCode='..errorCode) end -- Wait 60s fibaro:sleep(60*1000) end } fibaro:debug("Function successfully loaded in memory") end -- Start MyObject:main(); Si les experts ont un avis sur la question, je suis preneur. En attendant, j'espère que ça pourra servir. Dans tous les cas, j'espère que la v4 résoudra ces problèmes.

Après avoir bien lu toutes ces explications, je me rappelle maintenant du concept de base en programmation, qui est appelée portée des variables. Je ne crois pas avoir vu Krikroff ou Steven mentionner ce concept, mais je suis certain que vous connaissez parfaitement ça. Pourtant c'est bien de ça qu'il s'agit dans le cas présent. Finalement c'est le défaut des langages trop permissifs comme le LUA, le PHP, etc, qui permettent d'utiliser des variables sans les déclarer explicitement, avec comme conséquence des résultats imprévisibles, obligeant à mettre beaucoup de debug pour comprendre l'origine du problème. Avec des langages genre le Pascal où l'on était obligé de déclarer très précisément chaque variable, il n'y avait plus d’ambiguà¯té possible.

Pas de souci particulier depuis ce matin, avec tapatalk depuis mon ADSL Free, ou 4G Bandyou.

Arf et je ne peux pas t'aider, j'ai bien un module RGBW, mais je ne l'ai pas encore mis en service... ça fait partie des projets futurs. Je crois que Krikroff maitrise assez bien les appels d'API, tu peux tenter un message privé.

Fredo, c'est comme ça qu'on apprend, en cherchant soi-même Je viens de faire un test de perf de copie réseau rien que pour toi Source : HP Proliant N54L avec Xpenology dans une VM, lecture sur 1 disque Western Digital RED 4 To Réseau : 1 Gbit/s, traversée de 2 switchs (celui de la Freebox, et un Netgear) => Copie de fichiers MKV via un partage Windows CIFS Destination : Core i7, RAM 6Go, SSD (donc clairement ce n'est pas ce PC qui limite les perfs). Débit moyen de 91 Mo/s. D'après les graphs de performances de vSphere Client et de Xpenology, le disque dur était occupé à 65%, et le CPU à 30% (pointe à 50%) donc je pense avoir saturé le réseau (pour rappel 1 Gb/s = 100 Mo/s) A noter qu'en Benchmark sous Linux, j'ai atteind les perfs théoriques du disque, j'ai mesuré 140 Mo/s en début de disque (là où c'est le plus rapide). Donc même avec virtualisation, en mappant les disques en RDM, les perfs sont plus que correctes Si tu ne crées pas d'autre VM (genre Sarah), as-tu vraiment besoin de virtualisation ? Je ne peux pas trop répondre à ta place. Pour le serveur Web PHP MySQL & co, tout ça est intégré à DSM, donc ton Xpenology pourra faire tout ce qu'un Synology sais faire, virtualisation ou pas. Tu peux effectivement utiliser le lecteur DVD dans tous les cas, BIOS modifié ou pas. Mais euh, comment dire, y'a encore des gens qui utilisent des galettes de 12cm en 2014 ???