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. -- Best Regards Peter Larsen Wise words of the day: If you want to make God laugh, tell him about your plans. -- Woody Allen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20120103/ce58a752/attachment-0005.sig>