Navigating ESXTOP

A tool that is very useful is “esxtop.” This command-line tools allows monitoring and collecting of data for the core four resources: CPU, memory, network, and disk.

After enabling SSH on an ESXi host, open up PuTTY and connect to that ESXi host using your root account and password.

Start running esxtop by typing the command on a single line:

esxtop

Once the tool is running, you need to know how to work with it. It runs from the command line and is managed via key strokes.

By default, the tools begins running in the CPU view. I can change views by simply typing “n” for the network view, “d” for the disk view, and “m” for the memory view.

In any view I can type “f” to open up the field screen. From here I can modify which counters are shown in the particular view I am in. I can customize the counters in all of my views. To select/deselect any counter, simply type the letter associated with it. To exit this view, press the space bar.

From any view, I can type a “V” (shift + v) to parse the list and only view virtual machine information.

To get even more information about a virtual machine, type “e” and enter the GID (Group ID) of your virtual machine and press enter. In the screenshot, I entered the GID of Test01-A so that I could view all the VM’s associated worlds.

A world is basically just a process. A world is a scheduled component of the VM, like a process on a typical OS. Worlds are scheduled by the VMkernel just like processes are scheduled. The VM is represented as a group, which gets a single world ID. There are worlds within the world to monitor vCPU, VMM, and MKS (Mouse/Keyboard/Screen).

I will be posting more on esxtop and its counters as I go through my studies. This post is just a quick guide to navigating.

Using vMA to manipulate the VM’s power state

Another set of useful commands are the vmware-cmd ones. I can use “vmware-cmd <vmx path> getstate to determine what the VM’s power state is.
If I want to power on a VM then the command will be ”vmware-cmd <vmx path> start. “
Alternatively to power it off, use ”vmware-cmd <vmx path> stop soft
Something else I can do is use the ”esxcli vm process list“ to list all virtual machine processes.
This can be useful when determining the world ID or UUID of the virtual machine, this also shows the path to the VM’s .vmx file.

Using the vMA to determine the relationship between the UUID and the datastore name

I am continuing to prepare for the VCAP-DCA, a big part of this process is practicing my command line skills.

Today I was using the vMA to practice some list commands and there was one in particular I wanted to share.

You can list the path names to your virtual machines that are registered with the target server (server you are running the commands against).

To do this use:

vmware-cmd -l | more

Your results may look something like:

From there you may notice the 3rd directory in the path to the .vmx file. This is the UUID (universally unique identifier) of the file system on which the virtual machine is residing.

To figure out which UUID belongs to which datastore, use:

esxcli storage filesystem list

Now I can tell which UUID is associated to the “Local01” and “Shared” datastores. Using these two commands, I can tell that “TestVM01” resides on the “Local01” datastore.

Installing ESXi 5.1 on UCS

I thought I would share a document that I created recently for the installation of ESXi on a UCS B200.

1. ESXi Installation Steps for Cisco UCS blades

The following sections provide instructions on installing and configuring ESXi on Cisco UCS blades. The installation time for this build is estimated at 8 hours.

1.1 Launch Cisco UCS Manager

The following section provides instructions on launching the Cisco UCS Manager interface.  The Cisco UCS Manager will be the primary interface to the Cisco UCS blades.
Table 1 Launch Cisco UCS Manager
image
1.2      Install ESXi Software on CIsco UCS Blades
The following section provides instructions on installing the VMware ESXi v5.1.0-799733-custom-cisco-2.1.0.3.iso software on the Cisco UCS blades.Installation time is approximately 30 minutes per blade. However, installation can be performed on multiple blades simultaneously in order to decrease the overall build time.The following instructions assume the blades have already been powered up during the Cisco UCS installation.  Additional copies of the ESXi software are required for this approach.
Table 2 Install ESXi Software on Cisco UCS Blades
image

1.3      Customize ESXi Hosts

The following section provides instructions on customizing the ESXi hosts.  Estimated completion time is approximately 15 minutes per host.
Table 3 Customize ESXi Hosts
image

2        ESXi Post Configuration

The following section provides post configuration procedures.

2.1      Configure Time Synchronization on ESXi Hosts

The following section provides instruction on configuring time synchronization on the ESXi hosts.  These steps only need to be performed on the host profile masters as defined in Appendix B Host Inventory table. This configuration will be applied to the remaining ESXi hosts through a host profile applied during the VMware vCenter Server build.  Estimated completion time is approximately 10 minutes.
Table 1 Configure Time Synchronization on ESXi Hosts
image

2.2      Configure vSwitches on ESXi Host

The following section provides instructions on configuring the vSwitches on the ESXi host.  These steps only need to be performed on one of each ESXi host hardware type. This configuration will be applied to the remaining ESXi hosts through a host profile applied during the VMware vCenter Server build.  Estimated completion time is approximately 20 minutes.
Table 2 Configure vSwitches on ESXi Host
image

2.3      Configure Storage on ESXi Host

The following section provides instructions on configuring the storage on the ESXi host.  These steps only need to be performed on one of each ESXi host hardware type. This configuration will be applied to the remaining ESXi hosts through a host profile applied during the VMware vCenter Server build.  Estimated completion time is approximately 20 minutes.
Table 3 Configure Storage on ESXi Host

