One of my personally least favoured methods of creating network pools in vCD is the portgroup backed method. Why? Well, it requires you create not only VLANs at the physical world, but also pre-define the portgroups at the vSphere level as well. For me I can only see a couple of reasons why you want to take this approach.

  1. You don’t posses Enterprize+ and therefore don’t have access to the Distributed vSwitch, and/or you trying to save yourself money by using a lower-level SKU to back your vCD. Personally, I think this is false economy as you give yourself more administration (which costs valuable admin time/money).
  2. Your organizations has adopted the Cisco Nexus 1000V method of managing your networks – and you have an automated system for creating VLANs and Portgroups. Remember that Cisco Nexus 1000V needs Enterprize+

Nonetheless in my “Cloud Quest” I’m determined have configured this at least once in my time. It strikes me that without a Distributed vSwitch you would need some PowerCLI scripts in your kit bag to add new portgroups for new VLANs, and the last thing you’d want to do is use the GUI to create all of those. I decided I should at least create portgroup backed network pool so I’d done it least once in my preparation for the VCP-CLoud exam. The last time I done this was back in vCD 1.0 many moons ago when I wrote a getting started series of articles about the product.

The first thing I needed to do was get the Standard vSwitch on every ESX hosts within a cluster. That was relatively easy. You might recall I blew away the default vSwitch0 when I migrated everything over to the Distributed vSwitch. I knew to make any Standard vSwitch function I would need free up a vmnic from the Distributed vSwitch.

After connecting to the vCenter, I used simple one liner to return all the hosts managed by it (including all the hosts in my Gold & Silver) clusters. The “sort-object name” isn’t really required it just means when it runs it will process in vSphere Host name order (esx01nyc, esx02nyc and so on) which is a bit easier to read in log files and vCenter tasks/events.

(get-vmhost | sort-object name) | New-VirtualSwitch -name vSwitch0

Next I needed put portgroups on those switches for every single host:

(get-vmhost | sort-object name) | Get-VirtualSwitch -Name vSwitch | New-VirtualPortGroup -Name VLAN60 -VLANID 60

(get-vmhost | sort-object name) | Get-VirtualSwitch -Name vSwitch | New-VirtualPortGroup -Name VLAN61 -VLANID 61

(get-vmhost | sort-object name) | Get-VirtualSwitch -Name vSwitch | New-VirtualPortGroup -Name VLAN62 -VLANID 62

(get-vmhost | sort-object name) | Get-VirtualSwitch -Name vSwitch | New-VirtualPortGroup -Name VLAN63 -VLANID 63

(get-vmhost | sort-object name) | Get-VirtualSwitch -Name vSwitch | New-VirtualPortGroup -Name VLAN64 -VLANID 64

(get-vmhost | sort-object name) | Get-VirtualSwitch -Name vSwitch | New-VirtualPortGroup -Name VLAN65 -VLANID 65

Looking at the above I knew this piece of PowerCLI was a bit clunky – so I asked Alan Renouf of PowerCLIMan fame (don’t deny it Al we all know its you!) if there was a better way to achieve this – here’s what Alan supplied (thanks Mr PowerCLIMan!). Basically, this uses a range of numbers (60..65) and says for each host found with vSwitch0 create VLAN60, 61, and so on. The nice thing about this is that I can just adjust the range (60..65) to create an number of VLANs needed. I got this idea from attending Alan’s PowerCLI session at the Brussels VMUG last week. I think this approach could be used in many ways – for example setting up vmkernel portgroups that need a static IP that is in contigious order.

60..65 | Foreach {

                         $Num = $_

                         (Get-VMHost | sort-object name) | foreach {

                         New-VirtualPortGroup -VirtualSwitch (Get-VirtualSwitch -Name vSwitch0 -VMHost $_) -Name vlan$num -VLanId $num

                         }

              }

Then I mapped vmnic03 to each to the Standard vSwitch:

$vSwitch = get-virtualswitch -name vSwitch0 -vmhost (get-vmhost | sort-object name)

Set-VirtualSwitch -VirtualSwitch $vSwitch -Nic vmnic3 -Confirm:$false

This left me with an indentical Standard vSwitch configuration on each hosts (admittedly with no network redundency – but what can you meaningfully achieve with only 4 vmnic)

Screen Shot 2012-11-07 at 15.33.44.png

With this task completed, I was now all set to create the portgroup backed network pool in vCloud Director.

1. Creating the network pools is relatively easy affair – you can kick of the wizard by either selecting 4. Create another network pool from the home page or by navigating to “Manage & Monitor” tab, > Cloud Resources and Network Pools – and then hitting the + icon to kick off the wizard…

Screen Shot 2012-11-07 at 15.34.53.png

2. Next you select your vCenter

Screen Shot 2012-11-07 at 15.35.08.png

3. And then you add in the portrgoups – that point to your VLANs and add them into the pool. As I had created the vSwitch0 across ALL my vSphere hosts in both the Gold & Silver clusters these portgroups (vlan60-65) were available to both Provider vDCs

Screen Shot 2012-11-07 at 15.36.07.png

4. Finally, I had to give the portgroup backed network pool a fun, interesting and memorable name!

Screen Shot 2012-11-07 at 15.37.28.png

5. I was done. I’d created a portgroup backed network pool.

Screen Shot 2012-11-07 at 15.38.00.png

And then the next thing I did was delete it and undo all this work – because the next step was actually fixing up my vSphere hosts to work with VXLAN. The quickest way to remove the vSwitch0 was with the command:

get-vmhost | foreach (Remove-VirtualSwitch vSwitch0)

Finally, remember like “External Networks” portgroup backed network pools use just the standard allocation of ports on a portgroup of 128. This will need to be increased….