Troubleshooting VM Boot Failures from SCSI Controller Conflicts
A virtual machine that suddenly stops at “Operating System Not Found”, enters an endless reboot cycle, or drops into a Windows recovery screen may have a storage presentation problem rather than a damaged guest OS. In VMware environments, the virtual SCSI controller determines how the guest sees its boot disk, data volumes, and attached devices.
Controller conflicts commonly appear after a disk migration, template change, hardware version upgrade, recovery operation, or manual edit to the VM configuration. A change that looks harmless in vSphere can alter the controller type, SCSI address, or driver requirement presented during startup.
This issue is especially relevant in Australian organisations where a small infrastructure team may support production systems across Sydney, Melbourne, Brisbane, Perth, or regional sites. A failed VM during an overnight maintenance window can quickly become an “arvo” problem if the original configuration is not documented.
The safest response is a controlled comparison of the working configuration, the recent change, and the guest operating system’s storage drivers. Avoid repeatedly changing settings at random, because each boot attempt can make the final state harder to identify.
| Boot symptom | Common SCSI-related cause | First check |
|---|---|---|
| Operating system not found | Boot disk is disconnected or on the wrong controller | Confirm disk attachment and boot order |
| Blue screen or INACCESSIBLE_BOOT_DEVICE | Guest lacks the required controller driver | Compare controller type with installed drivers |
| Linux drops to initramfs | Device name or storage module changed | Inspect initramfs and /etc/fstab |
| VM hangs during startup | Controller or disk configuration is inconsistent | Review recent hardware and snapshot changes |
Confirm What Changed Before Editing
Start with the VM’s Events and Tasks history in vCenter. Look for disk moves, controller additions, template customisation, storage vMotion, snapshot operations, or changes made by automation. PowerCLI history, Git-managed configuration, and change records can help establish whether the failure began after a predictable action.
Record the current controller type, bus number, device address, disk filename, provisioning mode, and virtual hardware version. Compare these values with a known-good VM from the same template. A configuration export is useful before making repairs, particularly where the VM supports a critical application.
Inspect Controller Type And Bus Placement
VMware commonly presents disks through LSI Logic SAS, LSI Logic Parallel, or VMware Paravirtual SCSI (PVSCSI). PVSCSI is generally preferred for high-I/O workloads, but the guest must have the appropriate driver available. Older Windows builds, recovery environments, and some Linux initramfs images may fail when a disk is moved to a controller they cannot initialise.
The boot disk should normally remain on a controller that the guest can access during early startup. Data disks can use a second controller, but verify that the bus number and SCSI ID are valid and do not conflict with another device. A disk connected at SCSI (1:0) is not interchangeable from the guest’s perspective with every other address, especially when software or scripts expect stable device paths.
Check Windows Driver And Boot Records
For Windows, an INACCESSIBLE_BOOT_DEVICE stop error often indicates that the storage driver is disabled, missing, or not available early enough in the boot process. If the VM previously used LSI Logic and was switched directly to PVSCSI, restore the original controller temporarily or attach the required VMware driver before changing it again.
Use Windows Recovery Environment to inspect startup repair results, boot configuration data, and system logs. If the operating system starts after restoring the old controller, install or enable the PVSCSI driver while the VM is stable, then schedule a planned controller migration. Desktop virtualisation environments should also account for the storage model used by linked clones or instant-clone workflows; the Horizon deployment guide provides useful context when troubleshooting those dependencies.
Validate Linux Device Discovery
Linux guests may boot into an initramfs shell when a controller change alters device discovery. Check whether the root volume is present with tools such as lsblk, blkid, and lsscsi. Review /etc/fstab for references to changing device names, and prefer UUID or filesystem labels where appropriate.
If the root disk is visible but the required module is absent, rebuild the initramfs using the distribution’s supported method. Also check bootloader settings and multipath configuration on systems connected to shared storage. A controller adjustment should be tested against the exact kernel and distribution release, rather than assumed to work because another Linux VM uses the same setting.
Rule Out Storage And Snapshot Confusion
A SCSI fault can resemble a datastore problem. Confirm that the VMDK is present, accessible, and still mapped to the intended datastore. Check for inaccessible snapshot delta files, locked disks, stale replicas, or a failed storage migration. Do not consolidate snapshots blindly when the VM’s disk chain is already under investigation.
For clustered applications, verify whether multi-writer disks, bus sharing, or guest clustering settings are involved. A controller change that is safe for a standalone file server may be unsuitable for a database cluster. The vSphere cluster practices guide is a useful reference when separating guest boot issues from broader cluster configuration risks.
Use A Controlled Recovery Sequence
Power off the VM and take a configuration backup or export where operational policy permits. Disconnect nonessential data disks, leaving the suspected boot volume attached to the controller and address used by the last known-good state. Avoid deleting disks or removing controllers until their dependencies are recorded.
Test the VM after each single change. If it boots, document the working controller, bus, and driver state before reconnecting additional volumes. When the guest remains offline, attach its boot disk to a temporary recovery VM only if application and licensing requirements allow it, and use that system to inspect files, drivers, and boot records without modifying the original unnecessarily.
Prevent Repeat Failures During Maintenance
Standardise controller choices in templates and document when PVSCSI is appropriate. Include controller type, SCSI addresses, boot order, guest drivers, and disk roles in the build record. Templates should be updated in a test folder first, with a full boot validation before they are used for production deployments.
Automated maintenance also needs guardrails. Validate VM hardware changes in a staging cluster, log the before-and-after configuration, and ensure the task does not detach the boot disk accidentally. A controlled approach to ESXi update automation can reduce unrelated maintenance risk by making host changes repeatable and auditable.
When a VM will not boot, treat the SCSI controller as part of the guest’s boot dependency chain. Compare the known-good state, restore the smallest necessary change, verify the driver path, and record the final configuration. Add these checks to runbooks used by teams supporting Australian sites and after-hours operations, then apply the same discipline to templates, recovery tests, and automation pipelines.