Australian cloud for business software — built and run in Sydney since 2003

NetLeverage
NetLeverage

VM Will Not Boot After a Disk Controller Change: Diagnosis

Technical article
Troubleshooting

Direct answer: A guest can only reach its boot disk if the driver for that disk's controller loads before the root file system is needed. If a VM's boot disk is moved to a controller type whose driver the guest does not load early, Windows stops with INACCESSIBLE_BOOT_DEVICE (Stop 7B) and a dracut-based Linux guest cannot find its root device. Prove which case you have with read-only checks first. Recovery and the switch are changes: follow the vendor procedure for your exact case with a verified backup, a rollback plan and a reviewer. This article gives no step-by-step recovery.

Why it matters

Controller changes are made for performance (Broadcom describes PVSCSI as giving greater throughput and lower CPU utilisation) or happen during conversion, restore onto new virtual hardware or platform moves. The failure shows at the first boot. Quick fixes (offline registry edits, copied driver files, forced module lists, trying controller types until one boots) can turn a reversible configuration problem into a damaged guest.

How it works

Windows

If the boot controller has no installed and enabled driver, Windows cannot reach the system volume. Microsoft lists, among the causes of Stop 7B, "Using a different storage controller than the one that was used when Windows was installed" and "Moving the hard disk to a different computer that has a different controller", alongside storage filter drivers, file system corruption and boot configuration problems. A Stop 7B is therefore not proof of a controller cause on its own.

Broadcom KB 313507 states that the PVSCSI driver "is not native to some version of the Windows Operating System and the guest will experience a BSOD on boot" if the boot disk is moved to PVSCSI first. It warns that uninstalling VMware Tools from a guest booting from PVSCSI leaves it unbootable.

Keep two cases apart:

  • Known controller change. The VM booted before and the original controller setting is recorded. Broadcom KB 341383 and KB 414027 cover this.
  • P2V conversion. The VM never booted on virtual hardware; Broadcom KB 416811 gives the cause as the converter failing to inject the driver for the assigned controller. There is no original virtual controller to return to, and trying other types is not a documented recovery.

Linux with dracut

With dracut, the initramfs holds the modules needed to mount the root file system. Upstream, host-only mode installs only what the local host needs, with the stated drawback: "you can't put the disk on another controller or machine ... without recreating the initramfs image". The --hostonly-mode setting has two values: "sloppy", which adds extra drivers so a minor hardware change does not make the image unbootable, and "strict", in which a minor hardware change can make it unbootable. Your distribution's packaged defaults can differ from upstream (host-only, sloppy), so read them.

The image is built for one kernel; with none given, "the version of the actual running kernel is used". After an update the next boot kernel can differ, so check the image of the kernel the boot loader will select.

KB 313507 lists Linux kernels with the in-kernel PVSCSI driver (RHEL 6+, SLES 11 SP1+, Ubuntu 10.04+) and recommends it.

Read-only checks

None of these was run for this article. They read state only; keep copies of the output for the change record.

  1. What changed: in vCenter, read the boot disk's controller type and the VM's task and event history. Compare with the last known good configuration.
  2. Snapshots: read the VM's snapshot list. Broadcom's procedures require no snapshots before a controller change.
  3. Supported combination: check the Broadcom Compatibility Guide for the guest OS release, the ESXi release and the target controller, and confirm the VM hardware version (7 or later for PVSCSI, per KB 313507).
  4. Windows, error: record the stop code shown on the console. Broadcom KB 414027 notes Safe Mode also fails when the PVSCSI driver is not detected; record whether it was tried, without treating it as a test of anything else.
  5. Windows, disk visibility: from Windows Recovery Environment, Microsoft's article uses diskpart with list disk and list vol to see whether the OS disk is visible. Use only the list commands. If the OS disk is not listed, Microsoft says to engage the OEM or virtualisation vendor; if listed, bcdedit with no arguments displays the boot entries. WinRE loads its own drivers, so a visible disk there shows the virtual hardware presents the disk; it does not prove the installed Windows has the boot driver present and enabled, or rule out a controller-path fault. Microsoft's Stop 7B article continues with further checks of the installed system rather than excluding the controller.
  6. Windows, before any planned switch: in the running guest, confirm VMware Tools is installed with the Paravirtual SCSI component, as KB 313507 requires.
  7. Linux, emergency shell: record the root device message and the kernel entry booted.
  8. Linux, image for the kernel that will boot: on a system that still boots, identify the default boot kernel and use lsinitrd on its image to check for the target controller's module (module names come from your distribution's documentation).
  9. Linux, dracut settings: read /etc/dracut.conf and the files in /etc/dracut.conf.d/ for hostonly, hostonly_mode and any driver lists.

Candidate causes (hypotheses to test)

