Validate Your Veeam Lab from RHEL

Use Ansible on RHEL to verify Veeam and vCenter network readiness.

Introduction

30 Second Summary

A backup lab can appear healthy while a missing hostname or blocked connection quietly stalls the next automation task. Checking the basics first gives you evidence before anyone changes a working system.

In this project, you will build a read-only Ansible validation kit on Red Hat Enterprise Linux that reports the local runtime. It checks TCP reachability to Veeam Backup & Replication plus VMware vCenter Server without changing either platform.

What You'll Build

Your finished kit prints a readiness report with clear connection statuses plus a checklist of missing administrator details.

By the end of this project, you'll have:

A local environment report that shows the Ansible version, RHEL release, and Python version directly in your terminal.
A reusable host configuration in vars.yml that lets every check use the same Veeam and vCenter addresses.
A read-only reachability report that labels Veeam TCP 443, Veeam TCP 9419, and vCenter TCP 443 as REACHABLE or NOT REACHABLE.
Secret Mission: Add a clear failure gate that stops the playbook when neither candidate Veeam port is reachable.

Are there any prerequisites?

You need terminal access to the RHEL control node plus the hostnames or IP addresses for the lab's Veeam and vCenter servers. If Ansible Core is missing on a standalone RHEL control node, you also need approval to install ansible-core.

Before We Start

Before any checks run, this is your moment to commit to safe discovery through local, read-only Ansible TCP checks that leave your lab unchanged. Your starting point is terminal access to the RHEL control node plus the Veeam Backup & Replication and VMware vCenter Server addresses you will enter later.

Confirm Ansible on the Control Node

Your read-only checks need a known RHEL control node with a supported runtime. Without that foundation, none of the playbooks can run.

The package path depends on whether the control node is a standalone RHEL 9 host or Red Hat Satellite. You will confirm Ansible Core before creating the empty starter workspace.

In this step, get ready to:

Identify the RHEL machine acting as the control node.
Confirm the supported Ansible runtime path.
Create the empty starter files for the validation kit.

Identify the control node

A standalone RHEL 9 node can follow an approved package path. A Satellite Server must use the runtime supported by its product release.

Use your lab notes to classify the current machine as a standalone RHEL 9 control node or a Satellite Server.
Ask the Satellite administrator for the installed product version if this machine is a Satellite Server.
Record the supplied value as your Satellite version.
Ask the Satellite administrator to confirm the product-supported Ansible runtime for that release.

Why Satellite Needs Separate Handling

Satellite ties its supported Ansible runtime to the installed product release. Changing packages without approval can move the server outside its supported configuration.

Confirm the supported runtime

The version check identifies the installed Ansible Core release. It also shows information about the executable used by your terminal.

Before you run the check, predict whether the playbook runner is already available.

Check the Ansible runtime from the terminal by running this command:

ansible-playbook --version

What Does This Check Prove?

The command confirms whether the Ansible playbook runner is available.
The --version flag prints the Ansible Core version plus executable information.
This local check does not contact Veeam Backup & Replication.
It also does not contact VMware vCenter Server.

✔️ I see version 2.16

Good work. The playbook runner is available on this control node.

You have cleared the runtime gate for the local validation playbooks.

ⓧ I see another version

A different version needs an administrator-approved support decision. The correct path depends on the type of control node.

Send the displayed version to the Satellite administrator if this machine is a Satellite Server.
Ask the Satellite administrator to confirm the supported runtime for the installed Satellite release.
Ask the RHEL administrator to confirm the approved Ansible Core update path if this machine is a standalone control node.

Need Help Interpreting the Version?

Share the complete version output with your administrator. The executable information helps them identify which runtime your terminal is using.

Ask for help with the runtime decision.

ⓧ Command not found

A missing command has separate paths for Satellite Server and standalone RHEL 9. Confirm the machine type before changing any packages.

Ask the Satellite administrator to confirm the supported runtime if this machine is a Satellite Server.
Stop this installation path if the current machine is a Satellite Server.
Get package installation approval if this machine is a standalone RHEL 9 control node.

