VI Team Blog

What is the new news?

In VMware Infrastructure version 3.5 we introduced Storage VMotion, which does a live migration of virtual machine disk files from one storage location to another without any disruption or downtime to virtual machines and applications. Although Storage VMotion is designed to work with any type of storage, it was initially supported only with Fibre Channel SANs. As of Update 1, Storage VMotion is supported with iSCSI SAN’s for moving virtual machine disk files in the following scenarios:

- From iSCSI SANs to other iSCSI SANs

- From iSCSI SANs to FibreChannel SANs

- From FibreChannel SANs to iSCSI SANs
 
In addition, we now support the use of 10Gb Ethernet for iSCSI in a VMware Infrastructure environment.

What does this mean for users?

It means that you have the ability to optimize and update your storage environment whenever you need, without downtime to your applications. You can make sure that your virtual machines are always on the storage that meets your needs—regardless of how you first deploy your virtual machines, you can change the configuration of your storage and the type of storage (whether FibreChannel or iSCSI) as you need without disrupting your running virtual machines and applications. With Storage VMotion you can do any of the following without downtime:

• Move virtual machines to a new array when you upgrade or refresh an array
• Move virtual machine disks to a different tier of storage as their needs change
• Troubleshoot and solve performance problems caused by storage misconfiguration or too      much load on a particular LUN 

Adding support for 10GB Ethernet for iSCSI means that you can continue to ensure that your iSCSI SAN deployment meets your performance requirements even as your virtual environment continues to scale up and your demands for storage networking bandwidth continue to grow.

The world of networking is often unfamiliar territory for server and VMware Infrastructure (VI) admins. In most enterprises, networking is the responsibility of a dedicated team of networking experts who may be unfamiliar with the world of server virtualization. So how does a VI admin approach networking? How does he or she say to the networking folks, “I want to roll out VI across these hosts and I need them all connected to the production network.”

First up, involve the network team early and provide them with some information on how VI networking works. A good place to start is the VMware Virtual Networking Concepts paper at http://www.vmware.com/resources/techresources/997 This paper covers the essentials of VI networking: what is a vSwitch? How do I use VLANs? What are my options for NIC teaming, and so on? A network admin will find the concepts presented quite familiar. vSwitches (virtual switches) are very similar to L2 physical switches. Having the network folks read this paper will help put you all on the same page.

Next, talk about the application requirements. In almost all cases, you will want to separate all the traffic by type. 802.1Q VLAN tagging to the vSwitch (Virtual Switch Tagging) is the most common and recommended practice for scaling and separating traffic with restriction from the number of physical NICs. Management/Service Console (SC), VMotion, iSCSI, NFS, and VM traffic in most cases should be separated through the use of VLANs and appropriate NIC teaming policies. The network folks will look after and allocate the VLAN numbering (and may talk about avoiding VLAN 1 and use of native VLANs, etc).

NIC teaming gives you the two-fold benefit of maximizing the use of the host NICs while protecting against NIC, switch of link failures. The most common (and best practice method for guest VMs) is to select “originating virtual port-id” in the port group definition. This spreads the load over the available links in the NIC team—each guest VM hashes to one of the physical NICs (vmnics). Should a link, NIC or switch failure occur, traffic is forwarded over the remaining links in the team. Spreading the links over two physical switches protects the host against network failure, thereby maximizing availability. All that is required from a network admin standpoint is L2 continuity between the switches.

But, what about spanning tree protocol (STP), I hear someone say? Doesn’t this create a loop? vSwitches do not participate in STP. They don’t consume, forward or produce BPDUs. The other thing is, any frame received on a vmnic uplink is never forwarded out another uplink. This means we can connect our uplinks to different switches without causing any loops and avoiding the wasteful STP property of causing links to block (to avoid loops). You do not need to disable STP on the adjacent physical switch ports, but enable trunkfast or portfast to bypass the learning and listening phases of STP upon the link becoming active.

In summary, the concepts aren’t that complex, but you do need to understand how the pieces fit together.

There are many other networking topics to cover and we have quite a rich list of content coming out to help you with understanding and deploying VI networking. Look out for the VI Networking blog at blogs.vmware.com/networking starting this week.

If there is something you think I need to cover, let me know. Email me at guy@vmware.com