filippo333

So, does your system automatically turn off and on?

Is anyone able to test auto-power on? Since the latest update, this feature is no longer working for me. Shutting down automatically however still does work fine.

Question: Why on earth would you want a second system to manage docker containers when there's a perfectly good one built into DSM?

Works fine on my config! Only after the latest VMM update (2.3.4-9027). Before this Windows would BSOD in a loop upon booting up the VM, Linux also kernel panic'd. I've not tested Linux yet but Windows 10 1809 installs and runs perfectly.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.1-23824 Update 2 - Loader version and model: Jun's Loader v1.04b - DS918+ - Using custom extra.lzma: NO - Installation type: BAREMETAL - Intel i3 6100

Currently using the DS918+ loader (was previously using the DS3615xs on my i3 baremetal) and so far it's a mixed bag. Windows 10 1809 installs fine, whereas Ubuntu and Xubuntu boot but won't install. I can see and format the disks without a problem, but as soon as I get to the disk selection step of the installer, the setup window goes into an infinite loading screen. It doesn't matter if I switch the disk mode from VirtIO to SATA or IDE the result is the same. CentOS has it the worst, using the minimal installation ISO I get a kernel panic and there is no way around it that I was able to see. The official compatibility list is quite out of date, I did try a certified build of CentOS but get the same problem. VMM might be putting some incompatible instruction in the Qemu VM config or maybe it's just really broken (which I find hard to believe). I'm lead to believe that this is the case as in my previous post I mentioned that enabling CPU compatibility mode with VMM Pro resolved the issue whilst on my DS3615xs loader (in which VMM was even more broken than it is on the loader I'm currently using )

Thanks again dude!

Is there a DS918+ loader version of the DSM 6.2? For previous loader releases this was an option.

Does changing model require a re-import of your data? It's possible VMM is fine tuned for the CPUs it's designed for. This is likely why people running as a DS3615xs and DS3617xs have no issues with VMM on enterprise Xeon hardware (as far as I know).

Update: After enabling Core 2 Duo CPU compatibility for the VM (only available with the pro version of VMM) it works perfectly. Unfortunately this isn't an option for most people (me included) as it requires a valid S/N and MAC combo to obtain a trial and or purchase a VMM pro license for $130. Maybe there's some way to force this instruction set in the hyper-visor without a license?

Yeah I'm getting the exact same thing, Windows also gives me a "kmode exception not handled" BSOD. It seems like some sort of Synology kernel incompatibility. Though the odd thing is the beta didn't have this problem when I was first testing it out on my bare-metal NAS.

Does anyone know if the drivers on the bootable medium override any drivers Synology might update?

Agreed, it's worth pointing out that the DS3615xs is based off the regular consumer i3 architecture whereas the DS3617xs is Xeon based. Obviously if you're not using a Xeon of that generation then it's recommended not to use that specific config.

Yeah I have the exact same problem when running the loader from VMware Workstation 12. No network or disk activity whatsoever, not tested on baremetal hardware myself.

Can you please define not working? It's not helpful to developers when people aren't verbose