> From: "Bob Doolittle" <bob(a)doolittle.us.com&gt; > 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?

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

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

----- Original Message ----- > From: "Bob Doolittle" <bob(a)doolittle.us.com&gt; > To: "Alon Bar-Lev" <alonbl(a)redhat.com&gt; > Cc: users(a)ovirt.org, "Sandro Bonazzola" <sbonazzo(a)redhat.com&gt; > Sent: Sunday, November 3, 2013 11:24:57 PM > Subject: Re: [Users] Problem setting up new engine with 3.3 on Fedora 19 > > > On 11/03/2013 03:37 PM, Alon Bar-Lev wrote: > ----- Original Message ----- >>> From: "Bob Doolittle" <bob(a)doolittle.us.com&gt; >>> 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 > as far as I can see this already been fixed in fedora-19, if you update the nfsutils package.

> 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 This log is stopped using Ctrl-C at customization stage.

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