3.5->3.6 did not import hosted engine storage domain
So, on to my next upgrade issue (sorry for all the questions and thanks for everybody's help)... I upgraded my test cluster from 3.5 to 3.6 (latest version of each, all on CentOS 7 except the engine on CentOS 6). Now I'm working on the next step, upgrading to 4.0 and migrating the HE to the appliance. When I went from 3.5 to 3.6, I ended up with an fhanswers.conf in the shared storage that only contained "None"; I fixed that based on some mailing list messages (but just mentioning it in case it could be related). My problem is that the hosted engine storage domain did not get imported into the engine DB, so I can't proceed with "hosted-engine --upgrade-appliance". I didn't see any errors, so I'm not sure how that happened. I'm also not sure how to fix that. Suggestions? -- Chris Adams <cma@cmadams.net>
On Fri, Feb 24, 2017 at 8:24 PM, Chris Adams <cma@cmadams.net> wrote:
So, on to my next upgrade issue (sorry for all the questions and thanks for everybody's help)... I upgraded my test cluster from 3.5 to 3.6 (latest version of each, all on CentOS 7 except the engine on CentOS 6). Now I'm working on the next step, upgrading to 4.0 and migrating the HE to the appliance.
When I went from 3.5 to 3.6, I ended up with an fhanswers.conf in the shared storage that only contained "None"; I fixed that based on some mailing list messages (but just mentioning it in case it could be related).
My problem is that the hosted engine storage domain did not get imported into the engine DB, so I can't proceed with "hosted-engine --upgrade-appliance". I didn't see any errors, so I'm not sure how that happened. I'm also not sure how to fix that.
Suggestions?
Can you please attach your engine.log ?
-- Chris Adams <cma@cmadams.net> _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Once upon a time, Simone Tiraboschi <stirabos@redhat.com> said:
Can you please attach your engine.log ?
Sorry, I was rolling back to 3.5 snapshots to test my 3.6 procedure (trying to make sure I didn't just screw up), made a mistake, and started over. Now however, I can't do anything, because jpackage.org has really screwed up their DNS - registered to 3 nameservers, two of which only exist as glue records (not in authoritative DNS), and all three point to the same IP (which is not responding). -- Chris Adams <cma@cmadams.net>
Once upon a time, Simone Tiraboschi <stirabos@redhat.com> said:
On Fri, Feb 24, 2017 at 8:24 PM, Chris Adams <cma@cmadams.net> wrote:
So, on to my next upgrade issue (sorry for all the questions and thanks for everybody's help)... I upgraded my test cluster from 3.5 to 3.6 (latest version of each, all on CentOS 7 except the engine on CentOS 6). Now I'm working on the next step, upgrading to 4.0 and migrating the HE to the appliance.
When I went from 3.5 to 3.6, I ended up with an fhanswers.conf in the shared storage that only contained "None"; I fixed that based on some mailing list messages (but just mentioning it in case it could be related).
My problem is that the hosted engine storage domain did not get imported into the engine DB, so I can't proceed with "hosted-engine --upgrade-appliance". I didn't see any errors, so I'm not sure how that happened. I'm also not sure how to fix that.
Suggestions?
Can you please attach your engine.log ?
I recreated a 3.5 setup and upgraded the engine to 3.6 - that should have been enough to import the hosted engine storage domain, right? I do see a VDSM timeout, but I'm not sure what the command was (so, not sure if that's the problem). engine.log attached -- Chris Adams <cma@cmadams.net>
On Tue, Feb 28, 2017 at 10:04 PM, Chris Adams <cma@cmadams.net> wrote:
On Fri, Feb 24, 2017 at 8:24 PM, Chris Adams <cma@cmadams.net> wrote:
So, on to my next upgrade issue (sorry for all the questions and thanks for everybody's help)... I upgraded my test cluster from 3.5 to 3.6 (latest version of each, all on CentOS 7 except the engine on CentOS 6). Now I'm working on the next step, upgrading to 4.0 and migrating the HE to the appliance.
When I went from 3.5 to 3.6, I ended up with an fhanswers.conf in the shared storage that only contained "None"; I fixed that based on some mailing list messages (but just mentioning it in case it could be related).
My problem is that the hosted engine storage domain did not get imported into the engine DB, so I can't proceed with "hosted-engine --upgrade-appliance". I didn't see any errors, so I'm not sure how
Once upon a time, Simone Tiraboschi <stirabos@redhat.com> said: that
happened. I'm also not sure how to fix that.
Suggestions?
Can you please attach your engine.log ?
I recreated a 3.5 setup and upgraded the engine to 3.6 - that should have been enough to import the hosted engine storage domain, right?
Did you also raised the cluster compatibility level to 3.6 on the engine? Could you please upload your agent.log file from the host?
I do see a VDSM timeout, but I'm not sure what the command was (so, not sure if that's the problem).
engine.log attached -- Chris Adams <cma@cmadams.net>
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Once upon a time, Simone Tiraboschi <stirabos@redhat.com> said:
I recreated a 3.5 setup and upgraded the engine to 3.6 - that should have been enough to import the hosted engine storage domain, right?
Did you also raised the cluster compatibility level to 3.6 on the engine?
No (I didn't realize this didn't happen until that was changed). However, now I'm back into the catch-22 of 3.6.7+hosted engine: the cluster compatibility level can't be raised while there's a running VM, and that includes the hosted engine. -- Chris Adams <cma@cmadams.net>
On Wed, Mar 1, 2017 at 3:19 PM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Simone Tiraboschi <stirabos@redhat.com> said:
I recreated a 3.5 setup and upgraded the engine to 3.6 - that should have been enough to import the hosted engine storage domain, right?
Did you also raised the cluster compatibility level to 3.6 on the engine?
No (I didn't realize this didn't happen until that was changed).
However, now I'm back into the catch-22 of 3.6.7+hosted engine: the cluster compatibility level can't be raised while there's a running VM, and that includes the hosted engine.
Please see this one: https://bugzilla.redhat.com/show_bug.cgi?id=1364557 Simply define 'InClusterUpgrade' scheduling policy on the HE VM cluster
-- Chris Adams <cma@cmadams.net> _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Once upon a time, Simone Tiraboschi <stirabos@redhat.com> said:
On Wed, Mar 1, 2017 at 3:19 PM, Chris Adams <cma@cmadams.net> wrote:
However, now I'm back into the catch-22 of 3.6.7+hosted engine: the cluster compatibility level can't be raised while there's a running VM, and that includes the hosted engine.
Please see this one: https://bugzilla.redhat.com/show_bug.cgi?id=1364557
Simply define 'InClusterUpgrade' scheduling policy on the HE VM cluster
I first tried setting the policy, but got "Error while executing action: The set cluster compatibility version does not allow mixed major host OS versions. Can not start the cluster upgrade."; I guess this is because my hosts are CentOS 7 and the engine is CentOS 6? I tried changing the engine config to skip that check from comment 10 step 3, but got: - Can not start cluster upgrade mode, see below for details: - VM HostedEngine with id 4a035efd-a041-4e46-84db-01cf79400913 is configured to be not migratable. I did the SQL update from comment 1, and then I could set the policy. However, I still can't change the cluster compatibility version. -- Chris Adams <cma@cmadams.net>
On Wed, Mar 1, 2017 at 5:04 PM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Simone Tiraboschi <stirabos@redhat.com> said:
On Wed, Mar 1, 2017 at 3:19 PM, Chris Adams <cma@cmadams.net> wrote:
However, now I'm back into the catch-22 of 3.6.7+hosted engine: the cluster compatibility level can't be raised while there's a running VM, and that includes the hosted engine.
Please see this one: https://bugzilla.redhat.com/show_bug.cgi?id=1364557
Simply define 'InClusterUpgrade' scheduling policy on the HE VM cluster
I first tried setting the policy, but got "Error while executing action: The set cluster compatibility version does not allow mixed major host OS versions. Can not start the cluster upgrade."; I guess this is because my hosts are CentOS 7 and the engine is CentOS 6?
This is not an issue, are you sure that all the hosts are el7 based?
I tried changing the engine config to skip that check from comment 10 step 3, but got: - Can not start cluster upgrade mode, see below for details: - VM HostedEngine with id 4a035efd-a041-4e46-84db-01cf79400913 is configured to be not migratable.
I did the SQL update from comment 1, and then I could set the policy.
However, I still can't change the cluster compatibility version. -- Chris Adams <cma@cmadams.net> _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Once upon a time, Simone Tiraboschi <stirabos@redhat.com> said:
On Wed, Mar 1, 2017 at 5:04 PM, Chris Adams <cma@cmadams.net> wrote:
I first tried setting the policy, but got "Error while executing action: The set cluster compatibility version does not allow mixed major host OS versions. Can not start the cluster upgrade."; I guess this is because my hosts are CentOS 7 and the engine is CentOS 6?
This is not an issue, are you sure that all the hosts are el7 based?
Yes, there are only two hosts (dev/test setup), both freshly installed with CentOS 7.3 plus all current updates. -- Chris Adams <cma@cmadams.net>
Once upon a time, Chris Adams <cma@cmadams.net> said:
However, now I'm back into the catch-22 of 3.6.7+hosted engine: the cluster compatibility level can't be raised while there's a running VM, and that includes the hosted engine.
I'm still stuck on this - anybody have any solution? Because of this, I can't upgrade my cluster. -- Chris Adams <cma@cmadams.net>
Can you configure a *new* cluster and migrate the engine to that? You should be able to import your existing storage domains and logical networks under the new cluster which can then be used as a migration target for any running VMs. Your other option would be to build a new engine using 4.0 and then restore your 3.6 backup. On 03/07/2017 04:32 PM, Chris Adams wrote:
Once upon a time, Chris Adams <cma@cmadams.net> said:
However, now I'm back into the catch-22 of 3.6.7+hosted engine: the cluster compatibility level can't be raised while there's a running VM, and that includes the hosted engine. I'm still stuck on this - anybody have any solution? Because of this, I can't upgrade my cluster.
participants (3)
-
Chris Adams -
Michael Watters -
Simone Tiraboschi