Why this. If you have a new infrastructure you should do on you old system a complete backup of your 1.6 installation. Restore this with the same 1.6 on the new infrastructure and then upgrade to 2.0 as described in the article.
I agree with Andreas: The URL you posted, contains multiple scenarios how to update to 2.x, so I believe you can follow this guide. It even contains instructions how to do this “live” from one machine to the other.
My infrastructure consists of a physical master “centos 8” with two VM slaves “centos 8” connected to each other in distributed monitoring via TLS.
I was struggling to create a fully virtualized infrastructure on new redhat 8 machines recreate distributed monitoring and complete it via export and import.
Otherwise you say that I should first replace the physical master then follow the guide to upgrade to 2.0?
As far as I understood your initial post, your goal was/is to update one instance
from Checkmk 1.6.x to 2.0.x. Your last post is referring to a distributed monitoring setup,
so you need to update multiple instances.
As per the update guide, the recommended procedure to do this, is to stop all instances,
update all of them, and start them all up again: That’s all you need to take care of.
Checkmk, and updates for it, are - more or less - independent of your underlying OS, resp.
your infrastructure combinations. As such, I’m hesitant to give you a recommendation for
your “example” plan, but it does sound feasible…
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.