Compartir a través de

Question - Machine scale set configuration

David Fernando Lopez Cueca 60 Puntos de reputación
2026-05-20T17:04:31.22+00:00

We currently have a machine scale set configured for the worker nodes of an ARO OpenShift cluster. This infrastructure is also mapped to a UCMDB platform to manage the various infrastructure assets at the application level. We've observed that when new machines are created within the machine scale set, the name changes dynamically, particularly the last few letters. Our specific question is whether it's possible to configure the machine set so that when new machines are created or deleted, they are assigned the exact same name, thus avoiding the need to modify the UCMDB entry.

Azure Virtual Machine Scale Sets
Azure Virtual Machine Scale Sets

Recursos de proceso de Azure que se usan para crear y administrar grupos de máquinas virtuales heterogéneas con equilibrio de carga.


1 respuesta

Ordenar por: Muy útil
  1. Nikhil Duserla 9,940 Puntos de reputación Personal externo de Microsoft Moderador
    2026-06-05T10:11:43.5966667+00:00

    Hey David, it looks like you’re hitting a common limitation: Azure VM Scale Sets (and by extension the ARO OpenShift worker nodes running on them) always generate instance names with a dynamic suffix by design. There isn’t a built-in way to force each new or replacement VM to use the exact same hostname as its predecessor. Here are a few workarounds you can consider so you don’t have to manually update your UCMDB entries each time:

    1. Monitor the Scale Set resource, not individual VMs Instead of treating each VM as a separate CI, consider tracking the VMSS or OpenShift MachineSet object in UCMDB. That resource name (for example, aro-<clustername>-worker-<region>) is stable and doesn’t change when you scale in or out.
    2. Use Azure tags for a stable identifier During provisioning (via an ARM template, Azure CLI, or an Automation runbook), apply a fixed tag like logicalName = worker-node-01 or appRole = aro-workernode Then configure UCMDB discovery to key off the tag value instead of the VM name. Tags survive reimages and replacements.
    3. Automate UCMDB updates with Event Grid + Runbooks Subscribe to VMSS scale-in/scale-out events in Azure Event Grid, then fire an Azure Logic App or Automation Runbook that calls the UCMDB REST API to add or remove CI records automatically. This eliminates manual intervention entirely.
    4. Leverage scale-in policies to reuse instance IDs more predictably While you can’t guarantee names, you can pick a scale-in policy (Default, OldestVM, NewestVM) so that instance IDs roll over more consistently. In many steady environments, a replacement VM will end up with the same numeric suffix (for example, vmssname_2), which may reduce CI drift.

    Note: With ARO, don’t modify the underlying VMSS directly—always scale via the OpenShift Machine API (oc scale machineset) or the OpenShift console. Direct edits to the VMSS can conflict with the ARO operator.

    Hope that helps!

    Reference list

    Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

    ¿Le ha resultado útil esta respuesta?

    0 comentarios No hay comentarios

Su respuesta

Las respuestas pueden ser marcadas como "Aceptadas" por el autor de la pregunta y "Recomendadas" por los moderadores, lo que ayuda a los usuarios a saber que la respuesta ha resuelto el problema del autor.