Build a vSphere VM and VLAN Inventory

Create an evidence-backed vSphere VM inventory and trace VLANs to uplinks.

Introduction

30 Second Summary

A crowded toy box is difficult to explain when every piece has a name but no label for what it does or where it belongs. A virtual lab creates the same confusion when its machines and network paths live only in someone's memory.

In this project, you will build an evidence-backed VM inventory in Microsoft Excel from observations gathered in the vSphere Client. You will trace VLAN 214 and VLAN 215 from representative virtual machines to the physical-network boundary.

What You'll Build

Your final demo gives another administrator a clear path through vSphere-Toy-Box-Inventory.xlsx, from any VM's guest identity and server role to its distributed port group, VLAN, vSphere Distributed Switch, and shared physical vmnic.

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

A saved inventory you can filter to find missing guest identity, VMware Tools telemetry, role evidence, clone history, or confidence.
A role classification you can defend for each machine, covering Red Hat Identity Management, Red Hat Satellite, OpenShift-style control-plane nodes, worker nodes, other roles, or unknown machines.
A traceable VLAN explanation showing how VLAN 214 and VLAN 215 use Virtual Switch Tagging to reach one physical vmnic, with the upstream trunk marked for external verification.
Secret Mission: Defend one ambiguous VM record end to end using multiple vSphere views, a confidence level, and a named owner for the unresolved evidence gap.

Are there any prerequisites?

You need a Windows device with Microsoft Excel plus administrator access to a reachable vCenter Server 8.0 Update 3 or later environment containing the test VMs and a vSphere Distributed Switch carrying VLAN 214 and VLAN 215. Guest operating system credentials and physical-switch access are not required.

Before We Start

Before you inspect the lab, commit to building an evidence-backed inventory for a specific administrator and question. This keeps familiar VM names or IP patterns from becoming proof without supporting observations.

Set Up Your Read-Only Workspace

Evidence is easier to trust when every observation lands in a controlled workspace. That workspace also helps you avoid accidental changes in vCenter Server.

The vSphere Client gives you the lab view. Microsoft Excel gives each observation a consistent place to land.

In this step, get ready to:

Confirm a supported Microsoft Edge version is ready.
Establish a view-only vSphere Client session.
Create the saved inventory workbook.

Get Microsoft Edge ready

The vSphere Client supports Microsoft Edge version 90 or later. Checking the browser first removes a compatibility problem before you reach the sign-in page.

Press the Windows key to open Windows search.
Type Microsoft Edge into the search field.
Choose the not-installed tab below if Microsoft Edge does not appear.
Select Microsoft Edge from the search results if it appears.
Select Settings and more in the upper-right corner if Edge opens.
Select Help and feedback.
Select About Microsoft Edge.
Choose the tab below that matches the result on the About page.

✔️ Edge meets the requirement

You should see a major version of 90 or higher. Your browser clears the compatibility check for the vSphere Client.

Keep Microsoft Edge open for the vCenter sign-in.

ⓧ I see an older version

The About page checks for available updates. Updating Edge gives the vSphere Client a supported browser.

Select Download and install if that option appears.
Select Restart when Edge prompts you.
Return to About Microsoft Edge after the restart.

You should now see a major version of 90 or higher.

Keep Microsoft Edge open for the vCenter sign-in.

ⓧ Microsoft Edge is not installed

The installer may ask Windows for permission to make changes. This is expected during a browser installation.

Use another available browser to visit the official Microsoft Edge download page.
Select Download Edge for Windows.
Run the downloaded installer.
Follow the on-screen installation instructions.
Press the Windows key after installation.
Type Microsoft Edge into the search field.
Press Enter to open Edge.
Enter edge://settings/help in the address bar.

You should see a major version of 90 or higher. Keep Edge open for the vCenter sign-in.

Having trouble with Microsoft Edge?

If the update options are unavailable, your organization may manage browser updates. Ask your device administrator to update Edge.

