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.)