Djey
-
Posts
171 -
Joined
-
Last visited
Posts posted by Djey
-
-
Bonjour,
la seule solution que j'aie trouvée pour le démarrage est d'utiliser la fonction wake-on-lan du HP (si activée dans le BIOS).
Mais cela nécessite qu'un appareil tourne sur le réseau et 'réveille' le microserver à une heure définie.
Pour ma part, j'ai créé un outil en ruby qui tourne H24 sur un raspberry pi. Sinon à la demande une simple appli smartphone fait très bien le job du WOL (il en existe pas mal de dispo).
Et pour l'arrêt, oui bien sûr on peut scripter l'extinction du serveur avec le shell ESXi. Et selon la configuration des VMs, on peut leur demander de s'arrêter proprement juste avant l'extinction (les vmware tools doivent être installés sur la VM, un paquet syno existe).
Idem l'outil sait gèrer l'arrêt à la demande (via une requête http) ou selon une planification basique avec cron.
Cela peut s'installer à la mano ou via un docker.
+ d'infos : viewtopic.php?f=2&t=4475
-
I think you're very close.
Personally, I just had to create/edit this file in ESXI shell (connect with ssh as root):
/etc/ssh/keys-root/authorized_keys
and append my public key to it.
I can't remember of additional ESXi settings necessary. Might help in your case.
-
Indeed, authentication has to be correctly set-up before starting pi-control container.
Here is a starter link :
https://blogs.vmware.com/vsphere/2012/0 ... xi-50.html
Here comes some explanation on article steps:
To generate a private/public key pair onto dsm, you just log onto DSM shell then run:
ssh-keygen
and follow instructions. It will create keys in directory : /root/.ssh/
( or if you already have keys, copy them into /root/.ssh/ directory)
Then, connect to ESXl from DSM:
ssh root@
And confirm to add key to host cache
In ESXI, edit /etc/ssh/keys-/authorized_keys file and copy contents of previously generated id_rsa.pub (public key) - that's what
ssh-copy-id
command does.
Exit ESXI shell and try connecting again. If properly configured, next time connection won't require password.
To run the container, you just check volume parameter to point your DSM keys directory, check -v parameter :
-v /root/.ssh:/root/.ssh
Also, after running pi-control container, execute command and post results here :
docker logs pi-control
Should be better after that. Please let me know
Thanks
-
Sorry for late reply, I just tested smartX x64 image against SynoDocker. Working here.
From root shell:
docker run -d -p 8080:80 -e PI_CONTROL_ADDRESS=':4600' --restart=always --name smartx djey/smartx-linux-x64:0.1
, assuming that pi-control container running under host port 4600.
Thus smartX web-ui will be available through http://:8080/smartx.html
-
Tested and it works as well as containerized on rPi
Sadly, DSM GUI did not let me provide all required arguments to run image into a container; I had to type from root shell:
docker run -d -p 4600:4600 -e ESXI_HOST='x.x.x.x' -e ESXI_USER='root' -e ESXI_MAC_ADDR='xx:xx:xx:xx:xx:xx' -e LAN_BROADCAST_ADDR='x.x.x.x' -v /root/.ssh:/root/.ssh --restart=always --name pi-control djey/pi-control-linux-x64:0.1
Running container does appear into DSM GUI afterwards, so that's alright finally.
- I'm with DSM 5.2-5967 U1 -
Edit: x64 Linux image available for smartX web interface. But need to be tested against SynoDocker, still.
-
Thanks haydibe, looks like DSM GUI always wanna get 'latest' tag.
So latest tag is working for some images, some other won't (might be due to different docker version - ARM images are pushed from my raspberry PI directly, x64 ones from virtualized Xubuntu 14.04 )
I guess that manually (command line) pulled images do appear into DSM as well?
Sorry I haven't time to try this till tomorrow.
-
That's weird, I could pull the image from PC at work, but DSM GUI couldn't for the same reasons as you.
All other images can be retrieved without a hitch.
Maybe I should recreate the repository and push again ...
-
Docker image for x64 Linux kernel is ready. It should run fine within xpenology.
https://hub.docker.com/r/djey/pi-control-linux-x64/
Please note that some limitations do remain, due to the base image I've been using (Alpine). Will fix it in the future.
-
Yeah, my fault I'm afraid. I did not provide details about image compatibility.
A x64-based image (from alpine linux I guess) should work well on syno docker.
-
Hi,
that happens because the current image is based on Debian for ARM (raspbian:jessie) as it's running on a raspberry PI.
To make it run on x64 architecture, I have to create a new image. I will do eventually.
-
Finally!
I was able to create Docker images for both pi-control and smartX projects!
Those first images are made for devices running raspbian:jessie.
- pi-control: https://github.com/djey47/pi-control/wi ... install%3F (instructions) and https://hub.docker.com/r/djey/pi-control-raspbian/ (hub)
- smartX: https://github.com/djey47/smartX/blob/master/README.md (instructions) and https://hub.docker.com/r/djey/smartx-raspbian/ (hub)
- pi-control: https://github.com/djey47/pi-control/wi ... install%3F (instructions) and https://hub.docker.com/r/djey/pi-control-raspbian/ (hub)
-
Hi,
pi-control services do actually run on raspberryPi (or similar device). It's not so easy to install (or even create a such a spk file) on the NAS - due to lack of software support on DSM.
smartX could be however, as it only need nginx.
Some of the reasons why I decided to set everything on a rPi:
- the need to control the NAS even when ESXi is OFF (e.g. to start it)
- the need to check hypervisor status with all Vms plugged in, even when xpenology is not running.
and yes, smartctl seems to work finally on xpenology. The fact is, smartX is just a webapp and can't directly get data from the system, it must use a data source (like JSON sent by pi-control) to get values. A solution would be to enhance pi-control to provide info from smartctl as well ...
By the way, as a first step I was planning to use ESXI smartd daemon to get latest events.
https://github.com/djey47/pi-control/issues/10
I will take note of your idea, can't guarantee to get time to put my hands on it, but who knows ...
Thanks for your interest in this project!
-
Il serait intéressant de voir du côté du paramétrage smb du xpenology. Le protocole a du évoluer.
-
@elmuziko:
it should work with ESXi 5.1, as it does not rely on tools which are 5.5-specific.
@McDull:
No, SMART support has not always been available with smartctl/smartd, depending on xpenology version and installed bootloader.
It did work with Trantor's 4.3.
When I migrated to 5.0, gnoBoot did not support it; that's why I had to find a workaround.
Now, nanoboot seems to have it fixed. So what will be next ? I can't definely rely on the bootloader...
A major advantage is I can monitor my datastore hdd to ESxi the same way:)
Anyway you're right, if your hardware support VT-d, adding a 3rd part disk controller and using passthrough mode is the way to go to.
That's not an option with N54L.
-
Concerning SMART data not available in ESXi,
I was facing the same issue and as none of existing solutions did the trick, I decided to set-up my own SMART workaround. I'm using SMART tools from ESXi directly (not xpenology) to get accurate information.
See thread:
-
Tout à fait d'accord sur ta première assertion, c'est justement pour cela que Synology ne fournit pas de support mais ne prend pas pour autant une position offensive vis-à-vis d'xpe ^^*Ils ont peut être compris que des produits " démos" cela faisait acheter les "vrais"
Surtout qu'il n'y a jamais eu vraiment quelqu'un qui ait décrit " complétement et pas à pas " comment ont pouvait créer la clé de démarrage !!!
Compte tenu de cela j' ai personnellement considéré que ce n'était que la "bidouille"
Pierre
Si personne n'a jamais donné de procédure entière, c'est peut-être parce que tout simplement la recette de cette fameuse "clé de démarrage" change à chaque version majeure ?
Il faut aussi accepter que xpenology a un (léger) cran de retard sur syno, mais est-ce vraiment genant finalement ? Qu'apporterait une version majeure de si crucial que l'on ne puisse pas attendre ? (vraie question).
Xpenology est de qualité bien supérieure à une simple bidouille. Avec tout le respect que je dois aux personnes se creusant la cervelle pour le maintenir. Et c'est factuel, cela fonctionne.
-
Tout àfait d'accord sur ta première assertion, c'est justement pour cela que Synology ne fournit pas desupport, mais ne prend pas pour autant une position offensive vis-à-vis d'xpe ^^*Ils ont peut être compris que des produits " démos" cela faisait acheter les "vrais"
Surtout qu'il n'y a jamais eu vraiment quelqu'un qui ait décrit " complétement et pas à pas " comment ont pouvait créer la clé de démarrage !!!
Compte tenu de cela j' ai personnellement considéré que ce n'était que la "bidouille"
Pierre
Si personne n'a jamais donné de procédure entière, c'est peut-être parce que tout simplement la recette de cette fameuse "clé de démarrage" change à chaque version majeure ?
Il faut aussi accepter que xpenology a un cran de retard sur syno, mais est-ce vraiment genant finalement ? Qu'apporterait une version majeure de si crucial que l'on ne puisse pas attendre ? (vraie question).
-
Pas forcément intuitif, mais je ne dirais pas complexe pour autant
Le tout est de s'y mettre pour de bon, la manip demande un peu de temps pour faire ça bien.
Dans mon cas, je suis passé d'un NAS 211+ vers xpenology sur ESXi, les tutos sur le net sont en général très complets et illustrés de moults captures d'écran, je n'ai pas rencontré de soucis particuliers.
Les disques durs, une fois alloués à ESXi (cf. post précédent) sont totalement reconnus par xpenology et ne demandent pas de formatage quelconque.
Bon courage !
-
Hi,
even though I'm not using this tool (and I've never had any knowledge about it), I guess notifications should be triggered from this php script using synology tool.
(thus php script should be able to detect failures).
e.g :
/usr/syno/bin/synodsmnotify -c -t |@ ""
I'm planning to implement this in my own solution.
-
Hi,
despite all help I could get in this amazing forum, I was never able to display SMART and perform self tests in DSM, because of a lack of feature in the drivers for VMWare ParaVirtual/LSI SCSI controller.
Whereas my main concern was just to get SMART data about hard drives in my xpenology set-up as a VM (in a VMWare ESXi hypervisor), 4 hards disks in Raw Device Mapping - Hardware is a HP G7 N54L -
Given the fact ESXi already has what it gets to fetch a lot of information from plugged in disks, I began thinking of providing a set of services. Those relying on ESXi 5.5's integrated tools. And so pi-control project was born.
To be installed on an always-on device (Raspberry-pi like), pi-control can be used to monitor hypervisor state and perform basic actions. All detailed in API: https://github.com/djey47/pi-control/wiki/API-reference
- hypervisor ON/OFF switch + schedule + status
- virtual machine list
- virtual machine ON/OFF switch + status
- hard disk list
- SMART details of particular disk(s)
- global logging to watch all received service requests ('big brother').
pi-control only requires ruby interpreter and a few common tools to be installed onto Raspberry-pi located on same network as hypervisor.
Technically, it accesses ESXi system through ssh to invoke well known tools as esxcli or vim-cmd and throw results back as JSON.
JSON gives a convenient way to use those results in a higher level application (script, webapp, ...)
You can find latest release hosted on Github: https://github.com/djey47/pi-control/tr ... er/release
(select current release archive then click View Raw link to start downloading).
New! First docker images are available.
pi-control images do not support all features for now: e.g ESXi ON
- pi-control (for rPi) : https://github.com/djey47/pi-control/wi ... install%3F (instructions) and https://hub.docker.com/r/djey/pi-control-raspbian/ (hub)
- pi-control (for x64) : https://github.com/djey47/pi-control/wi ... install%3F (instructions) and https://hub.docker.com/r/djey/pi-control-linux-x64/ (hub)
- smartX (for rPi): https://github.com/djey47/smartX/wiki/Installing (instructions) and https://hub.docker.com/r/djey/smartx-raspbian/ (hub)
- smartX (for x64): https://github.com/djey47/smartX/wiki/Installing (instructions) and https://hub.docker.com/r/djey/smartx-linux-x64/ (hub)
Most of the information is there: https://github.com/djey47/pi-control/wiki. So, enjoy
- hypervisor ON/OFF switch + schedule + status
-
Important Update : for your information, I just released following apps:
-
pi-control : a ruby app which exposes REST services to manage ESXi server and get SMART data : https://github.com/djey47/pi-control
- smartX : a webapp displaying disks and SMART information : https://github.com/djey47/smartX
pi-control is required to get SMART data, you only need to install smartX to easily watch storage state.
Dedicated thread here: viewtopic.php?f=2&t=4475
Feedback is welcome
-
pi-control : a ruby app which exposes REST services to manage ESXi server and get SMART data : https://github.com/djey47/pi-control
-
For those interested in project, still:
I've almost finished with a stable version of smartX webapp.
https://github.com/djey47/smartX
Release 1 will be available soon, in the meantime it can be installed manually by following instructions in README.md
Here are screens of what can be achieved with ESXI smart data fetched by pi-control module:
-
-sry for double post -
-
Sorry for late reply, I did not get notifications about it
I wasn't able to suppress them. Anyone ?2 questions pleaseIs there any way to disable error message in xpenology saying there's a problem with the temperature ?
Pi-Control is a lightweight script-based application, which does not rely on system libraries directly. You don't need to format your system to install it.To install pi-control on a raspberry pi, should it be clean installed ? I mean, I've already have a pi with openelec/xbmc, can I perform the install without problem ? and with future updates (openelec for example) will it still be ok ?thanks
As long as your updates don't break ruby script engine and SSH client it will be ok. At mine, I'm used to fetching git repository to /home/.../git/pi-control, and then I copy all files onto /media/.../pi-control (sdcard partition) to run them afterwards.
Jeedom / DOCKER / frequence 868
in Archives
Posted
Bonjour,
à mon avis, un conteneur Docker ne pourra pas accéder à une clé USB branchée sur le serveur. Docker ne gère que des flux réseau ou des volumes disques partagés, il n'accède pas nativement au matériel.
Ce n'est pas le même principe / but qu'une machine virtuelle.