Il 13/05/2014 11:50, Dan Kenigsberg ha scritto: > On Tue, May 13, 2014 at 10:27:12AM +0200, Sandro Bonazzola wrote: >> Il 13/05/2014 00:33, Bob Doolittle ha scritto: >>> On 05/12/2014 06:21 PM, Dan Kenigsberg wrote: >>>> On Mon, May 12, 2014 at 05:53:10PM -0400, Bob Doolittle wrote: >>>>> On 05/12/2014 02:49 PM, Bob Doolittle wrote: >>>>>> Hi, >>>>>> >>>>>> I'm trying to set up a fresh system on F19, using oVirt 3.4. >>>>>> >>>>>> When running hosted-engine --deploy, it fails during "Configuring the >>>>>> management bridge". The ovirt-hosted-engine-setup log shows: >>>>>> >>>>>> 2014-05-12 13:59:35 INFO >>>>>> otopi.plugins.ovirt_hosted_engine_setup.network.bridge bridge._misc:196 >>>>>> Configuring the management bridge >>>>>> 2014-05-12 13:59:35 DEBUG otopi.context context._executeMethod:152 method >>>>>> exception >>>>>> Traceback (most recent call last): >>>>>> File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in >>>>>> _executeMethod >>>>>> method['method']() >>>>>> File >>>>>> "/usr/share/ovirt-hosted-engine-setup/scripts/../plugins/ovirt-hosted-engine-setup/network/bridge.py", >>>>>> line 201, in _misc >>>>>> ].s.getVdsCapabilities()['info']['nics'][nics] >>>>>> KeyError: 'info' >>>>>> 2014-05-12 13:59:35 ERROR otopi.context context._executeMethod:161 Failed >>>>>> to execute stage 'Misc configuration': 'info' >>>>>> >>>>>> >>>>>> The vdsm.log shows: >>>>>> >>>>>> Thread-14::DEBUG::2014-05-12 >>>>>> 13:59:35,840::BindingXMLRPC::1067::vds::(wrapper) client >>>>>> [127.0.0.1]::call >>>>>> getCapabilities with () {} >>>>>> Thread-14::DEBUG::2014-05-12 13:59:35,875::utils::642::root::(execCmd) >>>>>> '/sbin/ip route show to 0.0.0.0/0 table all' (cwd None) >>>>>> Thread-14::DEBUG::2014-05-12 13:59:35,879::utils::662::root::(execCmd) >>>>>> SUCCESS: <err> = ''; <rc> = 0 >>>>>> Thread-14::ERROR::2014-05-12 >>>>>> 13:59:35,882::BindingXMLRPC::1086::vds::(wrapper) unexpected error >>>>>> Traceback (most recent call last): >>>>>> File "/usr/share/vdsm/BindingXMLRPC.py", line 1070, in wrapper >>>>>> res = f(*args, **kwargs) >>>>>> File "/usr/share/vdsm/BindingXMLRPC.py", line 393, in getCapabilities >>>>>> ret = api.getCapabilities() >>>>>> File "/usr/share/vdsm/API.py", line 1185, in getCapabilities >>>>>> c = caps.get() >>>>>> File "/usr/share/vdsm/caps.py", line 369, in get >>>>>> caps.update(netinfo.get()) >>>>>> File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 566, in >>>>>> get >>>>>> d['nics'][dev.name] = _nicinfo(dev.name, paddr) >>>>>> File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 516, in >>>>>> _nicinfo >>>>>> info = _devinfo(nic) >>>>>> File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 536, in >>>>>> _devinfo >>>>>> ipv4addr, ipv4netmask, ipv6addrs = getIpInfo(dev) >>>>>> File "/usr/lib64/python2.7/site-packages/vdsm/netinfo.py", line 317, in >>>>>> getIpInfo >>>>>> ipv6addrs = devInfo.get_ipv6_addresses() >>>>>> SystemError: error return without exception set >>>>>> >>>>>> >>>>>> I have two NICs - a wireless NIC which is disabled, and an ethernet NIC >>>>>> "p3p1" which is statically configured via network-scripts. >>>>>> >>>>>> I've also attached the output of "ip addr". >>>>>> >>>>>> I also notice some disturbing looking messages in the vdsm log during >>>>>> setupMultipath, including "Panic: Error initializing IRS" and then >>>>>> subsequent lvm-related errors during StorageRefresh. Those did not abort >>>>>> the deployment, however. What do those failures indicate? >>>>> This looks a lot like a new manifestation of: >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1057772 >>>> Which version of Vdsm are you using? ovirt-3.4.1's vdsm-4.14.7 should >>>> have fixed the that problem. >>> >>> >>> I am using the vdsm from ovirt-stable (and ovirt-3.4-stable): >>> vdsm-4.14.6-0.fc19.x86_64 >>> >>> Should stable be updated with vdsm-4.14.7? >>> Can I workaround the problem by using a different repository? >>> >>>>> I even instrumented the code in >>>>> /usr/lib64/python2.7/site-packages/vdsm/netinfo.py >>>>> >>>>> The device name ("p3p1") being passed in is correct (I even tried setting >>>>> the string directly), but the returned object is empty. >>>>> >>>>> If I start python by hand and run ethtool.get_interfaces_info("p3p1") it >>>>> returns the correct data. >>>>> >>>>> So it seems as though the code is somehow environmentally sensitive. I'm >>>>> not >>>>> sure what it is about my environment that would cause issues here however, >>>>> since presumably this is working for others... >>>> I'm afraid this has recently been tickled by a relase of python-ethtool >>>> to Fedora 19. >>> >>> What is my best workaround? I need to get going again ASAP. >> >> if it's a python-ethtool issue, try with >> yum downgrade python-ethtool >> if it works, add it to exclusion (in /etc/yum.conf add >> exclude=python-ethtool) until the issue is fixed. >> >> Dan, can we have a respin of VDSM once the issue is handled (if it has to be >> solved vdsm side)? >> >> If we haven't already a BZ, please open one and make it blocking 3.4.2 >> release, thanks! > > The bug has been solved in vdsm-4.14.7, and should have been in > ovirt-3.4-stable as of the release of ovirt-3.4.1. Sandro, do you know > why Bob reports that 4.14.6 is still there? >
ovirt-3.4.1 deliver vdsm-4.14.8.1 not 4.14.7, you can check yourself here: http://resources.ovirt.org/pub/ovirt-3.4/rpm Can you point me to the email where he says he has 4.14.6? That's the version we released with 3.4.0. Maybe he didn't follow installation instructions here: http://www.ovirt.org/OVirt_3.4.1_release_notes -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users