On 01/31/2013 02:31 PM, Laine Stump wrote:
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.)
Actually, I
would prefer to continue using my git20121130 package since
it works and I still get the functionality I wanted.
While I am sorry that they did not pick just a little earlier to get a
tarball, this would have to be debugged sooner or later and now if a
good time.
IIUC, the HEAD at the time I got my 20121130 tarball was
7147c3d1a3c82f21d1ce363f9ab59abb040afc56 in case anyone wants to update
to something known to work.
There needs to be someway to capture some (not all) of the info in the
git log when a tarball is created so that it is easier to understand the
history. Anyone have a solution for this?
Gene