Failure during self-hosted deployment: exception configuring management bridge
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? Thanks, Bob
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 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... -Bob
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 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.
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. Thanks, Bob
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!
Thanks, Bob _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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?
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
On Tue, May 13, 2014 at 12:03:28PM +0200, Sandro Bonazzola wrote:
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:
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?
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?
Look up ^^^ ;-)
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
Maybe.
I think I did in fact start with the wrong ovirt-release RPM, and consequently the wrong repos. I have started over as specified in the 3.4.1 release notes (fresh Fedora 19 install, yum localinstall http://resources.ovirt.org/pub/yum-repo/ovirt-release34.rpm). Now I am encountering a different issue during the same step, but I'll start a new e-mail thread for clarity. Thanks, Bob On 05/13/2014 08:24 AM, Dan Kenigsberg wrote:
On Tue, May 13, 2014 at 12:03:28PM +0200, Sandro Bonazzola wrote:
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:
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? 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? Look up ^^^ ;-)
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 Maybe.
Also - is there a bugID for this new issue? The one I quoted is supposed to only affect non-existent device names. Why is this affecting valid device names as well, and only in the VDSM context? Thanks, Bob 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 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.
On 13/05/14 00:35, Bob Doolittle wrote:
Also - is there a bugID for this new issue?
The one I quoted is supposed to only affect non-existent device names. Why is this affecting valid device names as well, and only in the VDSM context?
Antonio may correct me here, but I believe it's caused by vdsm using libnl-1.x and py-ethtool using libnl3. We've discovered an issue with this combination, where libnl-1.x is able to invalidate the netlink socket libnl3 gives py-ethtool; rendering py-ethtool useless. This issue is somewhat tracked in this bz: <https://bugzilla.redhat.com/show_bug.cgi?id=1078312> This is actually quite a delicate issue, as I believe there are some fixes in vdsm, py-ethtool have some patches to improve the error handling (which should help vdsm too) and we're waiting for an official libnl3 update to tackle the socket handling better. I have hopes that once the libnl3 fixes gets out, much of this will be solved. David S.
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 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.
----- Original Message -----
From: "David Sommerseth" <davids@redhat.com> To: "Bob Doolittle" <bob@doolittle.us.com>, "Dan Kenigsberg" <danken@redhat.com>, asegurap@redhat.com Cc: "users" <users@ovirt.org> Sent: Tuesday, May 13, 2014 10:59:47 AM Subject: Re: Failure during self-hosted deployment: exception configuring management bridge
On 13/05/14 00:35, Bob Doolittle wrote:
Also - is there a bugID for this new issue?
The one I quoted is supposed to only affect non-existent device names. Why is this affecting valid device names as well, and only in the VDSM context?
Antonio may correct me here, but I believe it's caused by vdsm using libnl-1.x and py-ethtool using libnl3. We've discovered an issue with this combination, where libnl-1.x is able to invalidate the netlink socket libnl3 gives py-ethtool; rendering py-ethtool useless.
This issue is somewhat tracked in this bz: <https://bugzilla.redhat.com/show_bug.cgi?id=1078312>
This is actually quite a delicate issue, as I believe there are some fixes in vdsm, py-ethtool have some patches to improve the error handling (which should help vdsm too) and we're waiting for an official libnl3 update to tackle the socket handling better.
I have hopes that once the libnl3 fixes gets out, much of this will be solved.
In vdsm's ovirt-3.4 branch we have detection of ethtool's version and use the same libnl version, as seen in: http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob_plain;f=lib/vdsm/netlink.py... if _ethtool_uses_libnl3(): This looks to me like there might be a python-ethtool 0.9.2 bug for devices that do not get ipv6 autoconf addresses. I'll investigate.
David S.
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 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.
Il 12/05/2014 23:53, Bob Doolittle ha scritto:
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.
Hi Bob, can you check you're using right repositories in order to get 3.4.1? See http://www.ovirt.org/OVirt_3.4.1_release_notes Thanks,
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
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...
-Bob
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On Tue, May 13, 2014 at 12:07:09PM +0200, Sandro Bonazzola wrote:
Il 12/05/2014 23:53, Bob Doolittle ha scritto:
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.
Hi Bob, can you check you're using right repositories in order to get 3.4.1? See http://www.ovirt.org/OVirt_3.4.1_release_notes Thanks,
I now see that EPEL6 still has 4.14.6 in its stable repo. Douglas - can you push 4.14.8 ASAP?
Il 13/05/2014 20:29, Dan Kenigsberg ha scritto:
On Tue, May 13, 2014 at 12:07:09PM +0200, Sandro Bonazzola wrote:
Il 12/05/2014 23:53, Bob Doolittle ha scritto:
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.
Hi Bob, can you check you're using right repositories in order to get 3.4.1? See http://www.ovirt.org/OVirt_3.4.1_release_notes Thanks,
I now see that EPEL6 still has 4.14.6 in its stable repo. Douglas - can you push 4.14.8 ASAP?
http://resources.ovirt.org/pub/ovirt-3.4/rpm/el6/noarch/ has 4.14.8.1. or do you mean fedora epel repository? -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On Wed, May 14, 2014 at 08:49:06AM +0200, Sandro Bonazzola wrote:
Il 13/05/2014 20:29, Dan Kenigsberg ha scritto:
On Tue, May 13, 2014 at 12:07:09PM +0200, Sandro Bonazzola wrote:
Il 12/05/2014 23:53, Bob Doolittle ha scritto:
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.
Hi Bob, can you check you're using right repositories in order to get 3.4.1? See http://www.ovirt.org/OVirt_3.4.1_release_notes Thanks,
I now see that EPEL6 still has 4.14.6 in its stable repo. Douglas - can you push 4.14.8 ASAP?
http://resources.ovirt.org/pub/ovirt-3.4/rpm/el6/noarch/
has 4.14.8.1.
or do you mean fedora epel repository?
Yes. Sorry for not being explicit. I now see[1] that there's not even a (non-scratch) Fedora build yet. So more of Douglas's help is needed. [1] https://admin.fedoraproject.org/updates/search/vdsm
participants (6)
-
Antoni Segura Puimedon -
Bob Doolittle -
Dan Kenigsberg -
David Sommerseth -
Joop van de Wege -
Sandro Bonazzola