Forum Discussion
RHEL In-place upgrades and Azure Update Manager
Following the process in this article will cause a disconnection between the data plane and the control plane of the virtual machine (VM). Azure capabilities such as Auto guest patching, Auto OS ima...
That's very correct Kidd_Ip, great job! That's exactly why I initially put that article and quote line you reiterated as the very first line of the post 😊 thankfully Microsoft was already very clear on what their official guidance was, but unfortunately that readily available public information was not the answer I was looking for, because as indicated by the very first line of the post, I already read that exact same article 😢.
To anyone reading this who may accidentally repost the same article despite it already being the very first line of the post: let me rephrase this into the think-for-me machine (a.k.a. an LLM) so it's easier to comprehend:
- Core Issue and Design Question: Why does performing a RHEL in-place upgrade break Azure Update Manager (AUM) due to a control/data plane disconnect? Is there an underlying architectural or developmental contradiction that prevents AUM from supporting in-place upgrades?
- Mechanics: How exactly does this disconnect occur between the Azure and Red Hat control planes during an upgrade?
- Architecture View: What does the in-place upgrade process look like from a high-level (bird’s-eye) perspective within Azure’s infrastructure?
- Roadmap Inquiry: Is Microsoft or Red Hat actively discussing or planning a solution to enable RHEL in-place upgrades without breaking AUM integration?