Navigate vCenter and Read Inventory

Navigate vCenter to map a VM's compute, storage, network, and health.

Introduction

30 Second Summary

When a system needs attention, the operations team first needs to know where it sits. A crowded management screen can scatter that answer across several views.

In this project, you will create an inventory passport for the test virtual machine from Project 0 using the vSphere Client. The passport connects its placement and infrastructure relationships to the operational evidence visible on screen.

What You'll Build

Your finished passport will let you walk an administrator through where the test VM runs, which infrastructure objects relate to it, and what its monitoring screens report.

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

A live compute path you can read from vCenter Server through the data center and ESXi host to your target VM.
A four-view mental model that separates compute placement, VM organization, datastore relationships, and network port groups.
A read-only operational check that translates object status, triggered alarms, and an event into plain language.
Secret Mission: Independently investigate a second VM and write a three-sentence comparison between its inventory passport and the first.

Are there any prerequisites?

This project requires the Windows test environment from Project 0, including its visible test VM plus read-only credentials and a URL for vCenter Server 8.0 Update 3 or newer. The first step helps you install Microsoft Edge if it is unavailable.

Before We Start

Before the hands-on work begins, lock in the Project 0 test virtual machine you will investigate. This gives every later inventory check one clear operational story.

Sign In to the Read-Only Workspace

A dependable vSphere inventory investigation starts in the correct server interface. The read-only guardrail keeps this project focused on evidence from the live test environment.

In this step, you will use Microsoft Edge to sign in to the vSphere Client for the supplied vCenter Server. You will confirm that your account can view permitted inventory objects.

In this step, get ready to:

Open the test vCenter Server address in Microsoft Edge.
Sign in with the supplied read-access credentials.
Confirm that permitted inventory objects are visible without changing the environment.

Start Microsoft Edge

Microsoft Edge provides the browser window for this read-only vSphere Client session. You already have it available from the project setup.

Press Cmd+Space (macOS) or the Windows key (Windows) to open the search bar.
Type Microsoft Edge into the search bar.
Press Enter to open Microsoft Edge.

You will see a Microsoft Edge browser window ready for the test vCenter Server address.

Open the vSphere Client

The direct client URL points Microsoft Edge to the browser interface for your test server. The server address must match the value supplied by your lab administrator.

Select the Microsoft Edge address bar.
Replace vcenter_server_ip_address_or_fqdn in https://vcenter_server_ip_address_or_fqdn/ui with the supplied test server address.
Enter the completed URL in the address bar.
Press Enter to load the vSphere Client sign-in page.

A certificate warning deserves a careful pause. Continue only when the warning is expected under your organization's policy.

Click Details if the expected certificate warning appears.
Click Go on to the webpage if your organization permits access.
Ask your lab administrator to confirm the certificate if the warning is unexpected.

You will reach the sign-in page for the test vCenter Server.

Can't reach the sign-in page?

Check that the supplied server address replaced vcenter_server_ip_address_or_fqdn without extra spaces.
Ask your lab administrator to confirm the server address if the page still does not load.

Help me diagnose the connection safely.

Confirm read-only access

Keep your credentials private

Credential screens deserve extra care. Keep the supplied details inside the sign-in form.

Leave all credential values out of screenshots.

Before you sign in, do you expect this account to show every object or only the objects allowed by its permissions?

Enter the supplied read-access credentials in the sign-in form.
Click Login.

You are in. The inventory navigator shows the objects this account is permitted to view.

Confirm that object names are visible in the inventory navigator.
Keep the Project 0 test VM from your inventory passport as the investigation target.
Use this session only to view object state and details.

What does read-only access mean?

The Read Only role permits you to view object state and details. It blocks actions through menus and toolbars.

A disabled or unavailable action shows that the permission boundary is protecting the environment.

Before your final check, what should prove that this session is ready for a read-only investigation?

Confirm that the address in Microsoft Edge ends with /ui.
Confirm that permitted inventory objects remain visible.
Leave every environment object unchanged.

You should see the vSphere Client inventory permitted by your account. Your Project 0 test VM remains the target for the investigation.

