Used network ports between ESX, vCenter, and the vSphere client

In a single customer setup, the network traffic and ports used in the virtual infrastructure are typically not a focus area because most components can be placed on the same networks. However, in a multiple customer environment we're experiencing that the network guys are asking a lot of questions as they want to lock down and secure the networks (which makes sense..).

Anyway, I just wanted to gather some of the info that I use regularly.

• A link to my previous post with a network diagram
• Link to VMware KB article about used ports for a vSphere environment and related components
• vMotion between networks requires TCP port 8000
• If searching and sorting VMs in the vSphere client is slow, then ensure that port 8443 TCP is opened between the vSphere client and the ESX hosts
• If hardware status tab is not available, then ensure that port 8443 TCP is opened between the vSphere client and the vCenter server
• In vCenter 5.x, if searching and sorting VMs in the vSphere client is slow then port 10443 TCP has to be opened between the vSphere client/client PC and the vCenter server (also, opening this port is required for viewing VM inventory across linked mode vCenter servers - for v5.1)
• If you can't get a remote console on the VMs (you get a black screen and a yellow bar in the top stating some sort of MKS error) ensure that port 903 (and 902) TCP is allowed from the vSphere client and to the ESX hosts
• If an ESX host keeps disconnecting in vCenter, ensure that port 902 UDP is allowed from the ESX host to the vCenter

Required ports between ESX and vCenter:

Source	Destination	Direction	Protocol	Port	Purpose
vCenter	ESX	In/out	TCP	902	VMware console
vCenter	ESX	In/out	TCP	903	VMware console
vCenter	ESX	In/out	TCP	443	HTTPS
vCenter	ESX	In/out	TCP	22	SSH
vCenter	ESX	In/out	TCP	80	HTTP
vCenter	ESX	In/out	TCP	161	SNMP
vCenter	ESX	In/out	TCP	5989	CIM
ESX	vCenter	out	UDP	902	Heartbeart

Access rights and permissions in vSphere

In more than one instance, I have experienced a situation where we had issues with managing permissions in both vCenter (vSphere 4) and VirtualCenter (VI3). The issue is that a user loses access rights when a group to which the user belongs is added with less permissions.

An example could be that a given user, 'UserA', has administrator rights at the top level (Hosts and Clusters) and then at a lower level (let's say at Datacenter level), a given security group, Group1, in which UserA exists is given, let's say, 'Virtual Machine User' rights. This will decrease the permissions for UserA on that datacenter to only Virtual Machine User in stead of Administrator - he cuts the tree under himself, so to speak.

The consequence can be that in stead of risking this scenario of suddenly losing access rights when groups are added, then security groups are not used at all, only single users are added. This is not a problem when only a few users needs acces to the vCenter or VirtualCenter. However, if many users need access, e.g. 20-40 employees, it gets rather complex to manage.

To be absolutely sure how these permissions work, I have done a bit of testing on both vCenter and VirtualCenter.

Test cases

First of all, permissions seem to work identically in both versions, that is VI3 (VirtualCenter) and vSphere (vCenter). Furthermore, when permissions are changed in vCenter, then they are applied more or less instantaneously. So if you change or configure permissions for a user that has the vSphere client open, then the changes will appear to the user at the same time while he has the vSphere client (or VI Client) open (this makes it nice and easy for testing purposes, by the way...)

If the administrator role is assigned to UserA at the Hosts and Clusters level, and then he is assigned less permissions at a lower level (e.g. at a given Cluster), then the less permisssions on that lower level will win.

It works the same way the other way around, if UserA has 'Read only' on Host and Clusters and Administrator rights at a given Datacenter, then UserA will have full rights on that Datacenter and read only on the rest of the virtual environment.

If UserA has Administrator rights at the Hosts and Clusters level and at the same time a group to which UserA belongs is added with Read only to the same level - the interesting question is which of the two different permision levels will UserA be granted, Administrator (as a single user) or Read only (as he belongs to the group)?
The answer is that the highest defined permissions defined at a given level for a user will win. In the case UserA will have administrator rights at hosts and clusters level.

Administrators group

Another thing to be aware of is that Windows Administrators on the vCenter server are automatically added as administrators in vCenter. If you do not intend to give all of your Windows admins full acces to your VMware environment, then remove the 'Administrators' group from vCenter (in stead, you can add the local administrator user a an administrator in vCenter, so you have the possibility to log in with a local account should AD fail..)

Security groups or Distribution lists

Only security groups defined in Active Directory (AD) can be used as groups in vCenter. Distribution lists won't work.

Recommendations for managing users

In regards to the use of groups for managing users in vCenter, I recommend that groups are used at the hosts and clusters level (of course, this can vary greatly depending on your setup). For example, you could have three groups:

• VMware admins (Administrator)
• VM admins (Deploy/destroy rights, change VM specs, etc.)
• Windows admins (console access to the VMs, similar to ILO access on physical servers)

Even though a VMware admin belongs to several groups, as long as these are defined at the same level, then he/she will retain administrator rights.

By using security groups, then the VMware admins won't have to manage user administration on the VMware environment. When a user is added to a given group in AD (this should be handled by your user administration department or system), then he automatically gets access to vCenter.

For more info, see Basic System Administration guide pp. 213-230 on VMware.com.

vCenter Converter Standalone 4 - ports used

We're doing quite a few P2V conversions at the moment, and that means that we see all kinds of weird errors, conversion failures, and connection issues. P2V is definitely not an exact science.

One thing that is recommended to have in order is that proper network ports are opened.

VMware has written a good KB article that explains which ports are used.

If you have server with Converter Standalone installed on it, and you have trouble connecting to the source physical computer, then first make sure that Windows Firewall is disabled. If that doesn't work, then install the Converter application directly on the source computer. Then you will need outbound 443 TCP connection to vCenter (former Virtual Center) (it's assumed that port 443 TCP is open inbound on the vCenter server, of course).

To test if ports are open, open a CMD prompt and run following command:

telnet 'vCenter ip' 443

(without the ' ') If the DOS prompt goes black, then the connection is good. Othervise you will get a 'can't connect' or something similar)

If you P2V directly to an ESX server, then ports 902, 903, and 443 TCP are used.

If you, for some reason, can't get port 443 opened, then a workaround is as follows:

• Install the Converter directly on the source system
• If you have an existing test VM in the same IP range, then create a new disk and attach that to the test VM.
• Make a Windows share on the new disk
• From the Converter choose to export to standalone virtual machine in Workstation format and then coose to place files on the share just created
• After export, change the VLAN to an IP range that doesn't have any firewalls blocking
• Import the VM from within vCenter

Draw a nice Visio digram from your VC using Powershell

If you have been drawing infrastructure diagrams in Visio of your company setup, you know how cumbersome it can be - especially as the infrastructure changes often. In stead of manually changing your Visio drawings, here's a new tool, that can depict an exact copy of your Virtual Center (now vCenter) or a given cluster - or from a given host - in Visio.

You need to have Powershell and VI Toolkit installed to run script. See here for installation instructions.

1. Go to Virtu-al for further instructions. Download the vDiagram.zip file.
2. Once extracted copy the 'My-VI-Shapes.vss' file to your 'My Documents\My Shapes' folder. If the folder does not exist create it and copy the file in.
3. Run the powershell script (Start-> VMware VI Toolkit -> VMware VI Toolkit ) with the following options:
To diagram the entire Infrastructure:
vDiagram.ps1 -VIServer MYVISERVER or HOST
To diagram a specific cluster use the following:
vDiagram.ps1 -VIServer MYVISERVER -Cluster "Production Cluster"