I have had to deal with a strange behaviour in one of my SLES 11 SP3 virtual machines that is hosted in an ESXi 5.5 hypervisor. After adding a new network interface, the operating system started a process to rename the ethernet interfaces. You can check the case below:
[QUOTE]<6>[ 24.883996] udev: renamed network interface eth4 to rename6
<6>[ 24.899864] udev: renamed network interface eth5 to rename7
<6>[ 24.911977] udev: renamed network interface rename6 to eth5
<6>[ 24.935901] udev: renamed network interface rename2 to eth2
<6>[ 24.951781] udev: renamed network interface eth6 to rename8
<6>[ 24.971782] udev: renamed network interface rename7 to eth4
[/QUOTE]
It seems that “udevadm settle” command receives timeout for the following interface (maybe it kept for some reason both names):
[QUOTE]udevadm settle - timeout of 30 seconds reached, the event queue contains:
/sys/devices/pci0000:00/0000:00:18.0/0000:1b:00.0/net/eth6 (1126)
/sys/devices/pci0000:00/0000:00:18.0/0000:1b:00.0/net/rename8 (1383)[/QUOTE]
I have configured 70-persistent-net.rules by specifying the MAC address of the NIC and by removing the KERNEL filter in order to be able, to change again the interface “rename8” to eth1.
Finally, the result is that I have the correct interface configuration , but I would like to neither to wait for the “udevadm settle” timeout nor to rename back the interface back to the correct name. Can you explain me where this “event queue” information is kept and how it can be clean again? Just to clarify also that after the restart the ethernet mapped to this port is eth1, so the device existing in the filesystem is the following:
“/sys/devices/pci0000:00/0000:00:18.0/0000:1b:00.0/net/eth1”
It appears that in the past few days you have not received a response to your
posting. That concerns us, and has triggered this automated reply.
These forums are peer-to-peer, best effort, volunteer run and that if your issue
is urgent or not getting a response, you might try one of the following options:
Visit http://www.suse.com/support and search the knowledgebase and/or check all
the other support options available.
If this is a reply to a duplicate posting or otherwise posted in error, please
ignore and accept our apologies and rest assured we will issue a stern reprimand
to our posting bot…
Is there any update regarding this case? My concern is about the timeout I receive during the execution of the “udevadm settle” command for this specific network card.
[QUOTE]udevadm settle - timeout of 30 seconds reached, the event queue contains:
/sys/devices/pci0000:00/0000:00:18.0/0000:1b:00.0/net/eth6 (1126)
/sys/devices/pci0000:00/0000:00:18.0/0000:1b:00.0/net/rename8 (1383)[/QUOTE]
As I have said, after the system boot the rules configured in “/etc/udev/rules.d/70-persistent-net.rules” apply, and the final configuration is as expected (the card is correctly mapped to eth1:
I’m sorry no one has replied to your post. The Knowledge Partners are
volunteers who help out on a best “effort basis”. Sometimes we
encounter situations with which we are unfamiliar and therefore have
nothing to contribute.
I too don’t have a solution, only a couple of suggestions.
If you are able to, open a Service Request with SUSE.
You say you encountered this issue after adding a new network
interface. I assume you first added it to your ESXi virtual machine
then used YaST Networking to configure it?
Perhaps you could try this:
Take a snapshot of your ESXi VM
From the system console using YaST Networking, remove all network
interfaces.
From the system console using YaST Networking, install all network
interfaces from scratch and configure them.
Perhaps recreating everything will resolve your issue. If it doesn’t,
you can simply restore your snapshot.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.
Thank you Kboyle for your recommendation. Indeed , the problem has been solved. I removed the physical interfaces from the virtual machine and I have recreated them. New MAC addresses have been assigned, so I had to reconfigure /etc/udev/rules.d/70-persistent-net.rules and the ifcfg-* files but everything now is as expected.
You can consider the problem as solved. Thanks a lot.
Regarding the Service Request, unfortunately SLES 11 SP3 is out of support since 31 January 2016, so they it couldn’t be handled.
You can consider the problem as solved. Thanks a lot. ;)[/color]
[color=blue]
I appreciate your feedback. If you haven’t done so already, please[/color]
click on the star below by signature.
–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below this post.
Thank you.
