How to maintain a the same MAC address all the time within your vSphere 4 installation.

In VMware vSphere 4 environement, when you move your VM to another host or the VM has different path on the same host, the MAC adress of the VM is changed.
If you want to guarantee that the same MAC address is assigned to a given virtual machine every time, even if the virtual machine is moved, or if you want to guarantee a unique MAC address for each virtual machine within a networked environment you have 2 choices. You can do it on the VM configuration level or you can do it on the guest level.
On the VM level you can do it via GUI or by editing your VMX file (just make sure that you unregister the VM from vCenter first, otherwise vCenter will overwrite the value) you go to Menu VM > Edit Settings > Network Adapter and you set the radio button on Manual. Then you can assign a static MAC address there between the authorised range by VMware. The MAC address range is:
00:50:56:00:00:00-00:50:56:3F:FF:FF

If in some rare cases you need to keep the same MAC as for exaple on your Physical server (for some software license files tightened to a MAC address for exemple), and the MAC adress is outside of the range, you have the possibility to do it inside of your Windows (linux) VM.
On the Windows VM you do it in the properties of your NIC:
Start the VM and in the Windows system go to Control panel > network connections > Properties

Click the Configure button and go to Advanced Tab where on selecting Locally administered value you are able to enter your own value.

And for linux VM you can try this:
ifconfig eth0 down
ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx
ifconfig eth0 up
There is reference webpage I found about MAC addresses ranges on VMware’s Website here. The page is is for VMware ESX Server 2.1, but it’s still valuable… There might be other resources on that, feel free to post a comment…

Source : www.vladan.fr Feeds

Feature Compare vSwitch 3.5, vSwitch 4.0, dVswitch 4.0, Cisco Nexus 1000

The following Table is a list of the key features of VMware vNetwork Distributed Switch. For a comprehensive list of VMware vSphere features download the key features summary.

Simplify and Enhance Virtual Machine Networking

• Simplified provisioning and administration of virtual networking across many hosts and clusters through a centralized interface.
• Simplified end-to-end physical and virtual network management through third-party virtual switch extensions for the Cisco Nexus 1000V virtual switch.
• Enhanced provisioning and traffic management capabilities through private VLAN support and bi-directional virtual machine rate-limiting.
• Enhanced security and monitoring for virtual machines migrated via VMware VMotion through maintenance and migration of port runtime state.

Click below --> Read More for Full Article..

Load-balancing Methods (I prefer to call Teaming Methods) --> 1) Originating Port ID Based 2) MAC Hash Based 3) IP Hash Based - Which is best, in real & what supports Actual Load Balance????

Now that we understand the basics, we will move on to the topic at hand, NIC Teaming. Although you can team vNIC's within a VM, we are not going to discuss OS vNIC teaming, but rather physical NIC teaming. You may be wondering why someone would want to team physical NIC's? Well why not! Teaming the NIC's will not only eliminate the single point of failure associated with a single physical NIC, but also provide better overall network throughput - what's not to like!?!

ESX offers 3 different methods for load balancing. However, not all methods are created equal, and only one method offers true load distribution. The 3 load-balancing methods include:

• Route based on the originating port ID (this is the default if not defined otherwise) - Also know as vSwitch port-based load-balancing, this method chooses an uplink based on the virtual port where the traffic entered the virtual switch.

• Route based on source MAC hash - This method chooses an uplink based on a hash of the source Ethernet address.

• Route based on IP hash - This method chooses an uplink based on a hash of the source and destination IP address of each packet.

Click below --> Read More for Full Article (Which one will give Real Load Balancing)

Online Training - How to Configure VMware dvPortGroup + Cisco Switch + Private VLAN IDs + Trunking

Source - www.NTpro.nl

• This presentation will lead you trough configuring VLAN IDs at both the vSphere environment and on the physical Cisco switch.

• You’ll get a good understanding of trunking on a Cisco switch and dvPortGroup Settings.