Can't see the inventory?

Confirm that you used the supplied read-access credentials.
Ask your lab administrator to verify the account permissions if the client loads without permitted objects.

Help me troubleshoot the missing inventory.

Your read-only workspace is ready. Next, you will use Hosts and Clusters to trace the target VM through its compute path.

Trace the VM Compute Path

Your read-only vSphere Client session is ready. The next operational question is where the target VM runs.

The Hosts and Clusters hierarchy gives the fastest visible answer to runtime placement. It leaves the VM's organizational path unresolved.

Storage relationships need separate evidence. Network port groups do too.

In this step, get ready to:

Follow the visible compute hierarchy until you locate the target VM.
Record the exact compute path shown in your environment.
Identify the infrastructure questions that need a different inventory view.

Read the compute hierarchy

The hierarchy arranges runtime placement beneath vCenter Server. Environments can add folders or resource pools between the main infrastructure levels.

What do these levels mean?

A data center aggregates the different object types used in the virtual infrastructure.
A cluster groups hosts so vCenter Server can manage their resources as one unit.
An ESXi host is the physical computer that runs the hypervisor and its virtual machines.
A resource pool partitions the CPU and memory resources available from a host or cluster.
A folder groups objects of the same type into an organizational level.

Why follow the hierarchy?

A direct search can locate the VM faster.

Following the parent-child tree preserves every visible level of runtime context. That context is the evidence your inventory passport needs.

Return to the vSphere Client tab in Microsoft Edge.
Select Hosts and Clusters in the navigation area.
Expand the visible vCenter Server object.
Expand the data center containing your Project 0 test VM.
Continue expanding each visible compute folder, cluster, standalone host, resource pool, or ESXi host until the target VM appears.
Select the target VM in the hierarchy.
Click Summary in the selected VM's tab bar.

You should see the target VM highlighted in the compute tree with its Summary view open. You have now found the VM inside the live compute hierarchy.

Can't find the target VM?

Expand any collapsed compute folder or resource pool beneath the data center.
Ask the lab administrator to confirm your visibility if the target VM never appears in the permitted inventory.

You can also ask for help checking where a VM might appear in Hosts and Clusters.

Record the path exactly as shown

The live hierarchy is the authority for this path. Your environment may include levels that another vCenter Server does not use.

Return to the Inventory Passport from earlier.
Read the visible ancestor sequence from the vCenter Server object down to the target VM.
Record the complete sequence in your Inventory Passport: your exact visible compute path.
Keep the target VM selected with Summary open.

Before you read it back, do you expect the recorded sequence to include every expanded ancestor?

Read your exact visible compute path aloud from the vCenter Server object to the target VM.
Compare each spoken node with the expanded hierarchy.

The path should begin with the visible vCenter Server object. It should end with the Project 0 test VM.

That's a useful checkpoint: your passport now preserves the VM's runtime placement exactly as this environment presents it.

Does the path look incomplete?

Expand any collapsed ancestor between the data center and the target VM.
Compare every recorded object name with its spelling in the live tree.

You can ask for help checking an incomplete vSphere compute path.

Name the missing answers

The compute hierarchy answers where the VM runs. It does not clearly establish every relationship needed for the inventory passport.

Which questions remain open?

The organizational folder path still needs a separate cross-check.
The VM's datastore relationships still need a separate cross-check.
The listed network port groups still need a separate cross-check.

Label the recorded compute hierarchy as the source for runtime placement.
Add the three cross-check questions from the callout to your Inventory Passport.

Before the final check, do you expect your passport path to match every expanded level in the current tree?

Return to the expanded Hosts and Clusters tree from earlier.
Select the target VM if another object is highlighted.
Open Summary if another tab is active.
Read your exact visible compute path through every visible level.
Compare the three unanswered questions with your passport notes.

Every node in the recorded path should match a visible ancestor in the current tree. The selected VM's Summary view should remain open.

Your passport should label runtime placement as answered. It should keep the organizational path, datastore relationships, and network port groups as open cross-checks.

