Skip to content

Ubuntu Guest Has No Network After V2V Import

Symptom: a VMware → KVM V2V import of an Ubuntu Server guest completes successfully, the VM boots, but it's unreachable on the network — console login works, but there's no IP and nothing responds to ping.

Confirm it

In the guest console:

ip a
ip link show
lspci | grep -i eth
dmesg | grep -i eth

If you see something like this, the NIC and driver are actually fine — the problem is guest network configuration, not a missing driver:

2: enp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:50:56:a2:21:b6 brd ff:ff:ff:ff:ff:ff

01:00.0 Ethernet controller: Red Hat, Inc. Virtio network device (rev 01)

[    1.649140] virtio_net virtio0 enp1s0: renamed from eth0

lspci shows the virtio NIC, dmesg confirms the virtio_net driver loaded and bound it, so do not go looking for a driver to install — it's already there. The interface just isn't configured/up.

Root cause 1 — netplan still references the old VMware interface name

VMware presents the NIC as vmxnet3 or e1000, which Ubuntu names something like ens160. KVM presents it as virtio-net, which gets a different predictable name — typically enp1s0 — because predictable naming is derived from the PCI bus path, and that path changed with the hypervisor. The netplan config written by the installer (subiquity) still hardcodes the old name:

cat /etc/netplan/*.yaml

network:
  version: 2
  ethernets:
    ens160:            # <-- doesn't exist anymore
      dhcp4: no
      addresses: [192.168.7.80/24]
      gateway4: 192.168.7.1
      nameservers:
        addresses: [8.8.8.8]

Fix

Edit the yaml so the key matches the interface name from ip a, then apply:

sudo nano /etc/netplan/*.yaml   # ens160 -> enp1s0
sudo netplan apply
ip a show enp1s0

Don't reach for nmcli

nmcli device connect enp1s0 fails with Error: Failed to add/activate new connection: ... device is strictly unmanaged. That's expected, not a bug — Ubuntu Server's default netplan renderer is systemd-networkd, and netplan explicitly tells NetworkManager to leave netplan-owned devices alone so the two don't fight over the same NIC. Stick to netplan apply / networkctl status enp1s0, not nmcli.

Root cause 2 — systemd-networkd itself isn't running

Even with the yaml fixed, you can end up with netplan apply reporting Configuration is valid, the interface flipping to UP,LOWER_UP when forced up manually, and still no IPv4 address — only an autoconf IPv6 link-local (fe80::...):

sudo ip link set enp1s0 up
ip a show enp1s0
# UP,LOWER_UP but only inet6 fe80::.../64 — no inet line

Netplan on Ubuntu Server only generates config for systemd-networkd to consume — if the service itself isn't enabled/running, the generated config never actually gets applied, even though netplan generate/apply report success.

Fix

systemctl status systemd-networkd
systemctl is-enabled systemd-networkd

sudo systemctl enable --now systemd-networkd
sudo netplan apply
ip a show enp1s0

If forcing the interface up in the guest still leaves it NO-CARRIER (not just missing an IP), stop working in the guest and check the compute node instead — the virtual link itself may be down at the hypervisor:

# on the compute node
virsh domiflist <vm-name>
# Interface   Type     Source   Model    MAC
# vnet73      bridge   ovsbr0   virtio   00:50:56:a2:21:b6

virsh dumpxml <vm-name> | grep -A10 "<interface"
ip link show vnet73          # the tap device
ovs-vsctl show
ovs-ofctl show ovsbr0

ip link show vnet73 showing UP,LOWER_UP means the tap has carrier and the hypervisor side is fine — the fault is back in the guest. Look for <link state='down'/> in the interface XML block, or PORT_DOWN/ LINK_DOWN flags on the specific port in ovs-ofctl show output. Note that ovsbr0's own LOCAL port showing down is normal on nodes that don't use that bridge for host management IP — it's not the guest's forwarding path (vnet73 ↔ the physical uplink), so don't chase it as the cause unless you've confirmed the node is actually supposed to have a management IP on that bridge.

Note: MAC address changes to the original vendor's OUI

It's expected for the converted guest's MAC to carry the source hypervisor's OUI (e.g. 00:50:56:... for VMware) instead of a 52:54:00:... libvirt-generated one — the V2V import can preserve the original NIC's MAC so DHCP reservations / firewall rules keyed on MAC keep working. This is intentional, not a symptom of anything broken.

See also