Changing packages on a control node is a sensitive step. The command below applies only to an approved standalone RHEL 9 host.

Install Ansible Core on the approved standalone host by running:

sudo dnf install -y ansible-core

What Does This Command Do?

The dnf package manager installs Ansible Core from the host's approved repositories. The -y option accepts the package confirmation prompt.

Recheck the installed runtime by running:

ansible-playbook --version

What Should You See?

You should see an Ansible Core version plus executable information. This confirms that the playbook runner is available on the standalone control node.

That is the installation hurdle cleared. Your standalone control node can now run local playbooks.

Installation Did Not Complete?

Check that the standalone RHEL 9 host can access its approved package repositories.
Ask your administrator to resolve any repository or permission problem.
Help me troubleshoot the approved Ansible Core installation.

Create the starter workspace

The project uses four separate YAML files so each validation stays focused. Each file starts blank for the playbook added in its matching step.

Move to your Desktop by running this command:

cd ~/Desktop

What Does This Command Do?

The cd command moves the terminal into your Desktop directory. This gives the project folder a predictable location.

Create the veeam-lab-check workspace plus its empty starter files by running these commands:

mkdir veeam-lab-check
cd veeam-lab-check
touch vars.yml 01_local_check.yml 02_single_port_check.yml 03_lab_readiness.yml

What Do These Commands Create?

The mkdir command creates the veeam-lab-check directory.
The cd command makes that directory your current working location.
The touch command creates the four empty starter files.

Before you check the workspace, predict which path and filenames the terminal should show.

Confirm the working directory plus the empty starter files by running:

pwd
ls -l

What Does This Check Show?

The pwd command prints the current directory. The ls -l command lists each starter file with its size.

You should see a path ending in /Desktop/veeam-lab-check. You should also see all four filenames with a size of zero bytes.

Starter Files Missing?

Check that the printed path ends with the veeam-lab-check directory.
Repeat the workspace creation commands if a filename is absent.
Help me fix my starter workspace.

✔️ Awesome, I've got everything!

Your veeam-lab-check directory now contains all four empty starter files. Keep this terminal in the same directory for the next step.

ⓧ I'd like to double check the full code

The complete contents of every starter file are blank at this stage. An empty editor pane is the correct full-file state.

The 01_local_check.yml file is empty.
The 02_single_port_check.yml file is empty.
The 03_lab_readiness.yml file is empty.
The vars.yml file is empty.

Your control node now has a confirmed runtime path plus a clean workspace. Next, you will turn the first empty file into a local facts playbook.

Run a Local Validation Playbook

Your Ansible runtime is ready on the RHEL control node. The next proof is whether it can execute a playbook locally before your lab checker contacts any remote system.

The playbook targets localhost through a local connection. Gathered facts then supply the runtime details you can verify on screen.

In this step, get ready to:

Build 01_local_check.yml as a local fact-gathering playbook.
Check the playbook syntax.
Run the playbook to print the control node's runtime details.

Build the local playbook

Ansible playbooks use YAML to describe hosts plus tasks. This play runs entirely on the RHEL control node.

Use your terminal editor to open the empty 01_local_check.yml file inside the current veeam-lab-check directory.
Paste the following playbook into the file:

---
- name: Check the local RHEL Ansible environment
  hosts: localhost
  connection: local
  gather_facts: true

  tasks:
    - name: Show the local environment
      ansible.builtin.debug:
        msg:
          - "Ansible version: {{ ansible_version.full }}"
          - "Operating system: {{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_version'] }}"
          - "Python version: {{ ansible_facts['python_version'] }}"

What Does This Playbook Do?

The play targets the control node through localhost.
The local connection keeps execution on the machine where you run the command.
Fact gathering reads the operating system plus runtime details from the control node.
The ansible.builtin.debug task turns those facts into readable output.

Save 01_local_check.yml.

Check the playbook syntax

A syntax check validates the playbook structure before task execution. This gives you a quick way to catch formatting problems.

Check 01_local_check.yml by running this command:

