Uploaded image for project: 'Migration Toolkit for Virtualization'
  1. Migration Toolkit for Virtualization
  2. MTV-1673

The IP address may be reversed after migration if the source VMware VM has "net.ifnames=0"

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 2.7.3
    • Controller, Guest
    • False
    • None
    • True
    • Important

      Description of problem:

      The source VM have two interfaces and the "Consistent Device Naming" is disabled with "net.ifnames=0". Following is the mapping of interface in VMware side:

      MAC IP Interface name Network Name 
      00:50:56:8a:55:83 192.168.0.10 eth0 VM network
      00:50:56:8a:df:c7 172.16.0.10 eth1 New network

      After migration, the IP address got reversed. 00:50:56:8a:55:83 have 172.16.0.10 and 00:50:56:8a:df:c7 have 192.168.0.10.

      MAC IP Interface name
      00:50:56:8a:df:c7 192.168.0.10 eth0
      00:50:56:8a:55:83 172.16.0.10 eth1

       

      This is because our network map by default is getting created with alphabetic order. So the "New network" will be passed first and will get first PCI address and will be named eth0. 

          <interface type='ethernet'>
            <mac address='00:50:56:8a:df:c7'/>         <===
            <target dev='tap0' managed='no'/>
            <model type='virtio-non-transitional'/>
            <mtu size='1400'/>
            <alias name='ua-net-0'/>
            <rom enabled='no'/>
            <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
          </interface>
          <interface type='ethernet'>
            <mac address='00:50:56:8a:55:83'/>                <===
            <target dev='tap17d5a8f04ff' managed='no'/>
            <model type='virtio-non-transitional'/>
            <mtu size='1500'/>
            <alias name='ua-net-1'/>
            <rom enabled='no'/>
            <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
          </interface>

      So the interface naming will change from that of VMware VM where eth0 will become eth1 and eth1 will become eth0. 

      Although, we have the correct udev rules generated by MTV, it's failing with following error because of conflict:

      # cat /etc/udev/rules.d/70-persistent-net.rules
      SUBSYSTEM=="net",ACTION=="add",ATTR{address}=="00:50:56:8a:55:83",NAME="eth0"
      SUBSYSTEM=="net",ACTION=="add",ATTR{address}=="00:50:56:8a:df:c7",NAME="eth1"
      Nov 18 03:06:47 localhost.localdomain systemd-udevd[515]: Error changing net interface name 'eth0' to 'eth1': File exists
      Nov 18 03:06:47 localhost.localdomain systemd-udevd[515]: could not rename interface '2' from 'eth0' to 'eth1': File exists
      Nov 18 03:06:47 localhost.localdomain systemd-udevd[514]: Error changing net interface name 'eth1' to 'eth0': File exists
      Nov 18 03:06:47 localhost.localdomain systemd-udevd[514]: could not rename interface '3' from 'eth1' to 'eth0': File exists

      Version-Release number of selected component (if applicable):

      OpenShift Virtualization         4.16.3
      Migration Toolkit for Virtualization Operator   2.7.3

      How reproducible:

      100%

      Steps to Reproduce:

      1. Set up a VMware VM with two network interfaces, where:
      eth0 is attached to the VMware network that comes later alphabetically.
      eth1 is attached to the VMware network that comes first alphabetically.
      
      2. Disable "Consistent Device Naming" on VM with "net.ifnames=0".
      2. Do a migration using MTV. Check the IP address. It will be getting reversed.

      Actual results:

      IP address may get reversed after migration if source VMware VM have "net.ifnames=0"

      Expected results:

       

      Additional info:

      We have a workaround to keep the order as that of VMware VM while creating the network map.

              fdeutsch@redhat.com Fabian Deutsch
              rhn-support-nashok Nijin Ashok
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: