I'm migrating an expensive Azure Virtual Desktop setup to a leaner VM Scale Set with dynamic autoscaling. Because the machines require custom software, I created a private Azure Compute Gallery image definition and version based on a specialized image.
I'm concerned that specialized images may preserve the source machine's hostname or identity, potentially causing naming and DNS conflicts when VMSS instances are created. A generalized image seems more appropriate, but I'm unsure how VMSS handles the hostname and local administrator credentials automatically during deployment. We still need a fallback local administrator account for situations where a machine is not domain joined or loses its domain relationship.
The bigger concern is building a repeatable image-maintenance process without destroying the golden VM. Generalizing or capturing a VM appears to make the source unusable, and a snapshot I created in another subscription also produced an unusable result. I'm considering this workflow:
- Maintain a golden VM with the required software.
- Apply patches and application updates.
- Shut down the VM and create a snapshot or managed image.
- Create a generalized image version for the gallery, possibly using a temporary VM cloned from the snapshot.
- Restore the golden VM from its snapshot if the capture process changes it.
- Repeat the process during the next patch cycle.
Is this approach sound? Should I use Azure Image Builder or Packer instead, and how should I handle hostnames, administrator credentials, and trusted launch limitations in a VMSS image pipeline?
4 Answers
Don’t generalize the only copy of your golden VM. Keep the source VM intact, or create a stopped snapshot or disk copy and use that to create a temporary build VM. Generalize and capture the temporary VM, publish the resulting image version, then delete the temporary resources. If you need a rollback point, keep the snapshot in the same subscription and resource context where possible; moving resources across subscriptions can break managed-disk references or otherwise complicate recovery.
For a practical workflow, shut down the source before taking a consistent snapshot, then build and generalize a disposable VM created from that snapshot. Alternatively, let Packer or Azure Image Builder create the temporary build machine for you. After testing the new gallery version, update the VMSS model and roll out the image through a controlled upgrade. This is safer than capturing the VM that you intend to keep using.
A better long-term approach is to avoid treating one running VM as the permanent golden source. Use Packer or Azure Image Builder to build a fresh image from a known base image, install the required software and updates, run validation, and publish a new Azure Compute Gallery version. That gives you a repeatable pipeline and avoids having to generalize or capture the same production VM repeatedly.
Packer looks promising, although trusted launch machines don’t appear to be supported in our current setup, so I’ll need to verify whether Azure Image Builder or another workflow can cover that requirement.
VMSS instances normally receive their own computer name during deployment, so you shouldn’t need to manually assign hostnames. The deployment process can also create or inject the configured administrator account. Services should run under their intended service identities rather than depending on an interactive local administrator login, but keeping a break-glass account for recovery is a separate and reasonable requirement.
The local administrator is only a fallback for machines that aren’t domain joined or have a broken domain relationship. It isn’t used to run services, but it is still important for recovery in our environment.
That explains why my earlier test may have failed. I’ll repeat it without moving the snapshot to another subscription and verify whether restoring the snapshot brings the source VM back correctly.