Example Architectural Decision – Port Binding Setting for a dvPortGroup

Posted on by

Problem Statement

In a VMware vSphere environment using Virtual Distributed Switches (VDS) where all VMs including vCenter is hosted on the VDS, What is the most suitable Port Binding setting for dvPortgroups to ensure maximum performance and availability?

Assumptions

1. Enterprise Plus Licensing
2. vCenter is hosted on the VDS

Requirements

1. The environment must have central management of vNetworking
2. All VMs must be able to be powered on in the event of a vCenter outage
3. Network connectivity must not be impacted if vCenter is down.

Motivation

1. Reduce complexity where possible.
2. Maximize the availability of the infrastructure

Architectural Decision

Use the default dvPortGroup Port Binding setting of “Static Binding”

Justification

1. A dvPortGroup port is assigned to a VM and reserved when a VM is connected to the dvPortGroup. This ensures connectivity at all times including when vCenter is down.
3. Using “Static Binding” ensures the vCenter VM can be powered on and connected to the dvPortGroup even after a failure/outage.
4. “Static Binding” is the default setting and there is no reason to modify this setting.

Implications

1. The number of VMs supported on the dvPortGroup / VDS is limited to the number ports on the VDS (not overcommitment of ports is possible).
2. Number of ports configured on a dvPortGroup should be greater than the maximum number of VMs required to be supported.
3. Port Allocation should be left at the default of “Elastic” to ensure the number of ports is automatically expanded if/when required.
4. New Virtual machines cannot be powered on and connected to a dvPortGroup (VDS) when vCenter is down.

Alternatives

1. Set dvPortGroup Port Binding to “Dynamic binding”
2. Set dvPortGroup Port Binding to “Ephemeral binding”

Related Articles

1. Distributed vSwitches and vCenter outage, what’s the deal? – @duncanyb (VCDX #007)

2. Choosing a port binding type in ESX/ESXi (1022312)

7 thoughts on “Example Architectural Decision – Port Binding Setting for a dvPortGroup”

  1. Mate, another nice post and thanks for sharing.

    I have a question (not an important one); is this an architectural decision? It seems more like a design decision to me?

    Like I said, not an important question, probably falls into the same category as on-premise vs. on-premises (i.e. they do really mean different things, just that most people don’t care and everyone generally understands no matter which one you use). Maybe a discussion for the next time we manage to chomp through a steak together or maybe even Kraken 🙂

    • Well put re: on-premise vs. on-premises

      Probably same category, as the post is part of a long series of architectural decisions, some of which fall into architectural and others specific design decisions.

  2. Hi Josh not sure if I totally agree. I do agree that Static Binding should be used in almost all use cases. However I have had issues if I need to move my vCenter while it is powered off.
    Say for example I have had a host issue related to storage or alike and vCenter was powered down as a result but not moved to anther host with HA.

    If I want to move that VM to a working host I need to unregister and re-register the VM directly on the hosts. This can not be done if Static Port binding is used.
    Therefore I find it handy to have one small port group using Ephemeral binding just for vCenter (any any servers it is dependent on).

    • In the corner case your talking about, I agree a dvPortGroup with Ephemeral binding is helpful. This could be created as part of the change control process before vCenter is shutdown, or created as a permanent “Get out of Jail Free” card for Management VMs.

      Another option would be to have all Management VMs living in a dvPortGroup with Ephemeral Binding, either in the same cluster, or a dedicated management cluster.