[libvirt] NetworkManager git20121211
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. Any suggestions on how to report this problem? (against what and what release?) I am effectively cross-posting by sending identical messages to the NetworkManager and libvirt mailing lists. Yes, I believe the problem is with NetworkManager but there is a large libvirt impact. Gene
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.)
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
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.
Any suggestions on how to report this problem? (against what and what release?)
I am effectively cross-posting by sending identical messages to the NetworkManager and libvirt mailing lists. Yes, I believe the problem is with NetworkManager but there is a large libvirt impact.
participants (2)
-
Gene Czarcinski -
Laine Stump