LESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/typography.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/template.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/responsive.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/k2.less

Follow Me Icons

 

Follow @KendrickColeman on TwitterConnect on LinkedInWatch My Videos on YouTubeFollow me on FacebookCheck Out My Projects on GitHubStay Up To Date with RSS

Search

BSA 728x90 Center Banner

vCloud Director 1.5 Native Port Group Change from Ephemeral to Static

I have to say thanks to my friends Chris Colotti and Dave Hill verifying this for me. I'm currently in the middle of writing a blog post on vCloud Director networking that will talk about the creation and installation of networking components and found this little tidbit of information.

 

To understand what I'm talking about, you need to know what the difference is between a static portgroup and an ephemeral portgroup on a vNetwork Distributed Switch. These definitions are taken from KB Article: 1010593:

  • Static Static Binding (Default): means that the dvPort is assigned to the virtual machine at configuration time. When all the ports are booked by virtual machines, it is not possible to connect to any more virtual machines, regardless of whether the connected virtual machines are powered up or not, and an error message is displayed.
  • Dynamic Dynamic Binding (being deprecated): means that the dvPort is assigned at the moment of powering the virtual machine up. This option allows for over committing the number of dvPorts.
  • None (Ephemeral ports): (Ephemeral Ports or No Binding) this behavior resembles the behavior in the standard vSwitch. If you select this option, the number of ports are automatically set to 0, and the Portgroup allocates one port for each connected virtual machine, up to the maximum number of ports available in the Switch.

 

In vCloud Director 1.0.X, any port groups that were created by vCD were given an ephemeral setting. The reason for setting it as ephemeral was to make sure that the creation and destruction of VMs didn't waste unused ports on a the vNetwork Distributed Switch. Thereby giving vCloud Director the safety net and availability to not worry about capping the dvSwitch's maximum setting or having to worry about setting the static port totals.

 

vCloud Director 1.5 made a change. No longer are portgroups created by vCD set to ephemeral, but instead are set to static. This is a good thing and I'll explain why.

 

There is a little unknown thing about ephemeral port groups, and that is the lack of security compared to static. Taken from a quote by Tomas Fojta: "The disadvantage is that if you configure ephemeral port binding your network will be less secure. Anybody who will gain host access can create rogue virtual machine and place it on the network or to move VMs between networks. The security hardening guide even recommends to lower the number of ports for each distributed portgroup so there are none unused." Granted, I have personally never tried this sort of attack but it's a known flaw.

 

The behavior of a static port group is a bit different in vCloud than in vSphere. Within vSphere, when you assign a VM to a static port group, the VM gets pinned to a port even if the VM is turned off. In vCloud Director, a static port group emulates an ephemeral port group by only pinning a VM to a port when the VM actually get's powered on. During a power on sequence of a VM in a vApp, the VM gets reconfigured by vCloud to add itself to a portgroup association. After powering off the VM, the VM is reconfigured by vCloud to remove itself from a portgroup thereby releasing the port binding.

 

Now for the fun stuff... I created an external organization network within vCloud Director.

 

This external network automatically deployed a new port group and a vShield Edge device. As you can see from the image, this port group is automatically configured as static with 10 total ports and 9 available ports. 1 port has been used by the vShield Edge appliance.

 

I went ahead and created a new vApp with 12 VMs and set it on that external organization network.

 

As the VMs were being powered on, you could see the available ports dropping down all the way to 0.

 

Once 0 hit, the total amount of ports increased by 10, to 20 total ports and giving me an total amount of ports of 7 remaining.

 

To demonstrate what I was talking about earlier. I'm now going to stop the vApp.

 

Notice that the ports have been released and the portgroup has 19 available ports.

 

What happens when I delete the vApp containing 12 VMs?

 

Well nothing happened to the total amount of ports on the portgroup. It continues to stay at 20 ports.

 

Moral of the story is that vCloud Director is now utilizing the security of a static portgroup while still being flexible like ephemeral. The only thing that you need to be concerned with is the over allocation of total ports when perhaps they aren't needed. But since vCloud will reconfigure a VM to unbind from a port when it is turned off, this allows you to scale your environment better.

 

*quick update* from @sachin_t : actually it's driven by the version of the VC attached - not necessarily the vCD version, although that matters too. to be more specific in 5.0 they use static binding with the auto expand flag (introduced in 5.0). 4.1 is ephemeral

Related Items

Related Tags

LESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/styles/blue.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/styles/green.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/styles/orange.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/styles/purple.less