12:24 a.m.
On 11/03/2013 03:37 PM, Alon Bar-Lev wrote:
----- Original Message -----
> From: "Bob Doolittle" <bob(a)doolittle.us.com>
> To: users(a)ovirt.org
> Sent: Sunday, November 3, 2013 10:17:36 PM
> Subject: [Users] Problem setting up new engine with 3.3 on Fedora 19
>
> Hi,
>
> I am doing a fresh engine-setup, with all the defaults, using oVirt 3.3
> on Fedora 19 (all updates).
>
> When I connect to it, it shows my default Datacenter as "Uninitialized"
> and shows no Storage (it should show ISODOMAIN). I can see that my
> ISODOMAIN appears to be created and NFS exported, and I can mount it
> [*]. It's not actually mounted anywhere, however, which seems suspicious.
>
> In the Storage tab, if I go to create a New Domain, it shows "Data
> Center Default (NFS) !", and if I mouse-over the exclamation point it
> says "Data Center is uninitialized, in order to initialize add a data
> domain". But I can't actually create a new domain, because the "Use
> Host" pull-down is empty.
>
> Should I not see my local host in that pulldown menu? How am I supposed
> to add local storage?
> I can't find any errors in the log that logs that look relevant. I checked:
>
> engine-config.log (no errors)
>
> setup/ovirt-engine-setup-*.log (no errors)
>
> engine.log has no errors that look relevant, but it does have a lot of
> odd java exceptions, which can be viewed here:
> http://pastebin.com/TYxi3p36
>
> Any suggestions?
First off, I believe this issue to be resolved thanks to some guidance
on #ovirt from abaron and samppah.
The QuickStart Guide needs updating. It shows that a DC should be
initialized immediately after engine-setup. The reality is (apparently)
that you need to add a Host first, add a Data Domain using that Host,
and then you can connect the ISO_DOMAIN. Some browser refreshes may be
required along the way :)
This was masked for me by the bug I mentioned below when I tried adding
a host earlier, because NFS service was not active.
>
> -Bob
>
> * There's a bug in F19 that interferes with engine-setup
> (https://bugzilla.redhat.com/show_bug.cgi?id=970595). Systemd does not
> start the NFS service at boot and you have to do a weird kludge to
> actually get it to start at bootup (described in the bug report). I've
> applied the workaround so that's not my issue but it's worth mentioning
> here.
Thanks for the reference, sandro, we may want to depend on this newer package.
> Unfortunately engine-setup doesn't detect that the service is down
> when you attempt to configure an NFS storage domain. That sounds like an
> engine-setup bug to me - it should check and warn the user, which would
> go a fair ways towards mitigating the issue in F19,
I am not sure I follow, we cannot be a database for every known [and future known] bug
out there.
We do restart nfs post setup[1], please send your complete setup log.
I'm guessing you're doing the obvious thing: "systemctl restart
nfs-server.service".
The issue if you study the bug report is that simply doing that in F19
is not sufficient. It will not start the service. Hence the bug.
The workaround is:
systemctl enable nfs-lock.service
systemctl enable nfs.target
systemctl start nfs.target
This is a significant enough issue that I'd be tempted to put this into
oVirt for the time being, but that's just me, YMMV (Your Milage May
Vary). I do understand the issue of trying to work around a ton of
temporary bugs and that sometimes you have to choose your bullets, and
of course I'd rather see the fix in F19 than a workaround in oVirt. Not
sure how much control we have over the former vs the latter, however.
This seems a big issue, since at the moment F19 will simply not work for
the most basic of oVirt configurations. Hopefully someday soon this will
no longer be an issue but note this bug was reported 6 months ago, the
last update was over 2 months ago, and we still don't see a fix for this
critical issue in F19.
Pointer to log here:
https://db.tt/cpnZc71k
> and may be more
> important for other platforms which may make different assumptions about
> the default behavior of the NFS service (Fedora assumes it should be
> running, it's just a bug there, but other platforms may arguably assume
> it should not be running by default).
We are not making that assumption as far as I understand.
Perfect. Thanks.
Regards,
Bob