Veeam Agent for Windows can restore a full system image to completely different hardware. That includes moving a physical server (or a VMware/Hyper-V VM) to a KVM-based cloud VPS. The catch: KVM uses VirtIO paravirtualized drivers for storage and networking. Without them in your recovery media, the restore environment cannot see the target disk or reach your backup repository.

This guide covers preparing VirtIO drivers on the source, building a recovery ISO that includes them, restoring to a Virtua.Cloud VM, and validating the result.

What do you need before migrating a Windows server with Veeam?

You need Veeam Agent for Windows (version 6.3 or later in standalone mode, or version 13 if managed by Veeam Backup & Replication) installed on the source server, an image-level backup stored on a network-accessible SMB or NFS share, and the VirtIO driver package. The source server must be running Windows Server 2016 or later.

Requirement	Details
Veeam Agent for Windows	v6.3+ (standalone) or v13 (managed by VBR)
Backup type	Image-level (entire computer or volume-level with system volumes)
Backup location	SMB share or NFS export reachable from the target VM's network
VirtIO drivers	virtio-win latest stable (currently 0.1.285)
Windows ADK	Required if Windows RE components are missing on source
Target VM	Disk size >= source used space + 10% headroom

Before starting, confirm your Veeam Agent version (Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like "*Veeam*" }), check used disk space across all volumes, and verify that a recent image-level backup exists on the network share.

How do you create a Veeam recovery ISO with VirtIO drivers?

Download the VirtIO driver package, install it on the source server, then create a Veeam recovery ISO. The "Include hardware drivers from this computer" option captures installed VirtIO drivers and embeds them into the WinPE-based recovery image. This is the only reliable way to get VirtIO storage and network drivers into the recovery environment.

Why are VirtIO drivers required for cloud VMs?

KVM hypervisors expose storage and network devices through VirtIO paravirtualized interfaces. Standard Windows drivers do not recognize these devices. Without VirtIO drivers in the recovery environment, the Veeam restore wizard cannot detect the target VM's disk and cannot connect to your backup repository over the network. The restore fails before it starts.

Three drivers matter for migration:

Driver	Purpose	Device Manager entry after install
viostor / vioscsi	VirtIO block or SCSI storage controller	Red Hat VirtIO SCSI controller
NetKVM	VirtIO network adapter	Red Hat VirtIO Ethernet Adapter
Balloon	Dynamic memory management	VirtIO Balloon Driver

How do you install VirtIO drivers on the source server?

Download the latest stable ISO from the Fedora virtio-win project. Mount it and run the guest tools installer:

# Download the virtio-win ISO
Invoke-WebRequest -Uri "https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso" -OutFile "C:\Temp\virtio-win.iso"

# Mount the ISO
$mount = Mount-DiskImage -ImagePath "C:\Temp\virtio-win.iso" -PassThru
$driveLetter = ($mount | Get-Volume).DriveLetter

# Run the guest tools installer (silent, all drivers)
Start-Process -FilePath "${driveLetter}:\virtio-win-guest-tools.exe" -ArgumentList "/silent" -Wait

The installer deploys NetKVM, viostor, vioscsi, Balloon, and several other VirtIO drivers into the Windows driver store. Confirm they landed:

Get-WindowsDriver -Online | Where-Object { $_.ProviderName -eq "Red Hat, Inc." } | Select-Object ClassName, Driver, ProviderName

ClassName   Driver         ProviderName
---------   ------         ------------
Net         oem12.inf      Red Hat, Inc.
SCSIAdapter oem13.inf      Red Hat, Inc.
SCSIAdapter oem14.inf      Red Hat, Inc.
System      oem15.inf      Red Hat, Inc.

The output lists Net (NetKVM), SCSIAdapter (viostor/vioscsi), and System (Balloon) classes.

How do you embed drivers into the recovery media?

With VirtIO drivers now in the Windows driver store, create the recovery ISO:

Open Start > Veeam > Create Recovery Media
At the Recovery Media Options step, select ISO file as the media type
Check Include hardware drivers from this computer. This captures the VirtIO drivers you just installed.
Optionally check Include network connection settings from this computer if the target VM will use similar network config
Under Include the following additional storage and network hardware drivers, click Add and point to the mounted VirtIO ISO folder ${driveLetter}:\ as a fallback. The folder must contain the driver's CAT, INF, and SYS files. Do not add more than 1 GB of drivers, as they load into RAM at boot and can prevent WinPE from starting.
Choose an output path for the ISO. Name it something identifiable: veeam-recovery-virtio.iso
Click Create and wait for the wizard to finish

The resulting ISO is a WinPE image with Veeam's recovery tools and your VirtIO drivers baked in. Keep it accessible; you will send it to Virtua.Cloud support.

How do you order and prepare the target VM?

