[Users] Unable to finish AIO 3.3.0 - VDSM

[Dan Kenigsberg]

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 ?