If installation fails, confirm that the installer finished downloading before you run it.

Get help with installing or updating Microsoft Edge.

Sign in without changing vCenter

The vSphere Client connects you to the inventory managed by vCenter Server. Your administrator account can also alter that inventory.

Keep this session view-only

Use your administrator access only to view or export information during this project. Close every configuration dialog without applying changes.

Enter your vCenter address in this format in the Edge address bar: https://vcenter_server_ip_address_or_fqdn/ui.
Select Launch vSphere Client (HTML5) if the vSphere Welcome page appears.
Enter your confirmed vCenter administrator username in the sign-in form.
Enter your vCenter administrator password.
Select Login.
Confirm that the vSphere Client home page loads.

You now have a working vSphere Client session. The lab remains unchanged because this project uses the interface only for observation.

Unable to reach the vSphere Client?

Confirm that the address contains your real vCenter hostname or IP address. Keep the /ui path at the end.

If the page loads but sign-in fails, confirm that you are using the provided vCenter administrator account.

Get help with diagnosing my vSphere Client sign-in problem.

Build the evidence workbook

One workbook keeps VM facts separate from network paths. A third sheet gives uncertain evidence a dedicated home.

Press the Windows key to open Windows search.
Type Excel into the search field.
Press Enter to open Excel.
Select Blank workbook.
Select File.
Select Save As.
Select Browse.
Choose a local folder where you can find the inventory later.

The save dialog now points to the local folder that holds your evidence workbook.

Enter vSphere-Toy-Box-Inventory.xlsx in the File name field.
Confirm that Save as type shows Excel Workbook (.xlsx).
Select Save.

The workbook name should now appear in the Excel title bar. Your evidence has a saved local destination.

Double-click the first sheet tab.
Type VM Inventory as its name.

You should see VM Inventory on the first sheet tab.

Select the New Sheet plus icon at the bottom of the workbook.
Double-click the new sheet tab.

The new sheet name is ready for editing.

Type Network Map as the second sheet name.

You should now see a second tab named Network Map.

Select the New Sheet plus icon again.
Double-click the new sheet tab.

The third sheet name is ready for editing.

Type Evidence Notes as the third sheet name.

The workbook should now show the three required sheet tabs. Keep Network Map plus Evidence Notes blank for later observations.

The inventory headers create a fixed destination for each kind of VM evidence. They also preserve uncertainty through dedicated notes plus confidence fields.

Select cell A1 in the VM Inventory sheet.
Fill the first row by pasting the tab-separated headers below:

VM Name	Guest Hostname	IP Address	Guest OS	Power State	VMware Tools	ESXi Host	Network Adapter	Distributed Port Group	VLAN	Server Role	Clone Evidence	Task/Event Notes	Confidence

What does this header row do?

The tab separators place each label in a separate Excel column when you paste the row into A1. Every VM gets one consistent path from identity evidence to network evidence.

The final columns preserve role reasoning, historical clues, activity notes, plus confidence. Empty evidence stays visible as an investigation gap.

Press Ctrl+S to save vSphere-Toy-Box-Inventory.xlsx.
Confirm that the first row of VM Inventory contains all fourteen headers.
Confirm that Network Map remains blank.
Confirm that Evidence Notes remains blank.

Did the headers stay in one cell?

Undo the paste if the complete row appears inside one cell. Copy the full tab-separated line again before pasting it into A1.

If a sheet name differs, double-click its tab to rename it with the exact spelling shown above.

Get help with fixing my Excel inventory workbook.

Before you arrange the windows, what should a safe starting workspace show without any vCenter configuration changes?

Drag the Microsoft Edge window to the left edge of the screen until it snaps into place.
Select Excel from the available window choices on the right.
Select the VM Inventory sheet.

You should see the vSphere Client home page in Edge. Beside it, Excel should show the saved vSphere-Toy-Box-Inventory.xlsx workbook with all three sheet tabs.

