3:21 p.m.
On Mon, Sep 23, 2013 at 02:25:49PM -0400, Moti Asayag wrote:
I have looked at the getVdsCapabilities reported by VDSM for the
first time, on which the engine based its
setupNetwork command for configuring the management network:
'lastClientIface': 'em1',
'nics': {'em1': {'netmask': '255.255.255.0',
'addr': '192.168.2.9', 'hwaddr': 'a4:ba:db:ec:ea:cd',
'cfg': {}, 'ipv6addrs': ['fe80::a6ba:dbff:feec:eacd/64',
'2001:4830:1692:1:a6ba:dbff:feec:eacd/64'], 'speed': 1000, 'mtu':
'1500'}}
Based on that input, the engine sends setupNetwork command to configure the management
network on top of 'em1' nic.
However, since it has no bootprotocol or gateway, it is identified as bootproto=NONE,
which result in engine not to pass ip address/subnet/gateway to vdsm, therefore the
command fails.
This seems very similar to what triggered
Bug 987813 - [RFE] report BOOTPROTO and BONDING_OPTS independent of
netdevice.cfg
Vdsm does not really cope with network definitions that are not
ifcfg-based. I do not know what makes Fedora 19 sometimes use ifcfg
out-of-the-box and sometimes not, but in order to play well with the
current implementation of Vdsm, we should make it use legacy initscript
for network definition.
networks=[ovirtmgmt {id=b05f272d-473f-41cb-b5a0-25cf06951f6b, description=Management
Network, comment=null, subnet=null, gateway=null, type=null, vlanId=null, stp=false,
dataCenterId=7a7e4a7a-ecc8-4b3e-b200-2b54d0809a52, mtu=0, vmNetwork=true,
cluster=NetworkCluster {id={clusterId=null, networkId=null}, status=OPERATIONAL,
display=false, required=true, migration=false}, providedBy=null, label=null}],
bonds=[],
interfaces=[em1 {id=80a1e7c8-05bd-4209-a6fe-a23c38538330,
vdsId=5e3da5d9-7133-4119-86c0-f655d3e37b38, name=em1, macAddress=a4:ba:db:ec:ea:cd,
networkName=ovirtmgmt, bondName=null, bootProtocol=NONE, address=192.168.2.9,
subnet=255.255.255.0, gateway=null, mtu=0, bridged=true, speed=1000, type=2,
networkImplementationDetails=null}],
removedNetworks=[],
As received by VDSM, where we can see the ip address and the subnet are omitted:
Thread-17::DEBUG::2013-09-23 07:07:21,314::BindingXMLRPC::979::vds::(wrapper) client
[192.168.2.9]::call setupNetworks with ({'ovirtmgmt': {'nic':
'em1', 'STP': 'no', 'bridged': 'true'}}, {},
{'connectivityCheck': 'true', 'connectivityTimeout': 120}) {}
Looking at the traceback on vdsm.log reveals less information:
storageRefresh::DEBUG::2013-09-23 07:07:22,597::misc::817::SamplingMethod::(__call__)
Returning last result
Thread-17::ERROR::2013-09-23 07:09:24,154::API::1261::vds::(setupNetworks)
Traceback (most recent call last):
File "/usr/share/vdsm/API.py", line 1259, in setupNetworks
supervdsm.getProxy().setupNetworks(networks, bondings, options)
File "/usr/share/vdsm/supervdsm.py", line 50, in __call__
return callMethod()
File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda>
**kwargs)
File "<string>", line 2, in setupNetworks
File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in
_callmethod
raise convert_to_error(kind, result)
ConfigNetworkError: (29, '')
Nicholas, could you add also /var/log/vdsm/supervdsm.log and /var/log/messages so we can
get more input about
the failure to bring up em1 ?