Home > Business Critical Applications, VMware > vSphere 5 and vShield 5 Critical Considerations

vSphere 5 and vShield 5 Critical Considerations

vSphere 5.0 introduces some great enhancements to host profiles and the ability to quickly and automatcially deploy new hosts (both stateful and stateless), which will be especially attractive to enterprise customers. These new features present some unique challenges and considerations for customers that are using or are thinking of deploying the VMware vShield Suite of products as part of their virtualization security strategy.  In this article I’ll briefly discuss some things you must consider to successfully deploy both vSphere 5.0 and vShield App and Endpoint.

Before I get started this article assumes you have a basic understanding of the new Image Builder, Auto Deploy, and Host Profile features of vSphere 5.0. If you’re not currently familiar with these features at a basic level it would pay to read up on them. They are excellent features and will be very useful in many vSphere 5.0 environments. These are the features with the biggest impact on a design and implementation of vSphere 5.0 in combination with vShield App and Endpiont.

First I have to give you some bad news. vShield App and vShield Endpoint are not  supported in combination with AutoDeployed Stateless ESXi 5.0 hosts with vShield v5.0. The reason for this is that the vmkernel modules that both App and Endpoint rely on are not available as VIB packages with v5.0 that can be added to ImageBuilder Image Profiles that can then be deployed with AutoDeploy for stateless hosts that will be PXE booted.  VMware has just released an updated version of vShield, v5.0.1 that does support the vShield VIB packages being loaded into an Image Builder Profile and used for AutoDeploy. If you wish to use AutoDeploy I would strongly encourage you to update to vShield 5.0.1.

You will have no problem deploying vShield App and Endpoint modules to stateful ESXi 5.0 hosts and they will survive a reboot. However this process has some important implications to the way you use host profiles. After installing vShield App or Endpoint (or both) you won’t be able to use the original host profile any longer that you used to do the initial configuration of the host. This is because the specific vShield App and vShield Endpoint settings will be missing from the original host profile.

Your host might work fine for a while with the original host profile, but you’ll soon find as soon as you reboot your host that vShield components no longer work. This is because the original host profile has been reapplied after the reboot and overwritten the vShield configuration on your host. To ensure that your vShield components host configuration is retained on the next reboot you will need to ensure that you you detatch your host from it’s original build host profile after the initial deployment is complete and create a new host profile that includes the vShield component settings.

So the install process including vShield App or Endpoint is described below. This assumes you already have a suitable host profile created for the base host build.

  1. Deploy your new Host “X” (using whichever method you choose) using Host Profile “Y”, which is your initial host profile.
  2. Install vShield App or Endpoint on Host “X”.
  3. Use Host “X” to create a new Host Profile “Z”. Host Profile “Z” will be a combination of Host Profile “Y” and the vShield specific configurations.
  4. Detatch Host “X” from Host Profile “Y” and then attach it to Host Profile “Z”. Host Profile “Z” will then be used for the host during subsequent reboots.

The uninstall process uses steps 2 and 4 above in reverse order as follows:

  1. Detatch Host “X” from Host Profile “Z” and then attach it to Host Profile “Y”. Host Profile “Y”, which is the original profile used during the build, will be used for subsequent reboots.
  2. Uninstall vShield components from Host “X”. This will involve putting the host into maintenance mode and rebooting the host.
  3. When the host reboots it will be back in the original state.

Now some of you might be wondering why I didn’t mention vShield Edge. This is because vShield Edge doesn’t require any vmkernel modules be deployed in order to function. So it will work fine regardless if the hosts are stateful or stateless. This is great news given that vShield Edge and Auto Deploy are incredibly useful for public cloud providers based on VMware vCloud Director. For more information on this configuration check out Auto Deploy and vCloud Director by Alan Renouf.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.comBy Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Advertisements
  1. Shane White
    January 13, 2012 at 1:48 pm

    Michael,
    Does this apply to vShield 5 on ESXi 4.1, or only for ESXi 5?
    Thanks.
    Shane.

    • January 13, 2012 at 8:51 pm

      Hi Shane, Only vShield 5.0 on vSphere 5.0. The reason is due to the enhancements that were made to host profiles in vSphere 5.0 to support AutoDeploy and additional build process and compliance automation.

  2. April 19, 2012 at 11:58 pm

    Great article, I was worrying that the VIB packages wouldn’t be compatible for usage with auto deploy host profiles.

  1. March 16, 2012 at 7:28 pm

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: