RosiKyu commented on issue #13241: URL: https://github.com/apache/cloudstack/issues/13241#issuecomment-4787423107
I have tested this. With the flow described in the **Steps to reproduce** : **The original bug (default import):** - Real Windows Server 2025 (UEFI/GPT) -> CloudStack VMware -> KVM import -> conversion succeeds, disk is fine - but the VM is created BIOS + i440fx (boottype=None, machine='pc-i440fx-rhel7.6.0', SeaBIOS). - Result: "No bootable device" <img width="1525" height="861" alt="Image" src="https://github.com/user-attachments/assets/79215ff4-bf48-449b-9d60-fdbb3861ba32"; /> **The workaround (verified booting):** - Set the VM to UEFI=legacy (-> q35 + UEFI/OVMF) and host CPU to host-passthrough; virtio disk/NIC the import already set. - Confirmed live config: machine='pc-q35-rhel9.2.0', OVMF loader+nvram, cpu mode='host-passthrough'. - Result: VM boots But: a **secondary reboot loop** appears after the workaround boots - With the UEFI/q35 config the VM boots, but Windows reaches the logon screen and then restarts itself, repeatedly. UEFI reloads \EFI\Microsoft\Boot\bootmgfw.efi from the GPT partition each cycle - so firmware/disk are fine; Root cause of the loop is a virtio-win driver signing issue, not the firmware - virt-v2v installs a first-boot script (2000-0001-pnputil-install-drivers.bat) that pnputil-installs the bundled virtio drivers. It fails on smbus.inf, exits non-zero, and virt-v2v reboots to "retry on next boot" - which it did on every reboot (56 cycles observed before manual intervention), an effectively infinite loop: ``` Installing: smbus.inf. Adding the driver package failed : A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. Failed to install smbus.inf. .... exit code 249 Script failed, will retry on next boot ``` - Why only smbus: within the same virtio-win package the drivers are signed differently. ``` netkvm.cat (installs fine) -> subject = Microsoft Windows Hardware Compatibility Publisher [WHQL, trusted] smbus.cat (fails) → subject = O=virtio-win, OU=Dev, CN=Red Hat Inc. [self-signed dev cert, NOT trusted] ``` => Not a virtio-win version issue: checked both the latest (0.1.285) and the stable virtio-win - both ship smbus with the same self-signed dev cert, so switching versions does not fix it. The dev-signed smbus driver is present in all builds. virt-v2v's first-boot path installs via pnputil without importing the virtio-win certificate (the virtio-win guest-tools MSI normally imports it into Trusted Publisher first), so the dev-signed driver fails - and virt-v2v retries forever on a single driver failure. Any Windows guest converted through this path can hit the same loop. **Workaround and final state** - Removed the looping first-boot driver script from the converted disk -> Windows then boots stably to SConfig. - Migrated guest is functional: storage (offline-injected viostor) and network (virtio-net) work; only one non-essential device - the virtio serial controller (shown as PCI Simple Communications Controller, VEN_1AF4&DEV_1043) - is left without a driver. <img width="1649" height="1212" alt="Image" src="https://github.com/user-attachments/assets/711d0f60-1e7f-4523-a7a3-406960db29d3"; /> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
