<div dir="ltr">Hi! <div><br></div><div>>> Hope this helps to find the root cause....<br></div><div>></div><div>> Not sure what you mean - did you have any other problem after<br>> applying your patch? Seems to me that the root cause is some<br>> code (the part you patched or something earlier) did not expect<br>> a prefix of /32, which is indeed quite rare. Not even certain<br>> how it works - did you also get a default gateway? How can you<br>> access it, if it's not in your subnet?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Well, since I don't really know the code I wasn't sure if it's ok to assume /32 in this case. Actually, I hit a couple of other issues afterwards (e.g. the "SCOPE" line wasn't copied into the new bridge interface configuration). So from my experience, I'd be better to tell users with configurations like mine that the configuration is just not supported. </div><div class="gmail_extra"><br></div><div class="gmail_extra">Since I got this config from my provider, I'm also not 100% sure what the SCOPE does, but it seems as if it would make a PtP interface out of a regular ethernet interface, i.e. "hey kernel, with this interface/address I can contact exactly one other host - my gateway". <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">So summed up, I'd suggest to warn users with this configuration and tell them to reconfigure first (without SCOPE and a regular subnet mask). At least that's what I did and what helped after I hit other issues after this fix.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Andreas</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:arial;font-size:small"><br></div><div style="font-family:arial;font-size:small"><br></div><p>---</p><p><b style="font-family:Helvetica,Arial,sans-serif;font-size:12px;line-height:14px">Andreas Mather</b><br></p></div></div></div></div></div></div><div class="gmail_quote">On Wed, Dec 31, 2014 at 11:40 AM, Yedidyah Bar David <span dir="ltr"><<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">----- Original Message -----<br>
> From: "Andreas Mather" <<a href="mailto:andreas@allaboutapps.at">andreas@allaboutapps.at</a>><br>
> To: <a href="mailto:users@ovirt.org">users@ovirt.org</a><br>
> Sent: Wednesday, December 24, 2014 11:29:58 PM<br>
> Subject: Re: [ovirt-users] hosted-engine --deploy fails<br>
><br>
> Hi All!<br>
><br>
> Just did more research on this and it seems as if the reason was related to<br>
> my interface configuration. Disclaimer upfront: I've a public IP configured<br>
> on this server (since it's a hosted root server), but changed the IP addr<br>
> here to 192.168.0.99<br>
><br>
> I started with the output from ´vdsm-tool restore-nets':<br>
> ipv4addr, prefix = addr['address'].split('/')<br>
> ValueError: need more than 1 value to unpack<br>
><br>
> So I dumped the addr dictionary:<br>
> {'address': '192.168.0.99',<br>
> 'family': 'inet',<br>
> 'flags': frozenset(['permanent']),<br>
> 'index': 2,<br>
> 'label': 'eth0',<br>
> 'prefixlen': 32,<br>
> 'scope': 'universe'}<br>
><br>
> I've no clue why there's no "/32" at the end, but that's what my netmask<br>
> actually is due to the special configuration I got from my hosting provider:<br>
><br>
> [root@vhost1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0<br>
> DEVICE=eth0<br>
> BOOTPROTO=none<br>
> ONBOOT=yes<br>
> HWADDR=00:52:9F:A8:AA:BB<br>
> IPADDR=192.168.0.99<br>
> NETMASK=255.255.255.255<br>
> SCOPE="peer 192.168.0.1"<br>
><br>
> (again, public IPs changed to private one, if that matters. And I skipped the<br>
> IPv6 config above...)<br>
><br>
> So what I did next, was to patch the netinfo.py:<br>
> [root@vhost1 vdsm]# diff -u netinfo_orig.py netinfo.py<br>
> --- netinfo_orig.py 2014-12-24 22:16:23.362198715 +0100<br>
> +++ netinfo.py 2014-12-24 22:16:02.567625247 +0100<br>
> @@ -368,7 +368,12 @@<br>
> if addr['family'] == 'inet':<br>
> ipv4addrs.append(addr['address'])<br>
> if 'secondary' not in addr['flags']:<br>
> - ipv4addr, prefix = addr['address'].split('/')<br>
> + """Assume /32 if no prefix was found"""<br>
> + if addr['address'].find('/') == -1:<br>
> + ipv4addr = addr['address']<br>
> + prefix = "32"<br>
> + else:<br>
> + ipv4addr, prefix = addr['address'].split('/')<br>
> ipv4netmask = prefix2netmask(addr['prefixlen'])<br>
> else:<br>
> ipv6addrs.append(addr['address'])<br>
><br>
><br>
> and recompiled it:<br>
> [root@vhost1 vdsm]# python -m py_compile netinfo.py<br>
><br>
><br>
><br>
> Et voilà:<br>
> vdsm-tool ran fine:<br>
> `hosted-engine --deploy' passed the previous failing stage!<br>
<br>
</div></div>Thanks for great analysis, report and patch!<br>
Would you like to push it to gerrit? See [1] and [2]<br>
<br>
Adding Dan in case you do not want to, so that your patch isn't lost...<br>
<span class=""><br>
><br>
> Hope this helps to find the root cause....<br>
<br>
</span>Not sure what you mean - did you have any other problem after<br>
applying your patch? Seems to me that the root cause is some<br>
code (the part you patched or something earlier) did not expect<br>
a prefix of /32, which is indeed quite rare. Not even certain<br>
how it works - did you also get a default gateway? How can you<br>
access it, if it's not in your subnet?<br>
<br>
[1] <a href="http://www.ovirt.org/Develop" target="_blank">http://www.ovirt.org/Develop</a><br>
[2] <a href="http://www.ovirt.org/Working_with_oVirt_Gerrit" target="_blank">http://www.ovirt.org/Working_with_oVirt_Gerrit</a><br>
<br>
Best regards,<br>
<span class=""><font color="#888888">--<br>
Didi<br>
</font></span></blockquote></div><br></div></div>