We are now onto the second stage of the VMware vSphere Blogging contest, the winner of week one’s FT subject was Hany Michael from http://www.hypervizor.com/ you can read his post here >> http://www.hypervizor.com/2009/09/vsphere-40-fault-tolerance-architecture-diagram-video-and-use-cases/ you can also get the full run down from VMware on the vSphere blog here >> http://blogs.vmware.com/vsphere/ Congratulations to Hany for the win it was well deserved.
Moving onto the next subject vNetwork Distributed Switches, there is already a lot of information regarding the vNetwork Distributed Switches, including a very good white paper by VMware which I have linked to at the end and numerous videos and how to blogs. I have decided to make my blog post more of a guide for potential new users / customers and pass on my thoughts on using vNetwork Distributed Switches.
The vNetwork Distributed Switches vDS for short allows you to configure a single virtual switch to span multiple hosts, so you would be correct in thinking that this means you no longer need to create your virtual machine port groups on all your hosts, saving you time and taking the risk out of accidently spelling one wrong and causing issues for vMotion / HA. The vNetwork Distributed is a feature that is only available to those with vSphere Enterprise plus licensing.
vDS also introduces a number of other features these are :-
• Private VLANs
• Network VMotion—tracking of VM networking state, improving troubleshooting and enabling
• 3rd Party Virtual Switch support with the Cisco Nexus 1000V Series Virtual Switch
• Bi-directional traffic shaping
You did read that third item right, you can now have a Cisco switch as your virtual switch, the Cisco Nexus 1000V is an optional extra that you can purchase that allows you to have a Cisco switch inside your virtual infrastructure, a must have for any large company with Cisco networking throughout. The VMware administrator can now pass the networking back to the networking team, they can now manage the virtual networking in exactly the same way as they do the physical, much to the relief of the networking team who were always probably a bit concerned with the virtual aspect of the network and possibly open the world of virtualisation to some customers who haven’t been able to proceed for this reason.
Network vMotion allows counters and statistics regarding the virtual machine to move with the machine when it is vMotion’ed this ensures monitoring and troubleshooting is a lot easier for machines that are being moved by vmotion.
There are two main concepts to understand about vNetwork Distributed Switches these are
Distributed Virtual Port Groups (Left Side of image below) Much like the port groups on your standard virtual switches, these are port groups on the vDS that specify port configuration.
Distributed Virtual Uplinks (Right Side of image below) This is a new concept the Distributed Virtual Uplinks contain the physical NICs that will act as uplinks on your hosts, from here you can configure NIC teaming, load balancing and failover policies.
If the configuration for some reason differs on one of your hosts maybe due to downtime due to a fault or other host issues you will receive a warning making you aware of this issue.
When the host then becomes available again the settings will be automatically updated on that host.
When deploying a vDS you are able to automate the configuration of your hosts by using host profiles. This will also allow you to check compliance of your hosts at any time and quickly add new hosts in the future.
My Preference…
My preference when using vDS is to run in a hybrid mode, keeping the service consoles and vmKernel as a standard switch and moving all the Virtual Machine Port groups to a vDS. This means I handle the service console and vmKernel at installation the same as usual then add my host to the vDS, when I then find the need to add a new portgroup to my hosts I have only got to configure it in one place. In large environments this saves considerable amounts of time and the potential for error.
Although running with the service console and vmKernel as part of the vDS is a fully supported configuration and what a number of people would do, indeed in an environment with less physical NICs this would be what I would choose to do.
I have updated my VCP in vSphere Cue Cards with some key information on vSphere networking to assist you with studying towards the new VCP. These can be found here >> https://virtualisedreality.wordpress.com/vcp-in-vsphere-4-0-study-notes/
If you are considering using vDS’s or would like more information the following white paper from VMware is a must read! >> VMware® vNetwork Distributed Switch Migration and Conguration
Virtualised Reality 
this is a newbie question for Hybrid:
1. what happen if i use vSS with vmkernel and SC then I also create vDS for VM Network Group and also with vmkernel and SC? Just checking if I may accidentally encounter this scenario.
2. in addition, if I implement the hybrid mode and suddenly vCenter crash (i only have 1 vcenter). Will my VM still runs? for how many days max? What is the other solution or alternative access my vm’s network why I recover my vCenter? Can I re-create new vcenter and restore the DB backup, do i still recover my vDS configs?