I am happy to announce that I have submitted my first session for VMworld:

Scale-Out Cloud Infrastructure - A Look into the Cloud Foundry PaaS. In this session vSpecialist Tarik Dwiek and I will discuss how the infrastructure for Cloud Foundry has been architected to ensure scalability. In addition, we will cover specific testing done between VMware and EMC in order to fully understand performance, reliability, and replication during typical Cloud Foundry operational functions.

Now it is a waiting game to see if the session is accepted. I am really excited about the topic and hope to have the opportunity to present at VMworld 2012!

The more I use logrotate the less I like it. If you recall from my previous post on logrotate, I choose to leverage the copytruncate option. While this configuration seemed to work well when I tested it, I have now experienced some significant limitations that are not documented in the man page:

1. After rotation, high volume logs files remained the same size and continued to grow
2. Pre and post rotated high volume log files contained NUL characters
3. Large sized log files lost messages during logrotate operation

So what caused the issues, what was the impact, and how can you rotate logs messages and not experience these issues?

Since I have experienced this issue several times before and I can never remember the commands needed to figure out what is wrong, I figured I would write a quick post. The issue is upon reboot of a Vyatta firewall you receive a 'configure failed!' error message. The exact error message depends on which features you have enabled on your device, but one example is:

Starting Vyatta router: migrate r1-system firewall configure failed!

So how do you check what changed / what is causing the issue?

I was recently asked to assist in configuring a wildcard SSL certificate on a pair of vCloud Director (vCD) cells. While the certificate had been installed on the cells, some browsers were displaying SSL errors such as the following:

While other browsers appeared to work:	Until you drilled down a little further:

In addition, while uploading/downloading VMs SSL errors like the following were displayed:

So what was going on and how can it be fixed?

Over the last two weeks I have been hit by the same UCS bug, though by different means, twice and as such I would like to educate others about it. The issue initially came up after running a 'show tech' command on a UCS Fabric Interconnect (FI). Shortly after the process started my session to the FI dropped. Since I have experienced random disconnects from an FI in the past I tried to reconnect. To my surprise the FI was unresponsive. Not knowing what was going on I tried the second FI and it also was not responding. A ping check confirmed my fear, both FIs were down.

For those who have never experienced a dual fabric reboot on an active/production environment before, the ten minutes that follow will be the longest of your life (even if you do have access to the console port - locally or remotely). After about ten minutes the FIs started to respond again. As if a dual fabric reboot was not enough, the problem did not end there. About 5-10 minutes after the FIs came back online they went down again! This cycle continued until manual intervention stopped it.

So what was the problem; what was the impact; how can you fix it; and how can you prevent it?