Home > Blogs > VMware vSphere Blog > Tag Archives: Monitoring

Tag Archives: Monitoring

Did you know vCenter Server can manage multiple hypervisors?

VMware vCenter Multi-Hypervisor Manager is a component that enables support for heterogeneous hypervisors in a VMware vCenter Server environment. It provides the following benefits to your virtual environment:

  • An integrated platform for managing VMware and third-party hypervisors from a single interface.
  • A hypervisor choice for the different business units in your organization to accommodate their specific needs.
  • No single hypervisor vendor lock-in.

When you add a third-party host to vCenter Server, all virtual machines that exist on the host are discovered automatically, and are added to the third-party hosts inventory.

The ability of vCenter Multi-Hypervisor Manager to migrate virtual machines from third-party hosts to ESX or ESXi hosts is implemented by exposing the capabilities of vCenter Converter Standalone in the vSphere Client. See VMware KB article 2048927 for information about dependency between vCenter Multi-Hypervisor Manager and vCenter Converter Standalone.

Key Capabilities

vCenter Multi-Hypervisor Manager 1.1 introduces the following set of basic management capabilities over third-party hosts:

  • Third-party host management including add, remove, connect, disconnect, and view the host configuration.
  • Ability to migrate virtual machines from third-party hosts to ESX or ESXi hosts.
  • Ability to provision virtual machines on third-party hosts.
  • Ability to edit virtual machine settings.
  • Integrated vCenter Server authorization mechanism across ESX/ESXi and third-party hosts inventories for privileges, roles, and users.
  • Automatic discovery of pre-existing third-party virtual machines
  • Ability to perform power operations with hosts and virtual machines.
  • Ability to connect and disconnect DVD, CD-ROM, and floppy drives and images to install operating systems.

Continue reading

vSphere 5.1 – Feature enhancements – Networking MIB support – Part 2

In the last post here, I provided some basic information on SNMP and also shared which networking MIB modules are supported in vSphere 5.1. Before I describe how to use these MIB modules, there is one correction I would like make to the last post. I had mentioned that network related Trap is not supported, but that is not correct. SNMP agent on the host does send SNMP Trap when a physical link goes UP or DOWN. The Trap is like an interrupt. Instead of polling the values of the different network parameters, specific trap tells the user which network parameter needs attention.

Let’s take a look how you can use Networking MIBs to monitor virtual switch parameters.

Continue reading

vSphere 5.1 – Feature enhancements – Networking MIB support – Part 1

In this post, I want to discuss one of the important enhancements in vSphere 5.1. It is obviously related to networking and has to do with providing monitoring support to virtual switch parameters through SNMP. We talked about the RSPAN, ERSPAN capabilities and how you can make use of these features to monitor and troubleshoot any networking issue. Similarly, using the new networking MIBs, you will have the visibility into virtual switches. Here are some of the basics on SNMP before I jump-in and discuss the enhancement in detail.

Simple Network Management Protocol (SNMP) is a standard that allows you to manage devices on IP networks. It consists of three key components: Managed devices, Agent, and Network Management System. In a physical network you will find switches, routers and other networking devices as Managed devices with SNMP Agent running on them. The Agent support on these physical network devices allows a centralized Network Management System (NMS) to get information about these devices and also set parameters centrally.

Continue reading

vCenter Single Sign-On – Part 4: Pre Install Requirements

The installation of vSphere vCenter Sign-On is a relatively a straight forward process when planned correctly and as there are many factors of the environment that the installation process will touch, it is important to review the vCenter Single Sign-On Server prerequisites prior to deployment, preferably during the initial design phase. It is important to note that the vCenter Single Sign-On server is the first component to be installed prior to vCenter Server install or upgrade.

Continue reading

vCenter Single Sign-On – Part 3: Availability

Before we continue with the pre-requisites and installation of SSO we need to complete the planning of our vSphere install/upgrade design and this includes the desired level of availability required, if any.

When speaking to partners and customers I am often stumbled by the amount of attention and time that is placed on individual SSO availability. My response is bluntly why? followed by the question on what do you use today to protect vCenter server? to which the response is typically nothing or vSphere HA, sometimes vCenter Heartbeat. Don’t get me wrong my background is in business continuity and the way I look at it, SSO is an authentication component of the vCenter server, nothing more, nothing less and so when looking to protect SSO, the solution you choose for protecting vCenter server will provide the best protection of all vCenter components. If you choose not to protect the vCenter server then no protection of SSO is required, if SSO goes down, you bring down the vCenter server management, if only vCenter server goes down, you’re in the same situation, without vCenter server your not going to have much use for an SSO server unless shared with multiple vCenter servers (see below). There are solutions that enable themselves with SSO but these all have a dependency on the vCenter server to be operational. I understand that when reading up on SSO at the excellent vSphere 5.1 Documentation Center, there is a configuration called SSO HA (not to be confused with vSphere HA) and as this is an installable configuration, some believe this is the only option for SSO availability which is not correct. While this solution works, it can be very complex to setup, requires the use of third party technologies but does it give me anymore protection than say vSphere HA? I hope to answer this for you.

