OpenMediaVault 7 on a Dell R620: The Complete Build, and Why I Moved On

The Dell PowerEdge R620 sits at the back of my lab rack doing one thing: storage. Twelve drive bays, a flashed-to-IT-mode PERC H310, and ten 1 TB SAS spinners make it a solid NAS candidate. OpenMediaVault (OMV) is my NAS OS of choice — Debian under the hood, web UI on top, no licensing fees, and a plugin ecosystem that covers everything from ZFS to Docker.

This is Part 1: the base installation. Part 2 will cover performance tuning, SMART monitoring, SMB/NFS shares, and Docker via the OMV-Extras plugin.

Lab Hardware

What You’ll Need

• OpenMediaVault 7.x ISO — download from openmediavault.org
• USB drive (4 GB+) or iDRAC virtual media
• Rufus (Windows) or dd / balenaEtcher (Linux/Mac) to write the ISO
• Network cable connected to one of the 1GbE RJ45 ports (use the I350 ports for initial setup)
• A dedicated OS disk — I’m using the BOSS card M.2 SATA, keeping all SAS bays free for data

Step 1 — Write the Installation Media

On Windows with Rufus: select the OMV ISO, partition scheme MBR, target system BIOS (or UEFI if your R620 firmware supports it — the R620 does support UEFI boot). Write in DD Image mode when prompted.

On Linux:

Step 2 — BIOS & Boot Configuration

On the R620, enter System Setup (F2 at POST) and configure:

• Boot Mode: UEFI or BIOS — either works. I use BIOS legacy for compatibility.
• Boot Sequence: Move USB / virtual media to the top, or use the one-time boot menu (F11) for the install.
• SATA Mode: If using the BOSS card, ensure the internal M.2 slot is enabled under Integrated Devices → SATA Settings.
• Secure Boot: Disable it. OMV’s installer won’t fight you but it’s one less variable.

Step 3 — Install OpenMediaVault

Boot from the USB or virtual media. You’ll get the OMV GRUB menu — select Install (not graphical install, they’re functionally identical but the text installer is faster on server hardware).

Select your language, country, and keyboard layout. These only affect the installer display — OMV itself is always en-US in the web UI.

The installer will detect your NICs. On the R620 with the Intel X520 + I350 NDC, the I350 1GbE ports (typically em1 / em2 in older kernels, or eno1 / eno2 in newer ones) show up first. Pick one, let it DHCP, or enter a static IP. You can change this later in the web UI — just make sure you can reach the box post-install.

Set a hostname. I use r620-nas. Keep it short, no dots.

Set a strong root password. This is for SSH and the console — the OMV web UI uses a separate admin account.

This is critical. The installer shows all available disks. Select your BOSS card M.2 — it typically appears as /dev/sda if it’s the first SATA device. Do not select any of your data SAS drives. Double-check the size — the BOSS card M.2 will be smaller (typically 240 GB or 480 GB) versus the 1 TB SAS spinners.

Select a Debian mirror close to your region. This pulls the base packages during install. The UK mirror (ftp.uk.debian.org) or Cloudflare (deb.debian.org) both work well.

Install GRUB to the BOSS card (/dev/sda or whichever disk you selected for the OS). Confirm and let the installer finish.

Step 4 — First Boot

Remove the USB once the installer reboots. OMV will boot from the BOSS card. You’ll land at a login prompt with the server’s IP address displayed — this is what you need for the web UI.

If the IP isn’t displayed or you need to check:

Step 5 — Access the Web UI

From any machine on the same network, open a browser and go to:

Default credentials:

• Username: admin
• Password: openmediavault

Change the admin password immediately — go to User Management → Users → admin → Edit and set a new one.

Step 6 — System Updates

Before doing anything else, update the system. In the web UI: System → Update Management → Updates, then click Check and install all pending updates. Or from the command line:

Reboot after updates if the kernel was updated:

Step 7 — Verify Your Drives Are Visible

Go to Storage → Disks. With the PERC H310 in IT Mode, you should see all 10 SAS drives listed as individual disks (/dev/sdb through /dev/sdk or similar), not as a single RAID volume. If you only see one large virtual disk, the HBA is still in RAID mode.

