Migrating Debian 13 from VMware ESXi to Proxmox: Fixing Networking and Installing QEMU Guest Agent

By William Rendell | 23 October 2026

As part of my ongoing migration from VMware ESXi to Proxmox VE, I’ve been moving several virtual machines across to our new Proxmox cluster.

One of these was a Debian 13 (Trixie) virtual machine running Uptime Kuma, which I use for monitoring systems and services.

The migration itself was straightforward, but there were two issues worth documenting: the network interface stopped working after switching to VirtIO, and the QEMU Guest Agent initially refused to start.

Both problems turned out to have simple solutions once I’d identified the causes.

This guide covers exactly what happened, how I fixed it, and the commands you can use if you’re migrating Debian VMs from VMware to Proxmox.

The environment

My setup for this migration was:

• Source hypervisor: VMware ESXi
• Destination hypervisor: Proxmox VE 9.2
• Guest operating system: Debian 13 (Trixie)
• Application: Uptime Kuma running in Docker
• Original network adapter: VMware VMXNET3
• Replacement adapter: VirtIO (paravirtualized)
• Guest integration: QEMU Guest Agent

The objective was to remove the remaining VMware-specific components and configure the VM to run properly under Proxmox.

1. Changing the network adapter from VMXNET3 to VirtIO

After importing the VM into Proxmox, I wanted to replace the existing VMware VMXNET3 network adapter with VirtIO.

VirtIO is the recommended paravirtualized network adapter for modern Linux guests running under Proxmox. It provides efficient communication between the VM and the hypervisor.

In the Proxmox interface:

1. Select the virtual machine.
2. Open Hardware.
3. Select Network Device and click Edit.
4. Change the model to VirtIO (paravirtualized).
5. Preserve the existing MAC address, bridge and VLAN configuration.
6. Start the VM.

Before changing a network adapter, it’s sensible to record the existing IP address and network configuration. Make sure you have console access, as SSH may stop working.

The first problem: Debian lost its IP address

After switching to VirtIO, the VM no longer obtained an IP address.

Checking the network configuration showed:

cat /etc/network/interfaces

The relevant section contained:

# The primary network interface
allow-hotplug ens192
iface ens192 inet dhcp

This was the original VMware network interface.

However, when I checked the available interfaces:

ip -br addr

The new VirtIO adapter appeared as:

ens18    DOWN

The old ens192 interface was no longer present.

Debian was still configured to obtain its DHCP address through an interface that no longer existed.

2. Fixing Debian networking after migration

The solution was to update /etc/network/interfaces to reference the new VirtIO interface.

Edit the file:

nano /etc/network/interfaces

Replace:

allow-hotplug ens192
iface ens192 inet dhcp

With:

auto ens18
iface ens18 inet dhcp

The important detail is to use the actual interface name reported by Debian. Your VM may have a different name depending on its virtual hardware configuration.

Save the file, then bring up the interface:

ifup ens18

Check the result:

ip -br addr
ip route

If DHCP is working, the interface should now have an IP address and the routing table should contain the expected default gateway.

Why auto ens18 mattered

I initially got the interface working, but after rebooting the VM, it lost its IP address again.

The missing detail was the auto ens18 line.

Adding this ensured that Debian’s ifupdown networking configuration brought the interface up during system startup.

After making the change, networking worked correctly following a reboot.

Lesson learned: When changing network adapters during a VMware-to-Proxmox migration, always check both the interface name and the configuration used to activate it at boot.

3. Removing VMware Tools from Debian 13

Once networking was working, the next job was to remove the VMware-specific guest utilities.

First, check whether VMware Tools are installed:

dpkg -l | grep -E 'open-vm-tools|vmware'

For the standard Debian package installation, remove them with:

apt purge open-vm-tools

If the desktop package is also installed, it can be removed:

apt purge open-vm-tools-desktop

Review the package removal list before proceeding.

VMware Tools aren’t necessarily harmful if left installed, but they serve little purpose once the VM has moved permanently to Proxmox.

If VMware Tools were installed using VMware’s older manual installer rather than Debian packages, the removal procedure may be different.

4. Installing QEMU Guest Agent on Debian 13 Trixie

Proxmox uses QEMU Guest Agent to communicate with the operating system inside a VM.

