[libvirt] NetworkManager git20121211

[Gene Czarcinski]

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