Proxcenter Warm Migration Pre-req's need to be manually installed moving forward?

[neilcolyn-jpg]

Just looking for confirmation, Warm Migration pre-req packages need to be manually installed and Proxcenter no longer provides the option to install the required packages from Proxcenter migration wizard?

[adminsyspro]

Hi Neil,

Confirmed: for warm migration, the runtime on the Proxmox node has to be installed manually, once per node. ProxCenter doesn't auto-install it, and it runs the readiness check you're seeing to block a migration that would otherwise fail mid-flight.

This is by design, not a removed option. Two of the four pieces genuinely can't be installed automatically:

• The Broadcom VDDK (libvixDiskLib) is a proprietary SDK. It can't be redistributed or fetched without a Broadcom account and acceptance of the license, so we can't ship it or pull it down for you. You get it here: https://developer.broadcom.com/sdks/vmware-virtual-disk-development-kit-vddk/latest/
• The nbdkit VDDK plugin (nbdkit-plugin-vddk) lives in Debian non-free, which a stock Proxmox node doesn't enable. Turning on non-free is a system-wide change we won't make silently on your node.

The other two (nbdkit, nbd-client) are in Debian main and are a plain apt install.

What you may be remembering is the offline (cold) migration path: that one does auto-install its tooling (nbdkit + libnbd-bin, both open source) during the migration. Warm is the exception, purely because of the proprietary VDDK.

The full step-by-step node setup (including the VDDK 9.x library-name symlink that nbdkit needs) is now documented here:
https://docs.proxcenter.io/automation/migration#warm-migration-node-setup

Once the node has all four components, reselect it in the dialog and the banner turns green.

[neilcolyn-jpg]

Thank you for confirming that.

Can you also please confirm the VirtIO Windows agent/driver injection for warm migrations no longer happen and needs to be manually afterwards?

Thanks!

[adminsyspro]

You've got it right, for warm migration, ProxCenter does not inject the VirtIO drivers or the QEMU Guest Agent. Those have to be installed manually inside Windows after the cutover.

The reason warm differs from cold:

• Cold migration of a Windows VM runs through virt-v2v, which operates on the powered-off disk: it mounts the guest offline, adds the boot-critical viostor driver to the registry, and drops a firstboot script that installs virtio-win-guest-tools (VirtIO drivers plus the QEMU Guest Agent). That is inherently an offline operation.
• Warm migration keeps the source VM running and copies only changed blocks live (CBT/VDDK). Running virt-v2v's offline registry surgery on a disk that is still changing underneath us is not safe, so warm skips it by design. The disk lands on Proxmox as a faithful block-for-block copy of what was on ESXi (VMware Tools still inside, no VirtIO).

So the guest boots, but without VirtIO. To keep that first boot reliable, the warm target VM is created with an LSI SCSI controller and an e1000 NIC (both have built-in Windows drivers), and the agent flag is enabled on the Proxmox side even though the agent service is not yet installed in the guest.

Recommended post-migration steps on the Windows guest:

1. Mount the virtio-win ISO and run virtio-win-guest-tools.exe (installs the storage, network and balloon drivers plus the QEMU Guest Agent service).
2. Optionally uninstall VMware Tools.
3. Once VirtIO is in and confirmed working, you can switch the disk controller to virtio-scsi-single and the NIC to virtio for better performance (shut down, change in the VM hardware tab, boot).

That manual driver step is the trade-off for warm's near-zero downtime. If you'd prefer the drivers and agent injected automatically and can take the VM down for the copy, use a cold migration instead.