It enables useful features including reporting guest IP addresses, coordinated shutdown operations and filesystem freeze/thaw operations for certain backups.

Install it using:

apt update
apt install qemu-guest-agent

I then tried:

systemctl enable --now qemu-guest-agent

But Debian returned a message explaining that the service had no installation configuration and was a static unit.

This initially looked like a problem.

Why the service is static

On Debian 13, the QEMU Guest Agent systemd unit can be activated when the required virtual device is available.

It doesn’t necessarily need to be enabled using systemctl enable.

The important check is whether the service is running:

systemctl status qemu-guest-agent

In my case, however, attempting to start it resulted in:

A dependency job for qemu-guest-agent.service failed.
See 'journalctl -xe' for details.

That led to the second problem.

5. Fixing the QEMU Guest Agent dependency failure

The first thing I checked was whether Debian could see the guest-agent virtual device.

Run:

ls -l /dev/virtio-ports/

Initially, the result was:

ls: cannot access '/dev/virtio-ports/':
No such file or directory

That was the clue.

The QEMU Guest Agent package was installed, but the virtual communication device wasn’t available inside the guest.

Enable the agent in Proxmox

In the Proxmox interface:

1. Select the VM.
2. Open Options.
3. Select QEMU Guest Agent and click Edit.
4. Tick Use QEMU Guest Agent.
5. Save the settings.

I also left the filesystem freeze/thaw option enabled for supported backup operations.

Even after confirming the agent was enabled in Proxmox, Debian still couldn’t see the device.

The fix: fully shut down and restart the VM

The solution was to shut down the virtual machine completely and then start it again from Proxmox.

This is different from simply rebooting Debian inside the VM.

After the full shutdown and restart, I checked again:

ls -l /dev/virtio-ports/

This time, the output showed:

org.qemu.guest_agent.0 -> ../vport1p1

The virtual communication device was now available.

I checked the service:

systemctl status qemu-guest-agent

And received:

Active: active (running)
Main PID: 552 (qemu-ga)
Memory: 2.5M

Success! The QEMU Guest Agent was running correctly.

6. Verifying QEMU Guest Agent from Proxmox

The final check is to confirm that the Proxmox host can communicate with the agent.

From the Proxmox host shell, run:

qm agent <VMID> ping

Replace <VMID> with the actual virtual machine ID.

For example, for VM 120:

qm agent 120 ping

If the command completes without an error, the guest agent is responding.

You can also request the guest’s network interface information:

qm guest cmd 120 network-get-interfaces

With the agent functioning, Proxmox can retrieve information about the operating system running inside the VM.

7. My post-migration checklist

For future Debian migrations, I’ll be using this checklist:

• Confirm the VM boots correctly under Proxmox.
• Check the network adapter model and switch to VirtIO where appropriate.
• Verify the new Linux interface name.
• Update /etc/network/interfaces or the relevant network manager configuration.
• Confirm the IP address, gateway and DNS are working.
• Reboot and confirm networking survives.
• Remove VMware Tools where appropriate.
• Install QEMU Guest Agent.
• Enable QEMU Guest Agent in Proxmox.
• Fully shut down and restart the VM if the guest-agent device is missing.
• Confirm the guest agent is active.
• Test application services and monitoring.
• Verify backups are configured and working.

Final thoughts

Moving Debian virtual machines from VMware ESXi to Proxmox is generally straightforward, particularly with modern Linux distributions that already include VirtIO drivers.

However, there are a couple of small details that can cause unnecessary downtime.

In my case, the two most important lessons were:

First: Switching from VMXNET3 to VirtIO changed the network interface from ens192 to ens18. Debian’s network configuration needed updating, including the auto ens18 line.

Second: Installing QEMU Guest Agent wasn’t enough on its own. The virtual device needed to be present, and a complete VM shutdown and restart resolved the issue.

With both changes completed, my Debian 13 Uptime Kuma VM was running properly under Proxmox, with working networking and guest-agent integration.

I’m continuing to migrate the remaining VMware workloads across to Proxmox, so I’ll be documenting more of the process as I go.

If you’re doing a similar migration, hopefully these notes save you some troubleshooting time.

William Rendell

Useful references

• Proxmox VE — Migrating to Proxmox
• Debian 13 QEMU Guest Agent package
• QEMU Guest Agent documentation