I have to say thanks to my friends Chris Colotti and Dave Hill verifying this for me. I'm currently in the middle of writing a blog post on vCloud Director networking that will talk about the creation and installation of networking components and found this little tidbit of information.

To understand what I'm talking about, you need to know what the difference is between a static portgroup and an ephemeral portgroup on a vNetwork Distributed Switch. These definitions are taken from KB Article: 1010593:

• Static Static Binding (Default): means that the dvPort is assigned to the virtual machine at configuration time. When all the ports are booked by virtual machines, it is not possible to connect to any more virtual machines, regardless of whether the connected virtual machines are powered up or not, and an error message is displayed.

• Dynamic Dynamic Binding (being deprecated): means that the dvPort is assigned at the moment of powering the virtual machine up. This option allows for over committing the number of dvPorts.

• None (Ephemeral ports): (Ephemeral Ports or No Binding) this behavior resembles the behavior in the standard vSwitch. If you select this option, the number of ports are automatically set to 0, and the Portgroup allocates one port for each connected virtual machine, up to the maximum number of ports available in the Switch.

In vCloud Director 1.0.X, any port groups that were created by vCD were given an ephemeral setting. The reason for setting it as ephemeral was to make sure that the creation and destruction of VMs didn't waste unused ports on a the vNetwork Distributed Switch. Thereby giving vCloud Director the safety net and availability to not worry about capping the dvSwitch's maximum setting or having to worry about setting the static port totals.

THIS HAS BEEN UPDATED. PLEASE VISIT VMware vSphere 5 Host NIC Network Design Layout and vSwitch Configuration [Major Update]

As vSphere has progressed, my current 6, 10, and 12 NIC designs have slowly depreciated. In an effort to update these to VMware vSphere 5, I took the 2 most popular configurations of 6 and 10 NICs and updated the Visios to make them a bit more pretty. I also don't know how much longer these will be necessary as the industry moves forward with 10GbE as a standard.

The assumption of these physical NIC designs is that these hosts are going to be configured with Enterprise Plus Licensing so all the vSphere features can be used. I didn't create a bunch of different designs as before because ideally you would want to stick with a simple design that meets a bunch of criteria for most people. In addition, I have updated these configs for performing multi-pathing for iSCSI and removing the use of etherchannel configurations because those were mostly needed on standard vSwitch configurations. I would also recommend to start moving everything over to a vNetwork Distributed Switch configuration because it is the easiest way to standardize across all of your hosts. vSphere 5 implemented a better HA and failed host policy in vSphere 5 so the use of a hybrid solution is fading as well.

Another assumption that has been depicted in every diagram is the physical switch configuration. These configurations can be done via Cisco 3750Gs with cross-stack links so it's viewed as a single switch or a single highly available enterprise switch such as a Cisco 4500 or can be implemented in a vPC configuration of dual Cisco Nexus 5000 or 7000s. The most important thing to keep in mind is that the switches in these configurations are enterprise class and you aren't connecting two switches via LACP because if you are doing that then the load teaming/balancing settings needs be re-configured.

OK readers, I've got a task I need help with. My vSphere 5 license keys don't allow me to report bugs to VMware and since I'm running vSphere on my Shuttle Boxes, they would automatically call me out on not being on the HCL. I'm asking for someone with a few minutes and a setup they can break to please test something out.

I'm currently rebuilding my lab from vSphere 5 beta build 384847 to vSphere 5 GA build 469512. vCenter is running GA build 455964. I try to mimic a 10GbE environment by using everything on 2 1GbE NICs sitting on a Virtual Distributed Switch (vDS). The issue rises when setting the MTU on the vDS to anything greater than 1500 MTU. I need to set the vDS to atleast 1524 MTU for a nested vCloud Director environment. When setting the vDS to a number greater than 1500, my iSCSI datastores all disconnect. This setup worked perfectly on vSphere 4.1 and even on vSphere 5 beta. I have a feeling that the issue is with vCenter 455964 and the vDS, but not the actual host itself because the ESXi host running build 384847 was running fine until I had to rebuild my vCenter server. The switch connecting all this is a HP ProCurve that supports Jumbo Frames and is turned on. This is all done using the hardware iSCSI initiator that is baked into my Broadcom BCM5709 NICs. So only test this if you have NICs that are capable of doing iSCSI and not utilizing the Software iSCSI Inititor provided by VMware.

VCE is announcing the latest of solutions called the AlwaysOn Point of Care Solution, creating a resilient VDI Deployment with VMware View and Vblock. This will be the ONLY HA solution from VMware once it has been given the VMware-Ready logo which is only a few short days away. This solution is geared towards the expanding market of VDI in healthcare related deployments for a desktop anywhere approach even though this will work in many different scenarios. More documents will be coming out next week at VMworld, but here is a sneak peek.

AlwaysOn utilizes Imprvata's Single Sign On (OneSign), Cisco's ACE load balancer and VMware View 4.6 with PCoIP all running on Vblock Infrastructure Platforms.

The master image is replicated between Vblocks at multiple sites using VNX storage arrays. The "golden" desktop image uses EMC's Celerra Replicator to asynchronously copy the data between sites giving an automated backup mechanism. The View Administrator can use this method to update the golden image on each site through a manual or scripted procedure. The user data is also replicated between sites for failure protection. EMC's Recoverpoint can also be used if desired. The active-active desktops are access via Imprivata's SSO with the tap of a proximity card at a Wyse thin client terminal. The users session hits a Cisco ACE load balancer to balance out the traffic between sites or will be routed to the site holding the users desktop. The user can tap into another terminal and his/her desktop will move to the new terminal with a 5-8 second delay. In a disaster scenario, Cisco's ACE will re-route all existing and new desktop sessions to a secondary site. This solution has been tested and certified in VCE labs.