Seamlessly Importing kvm/qemu VMs from Ubuntu

[ThinkAgain]

Hi, I have a new hardware platform here and am considering to move from an Ubuntu server running kvm/qemu VMs to Proxmox for the new machine. I found the migration doc in the wiki, which is working ok. However, there are a few details that impact the VMs, one of which is that NICs get renamed for quite some of the imported VMs. I found how to adjust the MAC addresses, but I think NIC naming is more related to the (virtual) PCI location of the NIC.

Definition of the NIC on the ubuntu server looks like this:

    <interface type='bridge'>
      <mac address='52:54:00:25:64:62'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Consequently, the NIC is named ens3 in the existing VM. If I import this VM into Proxmox, the NIC becomes ens18.

The GUI doesn't offer customization possibilities for the PCI connection, and man qm doesn't appear to, either.

Any chance to configure this to enable a seamless move of VMs to my current to the new (Proxmox) host and back, while I'm testing Proxmox?

Thanks!

 

[t.lamprecht]

Hi,

Any chance to configure this to enable a seamless move of VMs to my current to the new (Proxmox) host and back, while I'm testing Proxmox?

no not really from the Proxmox VE side. PVE allocates the PCI(e) slots automatically in a stable way to ensure live migration compatibility.

You could adapt the source to use the slot "0x12" instead of the current "0x03", as it'd become then ens18 also there.
Additionally you could tell systemd to use a MAC or kernel based "persistent interface naming".
https://www.freedesktop.org/wiki/So...nterfaceNames/#idontlikethishowdoidisablethis

Or add a udev rule to enforce one name, something like:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="52:54:00:25:64:62", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="ens3"

hope that helps

 

[ThinkAgain]

Ok, thanks. I will fix this from within the VMs then - either with udev rules or with assigning adapter names via netplan, depending on the VMs.