Your inventory passport now contains a verified compute path for the Project 0 test VM. Next, you'll compare this runtime placement with the VM's organizational hierarchy.

Compare Inventory Hierarchies

The compute path you recorded in the vSphere Client shows where the Project 0 test virtual machine runs. Questions about its organizational folder still remain.

vSphere uses separate inventory hierarchies to represent different object relationships. Seeing the same VM through a second hierarchy makes this distinction concrete.

In this step, get ready to:

Locate the target VM in VMs and Templates.
Record the VM's organizational path exactly as displayed.
Read one visible Summary state or message without changing the environment.

Switch to VMs and Templates

What do folders and templates represent?

The VMs and Templates view presents the VM's organizational hierarchy. Its visible nodes can include the data center.

A folder groups objects of the same type. It can contain other folders.

A template is a primary VM copy used to provision new virtual machines.

Return to the vSphere Client tab in Microsoft Edge.
Click VMs and Templates in the main navigation.
Expand the vCenter Server object.
Expand the data center that contains your target VM.
Expand each visible VM folder until the target VM appears.
Select the Project 0 test VM.
Record the full path in your inventory passport: your exact VMs and Templates path.

You should see the same target VM at the end of the expanded organizational path.

That is a useful breakthrough. The same VM now has an organizational path you can compare with its compute placement.

Can't find the target VM?

Confirm that you expanded the same data center used in Hosts and Clusters.
Expand every visible VM folder under that data center.
Confirm that the VM name matches the target recorded in your inventory passport.

Ask for help to locate the same VM in VMs and Templates.

Compare the two paths

The two paths describe separate relationships. VM folders describe organization.

Why does vSphere use separate hierarchies?

Within each data center, there are four separate hierarchies. Each hierarchy presents one type of infrastructure relationship.

Hosts and Clusters focuses on compute placement. VMs and Templates focuses on VM organization.

Before you compare the entries, do you expect both paths to answer the same question?

Place the VMs and Templates path beside the Hosts and Clusters path in your inventory passport.
Label each VM folder as an organizational container.
Mark the cluster as compute placement if your path includes one.
Mark the resource pool as compute placement if your path includes one.
Mark the ESXi host as compute placement.
Write one sentence explaining the different question answered by each path.

You should see that the organizational path groups the VM through VM folders. The compute path shows the host-side resources that run it.

You have now separated two views that are easy to blur together.

Read the Summary view

The Summary view adds a current object-level observation to your two path records. A visible state or message gives you evidence to report.

Keep this investigation read-only

A warning can make the screen feel urgent. Your task is limited to recording what the client reports.

Acknowledgement controls remain untouched. Reset controls remain untouched. Remediation controls remain untouched.

Keep the target VM selected in VMs and Templates.
Click Summary in the object's tab row.
Read one visible state or message.
Translate the observation into one plain-language sentence.
Record that sentence in your inventory passport.

Your note should describe only what the Summary view displays. It should avoid guessing at an unseen cause.

Before the final check, do you expect the Summary observation to replace either recorded path?

Confirm that the organizational path starts at vCenter Server and follows the visible VM folders to the target VM.
Confirm that the compute path still records the host-side placement from Hosts and Clusters.
Confirm that your Summary note describes one visible state or message.
Confirm that datastore relationships remain listed as a question to cross-check.
Confirm that network port groups remain listed as a question to cross-check.

Strong work. Your inventory passport now contains two separate paths for the same VM plus one evidence-based Summary observation.

Your organizational path now sits beside the VM's compute placement. Next, you will cross-check the storage and networking questions that remain.

Map Storage and Networking

Your compute path now explains where the Project 0 test virtual machine runs. Your organizational path explains where the same VM is grouped.

A datastore is a logical storage location for VM files. A network port group provides policy and a connection point for a virtual NIC.

The earlier trees could not cross-check either relationship. The vSphere Client's Summary, Storage, and Networking views complete the passport without changing the environment.

In this step, get ready to:

Capture every infrastructure relationship listed under Related Objects.
Cross-check each recorded datastore through its VMs tab.
Locate each recorded port group in Networking.

