> > 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. -- Jonathan.Nilsson at uci dot edu Social Sciences Computing Services SSPB 1265 | 949.824.1536