Order a Windows-capable VM from Virtua.Cloud with enough disk to hold your restored data. Send the recovery ISO to support for mounting before first boot.

What disk size does the target VM need?

The target disk must be at least as large as the sum of your used space across all source volumes, plus 10% headroom. Veeam can shrink partitions during restore, but it cannot restore to a disk smaller than the actual data.

Formula: target disk >= total used space x 1.1

From the earlier example (42.3 GB + 87.1 GB = 129.4 GB used), you need at minimum 143 GB. Round up to the nearest available option.

Do not match the source disk's allocated size. If your source has a 500 GB disk but only uses 130 GB, a 160 GB target disk works fine.

How do you get the ISO mounted?

Order your VM through the Virtua.Cloud control panel. Select a plan with sufficient disk, RAM, and CPU for your workload.
Open a support ticket requesting custom ISO mounting. Attach or provide a download link for your veeam-recovery-virtio.iso.
Ask support to mount the ISO as the primary boot device and confirm when ready.
Support will confirm the ISO is mounted and the VM is set to boot from it.

While waiting, note your VM's network details from the control panel: IP address, subnet mask, gateway, and DNS servers. You will need these to configure networking inside WinPE.

How do you restore a Veeam backup to a cloud VM?

Boot the VM from the recovery ISO via the VNC console, configure networking manually in WinPE, connect to your backup repository, and run the bare-metal restore wizard.

How do you boot and access the recovery environment?

Open the VNC console for your VM from the Virtua.Cloud control panel
The VM boots from the mounted ISO into the Veeam Recovery Media environment
Wait for the WinPE desktop to load with the Veeam Bare Metal Recovery interface

If the VM boots to a UEFI shell or a blank screen instead of WinPE, contact support to verify the boot order. The ISO must be the first boot device.

How do you configure networking in the WinPE recovery environment?

The recovery environment needs network access to reach your backup repository. Cloud VMs rarely get DHCP on first boot. Configure the adapter manually.

In the Veeam Recovery Media screen, click Network Settings (bottom-right corner)
If the adapter list is empty, VirtIO network drivers did not load. Click Load network adapter driver, select the NetKVM driver from the Hardware Drivers window, and click Install.
Select the network adapter in the list. Click Properties.
Enter the static IP configuration from your VM's control panel:
- IP address
- Subnet mask
- Default gateway
- DNS server
Click OK to apply

Test connectivity by opening a command prompt from the recovery environment (press Shift+F10 if needed):

ping 8.8.8.8
ping your-backup-server.example.com

If ping works but DNS fails, verify the DNS server address. For SMB shares, test the path directly:

net use \\backup-server\share /user:domain\username

How do you connect to the backup repository?

Back in the Veeam interface, click Bare Metal Recovery
At Backup Location, select Network storage
Select Shared folder (for SMB) or Linux-based (for NFS)
Enter the UNC path to your backup: \\backup-server\share\VeeamBackup\ServerName
Provide credentials when prompted
Veeam scans the location and lists available backups
Select your server's backup and pick the restore point (usually the most recent)

How do you map source disks to the target VM?

After selecting the restore point, choose Entire computer as the restore mode. Veeam opens the Disk Mapping screen showing your source volumes on the right and the target disk on the left.

If the target disk is not visible, click Load driver and install the VirtIO SCSI driver (vioscsi or viostor) from the Hardware Drivers list.

For a single-disk target VM:

Right-click the target disk and select Apply Backup Layout. This recreates the source partition structure on the target disk.
If the target disk is larger than the source, the extra space becomes unallocated. You can expand the last partition later in Windows Disk Management.
If the target disk is smaller (but larger than used data), Veeam automatically shrinks partitions to fit. Review the proposed layout before proceeding.

For servers with multiple source disks mapped to a single target disk, use Customize disk mapping to place volumes manually. Right-click unallocated space on the target disk and select which source volume to restore there. Use Resize to adjust partition sizes.

Check the Inject these drivers into operating system while performing bare metal recovery checkbox. This writes the VirtIO drivers into the restored Windows installation, which prevents boot failures caused by missing storage drivers.

Click Restore to start. The duration depends on backup size and network speed between the backup repository and the VM. A 100 GB restore over a 1 Gbps link takes roughly 15-20 minutes.

What should you check after the restore completes?

Once the restore finishes, request ISO unmount from support, reboot the VM into Windows, and validate drivers, networking, and activation.

Post-restore procedure

Request ISO unmount. Open your support ticket and ask Virtua.Cloud to unmount the recovery ISO and set the hard disk as the primary boot device.
Reboot the VM. Use the VNC console to watch the first boot. Windows may take longer than usual as it detects new hardware and configures drivers.
Log in via VNC. RDP will not work until you confirm network configuration.

How do you verify VirtIO drivers are loaded?

Open Device Manager and check for any devices with yellow warning icons. Then confirm the VirtIO drivers specifically:

