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 ? _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users