<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr"><br><br><div>> Date: Tue, 24 Sep 2013 13:28:26 +0100<br>> From: danken@redhat.com<br>> To: cybertimber2000@hotmail.com<br>> CC: jbrooks@redhat.com; masayag@redhat.com; alonbl@redhat.com; users@ovirt.org<br>> Subject: Re: [Users] Unable to finish AIO 3.3.0 - VDSM<br>> <br>> On Mon, Sep 23, 2013 at 06:10:09PM -0400, Nicholas Kesick wrote:<br>> > Ok the thread got a little fragmented, so I'm trying to merge these<br>> > together. Let me know if I missed something.<br>> > <br>> > ----- Original Message -----<br>> > > > From: "Dan Kenigsberg" <danken@redhat.com><br>> > > > To: "Jason Brooks" <jbrooks@redhat.com><br>> > > > Cc: "Nicholas Kesick" <cybertimber2000@hotmail.com>, "oVirt Mailing List" <users@ovirt.org><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<br>> > using the netinstall.iso. I can try a DVD install with<br>> > minimal+standard. For what it's worth that's what I've always used,<br>> > especially after that thread about minimal missing tar, and that part<br>> > of the install or setup requires tar. <br>> > <br>> > I do wonder if the interface names are messing things up. I don't know<br>> > if something changed upstream, or if it's part of the net install, but<br>> > interfaces aren't name eth# or em# (embedded) / p#p# (PCI) anymore.<br>> > 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.<br>> > ifconfig currently reports that I'm using em1, but there is no config<br>> > file for that. hmm.<br>> <br>> Naming per se should not matter. I have seen ovirt install on hosts with<br>> all kinds of nic names.<br>> <br>> However could we get to the bottom of the relation between enp4s0 and<br>> em1? Do you have two physical nics, or just one? Which of them is<br>> physically connected to the outer world? Your /var/log/messages that<br>> it's your em1. THAT nic should have it ifcfg file before Vdsm is<br>> installed on the host.<br>> <br>There is only one NIC on the system, an NIC that is embedded to the motherboard.<br>During install it's listed as enp4s0. Not sure what it's called after first or second boot, but there is a ifcfg-enp4s0 for it.<br>Currently on the system, the output of ifconfig doesn't list that interface, but instead lists em1. If I try a ifdown enp4s0, em1 goes down. It's like they are linked, but I can't find any reference of that. It's off at the moment so when I can boot it up I'll provide more info.<br>I might reinstall and see how it progresses from being named enp4s0 to em1. Worst case I'll disable biosdevname.<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>> > <br>> <br><snipped><br>> <br>> Here, Vdsm is trying to configure em1 with no ip address (because it<br>> found no ifcfg-em1 to begin with). But then, it fails to do so since<br>> NetworkManager is still running.<br>> <br>> So if possible, make sure ifcfg-em1 exists (and has the correct<br>> BOOTPROT=dhcp in it) and the NetworkManager is off before initiating<br>> installation. That's annoying, I know. It should be fix, for sure. But<br>> currently it is a must.<br>> <br>> Regards,<br>> Dan.<br>Hopefully I didn't miss any other comments in that log snippet of log file ^^;; It's good to know why it keeps failing. I'm just trying to figure out how to move forward from here, and I'll take a crack at it this evening.<br>I thought that NetworkManager only needs to be disabled if you are using a static IP? I did try disabling NM before I realized it said only for static and had a failure, but probably because of the interface/ifcfg issue. I will try again this evening.<br><br>I'll try to jump into IRC by 5pm EDT if you happen to be around.<br><br></div></div>
</div></body>
</html>