• At the end you’re able to configure a Cisco switch using Cisco’s Network Assistant and understand the different dvPortGroup Settings.

Below Video is about for 40 minutes.  (right click on video for Full Screen)



Online Training - Configure Private VLAN IDs from Eric Sloof NTPRO.NL on Vimeo.

How CDP (Cisco Discovery Protocol) will benefit you to identify *** Which NIC connected to what External Device on ESX ***

Source : VMware KB and www.vmetc.com 
 

This is a handy little trick, starting with version 3.5, VMware added support for Cisco Discovery Protocol (CDP) on the ESX Server vSwitches. CDP support is enabled on a vSwitch with this command:

Verify the current CDP setting for vSwitch2
ESX# esxcfg-vswitch -b vSwitch2 

down 

The above output is down - which indicates CDP is currently not enabled vSwitch2  

To enable CDP on vSwitch2

ESX# esxcfg-vswitch -B both vSwitch2

To Verify the CDP Status (Expect -> Down, Listen, Advertise, Both)

ESX# esxcfg-vswitch -b vSwitch2

Both

Check CDP information on Physical Switch

Once CDP support is enabled on the vSwitch & physical switch - execute below command on Phy.Switch. Which will show the link between each physical switch port and the matching ESX Server NIC. The output will look something like this:

# show cdp neighbor 

 Capability Codes: R-Router, T-Trans Bridge, B-Source Route Bridge

                  S-Switch, H-Host, I-IGMP, r-Repeater, P-Phone

DeviceID  Local Intrfce  Holdtme  Capability  Platform      Port ID

s3        Gig   0/26        147      T S    WS-C3524-XFas 0/24

esx04     Gig   0/22        168       S     VMware        ESXvmnic0

esx04     Gig   0/21        168       S     VMware        ESXvmnic1

As you can see in the output above, the CDP output clearly links the physical switch port and the ESX Server NIC. This makes it incredibly easy to identify the NICs in the server. This is particularly helpful in blade situations, since you can’t exactly unplug the NIC and see which one goes down with “esxcfg-nics -l” (a common approach to identifying the NICs in the server). Of course, this requires CDP switches in the blade chassis. Since the internal port mappings on the blade chassis determine which NICs connect to which ports, this command adds the mapping within ESX Server and lets us quickly and definitively identify the NICs in the server as seen by ESX Server.

Check CDP information in VI Client

Now, using the VI Client you can go to the Configuration tab of a host and select Networking. To the right of each vSwitch is what I’ll describe as a dialogue icon.

Clicking this Call out icon (Green circle) brings up the switch port info you are seeking.

Cisco Nexus 1000V Switch Seminar Series

The Cisco Nexus 1000V Switch delivers VN-Link services to virtual machines hosted on its server. It takes advantage of the VMware vSphere framework to offer tight integration between server and network environments, and to help ensure consistent, policy-based network capabilities to all servers in your data center.

Learn more about this software switch at the Nexus 1000V Switch Spring 2010 Seminar Series. The series has two tracks: Sales and Technical.

Topics include:

• Nexus 1000V Switch Business Impact and Return on Investment
• Basic Nexus 1000V Switch Features
• Accelerating Data Center Virtualization with Nexus 1000V Switch
• Advanced Nexus 1000V Switch Features
• Nexus 1000V Customer Panel
• Virtualize DMZ with Nexus 1000V Switch
• Analyst Panel Roundtable Discussion: Nexus 1000V Switch
• Approach Payment Card Industry (PCI) Compliance with Nexus 1000V Switch
• Ecosystem Partners & Products
• VN-Link and the Future of Virtual Networking
• Channel Partner Roundtable Discussion
• Interoperability with VMware Products
• Infrastructure as a Service Reference Architecture
• Cisco Nexus 1010 Virtual Services Appliance
• Advanced Networking in a Virtualized Environment