ansible-playbook --syntax-check 01_local_check.yml

What Does This Command Check?

The --syntax-check flag asks ansible-playbook to parse the saved playbook without executing its tasks. It catches YAML structure problems before the full run.

A clean command result means Ansible accepted the playbook syntax. Your local check is ready to execute.

Seeing a Syntax Problem?

Compare the indentation in your file with the full code below.
Check that each output message keeps its surrounding double quotes.
Help me diagnose my local Ansible playbook syntax problem.

Run the local validation

A valid file can now be executed against the control node. Execution proves that local fact gathering plus debug output work together.

Before you run it, which three runtime details do you expect the control node to report?

Execute the local validation playbook by running this command:

ansible-playbook 01_local_check.yml

What Should You See?

The Ansible line reports the active playbook runtime.
The operating system line reports the RHEL distribution plus its version.
The Python line reports the interpreter version discovered during fact gathering.

That's your first local validation working. The RHEL control node can now execute a playbook plus report its own environment.

Missing Runtime Details?

Confirm that your saved file matches the full code below.
Check that the play reaches the task named Show the local environment.
Help me troubleshoot my missing Ansible runtime output.

✔️ Awesome, I've got everything!

Your local playbook now gathers facts from the RHEL control node. Its task prints all three runtime details.

ⓧ I'd like to double check the full code

Compare your saved 01_local_check.yml file with this complete version:

---
- name: Check the local RHEL Ansible environment
  hosts: localhost
  connection: local
  gather_facts: true

  tasks:
    - name: Show the local environment
      ansible.builtin.debug:
        msg:
          - "Ansible version: {{ ansible_version.full }}"
          - "Operating system: {{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_version'] }}"
          - "Python version: {{ ansible_facts['python_version'] }}"

What Should Match?

The full file contains one local play. Its single task prints the Ansible runtime plus the gathered operating system and Python details.

Your local validation loop is ready. Next, you'll reuse it for a read-only Veeam Backup & Replication network check.

Test One Veeam Connection

Your first local playbook confirmed that Ansible can execute on the Red Hat Enterprise Linux control node. Now you need evidence that this node can reach Veeam Backup & Replication.

A read-only TCP check gives you that first network signal. The playbook preserves either outcome for a readable report.

In this step, get ready to:

Store the Veeam hostname or IP in vars.yml.
Build a local playbook for a read-only TCP 443 check.
Run the playbook to interpret its network result.

Record the Veeam target

A variables file keeps lab-specific values separate from your playbook logic. You can reuse the same target without typing it into every check.

Use your terminal editor to edit vars.yml inside the veeam-lab-check working directory.
Add the reusable lab values by pasting this template:

---
veeam_host: "replace-with-veeam-hostname-or-ip"
vcenter_host: "replace-with-vcenter-hostname-or-ip"
veeam_version: "unknown"
veeam_api_access_confirmed: false

What Do These Variables Control?

The veeam_host value identifies the Veeam server that this step checks.
The vcenter_host value keeps its template text until the later readiness report uses VMware vCenter Server.
The veeam_version value stays unknown until an administrator confirms the installed version.
The veeam_api_access_confirmed value stays false until an administrator approves REST API access.

Replace replace-with-veeam-hostname-or-ip with your Veeam hostname or IP.
Keep the remaining three values unchanged.
Save vars.yml.
Confirm that the first line contains your Veeam target.

Missing the Veeam Target?

Ask the Veeam administrator for the exact backup server hostname or IP. Keep the template value in place until the target is confirmed.

If you have a target but are unsure about its format, help me check my Veeam hostname or IP value.

Build the TCP check

The ansible.builtin.wait_for module can test whether a host accepts a connection on a specific port. Registering the result lets later tasks choose a matching report message.

Use your terminal editor to edit 02_single_port_check.yml inside veeam-lab-check.
Add the local play and its first port check by pasting this code:

---
- name: Test one Veeam connection
  hosts: localhost
  connection: local
  gather_facts: false
  vars_files:
    - vars.yml

  tasks:
    - name: Check Veeam TCP 443
      ansible.builtin.wait_for:
        host: "{{ veeam_host }}"
        port: 443
        state: started
        connect_timeout: 3
        timeout: 5
      register: veeam_443
      ignore_errors: true

What Does This Check Do?

The play targets localhost because the check runs from your RHEL control node.
The vars_files section loads your Veeam target from vars.yml.
The state: started setting checks whether TCP port 443 accepts a connection.
The veeam_443 result stores the outcome for the report tasks.
The ignore_errors: true setting keeps the play running after a failed connection.

Save 02_single_port_check.yml.

Before you run this check, do you expect the RHEL control node to connect to TCP port 443?

A blocked connection can use the full five-second timeout. That brief pause is expected.

Run the initial connection check with this command:

ansible-playbook 02_single_port_check.yml

What Does This First Run Show?

The play recap confirms that Ansible executed the port-check task. A failed connection remains contained because the play is allowed to continue.

You will see the port-check task finish. The terminal does not yet translate the stored outcome into a plain-language result.

Connection Check Cannot Start?

Check that veeam_host no longer contains the template value.
Check the indentation beneath ansible.builtin.wait_for.
Ask for targeted help with my first Veeam TCP check.

Run the connection report

The registered result can select a message for a successful connection. This turns the raw task outcome into a result you can share.

Place the reachable report task below ignore_errors: true in 02_single_port_check.yml by pasting this code:

    - name: Report reachable Veeam TCP 443
      ansible.builtin.debug:
        msg:
          - "Veeam TCP 443 is reachable."
          - "This proves network reachability only. It does not identify the Veeam version or prove REST API authentication."
      when: veeam_443 is succeeded

How Does the Reachable Branch Work?

The when: veeam_443 is succeeded condition runs this task only after a successful connection. Its second message defines the boundary of the evidence.

Save 02_single_port_check.yml.
Test the reachable branch by running the playbook again:

ansible-playbook 02_single_port_check.yml

What Does This Run Report?

A successful connection prints Veeam TCP 443 is reachable. A failed connection skips this branch because its condition is false.

Reachable Message Missing?

A missing reachable message can mean the connection failed. It can also mean the when line is indented outside the report task.

Use the task result to help me diagnose the reachable report branch.

A failed connection needs its own branch. This keeps the report readable for either network outcome.

Place the unreachable report task below the reachable report task by pasting this code:

    - name: Report unreachable Veeam TCP 443
      ansible.builtin.debug:
        msg:
          - "Veeam TCP 443 is not reachable."
          - "This could mean the hostname, route, firewall, service, port, or product version needs checking."
      when: veeam_443 is failed

How Does the Failed Branch Work?

The when: veeam_443 is failed condition selects the failed-result message. The possible causes remain separate from any claim about API access.

Save 02_single_port_check.yml.

Before you run the finished report, which result branch do you think your current network path will select?

Run the finished single-port report with this command:

ansible-playbook 02_single_port_check.yml

What Does the Final Run Show?

A successful connection prints Veeam TCP 443 is reachable. It also prints the network-only warning.

A failed connection prints Veeam TCP 443 is not reachable. It also lists network details that may need checking.

The deliberate shortfall is now visible. The result gives evidence about one TCP path.

The Veeam version remains unverified. REST API authentication also remains unverified.

Good work. Your checker now turns either network outcome into a readable result.

No Report Message Appears?

Check that both report tasks remain inside the play's tasks section.
Check that each when condition aligns with its ansible.builtin.debug task.
Ask for help with my missing Veeam result message.

✔️ Awesome, I've got everything!

Save vars.yml.
Save 02_single_port_check.yml.
Keep your confirmed Veeam target in place of the template value.

ⓧ I'd like to double check the full code

Compare both files with the references below. Keep your confirmed Veeam target in place of the template value in vars.yml.

---
veeam_host: "replace-with-veeam-hostname-or-ip"
vcenter_host: "replace-with-vcenter-hostname-or-ip"
veeam_version: "unknown"
veeam_api_access_confirmed: false