Continue reading

vSphere 5.1 – VDS Feature Enhancements – Port Mirroring – Part 3

The remote mirroring capability on VDS helps you send traffic from a virtual machine running on one host to a virtual machine on another host for debugging or monitoring purposes. As shown in the diagram below, traffic from a monitored VM on Host 1 is sent through multiple physical switches to an Analyzer VM on Host 2. For this setup to work, you have to perform configuration at various levels as shown by the numbered red circles in the diagram.

RSPAN Deployment Diagram

Continue reading

vSphere 5.1 – VDS Feature Enhancements – Port Mirroring – Part 2

In the last post I covered the configuration of one of the port mirroring session type, Switch Port Analyzer (SPAN) on a host. SPAN is a simple configuration on VDS that allows users to quickly replicate traffic to another virtual machine on the same host. However, SPAN on VDS has following limitations

–       The source and destination ports of the session should be on the same host. Thus limiting the visibility to a particular host.

–       If the monitored virtual machine is moved from one host to another using vMotion, you can’t monitor that virtual machine traffic anymore.

The Remote SPAN (RSPAN) port mirroring session addresses above concerns and also provides the capability to send mirror traffic to a central analyzer tool. The analyzer tool can be connected multiple hops away in a network as shown in the diagram below.

RSPAN Deployment Diagram

Continue reading

vSphere 5.1 – VDS Feature Enhancements – Port Mirroring – Part 1

Network troubleshooting and monitoring tools are critical in any environment. Especially in data centers where you have many applications or workloads consolidated on server virtualization platforms such as vSphere. When you ask any network administrators, what are the challenges in troubleshooting data center networks, where server virtualization is prominent? They will say that they don’t have the visibility into virtual networks and they don’t know what is going on in the hypervisor world.

To provide the right amount of visibility to the administrators, VMware vSphere Distributed Switch (VDS) supports industry standard features such as port mirroring and NetFlow. These features were introduced with the release of vSphere 5.0. In this latest release there are more enhancements to the features along with configuration workflow improvements. I will provide more details on the different types of port mirroring capabilities and which one to choose while troubleshooting or monitoring your network.

Continue reading

How to use Port-Mirroring feature of VDS for monitoring virtual machine traffic?

I would like to clarify few things in this blog entry about the Port-mirroring feature that is available on vSphere Distributed Switch (VDS). This feature is similar to the port mirroring capability available on the physical switches. Network administrators can use this feature to troubleshoot any network related issues in the virtual infrastructure and monitor virtual machine to virtual machine traffic that is flowing on the same ESXi host. Network administrators use network analyzer tool, which captures traffic, along with the port mirror feature to perform monitoring and troubleshooting activities. In the physical network, depending on where the analyzer or debug tool is placed in the network, network administrators choose different port mirroring options. The following are some of the standard port mirroring options available on physical switches:

-       Switch Port Analyzer (SPAN)

-       Remote Switch Port Analyzer (RSPAN)

-       Encapsulated Remote Switch Port Analyzer (ERSPAN)

SPAN feature is local to the switch and requires the monitored ports and the destination port are on the same switch. With the release of vSphere 5.0, VMware provides support for only SPAN feature on VDS. The following blog entry discusses the feature in little more detail. During the setup of a SPAN session customers have to select a virtual port that needs monitoring and then choose a destination virtual port where all the traffic will be mirrored. Here are some of the common monitoring and troubleshooting use cases based on where the analyzer tool is running.

1)    Mirroring to an analyzer tool running in a virtual machine on the same host.

As shown in the figure below, you can have a virtual machine run analyzer tool. In such scenario you have to configure the pot mirror session with source as virtual port of the monitored virtual machine and destination as the virtual port of the virtual machine running analyzer tool.


2)    Mirroring to an external physical analyzer connected directly to the uplink port of the host.

In this case the analyzer tool is running on an external physical device, which is directly connected to the host through a NIC. As shown in the figure below, the source virtual port of the port mirror session remains same but the destination is changed to the uplink port connected to vmnic1. The mirror packets are sent through the vmnic1 to the analyzer device for monitoring.


3)    Mirroring to an external physical analyzer connected to a physical switch where the host is also connected.

This setup is possible provided you configure a SPAN session on the VDS and physical switch as well. Let’s dig a little more here. As mentioned earlier, SPAN feature is local to a switch and requires both monitored and destination ports on the same switch. If you look at the diagram below, the analyzer is not directly connected to the VDS. It is connected through a physical switch. So this is not a straightforward use case 2.

