On 11/03/2013 03:37 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Bob Doolittle" <b...@doolittle.us.com>
To: users@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
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