The first row of VM Inventory should contain the fourteen evidence headers. The other two sheets should remain blank.

Your controlled workspace is ready for evidence collection. Next up, you will export the visible VM list to expose what the baseline includes plus what still needs investigation.

Export the First VM Inventory

Your read-only vSphere Client session is ready. Your saved Excel workbook is waiting beside it.

A useful VM inventory starts with one row for every visible VM. The global object list gives you that baseline quickly.

However, a CSV cannot prove why each server exists. It also cannot trace a VLAN path to a physical uplink.

In this step, get ready to:

Export the visible virtual-machine object list as a CSV.
Transfer the exported values into your saved inventory workbook.
Mark unsupported identity, role, clone, and network fields as investigation gaps.

Export the virtual machine list

Global Inventory Lists gathers objects from across the environment into one table. You can export the visible VM list without changing any VM configuration.

Return to the vSphere Client from earlier.
Click Menu in the top navigation area.
Select Global Inventory Lists.
Select the object category that lists the virtual machines.
Click Manage Columns.
Review the available fields under Show Columns.
Retain the useful available fields for the visible VMs.
Return to the virtual-machine object list.

Before you export, do you think this list can explain each VM's server role or full network path? Keep your prediction in mind.

Click Export.
Download the generated CSV to your Windows Downloads folder.

You should see the generated CSV in your downloads. That file is your source snapshot of the virtual machines visible in the object list.

What Does Export Create?

The export captures the rows and available columns from the object list. It gives you a repeatable starting point without changing any inventory object.

The downloaded file remains separate from your saved workbook. You will copy its evidence into the existing VM Inventory sheet.

CSV Missing From Your Downloads?

Return to the virtual-machine object list and confirm that VM rows are visible.
Click Export again.
Check whether Microsoft Edge blocked or redirected the download.

If the file still does not appear, help me troubleshoot the missing vSphere inventory export.

Build the CSV-backed baseline

Excel opens CSV data in a separate workbook so you can compare it with your saved inventory. Your original workbook remains the destination for the baseline.

Return to Excel from earlier.
Click File.
Click Open.
Select the downloaded CSV from your Windows Downloads folder.

Excel displays the CSV data in a separate workbook. You should see one data row for each VM included in the export.

Before you transfer the data, which workbook columns do you expect the CSV to leave unresolved? Keep your prediction in mind.

Select the exported values under the first CSV column that matches a header in your saved workbook.
Copy the selected values.
Return to vSphere-Toy-Box-Inventory.xlsx.
Select the VM Inventory sheet.
Paste the values beneath the matching header.
Repeat this transfer for every exported column that matches a workbook header.
Keep every exported value exactly as it appears in the CSV.
Save vSphere-Toy-Box-Inventory.xlsx.

You now have your first evidence-backed win: every visible VM has a row built from the exported source. The imported values should match the CSV exactly.

Why Preserve the Exported Values?

The CSV records what the vSphere Client reported at export time. Preserving those values keeps your baseline traceable to its source.

Later observations can fill the investigative columns. They should never silently rewrite the original evidence.

Row Counts Do Not Match?

Check that the CSV header was not pasted as a VM data row.
Confirm that no VM row was skipped during the transfer.
Remove any duplicate row created by an accidental second paste.

If the counts still differ, help me reconcile my CSV and VM Inventory row counts.

Mark the investigation gaps

Blank investigative cells show where the object list lacks enough evidence. Highlighting those blanks keeps the baseline honest.

Before you compare the headers, can the CSV prove each VM's identity, role, clone history, or VLAN path? Keep your prediction in mind.

Compare the exported columns with every header in the VM Inventory sheet.
Leave every unsupported investigative value blank.
Apply a light yellow fill to each unsupported blank cell.
Save vSphere-Toy-Box-Inventory.xlsx.

You should see unresolved cells under headers such as Guest Hostname, IP Address, Server Role, Clone Evidence, Distributed Port Group, VLAN, Task/Event Notes, and Confidence.

