GitHub
Sign in
Start for free
View Categories

Standardizing on premises OS images

Flow overview – Standardize Cloud OS Images #

This guide walks you through the end‑to‑end process of standardizing on-premises operating system images with XOAP. The goal is to help you build repeatable, compliant, and provider‑agnostic base images that can be used consistently across on-premises deployments on either VMware vSphere, Nutanix or XenServer. 

What Are Standardized on-premises OS Images?  #

Standardized Cloud OS Images are centrally defined, versioned, and automated operating system images that: 

  • Follow a common baseline (security, hardening, tooling) 
  • Are built in a reproducible way 
  • Can be reused across multiple environments and providers 
  • Serve as the foundation for higher‑level automation (platform management) 

XOAP acts as the control plane that defines what an image should look like and how it is built, while the actual build execution happens inside the target environment. 

What is the difference between images being created in the cloud and on-premises #

Creating images in the cloud and on-premises follows the same high-level goal—producing a reusable, standardized machine image—but differs significantly in implementation details.  

In on-premises environments, image creation typically relies on full OS installers and requires an explicit autounattend.xml for Windows to automate setup steps such as disk partitioning, locale, users, and initial configuration; additional scripts are needed to configure WinRM, open or adjust the Windows Firewall, and install the appropriate hypervisor tools (for example, VMware Tools or XenServer guest tools) to ensure manageability and performance.  

In cloud environments, many of these steps are partially abstracted by the platform through metadata services and pre-configured base images, but customization scripts are still required to align with enterprise standards.

For Linux, both cloud and on-premises image builds require unattended installation mechanisms (for example Kickstart, Preseed, or Cloud-Init) along with post-install scripts to configure SSH access, firewall rules, networking, time synchronization, and to install the relevant hypervisor or cloud-agent packages, ensuring the image integrates cleanly with the target runtime platform. 

High‑Level Architecture – How It Works  #

At a high level, the process looks like this: 

  1. XOAP defines operating systems, builders, and image definitions 
  2. An on‑premises Connector executes builds locally 
  3. Images are created using native provider tooling 
  4. Results are tracked, versioned, and reused 

Key design principles: 

  • No public inbound access required for XOAP 
  • Least‑privilege access using native identity concepts 
  • Separation of control plane and execution plane 

Short Overview of the End‑to‑End Flow  #

  • Prepare prerequisites 
  • Deploy a Connector 
  • Add an on-premises Connection 
  • Add and manage Operating Systems 
  • Configure Builders 
  • Create Image Definitions 
  • Run Image Builds 
  • Validate the created images 
  • Troubleshoot if required 
  • Next steps and extensions 

Prerequisites #

Before you start, ensure the following prerequisites are met: 

General #

  • An active XOAP Workspace 
  • Access to at least one supported on-premises virtualization platform 
  • Permissions to create images and identities in the target environment (solution specific) 
  • An Linux or Windows VM, to install the XOAP Connector which acts a s a proxy 
  • If a proxy is used for internet connection, proxy credentials are needed for the Connector 
  • Connector has access to the created images with required ports (WinRM 8595, 8596) 
  • An ISO on the datastore of the desired platform 
  • The SHA256 hash of the iso 

Cloud‑Specific  #

vSphere   #

Required privileges at vCenter level (minimum set): 

    •   Datastore 

    •   Allocate space 

    •   Browse datastore 

    •   Low level file operations 

    •   Network 

    •   Assign network 

    •   Resource 

    •   Assign virtual machine to resource pool 

    •   Virtual Machine → Inventory 

    •   Create new 

    •   Register 

    •   Remove 

    •   Virtual Machine → Configuration 

    •   Add new disk 

    •   Add or remove device 

    •   Change CPU count 

    •   Change memory 

    •   Settings 

    •   Virtual Machine → Interaction 

    •   Power on 

    •   Power off 

    •   Reset 

    •   Virtual Machine → Provisioning 

    •   Allow disk access 

    •   Allow read-only disk access 

    •   vApp 

    •   Import 

 

Best practices: 

    •   Create a dedicated vCenter role for Packer/XOAP 

    •   Assign the role at Datacenter or Folder level 

    •   Use a service account, not a personal user

Nutanix  #

Required roles / permissions: 

    •   Ability to create, update, and delete VMs 

    •   Image upload and management permissions 

    •   Network assignment permissions 

    •   Disk attach/detach permissions 

 