How to Compare vars.yml

Confirm that all four keys are present. Your veeam_host value contains the target supplied for your lab.

---
- name: Test one Veeam connection
  hosts: localhost
  connection: local
  gather_facts: false
  vars_files:
    - vars.yml

  tasks:
    - name: Check Veeam TCP 443
      ansible.builtin.wait_for:
        host: "{{ veeam_host }}"
        port: 443
        state: started
        connect_timeout: 3
        timeout: 5
      register: veeam_443
      ignore_errors: true

    - name: Report reachable Veeam TCP 443
      ansible.builtin.debug:
        msg:
          - "Veeam TCP 443 is reachable."
          - "This proves network reachability only. It does not identify the Veeam version or prove REST API authentication."
      when: veeam_443 is succeeded

    - name: Report unreachable Veeam TCP 443
      ansible.builtin.debug:
        msg:
          - "Veeam TCP 443 is not reachable."
          - "This could mean the hostname, route, firewall, service, port, or product version needs checking."
      when: veeam_443 is failed

How to Compare the Playbook

Confirm that the port check registers veeam_443. Confirm that the two report tasks use opposite result conditions.

Your single-port checker now reports the first network signal from RHEL. Next, you will expand that evidence into a read-only readiness report for both lab platforms.

Build a Lab Readiness Report

Your first Ansible connection check gave the RHEL control node an early network signal for Veeam Backup & Replication. That single port still cannot identify the product version or prove REST API access.

This step expands the evidence with both documented Veeam candidate ports plus VMware vCenter Server. The finished report keeps every check read-only while showing which details still need administrator confirmation.

In this step, get ready to:

Add the vCenter hostname or IP to the shared variables file.
Check two Veeam ports plus one vCenter port without changing either platform.
Capture a readiness report for the Veeam administrator.

Update the shared lab details

The readiness report loads its hostnames from vars.yml. Keeping those values in one file lets every playbook use the same lab details.

Switch back to vars.yml in your editor.
Replace replace-with-vcenter-hostname-or-ip with your vCenter hostname or IP.
Keep veeam_version set to unknown until an administrator confirms the exact version or build.
Keep veeam_api_access_confirmed set to false until a read-only REST API account is approved.
Save vars.yml.

Why keep unconfirmed values visible?

The values unknown and false turn missing information into part of the report. They prevent network reachability from being mistaken for full API readiness.

Add the read-only network checks

Each ansible.builtin.wait_for task attempts a TCP connection from the RHEL control node. The registered result lets later tasks describe the outcome without stopping the playbook when a port is closed.

Use your existing editor to open the empty 03_lab_readiness.yml file inside veeam-lab-check.
Add the play header plus the first Veeam check by pasting this code:

---
- name: Build a Veeam and vCenter readiness report
  hosts: localhost
  connection: local
  gather_facts: false
  vars_files:
    - vars.yml

  tasks:
    - name: Check Veeam TCP 443
      ansible.builtin.wait_for:
        host: "{{ veeam_host }}"
        port: 443
        state: started
        connect_timeout: 3
        timeout: 5
      register: veeam_443
      ignore_errors: true

What does this code do?

The play runs locally without gathering system facts because this report only needs shared variables plus network results.
The first task checks TCP port 443 on veeam_host.
The veeam_443 result records whether the connection succeeded.
The ignore_errors: true setting keeps the report running after a failed check.

Save 03_lab_readiness.yml.
Return to the terminal from earlier.
Run the first version of the report by running this command:

ansible-playbook 03_lab_readiness.yml

What should I see?

The task output shows that Ansible attempted the Veeam TCP 443 check. A closed port can use the full five-second timeout before the play continues.

Does the playbook stop before the check?

Check that the YAML uses spaces for indentation.
Confirm that vars.yml remains inside the veeam-lab-check folder.
Use help me troubleshoot the first readiness check.