Why Is the Baseline Incomplete?

The CSV proves which VMs were visible. It also preserves the fields available in the object list.

Guest identity remains unresolved when the export lacks reported guest data. An absent IP address remains an evidence gap.

Server roles need supporting observations. Clone provenance needs retained activity or administrative evidence.

The VLAN path requires additional vSphere views. This is the intended shortfall of the CSV baseline.

Before the final check, do you expect the workbook row count to match the CSV exactly? Keep your prediction in mind.

Count the VM data rows in the downloaded CSV.
Count the populated VM Name cells in vSphere-Toy-Box-Inventory.xlsx.
Compare the two counts.
Confirm that unsupported investigative cells remain visibly blank with light yellow fill.

The two counts should match. Your VM Inventory sheet should contain one CSV-backed row for every visible VM.

You have a trustworthy baseline now. Its visible gaps show exactly where further evidence is still required.

Your exported baseline now accounts for every visible VM without turning missing evidence into guesses. Next up, you will inspect each VM's reported identity, classify its role, and interpret its retained activity.

Identify Every VM and Interpret Its History

Your exported CSV now gives every visible VM a row in Microsoft Excel. Those rows still cannot tell another administrator who each guest is or what job it performs.

Names can suggest a role or clone history. In this step, you will replace those guesses with observations from the vSphere Client. Retained activity provides the history behind each confidence decision.

In this step, get ready to:

Record guest identity and runtime evidence for every visible VM.
Assign an evidence-based server role with a confidence level.
Assess clone history from retained activity.

Record reported identity and telemetry

The exported VM Name identifies the inventory object. The Guest Hostname records the identity reported by the guest telemetry.

Why can guest details be missing?

The vCenter Server relies on VMware Tools telemetry for guest IP information. A stopped Tools service or an unresponsive guest can leave Virtual Machine Details incomplete.

The VM power state can also limit the evidence available to you. Recording the limitation keeps a missing value from becoming a guess.

Switch back to the vSphere Client in Microsoft Edge.
Select the first VM whose workbook row has investigation gaps.
Open the Summary tab.
Find the Virtual Machine Details section.
Record the displayed hostname in Guest Hostname.
Record the displayed address in IP Address.
Record the displayed operating system in Guest OS.
Record the displayed power state in Power State.

Keep inventory identity separate

Preserve the exported VM Name even when the reported guest hostname differs. That difference can become useful evidence during troubleshooting.

Record the displayed Tools state in VMware Tools.
Record the displayed host in ESXi Host.
Enter Not reported in any field that has no displayed value.
Add a short explanation of the observed telemetry limitation in the same cell.
Repeat these observations for every VM row in VM Inventory.
Save vSphere-Toy-Box-Inventory.xlsx.
Confirm every row now separates VM Name from Guest Hostname.

Good progress. Every row now distinguishes the vCenter inventory name from guest-reported identity while preserving missing telemetry honestly.

Classify each server role

A role label becomes useful when another administrator can follow the evidence behind it. The confidence level records how strongly the available observations support that label.

What do these server roles mean?

Red Hat Identity Management provides centralized identity infrastructure. It supports authentication policy across managed systems.
Red Hat Satellite centralizes content lifecycle management. It also coordinates host management.
OpenShift-style control-plane nodes manage the cluster.
Worker nodes run the workloads requested by cluster users.
Use another role when observations support a different function. Use Unknown when the evidence is insufficient.

Return to the first row in the VM Inventory sheet.
Review its observed VM name for role clues.
Review its reported guest hostname for supporting evidence.
Review its reported guest OS for supporting evidence.
Enter the matching role name from the callout exactly as written in Server Role.
Enter Unknown when the evidence does not support a role.
Enter High, Medium, or Low in Confidence.
Add a short evidence basis to Task/Event Notes.

