On 01/31/2013 10:59 AM, Gene Czarcinski wrote: > I needed some functionality (dynamic dns update) not available in the > NetworkManager package available in Fedora 18 so I created my own > version based on git20121130. This worked nicely providing the > functionality and did not appear to have any bad side effects. > > Then the NetworkManager git20121211 package appeared in rawhide it is > usually better to use a package available from Fedora. So, I got the > source rpm and rebuilt it for Fedora 18. > > This appeared to work fine until I realized that all of the virtual > networks did not have the expected IPv4 addresses. Surprisingly, if > IPv6 was defined for a network, it was there. > > After some investigation, I could only see that NetworkManager may be > the problem. I downgraded to the git20121130 package and rebooted. > The virtual networks were now OK. Yes, that's a known problem: https://bugzilla.redhat.com/show_bug.cgi?id=905035 > Any suggestions on how to report this problem? (against what and what > release?) Unless you want to add prodding in that BZ, there's not much to do other than wait. (Well, actually if you want a temporary workaround, since I assume you're using your own libvirt build anyway, I *think* you may be able to eliminate the problem by forcing the "virbr0-nic" tap device to be UP. You can do that by changing the flags sent to virNetDevTapCreateInBridgePort to: VIR_NETDEV_TAP_CREATE_USE_MAC_FOR_BRIDGE | VIR_NETDEV_TAP_CREATE_IFUP This is around bridge_driver.c:1820 in networkStartNetworkVirtual(). I haven't tried this myself, as I just learned about the problem yesterday, and don't have a rawhide system setup. If you try this workaround, I'd be interested to hear whether or not it works.)