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. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
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
> > 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
Greetings, ----- Original Message -----> 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.That's how it is on physical machines (I image lab computers and have to clean up the udev rules file among other things) and would expect the same behavior from virtual machines. The limitations of virt-clone are known and are being addressed in virt-sysprep... which hasn't made it to RHEL yet I don't think... but you can find out about it here: http://rwmj.wordpress.com/2011/10/08/new-tool-virt-sysprep/ TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [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. -- 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.sig>
On Tue, Jan 3, 2012 at 5:13 PM, Peter Larsen <plarsen at 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.? -- Les Mikesell lesmikesell at gmail.com
On Tue, Jan 3, 2012 at 8:52 AM, James B. Byrne <byrnejb at harte-lyne.ca>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. > > -- > *** E-Mail is NOT a SECURE channel *** > James B. Byrne mailto:ByrneJB at Harte-Lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 > Hamilton, Ontario fax: +1 905 561 0757 > Canada L8E 3C3 > >I do this on VM clones. It depends on your OS but where I've had to do it is with Ubuntu VMs. I'm not sure where exactly they set that in CentOS but I'd start looking in /lib/udev/rules.d/75-persistent-net-generator.rules Grant McWilliams -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20120104/5b75773c/attachment-0006.html>