Admin Portal Views
This page provides details on what you can access from the Commander Admin Portal Views menu.
The functionality available to you is based on your user role; some commands are restricted to certain user roles. For information, see Commander Access Control.
The Inventory allows you to monitor, manage, and report on your IT assets and resources through the following subviews:
The Infrastructure view displays your IT assets hierarchically in your actual infrastructure location. For example, when you view an AWS EC2 instance, you can determine that it belongs to a particular Amazon cloud account, region, and VPC.
Cloud Account Type
A hierarchy of AWS regions, stacks, Virtual Private Clouds (VPCs), Auto Scaling Groups, VMs (Amazon EC2 instances), load balancers (Amazon Elastic Load Balancers), and databases (Amazon RDS database instances). Doesn't include templates (AMIs).
Stacks don't have children in the tree, because stack resources are already displayed in the appropriate location in the tree.
A hierarchy of GCP resources, grouped by region and zone. Because this view is region-centric, you should use it when thinking about geographic distribution. GCP deployments are not shown in this view.
An infrastructure-centric view showing the logical grouping of pods and containers, based on the node where they reside.
A hierarchy of Azure regions, resource groups, virtual networks, VMs, and templates (images). Because this view is region-centric, you should use it when thinking about geographic distribution.
Resource groups are created in a specific region, but the contents of a resource group can span regions. Therefore, in the Infrastructure View, resource groups don't have children (in contrast to the Applications view). When you click a resource group in any view, you can see a list of its resources on its Resources tab.
Hosts, clusters and any folders or datacenters that you have created in the hierarchy. Shows VMs and templates in the hierarchy.
Hosts, clusters, resource pools, and any folders or datacenters that you've created in vCenter. Shows VMs and templates in the hierarchy.
To support both VPCs and EC2 Classic in AWS cloud accounts, Commander displays instances running in a VPC as children of the VPC, and instances not running in a VPC as children of "EC2-Classic", as shown in the following image:
The Applications view displays your deployed resources hierarchically by their membership in a logical group, not by location.
Cloud Account Type
A hierarchy of AWS templates, VMs, and stacks. For each AWS region, this view shows:
Note that stacks don't have children in the tree, because stack resources are already displayed in the appropriate location in the tree.
An application-centric view of GCP resources (including VMs and deployments), logically grouped by organization, folder, and project.
Note that deployments don't have children in the tree, because deployment resources are already displayed in the appropriate location in the tree.
An application-centric view of the Kubernetes cluster, composed of pods, containers and other resources, broken down by namespace.
A hierarchy of popular public Azure images, resource groups, private templates, virtual networks and VMs. Because this view is resource group-centric, it's the view you should use for lifecycle management.
Commander supports only VM images, not OS images.
Resource groups are created in a specific region, but the contents of a resource group can span regions, so regions are not shown in this view. In the Applications view, the children of a resource group are shown beneath the resource group in the hierarchy (in contrast to the Infrastructure View). Because virtual networks may not be in the same resource group as the VMs within it, virtual networks and VMs are displayed at the same level in this view, right under the resource group.
Note that when you click a resource group in any view, you see a list of its resources on its Resources tab.
Templates in the SCVMM library.
A hierarchy of all folders, VMs, and templates.
A view of storage resources in the Infrastructure hierarchy.
Cloud Account Type
|Shows both the EBS and S3 datastores. For more information, see Supported AWS Resources .|
Shows storage resources grouped by region. For GCP, all storage resources are displayed under the Managed folder. Both regional and zonal storage resources are organized into Commander datastores, which are logical groups aggregating persistent VM disks. When you look at a datastore, you can see which VMs have persistent disks, as well as the total storage usage in that zone or region. Disks for images and local disks are not attached to any datastore, so they're not visible in the Storage view. For more information, see Supported GCP Resources.
Provides a storage footprint view of all volumes in the cluster, as well as a list of volumes for each pod, broken down by volume type. It doesn't show volume backings or storage classes.
Shows both managed and unmanaged storage. The view is region-centric, which means that it doesn't provide a resource group–centric view of storage accounts. For more information, see Supported Azure Resources.
The Unmanaged folder in this view shows out-of-inventory VMs (VMs that exist on a datastore but don't exist in vCenter's inventory).
The Terraform view allows you to access the state of Terraform configurations stored in backends that reside in Terraform Cloud, AWS S3 buckets, and Azure Blob Storage containers. You can also view details such as the outputs, variables, and resources for your Terraform deployments.
For more information, see Terraform.
Cost Analytics allow you to see the cost of all services across all cloud accounts, providing you with the data you need to make informed cloud cost decisions. Costs include both the costs for VMs and other services that are managed by Commander and the costs for resources and services that aren't managed by Commander, but will show up on your bill.
For more information, see Cost Analytics.
This View menu selection will take you to the Service Requests page. In Commander, you can set up a process to help you manage service requests received from Service Portal users (as well as from Commander users). You can create and use a service request form by itself or add workflows to create a complete service request process from the initial user request through to deployment and final release of the service to the user.
On the Service Requests page, you can:
- Track service requests in the workflow process. See Track Service Requests.
- Approve (or reject) service requests. See Approve or Reject Service Requests.
- Fill service requests. See Fulfill approved service requests.
- Make your own service requests. See Request New Services.
For general information on managing service requests, see Self-Service.
This View menu selection will take you to the Commander Solutions page.
This View menu selection will take you to the sign in page for the Service Portal — the self-service portal that allows authorized users to do things such as power services on and off, request new services, request changes to existing services, monitor VM performance, resource usage, and service costs.
Through the Service Portal, you can provide your users a view of the resources that they need without allowing access to the underlying private or public cloud infrastructure.
For information on how to set up the Service Portal for users, see Configure the Service Portal.