Switch back to 03_lab_readiness.yml in your editor.
Add the second Veeam check below the first task:

    - name: Check Veeam TCP 9419
      ansible.builtin.wait_for:
        host: "{{ veeam_host }}"
        port: 9419
        state: started
        connect_timeout: 3
        timeout: 5
      register: veeam_9419
      ignore_errors: true

What does the second check add?

This task checks Veeam TCP port 9419 with the same timeout behavior. Its result is stored separately as veeam_9419.

Save 03_lab_readiness.yml.
Return to the terminal from earlier.
Press the Up Arrow to recall the report command.
Press Enter to rerun it.

You now see separate task results for Veeam TCP 443 plus TCP 9419.

Does the second task fail to load?

Confirm that the new task aligns with the first - name: line.
Check that register: veeam_9419 sits outside the module parameter block.
Use help me fix the Veeam TCP 9419 task.

Switch back to 03_lab_readiness.yml in your editor.
Add the vCenter check below the Check Veeam TCP 9419 task:

    - name: Check vCenter TCP 443
      ansible.builtin.wait_for:
        host: "{{ vcenter_host }}"
        port: 443
        state: started
        connect_timeout: 3
        timeout: 5
      register: vcenter_443
      ignore_errors: true

What does the vCenter check add?

This task applies the same read-only TCP test to vcenter_host on port 443. The vcenter_443 result remains independent from both Veeam results.

Save 03_lab_readiness.yml.
Return to the terminal from earlier.
Press the Up Arrow to recall the report command.
Press Enter to rerun it.

Ansible now attempts all three connections. A failed connection remains visible while the play continues to the next host or port.

Does the vCenter check use the placeholder?

Return to vars.yml.
Confirm that vcenter_host contains your lab hostname or IP.
Use help me check my vCenter variable.

Report and capture the readiness results

The registered results now hold the raw connection outcomes. Conditional debug tasks convert them into one plain-language status for each port.

Switch back to 03_lab_readiness.yml in your editor.
Add the Veeam TCP 443 status tasks below the vCenter check:

    - name: Report reachable Veeam TCP 443
      ansible.builtin.debug:
        msg: "Veeam TCP 443: REACHABLE"
      when: veeam_443 is succeeded

    - name: Report unreachable Veeam TCP 443
      ansible.builtin.debug:
        msg: "Veeam TCP 443: NOT REACHABLE"
      when: veeam_443 is failed

How does the status branch work?

The two conditions inspect veeam_443. Only the message matching the registered outcome runs.

Save 03_lab_readiness.yml.
Return to the terminal from earlier.
Press the Up Arrow to recall the report command.
Press Enter to rerun it.

You see either Veeam TCP 443: REACHABLE or Veeam TCP 443: NOT REACHABLE.

Missing the Veeam TCP 443 status?

Confirm that both conditions use veeam_443.
Check that one condition says is succeeded while the other says is failed.
Use help me fix the Veeam TCP 443 status tasks.

Switch back to 03_lab_readiness.yml in your editor.
Add the Veeam TCP 9419 status tasks below the TCP 443 status tasks:

    - name: Report reachable Veeam TCP 9419
      ansible.builtin.debug:
        msg: "Veeam TCP 9419: REACHABLE"
      when: veeam_9419 is succeeded

    - name: Report unreachable Veeam TCP 9419
      ansible.builtin.debug:
        msg: "Veeam TCP 9419: NOT REACHABLE"
      when: veeam_9419 is failed

What does this status pair report?

These conditions inspect veeam_9419. They produce one clear status for the second Veeam candidate port.

Save 03_lab_readiness.yml.
Return to the terminal from earlier.
Press the Up Arrow to recall the report command.
Press Enter to rerun it.

The report now prints a separate REACHABLE or NOT REACHABLE result for each Veeam candidate port.

Missing the Veeam TCP 9419 status?

Confirm that both new conditions use veeam_9419.
Check that the messages contain TCP 9419.
Use help me fix the Veeam TCP 9419 status tasks.

