I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface.
The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. Because eth1 does not exist in the cloned guest one has to manually edit /etc/udev/rules.d/70-persistent-net.rules to get rid of the bogus entries and then restart the clone instance to have the changes take effect. All this does is return the new guest to the prototype eth0 configuration.
Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest.
James B. Byrne wrote:
I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface.
The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone.
<snip> On the physical box, how many NICs are there?
Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware?
Have you edited /etc/udev/rules.d in the prototype setup?
Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest.
Unfortunately, no, you need it: on boot, /dev, and everything in it, is created on the fly by udev.
mark
On Tue, January 3, 2012 11:58, m.roth@5-cent.us wrote:
On the physical box, how many NICs are there?
There are two physical NICs. Eth0 is the WAN, Eth1 is the LAN. The vm guests are supposed to only be accessible via the WAN. The prototype is configured with only one NIC connected to the bridge device (vnet0 - bridge Br0).
Do physical attributes of the host override the configured virtual attributes of a guest?
Have you edited /etc/udev/rules.d in the prototype setup?
I had previously removed the contents of the 70-persistent-net.rules file on the prototype. However, I did not pay enough attention to the fact that this file is rewritten upon startup. So I was getting the eth0 i/f added back into it every time I started the prototype to perform updates.
If I remove the contents of this file just before shutting down the prototype then the interface problem with cloning disappears.
Thanks for the hint.
Regards,
James B. Byrne wrote:
On Tue, January 3, 2012 11:58, m.roth@5-cent.us wrote:
On the physical box, how many NICs are there?
There are two physical NICs. Eth0 is the WAN, Eth1 is the LAN. The vm guests are supposed to only be accessible via the WAN. The prototype is configured with only one NIC connected to the bridge device (vnet0 - bridge Br0).
Do physical attributes of the host override the configured virtual attributes of a guest?
Dunno 'bout guests - I haven't worked with them, much, except VMware.
man udev: DESCRIPTION udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed from the system.
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.
So it's good, in some ways, but...
Have you edited /etc/udev/rules.d in the prototype setup?
I had previously removed the contents of the 70-persistent-net.rules file on the prototype. However, I did not pay enough attention to the fact that this file is rewritten upon startup. So I was getting the eth0 i/f added back into it every time I started the prototype to perform updates.
If I remove the contents of this file just before shutting down the prototype then the interface problem with cloning disappears.
Thanks for the hint.
Sure. Those persistant-net-rules can really getcha. I've done a lot of upgrades (to 6.x) via rsync from servers I'd built directly, and that caught me a number of times, till I Got It.
mark "and got rid of eth0,1,2,3,4,5...."
I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface.
we experience this problem with VMware too.
The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone.
i'm no expert, but i thought the problem was that the "cloning" mechanism changes the mac address of the eth0 device (to make it unique), but it does not update the udev rules accordingly. udev notices a "new" device and treats it as eth1.
so the correct fix would be either 1) a virtual machine cloning mechanism that updates udev rules to use the new mac address or 2) udev rules that somehow don't need to use the mac address
but i really know next to nothing about udev other than what i've discovered by poking around the "70-persistent-net.rules" same as you
Because eth1 does not exist in the cloned guest one has to
manually edit /etc/udev/rules.d/70-persistent-net.rules to get rid of the bogus entries and then restart the clone instance to have the changes take effect. All this does is return the new guest to the prototype eth0 configuration.
not exactly... the clone does have a new mac address still, so it isn't identical to the prototype.
Is there no way to alter udev's behaviour? Is udev even
needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest.
ahh, the life of a sysadmin. since i do not know enough about udev to answer the first 2 questions, and i do not have time (or interest really) to learn this detail, i just absorb the busy work.
On Tue, 2012-01-03 at 11:52 -0500, James B. Byrne wrote:
I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface.
The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. Because eth1 does not exist in the cloned guest one has to manually edit /etc/udev/rules.d/70-persistent-net.rules to get rid of the bogus entries and then restart the clone instance to have the changes take effect. All this does is return the new guest to the prototype eth0 configuration.
Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest.
Make sure the 70-persistent-net.rules is empty or doesn't contain any mappings in your template. This file is generated automatically when new hardware is discovered. So as long as the template doesn't contain it, you'll get it generated. The issue you'll find yourself in, however, is that you may discover the NICs in the wrong sequence so eth0 and eth1 gets swapped around for you.
A better solution is to not use the MAC address but the "bios" location in 70-persistent-net.rules. If you do that, you can keep the file in the template.
It's a very common problem. Another way is to have a %post script in KS or after initial startup as a VM, that fixes the file based on what the VM properties are.
On Tue, Jan 3, 2012 at 5:13 PM, Peter Larsen plarsen@famlarsen.homelinux.com wrote:
Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest.
Make sure the 70-persistent-net.rules is empty or doesn't contain any mappings in your template. This file is generated automatically when new hardware is discovered. So as long as the template doesn't contain it, you'll get it generated. The issue you'll find yourself in, however, is that you may discover the NICs in the wrong sequence so eth0 and eth1 gets swapped around for you.
A better solution is to not use the MAC address but the "bios" location in 70-persistent-net.rules. If you do that, you can keep the file in the template.
It's a very common problem. Another way is to have a %post script in KS or after initial startup as a VM, that fixes the file based on what the VM properties are.
It happens in real hardware too if you move a disk to a different chassis, clone a drive, restore a backup to similar hardware, etc.
Where is the best documentation on what triggers the rules to be rewritten, how the bios location works, etc.?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Tuesday, January 03, 2012 22:24 To: CentOS mailing list Subject: Re: [CentOS] turning off udev for eth0
On Tue, Jan 3, 2012 at 5:13 PM, Peter Larsen plarsen@famlarsen.homelinux.com wrote:
Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest.
<SNIP>
It's a very common problem. Another way is to have a %post script in KS or after initial startup as a VM, that fixes the file based on what the VM properties are.
It happens in real hardware too if you move a disk to a different chassis, clone a drive, restore a backup to similar hardware, etc.
Where is the best documentation on what triggers the rules to be rewritten, how the bios location works, etc.?
I gave up on tricking UDEV, it was easier to work with the system with my clones. `system-config-network-cmd -e` yields a text file that, you can have either a firstboot script or the booting sysadm, `system-config-network-cmd -i -c -f file.txt` will pull back in and reconfigure the system after ifdown'ing eth0. For good measure I also blanked (and restorecon'd) resolv.conf and hosts prior to pulling in the file.
Good luck.
On Wed, Jan 4, 2012 at 8:22 AM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane todd.denniston@navy.mil wrote:
It's a very common problem. Another way is to have a %post script in KS
or after initial startup as a VM, that fixes the file based on what the VM properties are.
It happens in real hardware too if you move a disk to a different chassis, clone a drive, restore a backup to similar hardware, etc.
Where is the best documentation on what triggers the rules to be rewritten, how the bios location works, etc.?
I gave up on tricking UDEV, it was easier to work with the system with my clones. `system-config-network-cmd -e` yields a text file that, you can have either a firstboot script or the booting sysadm, `system-config-network-cmd -i -c -f file.txt` will pull back in and reconfigure the system after ifdown'ing eth0. For good measure I also blanked (and restorecon'd) resolv.conf and hosts prior to pulling in the file.
Thanks, but does that control the device naming order? My boxes generally have 4 to 6 NICs, with at least 2 active. Every time I touch something the system wants to change the names around. With 5.x, once the MAC addresses were known and in the ifcfg-* files the names generally were stable unless something triggered kudzu to run and replace them. With 6.x even that is not reliable. I need something that will tie the ip config to a certain physical nic and keep it there. Sometimes I know the MAC addresses ahead of time when cloning. Should I expect substituting them into this file to nail things down or is udev still involved separately?
We use the following from a kickstart script using the PCI bus location for the NICs:
echo "ID=="0000:04:04.0", NAME="eth0"" >> /etc/udev/rules.d/70-netrename.rules echo "ID=="0000:05:00.0", NAME="eth0"" >> /etc/udev/rules.d/70-netrename.rules echo "ID=="0000:05:01.0", NAME="eth0"" >> /etc/udev/rules.d/70-netrename.rules
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Wednesday, January 04, 2012 11:43 AM To: CentOS mailing list Subject: EXTERNAL: Re: [CentOS] turning off udev for eth0
On Wed, Jan 4, 2012 at 8:22 AM, Denniston, Todd A CIV NAVSURFWARCENDIV Crane todd.denniston@navy.mil wrote:
It's a very common problem. Another way is to have a %post script in KS
or after initial startup as a VM, that fixes the file based on what the VM properties are.
It happens in real hardware too if you move a disk to a different chassis, clone a drive, restore a backup to similar hardware, etc.
Where is the best documentation on what triggers the rules to be rewritten, how the bios location works, etc.?
I gave up on tricking UDEV, it was easier to work with the system with my clones. `system-config-network-cmd -e` yields a text file that, you can have either a firstboot script or the booting sysadm, `system-config-network-cmd -i -c -f file.txt` will pull back in and reconfigure the system after ifdown'ing eth0. For good measure I also blanked (and restorecon'd) resolv.conf and hosts prior to pulling in the file.
Thanks, but does that control the device naming order? My boxes generally have 4 to 6 NICs, with at least 2 active. Every time I touch something the system wants to change the names around. With 5.x, once the MAC addresses were known and in the ifcfg-* files the names generally were stable unless something triggered kudzu to run and replace them. With 6.x even that is not reliable. I need something that will tie the ip config to a certain physical nic and keep it there. Sometimes I know the MAC addresses ahead of time when cloning. Should I expect substituting them into this file to nail things down or is udev still involved separately?
On Thu, Jan 5, 2012 at 7:58 AM, Massey, Ricky ricky.massey@lmco.com wrote:
We use the following from a kickstart script using the PCI bus location for the NICs:
echo "ID=="0000:04:04.0", NAME="eth0"" >> /etc/udev/rules.d/70-netrename.rules echo "ID=="0000:05:00.0", NAME="eth0"" >> /etc/udev/rules.d/70-netrename.rules echo "ID=="0000:05:01.0", NAME="eth0"" >> /etc/udev/rules.d/70-netrename.rules
That looks like what I need, but I don't understand it. Is there any documentation for how that stuff works, or can you elaborate? And if you do that, can you remove the HWADDR entries from the ifcfg-eth? files and have them stick to the right devices?
There are actually three Ethernet ports (eth0, eth1, and eth2). We use this method to kickstart many servers with the same configuration. The HWADDR is removed from the ifcfg-ethx files. Udev will process the files in the rules.d directory in order. The closest link I have found is http://sicherheitsschwankung.de/post/jan/2005-10-13/renaming-network-devices.... Also, I should point out we are using CentOS 5.5.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Les Mikesell Sent: Thursday, January 05, 2012 12:58 PM To: CentOS mailing list Subject: Re: [CentOS] EXTERNAL: Re: turning off udev for eth0
On Thu, Jan 5, 2012 at 7:58 AM, Massey, Ricky ricky.massey@lmco.com wrote:
We use the following from a kickstart script using the PCI bus location for the NICs:
echo "ID=="0000:04:04.0", NAME="eth0"" >> /etc/udev/rules.d/70-netrename.rules echo "ID=="0000:05:00.0", NAME="eth1"" >> /etc/udev/rules.d/70-netrename.rules echo "ID=="0000:05:01.0", NAME="eth2"" >> /etc/udev/rules.d/70-netrename.rules
That looks like what I need, but I don't understand it. Is there any documentation for how that stuff works, or can you elaborate? And if you do that, can you remove the HWADDR entries from the ifcfg-eth? files and have them stick to the right devices?
-
Denniston, Todd A CIV NAVSURFWARCENDIV Crane -
James B. Byrne -
Jonathan Nilsson -
Les Mikesell -
m.roth＠5-cent.us -
Massey, Ricky -
Peter Larsen