Yesterday I received a nice tip from @Shaun_Gee. During the installation of the vSphere Syslog Collector you have to select the max size of the log files and when a rotation will happen. But how do you change this after the installation? The answer is straight forward, but unfortunately not well documented, thanks Shaun for sharing.

The vSphere Syslog Collector settings can be found under:

• Windows 2003 –> C:\Users\All Users\VMware\VMware Syslog Collector\vmconfig-syslog.xml
• Windows 2008 –> C:\ProgramData\VMware\VMware Syslog Collector\vmconfig-syslog.xml

If you open this file you can change all the settings you configured during the installation.

<defaultValues>
<port>514</port>
<protocol>TCP,UDP</protocol>
<maxSize>2</maxSize>
<rotate>8</rotate>
<sslPort>1514</sslPort>
</defaultValues>

You never know when you might need it

Today on twitter there was a discussion around having an appliance for the vSphere Web Client. I didn’t get the question as there’s already a vCenter Appliance out there. Apparently not everyone realised that the Web Client is part of the vCenter Appliance. On top of that you could even split out the components and use the vCenter Appliance just for Web Client functionality. I remembered seeing an article from one of my colleagues not too long ago. I dug up the links and here they are. I included a short snippet so you know what to expect. These articles are by Michael Webster so all credits go to him:

Deploy vSphere Web Client without Additional Windows Server License

Prior to running through the steps below you should have downloaded and deployed the vCenter Server Virtual Appliance (VCVA) from the VMware web site. This process assumes you already have the VCVA connected to the network and configured with the correct timezone already. To de-register the local embedded vCenter System and to register an existing vCenter Server with the vSphere Web Client do the following….

This is the first step you can take to get the vSphere Web Client up and running. But what if you want to provide some additional redundancy. Or what if you have dozens of people literally using the Web Client and want to add some load balancing? Well Michael thought about that as well and came up with a cool solution for this.

Increase vSphere Web Client Availability and Scalability for Enterprise Environments

In the above design I’ve chosen to use the vCenter Virtual Appliance with the vCenter Services disabled to act as the vSphere Web Client Servers. I’ve used a F5 BIG-IP LTM VE to provide load balancing for the vSphere Web Client User access to the vSphere Web Client Servers, as well as for the vCenter Servers to access the vSphere License Plug-in. You can use any load balancer that will successfully load balance HTTPS traffic on port 9443, which is the port the vSphere Web Client uses.

I think this is a cool solution, and considering the Web Client is the way forward it is definitely an option exploring. I do want to point out that this has more than likely not been explicitly tested by VMware and I am uncertain if it is supported. I have reached out to our vCenter experts however to comment on it.

I think this will make you happy. VMware just released the vCloud Director virtual appliance. That means no more installing Red Hat, Oracle and vCloud Director. Just download the appliance and deploy it. On top of there is a great vCloud Cloud Director Evaluators Guide which will help you to evaluate the product.

• vCloud Director virtual appliance download (You will need to register for the eval)
• VMware vCloud Director Evaluator’s Guide

If you haven’t done anything with vCloud Director before the following articles might also be worth reading, note that these are 1.0 based articles but most of the content is still valid today.

• vCloud Director Intro
• vCloud Director Demo
• vCloud Director networking part 1, 2, 3a and 3b
• vCloud Director Allocation Models

** 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…

I am just playing around in my lab and needed to do a couple of common ESXi commandline tasks which I figured I would document as they will come in handy at some point.

• List all VMs registered to this host (This reveals the Vmid needed for other commands)
  vim-cmd /vmsvc/getallvms
• Unregister a VM
  vim-cmd /vmsvc/unregister <Vmid>
• Register a VM
  vim-cmd /solo/register /path/to/file.vmx
• Get power state of a VM
  vim-cmd /vmsvc/power.getstate <Vimid>
• Power off a VM
  vim-cmd /vmsvc/power.off <Vmid>
• Power on a VM
  vim-cmd /vmsvc/power.on <Vmid>

I bet you wouldn’t mind winning any of the following:

• 10 x Iomega SSD
• 10 x Iomega IX2 Cloud Edition
• 2 x iPad gen 1
• 5 x iPad gen 2
• 1 x VNXe 3300 with 10GbE/1GbE and 15 x 600GB 10K RPM spindles (!!)

Yes you did read that correctly a VNXe with 15 x 600GB disk… It is crazy indeed, and only one person is crazy enough to start a survey with these kind of prices, Chad “Santa” Sakac. Head over to Chad’s blog post, fill out the 18 questions and you might be the lucky one!

http://virtualgeek.typepad.com/virtual_geek/2011/11/official-unofficial-vmwarestorage-survey-2011-edition.html

I was playing around with vShield App and I locked out my vCenter VM which happened to be hosted on the cluster which was protected by vShield App. Yes I know that it is not recommended, but I have a limited amount of compute resources in my lab and I can’t spare a full server just for vCenter so I figured I would try it anyway and by breaking stuff I learn a lot more.

I wanted to know what happened when my vShield App virtual machine would fail. So I killed it and of course I couldn’t reach vCenter anymore. The reason for this being is the fact that a so-called dvfilter is used. The dvfilter basically captures the traffic, sends it to the vShield App VM which inspects it and then sends it to the VM (or not depending on the rules). As I killed my vShield App VM there was no way it would work. If I would have had my vCenter available I would just vMotion the VMs to another host and the problem would be solved, but it was my vCenter which was impacted by this issue. Before I started digging myself I did a quick google and I noticed this post by vTexan. He had locked himself out by creating strict rules, but my scenario was different. What were my options?

Well there are multiple options of course:

1. Move the VM to an unprotected host
2. Disarm the VM
3. Uninstall vShield

As I did not have an unprotected host in my cluster and did not want to uninstall vShield I had only 1 option left. I figured it couldn’t be too difficult and it actually wasn’t:

1. Connect your vSphere Client to the ESXi host which is running vCenter
2. Power Off the vCenter VM
3. Right click the vCenter VM and go to “Edit Settings”
4. Go to the Options tab and click General under Advanced
5. Click Configuration Parameters
6. Look for the “ethernet0.filter0″ entries and remove both values
7. Click Ok, Ok and power on your vCenter VM

As soon as your vCenter VM is booted you should have access to vCenter again. Isn’t that cool? What would happen if your vShield App would return? Would this vCenter VM be left unprotected? No it wouldn’t, vShield App would actually notice it is not protected and add the correct filter details again so that the vCenter VM will be protected. If you want to speed this process up you could of course also vMotion the VM to a host which is protected. Now keep in mind that while you do the vMotion it will insert the filter again which could cause the vCenter VM to disconnect. In all my tests so far it would reconnect at some point, but that is no guarantee of course.

Tomorrow I am going to apply a security policy which will lock out my vCenter Server and try to recover from that… I’ll keep you posted.

** Disclaimer: This is for educational purposes, please don’t try this at home… **