A familiar VM name provides weak evidence on its own. Guest identity plus supporting observations can justify stronger confidence.

Repeat the classification for every VM row.
Save vSphere-Toy-Box-Inventory.xlsx.
Filter Server Role for blank cells.
Filter Confidence for blank cells.

Your filters should return no blank role or confidence cells. Each VM now has an evidence-based classification or an explicit Unknown.

Inspect tasks, events, and clone evidence

A VM clone copies the source VM's virtual hardware and configured properties. Clone provenance comes from retained activity or other administrative evidence.

What can retained history prove?

vSphere tasks record activities on inventory objects. Events add details that can explain what happened around those activities.

Task and event retention is configurable. The default is 30 days, so older creation or clone activity may be absent.

A missing clone event leaves provenance unresolved. Record that uncertainty instead of upgrading a familiar naming pattern into proof.

Choose one representative VM in the workbook for a history sample.
Switch back to the vSphere Client.
Select the representative VM.
Click the Monitor tab.
Select Tasks and Events.
Open Tasks.
Choose one useful retained task.
Return to the matching workbook row.

Record the task target in Task/Event Notes.
Add the task status to the same note.
Add the task initiator to the same note.
Add the displayed task time to the same note.
Return to the VM's Monitor tab.
Open Events.
Expand a relevant event row.
Add its event detail to Task/Event Notes.

Your sampled VM now has a compact activity record containing target, status, initiator, time, and event detail.

Repeat the history inspection for every suspected clone.
Record retained task evidence in Clone Evidence when it supports clone provenance.
Record retained event evidence in Clone Evidence when it supports clone provenance.
Record available annotation or administrative evidence in Clone Evidence when it supports clone provenance.
Enter Suspected when a clone-like name lacks supporting evidence.
Enter Unknown wherever the available evidence cannot establish provenance.
Append Not sampled to Task/Event Notes for every VM outside the history sample.
Save vSphere-Toy-Box-Inventory.xlsx.

Before you filter the sheet, which gaps do you expect to remain because vCenter lacks telemetry or retained history?

Filter this step's completed investigative columns in VM Inventory for blank cells.

You should find no unexplained blanks in the identity, role, clone-evidence, history, or confidence columns. Unavailable observations should show Not reported, while unsupported provenance should remain Suspected or Unknown.

At least one sampled VM should include a task or event target, status, initiator, time, and detail. The network adapter, distributed port group, and VLAN gaps remain ready for the next investigation.

Still seeing unexplained blanks?

Return to the VM's Summary tab to confirm whether guest telemetry is available.
Use Not reported when the vSphere Client does not display an observed value.
Use Unknown when the available evidence cannot support a role or provenance decision.

Help me review an incomplete VM inventory row without guessing from the VM name.

Your evidence-backed inventory is ready. Next, you will trace both VLANs through the vSphere Distributed Switch to the shared physical uplink.

Trace VLANs to the Shared Uplink

Your VM inventory now separates observed identity from name-based guesses. A distributed port group name alone cannot explain where a VM's traffic leaves the host.

In this step, you will inspect representative VMs for VLAN 214 and VLAN 215 in the vSphere Client. You will trace both through a vSphere Distributed Switch to the shared physical NIC.

In this step, get ready to:

Inspect representative VM adapters for VLAN 214 and VLAN 215 without changing their settings.
Trace both adapters through the distributed-switch topology to the shared physical NIC.
Document the tagging method plus the physical-network verification boundary.

Inspect the representative VM adapters

Each representative VM shows the distributed port group selected for its virtual network adapter. Its connection settings capture whether that adapter is attached.

Opening Edit Settings can feel risky with administrator access. Closing the dialog with Cancel leaves the VM configuration unchanged.

