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.

With vSphere 5 comes a new virtual machine hardware version... version 8. The vCPU configuration has changed a bit in the new layout and you can totally see why. When creating a new VM, or editing virtual machine hardware, you can now choose a virtual socket and core allocation to the VM instead of just choosing a "vCPU count".

The amount of vCPU's you can distribute is based on the amount of physical cores available on the host. For instance, I have a single Quad Core Intel chip on each of my home lab servers. That means a VM can be configured with up to 4 available vCPUs in an array of different options. Why would VMware do this?? For application licensing of course! If you have an application that needs some horsepower but is licensed by the socket, no difference if it is virtual or physical, you can get around that by applying multiple cores to a single socket. Think about the money you could save moving from a 12 vCPU VM in vSphere 4 with 12 licensed sockets to a single vCPU socket with 12 cores in vSphere 5!

Add a comment