[ovirt-users] hosted-engine --deploy fails

[Andreas Mather]

Hi!

>> Hope this helps to find the root cause....
>
> Not sure what you mean - did you have any other problem after
> applying your patch? Seems to me that the root cause is some
> code (the part you patched or something earlier) did not expect
> a prefix of /32, which is indeed quite rare. Not even certain
> how it works - did you also get a default gateway? How can you
> access it, if it's not in your subnet?

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.

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".

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.

Regards,

Andreas






---

*Andreas Mather*
On Wed, Dec 31, 2014 at 11:40 AM, Yedidyah Bar David <didi at redhat.com>
wrote:

> ----- Original Message -----
> > From: "Andreas Mather" <andreas at allaboutapps.at>
> > To: users at ovirt.org
> > Sent: Wednesday, December 24, 2014 11:29:58 PM
> > Subject: Re: [ovirt-users] hosted-engine --deploy fails
> >
> > Hi All!
> >
> > Just did more research on this and it seems as if the reason was related
> to
> > my interface configuration. Disclaimer upfront: I've a public IP
> configured
> > on this server (since it's a hosted root server), but changed the IP addr
> > here to 192.168.0.99
> >
> > I started with the output from ´vdsm-tool restore-nets':
> > ipv4addr, prefix = addr['address'].split('/')
> > ValueError: need more than 1 value to unpack
> >
> > So I dumped the addr dictionary:
> > {'address': '192.168.0.99',
> > 'family': 'inet',
> > 'flags': frozenset(['permanent']),
> > 'index': 2,
> > 'label': 'eth0',
> > 'prefixlen': 32,
> > 'scope': 'universe'}
> >
> > I've no clue why there's no "/32" at the end, but that's what my netmask
> > actually is due to the special configuration I got from my hosting
> provider:
> >
> > [root at vhost1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
> > DEVICE=eth0
> > BOOTPROTO=none
> > ONBOOT=yes
> > HWADDR=00:52:9F:A8:AA:BB
> > IPADDR=192.168.0.99
> > NETMASK=255.255.255.255
> > SCOPE="peer 192.168.0.1"
> >
> > (again, public IPs changed to private one, if that matters. And I
> skipped the
> > IPv6 config above...)
> >
> > So what I did next, was to patch the netinfo.py:
> > [root at vhost1 vdsm]# diff -u netinfo_orig.py netinfo.py
> > --- netinfo_orig.py 2014-12-24 22:16:23.362198715 +0100
> > +++ netinfo.py 2014-12-24 22:16:02.567625247 +0100
> > @@ -368,7 +368,12 @@
> > if addr['family'] == 'inet':
> > ipv4addrs.append(addr['address'])
> > if 'secondary' not in addr['flags']:
> > - ipv4addr, prefix = addr['address'].split('/')
> > + """Assume /32 if no prefix was found"""
> > + if addr['address'].find('/') == -1:
> > + ipv4addr = addr['address']
> > + prefix = "32"
> > + else:
> > + ipv4addr, prefix = addr['address'].split('/')
> > ipv4netmask = prefix2netmask(addr['prefixlen'])
> > else:
> > ipv6addrs.append(addr['address'])
> >
> >
> > and recompiled it:
> > [root at vhost1 vdsm]# python -m py_compile netinfo.py
> >
> >
> >
> > Et voilà:
> > vdsm-tool ran fine:
> > `hosted-engine --deploy' passed the previous failing stage!
>
> Thanks for great analysis, report and patch!
> Would you like to push it to gerrit? See [1] and [2]
>
> Adding Dan in case you do not want to, so that your patch isn't lost...
>
> >
> > Hope this helps to find the root cause....
>
> Not sure what you mean - did you have any other problem after
> applying your patch? Seems to me that the root cause is some
> code (the part you patched or something earlier) did not expect
> a prefix of /32, which is indeed quite rare. Not even certain
> how it works - did you also get a default gateway? How can you
> access it, if it's not in your subnet?
>
> [1] http://www.ovirt.org/Develop
> [2] http://www.ovirt.org/Working_with_oVirt_Gerrit
>
> Best regards,
> --
> Didi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150102/1487759c/attachment-0001.html>