Feb 13

autoExpand for vSphere 5 distributed switch portgroups

Administration, Network, Tips and Tricks 2 Comments »

You have probably read my last post on when to use Ephemeral Port Bindings on distributed switches.  As mentioned in that article, Static port bindings should be the standard going forward.  When you create a port group with a Static port group binding, you set how may ports are dedicated to that port group.  The default is 128 ports and can be changed if need be.

There are some important numbers to remember from the vSphere 5 Maximums doc:

  • Distributed virtual network ports per vCenter: 30,000
  • Static port groups per vCenter: 5,000
  • Ephemeral port groups per vCenter:  256
  • Distributed switches per vCenter: 32
One of the concerns is that what if I run out of static ports and one of the other admins needs to put a new VM into that port group?  What if he does not have permission to expand the number of ports in the port group?
vSphere 5 includes a new feature for distributed switches called autoExpand.  This is a little known advanced option that will add ports to a port group before you run out of ports.

In vSphere 5.0 a new advanced option called autoExpand has been introduced. This property of Portgroup allows a Portgroup to expand automatically by a small predefined margin everytime Portgroup is about to run out of Ports.  The only documentation I could find about this procedure was in the KB article on port bindings.  This is the process from the referenced KB article at the time of this writing:

In vSphere 5.0 a new advanced option called autoExpand has been introduced. This property of a Portgroup allows a Portgroup to expand automatically by a small predefined margin everytime Portgroup is about to run out of Ports.

This is disabled by default and can be enabled using vSphere 5.0 sdk via managed object browser.

  1. In a browser, enter the address http://vc-ip-address/mob/.
  2. When prompted, enter your vCenter Server username and password.
  3. Click the content link.
  4. In the left pane, search for the row with the word rootFolder.
  5. Open the link in the right pane of the row. The link should be similar to group-d1 (Datacenters).
  6. In the left pane, search for the row with the word childEntity. In the right pane, you see a list of datacenter links.
  7. Click the datacenter link in which the vDS is defined.
  8. In the left pane, search for the row with the word networkFolder and open the link in the right pane. The link should be similar to group-n123 (network).
  9. In the left pane, search for the row with the word childEntity. You see a list of vDS and distributed port group links in the right pane.
  10. Click the vDS for which you want to change this property.
  11. In the left pane, search for the row with the word config and click the link in the right pane.
  12. In the left pane, search for the row with the word autoExpand. It is usually the first row.
  13. Note the corresponding value displayed in the right pane. The value should be false by default.
  14. Go back to the vDS page.
  15. Click the link that reads ReconfigureDvs_Task. A new window appears.In the Spec text field, enter <spec><autoExpand>true</autoExpand></spec>
  16. Click the Invoke Method link.
  17. Close the window.
  18. Repeat Steps 9 through 13 to verify the new value for autoExpand.

This looks like a great option to use to help you “auto-manage” you port group size if need be.

UPDATE: The procedure above is invalid.  Please refer to http://blogs.vmware.com/vsphere/2012/02/automating-auto-expand-configuration-for-a-dvportgroup-in-vsphere-5.html for a script that can implement the change.  VMware is in the process of updating the article and I will update this article as information becomes available.

Feb 10

vSphere DVS Ephemeral Port Binding: Use only in case of emergency.

Network, Tips and Tricks 2 Comments »

There is a great new document out for the Best Practices using vSphere Distributed Switches.  This is a outstanding read but it does lack some important information: which kind of port bindings you should use for your port groups.  There are a few options.  In v4.1 you can use Static, Dynamic and Ephemeral.  I will not go into the detail of each port binding type, you can read that here.

In vSphere 5 the Dynamic port binding option has been removed and only Static and Ephemeral are available.  The best practice is to use static binding for everything and only use ephemeral ports as backup port groups in case of emergency.  For all of the port groups that you have created with static binding, you should create an additional port group with the same failover order and the same VLAN settings etc.  This ephemeral port group is only to be used in case of emergency.

Here’s the scenario:  If you boot up an ESXi host and vcenter is not available, your VMs will still be able to use their existing static port.  However, if you want to make any changes to the network config of the VM and the vcenter is not available, you can change the VM to use the same “backup” port group with the ephemeral binding(or a different ephemeral group).  These port groups will be an option to choose for the VM nic even if the vCenter is down.  The other static port groups will not be available when vCenter is down.

There used to be a reason to use Ephemeral ports with VMware View configurations.  This is because in v4.x of View, when View goes to make a linked-clone pool of desktops, it does not change the static port assignment and tries to use the same port which fails.  There is even a KB Article that says to use Ephemeral bindings with View 4.x.  However, as with all Best Practices, you have to confirm they are still valid.  In the same KB article referenced above, it states to use Static Port Bindings with View 5.  View 5 handles the static port bindings correctly, even if the base image is using one.  Each time a linked clone is created it tells the clone to grab a new static port from the port group.

There also used to be a recommendation to use Ephemeral port bindings with vCloud Director for the same issues that View experienced when creating linked clones.  This has also changed with the release of vCloud Director 1.5.  vCloud Director 1.5 now automatically creates the port groups as Static and uses them correctly.

If you are using Ephemeral ports, start planning to migrate off them.  You can do this by creating an identical port group on the DVS and mark the binding as static.  You can then edit the properties of the VM’s, specifically the virtual nics and change their port group to the new one.  This will “flip” them over very quickly while only losing a ping or two.  Once all of the VM’s are plugged into the new port group, delete the old group – or save it in case of emergency.

One last reason to convert of ephemeral: there is an issue when using Ephemeral ports everyday when you have to do a host reboot.  The issue is in this KB article.  The host could free the port on boot and you may manually have to assign one.  Not a fun issue if your vCenter is the VM that needs one.

Always double-check best practices, they can change over time.

This information is based off a updated KB article which I will copy from at the time of this writing:

Note: Ephemeral Portgroups should be used only for recovery purposes when you want to provision Ports directly on host bypassing vCenter Server, not for any other case. This is true for several reasons:

  • ScalabilityAn ESX/ESXi 4.x host can support up to 1016 ephemeral Portgroups and an ESXi 5.x host can support up to 256 ephemeral Portgroups . Since ephemeral Portgroups are always pushed to hosts, this effectively is also the vCenter Server limit. For more information, see Configuration Maximums for VMware vSphere 5.0 and Configuration Maximums for VMware vSphere 4.1.
  • PerformanceEvery operation, including add-host and virtual machine power operation, is slower comparatively because ports are created/destroyed in the operation code path. Virtual machine operations are far more frequent than host-add or switch-operations, so ephemeral Ports are more demanding in general.
  • Non-persistent (that is, “ephemeral”) portsPort-level permissions and controls are lost across power cycles, so no historical context is saved.

 

 

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in