Enabling CDP on a vSwitch? What will the Cisco admin see...

Enabling CDP on a vSwitch? What will the Cisco admin see...

from NTPRO.NL - Eric Sloof by nospam@example.com (Eric Sloof)

It’s possible to configure the ESX host's virtual switches so the Cisco Discovery Protocol on a standard or distributed switch is issuing broadcasts containing some of your ESX host's information. After enabling the CDP on your ESX server, the Cisco administrator is able to listen for information broadcasted by your ESX host but what can he actually see? To find out I’ve installed the Tallsoft’s Cisco CDP Monitor on my vCenter server.

With Cisco CDP Monitor, you can display the information of the connecting Cisco devices, such as device names, device models, connecting port , administrative ip address, IOS version, VTP Domain Name, and so on. With this information, one could easily learn the total topology of the complete network and do troubleshooting. Once the Cisco Discovery Protocol information changes (such as the link or device failed, or the setup of Cisco device changed), Cisco CDP Monitor will detect it and will display the related info. It also shows information broadcasted by you ESX servers.

Virtual switches can be configured for four different CDP modes of operation:

Down – CDP information is neither sent nor received
Listen – CDP information is received from the physical switches
Advertise – CDP information is sent to the physical switches
Both – CDP information is sent to and received from the physical switches
For enabling CDP on standard switches you have to use command-line interface. CDP can be enabled on distributed switches using the vSphere Client. Here’s the info I was able to retrieve from an ESX host after running “esxcfg-vswitch -B both vSwitch0” in the service console.

Neigbour1:
device id: esx4-l.ntpro.local
ipaddress: 0.0.0.0
port: vmnic0
capabilities: Switch
ios_version: Releasebuild-208167
platform: VMware ESX
prefix:
vtp_domain:
native_vlan:
duplex: full

NIC teaming in ESX Server

NIC teaming in ESX Server

(Extracted from VMware KB Article: 1004088)

Purpose

This article discusses how to configure NIC teaming. A NIC team can share the load of traffic between physical and virtual networks among some or all of its members, as well as provide passive failover in the event of a hardware failure or a network outage.

Resolution

To utilize NIC teaming, two or more network adapters must be uplinked to a virtual switch. The main advantages of NIC teaming are:

• 
  
  Increased network capacity for the virtual switch hosting the team.
• 
  
  Passive failover in the event one of the adapters in the team goes down.

To configure NIC teaming using the Virtual Infrastructure Client:

1. 
   
   Highlight the host and click on the Configuration tab.
2. 
   
   Click the Networking link.
3. 
   
   Click Properties next to the virtual switch.
4. 
   
   On the Ports tab, highlight the name of the virtual switch and click Add.
5. 
   
   Select the appropriate network adapters and click Next.
6. 
   
   Ensure the selected adapters are under Active Adapters.
7. 
   
   Click Next.
8. 
   
   Click Finish.
9. 
   
   On the Ports tab, highlight the name of the virtual switch and click Edit.
10. 
    
    Click the NIC Teaming tab.
11. 
    
    The default load balancing policy is Route based on the originating virtual port ID. If the physical switch is using link aggregation, Route based on IP hash load balancing must be used. For more information, see ESX Server requirements for link aggregation (1001938).

Additional Information

Sample environment using four network adapters:

Virtual switch Portgroup # Uplinks

1 Service Console 1

2 Virtual Machine 2

3 Vmotion 1

The NIC team used for the virtual machine network provides extra capacity as well as failover and keeps the portgroup connected to the network if one of the network adapters fails. The VMotion uplink is ideally connected to its own subnet along with other ESX Server host's VMotion ports to separate its traffic from the virtual machine and Service Console traffic and maximize performance.

An additional network adapter can be uplinked to virtual switch 1 to provide for failover on the Service Console (management) interface, or to a new virtual switch 4 to provide for iSCSI or NFS storage (ideally on its own subnet).