Capture the VM's related objects

The VM's Summary view uses the Related Objects tile to show infrastructure references. A reference can come from a current device, mounted media, or a snapshot.

In the target VM's Summary view from earlier, locate the Related Objects tile.
Record every datastore name in your Inventory Passport: your listed datastore names.
Record every network port group name in your Inventory Passport: your listed port group names.

That closes the first gap: your passport now carries the relationships that the earlier trees left unanswered.

Why Related Objects Needs a Cross-Check

A datastore in Related Objects means the VM holds a reference to it. Current files, mounted media, or a snapshot can create that reference.

Snapshots can also preserve earlier port group references. Each extra name remains a read-only observation in this project.

Cross-check each datastore

A datastore's VMs tab lists the virtual machines that reside on it. This gives you a visible test for each storage relationship in your passport.

Return to the main inventory by clicking Storage.
Locate the first datastore from your listed datastore names.
Select the matching datastore.
Click VMs.
Check whether the Project 0 test VM appears in the list.
Record whether the VM appears beside that datastore in your Inventory Passport.
Repeat this check for every remaining datastore.

You should see the Project 0 test VM in the VMs list for the datastore that stores its files. A different result for another reference belongs in your passport as evidence.

VM Missing from the VMs Tab?

Compare the selected datastore name with the name copied into your passport.
Confirm that the open VMs tab belongs to the selected datastore.

Help me understand why my VM is missing from a datastore's VMs tab.

Locate each network port group

The Networking view gives each port group a place in the network inventory. Matching the displayed names completes the connection side of your passport.

Before the final check, do you expect every recorded port group name to appear exactly as copied? The Networking view tests that prediction.

Click Networking.
Locate every port group from your listed port group names.
Compare each displayed name with the spelling in your passport.
Record each located port group name in your Inventory Passport.
Record any missing match or unexpected additional network reference as a read-only observation.

You should see matching port group names in Networking. Each match confirms that the recorded name exists in the network inventory.

Port Group Hard to Find?

Compare the capitalization of the network inventory name with your recorded name.
Compare the spacing of the network inventory name with your recorded name.
Return to the VM's Summary view to confirm the original spelling.

Help me locate a VM's recorded network port group in vSphere Networking.

Inventory Passport Checkpoint

Every datastore and network port group shown in Related Objects is now recorded.

For each datastore, the passport says whether the Project 0 test VM appears after selecting that datastore in Storage and opening VMs.

For each port group, the passport says whether its name was located in Networking.

Any unexpected additional network reference remains recorded as a read-only observation.

That is the infrastructure story complete: your passport now connects the VM's placement with its storage and network relationships. Next, you'll read status, alarms, and events as operational evidence.

Read Status, Alarms, and Events

Your inventory passport now connects the Project 0 test virtual machine to its compute placement. It also records the related infrastructure.

Operational evidence adds the condition behind that map. The vSphere Client presents a datastore status separately from a triggered alarm and an event history.

In this step, get ready to:

Interpret the displayed status of one recorded datastore.
Record the current triggered-alarm result for the target VM.
Translate one event into a plain-language observation.

Interpret a datastore status

A datastore status summarizes the condition currently reported by the client. Its meaning depends on the exact status displayed.

How to read datastore status

A status of Normal means the datastore is healthy. A status of Warning indicates a potential problem.

A status of Critical indicates a serious problem that requires immediate attention. A status of Unknown means vCenter Server cannot determine the status because of connectivity or another problem.

Return to the Storage view from earlier by clicking Storage.
Select one datastore recorded in your inventory passport.
Click Summary.
Read the displayed status for the selected datastore.
Record the exact status in your inventory passport.
Write the documented interpretation as one plain-language sentence beneath the status.

Good progress. Your passport now turns a datastore status label into an operational explanation.

Read triggered alarms

An alarm result may show entries or an empty list. Both outcomes describe the selected object within your current permission scope.

This investigation only reads alarm data. Acknowledging an alarm would change the environment. Resetting or remediating an alarm would also change it.