Recommended built-in roles: 

    •   Infrastructure Admin (broad, easiest) 

    •   Or a custom role with: 

    •   VM Create / Delete 

    •   Image Create / Update 

    •   Network View / Attach 

 

Best practices: 

    •   Use a service account in Prism Central 

    •   Scope permissions to a specific project if possible

XenServer #

Required permissions: 

    •   Pool‑admin or equivalent custom role with: 

    •   VM create / destroy 

    •   Attach / detach disks 

    •   Power operations 

    •   ISO SR access 

 

Key requirements: 

    •   Access to an ISO SR containing the installation media 

    •   Permission to create templates or base VMs 

 

Best practices: 

    •   Use a dedicated automation user 

    •   Avoid using the built‑in root account

Connector Deployment Flow  #

For most scenarios, XOAP uses a Connector that runs inside the target environment. 

Create an API Key  #

Text

Note your Workspace ID  #

Text

Install Connector on Windows  #

  • Deploy the Connector VM or service in the target environment 
  • Outbound‑only communication to XOAP (api.xoap.io) via 443 
  • No inbound firewall rules required 

Install Connector on Linux  #

  • Deploy the Connector VM or service in the target environment 
  • Outbound‑only communication to XOAP (api.xoap.io) via 443 
  • No inbound firewall rules required 

Verify Registration  #

Text

Add a Connection  #

The Connection represents the logical link between XOAP and a target environment. 

Steps:

  • Navigate to Connections in XOAP 
  • Select the target provider (Nutanix, vSphere or XenServer 
  • Insert necessary Connection information 
  • Assign the Connector that should be used for communication 
  • Save the connection 

Add connection Cloud-specific  #

Nutanix #

Text

vSphere #

Text

XenServer #

Text

At this stage, no workloads are executed yet—you are only defining where builds will later run. 

Add Operating Systems  #

Operating Systems define what base OS versions are supported for image creation. On-premises operating systems are generic for all types of on-premises hypervisors. 

Examples: 

  • Windows 11 Enterprise 
  • Windows Server 2025 
  • Ubuntu LTS 
  • RHEL 

Add Builder Configuration  #

Builders define how an image is created. 

A Builder configuration typically includes: 

  • Target platform (Nutanix, vSphere or XenServer.) 
  • CPU and RAM configuration 
  • Networking and storage configuration 
  • Temporary build resources 

Builders abstract provider differences while keeping builds transparent and auditable. 

Add a builder configuration Cloud specific #

Nutanix #

Text

vSphere #

Text

XenServer #

Text

Add Image Definition  #

An Image Definition ties everything together. 

It references: 

  • Platform 
  • Builder Configuration 
  • Operating System 
  • Provisioning steps (scripts, actions, hardening), we call it Provisioner Role. 

Run Image Definition  #

Once defined, you can start an image build: 

  1. Select the Image Definition 
  2. Trigger a run manually or via schedule 
  3. XOAP hands off execution to the Connector 
  4. Build progress and logs are tracked centrally 

Each run results in a new, versioned image artifact. 

Summary  #

By following this flow, you establish a clean, auditable, and scalable image pipeline: 

  • One control plane (XOAP) 
  • Multiple execution environments 
  • Consistent OS baselines 
  • Cloud and on‑prem parity 

This forms the foundation for enterprise‑grade automation and compliance‑driven infrastructure. 

Next steps #

Once your first standardized image is working, typical next steps include: 

Verify the Created Image  #

After a successful build: 

  • Validate the image 
  • Confirm naming and version metadata 

XOAP keeps a record of: 

  • Logs 
  • Resulting image IDs 

Validate Image Definition Cloud Specific #

Nutanix #

Text

vSphere #

Text

XenServer #

Text

Troubleshooting  #

If a build fails: 

  • Review build logs in XOAP 
  • Check Connector health and permissions 
  • Validate cloud quotas and limits 
  • Confirm network reachability inside the target environment 

Most issues are related to: 

  • Missing permissions 
  • Network misconfiguration or port restrictions 
  • Provider‑side quota limits 

Add Your Own Scripts, Applications and Configurations  #

  • Extend provisioners with custom scripts 
  • Integrate security baselines 
  • Install enterprise tooling 

Check our repo at https://xoap.io/image-management-templates 

Reuse existing Roles in the cloud  #

  • Apply the same provisioning roles to cloud images 
  • Achieve consistency across hybrid environments 

Build Higher‑Level Automation  #

  • Application packaging 
  • Stacks and roles 
  • Continuous image updates 

Getting started

Powered by BetterDocs

Scroll to Top