That’s easy - run it in VM
Or in another words - you can’t make Docker version Supervised.
And for anyone posting Docker version is available - what about hass.io package now?
Nothing - there is a list of requirements (I think 5 or 6 of them) - you need to have all prerequisites according to the list. Just having new version of Docker doesn’t change anything.
You would need to format disk, install new OS (not DSM) and then it could be Supervised (on bare metal). So running in VM on Synology is the only way to have it officially supported.
Thanks for confirmation. That is what i came out with my research, too: it can’t be done…
If i remember correctly @fredrike stopped developing his version of HA in Syno because Docker vas to old (among others). It was unofficiall, but at least it was supervised.
As i said before: i don’t mind running HA in VM, it works perfectly (so far…). I just wanted to explore a bit and see what options are.
When I start the VM, it runs through and gets to the homeassistant login: but then crashes with the following error(s):
[ 21.012206] udevd[205]: bind failed: Address in use
[ 21.012287] udevd[205]: error binding udev control socket
The IPs showing are 192.168.1.116 (DHCP) 172.17.0.1 (I think the default docker bridge network from the VM) and 172.30.32.1 (not sure). I know it’s meant to be on port 8123, and that port isn’t in use on my 920+ NAS.
…but also keep router forwarding port 443 to the Synology NAS and not the new VMM IP.
This is how I ended as well with a DS218+ after adding RAM. Initially following @BeardedConti’s great guide but went down a rabbit hole with DuckDNS thinking I needed to change it all over since its now a VM with a separate IP. But thanks to Pavel, found my way to this method with keeping the existing Synology DDNS (*.DSMyNAS.com) and SSL certificate. But one (of many) mistakes I made was in changing the 443 port forwarding rule of my router to also point to the new VM IP address instead of just keeping it forwarding to Synology NAS IP.
Although I still wouldn’t recommend upgrading to DSM 7.0 unless you really have a BIG reason to do so, tried today on my recording setup to see if I can get USB Zigbee devices working.
Testing is still not finished, but let me put down what I got so far:
I’m using DS415+ . officially not supporting VMM, so after DSM7 upgrade, had to remove package and install new version (for DSM 7) - used 2415+ VMM package for that (same CPU).
because of that, I had to import my VM storage, and everything was imported correctly, EXCEPT network - this had to be change by hand so VM could have network access
cc2531 (yes, cheapest Zigbee USB controller) is working. Synology doesn’t see or recognize it, but still you can select it from drop down list in VM Editor.
But some things to look for for ex. a lot of DDNS service provider have been removed - for ex. DNS-O-MATIC, so be careful if you were using providers that were removed.
EDIT: To add on this - using slae.sh CC2652RB stick - with VM. Without any additional drivers on Synology, it is correctly mapped to VM, and VM recognises it correctly.
HA Supervisor lists everything correctly, it can be added there in Zigbee2MQTT and all is working well.
EDIT 2: And CC2652P is also working in VM.
EDIT 3: When restarting Synology, assigned USB information is not lost. Some had issues with this - tested with one restart and stick name was still here after restart and selected.
EDIT 4: And video on this is out too (apologising for shameless self-promotion):
I guess that this no-support is inside DSM, while VM obviously scans USB deveices directly and thus it can see them…
EDIT: today i installed DSM 7 on my machine. All went well, works perfect, too. Before upgrade i suspended my VM with HA. After update i had to manually update Virtual manager, then i just ran HA and all is perfect.
I followed the how-to by the letter but end up with a install that eventually shows me a Preparing Home Assistant screen with the blinking blue dot and the information i have to wait 20 minutes.
Now i can wait 20 minutes or 20 hours, nothing changes.
did you try going directly to HA url - without landing page part of it? It can sometimes get stuck in that state.
Also, some just restarted VM and logged back in HA.
If i go to the console of the virtual machine i do see the proper HA console which states on which url i find the supervisor and observer but im stil stuck with the spinning blue log dot on the Preparing screen.
What i havent tried yet is rebooting the VMM to see if that helpds. Be right back.
nope. Even after several reboots. I wont go passed the preparing screen.
– This is the end of the log file you get when you click on the blue dot
[s6-init] making user provided files available at /var/run/s6/etc…exited 0.
[s6-init] ensuring user provided files have correct perms…exited 0.
[fix-attrs.d] applying ownership & permissions fixes…
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts…
[cont-init.d] udev.sh: executing…
[12:12:57] INFO: Using udev information from host
[cont-init.d] udev.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[12:12:57] INFO: Starting local supervisor watchdog…
21-07-16 12:12:58 INFO (MainThread) [main] Initializing Supervisor setup
21-07-16 12:12:58 INFO (MainThread) [supervisor.bootstrap] Initializing Supervisor Sentry
21-07-16 14:12:58 INFO (MainThread) [supervisor.bootstrap] Seting up coresys for machine: qemux86-64
21-07-16 14:12:59 INFO (SyncWorker_0) [supervisor.docker.supervisor] Attaching to Supervisor homeassistant/amd64-hassio-supervisor with version 2021.06.8
21-07-16 14:12:59 INFO (SyncWorker_0) [supervisor.docker.supervisor] Connecting Supervisor to hassio-network
21-07-16 14:13:06 INFO (SyncWorker_0) [supervisor.docker.interface] Cleanup images: [‘homeassistant/amd64-hassio-supervisor:2021.06.3’]
21-07-16 14:13:08 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.INITIALIZE
21-07-16 14:13:08 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
21-07-16 14:13:08 INFO (MainThread) [main] Setting up Supervisor
21-07-16 14:13:09 INFO (MainThread) [supervisor.api] Starting API on 172.30.32.2
21-07-16 14:13:09 INFO (MainThread) [supervisor.hardware.monitor] Started Supervisor hardware monitor
21-07-16 14:13:10 INFO (MainThread) [supervisor.host.info] Updating local host information
21-07-16 14:13:10 INFO (MainThread) [supervisor.host.services] Updating service information
21-07-16 14:13:10 INFO (MainThread) [supervisor.host.network] Updating local network information
21-07-16 14:13:11 INFO (MainThread) [supervisor.host.sound] Updating PulseAudio information
21-07-16 14:13:11 INFO (MainThread) [supervisor.host] Host information reload completed
21-07-16 14:13:11 INFO (MainThread) [supervisor.host.apparmor] Loading AppArmor Profiles: {‘hassio-supervisor’}
21-07-16 14:13:11 INFO (MainThread) [supervisor.host.services] Reloading local service hassos-apparmor.service
21-07-16 14:13:11 INFO (SyncWorker_0) [supervisor.docker.interface] Attaching to homeassistant/amd64-hassio-dns with version 2021.06.0
21-07-16 14:13:12 INFO (MainThread) [supervisor.plugins.dns] Updated /etc/resolv.conf
21-07-16 14:13:12 INFO (SyncWorker_1) [supervisor.docker.interface] Attaching to homeassistant/amd64-hassio-audio with version 2021.04.0
21-07-16 14:13:13 INFO (SyncWorker_1) [supervisor.docker.interface] Attaching to homeassistant/amd64-hassio-cli with version 2021.05.1
21-07-16 14:13:14 INFO (SyncWorker_1) [supervisor.docker.interface] Attaching to homeassistant/amd64-hassio-observer with version 2021.06.0
21-07-16 14:13:17 INFO (SyncWorker_0) [supervisor.docker.interface] Attaching to homeassistant/amd64-hassio-multicast with version 2021.04.0
21-07-16 14:13:18 INFO (MainThread) [supervisor.updater] Fetching update data from https://version.home-assistant.io/stable.json
21-07-16 14:13:21 INFO (MainThread) [supervisor.homeassistant.secrets] Loaded 0 Home Assistant secrets
21-07-16 14:13:21 INFO (SyncWorker_1) [supervisor.docker.interface] Attaching to homeassistant/qemux86-64-homeassistant with version landingpage
21-07-16 14:13:23 INFO (MainThread) [supervisor.homeassistant.core] Starting HomeAssistant landingpage
21-07-16 14:13:23 INFO (MainThread) [supervisor.hassos] Detect Home Assistant Operating System 6.1 / BootSlot A
21-07-16 14:13:24 INFO (MainThread) [supervisor.store.git] Loading add-on /data/addons/git/a0d7b954 repository
21-07-16 14:13:24 INFO (MainThread) [supervisor.store.git] Loading add-on /data/addons/core repository
21-07-16 14:13:24 INFO (MainThread) [supervisor.store] Loading add-ons from store: 62 all - 62 new - 0 remove
21-07-16 14:13:24 INFO (MainThread) [supervisor.addons] Found 0 installed add-ons
21-07-16 14:13:24 INFO (MainThread) [supervisor.snapshots] Found 0 snapshot files
21-07-16 14:13:24 INFO (MainThread) [supervisor.discovery] Loaded 0 messages
21-07-16 14:13:24 INFO (MainThread) [supervisor.ingress] Loaded 0 ingress sessions
21-07-16 14:13:24 INFO (MainThread) [supervisor.resolution.check] Starting system checks with state CoreState.SETUP
21-07-16 14:13:24 INFO (MainThread) [supervisor.resolution.check] System checks complete
21-07-16 14:13:24 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.SETUP
21-07-16 14:13:24 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
21-07-16 14:13:24 INFO (MainThread) [supervisor.jobs] ‘ResolutionFixup.run_autofix’ blocked from execution, system is not running - CoreState.SETUP
21-07-16 14:13:24 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.SETUP
21-07-16 14:13:24 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
21-07-16 14:13:24 INFO (MainThread) [main] Running Supervisor
21-07-16 14:13:26 INFO (MainThread) [supervisor.hassos] Rauc: A - marked slot kernel.0 as good
21-07-16 14:13:26 INFO (MainThread) [supervisor.addons] Phase ‘AddonStartup.INITIALIZE’ starting 0 add-ons
21-07-16 14:13:26 INFO (MainThread) [supervisor.addons] Phase ‘AddonStartup.SYSTEM’ starting 0 add-ons
21-07-16 14:13:26 INFO (MainThread) [supervisor.addons] Phase ‘AddonStartup.SERVICES’ starting 0 add-ons
21-07-16 14:13:26 INFO (MainThread) [supervisor.core] Skiping start of Home Assistant
21-07-16 14:13:26 INFO (MainThread) [supervisor.addons] Phase ‘AddonStartup.APPLICATION’ starting 0 add-ons
21-07-16 14:13:27 INFO (MainThread) [supervisor.misc.tasks] All core tasks are scheduled
21-07-16 14:13:27 INFO (MainThread) [supervisor.core] Supervisor is up and running
21-07-16 14:13:27 INFO (MainThread) [supervisor.homeassistant.core] Home Assistant setup
21-07-16 14:13:27 INFO (MainThread) [supervisor.host.info] Updating local host information
21-07-16 14:13:27 INFO (SyncWorker_0) [supervisor.docker.interface] Updating image homeassistant/qemux86-64-homeassistant:landingpage to ghcr.io/home-assistant/qemux86-64-homeassistant:2021.7.3
21-07-16 14:13:27 INFO (SyncWorker_0) [supervisor.docker.interface] Downloading docker image ghcr.io/home-assistant/qemux86-64-homeassistant with tag 2021.7.3.
21-07-16 14:13:27 INFO (MainThread) [supervisor.resolution.check] Starting system checks with state CoreState.RUNNING
21-07-16 14:13:27 INFO (MainThread) [supervisor.resolution.checks.base] Run check for IssueType.PWNED/ContextType.ADDON
21-07-16 14:13:27 INFO (MainThread) [supervisor.resolution.checks.base] Run check for IssueType.FREE_SPACE/ContextType.SYSTEM
21-07-16 14:13:27 INFO (MainThread) [supervisor.resolution.module] Create new suggestion SuggestionType.CREATE_FULL_SNAPSHOT - ContextType.SYSTEM / None
21-07-16 14:13:27 INFO (MainThread) [supervisor.resolution.checks.base] Run check for IssueType.SECURITY/ContextType.CORE
21-07-16 14:13:27 INFO (MainThread) [supervisor.resolution.check] System checks complete
21-07-16 14:13:27 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.RUNNING
21-07-16 14:13:27 INFO (MainThread) [supervisor.host.services] Updating service information
21-07-16 14:13:28 INFO (MainThread) [supervisor.host.network] Updating local network information
21-07-16 14:13:29 INFO (MainThread) [supervisor.host.sound] Updating PulseAudio information
21-07-16 14:13:29 INFO (MainThread) [supervisor.host] Host information reload completed
21-07-16 14:13:31 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
21-07-16 14:13:31 INFO (MainThread) [supervisor.resolution.fixup] Starting system autofix at state CoreState.RUNNING
21-07-16 14:13:31 INFO (MainThread) [supervisor.resolution.fixup] System autofix complete
Seems stuck there in the autofix bit…
Would love to know if other Synology users with DSM7 on their device have the same problem. One of the Dutch Home Assistant facebook just confirmed the HA ova does work when imported as a virtual machine in DSM6.
Are you using URL to load it or IP address? Try using IP address you see in VMM for this machine - with port 8123 at the end.
It should load it.
This will eliminate any possible issues with reverse proxy, as it now requires some configuration steps to be able to use it in HA, not as before.
Thanks Beard. You wrote this and then i remembered the new install on docker also needed a proxy adjustment in the config file. I have now connected to the vmm install via IP and it is now working again. Many thanks!
Hi, looks some a lot of users here are getting this working so thought l’d try. I boot up the VM in VMM and can’t connect to the HA landing page. My VMM IP doesn’t show a 192.168 address, only a 172.xx.Xx.X one which I also can’t connect to. My router also only shows an ipv6 address and no ipv4 address for the “device”. I tried using nmcli con edit following a video from The Hookup Youtube channel on setting a static address in the cli but don’t really know what I’m doing and it doesn’t work. I’m on DSM 7, using haos_ova-6.2.ova on a ds720+, VM has 3GB RAM and 2 vcpu. Was really hoping to get this working. Thanks in advance.
Did you try using Connect from VMM to connect to console?
It should open new window and give you info about IP addresses and how to access it.
I have ipv6 disabled on my network, so can’t help you with that, but I did see that there were some issues with ipv6 before.
Hi, thanks for replying. Yes I was able to connect but no ipv4 is shown. In all the examples I see online, the VM showed a 192.168 adddress and the 172 address. Mine doesn’t show the 192.168 one.
In the terminal I can see the ha user and typed “login” to try to set an ipv4 but when I used nmcli con edit. The instructions were use HassOS default after the nmcli con edit and it didn’t recognize what HassOS default was.
I’ve tried using a virtual box VM on my PC in the past to do this and had to use this method to set the ipv4 and it worked. But things change so quick.
I can try to disable ipv6 and try again and see if it picks up an ipv4. Also on the home assistant installation page under the .ova instructions it says use e1001 network adapter type, but when I create the vswitch in VMM it gives an e1000 type and no option to change. But I don’t really know what that does. Something about multicast.
Check to see what BIOS/firmware is selected for VM - it should be UEFI.
In regard to network adapter, did you select external or private adapted? To add, you didn’t have to create new, you could have used existing/default one - it should work.
From what I’ve seen on forum, it looks like HA is trying to use ipv6 and just ignores ipv4.
Thanks for your help on this. I’m using UEFI, The vlan is using the LAN port in use and its external. I disabled ipv6 on my network but when I re-made the VM it picked up ipv6 on my router (eero) again and the VM is still not showing the 192.168.x.x IP.
Not sure if its safe to show ipv6s so I blanked part of it out…
Really at a loss, I had core running in docker but sounds like OS is way easier to handle for a beginner.