Choose one powered-on VM to represent VLAN 214.
Open Edit Settings for the selected VM.
Expand Network adapter under Virtual Hardware.
Switch to the saved vSphere-Toy-Box-Inventory.xlsx workbook in Microsoft Excel.
Enter the adapter label plus the displayed Connected and Connect at power on states in the VM's Network Adapter cell.
Enter the selected port group in the VM's Distributed Port Group cell.
Switch back to the VM settings in the vSphere Client.
Click Cancel to close the settings without applying changes.

The VLAN 214 representative row now contains its observed adapter label, connection settings, and selected port group.

What does the adapter evidence prove?

The selected port group identifies where the VM adapter enters the distributed network. The topology still needs to prove the VLAN ID plus the physical uplink.

The Connected and Connect at power on settings preserve the adapter state you observed during the inspection.

Choose one powered-on VM to represent VLAN 215.
Open Edit Settings for the selected VM.
Expand Network adapter under Virtual Hardware.
Switch back to vSphere-Toy-Box-Inventory.xlsx.
Enter the adapter label plus the displayed connection settings in the VM's Network Adapter cell.
Enter the selected port group in the VM's Distributed Port Group cell.
Switch back to the VM settings in the vSphere Client.
Click Cancel to close the settings without applying changes.

That's the risky inspection done. Both representative rows now carry adapter evidence gathered without changing either VM.

Can't find the expected adapter details?

Confirm that you selected a powered-on representative VM from the correct lab environment.
Expand Network adapter inside Virtual Hardware to reveal the selected port group.
Choose another powered-on representative VM if the current VM has no usable network adapter evidence.

Help me identify why a representative VM is missing its network adapter or distributed port-group details.

Trace both paths through the topology

The distributed-switch topology connects the VM-facing port group to its VLAN policy. It also exposes the uplink plus the physical NIC carrying that adapter's traffic.

Return to the vSphere Client.
Navigate to the vSphere Distributed Switch that carries the two recorded port groups.
Select Configure.
Select Topology under Settings.
Locate the VLAN 214 representative adapter by matching its VM name plus its recorded port group.
Follow its displayed route from the distributed port group through the uplink to the physical NIC.
Switch to vSphere-Toy-Box-Inventory.xlsx.
Enter the first path in Network Map with the observed labels placed into VM vNIC > distributed port group > VLAN 214 or 215 > distributed switch uplink > shared vmnic > physical-switch trunk.

Your first network-map entry now reaches the physical NIC observed by the distributed-switch topology.

What does the topology prove?

The topology ties the representative VM adapter to its distributed port group. It also shows the port group's VLAN mode plus VLAN ID.

The route continues through the distributed switch uplink to a physical NIC. That physical NIC is the last component the virtual topology can directly establish.

Switch back to the distributed-switch topology.
Locate the VLAN 215 representative adapter by matching its VM name plus its recorded port group.
Follow its displayed route from the distributed port group through the uplink to the physical NIC.
Switch back to vSphere-Toy-Box-Inventory.xlsx.
Enter the second path in Network Map using the same required structure.
Enter the observed VLAN 214 evidence in the first representative VM's VLAN cell.
Enter the observed VLAN 215 evidence in the second representative VM's VLAN cell.
Compare the physical NIC endpoints recorded for the two paths.

You should see both paths reach the same observed physical vmnic. This shared endpoint connects both virtual paths to the physical-network boundary.

Don't see a shared vmnic?

Confirm that the distributed switch you opened carries both recorded port groups.
Match each topology adapter to the VM name plus the port group recorded in the workbook.
Verify the representative VM selections with the lab administrator if the routes end on different physical NICs.

Help me reconcile two vSphere topology paths that do not reach the expected shared physical NIC.

Document the tagging boundary

Virtual Switch Tagging uses the distributed port group's VLAN ID to tag traffic before it leaves the host. The upstream physical port must carry those tagged VLANs.

The physical-switch trunk sits beyond the evidence available in the vSphere Client. Its allowed VLAN list needs physical-switch access or independent network evidence.

