convert: remove nutanix virtio drivers from windows vms

[jonner]

When converting a vm from nutanix, there may be existing virtio drivers installed on the vm. In order to have a fully supported vm after conversion, we want to ensure that the virtio drivers that are installed by virt-v2v are the ones that are in use. Because both the nutanix and upstream virtio drivers target the same device ids, if multiple virtio drivers are installed, windows will use the driver that has the highest version number. To avoid relying on version numbers, simply uninstall existing drivers if they're found in the guest.

[rwmjones]

How was this tested? We will also need to add a regression test to the Red Hat test suite, probably by installing the Nutanix drivers inside a VM on VMware (somewhat unrealistic, but they won't do anything there) and checking the VM can convert and the drivers get uninstalled (@crobinso). But the patch looks fine otherwise.

[rwmjones]

The commit message needs to say a lot more, and also needs to have a Fixes line pointing to the RHEL bug.

[jonner]

I tested this against a vmware VM that had nutanix virtio drivers installed (provided by @mnecas). Well, technically I tested locally against an OVA export of that VM. Then I imported the converted vm into libvirt and verified that the injected drivers were working correctly and the nutanix drivers were uninstalled.

[jonner]

I copied the comment from this PR into the commit message. Is that sufficient?

[rwmjones]

I tested this patch myself and it seems to work as intended. There is no output from the uninstall command, but it does appear to run:

running "C:\Program Files\Guestfs\Firstboot\scripts\5000-0006-uninstall-Nutanix-VirtIO.bat"
uninstalling Nutanix VirtIO drivers
.... exit code 0
Script succeeded, moving to scripts-done
        1 file(s) moved.

The diff between pnputil /e output before and after is:

--- before.txt	2026-07-17 13:55:00.785932560 +0100
+++ after.txt	2026-07-17 13:40:57.303059491 +0100
@@ -1,9 +1,9 @@
 Microsoft PnP Utility
 
-Published name :            oem9.inf
-Driver package provider :   Nutanix, Inc.
+Published name :            oem14.inf
+Driver package provider :   Red Hat, Inc.
 Class :                     System devices
-Driver date and version :   08/27/2023 1.2.3.9
+Driver date and version :   12/08/2025 100.102.104.29400
 Signer name :               Microsoft Windows Hardware Compatibility Publisher
 
 Published name :            oem4.inf
@@ -12,22 +12,76 @@
 Driver date and version :   04/24/2017 1.0.0.0
 Signer name :               Microsoft Windows Hardware Compatibility Publisher
 
+Published name :            oem13.inf
+Driver package provider :   Red Hat, Inc.
+Class :                     System devices
+Driver date and version :   01/13/2025 100.100.104.27100
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
+Published name :            
+Driver package provider :   Unknown
+Class :                     Storage controllers
+Driver date and version :   01/01/1601 0.0.0.0
+Signer name :               Unknown
+
+Published name :            oem17.inf
+Driver package provider :   Red Hat, Inc.
+Class :                     System devices
+Driver date and version :   12/08/2025 100.102.104.29400
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
 Published name :            oem6.inf
 Driver package provider :   VMware, Inc.
 Class :                     Storage controllers
 Driver date and version :   08/02/2019 1.3.15.0
 Signer name :               Microsoft Windows Hardware Compatibility Publisher
 
-Published name :            oem12.inf
+Published name :            oem18.inf
 Driver package provider :   QEMU
+Class :                     Ports (COM & LPT)
+Driver date and version :   05/09/2017 1.4.0.0
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
+Published name :            oem19.inf
+Driver package provider :   Red Hat, Inc.
+Class :                     System devices
+Driver date and version :   07/08/2025 100.101.104.28400
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
+Published name :            oem21.inf
+Driver package provider :   Red Hat, Inc.
+Class :                     Human Interface Devices
+Driver date and version :   07/08/2025 100.101.104.28400
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
+Published name :            oem23.inf
+Driver package provider :   Red Hat, Inc.
+Class :                     System devices
+Driver date and version :   07/08/2025 100.101.104.28400
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
+Published name :            oem24.inf
+Driver package provider :   Red Hat, Inc.
+Class :                     Storage controllers
+Driver date and version :   01/21/2026 100.102.104.29500
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
+Published name :            oem25.inf
+Driver package provider :   Red Hat, Inc.
 Class :                     System devices
-Driver date and version :   08/27/2023 1.2.3.9
+Driver date and version :   07/08/2025 100.101.104.28400
 Signer name :               Microsoft Windows Hardware Compatibility Publisher
 
-Published name :            oem11.inf
-Driver package provider :   Nutanix, Inc.
+Published name :            oem26.inf
+Driver package provider :   Red Hat, Inc.
+Class :                     System devices
+Driver date and version :   01/21/2026 100.102.104.29500
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
+Published name :            oem15.inf
+Driver package provider :   Red Hat, Inc.
 Class :                     Storage controllers
-Driver date and version :   08/27/2023 1.2.3.9
+Driver date and version :   02/18/2026 100.103.104.29700
 Signer name :               Microsoft Windows Hardware Compatibility Publisher
 
 Published name :            oem2.inf
@@ -48,10 +102,10 @@
 Driver date and version :   07/11/2019 12.5.10.0
 Signer name :               Microsoft Windows Hardware Compatibility Publisher
 
-Published name :            oem10.inf
-Driver package provider :   Nutanix, Inc.
+Published name :            oem16.inf
+Driver package provider :   Red Hat, Inc.
 Class :                     Network adapters
-Driver date and version :   08/27/2023 1.2.3.9
+Driver date and version :   12/08/2025 100.102.104.29400
 Signer name :               Microsoft Windows Hardware Compatibility Publisher
 
 Published name :            oem1.inf
@@ -66,6 +120,18 @@
 Driver date and version :   06/21/2006 10.0.17763.1
 Signer name :               Microsoft Windows
 
+Published name :            oem20.inf
+Driver package provider :   Red Hat, Inc.
+Class :                     Display adapters
+Driver date and version :   12/08/2025 100.102.104.29400
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
+Published name :            oem22.inf
+Driver package provider :   Red Hat, Inc.
+Class :                     Memory technology devices
+Driver date and version :   12/08/2025 100.102.104.29400
+Signer name :               Microsoft Windows Hardware Compatibility Publisher
+
 Published name :            oem3.inf
 Driver package provider :   VMware, Inc.
 Class :                     Display adapters

[rwmjones]

One problem I can foresee is that we remove the Nutanix drivers very late, after everything else has been performed. In particular we have already booted using the preliminary virtio-blk driver and Windows has already decided whether or not it's going to install our virtio drivers (or, I guess, stick with the Nutanix drivers).

Not sure how solvable that is, or indeed if it's something we need to solve.

@vrozenfe opinions on this?

[ybendito]

2 questions:

• isn't it better to remove any already installed virtio drivers (not especially from Nutanix)?
• are there some user-mode components (related to Nutanix) that it makes sense to remove also?

[rwmjones]

These are for @jonner to answer I think, but

isn't it better to remove any already installed virtio drivers (not especially from Nutanix)?

is there a way to do this?

[vrozenfe]

@jonner I agree that we need to get rid of any non-RH VirtIO drivers.

In the Nutanix case, a simple driver update should work because of Nutanix’s driver versioning pattern:

-Driver date and version : 08/27/2023 1.2.3.9
+Driver date and version : 12/08/2025 100.102.104.29400

Technically, our drivers have a newer timestamp and a higher version number, which makes them preferable in terms of Windows driver ranking:
https://learn.microsoft.com/en-us/windows-hardware/drivers/install/how-windows-ranks-driver-packages

However, if another vendor uses a versioning scheme with a higher leading component than our current “100” (for example, 200.x.x.x), Windows may continue to prefer that driver. In that case, with our current versioning scheme, we would likely need to clean up the registry/driver store entries manually in order to remove the third-party VirtIO drivers.

Best regards,
Vadim

[rwmjones]

As usual we will need to know precisely what steps to take in detail in order to implement anything.

[jonner]

So, here's a different proposal. As @vrozenfe pointed out, the Red Hat drivers already beat nutanix because of version numbers, so I guess this patch isn't actually achieving much. It doesn't really help at all for another potential vendor that ships drivers with a version number higher than the version we're trying to install.

So what if we try to remove all existing VirtIO drivers from the driver store offline instead, before first boot and before virt-v2v injects the virtio drivers? That way everything just gets removed and we can install our virtio drivers fresh without worrying about any version conflicts.

I'm playing with a patch that does the following:

• Scan DriverStore/FileRepository and delete any staged driver directory whose INF file contains the virtio vendor ID 1AF4.
• Clean up the corresponding registry entries in DriverDatabase so Windows has no stale references.

Are there any downsides to doing it this way? It seems to mostly work, but I'm working through a couple remaining issues.

[rwmjones]

The downside is that's pretty invasive. And seems not necessary - if our drivers have a high version, Windows will use them (AIUI), so there's no reason for us to do anything.

The original bug report doesn't specify any particular problem at the moment, it just talks about vague worries. But unless something very concrete is not working my instinct is not to do anything, especially not anything risky.

[jonner]

OK, I guess I'll put this on the back burner until an actual issue pops up.

[rwmjones]

If you have something written, even a draft, then it could be worth posting it (marked as "draft"). This will be a record of what we tried and also something someone could resurrect later if this proves necessary.

But you're right that we shouldn't spend too much time on this unless there an actual problem that we're solving, and it doesn't look like that right now.

[mnecas]

The original bug report doesn't specify any particular problem at the moment, it just talks about vague worries. But unless something very concrete is not working my instinct is not to do anything, especially not anything risky.

Indeed, I don't have any problems or proof. I opened the ticket so we investigate it and I'm fine as long as the windows does use the correct drivers.

[sparimi-rh]

Should this be case insensitive search ? I assume that String.find would do case sensitive search

[mnecas]

Now that we are dealing with many vmware leftover issues I think it would be safer to remove the nutanix aswell.
Just to play it safe