Moved a machine from VMware and it will not boot: the disk is there, the road to it is not

The import finished, the disk is listed, the machine starts, and then it stops with a message about a boot device it cannot reach. The instinct at that moment is that something was lost in the conversion. Almost always nothing was lost.

The disk is where it should be. What changed is the road to it.

Why it happens

A virtual machine does not talk to a disk. It talks to a disk controller, and the controller is part of what the hypervisor presents to it. VMware presented one kind. Proxmox presents another.

That would be harmless if the guest loaded every driver it might ever need. It does not. An operating system loads only a small set of drivers before it has access to its own disk, and that set was decided on the day it was installed. If the controller in front of the disk is not in that set, the guest can see nothing to boot from, and it says so in the only way it can: there is no boot device.

So the symptom points at the disk and the cause is one layer in front of it.

Two different failures that look alike

They get treated as one problem and they are not.

No boot device at all. Often firmware, not the controller. A machine created under EFI does not boot under a legacy BIOS, and the reverse is also true. Nothing about the disk is wrong; the machine is being started in a way it was never installed for.

Boot starts, then stops complaining about the boot device. This is the controller case. Firmware was right, the loader ran, and then the kernel could not reach the disk it was told to use.

Telling these two apart before changing anything saves the whole afternoon, because the fixes are different and applying the wrong one produces a second symptom on top of the first.

Three questions before touching anything

Is the disk actually attached to the machine? Look at the machine's configuration, not at the storage. An imported disk can end up present on the storage but unattached, and that is a two second fix that looks like a catastrophe.

Which firmware was this machine installed under? If it came from an EFI environment it needs one, and it also needs somewhere to keep its boot entries.

Does the guest have the driver for the new controller at all? Not "is it installed", but "does it exist inside that disk image". A Windows machine that has never met a VirtIO controller does not have that driver, and it cannot fetch it while it is unable to boot.

The way out that is reversible

There are two approaches and they are not equally safe.

Give the guest a controller it already knows. Attach the disk on an interface the guest has supported since the day it was installed, boot normally, install the new driver from inside the running system, shut down, then switch the controller. Each step is small and each one can be undone.

The trick that makes this painless: before switching, attach a second, tiny disk on the new controller type. The guest boots on the old road, sees unknown hardware, and lets you install the driver for it calmly. Then the switch of the real disk is uneventful, because the driver is already there.

Inject the driver into the image from outside. Faster and it works, but if it does not work you are left debugging an image that is now different from the one you started with. It is the right tool when you have many machines and a known recipe. It is the wrong tool for the first one.

⚠️ Change one thing at a time. Firmware and controller together is the most common way to turn a solvable problem into an unclear one: the machine still does not boot and now there are two candidates.

Linux guests: same cause, quieter symptom

The same thing happens and it reads differently. The boot loader runs, then the system stops waiting for a root device that never appears. The reason is identical: the early boot image was built without the driver for the new controller, because on the old hypervisor it was never needed.

The fix is also the same shape. Boot from a rescue image, rebuild the early boot image with the driver included, and only then switch the controller.

What not to do

Do not rebuild the machine and attach the old disk to it. The new machine will have the same controller and the same result, and now you have two machines to keep track of.

Do not delete the source machine yet. The migration is finished when the new one has booted, done real work and been backed up. Not when the copy completes.

Do not disable the fast startup setting later and be surprised. A Windows guest that was shut down with fast startup enabled does not fully shut down, so a hardware change made in that state is met by a system that thinks it is resuming, not starting.

What Atlas does

Atlas puts the two things this problem lives between on the same screen. The machine's hardware view shows the disk, the controller it is attached to and the firmware setting together, so the question "which of the two is wrong" is answered by looking rather than by trying.

The resource chain also answers the first of the three questions directly: the map draws the machine down to the physical disk, so a disk that was imported but never attached is visibly missing from the chain rather than hiding in a storage list.

Before a change like this is applied, Atlas takes a snapshot, so the reversible path stays reversible even if the guest reacts badly. The affected resources are listed before the change runs, which is what makes changing one thing at a time practical instead of merely advisable.