[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. 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, 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).
----- Original Message -----
From: "Bob Doolittle" <bob@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?
-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. Regards, Alon Bar-Lev. [1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=packaging/setup/p...
On 11/03/2013 03:37 PM, Alon Bar-Lev wrote: ----- Original Message -----
From: "Bob Doolittle" <bob@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
----- Original Message -----
From: "Bob Doolittle" <bob@doolittle.us.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: users@ovirt.org, "Sandro Bonazzola" <sbonazzo@redhat.com> 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@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
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
On 11/03/2013 04:32 PM, Alon Bar-Lev wrote:
----- Original Message -----
From: "Bob Doolittle" <bob@doolittle.us.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: users@ovirt.org, "Sandro Bonazzola" <sbonazzo@redhat.com> 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@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
as far as I can see this already been fixed in fedora-19, if you update the nfsutils package.
That's disturbing. My system was fully up-to-date as of Friday, and I'm not seeing any pending updates for nfs-utils. Perhaps it's a re-manifestation of the bug, or a new one which is similar in behavior.
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.
I'm sorry then I don't know what happened to the logs because I don't have any others available. If I see this issue again I'll be sure to save/post the log. Regards, Bob
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
participants (2)
-
Alon Bar-Lev -
Bob Doolittle