LinuxQuestions.org - eth0 won't bind

Okay this is a Xen VPS under Virtualizor, so I just took a screenie from the softaculous Java console in that control panel.

Here's the scenario. several virtual machines moved from one datacenter to another. All went well, but they tend to not have a NIC recognized on the PCI bus. The provider wasn't specific, so I'm not sure why but when I show them the lspci they eventually are able to fix that on their end.

I'm going to show snippets of two machines - identical virtualization and identical installs, with the exception of their hostnames/IPs:

Here's some output from box001 (The one without ANY problems):

Code:

root@box001:~# ip address show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 scope host lo

      valid_lft forever preferred_lft forever

    inet6 ::1/128 scope host

      valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:16:3e:9a:cc:ac brd ff:ff:ff:ff:ff:ff

    inet 1.2.3.4/25 brd 1.2.3.255 scope global eth0

      valid_lft forever preferred_lft forever

    inet6 fe80::dead:beef:cafe:gaff/64 scope link

      valid_lft forever preferred_lft forever

root@box001:~# lsmod |grep 8139

8139cp                20523  0

mii                    4291  1 8139cp

root@box001:~# dmesg |grep 8139

[    1.546011] pci 0000:00:04.0: [10ec:8139] type 00 class 0x020000

[  17.165454] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)

[  17.520333] 8139cp 0000:00:04.0 eth0: RTL-8139C+ at 0xffffc900002ce000, 00:16:3e:9a:cc:ac, IRQ 32

[  57.125853] 8139cp 0000:00:04.0 eth0: link up, 100Mbps, full-duplex, lpa 0x05E1

root@hammer:~# lspci |grep -i ethernet

00:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8100/8101L/8139 PCI Fast Ethernet Adapter (rev 20)

root@box0011:~#

Now, in the dmesg above, I noted that the ONLY difference I could glean was that the address of eth0 was located at...
0xffffc900002ce000 for box001, and
0xffffc900000aa000 for box002.

There's no cloning going on, just completely identical, step by step installs by hand from iso files.

Here's the dmesg from box002 (the one with the problem):

Code:

~# dmesg |grep 8139

[    0.889382] pci 0000:00:04.0: [10ec:8139] type 00 class 0x020000

[    8.689219] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)

[    8.807736] 8139cp 0000:00:04.0 eth0: RTL-8139C+ at 0xffffc900000aa000, 00:16:3e:aa:a6:d7, IRQ 32

[  11.963356] 8139cp 0000:00:04.0 eth126: renamed from eth0

[  11.970147] 8139cp 0000:00:04.0 eth1: renamed from eth126

[ 7471.715843] 8139cp 0000:00:04.0 eth1: link up, 100Mbps, full-duplex, lpa 0x05E1

I've included a screenie as an attachment for box002 and...
here's a screenie online of box002:
https://www.screencast.com/t/YjtcAQ0xbE

What I've done, to get the box up and talking, is to put in a private IP for eth0 in /etc/rc.d/rc.inet1.conf and then the IP addy I was assigned for the box for eth1, changed the interface in rc.firewall and bang! she came up after a quick restart of rc.inet1 and rc.firewall.

But this is just a kludge, and I want to get to the bottom of this (I may have to point the provider to where the issue might lie on their end) and set it right as it should be.

I've never seen an iface bounce like what dmesg is showing in the screenie before - from eth0 to eth126 to eth1 - that's just fricken' odd.

What might cause this? and Where might I look to investigate further and work towards a resolution that doesn't involve such a kludge?

Thanks in advance for any suggestions and ideas anyone might have, and I'll provide additional system data if needed. In the meantime all is well and the box is back in production but I'm not comfortable with how.

Attachment 24490