Let’s take a look at the mirror packet flow. The port mirror session is configured on the VDS with the virtual port of the monitored virtual machine as the source and uplink connected to vmnic 1 as the destination. All packets flowing through the monitored virtual machine are now copied through the vmnic1 to the physical switch port. On the same physical switch the analyzer is connected to a different port. The analyzer connected to a port on the same switch is not going to see the traffic mirrored by VDS. For this use case to work, it is not enough to configure the port mirror session on VDS. You have to configure SPAN session on the physical switch with the switch port where the host’s vmnic 1 is connected is the monitored port and the destination port is where the analyzer is connected.


VDS currently doesn’t support RSPAN capability, which allows network administrators to monitor the traffic remotely multiple hops away from the source. Customers have to create a dedicated VLAN to carry the RSPAN traffic and the switches supporting RSPAN feature have to encapsulate all the monitored traffic in this special VLAN.

There is also some confusion because of the GUI screen options provided during the port mirroring setup on VDS.

If you take a look at the configuration screen shown below, there is an encapsulation option shown in the red box. This encapsulation option gives the feeling that RSPAN is supported. However, it is not and you shouldn't configure this parameter. 


As usual, I would like to hear your comments. Thanks for reading.

Get notification of these blogs postings and more VMware Networking information by following me on Twitter:  @VMWNetworking


vSphere 5 New Networking Features – Port Mirroring

Port mirroring is the capability on a network switch to send a copy of network packets seen on a switch port to a network-monitoring device connected to another switch port. Port mirroring is also referred to as Switch Port Analyzer (SPAN) on Cisco switches. In VMware vSphere 5, a Distributed Switch provides a similar port mirroring capability that is available on a physical network switch. After a port mirror session is configured with a destination—a virtual machine, a vmknic or an uplink port—the Distributed Switch copies packets to the destination.

Port mirroring provides visibility into

• Intrahost virtual machine traffic (virtual machine–to–virtual machine traffic on the same host)

• Interhost virtual machine traffic (virtual machine–to–virtual machine traffic on different hosts)

Figure below shows different types of traffic flows that can be monitored when a virtual machine on a host acts as a destination or monitoring device. All traffic shown by the orange dotted line with arrow is mirrored traffic that is sent to the destination virtual machine.

The terms Ingress source and Egress source are with respect to the VDS. For example, when you want to monitor the traffic that is going out of a virtual machine towards the VDS, it is called Ingress Source traffic. The traffic seeks ingress to the VDS and hence the source is called Ingress. If you want to monitor traffic that is received by a virtual machine, then configure the port mirroring session with the traffic source as Egress Source as shown in the top right corner diagram of the figure below.


Following figure shows the traffic flow when the mirror destination is configured as an uplink port. In this case both the normal traffic as well as mirror traffic flows through the same physical uplink.


When network administrators are concerned about the impact of the mirror traffic on normal traffic, they can choose a separate uplink port to send mirror traffic. The figure below shows the traffic flow when a separate uplink port is configured to carry mirror traffic.



The port mirroring capability on a Distributed Switch is a valuable tool that helps network administrators in debugging network issues in a virtual infrastructure. The granular control over monitoring ingress, egress or all traffic of a port helps administrators fine-tune what traffic is sent for analysis.


Port mirror configuration can be done at the Distributed Switch level, where a network administrator can create a port mirror session by identifying the traffic source that needs monitoring and the traffic destination where the traffic will be mirrored to. The traffic source can be any port with ingress, egress or all traffic selected. The traffic destination can be any virtual machine, vmknic or uplink port.

The following figure is the first screen of port mirror session configuration process. In this step users can define the name of the port mirror session and choose if they want to allow normal I/O on a destination port. They can also choose a VLAN to encapsulate these mirrored packets by selecting the Encapsulations VLAN box.


Once you click next, the configuration screen will provide the option to choose the source that you want to monitor. Depending on what traffic you want to monitor you can choose Ingress, Egress, or Ingress/Egress in the traffic direction pull down menu as shown in figure below. Then specify the Port ID of that particular source VM. To get the corresponding dvPort number or Port ID number of a VM use the following steps:

1.      Switch to the Home > Inventory > Networking view.

2.      Select dvSwitch and choose the Ports tab on the right panel. Scroll down to see the virtual machines and the associated port ID.

Enter the port number in the Port ID field and move it to the right panel and then click next.


In the next step you have the option to configure the destination where you want to mirror the traffic to. There are two options provided in the Destination type pull down menu as shown in figure below.


This completes the creation of the port mirroring session. As shown in below, you can find the details about the port mirror session and also note that the status of the session is disabled.


To enable the port mirroring session, click Edit in the figure above. This will pop up the panel with an option to enable the session. Select the status as enabled as shown in figure below. This enables the port mirror session and VDS will mirror the traffic to selected destination port.


This covers the trouble shooting and monitoring features of vSphere 5. I will talk about the enhancements to the Network I/O control (NIOC) feature in my next post. So please stay tuned.