On Thu, Dec 8, 2016 at 5:24 PM, Mark Steckel <mjs(a)fix.net> wrote:
[Apologize. Accidentally hit send instead of save. Continuing
below...]
> ----- Yedidyah Bar David <didi(a)redhat.com> wrote:
> > On Thu, Dec 8, 2016 at 12:42 AM, Mark Steckel <mjs(a)fix.net> wrote:
> > > Hi,
> > >
> > > OK, I reset things and tried again but was more more careful regarding the
DNS setup which I believe was correct this. In other words, the FQDNs were resolved from
both the host and the HE VM.
> > >
> > > After the latest failure I execute 'ip address' to see the state of
the interfaces. And lo and behold the /29 IP I had on eth0:1 no longer exists.
> > >
> > > So some context.
> > >
> > > The server's primary IP is a /24 with the gw being the x.y.z.1.
> > >
> > > I have have a /29 subnet to use for the VMs.
> > >
> > > I have been presuming that I place the a.b.c.1/29 on eth0:1 for the
subnet's gw and OVirt will ether keep it in place or migrate it to the ovirtmgmt
device. Instead it is deleted during "hosted-engine --deploy".(Note, when the
.1/29 is assigned to eth0:1, the IP address is reachable from the the Internet.)
> > >
> > > Dnsmasq is configured to a) serve a.b.c.2/29 a.b.c.6/29 via DHCP and b) to
resolve unique FQDNs for each IP. The he VM set to receive the a.b.c.2/29 address.
> > >
> > > Am I missing and or just misunderstanding something here?
> >
> > "eth0:1" is not really a different interface.
> >
> > Part of the deploy process is to take the interface you have chosen,
> > create a new bridge, copy part of the configuration from the nic to
> > the bridge, and add the nic to the bridge. This is one of the most
> > delicate parts of the process, the one that if fails might leave you
> > with no network access, the one due to which we recommend to run this
> > inside 'screen'. You can't do this to "eth0" and keep
"eth0:1"
> > untouched. You need either a vlan interface or a separate physical
> > nic. If you feel like this, please open a bug to make 'hosted-engine
> > --deploy' notice and prevent what you tried to do. Currently it does
> > not check IP aliases.
I was creating the /29 gw IP on eth0:1 because it seems the simplest thing to do. There
is no requirement for it to hang off of eth0.
Given that I have to hang the entire /29 subnet on the host (and VMs), and I am presuming
that the gw IP of the /29 must be on the host, do you have a suggestion of how to
configure this? (And to be explicit about it, do I need the /29 gw IP on the host to
ensure the vm networking operates?)
Not sure, but even if you do, I think you can do that after --deploy finishes.
Can you please detail (again, perhaps) your intention/plan? How many NICs you
have, can you use VLANs, etc.? Also, if if it's a single host that will remain
single, you might find it simpler to use virt-manager. oVirt is intended for
managing larger setups.
Without the vm engine logs it is difficult to determine why the engine vm fails when
resolving its fqdn. At this point I'm presuming it's due to a networking/routing
issue, but am open to suggestions.
> > Another point - the script that failed is 'engine-setup'. This one
> > runs inside the engine vm, and keeps its logs in
> > /var/log/ovirt-engine/setup. If it fails again, please check/post also
> > these, if at all possible (that is, if you can access the vm).
> > Thinking about this, it might be possible for 'hosted-engine --deploy'
> > to get this log, perhaps through the virtual serial connection it
> > opens to show you the output, and save it on the host side, for easier
> > debugging. Please open a bug for this too :-)
>
When the engine vm setup fails I am unable to connect to it via "hosted-engine
--console". Should console access to the engine vm exist at this point? If so, what
is the best way to access the engine vm console?
The lack access to the engine vm logs is very painful for trying to diagnose what is
going wrong. Ideas welcomed!
If the vm is still up, you can see its qemu process on the host
with 'ps'.
I detailed most of what I know about accessing the console in:
http://www.ovirt.org/documentation/admin-guide/hosted-engine-console/
Please note that in recent versions, '--console' connects you to the
serial console, not graphical one. We did this so that we do not
need to enforce installing a graphical env on mostly-headless hosts.
Best,
--
Didi