Changing CPU type from Opteron G3 to Epyc with hosted engine in 4.3
Hi! Now that I have engine and nodes on 4.3 level I'm stuck on upgrading the CPU type. I have 2 node cluster with Epyc processors. It was originally installed with 4.2 so it chose CPU type as Opteron G3 (no Epyc support back then). In Engine 4.3 Epyc is available as CPU type when I choose Compatibility Version: 4.3. Big problem is that it doesn't allow to upgrade CPU because all hosts are not in maintenance: "Error while executing action: Cannot change Cluster CPU type unless all Hosts attached to this Cluster are in Maintenance". Putting all hosts to maintenance is impossible because Engine is hosted in the cluster. I tried with Global HA maintenance, but that didn't help. What is the correct way to solve this problem? Thanks, -Juhani
On Tue, Feb 5, 2019 at 8:24 AM Juhani Rautiainen <juhani.rautiainen@gmail.com> wrote:
Hi! Now that I have engine and nodes on 4.3 level I'm stuck on upgrading the CPU type. What is the correct way to solve this problem?
So it seems that I have to reinstall the whole cluster because usually the silence means that there is no solution. As it currently stands I don't see any other way. I made bugzilla entry about the problem (1672859). This problem has been discussed shortly on this list 2016 but probably nobody bothered to do the bug report back then. Makes upgrading hardware bit pointless if you can't use new CPU features. -Juhani
On Wed, Feb 6, 2019 at 5:21 AM Juhani Rautiainen < juhani.rautiainen@gmail.com> wrote:
On Tue, Feb 5, 2019 at 8:24 AM Juhani Rautiainen <juhani.rautiainen@gmail.com> wrote:
Hi! Now that I have engine and nodes on 4.3 level I'm stuck on upgrading the CPU type. What is the correct way to solve this problem?
So it seems that I have to reinstall the whole cluster because usually the silence means that there is no solution. As it currently stands I don't see any other way. I made bugzilla entry about the problem (1672859). This problem has been discussed shortly on this list 2016 but probably nobody bothered to do the bug report back then. Makes upgrading hardware bit pointless if you can't use new CPU features.
You can simply upgrade the cluster if all the hosts are in global maintenance mode. The only case that could prevent that is that you are in hosted-engine mode and so you cannot set the latest host into maintenance mode without loosing the engine itself. If this is your case, what you can do is: - set HE global maintenance mode - set one of the hosted-engine hosts into maintenance mode - move it to a different cluster - shutdown the engine VM - manually restart the engine VM on the host on the custom cluster directly executing on that host: hosted-engine --vm-start - connect again to the engine - set all the hosts of the initial cluster into maintenance mode - upgrade the cluster - shut down again the engine VM - manually restart the engine VM on one of the hosts of the initial cluster - move back the host that got into a temporary cluster to its initial cluster
-Juhani _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/54K7BGQEWESN2D...
On Wed, Feb 6, 2019 at 10:31 AM Simone Tiraboschi <stirabos@redhat.com> wrote:
You can simply upgrade the cluster if all the hosts are in global maintenance mode.
Like I originally wrote it doesn't work like that for me. This was what I tried. I tried again now and even confirmed from cli that it is correct mode: # hosted-engine --vm-status !! Cluster is in GLOBAL MAINTENANCE mode !! And still I get this: "Error while executing action: Cannot change Cluster CPU type unless all Hosts attached to this Cluster are in Maintenance" Is there a log where I can check if there are some traces why it gives this error message?
The only case that could prevent that is that you are in hosted-engine mode and so you cannot set the latest host into maintenance mode without loosing the engine itself.
If this is your case, what you can do is: - set HE global maintenance mode - set one of the hosted-engine hosts into maintenance mode - move it to a different cluster - shutdown the engine VM - manually restart the engine VM on the host on the custom cluster directly executing on that host: hosted-engine --vm-start - connect again to the engine - set all the hosts of the initial cluster into maintenance mode - upgrade the cluster - shut down again the engine VM - manually restart the engine VM on one of the hosts of the initial cluster - move back the host that got into a temporary cluster to its initial cluster
I might try this one. Thanks, Juhani
participants (2)
-
Juhani Rautiainen -
Simone Tiraboschi