Posts by fredfred

    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.