Hypothesis What would support it What would weaken it Platform
Boot controller changed before its driver was installed Controller type changed in history; Stop 7B; installed OS lacks the boot driver or has it disabled Installed OS has the driver present and enabled for that controller (WinRE visibility alone does not decide this) Windows
P2V without driver for the assigned controller First boot after conversion fails; converter log VM booted on virtual hardware before Windows
VMware Tools removed after boot disk moved to PVSCSI Uninstall in guest or task history Tools component present Windows
Filter driver, BCD or file system problem BCD entries or filters wrong in the installed OS No such fault found in the installed OS Windows
Host-only image lacks the target module lsinitrd for the boot kernel lacks the module Module present in that image Linux
Boot kernel differs from the kernel the image was built for Default boot entry is a newer kernel than the running one Same kernel Linux
Guest release not supported with the controller Compatibility guide Listed as supported Both

Decision guidance

Every route below is a change. First: a verified restorable backup, no snapshots (Broadcom's requirement), the original controller and boot entries recorded as the rollback point, a change record, and a second person to review the vendor procedure against your versions. Rehearse on an isolated copy where possible; if anything is missing, stop and escalate.

Situation Decision Authoritative procedure
Known controller change, Windows, VM booted before Return the boot controller to its recorded type, then plan the driver installation separately Broadcom KB 341383; KB 414027 for the PVSCSI to LSI Logic SAS case
Planned move of a Windows boot disk to PVSCSI Install VMware Tools with the Paravirtual SCSI component first, then follow the vendor method Broadcom KB 313507 and KB 341383
P2V conversion, Windows Do not trial controller types; inject the driver only through the vendor procedure, or reconvert Broadcom KB 416811, which refers on to KB 313507 and, if failure persists, Microsoft Support
OS disk visible in WinRE, no known controller change Investigate the installed OS: boot-driver presence and start configuration, filter drivers, BCD and file system, following Microsoft's Stop 7B branches. Do not conclude the controller path is fine Microsoft's Stop 7B article; Microsoft Support for Server editions
Linux, module missing from the boot kernel's image Return to the recorded controller or boot a kernel whose image works, then add the module and rebuild for the kernel that will boot Your distribution's documentation for initramfs regeneration; dracut(8) and dracut.conf(5) for the options
Unsupported guest and controller combination Do not switch Broadcom Compatibility Guide

A reviewer should confirm before work starts:

  • Temporary disks. Broadcom's method adds and later removes a temporary disk on a second controller. Identify it by device node and size, remove it from the VM without deleting files, and never delete a production disk's files.
  • Rollback and fallback. Know the original controller type and, on Linux, the boot entry and image to select if the new image fails. The dracut manual recommends keeping a general purpose image and kernel as a fallback; confirm one boots before rebuilding.

What not to do

  • Do not try controller types one after another to find one that boots.
  • Do not edit offline registry Start values or delete filter driver entries without vendor support. Microsoft's article documents those steps for specific cases and also warns that disabling a service without removing its filter entry causes a 0x7b stop.
  • Do not use dracut's --drivers to replace the module list; the manual calls this option "not recommended" and "at your own risk".
  • Do not uninstall VMware Tools from a Windows guest that boots from PVSCSI.
  • Do not run chkdsk /f /r or rebuild boot files as a first response; they address corruption, not a missing driver.
  • Do not delete any virtual disk file during recovery.

Limitations

  • Nothing here was run; lab validation is outstanding, so no recovery steps are given.
  • Microsoft's Stop 7B article is scoped to Windows Client; Windows Server editions are not separately covered by it.
  • Broadcom's controller-change KBs list vSphere 7.x and 8.x (KB 313507 also 9.0); their dates were not displayed.
  • The dracut pages are upstream rolling documentation (dracut 2026-08-03 snapshot) and do not certify any distribution's defaults or packaged version.
  • initramfs-tools, kernel module names per controller, NVMe and SATA virtual controllers are not covered.

Acceptance checklist

  • [ ] The case is identified (known controller change, P2V, unrelated Windows boot fault, Linux image) from read-only evidence.
  • [ ] The guest and host combination is supported for the target controller.
  • [ ] No snapshots exist and a verified backup is recorded before any change.
  • [ ] Rollback point recorded and the vendor procedure named in the change record and reviewed by a second person.
  • [ ] Windows: the driver is shown installed before the boot controller is switched.
  • [ ] Linux: lsinitrd shows the module in the image of the kernel the boot loader will select.
  • [ ] Any temporary disk identified before removal; no disk files deleted.
  • [ ] Two clean boots on the final configuration with all disks present.

Sources

Displayed dates as shown when accessed on 30 October 2026.

Related articles

Learning notes

  1. The boot disk's controller driver must load before the root file system; a new controller type needs its driver first.
  2. Stop 7B has several causes; WinRE uses its own drivers, so a visible OS disk there does not clear the installed system's boot driver or controller path.
  3. A known controller change and a P2V conversion have different vendor procedures.
  4. On Linux, check the image of the kernel that will boot, not only the running one.
  5. Recovery is a reviewed change with a verified backup and rollback point, never a trial of settings.