Section 2 of the blueprint is a pretty big one, and some of the pieces warranted their own post – however there are a lot of small little skills that don’t really require a complete tutorial so I thought I would just slam them all in here!
Determine use cases for and apply Port Binding settings
vSphere offers three types of port binding in their vSwitch settings (Distributed Virtual Switch only)– all of which are explained below
- Static – the port will be assigned immediately on connection to the vSwitch. The VM will stay connected to this port even when it’s powered off. The only way to free up the port is to explicitly remove the NIC from the VM. Static Ports are managed through vCenter Server
- Dynamic – Port is connected when the VM is powered on and then disconnected when the VM is powered off. Dynamic ports are managed through vCenter Server. This method has been depreciated in vSphere 5.x
- Ephemeral – Both static and dynamic port binding has a set number of ports, in ephemeral, the ports are actually created and destroyed on the VM power on/power off event therefore requiring a bit more overhead. That said, these are managed by the host, therefore, networking can still be connected/disconnected in the event that vCenter Server is unavailable.
Choosing a port binding method is pretty easy – Right click on your port group, chose edit settings and it should be front and centre in the General section.
As far as use-cases go, really ephemeral only needs to be used in recovery purposes since they are a bit more demanding in terms of overhead. Also, ephemeral does not maintain port-level permissions and controls when a VM is rebooted, since the port will be destroyed and recreated. For the most part it’s best to use Static port binding – and since 5.0 offers an auto expand feature to dynamically grow the number of ports by a specified interval, you shouldn’t have to worry about running out of ports.
Command Line goodness
The networking section references the ability to use command line tools to manage both standard and distributed virtual switches. Obviously I can’t go over every command and every switch. Just be sure to know how to use esxcfg-vswitch, esxcfg-vmknic, esxcfg-route, the networking namespaces in esxcli, as well as some of the PowerCLI cmdlets around networking (Get-VirtualSwitch, Get-NetworkAdapter, Get-VMHostNetwork, etc).
Hint – for the PowerShell command line stuff you can quickly find the PowerCLI commands associated with networking (or anything for the matter) by utilizing the Get-VICommand cmdlet and passing a search string. IE, to return all cmdlets containing ‘net’ you can use the following
|
1 |
Get-VICommand –Name *Net* |
Determine use cases for and applying VMware DirectPath I/O
I’ve never used DPIO – that said, there it is on the blueprint so I’d better figure it out. As for use cases, honestly I haven’t seen many. For the most part utilizing the virtualized hardware seems to perform well enough, but if you need the tiny bit performance improvement it claims to provide there are a couple of steps to get it running.
First up we need to configure pass-through on the host itself. This is done on the Configuration tab under ‘Advanced Settings’. Simply select ‘Configure Pass-through’ and select the device you want to present to a VM.
Once you are done this you will need to restart the host in order to complete the next step, so go ahead and do that.
As for presenting the pass-through device to the VM this is done just as you would do any other piece of hardware (In ‘Edit Settings’ of a VM). Simply select PCI Device as your hardware and follow the wizard. You should see your device that you had setup for pass-through earlier in the dropdown box as shown below.
From here you will need to ensure that your guest OS has the correct drivers in order to install this hardware as it is presented directly to the VM. Aside from creating a memory reservation on your VM there are also a ton of features that are unavailable when you utilize DPIO. Things such as vMotion, HA, DRS, Snapshots, Hot add, Fault tolerance are all not supported – probably why there is such low adoption.
And I think that should just about wrap up networking. There is some teaming information mentioned, but honestly I find this to be VCP level knowledge and I’m just going to assume you already know it 🙂 Good Luck!