Get-PnpDevice | Where-Object { $_.FriendlyName -like "*VirtIO*" -or $_.FriendlyName -like "*Red Hat*" } | Select-Object Status, Class, FriendlyName

Status Class           FriendlyName
------ -----           ------------
OK     Net             Red Hat VirtIO Ethernet Adapter
OK     SCSIAdapter     Red Hat VirtIO SCSI controller
OK     System          VirtIO Balloon Driver

Every entry should read OK. If any show Error or Degraded, the driver did not install correctly. Download the VirtIO guest tools installer onto the VM and run it:

# If drivers are missing post-restore
Invoke-WebRequest -Uri "https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win-guest-tools.exe" -OutFile "C:\Temp\virtio-win-guest-tools.exe"
Start-Process -FilePath "C:\Temp\virtio-win-guest-tools.exe" -ArgumentList "/silent" -Wait
Restart-Computer

How do you validate networking and RDP?

The restored OS may carry the source server's IP configuration. Open Network Connections, update the adapter to match your VM's assigned IP, subnet, gateway, and DNS from the control panel.

Test outbound connectivity with Test-NetConnection -ComputerName 8.8.8.8 -Port 443. Then try RDP from your workstation. If RDP does not connect, enable the firewall rule:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Does Windows need reactivation after a P2V migration?

Yes, usually. A P2V migration changes enough hardware identifiers that Windows sees it as a new machine and requires reactivation. The behavior depends on your license type:

Retail / OEM license: Hardware change triggers reactivation. Use slmgr /ato to attempt online activation. If it fails, phone activation or a support ticket to Microsoft is needed.
KMS (volume licensing): The VM contacts your KMS server automatically. Run slmgr /ato to force an immediate activation attempt.
MAK (Multiple Activation Key): Re-enter the key with slmgr /ipk YOUR-MAK-KEY then slmgr /ato.
AVMA (Automatic Virtual Machine Activation): Only works on Hyper-V hosts running Windows Server Datacenter. Does not apply to KVM VMs.

Check current activation status:

slmgr /dli

A dialog appears showing the license status. "Licensed" means activation succeeded. "Notification" or "Grace period" means you need to reactivate.

For volume license customers, also verify the KMS server is reachable from the new VM's network.

Troubleshooting common restore failures

INACCESSIBLE_BOOT_DEVICE blue screen after restore

This is the most common failure. Windows cannot find a storage driver for the VirtIO disk controller at boot time.

Cause: The VirtIO storage driver (vioscsi or viostor) was not injected into the restored OS. Either the "Inject these drivers" checkbox was unchecked during restore, or the recovery media did not contain VirtIO storage drivers.

Fix: Boot the recovery ISO again. Instead of running a full restore, open a command prompt (Shift+F10) and manually load the VirtIO driver into the offline Windows installation:

drvload X:\Drivers\vioscsi\2k22\amd64\vioscsi.inf

Replace X: with the drive letter where recovery media drivers are stored, and 2k22 with your Windows Server version folder (2k16, 2k19, 2k22, or 2k25). After loading the driver, use DISM to inject it permanently into the offline OS:

dism /image:C:\ /add-driver /driver:X:\Drivers\vioscsi\2k22\amd64

If this does not resolve it, re-run the full restore with VirtIO drivers properly embedded in the recovery media and the "Inject these drivers" checkbox enabled.

No network adapters visible in WinPE

Cause: The NetKVM driver is missing from the recovery media.

Fix: If you added the VirtIO ISO as an additional driver source during media creation, click Load network adapter driver in the Network Settings screen and browse to the NetKVM folder on the recovery media. Select the INF file matching your Windows version.

If no VirtIO drivers are present at all, you need to recreate the recovery ISO with VirtIO drivers installed on the source server first.

Target disk not visible in the disk mapping screen

Cause: The VirtIO SCSI driver is not loaded in WinPE.

Fix: Click Load driver in the Disk Mapping step. Select the vioscsi or viostor driver from the Hardware Drivers list. If the driver is not listed, click Load Driver and browse to the driver INF file on the recovery media.

Restore fails because the target disk is too small

Cause: The target disk is smaller than the total data in the backup.

Fix: You cannot shrink beyond used space. Either order a VM with a larger disk, or reduce data on the source server before taking a new backup. Delete temp files, clear Windows Update cache (Dism.exe /online /Cleanup-Image /StartComponentCleanup), and remove unnecessary data before running a fresh image-level backup.

Windows activation fails after restore

Cause: Hardware fingerprint changed. Expected after any P2V migration.

Fix: For retail keys, run slmgr /ato. If online activation fails, use phone activation: slui 4. For volume license keys, verify KMS server connectivity: nslookup -type=srv _vlmcs._tcp.yourdomain.com. For MAK keys, re-enter the key: slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX then slmgr /ato.