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 image upgrades, Hotpatching, and Azure Update Manager won't be available. To utilize these features, it's recommended to create a new VM using your preferred operating system instead of performing an in-place upgrade.
According to https://learn.microsoft.com/en-us/azure/virtual-machines/workloads/redhat/redhat-in-place-upgrade, Azure Update Manager will break if any RHEL in-place upgrades are performed due to data/control plane disconnect.
As a Microsoft product, this dilemma seems to defeat the benefits of AUM if you're someone like me who uses Redhat 'pet' VMs (as opposed to 'cattle' VMs) for work, and would frankly like to centralize all operations within the lifecycle of a Linux box inside the Azure tenant (patching, upgrading, rollback, any possible automation/application deployment etc). Unfortunately it would seem that this issue is largely something outside of the Azure customer's control.
So, to anyone with esoteric Azure knowledge: what gives? Why and how is there a data disconnect between the control planes? What does the process look like from a bird's eye view? Given that the issue exists in the first place I would imagine that there is some kind of developmental contradiction, otherwise a feature like this probably would have been figured out a while ago (or that it is, as I suspect, simply not high priority enough despite a solution which may already exist in development).
Furthermore, for those who may have more intimate info on the matter, does any sort of discussion or planning of a solution for this issue exist?
With kindness,
MadDogOfShimano
2 Replies
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?
As of now, Microsoft’s official guidance is to avoid in-place upgrades and instead:
- Create a new VM from the desired RHEL image
- Migrate workloads and data
- Re-register with Update Manager and other services
