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 ?