Part 1 got OMV installed and running on the R620. This part covers everything that turns it into a high-performance ZFS storage server feeding ESXi over a 20Gbps LACP bond — kernel replacement, network config, ZFS pool creation, NFS export, and ongoing monitoring.

The R620 has 384 GB of DDR3 — most of that becomes ZFS ARC (RAM cache). With 10 SAS drives in 5 mirrored pairs and sync writes disabled, this box absorbs VM write spikes almost entirely in memory.

Phase 2 — Kernel Preparation and ZFS

Step 2.1 — Enable OMV-Extras

ZFS and kernel management are community features outside the default OMV repo. SSH in as root and run:

Step 2.2 — Install the Kernel Management Plugin

In the OMV Web GUI, go to System → Plugins, search for kernel, and install openmediavault-kernel. Wait for the terminal window to confirm completion.

Step 2.3 — Install the Proxmox PVE Kernel

1. Go to System → Kernel.
2. Click the Proxmox “P” icon (Install Proxmox Kernel) in the toolbar.
3. Select version 6.17 (or the latest -pve listed) and click Install. Do not close the window until it finishes.

Step 2.4 — Set Default Kernel and Reboot

1. In System → Kernel, find the -pve entry and click the checkmark icon to set it as default.
2. Reboot from the power menu top-right.

Step 2.5 — Verify and Install ZFS Plugin

1. After reboot, confirm the -pve kernel has a checkmark in the Running column.
2. Go to System → Plugins, search zfs, install openmediavault-zfs.
3. Hard-refresh (Ctrl+F5) — a ZFS menu should now appear under Storage.

Phase 3 — Network and 10Gb Optimization

Step 3.1 — Create the LACP Bond

1. Go to Network → Interfaces → Create → Bond.
2. Name: bond0. Slaves: eno1 and eno2 (the 10GbE X520 ports).
3. Mode: IEEE 802.3ad LACP. Transmit hash policy: layer2+3. MTU: 9000.
4. IPv4: Disabled. Save and Apply.

Step 3.2 — Create the VLAN xx Interface

1. Create → VLAN. Parent: bond0. VLAN ID: 48. MTU: 9000.
2. IPv4 Static: x.x.x.100 / x.x.x.x. Leave gateway and DNS blank.
3. Save and Apply.

Step 3.3 — Force LACP Fast Rate

OMV defaults to slow mode (30s heartbeats). Force 1-second heartbeats to match the MikroTik:

Step 3.4 — Persist LACP Fast Rate Across Reboots

Automate it via System → Scheduled Tasks → Create. Set execution to At reboot, user root, command:

Phase 4 — ZFS Pool and Performance Tuning

Step 4.1 — Clear Old RAID Metadata

Step 4.2 — Create the Pool

Step 4.3 — Performance Tuning

Step 4.4 — Increase the Dirty Data Write Buffer to 16 GB

Add:

Then regenerate initramfs:

Step 4.5 — Register the Pool in OMV

1. Storage → ZFS → Pools — Import esxi_datastore.
2. Under the Datasets tab, create a filesystem named esxi_dataset. Save and Apply.
3. Storage → File Systems — mount /esxi_datastore/esxi_dataset. Save and Apply.

Phase 5 — NFS to ESXi

Step 5.1 — Create the Shared Folder

Go to Storage → Shared Folders → Create. Name: Datastore_NFS. File System: esxi_datastore/esxi_dataset. Relative Path: /. Save and Apply.

Step 5.2 — Configure the NFS Export

1. Go to Services → NFS → Shares → Create.
2. Shared folder: Datastore_NFS. Client: x.x.0.0/16.
3. Extra options: rw,no_root_squash,no_subtree_check,insecure
4. Save and Apply.

Step 5.3 — ESXi Storage Network

1. In ESXi, go to Networking → VMkernel adapters → Add VMkernel adapter.
2. Port group: your 10GbE SFP+ port group. VLAN ID: 48. MTU: 9000.
3. IPv4 Static: x.x.x.10 / x.x.x.x. Leave gateway blank.

Step 5.4 — Mount the NFS Datastore in ESXi

1. Storage → New Datastore → Mount NFS datastore.
2. Name: OMV_ZFS_DATASTORE. NFS Server: x.x.x.100.
3. NFS Share: /export/Datastore_NFS. NFS Version: NFS 3. Click Finish.

Monitoring and Maintenance

