Yellow Bricks

by Duncan Epping

networking

Back to Basics: Using the vSphere 5.1 Web Client to configure a vSwitch

· ·

In the previous articles we created a Datacenter, a cluster and added hosts to it. Now that we have done that we can start finalizing the configuration. This is just one example out of the many ways to configure networking for an ESXi host, and I kept it really really simple. This is not following any best practices, I just wanted to show some of the steps. In this scenario I have 4 network cards per host and I have VLANs for each network segment. Separating traffic through the use of VLAN is highly recommended and is a best practice.

Lets configure the virtual switch first. I will use a “standard vSwitch” for now. In this case we will set all vmnics to active on the vSwitch and control NIC usage on a portgroup level. [Read more…] about Back to Basics: Using the vSphere 5.1 Web Client to configure a vSwitch

vSphere 5.1 networking enhancements

· ·

There are many networking enhancement in vSphere 5.1 but I want to call out a couple specifically. The reason for this is that there have been many discussions on this blog about “hybrid VSS / VDS” environments as many were not comfortable with running everything on a VDS. Although the risks were minimal I could understand where people were coming from. So what’s new in this space?

  1. Management network rollback and recovery
  2. VDS config backup and restore
  3. Network health check

Management Network rollback / recovery says it all I guess. I for whatever reason you made changes that will result in your host not being able to connect to vCenter then this change will not be committed. Even more importantly, if you ever end up in the situation where your host is not able to connect to the network while using a VDS you can now reconfigure it through the DCUI (Network Restore Options). I played around with it, and I think it is a huge enhancement. I don’t see a reason to go hybrid any longer… go full VDS!

Another often heard complaint was around export/import of the VDS config or backup/restore. With vSphere 5.1 this ability is now added. Not only can you save the VDS config and use it for new VDS’s but you can of course also use this feature for backup purposes (see screenshot below). Another cool feature is that if you made a change to a portgroup that was not what you intended you can actually roll it back.

Last but not least is the “Network Health Check” option. I particularly like this feature as I’ve been in the situation many times in the past that changes were made on a physical level and people forgot to inform me about it. This will allow you to quickly identify when things changed and that will make the discussion with your networking colleagues a lot easier. In this release three things are checked:

  • VLAN
  • MTU
  • Network adapter teaming

These checks will be done every minute, and is done by sending probing packets on the VDS uplinks. If for whatever reason these probing packets fail it could indicate that the config of the physical components have changed. Nice right… I am not going to reveal any more secrets as I am guessing Venky will be writing some deepdive stuff soon.

In the mean while, for more details around what’s new I would like to refer to the great what’s new paper that Venky Deshpande wrote: What’s New for Network in vSphere 5.1.

Using Storage IO Control and Network IO Control together?

· ·

I had a question today from someone who asked if there was any point in enabling SIOC (Storage IO Control) when you have NIOC (Network IO Control) enabled and configured. Lets start with the answer: Yes there is! NIOC controls traffic on a single NIC port level. In other words, when you have 10GbE NIC ports and vMotion, VMs and NFS (for instance) use the same NIC port it will prevent one of the streams from claiming all bandwidth while others need it. It basically is the police officer who controls a group of people getting too loud in a single room.

As not many people realize this lets repeat it… NIOC controls traffic on a NIC port level. Not on a NIC pair, not on a host level and not on a cluster wide level. On a NIC port level!

SIOC does IO control on a Datastore-VM layer. Meaning that when a certain threshold is reached it will determine on a datastore wide level which hosts and essentially which VMs get a specific chunk of the resources. SIOC prevents a single VM from claiming all IO resources for a datastore in a cluster. SIOC is cluster wide on a datastore level! It basically is the police officer who asks your neighbor to tone it down when as he is bothering the rest of the street.

Yes, enabling SIOC and NIOC together makes a lot of sense!

Ephemeral ports?

· ·

A couple of days ago one of my colleagues released an article about Ephemeral Ports. The article explains about how Ephemeral ports could be used as a “backup” when vCenter is down. The summary of the article is in my opinion the paragraph I quoted below.

If the inability to quickly provision a new VM or to reconnect a vNIC while vCenter Server is unavailable has kept you from considering a pure vDS network architecture, ephemeral port groups may be a suitable safety net.  You would not even need to use ephemeral port groups for production virtual networks — simply create a few to have as backups for accessing the most critical VLANs.

This started a discussion internally as the default setting is not Ephemeral but Static. So the question that this resulted in was should we define a new standard or are the “Static” port binding just as good as Ephemeral? I believe that many people are hesitant of using a pure vDS infrastructure due to the inability to make changes to the vDS when vCenter would be unavailable. This applies to both ephemeral and static however and actually leads to another point, which we won’t discuss now, vCenter resiliency. Now, from a virtual machine perspective even if vCenter is down, and Static is used as the port bindings, the virtual machine can be powered on and off. With Static all ports are pre-defined on the host level and when a virtual machine is assigned a port it can consume it. Now the difference between Ephemeral and Static is that Ephemeral allows you to assign “new ports” to new virtual nics or virtual machines. I guess the question is how often do you make changes to the network of your virtual machines when vCenter is down and what type of changes?

Seriously, do we really want to make substantial changes to our environment when our management platform is not available? I believe we shouldn’t and I also feel that Static portgroups are the way forward, they have more or less the same level of flexibility Ephemeral have and on top of that Static offers a lot of advantages from a scaling perspective!