Return to the Hosts and Clusters view from earlier by clicking Hosts and Clusters.
Expand your recorded compute path until the Project 0 test VM is visible.
Select the Project 0 test VM.

Before you check the alarm screen, do you expect to see a populated list or an empty result?

Click Monitor.
Click Issues and Alarms.
Click Triggered Alarms.

You will see the current triggered-alarm result for the selected VM. The screen may contain one or more alarms. It may also show no triggered alarms.

Record the object named for every visible alarm.
Record the severity shown for every visible alarm.
Record the message shown for every visible alarm.
Record that no triggered alarm is visible for the selected object within your current permission scope if no alarm is listed.

That check gives your passport a precise alarm result without changing the selected VM.

Can't see the monitoring tabs?

Confirm that the Project 0 test VM is still selected.
Return to the VM through your recorded compute path if a different object is selected.
Ask your lab administrator to confirm your read access if the monitoring labels remain unavailable.

help me find the monitoring tabs for a VM in the vSphere Client.

Read an event as evidence

An event records activity associated with the selected object. A useful translation identifies the actor, action, affected object, and time.

Before you open the event history, do you expect at least one row to be available for the selected VM?

Return to the VM's Monitor tab by clicking Monitor.
Click Events.

You will see event rows associated with the selected VM or an empty event state.

Expand one event row if the list contains events.
Translate the expanded details into one passport observation using the four evidence questions.
Record the explicit empty-events state if the list contains no events.
Review the completed inventory passport for the three new operational entries.

You should see the selected datastore's displayed status with your interpretation. You should also see the VM's current triggered-alarm result.

A translated event or an explicit empty-events result completes the passport.

That's the investigation complete. Your inventory passport now links infrastructure placement to current operational evidence without changing the environment.

Secret mission

Investigate a Second VM Without Guidance

Choose a second visible VM. Build its full inventory passport without following the earlier click paths line by line. Finish with a three-sentence comparison against the Project 0 test VM.

Clean Up Your Resources

Your read-only investigation used an existing test vCenter Server through the vSphere Client. It added neither infrastructure resources nor ongoing costs.

Choose whether to keep the records available, pause your current browser work, or remove the records entirely.

Resources you used:

The completed Inventory Passport - Project 0 VM record.
The completed Inventory Passport - Second VM record with its three-sentence comparison.
The open read-only vSphere Client workspace in Microsoft Edge.

Keep everything running

No action needed. Choose this if you want to revisit both inventory passports while your read-only browser workspace remains open.

Keep the Inventory Passport - Project 0 VM record in its current location.
Keep the Inventory Passport - Second VM record with its comparison in its current location.
Keep the vSphere Client tab open only while you are actively reviewing the two records.

Pause - I'll come back to this later

Close your current browser work while preserving both records. Choose this when you want to resume the investigation later.

Close the Microsoft Edge window that contains the vSphere Client.
Keep the Inventory Passport - Project 0 VM record in its current location.
Keep the Inventory Passport - Second VM record with its comparison in its current location.

Delete - I don't want to use this again

Remove the two inventory records when you no longer need the investigation. The test vCenter Server inventory stays unchanged because every project action was read-only.

Close the Microsoft Edge window that contains the vSphere Client.
Remove the Inventory Passport - Project 0 VM record from the place where you stored it.
Remove the Inventory Passport - Second VM record from the place where you stored it.
Confirm that neither inventory passport remains in that location.

Nice Work!

Excellent work! You used the vSphere Client to create two read-only inventory passports that support a clear operational comparison.

You've learned how to:

Distinguish the four data center hierarchies. Read Hosts and Clusters, VMs and Templates, Storage, plus Networking as separate views of the environment.
Build an inventory passport that follows a virtual machine from its organizational path to its compute placement. Cross-check the related datastore plus network port groups in their dedicated views.
Interpret datastore status, triggered alarms, plus events as separate operational evidence. Record empty results accurately without changing the environment.
Secret Mission: Independently create a second VM inventory passport. Compare it with the Project 0 passport in three sentences.

Ready to quiz yourself?