I think the only way then is to share the disk on the 2016 server and mount it as a network drive in OMV.
I did almost exactly what you are trying to do when I was running tvheadend in a VM on a Windows PC and I wanted the recodrings to end up on the Windows PC and not inside the tvheadend VM.
There is a guide here: https://tvheadend.org/boards/4…598?r=35470#message-35470
Storage spaces kinda have the same problems. <snip>
I have used storage spaces for a long long time and it have never been slow - are you sure you have not done something to your computer? Like BOIS settings or something? True that "traditional spin-disks" are much slower than ssd's and others but storage spaces on its own have never been slow for me.
As far as recovering from a failty disk there are good guides out there and if you want to test what happends if (or when) something fails heres a simple way to play with it...
Ceate a VM and install whatever Windows version you are planning to run. Create some VHDX and attach those to the VM, create a storage space on them and add some data to it. Remove one of the VHDX files from the VM and see what happends.
If you want to emulate that the OS drive failed or the computer exploaded but the disks where okay, attach the storage space drives to another VM.
You can do the same with OMV or whatever OS you wanna run, or on whatever hypervisor - play with VM's - it's fun! 
Well now this may be somewhat complicated but will work...
On your Win10 host, create a storage space and store the data there. Mount that storage in OMV and you should be good (use automount in debian).
Or run OMV as the host and do whatever you want with disks and things, and run you VMs in OMV that runs your Windows.
Would that work?
For a home user with one node, adding that complexity is a VERY bad thing.
For anyone adding that complexity is a bad thing, keep things simple always, that's good.
Yes I know you can do very cool things with a lot of stuff, but I would NEVER recommend anyone to do it, ever.
I have for years played with Hyper-V (and other Virtualization technologies) in large and small environments along with Clusters SCVMM and other stuff, more and less complex environments and have come to this simple conclusion when it comes to attaching drives as physical devises, it may work but I would not recommend it.
The whole point of virtualization is that you should be able to move a VM from one host to another without doing anything to the VM. If you create a VM and attach specific physical things (like drives) from one specific host and that host fails you are toast. So no matter what virtualization technology you do use make sure that you don't do what you are trying to do.
I like you are running OMV on Hyper-V and this is how I run mine.
One VM and three disks (normal vhdxfiles of various sizes all dynamically expanding), OMV just for the OS 10GB, Docker 50GB, Media 1TB.
Make sure you set your network adapter to a static MAC address, when moving a VM without that settings things can get messed up.
When OMV is installed install "the drivers" for Hyper-V: apt install hyperv-daemons
Thats about all.
Now for redundancy... IF you want your OMV to be placed on redundant drives you have a couple of options.
On your host you can make the drives redundant and then place the vhdx files on those drives.
If you create vhdx files on separate physical drives on the host you can have OMV use all those files and use those for some form of duplication/raid.
If you have more than one host you can use Hyper-V replication between the hosts.
I opted for none of those solutions.
For simplicity I don't have anything like that, I just export my OMV one a week to a different drive so that if anything failes I have a full copy of the whole VM on my Hyper-V host. If my house burns down I have a copy of that drive at a friends house, just a simple FTP site I access using VPN.
So in my case if my hardware failes, all I have to get is another hardware with enough space to run my VM and I'm good to go. That is far simpler than anything I have ever tried before.
I have two docker containers for this.
I use Emby for my mediafiles, locally and remotely.
Access to Emby from outside home is done trough a SWAG container (nginx reverse proxy with some bells and whistles).
So in Kodi at remote locations I just install Emby for Kodi and I'm all good.
But...maybe VPN might be simpler.
If your dad is on a Windows client you could setup a VPN profile that automatically connects as soon as the client starts and add the client to start always - so your dad needs to do nothing but use the files.
Hello - beginner here - have I done this right?
Everything works as expected but I'm not sure I have done this right?
I have multiple gateways on my network, today my clients that uses another gateway than the default uses static ip settings and that gets cumbersome to maintain.
My ASUS routers DHCP server does not allow the option to set different gateways on static leases...
Enter OMV and Docker.
So I created a stack in portainer like this for ISC DHCP server
---
version: "2.1"
services:
dhcpd:
image: networkboot/dhcpd
container_name: dhcpd
network_mode: host
environment:
- PUID=123
- PGID=456
- TZ=Europe/Stockholm
volumes:
- /srv/dev-disk-by-uuid-bla-bla-bla/config/dhcpd:/data
restart: always
I then created the definitionfile for it here /srv/dev-disk-by-uuid-bla-bla-bla/config/dhcpd/dhcpd.conf
With this content:
# option definitions common to all supported networks...
option domain-name "workgroup";
option domain-name-servers 192.168.1.199;
default-lease-time 432000;
max-lease-time 432001;
authoritative;
ddns-update-style none;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.189;
option subnet-mask 255.255.255.0;
option routers 192.168.1.1;
option broadcast-address 192.168.1.255;
}
host Static-IP-Sample {
hardware ethernet 00:01:02:03:04:05;
fixed-address 192.168.1.99;
option routers 192.168.1.254;
}
# EOF
I created a scheduled job in omv that runs weekly that runs the command: omv-update
Been like this for a while now with no issues.
I also run watchtower weekly to update my containers and that have been working just fine.
I think lots of ppl are overthinking how to update and when, keep it simple and you will do just fine.
Make sure you align a backup/restore strategy that that work in tandem with you updates so that IF something really bad happens there is a way out. Like I do a full backup of everything Monday night and let updates run Tuesday morning.
Thank you good sirs!
"standard system update"
is that what gets listed under update management or do I have to do something more?
I'm on OMV5 ...
If you get it to fly, please please please write up something for us dummies to follow 
