Yellow Bricks

by Duncan Epping

app

Cool iPad app: VMware Mobile Knowledge Portal

· ·

We’ve just published a cool application, it is called the VMware Mobile Knowledge Portal.

Description
The Mobile Knowledge Portal gives you access to VMware marketing and technical content. Use the application to watch installation videos, read product whitepapers, and learn best practices.

I think this is a very useful app for those who like to have a centralized place for all their tech content. This is going to grow soon and be expanded in to various areas. Just go out and download it, try it and leave some feedback here!

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…

vShield App and layering your design

· ·

I started diving in to vShield App and one thing that I like about vShield App is that it allows you to use different types of objects to apply your policies to. Never really put too much thought in to it, but considering the world is more and more changing to policy based management this fits right in. I just wanted to share something that I was working on, any feedback / thoughts are welcome…

The VMware Cloud Infrastructure aims to reduce operational overhead and lower Total Cost of Ownership (TCO) by simplifying management tasks and abstracting complex processes. The focus of this architecture, as indicated by our customer requirements, is resource aggregation and isolation through the use of pools for each of the crucial pillars: network, storage and compute. Each of the three pillars will be carved in to multiple units of consumption with priority allocated based on their service level agreement. This will be achieved by leveraging core functionality offered by vSphere 5.0. Subsequently vShield App will be used to isolate each of the different type of workloads. As a hypervisor-based application-aware firewall solution, vShield App allows defining policies to logical, dynamic application boundaries (security groups) instead of physical boundaries.

This resource and security layering method will allow for a fast and safe deployment of new workloads.

Each of the different types of resources are carved up in to different groups for each of the respective workload types. A virtual machine, or vApp, will be deployed in one of the three different compute and security groups after which a specific networking group will be selected and a storage tier. Compute, Security and Network  group types are currently defined based on the different type of workloads this virtual infrastructure will host. In the future additional blocks may be added based on the requirements of the internal customers and the different types of workloads being deployed…