[Feature Absorption Request] Fully Automated VirtIO Integration - Complete Hands-Off Deployment for QEMU/KVM/Proxmox

[luckygreen]

Summary

Lucky Green and I (Claude Sonnet 4.5) have developed an external PowerShell script that achieves complete "first-boot-ready" VirtIO integration for MicroWin ISOs deployed on QEMU/KVM environments (including Proxmox VE, virt-manager, and other QEMU-based hypervisors). We believe this functionality would be valuable as a native MicroWin feature and are requesting its absorption into the project as a checkbox option.

Repository: https://github.com/luckygreen/microwin-virtio-integration

Our script eliminates all manual driver installation steps, solves the common "no drives found" error during Windows installation, and automates guest tools installation - delivering a truly zero-touch deployment experience for any QEMU/VirtIO environment.

The Problem We Solved

While MicroWin currently has basic VirtIO driver injection capability, users deploying to QEMU/KVM environments (Proxmox VE, virt-manager, libvirt, plain QEMU, etc.) still encounter critical issues:

1. "No drives found" during installation - The Windows installer (WinPE/boot.wim) cannot see VirtIO storage devices, forcing users to:

   • Use IDE emulation as a workaround (slower performance, legacy interface)
   • Manually load drivers during installation (tedious, error-prone)
   • Switch storage controllers mid-installation (complex, unreliable)

2. Post-installation manual work - Even after installation completes, users must:

   • Manually install virtio-win-guest-tools.exe for QEMU Agent and SPICE support
   • Configure services and components individually
   • Deal with missing drivers for serial ports, RNG, balloon memory, VirtIO-FS, etc.
   • Troubleshoot networking, input devices, and other VirtIO peripherals

3. Incomplete automation - Current VirtIO injection only handles install.wim, leaving the installer environment (boot.wim) without drivers

Our Solution

We've created Integrate-VirtIO-MicroWin.ps1 which performs:

Core Functionality

• ✅ Injects all 10 VirtIO drivers into install.wim (NetKVM, viostor, vioscsi, Balloon, viorng, vioserial, qemupciserial, vioinput, pvpanic, viofs)
• ✅ Injects all 10 VirtIO drivers into boot.wim - This is the critical difference! By injecting into the installer environment, Windows Setup can immediately see VirtIO storage devices
• ✅ Bundles virtio-win-guest-tools.exe and configures automatic silent installation via SetupComplete.cmd
• ✅ Generates properly bootable ISOs with UEFI/BIOS dual-boot support
• ✅ Smart auto-detection of source files (MicroWin ISO, VirtIO ISO, guest tools exe)
• ✅ Intelligent ISO naming with descriptive volume labels

The Result

Zero-touch VirtIO deployment for any QEMU/KVM environment. Users simply:

1. Run the script on their MicroWin ISO
2. Deploy the resulting ISO to any QEMU-based hypervisor with VirtIO devices
3. Install Windows normally - all drivers present, guest tools auto-install post-OOBE

No IDE workarounds. No manual driver loading. No post-installation configuration. Works on Proxmox VE, virt-manager, libvirt, oVirt, plain QEMU, and any other KVM-based platform.

Why This Should Be Absorbed Into MicroWin

We strongly believe this functionality belongs directly in MicroWin as a checkbox option for several reasons:

1. QEMU/KVM is ubiquitous - Proxmox VE, virt-manager, oVirt, and countless other platforms use QEMU with VirtIO devices
2. VirtIO is the performance standard - It's the recommended paravirtualized I/O for all modern KVM deployments
3. Current VirtIO support is incomplete - Without boot.wim injection, the "no drives found" error persists
4. Users expect this to "just work" - The current implementation creates friction in an otherwise streamlined MicroWin experience
5. All components are already present - MicroWin uses DISM and oscdimg; we're just extending existing workflows
6. Guest tools automation completes the picture - SetupComplete.cmd integration delivers true zero-touch deployment
7. Growing virtualization adoption - More users are moving to KVM-based infrastructure for Windows workloads

Proposed Integration

We envision this as a checkbox in the MicroWin UI:

☑ Complete VirtIO Integration for QEMU/KVM
  ├─ Auto-download VirtIO drivers ISO (latest from Fedora)
  ├─ Auto-download virtio-win-guest-tools.exe
  ├─ Inject drivers into install.wim AND boot.wim
  └─ Configure guest tools auto-installation

When checked, MicroWin would:

1. Download the latest VirtIO ISO from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/
2. Download matching virtio-win-guest-tools.exe
3. Inject all VirtIO drivers into both install.wim and boot.wim (critical!)
4. Bundle guest tools and create SetupComplete.cmd for silent post-OOBE installation
5. Generate the final ISO as normal

Technical Details

Our script is public domain (Unlicense) and available for complete absorption. Key implementation notes:

• Uses standard DISM commands: Add-WindowsDriver -Path $MountPath -Driver $DriverPath -Recurse -ForceUnsigned
• Injects into boot.wim Index 2 (Windows Setup environment) - this is what eliminates "no drives found"
• Creates \Windows\Setup\Scripts\SetupComplete.cmd to trigger guest tools installation
• Maintains dual-boot capability with proper oscdimg bootdata parameters

The script handles:

• Version matching between VirtIO ISO and guest tools exe
• Proper error handling and WIM unmounting
• Read-only attribute removal from copied ISO files
• ISO9660 volume label length restrictions (32 chars)
• Smart output naming based on input ISOs

Current Script Location

The complete script is available as Integrate-VirtIO-MicroWin.ps1 (v3.8.0). We're happy to:

• Provide the script for review
• Assist with integration into MicroWin's codebase
• Test the integrated implementation
• Update documentation

Why We're Not Just Submitting a PR

We felt this was substantial enough to warrant discussion first:

1. It adds external dependencies (VirtIO ISO downloads)
2. It introduces new UI elements (checkbox, progress indicators)
3. It requires decisions about user experience (auto-download vs. manual selection)
4. It may have implications for MicroWin's architecture

We'd rather discuss the approach with the maintainers before investing time in a PR that might not align with project direction.

User Impact

This would immediately benefit thousands of users who:

• Deploy Windows to QEMU/KVM environments (Proxmox VE, virt-manager, oVirt, etc.)
• Use VirtIO paravirtualized devices for optimal performance
• Run Windows VMs on Linux KVM hosts
• Manage virtualization infrastructure professionally
• Want truly hands-off Windows deployments without IDE fallbacks
• Need QEMU Guest Agent and SPICE integration working out-of-the-box

Closing Thoughts

MicroWin is an excellent tool that has saved countless hours of Windows setup pain. This enhancement would make it even better for the virtualization community. We hope the MicroWin team will consider absorbing this functionality.

We believe the spirit of this request aligns perfectly with MicroWin's mission: streamlined, automated, bloat-free Windows deployments.

Thank you for considering this feature absorption request!

---

Signed,
Lucky Green & Claude Sonnet 4.5

P.S. - Yes, we know "feature absorption request" sounds funny. It's technically accurate though! 😄