Switch back to 03_lab_readiness.yml in your editor.
Add the vCenter status tasks below the Veeam status tasks:

    - name: Report reachable vCenter TCP 443
      ansible.builtin.debug:
        msg: "vCenter TCP 443: REACHABLE"
      when: vcenter_443 is succeeded

    - name: Report unreachable vCenter TCP 443
      ansible.builtin.debug:
        msg: "vCenter TCP 443: NOT REACHABLE"
      when: vcenter_443 is failed

How is the vCenter result selected?

The conditions inspect vcenter_443. Exactly one vCenter status message runs after the connection task.

Save 03_lab_readiness.yml.
Return to the terminal from earlier.
Press the Up Arrow to recall the report command.
Press Enter to rerun it.

You now see a network status for both Veeam candidate ports plus vCenter TCP 443.

Missing the vCenter status?

Confirm that both conditions use vcenter_443.
Check that the registered result in the connection task uses the same identifier.
Use help me fix the vCenter status tasks.

Switch back to 03_lab_readiness.yml in your editor.
Add the remaining readiness checklist below the vCenter status tasks:

    - name: Show the remaining readiness checklist
      ansible.builtin.debug:
        msg:
          - "Recorded Veeam version: {{ veeam_version }}"
          - "REST API access approved: {{ veeam_api_access_confirmed }}"
          - "A reachable TCP port proves network access only. It does not prove API authentication."
          - "Next: confirm the exact Veeam version/build, server hostname, and read-only API access with the Veeam administrator."

What does the checklist prove?

The final task prints the recorded version plus the API approval flag. It also preserves the boundary between TCP reachability and authenticated API access.

This gives the administrator a focused list of missing details. The report remains safe because it never authenticates or changes remote configuration.

Save 03_lab_readiness.yml.
Return to the terminal from earlier.

Before you rerun it, ask yourself which of the three checks will report a reachable state.

Press the Up Arrow to recall the report command.
Press Enter to run the complete readiness report.

You see one status for Veeam TCP 443. You also see one status for Veeam TCP 9419 plus one status for vCenter TCP 443.

The checklist also prints the current values of veeam_version plus veeam_api_access_confirmed.

Take a screenshot of the terminal showing the complete report.
Ask the Veeam administrator for the exact Veeam Backup & Replication version or build.
Ask the Veeam administrator to confirm the backup server hostname.
Ask the Veeam administrator to approve a read-only REST API account.

That completes the read-only lab report. You now have concrete network evidence plus a checklist for the details that TCP checks cannot establish.

Does the complete report stop early?

Confirm that every network task includes ignore_errors: true.
Check that each debug condition matches its registered variable.
Use help me troubleshoot the complete readiness report.

✔️ Awesome, I've got everything!

Your 03_lab_readiness.yml file is saved. Your terminal report now covers both Veeam candidate ports plus vCenter TCP 443.

ⓧ I'd like to double check the full code

Compare your complete 03_lab_readiness.yml file with this reference.

---
- name: Build a Veeam and vCenter readiness report
  hosts: localhost
  connection: local
  gather_facts: false
  vars_files:
    - vars.yml

  tasks:
    - name: Check Veeam TCP 443
      ansible.builtin.wait_for:
        host: "{{ veeam_host }}"
        port: 443
        state: started
        connect_timeout: 3
        timeout: 5
      register: veeam_443
      ignore_errors: true

    - name: Check Veeam TCP 9419
      ansible.builtin.wait_for:
        host: "{{ veeam_host }}"
        port: 9419
        state: started
        connect_timeout: 3
        timeout: 5
      register: veeam_9419
      ignore_errors: true

    - name: Check vCenter TCP 443
      ansible.builtin.wait_for:
        host: "{{ vcenter_host }}"
        port: 443
        state: started
        connect_timeout: 3
        timeout: 5
      register: vcenter_443
      ignore_errors: true

    - name: Report reachable Veeam TCP 443
      ansible.builtin.debug:
        msg: "Veeam TCP 443: REACHABLE"
      when: veeam_443 is succeeded

    - name: Report unreachable Veeam TCP 443
      ansible.builtin.debug:
        msg: "Veeam TCP 443: NOT REACHABLE"
      when: veeam_443 is failed

    - name: Report reachable Veeam TCP 9419
      ansible.builtin.debug:
        msg: "Veeam TCP 9419: REACHABLE"
      when: veeam_9419 is succeeded

    - name: Report unreachable Veeam TCP 9419
      ansible.builtin.debug:
        msg: "Veeam TCP 9419: NOT REACHABLE"
      when: veeam_9419 is failed

    - name: Report reachable vCenter TCP 443
      ansible.builtin.debug:
        msg: "vCenter TCP 443: REACHABLE"
      when: vcenter_443 is succeeded

    - name: Report unreachable vCenter TCP 443
      ansible.builtin.debug:
        msg: "vCenter TCP 443: NOT REACHABLE"
      when: vcenter_443 is failed

    - name: Show the remaining readiness checklist
      ansible.builtin.debug:
        msg:
          - "Recorded Veeam version: {{ veeam_version }}"
          - "REST API access approved: {{ veeam_api_access_confirmed }}"
          - "A reachable TCP port proves network access only. It does not prove API authentication."
          - "Next: confirm the exact Veeam version/build, server hostname, and read-only API access with the Veeam administrator."