ZFS Health and Monthly Scrubs

Schedule scrubs in OMV under Storage → ZFS → Pools → Scrub Schedule.

ARC Cache Statistics

Bond and Network Health

UPS Integration

Because sync=disabled keeps writes in RAM, a hard power cut loses that buffer. Install openmediavault-nut and configure it under Services → UPS to shut down gracefully on low battery.

Performance Troubleshooting

1. Jumbo frames broken? Run vmkping -d -s 8972 x.x.x.100 from ESXi. Failure means a switch port reverted to MTU 1500.
2. Pool too full? ZFS drops performance above 80% used. Check with zpool list.
3. Dirty data limit active? Run cat /sys/module/zfs/parameters/zfs_dirty_data_max — should return 17179869184.

Parts 1 and 2 covered getting OMV installed and configuring ZFS, networking, and the NFS datastore for ESXi. This part is about making the OMV dashboard useful — setting up the right monitoring widgets, tracking ZFS pool health, and adding proper performance visibility beyond what the built-in dashboard provides.

1. Enable Dashboard Widgets

When you first log into OMV 7, the dashboard loads empty. Nothing is shown until you explicitly select what you want to monitor. OMV 7 stores widget preferences server-side (unlike OMV 6 which used browser local storage), so your layout stays consistent across any device you log in from.

1. Log into the OMV web interface as admin.
2. Click the Settings (gear icon) in the upper-right corner of the dashboard.
3. A checklist of available widgets appears. Enable what you need:

• S.M.A.R.T. Status — drive health and temperature across all physical disks. Enable this first. You want early warning if a SAS drive in your ZFS mirror is running hot or throwing errors.
• Filesystem — used and available capacity across mounted filesystems.
• Network Interfaces — current status and IP for each interface, including your LACP bond and VLAN xx.
• System Information — CPU and memory overview. With 384 GB of RAM, this is useful for watching how much ZFS ARC has claimed.

Click Save. The dashboard reloads with your selected widgets active.

2. ZFS Pool Health Monitoring

ZFS pools don’t appear in the standard Filesystem widget the way a normal ext4 or XFS mount would. For pool-level visibility, use the ZFS plugin menu:

1. Go to Storage → ZFS → Pools.
2. Highlight esxi_datastore and click Tools → Details.

This shows every VDEV and drive in the pool — each mirror pair and individual disk listed as ONLINE, DEGRADED, or FAULTED, along with read, write, and checksum error counts. Any non-zero checksum errors on a drive are worth investigating.

You can also check from the terminal at any time:

3. S.M.A.R.T. Drive Monitoring

If the S.M.A.R.T. widget shows “Unknown” for any drive, monitoring hasn’t been enabled for that disk yet:

1. Go to Storage → S.M.A.R.T. → Devices.
2. Select each drive, click Edit, check Enable monitoring, Save and Apply.

Do this for all 10 SAS drives. SAS drives under continuous load accumulate reallocated sectors and seek errors over time — S.M.A.R.T. is your early warning before a mirror member fails silently.

You can also query SMART status directly from the terminal:

4. Advanced Performance Monitoring

The built-in dashboard gives you current state but no historical throughput, IOPS trends, or temperature graphs over time. For a storage server feeding ESXi VMs, you want more than that.

For this R620 setup, Netdata is the right choice. It has native ZFS support — reads /proc/spl/kstat/zfs/ directly and surfaces ARC hit rate, cache size, and pool I/O without any manual configuration.

5. Built-in Diagnostics

Even without a third-party tool, two areas in OMV’s Diagnostics section are worth checking regularly:

• Diagnostics → Statistics — RRD graphs for CPU, memory, disk throughput, and network per interface. Not real-time, but shows trends over hours and days.
• Diagnostics → System Logs — consolidated view of syslog, auth.log, and service logs. If ZFS throws a checksum error or the bond drops a link, it appears here.

To watch live for bond or LACP events from the terminal:

OMV updates are mostly painless, but a handful of our performance settings live outside the normal config system — they’re applied at runtime, not persisted natively by OMV. The LACP fast rate and the ZFS dirty data limit both fall into this category. After a kernel update or unattended reboot, you need a quick way to confirm everything is still running as expected. This part is that checklist.

Phase 1 — Quick Terminal Verification