image

End of VMware ESXi v5.1.0-799733-custom-cisco-2.1.0.3.iso Installation Guide. 

This is not meant as a “one size fits all” guide, simply an example of a deployment that I was consulting on.

Domain Discovery with SSO

If domains are manually added after SSO is set up and SSO does not auto discover the domains, use the following steps to manually auto discover without using the vSphere Web Client.
Run the ssocli utility. It is located at %ProgramFiles%VMwareInfrastructureSSOServerutils
Open up command prompt, change the directory to the one specified above.
Run the following command:
ssocli configure-riat –verbose –a discover-is –u admin –p <sso password>

Renaming Virtual Machines

Something I run into fairly often is needing to rename the virtual machines files out on the datastore to match how the virtual machine is named in the vCenter inventory. This problem occurs when a user creates a virtual machine, for example “vm-01,” and then realizes that this name doesn’t meet some kind of standard in their organization. So what happens is that the user then right clicks the “vm-01” and selects rename. Say that the user renames it “dc01-austin.” Now when you are looking for the virtual machine, in the inventory it will be referred to as “dc01-austin” but when you look on the datastore it is in the “vm-01” director and the files are name “vm-01.***” In many environments this would fail some kind of annual or biannual audit.

Check out this KB from VMware on several ways to resolve this naming issue.

Organizational Networks in vCloud Director 5.1

Organization Network

An organization network provides network services to one particular organization, whereas an external network is created at the provider level and supplies connectivity to multiple organizations. There are three options when creating organization networks: internal, NAT-connected, and direct-connected. An organization administrator cannot create an organization network due to the configuration of external IPs; only a system administrator can configure this.

Internal

An organization can be set up so that it does not have a connection to the Internet or a connection to any other external network, just an internal connection. An internal-only network could be set up for groups of test virtual machines; a virtual machine can be configured with multiple network interfaces so that it has a connection to the internal network as well as one of the other two types. With an internal organization network, vApps can connect, but there is no traffic outside the organization.

Network Address Translation (NAT)-Connected

Network Address Translation (NAT)-connected, sometimes called a “routed network,” can be connected to the external network through a vShield Edge device. The vShield Edge device provides port-forwarding services, NAT, DNS forwarding, and DHCP services to the network; the vShield Edge device gets provisioned automatically
by vCloud Director as needed. A NAT connection allows for virtual machines to communicate with each other while only having one IP seen from the Internet. Another use of NAT is to fence, which includes two sets of IP addresses: external and internal. Fencing allows for several vApps to utilize the same internal IP addresses and extremely useful for test environments.

Direct Communication

The last option for an organization network is a direct connection. The organization would use an external net- work to connect to external systems, including the Internet. Using this method, a user can connect directly to a virtual machine using remote desktop or even SSH. If a vApp configured for a direct connection then the vApp’s IP addresses must be statically assigned or a DHCP server must be connected to the external providing the vApp with those IP addresses.

For further reading, check out my vCloud Director 5.1 Networking Concepts white paper!

vCloud Director 5.1 Networking Concepts (Introduction)

A VMware vCloud is made up of one or more vCloud Director servers that are integrated with underlying vSphere components. The vCloud is a new abstraction layer above vCenter Server consuming the resources that vCenter manages; this allows a user to self-provision virtual environments utilizing memory, compute, storage, and networking resources. Cloud computing has become a vague, arbitrary phrase, but there are six characteris- tics that define exactly what a cloud should consist of

  • self-service
  • elasticity
  • pay as you go
  • multi-tenancy
  • resource pooling
  • ubiquitous access

A private cloud is an infrastructure whose resources are only used internally. A public cloud is an infrastructure made available to external customers for a price. A hybrid cloud combines two or more clouds with some kind of standardized technology, like VMware vCloud Connector, while each cloud maintains its own unique identity.

The foundation of the vCloud centers on the networking configuration. Networking occurs over three different layers: external, organization, and vApp; it is imperative to properly configure and manage these networks so that the vCloud can be consumed. Think of vCloud networking as an onion that will be peeled back to reveal each layer, starting with the organization’s networks that are created by an administrator with the system administrator role in vCloud Director. A system administrator is the highest role within the vCloud.

For further reading, check out my vCloud Director 5.1 Networking Concepts white paper!

External Networks in vCloud Director 5.1

The first object that is created within vCloud Director is the External Network. An External Network provides the connection from the cloud to the outside world, allowing inter-Cloud connections and is port group based. Even though this connection is called the external connection, an Internet connection is not actually required; this can be set up to provide a connection to several different internal entities, like ESXi hosts, without an actual route

to the Internet. Since this connection is port group-based, then the port group needs to exist prior to attempting to establish the connection. The port group can be defined on a standard vSwitch, a distributed vSwitch, or on a Nexus 1000V. Organization virtual datacenters can use the external networks to provide Internet connectivity to the organizations and the virtual machines that reside within a vApp, given that the vApp network is configured for that. By creating an external network, vCloud Director is effectively configured to send all external traffic using the port group(s) selected. Should there be multiple external networks created then be sure to separate them by using VLANs. Only someone with the system administrator role within the vCloud can create and man- age external networks.

For further reading, check out my vCloud Director 5.1 Networking Concepts white paper!