Secret mission

Secret Mission: Turn Missing Veeam Access into a Clear Failure

Make your read-only Veeam checks act as a network gate. The playbook stops clearly when neither candidate port can be reached from RHEL.

Clean Up Your Resources

Everything you created is local to the RHEL control node. There are no ongoing costs.

The playbooks made no remote changes. Choose whether to keep the files, pause your work, or delete the folder.

Resources you used:

Your vars.yml file with the reusable lab values.
Your 01_local_check.yml local Ansible environment playbook.
Your 02_single_port_check.yml single-port Veeam check.
Your 03_lab_readiness.yml readiness report.
Your 04_require_veeam.yml Veeam network gate.

Keep everything running

No action is needed. Choose this option if you want to retain the validation kit as evidence or use it again.

Keep the five project files inside the veeam-lab-check folder.
Reuse 03_lab_readiness.yml after the administrator confirms the missing lab details.
Reuse 04_require_veeam.yml when you need a clear network gate before later automation.

Pause - I'll come back to this later

Each playbook exits after its run, so there is no Ansible process to stop. Your files can remain on disk until the missing information is available.

Leave the veeam-lab-check folder on the RHEL control node.
Update veeam_version after the administrator confirms the exact version and build.
Update veeam_api_access_confirmed after read-only API access is approved.

Delete - I don't want to use this again

Deleting the folder permanently removes all five local files. The read-only checks created nothing in Veeam, vCenter, or Satellite.

Remove the veeam-lab-check folder from the RHEL control node by running these commands:

cd ..
rm -rf veeam-lab-check
ls

What Do These Commands Do?

The first line moves your terminal to the directory above the project folder.
The second line permanently removes the veeam-lab-check folder and every file inside it.
The final line displays the remaining files and folders so you can verify the cleanup.

You should no longer see veeam-lab-check in the directory listing. That confirms all five local files are gone.

Folder Still Listed?

Confirm your terminal is connected to the RHEL control node that contains the project.
Check that your account has permission to remove the project folder.
Help me remove the local project folder safely.

Nice Work!

Excellent work! Your read-only Ansible validation kit now gives you evidence for safer automation across your lab.

You've learned how to:

Built a local environment playbook that uses gathered facts to report the Ansible runtime. The same run reports the RHEL version. It also shows the Python runtime.
Created reusable host variables for Veeam Backup & Replication. Added a matching variable for VMware vCenter Server. Used read-only TCP checks on candidate port 443. Checked the alternate candidate port 9419. Checked the vCenter network path on port 443.
Produced a readiness checklist for the exact Veeam version/build. Recorded the confirmed backup server hostname. Captured approval for read-only REST API access. Distinguished network reachability from authenticated API readiness.
Secret Mission: Added an assertion gate that succeeds when either Veeam candidate port is reachable. The playbook now stops with a clear failure when both checks fail.

Ready to quiz yourself?