Five commands, five targets. If all five pass, the system is running at full performance. SSH in as root and run them in order:

1. Kernel Check

If the result doesn’t contain -pve, go back to System → Kernel in the OMV GUI, select the PVE kernel, set it as default, and reboot.

2. LACP Rate

3. ZFS Write Buffer

4. Pool Health

5. NFS Export

If the export is missing, go to Services → NFS in the OMV GUI and click Apply to re-export the share.

Phase 2 — Restoring Settings if They Reverted

Force LACP Fast Rate

If the bond shows LACP rate: slow, the scheduled task either didn’t run or the sleep delay wasn’t long enough for the bond to initialise before the rate was set. Restore it manually:

Then verify:

Restore 16 GB Dirty Data Limit

If the result was 4294967296 (4 GB default), restore it immediately — large VM write spikes will hit the SAS disks instead of staying in RAM:

Phase 3 — Ensuring Persistence via Scheduled Tasks

Both the LACP fast rate and the dirty data limit are runtime kernel parameters — they reset on every reboot. The scheduled tasks we set up earlier handle this, but verify they’re still configured in System → Scheduled Tasks:

Task 1 — LACP Fast Rate

• Execution: At reboot
• User: root
• Command:

Task 2 — ZFS Write Performance

• Execution: At reboot
• User: root
• Command:

Phase 4 — Emergency Access via omv-firstaid

After a major OMV update, the web UI occasionally becomes inaccessible — login loops, “Access Denied” errors, or a blank page. This happens when the update changes internal session tokens or database schemas without clearing old state. The fix is omv-firstaid:

1. SSH into the R620 as root.
2. Run:

A menu appears. The two useful options here:

• Option 4 — Reset failed login counter: Clears any account lockouts from repeated failed attempts.
• Option 3 — Change Workbench administrator password: Use this if the admin credentials are no longer accepted after an update.

Final Health Indicator — ARC Hit Rate

Once everything checks out, look at the dashboard. The ZFS Hits/Misses widget is your single best indicator of whether the system is performing as intended:

• Hit rate near 100% — VMs are running almost entirely from the 384 GB RAM cache. Disk I/O is minimal. This is the target state.
• Misses increasing — the ARC is not serving the data and is falling back to the SAS drives. Common causes: pool is over 80% full, a VM workload has a working set larger than available ARC, or the ARC size was artificially capped.

Check live ARC stats at any time:

Running ZFS on OMV 7 requires the Proxmox VE kernel. The problem is that Debian does not know that. A routine apt upgrade will happily pull in a stock Debian kernel, and after the next reboot your ZFS pools fail to import. This post covers how to lock the system so that cannot happen.

Step 1 — Block Recommended and Suggested Packages

By default, Debian installs optional packages that are not strictly required — including extra kernels pulled in as recommendations. Disabling this globally means apt only installs what you explicitly request.

Create a new apt configuration file:

Paste these two lines:

Save and exit with Ctrl+O, Enter, Ctrl+X. This stops apt from silently dragging in packages — including backport kernels that arrive as recommendations alongside other packages.

Step 2 — Pin the Proxmox Kernel and Block the Debian Meta-Package

OMV often enables the Debian Backports repository, which is where unwanted kernels (like broken 7.0.7 builds) can come from. Use apt pinning to give Proxmox packages the highest priority and explicitly ban the standard Debian kernel meta-packages.

Create a package preferences file:

Paste this configuration block:

What each block does:

• Priority 1001 on proxmox-kernel* — exceeds the maximum normal apt priority (1000), so the PVE kernel always wins even if a newer Debian version exists.
• Priority -1 on linux-image-amd64 — a negative priority explicitly bans the package. apt will refuse to install or reinstall it automatically.

Step 3 — Verify the Pin is Active

Check that apt sees the correct priorities before rebooting:

If the Debian kernel still shows as installable, check the file syntax and run sudo apt update to refresh the policy cache.

Step 4 — Hold the Currently Running Kernel

As an extra safety net, hold the specific PVE kernel version you are running right now so it cannot be removed by the dependency resolver:

Final Dry-Run Check

Run a full update dry-run to confirm nothing unexpected is queued:

The output should show no kernel packages being changed. If you see linux-image-* in the list, the pin file has not taken effect. Once the dry-run looks clean, apply the updates and reboot. Then verify: