[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] NetworkManager git20121211



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]