<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Ok the thread got a little fragmented, so I'm trying to merge these together. Let me know if I missed something.<BR> <BR>----- Original Message -----<br>> > From: "Dan Kenigsberg" <<a href="mailto:danken@redhat.com">danken@redhat.com</a>><br>> > To: "Jason Brooks" <<a href="mailto:jbrooks@redhat.com">jbrooks@redhat.com</a>><br>> > Cc: "Nicholas Kesick" <<a href="mailto:cybertimber2000@hotmail.com">cybertimber2000@hotmail.com</a>>, "oVirt Mailing List" <<a href="mailto:users@ovirt.org">users@ovirt.org</a>><br>> > Sent: Monday, September 23, 2013 1:23:28 PM<br>> > Subject: Re: [Users] Unable to finish AIO 3.3.0 - VDSM<br>> > <br>> > On Mon, Sep 23, 2013 at 03:29:10PM -0400, Jason Brooks wrote:<br>> > > <br>> > > <br>> > > > <br>> > > > Hi Nicholas, I just installed an F19 AIO without any problem. My install<br>> > > > was<br>> > > > only minimal, though. I restored my snapshot to pre-ovirt install and<br>> > > > added<br>> > > > the "standard" group, rebooted, installed, and vdsm still installed<br>> > > > normally.<br>> > > > <br>> > > > I'm wondering if it makes a difference if the system starts out with<br>> > > > minimal+standard, rather than starting out minimal and adding standard<br>> > > > after...<br>> > > > <br>> > > > This is with dhcp addressing.<br>> > > <br>> > > Another difference -- my AIO machine has nics w/ the regular eth0 naming --<br>> > > don't know if the biosdevname bits could be causing an issue...<br>> > <br>> > Would I be wrong to assume that you had<br>> > /etc/sysconfig/network-scripts/ifcfg-eth0 defined before installation<br>> > began?<br>> <br>> My systems do always have this defined before installation begins. I almost always<br>> do PXE installs of Fedora. Wonder how it differs from a DVD install...<br>> <br>> Jason<BR>Good question. My particular attempts with ovirt 3.3 have been by using the netinstall.iso. I can try a DVD install with minimal+standard. For what it's worth that's what I've always used, especially after that thread about minimal missing tar, and that part of the install or setup <a href="http://lists.ovirt.org/pipermail/users/2013-July/015447.html">requires tar</a>. <BR> <BR>I do wonder if the interface names are messing things up. I don't know if something changed upstream, or if it's part of the net install, but interfaces aren't name eth# or em# (embedded) / p#p# (PCI) anymore. Mine are way more cryptic now (enp4s0) and it's very annoying.<BR>I know there wasn't a ifcfg-eth0, but there is a ifcfg-enp4s0. ifconfig currently reports that I'm using em1, but there is no config file for that. hmm.<BR> <BR>> On Mon, Sep 23, 2013 at 02:25:49PM -0400, Moti Asayag wrote:<br>> > I have looked at the getVdsCapabilities reported by VDSM for the first time, on which the engine based its<br>> > setupNetwork command for configuring the management network:<br>> > <br>> > 'lastClientIface': 'em1',<br>> > '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'}}<br>> > <br>> > Based on that input, the engine sends setupNetwork command to configure the management network on top of 'em1' nic.<br>> > 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.<br>> <br>> This seems very similar to what triggered<br>> <br>> Bug 987813 - [RFE] report BOOTPROTO and BONDING_OPTS independent of<br>> netdevice.cfg<br>> <br>> Vdsm does not really cope with network definitions that are not<br>> ifcfg-based. I do not know what makes Fedora 19 sometimes use ifcfg<br>> out-of-the-box and sometimes not, but in order to play well with the<br>> current implementation of Vdsm, we should make it use legacy initscript<br>> for network definition.<br>> <BR>See the above. I wonder if netinstall.iso messes with this.<BR>> > <br>> > 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}],<br>> > bonds=[],<br>> > 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}],<br>> > removedNetworks=[],<br>> > <br>> > As received by VDSM, where we can see the ip address and the subnet are omitted:<br>> > 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}) {}<br>> > <br>> > Looking at the traceback on vdsm.log reveals less information:<br>> > storageRefresh::DEBUG::2013-09-23 07:07:22,597::misc::817::SamplingMethod::(__call__) Returning last result<br>> > Thread-17::ERROR::2013-09-23 07:09:24,154::API::1261::vds::(setupNetworks)<br>> > Traceback (most recent call last):<br>> > File "/usr/share/vdsm/API.py", line 1259, in setupNetworks<br>> > supervdsm.getProxy().setupNetworks(networks, bondings, options)<br>> > File "/usr/share/vdsm/supervdsm.py", line 50, in __call__<br>> > return callMethod()<br>> > File "/usr/share/vdsm/supervdsm.py", line 48, in <lambda><br>> > **kwargs)<br>> > File "<string>", line 2, in setupNetworks<br>> > File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod<br>> > raise convert_to_error(kind, result)<br>> > ConfigNetworkError: (29, '')<br>> > <br>> > <br>> > Nicholas, could you add also /var/log/vdsm/supervdsm.log and /var/log/messages so we can get more input about<br>> > the failure to bring up em1 ?<BR>Yep, attached.<BR> </div></body>
</html>