Phase 1: Foundation Orchestration & Pre-Imaging Preparation
1. Foundation Session Initialization
Foundation does not immediately image the server. It first creates and activates its internal imaging workflow.
Foundation associates the imaging workflow with a NodeConfig object representing the target CVM and spins up local CherryPy/Flask microservices on your laptop or deployment machine to handle the imaging tasks.
2. Node Discovery
Foundation attempts to locate the physical nodes. It broadcasts over the local Layer 2 network segment using IPv6 link-local multicast (via the WS-Discovery protocol). It listens for replies from factory-fresh nodes or unconfigured hardware listening on the network.
Foundation is using its internal RPC mechanism to resolve information from the node before applying the final configuration.
3. Network Provisioning & Verification
Foundation begins constructing the network configuration that will ultimately be applied to the target environment. It subsequently configured AHV networking and tested the permanent CVM IP.
4. Deployment Validation
The validation worker maps target nodes, matches network configuration schemes, and processes local manifest checksums to prevent image corruption.
It checks internal metadata descriptors to guarantee that all required components, including the software images for Zeus, Stargate, and Cassandra, are complete and uncorrupted.
5. Phoenix Preparation
To install a clean hypervisor and CVM, the node must boot into a temporary, memory-resident micro-installation environment called Phoenix.
Foundation determines the node will be imaged via CVM/Phoenix path or IPMI imaging path.
Before attempting to boot the node into Phoenix, Foundation checks whether the node is already operating in Phoenix via SSH.
6. AHV Gateway APIs
Foundation tries to inspect /root/phoenix If the authentication fails because the node is running a factory-installed copy of AHV, it communicates directly with the hypervisor host gateway via secure HTTPS calls to port 7030.
It submits a multi-part POST payload to the host's endpoint to push the generated Phoenix kernel files. (If no compatible hypervisor exists, it falls back to mounting an ISO over IPMI Virtual Media).
7. Kernel Generation
Foundation dynamically builds a custom boot package. It extracts a mini Linux kernel, initial ramdisk (initrd), and a compressed read-only root filesystem (squashfs.img). This temporary OS is embedded with the precise automation scripts needed to image that specific node.
8. Phoenix Payload Staging
The Phoenix library initiates the staging process by preparing the required boot component as a multipart payload. The payload is then submitted to the AHV Host API using a POST request.
The API responds successfully, and the subsequent Phoenix log confirms that the kernel and initrd files were staged successfully, demonstrating successful communication with the AHV Gateway and completion of the staging operation.
9. Phoenix Integrity Verification
Phoenix performs integrity verification of the custom kernel components using SHA-256 checksums. The Foundation retrieves the custom kernel information, including SHA-256 checksums for the kernel, initrd, and SquashFS image.
These explicit checksum values provide cryptographic evidence that the system components can be verified for integrity and detected if they have been altered or corrupted.
10. Phoenix Boot
With the boot images staged in memory, Foundation sends a command to reboot the host. The node restarts, bypassing its standard boot disk, and boots directly into the customized Phoenix environment running entirely in the physical node’s RAM.
Phase 2: Phoenix Preparation & Boot Transition
11. Phoenix Hardware Discovery
Once Phoenix is active, Foundation generates hardware information in JSON file which contains chassis, storage controller, sensor, CPU, memory, and boot-device information.
12. RAID Platform Check
The imaging process performs a platform-specific storage check and determines that this system does not use the RAID boot-drive configuration targeted by the NX G7+ logic. As a result, the RAID validation/handling steps are bypassed, and the deployment proceeds through the standard imaging path.
13. Pre-Install Hardware Assessment
Before installing AOS, Foundation enters its pre-install workflow, moves the node into a staging environment, verifies the intended AOS version, and prepares the installation package.
14. Secure Boot & Boot Device Detection
During the pre-install checks, Foundation verifies the system’s boot security and storage identity. It confirms that Secure Boot is not enabled and identifies the boot device through its serial number, since no WWN is available.
15. Phoenix Node-Specific Configuration
Foundation starts the Phoenix imaging stage and builds configuration specifically for this particular node by creating a JSON configuration file which contains information needed for the imaging process, such as the node's hardware/platform characteristics and the installation parameters required for that particular deployment.
16. FRU & VPD Identification
Phoenix processes FRU/VPD information to identify platform-specific hardware details, such as component and system metadata. This information supports accurate hardware identification and node-specific configuration.
2026-05-25 12:27:03,194Z log.py:102 INFO sysUtil.py:1231 vpd_info {'vpd_method': 'nx_g10_dmi', 'rackable_unit_serial': '69SG8F115196', 'node_serial': 'WM292S251992', 'node_position': 'A'}
17. BIOS & VMD Configuration Evaluation
Phoenix evaluates the node for VMD-specific storage configuration and determines that VMD normalization is not supported for this hardware type. As a result, the workflow skips VMD-related BIOS setting updates and continues without making VMD configuration changes.
18. AOS & AHV Packages Download
Phoenix prepares to obtain the required AOS/AHV installation packages for the deployment. The deployment is associated with AOS version 7.5.0.5 & with AHV version 11.0.0.1, and the Foundation environment provides the corresponding installation package.
Phase 3: Bare-Metal Provisioning & CVM Imaging
19. CVM Resource Evaluation
Foundation starts the CVM installation process and evaluates the node’s available CPU, memory, storage, and NUMA topology. It identifies the available compute resources, checks hyperthreading, determines the NUMA location of the storage controllers, and evaluates the available storage capacity. These hardware characteristics are used as inputs for determining the appropriate CVM configuration.
20. CVM Sizing & NUMA Configuration
After evaluating the available hardware resources, Foundation calculates the appropriate CVM CPU and memory allocation and determines whether NUMA optimization should be enabled.
21. CVM Installer Preparation
Foundation prepares the CVM installer by generating unique SSH and SSL credentials for the Hypervisor-CVM pair. It then extracts the SVM installer, injects the required SSH keys, loads the HCL hardware compatibility information, and identifies the host’s boot disk for the upcoming CVM deployment.
22. CVM Chroot Installation
Foundation prepares a controlled chroot installation environment for deploying the CVM. It mounts the required system, storage, installer, staging, and Phoenix paths, copies the hardware configuration, and extracts the SVM installer. After the preparation step, the temporary environment is unmounted.
23. CVM Boot Image Selection
Foundation determines the appropriate boot image for the CVM installation. The AOS release provides multiple boot-image options and that Foundation selects the new boot image for starting the CVM installation process.
24. Boot Device Detection & Initial Cleanup
Foundation begins the SVM imaging operation. At this stage, Foundation identifies the SVM imaging task and determines which NVMe device is currently being treated as the boot device.
Foundation removes the existing ahv volume group so that the disks can be reused for the new deployment.
25. Data Disk Discovery
Phoenix identifies the disks that will participate in the deployment. In this node, four data devices are detected: 2 SATA devices and 2 NVMe devices. Foundation process aggressively cleans the disks before creating the new layout.
26. SVM Rescue Start
Phoenix launches svm_rescue in factory deployment mode. Foundation is now handing the low-level CVM deployment to the SVM rescue which begins performing the actual disk and filesystem deployment operations.
27. Boot Disk Partitioning
Phoenix identifies the 2 NVMe devices as the boot devices and determines that both require a fresh storage layout. The disks are blank, so Phoenix creates the required partition structure on each device.
The first 3 partitions on each NVMe disk are designated for boot storage, while the fourth partition is reserved for the data layer.
Phoenix also prepares the data partitions by clearing their existing contents and formatting them for use by the Nutanix data filesystem.
28. Redundant Boot Storage
Once both NVMe boot devices have been partitioned and cleaned, Phoenix combines matching boot partitions from both NVMe devices into mirrored RAID1 volumes for the SVM boot environment.
29. SVM Root Filesystem Preparation
Phoenix mounts the SVM storage as the target root filesystem and prepares the internal filesystem structure required by the SVM image.
Dedicated filesystem images are created and formatted for system data and logging, establishing the environment needed for the SVM OS and its runtime components.
30. CVM Deployment & Configuration
Phoenix extracts the base SVM image into the prepared target filesystem and updates its filesystem configuration. It then prepares the logging environment, installs the Nutanix software stack components, and optimizes the deployed files by hard-linking duplicate files.
31. CVM Post-deployment
Phoenix performs post-deployment changes to align the CVM boot environment with the deployed storage. It updates the root filesystem identity, prepares RAID metadata, updates the boot initialization data, and creates the Nutanix boot marker with the kernel, boot parameters and root filesystem information required to boot the deployed CVM.
32. CVM Data Storage Preparation
Phoenix prepares the additional storage required by the SVM, including the home and audit logging areas. It updates the filesystem configuration, fixes required permissions, and populates the data area with the Nutanix installer and software packages.
33. CVM Access & Security
Phoenix prepares the CVM for normal operation by configuring SSH access, gateway certificates, and runtime settings.
34. Filesystem Security Finalization
Phoenix applies the required SELinux contexts, synchronizes the filesystem, and unmounts the deployed filesystems before cleanup.
Phase 4: AHV Deployment & Host Configuration
35. CVM Initialization & Node Layout
Foundation initializes the CVM environment by locating the boot partition, generating the required configuration files, enabling automatic SELinux relabeling, and creates the hardware layout for the target Nutanix node.
36. Hardware & Firmware Detection
Foundation detects the underlying server platform and attempts to retrieve firmware/BMC information using the Supermicro Update Manager (SUM).
37. SVM Imaging Completion
Foundation reports the completion of the SVM imaging operation.
38. CVM Sizing & Installation Parameters
Foundation determines the resources required for the CVM and gathers storage/network information needed for the AHV installation.
39. AHV Metadata ISO Generation
Foundation confirms that the AHV version supports metadata ISO and packages the required SVM boot image and hardware configuration into the metadata ISO.
40. Hypervisor Installer VM Initialization
Foundation prepares and launches the QEMU/KVM-based Installer VM using the designated NVMe installation device, AHV installer ISO, and AHV metadata ISO.
Once the Installer VM starts, it loads the installation parameters and validates the target AHV configuration, including the installation device and node hostname, before proceeding with hypervisor deployment.
41. AHV Hypervisor Installation
The actual AHV installation begins. Foundation reports installation progress approximately every 30 seconds while the hypervisor image is written to the target device.
42. AHV Post-Installation & Reboot
Once the main hypervisor image is installed, Foundation performs the required post-installation activities on the node. This includes preparing the LVM configuration for Nutanix storage services and completing the remaining hypervisor installation tasks.
Foundation then initiates the AHV reboot sequence so the newly installed hypervisor can boot from the configured system partition.
43. AHV Installation Verification
Foundation verifies the installed AHV image and confirms that the Acropolis base software installation completed successfully.
44. Node Reboot & Foundation Connectivity
The node is rebooted after AHV installation. After the reboot, Foundation confirms that the node can communicate with the Foundation machine using the available network interfaces.
45. BMC & Network Interface Setup
Foundation configures the BMC interface and examines the br0-up network bond to identify which physical interface is currently active by its MAC address and assigns it as the primary member of the bond.
Phase 5: CVM Initialization & Node Bring-Up
46. First-Boot Configuration
During the first-boot stage, the newly installed AHV host applies its initial system configuration and prepares core services for normal operation.
The first-boot process confirms that the AHV network setup has completed and then initializes the iSCSI initiator. Foundation also starts the hostname configuration process and installs the required SSH keys.
In parallel, the node updates the LLDP daemon configuration and synchronizes the hostname information with the OVSDB database.
47. CVM Virtual Network Creation
Foundation defines the CVM and prepares the local virtual network required for the CVM. Since the CVM and local network do not already exist, Foundation creates them.
48. CVM Domain Creation & Startup
Foundation creates the VM definition for the Nutanix CVM on the newly installed AHV host. The CVM is implemented as a libvirt-managed virtual machine, so Foundation first verifies that the expected CVM domain exists, generates its XML definition containing the CVM's virtual hardware and configuration, and starts the CVM.
Phase 6: Post-Deployment & Workflow Completion
49. First-Boot Completion & CVM Boot
The AHV host completes its first-boot process and subsequently confirms that the CVM has successfully booted.
50. Post-Installation Configuration
After the CVM successfully boots, Foundation performs the final post-installation activities for the node. It first applies the deployment-specific configuration, including the deployment type and time-zone settings.
Foundation records the deployment as successful and updates its internal Pulse/deployment status with the node's installation details, including the AOS version, AHV version, KVM hypervisor type, deployment type, Foundation version, and imaging status.
51. Final Pulse Update & Installation Completion
The final deployment data is copied to the CVM, the node's temporary pulse data is removed from the Foundation master configuration, and the overall imaging step transitions from RUNNING to FINISHED.