Switch to Evidence Notes in the saved workbook.
Enter IDs 214 and 215 use Virtual Switch Tagging.
Enter the virtual switch adds the VLAN tag.
Enter the upstream physical port must carry the tagged VLANs.
Label the physical-switch trunk allowance External verification required.
Add a note that VLAN membership cannot be inferred solely from 192.168.213.0/24 addressing.
Save vSphere-Toy-Box-Inventory.xlsx.

Before you check the finished workbook, where do you think the vSphere Client's evidence should stop?

Return to Network Map.
Follow the VLAN 214 row from its VM adapter to the physical-switch trunk.
Follow the VLAN 215 row from its VM adapter to the physical-switch trunk.
Compare the last observed physical NIC in both rows.
Return to Evidence Notes.
Confirm that the physical-switch trunk allowance is labeled External verification required.

You should see one VLAN 214 path plus one VLAN 215 path ending at the same shared vmnic. Each path continues to a physical-switch trunk whose allowance requires external verification.

Your evidence notes should identify Virtual Switch Tagging without using 192.168.213.0/24 as proof of VLAN membership.

You have turned two port-group labels into an evidence-backed network map with a clear handoff to the physical-network team.

Secret mission

Defend One VM Record End to End

One ambiguous VM can expose every weak assumption in an inventory. Defend that record with evidence from five vSphere views, assign an honest confidence level, and brief another administrator on what remains unproven.

Clean Up Your Resources

Choose whether to keep your evidence as a lab baseline, pause your work for later, or delete the local files. Your evidence lives in files created with Microsoft Excel, so there are no cloud resources or ongoing costs.

Resources you used:

The saved local workbook vSphere-Toy-Box-Inventory.xlsx.
One or more downloaded vSphere VM inventory .csv files.

Keep everything running

No action is needed. Choose this if you want to keep refining the workbook or reviewing its evidence in the vSphere Client.

Retain vSphere-Toy-Box-Inventory.xlsx as your dated lab baseline.
Retain the downloaded .csv files as the original inventory export.
Continue the view-only workflow whenever you return to the vSphere Client.

Pause - I'll come back to this later

Save your current evidence before closing the local tools. Your workbook remains ready for the next review session.

Save vSphere-Toy-Box-Inventory.xlsx in Excel.
Close Excel.
Sign out of the vSphere Client.
Close Microsoft Edge.

No service needs to remain running while this project is paused.

Delete - I don't want to use this again

Deleting these local files removes your saved evidence. Your vCenter environment stays untouched because this workflow created no vSphere configuration.

Sign out of the vSphere Client.
Close Excel.
Locate vSphere-Toy-Box-Inventory.xlsx in its saved Windows location.
Delete vSphere-Toy-Box-Inventory.xlsx.
Locate the downloaded vSphere inventory .csv files in their download location.
Delete each downloaded vSphere inventory .csv file.
Confirm the workbook and downloaded inventory files no longer appear in their previous locations.

Nice Work!

You did it! You turned evidence from the vSphere Client into a complete VM inventory plus a VLAN map. Your saved Excel workbook gives another administrator a traceable view from each VM to the physical-network boundary.

What you learned:

Built an evidence-backed VM record for every VM visible in vCenter Server. Each row separates the vCenter VM name from guest-reported identity. Missing telemetry is recorded as Not reported.
Classified Red Hat Identity Management, Red Hat Satellite, OpenShift-style control-plane nodes, worker nodes, other roles, or Unknown from observed evidence. Used VMware Tools telemetry plus retained tasks and events to defend each confidence level.
Mapped an end-to-end network path for representative VLAN 214 and VLAN 215 VMs. The evidence follows each distributed port group through a vSphere Distributed Switch to the shared physical vmnic. The physical-switch trunk remains External verification required.
Secret Mission: Defended one ambiguous VM record with corroborating evidence from multiple vSphere views. Assigned an evidence-based confidence level. Wrote a five-sentence operator briefing that names the unresolved gap plus its next verification owner.

Ready to quiz yourself?