Yellow Bricks

by Duncan Epping

vshield

Upgrade vCloud Director 1.5 on vSphere 5.1 to vCD 5.1.1?

· ·

One of my colleagues, Matthew Meyer, posted a list of cool videos he produced. These videos show how to upgrade vCloud Director 1.5 on vSphere 5.0 to vCloud Director 5.1.1 running on vSphere 5.1.  Nice right?! Thanks Matt for creating these, awesome work. (I normally don’t use the “read more” option, but as there are 8 videos in total I will only show two on the front page. Hit “Continue Reading” if you want to see the rest!)

VMware vCenter Server 5.0 to 5.1 Upgrade

VMware vCenter Single Sign-On Installation

[Read more…] about Upgrade vCloud Director 1.5 on vSphere 5.1 to vCD 5.1.1?

Blocking or allowing traffic when vShield App is down?

· ·

I did a couple of articles about vShield App a couple of months back. One of them explained how to get around a situation where vShield App would be down, as in this case of traffic would be blocked. Since then I spoke to multiple customers who asked me if it was possible to configure vShield App in such a way that traffic would be allowed when an issue occurred with vShield App. Although this goes against best practices and I would not recommend this, I can understand why some customers would want to do this. Luckily for them vShield App 5.0.1 now offers a setting that allows you to do this:

  1. Go to vShield within vCenter
  2. Click “Settings & Reports”
  3. Click the “vShield App” tab
  4. Click “Change” under “Failsafe”
  5. Click “Yes” when asked if you would like to change the setting

Together with the option to exclude VMs from being protected by vShield App and the automatic restart of vShield App appliances in the case of a failure it seems that my feature requests were fulfilled.

 

Excluding your vCenter Server from vShield App protection!

· ·

A while back I posted a hack to exclude your vCenter Server from vShield App protection. I discussed this hack with the vShield team and asked them if it would be possible to add similar functionality to vShield. I was pleasantly surprised when I noticed that they managed to slip it in to vShield App 5.0.1 release. What a quick turnaround! It is described how to do this on page 51 of the admin guide. I tested it myself ad here are the steps I took:

  1. Log in to the vShield Manager.
  2. Click Settings & Reports from the vShield Manager inventory panel.
  3. Click the vShield App tab.
  4. On the Exclusion List, click Add.
    Add Virtual Machines to Exclude dialog box opens.
  5. Click in the field next to Select and click the virtual machine you want to exclude.
  6. Click Select.
    The selected virtual machine is added to the list.
  7. Click OK

In my case I excluded both my WSX server and my vCenter Server instance:

Avoid changing your VMs IP in a DR procedure…

· ·

I was thinking about one of the most challenging aspects with DR procedures, IP changes. This is a very common problem. Although changing the IP address of a VM is usually straight forward it doesn’t mean that this is propagated to the application layer. Many applications use hardcoded IP addresses and changing these is usually a huge challenge.

But what about using vShield Edge? If you look at how vShield Edge is used in a vCloud Director environment, mainly NAT’ing and Firewall functionality, you could use it in exactly the same way for your VMs in a DR enabled environment. I know there are many Apps out there which don’t use hardcoded IP adresses and which are simple to re-IP. But for those who are not, why not just leverage vShield Edge… NAT the VMs and when there is a DR event just swap out the NAT pool and update DNS. On the “inside” nothing will change… and the application will continue to work fine. On the outside things will change, but this is an “easy” fix with a lot less risk than re-IP’ing that whole multi-tier application.

I wonder how some of you out in the field do this today.

 

Secured down your environment with vShield App and locked out of vCenter?

· ·

** Disclaimer: This is for educational purposes, please don’t make these .vmx changes in your environment as it is not supported! **

Yesterday I showed how to recover from a vShield App crash. Now bare in mind that this scenario is very rare. Today I decided to lock down my environment to the level where it was impossible to login to vCenter Server or vShield Manager. I added L2 and L3 “Any – Any” block rules to the Datacenter which hosts vCenter and vShield Manager. I needed to get access back to my vCenter host so I started digging and this is how I managed to get it back… it was a lot easier than expected:

  1. http://<ip-address-of-vShield-manager>
  2. remove/change rule

Was it really that simple? Yes it was, even after applying block rules I could still access vShield Manager. I wondered why so I started digging in to it.

If you look at the vShield Manager UI you will see that all VMs are listed except for vShield Manager and the vShield App FW VMs. The reason for this is that the vShield VMs are considered to be Service VMs. You can actually see this when you go to your Cluster in the vShield Manager UI and check the “Summary” as it will list the amount of Service VMs as shown in the screenshot below.

I wondered what caused these VMs to be listed as Service VMs so I looked at the .vmx file of the vShield VMs and spotted the following entries:

  • vShield Manager.vmx:
    vshield.vmtype = "Manager"
    vshield.vmversion = "5.0"
    vshield.vmbuild = "473791"
  • vShield App FW.vmx:
    vshield.vmtype = "Zones"
    vshield.vmversion = "3.0"
    vshield.vmbuild = "473791"

Another thing that I noticed in the .vmx file for vShield Manager is that it did not have a filter applied, in other words traffic goes straight to the VM. This was the reason traffic was not blocked by the rules we created. The next thing I wanted to test is what would happen if I would remove the filters from the vCenter VM and simply add the three .vmx entries that the vShield Manager had? The reason I wanted to test this is because I wanted to know if a filter would be applied or not.

Instead of (ab)using my vCenter VM for this (I might need it later on) I created a test VM. I booted up the VM to see if it would get the filter and made sure the rules I created were applied. I couldn’t access the VM as expected as the filter and the rules were applied. I powered it off, removed the filter, added the three entries (vShield Manager) and booted up the VM… No changes were made to the VM and I could still access it. Is this useful for your production environment? No it is not, as it is definitely not recommended to make changes like these as it is totally unsupported and could lead to unexpected results. It is nice to know though…