|
Bugzilla – Full Text Bug Listing |
| Summary: | veth devices must not handled by udevd | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.3 | Reporter: | Richard Weinberger <richard> |
| Component: | Basesystem | Assignee: | Cédric Bosdonnat <cbosdonnat> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P4 - Low | CC: | jfehlig, mt, rmilasan |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Richard Weinberger
2013-07-11 10:32:14 UTC
The rule is part of sysconfig and it's maintained by Marius Tomaschewski, but I will stay in the CC. (In reply to comment #0) > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 > Firefox/22.0 > > /usr/lib/udev/rules.d/77-network.rules does not white list veth devices, > if tools like libvirt create veth devices udevd runs ifup/down/hotplug > on them and confuses libvirt. ^^^^^^^^^^^^^^^^ How does it confuse libvirt / what are the problem you've observed? libvirt creates veth devies and sets them up/down. If udevd also starts configuring them we end up in a situation where libvirt thinks that an interface is up, but is in reality down and vice versa. Fell free to read that thread: http://www.redhat.com/archives/libvir-list/2013-July/msg00008.html Gao feng and myself wasted a lot of time with hunting such an issue down. Thanks, //richard BTW: There is *zero* reason why udevd should handle virtual network devices... (In reply to comment #3) > libvirt creates veth devies and sets them up/down. Right. > If udevd also starts configuring them we end up in a situation where > libvirt thinks that an interface is up, but is in reality down and > vice versa. No, udev does not create them -- it just handles the event when interface appears in the system (created by libvirt in this case) or is removed from the system/kernel (triggered by libvirt, cleanup call on sysconfig side). There is no ifcfg-file for the veth interfaces, so nothing is done and nothing happens. When there is one, it is there a) by intention or b) libvirt is trying to use a system configured/reserved interface name, that is a misconfiguration. (In reply to comment #4) > BTW: There is *zero* reason why udevd should handle virtual network devices... e.g. routed vm configuration on the host side, we've used with xen. The user may want to create a ifcfg-file with STARTMODE=hotplug and ifroute-file to apply routes. As there is no issue, resolving as INVALID. So, can you please explain me why udevd is calling "/sbin/ifdown veth5 -o hotplug"? On my system is no ifcfg file for veth5. Thanks, //richard (In reply to comment #6) > So, can you please explain me why udevd is calling "/sbin/ifdown veth5 -o > hotplug"? On my system is no ifcfg file for veth5. To mark it "rename done" (by udev; or rule 77 reached), track the state and _if_ there is ifcfg config, to start the interface. That there is no ifcfg-veth5 file, does not mean there is really no ifcfg config for the interface: it could be an iBFT interface and ifup reads the iBFT NICs as ifcfg config - it even ignores an existing ifcfg file - then. Further, when there is no iBFT but a ifcfg-file, it may have STARTMODE=off, disabling it even ifcfg file exists. A test -f file is not sufficient. IMO libvirt is missing an "udevadm settle" call between "remove foo; add foo" -- the "add" and "link up" calls in libvirt are done before udev finished the "remove" event processing. See also link in comment 8. Jim, we can add veth and vnet to the skip_ifup blacklist as well, but the settle calls are IMO required too. The "ip link set down" is called because ifdown checks it and notices that the interface is still up. libvirt fix about to land in Factory. Upstream didn't want the libvirt patch. Patch in Factory, closing |