Windows VM imported from VMware fails first boot on virtio/scsi disk bus; SATA first boot then switch works

[dcieops]

What happened:
After migrating a Windows VM from VMware into KubeVirt using CDI/v2v (DataVolumeTemplates), the VM only boots successfully on the first boot when the boot disk bus is sata.

If the VM is created to boot with virtio or scsi (virtio-scsi controller) on the first boot, it fails to boot.
However, once the VM has booted successfully at least once using SATA, we can patch the VM disk bus to virtio or scsi and reboot, and then it boots successfully with those buses.

In other words: virtio/scsi work only after an initial SATA boot, even though the Windows guest had virtio drivers installed pre-migration in VMware.

What you expected to happen:
The migrated Windows VM should be able to boot on the first boot with the boot disk bus set to virtio or scsi (virtio-scsi), especially if virtio drivers were installed in the guest prior to migration. SATA should not be required as a “first boot staging” workaround.

How to reproduce it (as minimally and precisely as possible):

1. Take an existing Windows VM in VMware vCenter and ensure it is powered off. (Virtio drivers are installed in-guest pre-migration.)
2. Migrate/import the VM into KubeVirt using CDI/v2v (VMware → DataVolumeTemplates workflow).
3. Create a KubeVirt VirtualMachine that references the imported DataVolumes.
4. Set the boot disk bus to virtio (or scsi) before the first boot. Example JSON patch used in our automation:
5. (Similarly reproduced with "value": "scsi" with a virtio-scsi controller.)
   [ { "op": "replace", "path": "/spec/template/spec/domain/devices/disks/0/disk/bus", "value": "virtio" } ]
6. Start the VM → first boot fails.
7. Recreate/patch the VM to boot with SATA ("value": "sata") and start → first boot succeeds.
8. After the VM has booted successfully once on SATA, patch the disk bus to virtio or scsi and restart → boots successfully.

Additional context:

This looks like Windows may not consider the virtio/scsi storage driver “boot critical” until after a successful first boot / driver initialization phase. Guidance requested on whether this is expected and whether CDI/v2v should recommend or automate “first boot on SATA, then switch bus”.

Environment:

CDI version: v1.64.0 (cdi-controller image quay.io/kubevirt/cdi-controller:v1.64.0)

KubeVirt version: v1.6.2

Kubernetes version: v1.33.5 (cluster); kubectl client v1.27.4

Migration method: VMware vCenter → CDI/v2v import using DataVolumeTemplates

Hardware: Bare metal Kubernetes cluster

virtio driver: virtio-win-0.1.285

OS: Windows Server 2019/2016

[akalenyu]

hey @mrnold @rwmjones did you ever encounter something like this?

[rwmjones]

Not a lot to go on. We're going to need the virt-v2v conversion log, and the contents of C:\Program Files\Guestfs from the guest.

[dcieops]

@rwmjones We’re not running virt-v2v in this workflow. We use CDI’s VDDK importer to directly import the VMware VMDK into a PVC (DataVolume spec.source.vddk) and then attach that PVC to a KubeVirt VM. We have scripts to preinstall the virtio drivers. This worklflow is working fine for all Linux VMs. Since no virt-v2v/libguestfs “firstboot” conversion runs, we don’t have a virt-v2v conversion log and there is no C:\Program Files\Guestfs created inside Windows. But I can see VirtIO driver when we are booting with Sata.

[mrnold]

When you say boot failure, is that a Windows blue screen? I think 7B is the usual error if VirtIO isn't installed right. Can you describe exactly what steps your scripts do to pre-install the VirtIO drivers?

[dcieops]

@mrnold The error is "INACCESIBLE BOOT DEVICE" with blue screen. To be sure I have installed the all the virtio driver manually from the iso.