26 years after its release, Windows 2000 Professional still has a place in testing, legacy support, and retro-computing labs — but building a VM for it by hand, every single time, gets old fast. In my latest video, “HOWTO VirtualBox: How to Automate the Creation of an Appliance File,” I walk through a PowerShell script that does the whole job unattended: create the VM, install Windows 2000 Pro with zero clicking through Setup, power it off automatically, and export the finished appliance as a portable .ova file.
Here’s the write-up, including a couple of the gotchas that tripped the script up along the way.
Why Automate This?
A VirtualBox appliance file (.ova) packages a fully configured VM — OS, disk, settings, all of it — into a single portable file you can import anywhere. Building one by hand through the GUI is fine once. Needing a fresh Windows 2000 Pro VM repeatedly for a lab or test environment is a different story, and that’s where scripting the whole pipeline with VBoxManage.exe through PowerShell pays off.
The Twist With Windows 2000
Windows 2000 predates the autounattend.xml mechanism that later Windows versions use, so the assumption going in was that VBoxManage unattended install — the built-in facility that auto-generates a Windows answer file — wouldn’t support it, and that a hand-built winnt.sif + floppy would be needed instead.
Turns out that’s not the case. VBoxManage unattended install does support Windows 2000 — it builds its own answer file, auxiliary ISO, and floppy internally, no manual winnt.sif or floppy-writing tool required. That’s the route this script uses.
What the Script Does
At a high level, Deploy-Win2kProVM.ps1 handles the whole pipeline in one run:
Prompts for a VM name and cleans up any existing VM with that name.
Creates a new VirtualBox VM (Windows2000 guest type, PIIX4 IDE controller, 1 CPU — matches what this OS actually needs).
Creates and attaches a virtual hard disk.
Kicks off VBoxManage unattended install pointed at a standard Windows 2000 Pro install ISO — VBoxManage handles the answer file, auxiliary ISO, and floppy itself, and installs Guest Additions in the same pass.
Polls the VM’s state until it powers itself off.
Exports the finished VM to a .ova appliance file.
The full script is available on GitHub: [link to your GitHub repo]
Gotchas Worth Knowing About Before You Run This
A few things that came up while getting this working, in case they save you the same troubleshooting:
Flag names for unattended install are strict and easy to get wrong. It’s --key, not --product-key. It’s --user-password (or --admin-password, depending on the account type), not --password. VBoxManage errors out immediately with an “Unknown option” message if you get these wrong — worth double-checking against VBoxManage unattended install --help for your installed version.
Windows 2000 needs 1 CPU and --ioapic off. This matches a manually-built VM confirmed to install and boot reliably — modern virtual chipset defaults can trip up an OS this old.
Setup won’t shut down on its own. Without a shutdown command, the VM finishes install and just sits at the desktop, so the polling loop in the script would wait forever. The fix is VBoxManage’s own --post-install-command="shutdown -s -t 0" flag, which runs inside the guest automatically once Setup completes (via the Guest Additions execution channel — hence --install-additions needs to run first).
Downloaded scripts get blocked by Windows. If you see “not digitally signed” when running the .ps1 file, it’s the Mark of the Web from a browser download. Fix it with:
powershell
Unblock-File -Path '.\Deploy-Win2kProVM.ps1'
A genuine product key is required. There’s no way around supplying a real one in the unattended install parameters.
What You End Up With
Run the script, type a VM name, and walk away — no manual clicking through Setup, no hand-built floppy images. A few minutes later, you’ve got a fully installed, Guest-Additions-equipped Windows 2000 Professional VM exported as a ready-to-share .ova.
That exported file also becomes a reusable template — importing it for a fresh copy is far faster than rerunning the whole install.
Watch the Full Video
This post covers the highlights, but the video walks through the whole process live — including the actual errors we hit and fixed along the way. Check it out here: https://youtu.be/Nz2vhgU01qM
If you’ve automated your own VirtualBox workflows, I’d love to hear how — drop a comment on the video or below!
Lets start this by saying….As a “HiFi snob”! With lots of audio equipment!Apart from the obvious difference — one has a black spine and the other has a clear spine — what’s the difference between these two compact discs?That was the question that started this little investigation.At first glance, both CDs contain the same Fleetwood Mac album. One is an early West German Target CD and the other is the 2004 remastered and expanded edition.But are the original album tracks actually the same?Does the 2004 version simply contain the same digital master at a higher volume?Or did the mastering change?I decided to find out.
The Two CDs
The 1994 West German Target CD
The first CD is the West German Target pressing.
The most immediately noticeable feature is the black spine, along with the distinctive Target-style disc design associated with these early CD releases.
The disc contains the original 11-track album:
Monday Morning
Warm Ways
Blue Letter
Rhiannon
Over My Head
Crystal
Say You Love Me
Landslide
World Turning
Sugar Daddy
I’m So Afraid
The disc was manufactured in West Germany and is one of the early Target-style compact discs associated with the original CD era.
There is something rather special about these early Target CDs. They belong to the first generation of commercially produced CDs and have become collectible in their own right.
But I wasn’t interested in the Target CD simply because it looks good.
I wanted to know how it sounds.
The 2004 Edition
The second disc is the 2004 remastered and expanded edition.
And immediately there is another obvious physical difference.
The spine is clear rather than black.
But the differences go much further than that.
The 2004 edition contains 16 tracks, rather than the original 11.
The five additional recordings are:
Jam, No. 2
Say You Love Me
Rhiannon (Will You Ever Win)
Over My Head
Blue Letter
So before we even listen to the two CDs, we already know that the 2004 edition is more than a simple reissue.
It is an expanded and remastered edition.
But what happened to the original 11 tracks?
Let’s Rip the CDs
Rather than relying on my ears alone, I wanted to make this as objective as possible.
Both CDs were ripped using Exact Audio Copy (EAC), using secure extraction, and saved as lossless FLAC files.
The EAC results were then checked against AccurateRip and the CUETools Database.
The results were excellent.
1994 West German Target
All 11 tracks were reported as accurately ripped.
No errors occurred.
2004 Edition
All 16 tracks were also reported as accurately ripped.
No errors occurred.
The 2004 tracks had an AccurateRip confidence of 200, providing extremely strong confirmation of the extraction.
This means we weren’t comparing two recordings made from a CD player.
We were comparing the actual digital audio data extracted from the CDs.
The First Track: Monday Morning
I started with the opening track, Monday Morning.
And this is where things immediately became interesting.
The 1994 CD has a peak level of approximately:
-2.47 dBFS
The 2004 version reaches:
-0.10 dBFS
So the 2004 version is getting extremely close to digital full scale.
But peak level alone doesn’t tell the whole story.
The average level is even more revealing.
The 1994 version measures approximately –20.6 dBFS RMS.
The 2004 version measures approximately –13.2 dBFS RMS.
That’s roughly a 7.3 dB increase in average level.
In simple terms, the 2004 version is substantially louder.
But I wanted to know whether that was the whole story.
Is the 2004 Version Simply Louder?
This was the obvious question.
If the 2004 CD was simply the 1994 mastering with the volume turned up, reducing the 2004 version by the appropriate amount should make the two recordings essentially identical.
It doesn’t.
I level-matched the two versions, removing the large difference in overall volume, and then compared them again.
There were still measurable differences.
That means the 2004 version isn’t simply the 1994 master with the volume increased.
The mastering has changed.
The Dynamic Range Difference
One of the measurements we can use to examine this is crest factor — the difference between the average level of a recording and its peaks.
A higher crest factor generally means greater separation between the average level and the peaks.
For Monday Morning:
1994: approximately 17.6 dB
2004: approximately 13.1 dB
That’s a difference of approximately 4.5 dB.
And this wasn’t unique to Monday Morning.
When all 11 tracks appearing on both CDs were analysed, 10 of the 11 tracks showed a reduction in crest factor on the 2004 version.
That is a significant pattern.
It tells us that the 2004 mastering has generally been made louder and denser.
It does not, by itself, mean that the CD is clipped. High peak levels and clipping are two different things.
Change in crest factor between the 1994 West German Target and 2004 editions. Negative values indicate reduced peak-to-average separation on the 2004 version.
The Whole Album Tells the Story
This is where the comparison becomes much more convincing.
Rather than looking at one song, I analysed all 11 tracks that appear on both CDs.
The average RMS difference across the album is approximately:
5.3 dB louder on the 2004 edition
Every single one of the 11 common tracks is louder on the 2004 CD.
The graph makes the pattern very easy to see.
The 2004 version is consistently louder across the original album.
But What About the EQ?
This was the next question.
Perhaps the 2004 mastering was simply compressed and made louder.
To test that, I removed the volume difference by level-matching the two versions.
Then I compared their frequency spectra.
And again, the results showed that the two CDs aren’t identical.
The broad album-wide differences were approximately:
Frequency range
2004 compared with 1994
20–60 Hz
-1.6 dB
60–120 Hz
-0.8 dB
120–250 Hz
+0.7 dB
250–500 Hz
+0.7 dB
500 Hz–1 kHz
+1.2 dB
1–2 kHz
+0.7 dB
2–4 kHz
+1.2 dB
4–8 kHz
+1.7 dB
8–16 kHz
+1.6 dB
16–20 kHz
+0.9 dB
The important point isn’t each individual number.
It’s the overall shape.
After the overall volume difference was removed, the 2004 mastering still showed less energy in the very lowest frequencies and more energy through much of the midrange and upper frequencies.
So the tonal balance has changed too.
A Picture Tells a Thousand Words
Put the two discs next to each other and the physical differences are immediately obvious.
The black spine and clear spine are only the beginning.
The artwork, disc design, catalogue information, packaging and track content all provide clues that these aren’t simply two identical CDs from different production runs.
But the really interesting difference is something you can’t see by looking at the discs.
It’s in the audio data.
Eleven Tracks, Same Conclusion
The strongest evidence comes from looking at all 11 tracks common to both editions.
Every track is louder on the 2004 CD.
Ten out of eleven have a lower crest factor.
The frequency analysis also shows a different tonal balance after level matching.
This means we can confidently say that the 2004 edition is not simply the 1994 mastering with the volume turned up.
There has been a change in the mastering.
And Then There Are the Five Bonus Tracks
The 2004 edition adds five additional recordings.
These aren’t relevant when comparing the mastering of the original 11 tracks, because there is no corresponding recording on the 1994 disc.
But they are still an important part of the comparison.
The 2004 CD therefore offers something the 1994 Target doesn’t:
additional material.
So Which One Is Better?
Now we get to the difficult question.
Which CD sounds better?
The measurements can tell us what changed.
They can’t tell us what you will personally prefer.
The 1994 West German Target
Lower overall mastering levels
Greater peak-to-average separation
More headroom
A different tonal balance
The original 11-track album
The 2004 Edition
A substantially higher average level
Peaks much closer to digital full scale
Reduced peak-to-average dynamics on most tracks
A different tonal balance
Five additional recordings
If you prefer a mastering with greater dynamic headroom and less aggressive level management, the 1994 Target is likely to be the more interesting choice.
If you prefer a louder, more forward presentation and want the bonus material, the 2004 edition has obvious advantages.
The Conclusion
So, what’s the difference between these two compact discs?
Quite a lot.
It started with something as simple as noticing that one had a black spine and the other had a clear spine.
But once the discs were ripped and analysed, the differences became much more substantial.
The 2004 edition isn’t simply the 1994 CD with the volume turned up.
Across all 11 tracks common to both editions, the 2004 version is approximately 5.3 dB louder on average.
Ten of the 11 tracks show reduced crest factor.
And after level-matching the recordings, there are still measurable differences in frequency balance.
In other words, these are different masterings.
The 1994 West German Target represents a much more conservatively mastered presentation, with greater peak-to-average separation.
The 2004 edition offers a louder, more forward mastering, a different tonal balance and five additional recordings.
So the answer to the question I started with is:
The difference isn’t just the spine.
The two CDs may contain the same Fleetwood Mac album, but they don’t contain exactly the same sound.
And now that we’ve got the measurements, the question becomes a much more interesting one:
I know, I know. Five months is a long time between posts, but I’ve been keeping myself rather busy behind the scenes. So, when I finally sat down to write something, I thought I’d pick a topic that’s a little more… topical.
And what could possibly be more topical than Fortnite Sprites?
Yep — those little things.
Got to catch them all!
If you’ve played Fortnite recently, you’ll know that Sprites have become another little part of the Fortnite experience. They’re small, they’re cute, they’re useful… and, inevitably, you start wanting to catch them all.
It reminds me of Pokémon.
You’ve got to catch them all!
Only this time, rather than wandering around the Pokémon world throwing Poké Balls at everything that moves, you’re running around Fortnite looking for Sprites.
And, of course, once you find one, you can’t just leave it there.
You have to catch it.
Why am I talking about Fortnite?
Well, partly because it’s something completely different from my usual posts.
Those who know me will know that most of my blog posts tend to involve VMware, Proxmox, OpenNebula, Linux, networking, storage, scripting or some other form of infrastructure that inevitably involves staring at a terminal window.
Sometimes it’s nice to write about something that doesn’t involve a command prompt.
And let’s be honest — Fortnite is fun.
There’s something strangely satisfying about exploring the map, finding things you weren’t necessarily looking for and discovering another Sprite along the way.
Five months later…
It’s actually made me realise just how quickly time disappears.
Five months ago I was writing my previous blog post, and since then there’s been a whole load of projects, changes, experiments and general IT madness going on.
I’ve still got plenty of technical subjects I’d like to write about, particularly some of the work I’ve been doing around infrastructure automation and self-service.
But for now…
I’m going hunting.
Sprites, here I come.
? Got to catch them all!
And perhaps, after another five-month gap, I’ll even write another blog post before Christmas. ?
Minisforum MS-A2 HOW TO: Fix the Failed to Update CPU#0 Microcode PSOD with ESXi 8.0.3i ESXi 8.0u3i
HOW TO: Fix “Failed to update CPU#0 microcode” PSOD on ESXi 8.0.3i (Minisforum MS-A2)
In this guide from Hancock’s VMware Half Hour, I demonstrate how to fix the Purple Screen of Death (PSOD) error:
“Failed to update CPU#0 microcode”
This issue occurs when installing or booting VMware ESXi 8.0 Update 3i (ESXi 8.0.3i)
on the Minisforum MS-A2 mini workstation.
ESXi 8.0.3i, released on 2 March 2026, includes security fixes for CVE-2025-15467, an OpenSSL vulnerability. If you are running ESXi and have not
patched yet, you should update as soon as possible.
However, this update also includes new AMD CPU microcode updates, which currently
appear to trigger a PSOD during boot on the Minisforum MS-A2 platform.
The Problem
When booting the ESXi 8.0.3i installer (for example from Ventoy) on the
Minisforum MS-A2, the system may fail during boot with the following PSOD message:
The system has found a problem on your machine and cannot continue.
Failed to update CPU#0 microcode
This prevents ESXi from completing the boot process or installer launch.
Why This Happens
The ESXi 8.0.3i update includes newer AMD microcode updates intended to improve
security and stability. Unfortunately, these updates currently appear to be incompatible with the MS-A2 platform, which results in the microcode update failing
during boot.
When the microcode update fails, ESXi halts the boot process and displays the PSOD.
The Workaround
Until VMware releases a permanent fix, the issue can be worked around by using a kernel boot option during ESXi startup.
Steps to Fix
Boot the ESXi 8.0.3i installer.
When the ESXi boot screen appears, press Shift + O.
This opens the ESXi boot options.
Add the required kernel option shown in the video.
Press Enter to continue booting.
With the boot option applied, ESXi should boot successfully on the Minisforum MS-A2.
Video Walkthrough
Watch the full walkthrough below where I demonstrate the issue and apply the workaround.
What You Will Learn
What changed in ESXi 8.0.3i
Why AMD microcode updates trigger a PSOD
How to reproduce the issue during boot
The Shift + O ESXi boot workaround
How to confirm the fix works successfully
Credits
Huge thanks to members of the VMware community who investigated and documented this issue:
Stephen Wagner
Patrick Kernstock
vAndu
Martin Gustafsson
Their research and testing helped identify the workaround shown in this video.
HOW TO: Create a Custom VCF 9.0 VMware ESXi 9.0 ISO with Realtek Driver (PowerCLI)
Author: Andy – Andysworld.org.uk
Good news for homelab enthusiasts! We finally have a working Realtek network driver for ESXi 9.0. In this guide, I’ll show you step-by-step how to create a customised VMware ESXi 9.0 ISO for VCF 9.0 with the Realtek driver injected (slipstreamed) using PowerShell 7 and VMware PowerCLI.
Why This Matters
If you’re running ESXi in a homelab environment using consumer hardware, Mini PCs, or whitebox builds, Realtek NIC support has historically been a challenge. With the latest Realtek driver available, we can now build a custom ESXi 9.0 ISO that works perfectly in lab environments.
This process allows you to:
Inject the Realtek driver into the ESXi 9.0 image profile
Create a bootable ISO installer
Export an offline ZIP bundle
Important Disclaimer
ESXi 9.0 depot files require a valid Broadcom contract. I do not distribute depot files, customised ISOs, or any Broadcom software. Please obtain required files through official channels.
You should now have both a customised ISO and ZIP bundle ready for deployment in your homelab.
Method 2 – Scripted Approach
If you prefer automation, you can use a PowerShell script to perform the entire process in one go. The script automates:
Loading depot files
Cloning image profiles
Injecting the Realtek driver
Exporting ISO and ZIP bundles
This method is ideal for repeat builds or lab rebuilds.
Who Is This For?
Homelab enthusiasts
VMware learners
Mini PC / Whitebox ESXi users
VCF 9.0 lab deployments
This guide is intended for lab and educational use only, not production environments.
Final Thoughts
Creating a custom ESXi image is a valuable skill for anyone running a VMware homelab. With the Realtek driver now available for ESXi 9.0, lab builders can continue using affordable hardware while staying current with VMware releases.
If you found this guide helpful, check out more VMware content here at Andysworld.org.uk.
In this post, we’re going to walk through how to create a customised VMware ESXi 8.0 ISO with the Realtek network driver injected. This is particularly useful for homelab users running ESXi on consumer or whitebox hardware where Realtek NICs are common.
With the release of the ESXi 8.0 Realtek Driver Fling, Realtek-based systems can once again be used for lab and learning environments without unsupported hacks.
What You Will Learn
What ESXi depot files and image profiles are
How to inject (slipstream) the Realtek driver into ESXi 8.0
How to build a custom ESXi ISO and ZIP bundle
Manual and scripted methods using PowerShell
Prerequisites
Before starting, ensure you have the following:
PowerShell 7 (required)
VMware PowerCLI (or VMware Cloud Foundation PowerCLI)
Python 3.12
ESXi 8.0 depot ZIP file
Realtek Driver Fling ZIP file
Note: ESXi 8.0.3e and 8.0.3f depot files are publicly available. Later versions such as 8.0.3g and 8.0.3h require a valid Broadcom support contract. I do not distribute depot files or customised ISOs.
If you prefer automation, a PowerShell script called Hancocks-VMware-Half-Hour-ESXi-Customizer1.ps1 is available from GitHub and automates the entire process.
As shown in the video, even scripts can break — troubleshooting is part of the learning process.
Installation and Verification
Boot your ESXi host using the custom ISO
Complete the ESXi installation
Verify that the Realtek NIC is detected during install
If the driver has been injected correctly, the Realtek network adapter will be visible and usable within ESXi.
Important Notes
I do not provide ESXi depot files
I do not provide customised ESXi ISOs
I have no rights to distribute Broadcom software
This guide is intended for lab and homelab use only
Final Thoughts
This is a major step forward for the homelab community. With the Realtek Driver Fling, ESXi 8.0 is once again a viable option on affordable hardware.
Thanks for reading, and as always — happy virtualising!
Minisforum MS-A2: How to Install the New Realtek Driver on VMware ESXi 9.0
Running VMware ESXi 9.0 on the Minisforum MS-A2 is a fantastic option for homelabs and edge deployments, but out of the box you may notice that not all Realtek network interfaces are detected.
In this guide, based on my latest episode of Hancock’s VMware Half Hour, I walk through installing the new Broadcom-compiled Realtek driver (available as an official Broadcom Fling) to unlock additional NIC support.
What This Guide Covers
Why Realtek NICs are limited by default on ESXi 9.0
Where to download the official Broadcom Fling driver
Installing the driver using esxcli
Rebooting safely and verifying NIC availability
Supported Realtek Network Adapters
The driver demonstrated in this guide supports the following Realtek PCIe devices:
RTL8111 – 1GbE
RTL8125 – 2.5GbE
RTL8126 – 5GbE
RTL8127 – 10GbE
Driver Installation Command
Once the driver ZIP has been copied to your ESXi datastore and the host is in maintenance mode, install it using:
After installation, a reboot is required for the new network interfaces to become available.
Video Chapters
00:00 - Start
00:03 - Welcome to Hancock's VMware Half Hour
00:37 - Todays video - HOW TO Install Realtek driver on ESXi 9.0
00:55 - Broadcom Released the Realtek Driver fling in November 2025
01:55 - Minisforum MS-A2 - VCF 9.0 Homelab of the Year 2025 !
02:26 - Available as a Broadcom Fling - Tech Preview - not for production
02:55 - I'm not a fan of Realtek let it be known!
03:11 - Go to Broadcom Fling Portal site to download - https://support.broadcom.com/group/ecx/productdownloads?subfamily=Flings&freeDownloads=true
03:22 - Download the driver don't forget to Accept the Agreement!
03:51 - Enable SSH on Host, and use WinSCP to copy to local datastore
04:31 - Whoops Zoom is broke again!
05:07 - Connect to host using SSH
05:22 - Use lspci to show PCI devices in the host
06:05 - Use grep - lspci | grep Realtek
07:01 - Install the driver using esxcli software component apply -d /VMware-Re-Driver_1.101.00-5vmw.800.1.0.20613240.zip
07:59 - A reboot is required, reboot the server
08:36 - Reboot server
09:20 - The reason for the 10th Outake !
10:01 - Login to ESXi 9.0 using HTML Client
10:51 - Realtek driver is installed and network interfaces are available for use
11:07 - HenryChan1973 this video is for you!
12:23 - Thanks for Watching
Final Thoughts
This Broadcom Fling makes ESXi 8.0 far more usable on modern mini PCs like the Minisforum MS-A2, especially for homelabbers who rely on multi-gig Realtek networking.
Huge thanks to Henrychan1973 for their contribution and support.
If this guide helped you, consider subscribing on YouTube and checking out more VMware content on the blog.
Minisforum MS-A2: How to Install the New Realtek Driver on VMware ESXi 8.0
Running VMware ESXi 8.0 on the Minisforum MS-A2 is a fantastic option for homelabs and edge deployments, but out of the box you may notice that not all Realtek network interfaces are detected.
In this guide, based on my latest episode of Hancock’s VMware Half Hour, I walk through installing the new Broadcom-compiled Realtek driver (available as an official Broadcom Fling) to unlock additional NIC support.
What This Guide Covers
Why Realtek NICs are limited by default on ESXi 8.0
Where to download the official Broadcom Fling driver
Installing the driver using esxcli
Rebooting safely and verifying NIC availability
Supported Realtek Network Adapters
The driver demonstrated in this guide supports the following Realtek PCIe devices:
RTL8111 – 1GbE
RTL8125 – 2.5GbE
RTL8126 – 5GbE
RTL8127 – 10GbE
Driver Installation Command
Once the driver ZIP has been copied to your ESXi datastore and the host is in maintenance mode, install it using:
After installation, a reboot is required for the new network interfaces to become available.
Video Chapters
00:00 - Intro
00:06 - Welcome to Hancock's VMware Half Hour
00:31 - Today’s Video – Minisforum MS-A2
01:01 - Installing the ESXi Realtek Driver for ESXi 8.0
01:16 - Shoutout to member Henrychan1973!
02:03 - HTML Client view of network interfaces
03:00 - Broadcom engineering compiled a driver for ESXi 8.0
04:00 - Driver is available as a Broadcom Fling
05:00 - Download the driver from Broadcom Fling portal
05:44 - WinSCP – Copy driver ZIP to ESXi datastore
06:14 - Put host into maintenance mode
07:11 - Only three interfaces supported out of the box on MS-A2
07:16 - Start an SSH session using PuTTY
07:34 - Using lspci | grep Realtek
08:22 - Supported Realtek PCIe devices
08:35 - Installing the driver using esxcli
09:59 - Whoops! Typo!
10:37 - Can you spot it?
11:08 - Driver installed – reboot required
11:27 - Nano KVM issue accepting root password?
11:41 - Reboot via the GUI
12:30 - MS-A2 restarting
13:42 - Driver installed and Realtek interfaces available
14:54 - Thanks to Henrychan1973!
15:15 - Thanks for watching
Final Thoughts
This Broadcom Fling makes ESXi 8.0 far more usable on modern mini PCs like the Minisforum MS-A2, especially for homelabbers who rely on multi-gig Realtek networking.
Huge thanks to Henrychan1973 !!!
If this guide helped you, consider subscribing on YouTube and checking out more VMware content on the blog.
In Part 9 of the DIY UnRAID NAS series, we finally tackle one of the most requested upgrades — NVMe cache expansion.
This episode covers upgrading the UnRAID cache pool using Samsung 990 PRO 4TB NVMe SSDs,
walking through the hardware changes, UnRAID configuration, and the impact on performance.
What’s covered in Part 9
Removing NVMe devices from PCI passthrough
Rebooting and validating UnRAID hardware changes
Why UnRAID is used instead of vSAN in the homelab
Upgrading and rebalancing the NVMe cache pool
Btrfs RAID1 behaviour and live rebalance
Firmware considerations for Samsung 990 PRO NVMe drives
Why NVMe Matters in UnRAID
NVMe cache drives dramatically improve Docker, VM, and application performance in UnRAID.
With fast PCIe 4.0 NVMe devices, write amplification is reduced, cache flushes are faster,
and overall system responsiveness improves — especially under mixed workloads.
Unlike enterprise storage platforms, UnRAID allows flexible cache pool configurations,
making it ideal for homelab experimentation without vendor lock-in.
As always, thanks for watching, and if you’ve got questions about NVMe cache pools,
Btrfs behaviour, or UnRAID design decisions, drop them in the comments.
DIY UNRAID NAS Part 8: Preparing the Zero-Downtime NVMe Upgrade
Welcome back to Hancock’s VMware Half Hour and to Part 8 of the DIY UNRAID NAS build series.
In this episode, I walk through the planning and preparation for a zero-downtime NVMe cache
upgrade on my homelab UNRAID NAS, running on an Intel NUC 11 Extreme.
The goal of this two-part upgrade is to move from a single 512 GB XPG NVMe cache device
to a pair of Samsung 990 PRO 4 TB NVMe SSDs, ending up with a high capacity Btrfs RAID 1
cache pool for VMs, Docker, and PCIe passthrough workloads. Part 8 focuses on the design,
constraints, and first hardware changes. Part 9 completes the migration and final Btrfs rebalance.
Video: DIY UNRAID NAS Part 8
You can watch the full episode on YouTube here:
DIY UNRAID NAS – Part 8: Preparing the Zero-Downtime NVMe Upgrade
What This Episode Covers
Part 8 is all about understanding the current environment, identifying limitations in UNRAID,
and laying the groundwork for a non-destructive storage upgrade. In the video, I cover:
How my UNRAID array and cache devices are currently configured.
The future hardware specifications for the homelab UNRAID NAS.
Plans for using enterprise U.2 NVMe devices in future expansions.
Why we cannot simply create another cache pool in UNRAID to solve this.
A staged plan to replace the old 512 GB XPG NVMe with 4 TB Samsung 990 PRO drives.
How to safely stop Docker and virtual machines before making hardware changes.
Using PCIe passthrough (VMDirectPath I/O) to present NVMe devices directly to a Windows 11 VM.
Updating Samsung 990 PRO firmware from within the passthrough VM using Samsung Magician.
Confirming that all Samsung NVMe drives are genuine and authenticated.
Reviewing the NVMe slot layout in the Intel NUC 11 Extreme (2 x Gen 3 and 2 x Gen 4).
Chapter Breakdown
Here is the chapter list from the video for quick navigation:
00:00 – Intro
00:05 – Welcome to Hancock’s VMware Half Hour
00:47 – This is Part 8 DIY UNRAID NAS
01:21 – Explanation of UNRAID and how I have set up UNRAID
04:20 – Explanation of UNRAID array and cache devices
04:51 – Future specifications for homelab UNRAID NAS
05:54 – Future use of enterprise NVMe U.2 device
09:42 – I have a cunning plan says Andy
12:02 – We cannot create another cache pool
12:56 – Stop Docker and VMs
13:10 – Shutdown ESXi on UNRAID
13:28 – Shutdown Windows 11 on UNRAID
14:22 – New NVMe installed, old XPG removed
15:16 – PCIe passthrough demonstration configuration for UNRAID VMs
17:14 – Restart NAS
17:29 – NVMe devices are enabled for PCI passthrough
18:11 – VMware VM Direct I/O (PCI passthrough) explained
18:46 – Configure Windows 11 VM for PCI passthrough
20:00 – Samsung Magician advising firmware update available
20:48 – Update firmware of Samsung 990 PRO from Windows 11
23:14 – Confirmation that all Samsung NVMe are authenticated
26:22 – NVMe slots in Intel NUC 11 Extreme are 2 x Gen 3 and 2 x Gen 4
27:06 – Remove NVMe devices from Windows 11 VM
The Cunning Plan: A Staged, Non-Destructive NVMe Upgrade
The key challenge in this build is upgrading from a 512 GB NVMe cache to larger 4 TB devices
without wiping the array or losing data. Because UNRAID cannot create an additional cache pool
in this configuration, we need a staged process.
In Part 8, I outline and begin the following upgrade path:
Review the current UNRAID array and cache configuration.
Plan the future target: dual 4 TB NVMe Btrfs RAID 1 cache pool.
Shut down Docker and VM services cleanly.
Power down the NAS and remove the old XPG NVMe.
Install the first Samsung 990 PRO 4 TB NVMe drive.
Boot the system and confirm the new NVMe is detected.
Use PCIe passthrough to present the NVMe to a Windows 11 VM for firmware checks and updates.
Update NVMe firmware using Samsung Magician and validate that the drive is genuine.
The actual Btrfs pool expansion and final dual-drive RAID 1 configuration are completed
in Part 9, where the second 4 TB NVMe is installed and the cache pool is fully migrated.
PCIe Passthrough and Firmware Updates
A significant part of the episode is dedicated to demonstrating PCIe passthrough
(VMDirectPath I/O) from VMware ESXi into UNRAID and then into a Windows 11 virtual machine.
This allows the Samsung 990 PRO NVMe to be exposed directly to Windows for:
Running Samsung Magician.
Checking for and applying firmware updates.
Verifying drive health and authenticity.
This approach is particularly useful in homelab environments where the hardware is
permanently installed in a server chassis, but you still want to access vendor tools
without moving drives between physical machines.
Intel NUC 11 Extreme NVMe Layout
Towards the end of the video, I review the NVMe slot layout inside the Intel NUC 11 Extreme.
This platform provides:
2 x PCIe Gen 4 NVMe slots.
2 x PCIe Gen 3 NVMe slots.
Understanding which slots are Gen 3 and which are Gen 4 is critical when deciding where to place
high performance NVMe devices such as the Samsung 990 PRO, especially when planning for
future workloads and potential enterprise U.2 NVMe expansion.
What Comes Next in Part 9
Part 8 ends with the new 4 TB NVMe installed, firmware updated, and the environment ready
for the next stage. In Part 9, I complete the migration by:
Replacing the remaining 512 GB cache device with a second 4 TB Samsung 990 PRO.
Rebuilding the Btrfs cache pool as a dual-drive RAID 1 configuration.
Verifying capacity, redundancy, and performance.
If you are interested in UNRAID, NVMe-based cache pools, or nested VMware and PCIe
passthrough in a small form factor system like the Intel NUC 11 Extreme, this two-part
upgrade is a practical, real-world example of how to approach it safely.
Related Content
DIY UNRAID NAS build playlist on Hancock’s VMware Half Hour (YouTube).
Previous parts in the series covering hardware assembly, base UNRAID configuration, and initial NVMe installation.
Upcoming parts focusing on performance testing, further storage expansion, and homelab workloads.