DHCP Backend Validation Matrix
Purpose
This document defines the default validation matrix for xCAT DHCP backend changes.
Use this matrix for:
backend selection changes
DHCP renderer changes
reservation add, delete, or query changes
DDNS and service-management changes
PXE, xNBA, or boot-policy changes
Acceptance Scope
The validation result for this matrix is scoped to DHCP backend behavior and boot handoff:
backend selection matches the platform policy
generated backend configuration validates with the backend-native validator
static reservations allocate correctly, including Kea reservations outside
networks.dynamicrangedynamic pools are emitted only by the DHCP server that owns the network
the expected bootloader, node script, kernel, initrd, or root image artifacts are offered and fetched for the row under test
shell-oriented rows reach the expected xNBA or Genesis shell state
Failures after the expected boot artifacts have been delivered are image, initrd, kernel, userspace, or packaging follow-up work. They must be tracked, but they do not turn the DHCP backend acceptance row red unless the failure is caused by DHCP policy, allocation, or boot option rendering.
Secure Boot is not part of this matrix. Secure OVMF builds such as
OVMF_CODE.secboot.fd and OVMF_VARS.secboot.fd must be treated as
unsupported unless xCAT explicitly adds Secure Boot support.
Backend Policy
The default backend split is:
EL9, Ubuntu 20.04 LTS, and older supported releases:
ISC DHCPEL10, Ubuntu 22.04 LTS, and newer supported releases:
Kea
site.dhcpbackend=auto must follow that rule. Explicit isc and kea
overrides remain available for development and troubleshooting.
Always-Run Checks
Run these checks for every DHCP backend change before live validation:
Perl syntax checks for changed DHCP modules
unit tests for backend selection, range handling, boot policy, and renderer behavior
Kea version-aware renderer checks when client classification is touched:
Kea 2.4 output must use
only-if-requiredandrequire-client-classesKea 3.x output must use
only-in-additional-listandevaluate-additional-classesKea UEFI x86_64 boot classes must cover PXE architecture ids
0x0007and0x0009plus UEFI HTTP boot architecture id0x0010
backend-native configuration validation:
dhcpd -t -cf <config>for ISCkea-dhcp4 -t <config>for Kea DHCPv4kea-dhcp6 -t <config>for Kea DHCPv6 when usedkea-ctrl-agent -t <config>for Control Agent when usedkea-dhcp-ddns -t <config>for D2 when used
Default Live Matrix
The following matrix is the default live validation gate for DHCP backend work.
Platform |
Arch |
Backend |
Boot Validation |
Minimum Required Checks |
|---|---|---|---|---|
EL9 |
|
|
|
|
Ubuntu 20.04 LTS |
|
|
|
|
Ubuntu 22.04 LTS |
|
|
|
|
EL10 |
|
|
|
|
Ubuntu 24.04 LTS |
|
|
|
|
Ubuntu 26.04 LTS |
|
|
|
|
Kea Boot and Reservation Regression Matrix
Run this matrix whenever a change touches Kea boot policy, client classification, address pools, or host reservations.
Scenario |
Backend Scope |
Minimum Required Checks |
|---|---|---|
BIOS PXE/xNBA |
|
DHCP offer for architecture |
UEFI PXE architecture |
|
Client matches |
UEFI PXE architecture |
|
Same checks as |
UEFI HTTP architecture |
|
Client matches |
Static reservation outside dynamic pool |
|
Node address is inside the Kea subnet and outside
|
Static reservation inside dynamic pool |
|
Record the expected behavior explicitly. Current |
Dynamic pool ownership in hierarchy |
|
When |
Stateful netboot image |
|
DHCP/TFTP/HTTP handoff reaches kernel, initrd, root image, and the expected xCAT node state. |
Stateless netboot image |
|
DHCP/TFTP/HTTP handoff reaches the stateless image and validates post-boot xCAT state. |
|
|
Reproduce a node with static reservation and no usable dynamic pool; confirm Kea still allocates the reserved address and no allocation failure is logged. |
Extended Architecture Matrix
Run the extended matrix when a change touches architecture-specific boot logic,
client classification, firmware-specific file paths, or non-x86_64 code
paths.
Platform |
Arch |
Backend |
Boot Validation |
Minimum Required Checks |
|---|---|---|---|---|
EL10 |
|
|
|
DHCP offer; boot file handoff; POWER boot-path correctness; Genesis shell when Genesis payload validation is in scope |
Ubuntu 26.04 LTS |
|
|
|
package installation on |
Current Lab Baseline
KVM validation should cover both x86_64 and ppc64le hosts. Record the
repeatable lab access method privately with the validation run instead of
embedding site-specific hostnames or credentials in this repository.
Full Ubuntu 24.04 x86_64 stateless KVM validation required Ubuntu
genimage fixes for early BOOTIF handling and a lean initrd driver set.
Those image-generation fixes are tracked separately from the Kea DHCP backend
policy changes.
Known Exceptions
Known blockers do not remove the matrix requirement. They must be recorded explicitly in the validation result. A blocker only turns a DHCP acceptance row red when the root cause is DHCP backend policy, allocation, or boot option rendering.
Current exceptions:
Ubuntu 22.04 LTS ISC OMAPI/
omshellhost reservation updates are unreliable on current upstream code and are not caused by the Kea backend work.site.dhcpbackend=autotherefore selects Kea for Ubuntu 22.04 and newer releases; live Ubuntu 22.04 Kea validation remains a follow-up matrix row.Ubuntu
ppc64lepackage installation is missing required boot packages such asgoconserver,grub2-xcat, andxcat-genesis-base-ppc64. This is tracked separately and is not a Kea DHCP behavior issue.
Current PR Validation Snapshot
As of April 26, 2026, this PR has the following DHCP backend acceptance result for the supported KVM rows. All rows in this table are green for the DHCP backend scope described above.
Platform |
Arch |
Backend |
Boot Path |
Result |
Notes |
|---|---|---|---|---|---|
EL9 |
|
|
BIOS PXE/xNBA |
Pass |
DHCP/TFTP, node-specific xNBA handoff, Genesis shell, and compute-image validation passed. |
EL9 |
|
|
UEFI PXE/xNBA |
Pass |
Non-Secure-Boot UEFI DHCP/TFTP, node-specific xNBA handoff, Genesis shell, and compute-image validation passed. |
EL9 |
|
|
POWER GRUB/Genesis |
Pass |
DHCP/TFTP/GRUB handoff fetched |
EL10 |
|
|
BIOS PXE/xNBA |
Pass |
Static reservation outside |
Ubuntu 24.04 LTS |
|
|
BIOS PXE/xNBA |
Pass |
Static reservation outside |
EL10 |
|
|
UEFI PXE/xNBA |
Pass |
Non-Secure-Boot UEFI path matched the Kea x86_64 UEFI boot policy;
regenerated compute-image boot reached |
EL10 |
|
|
UEFI HTTP arch |
Pass |
Raw DHCP fixture on the KVM provisioning bridge sent option 93
|
Ubuntu 24.04 LTS |
|
|
UEFI PXE/xNBA |
Pass |
Non-Secure-Boot UEFI path matched the Kea x86_64 UEFI boot policy;
xNBA shell passed; compute-image boot fetched |
EL10 |
|
|
POWER GRUB/Genesis |
Pass |
Static reservation outside |
Ubuntu 24.04 LTS |
|
|
POWER GRUB/Genesis |
Pass |
Static reservation outside |
Ubuntu LTS KVM Validation Snapshot
As of May 1, 2026, the Ubuntu LTS KVM validation for the Ubuntu provisioning restoration work has the following result:
Platform |
Arch |
Backend |
BIOS Stateless |
BIOS Stateful |
UEFI Stateless |
UEFI Stateful |
Notes |
|---|---|---|---|---|---|---|---|
Ubuntu 18.04 LTS |
|
|
Pass |
Pass |
Pass |
Pass |
Stateless and stateful compute boots passed against an Ubuntu 18.04
headnode. The 18.04 debian-installer initrd did not include
|
Ubuntu 20.04 LTS |
|
|
Pass |
Pass |
Pass |
Pass |
Stateless and stateful compute boots passed. Stateful validation used a manual static reservation workaround for the known forced-ISC OMAPI issue. |
Ubuntu 22.04 LTS |
|
|
Pass |
Pass |
Pass |
Pass |
Stateless and stateful compute boots passed. Kea 2.0.2 configuration
validation with |
Ubuntu 24.04 LTS |
|
|
Pass |
Pass |
Pass |
Pass |
Stateless and stateful compute boots passed. Kea 2.4.1 configuration
validation with |
Ubuntu 26.04 LTS |
|
|
Pass |
Pass |
Pass |
Pass |
Stateless and stateful compute boots passed against an Ubuntu 26.04
headnode. Kea 3.0.3 configuration validation with |
Follow-up Tracking
These issues are outside the DHCP acceptance result but must be referenced when reporting this validation run:
Issue |
Area |
Impact |
|---|---|---|
Ubuntu |
Ubuntu |
Missing |
|
|
EL10 ppc64le fails with |
Reporting Rule
Every DHCP backend PR should summarize validation using this matrix:
what rows were run
what passed
what failed
what was blocked by a known external issue
If a row was skipped, the PR should state why.