Management

I recently upgraded my lab firewall from the aging Cisco ASA 5505 to the brand new Cisco ASA 5506W-X. Since this device is so new, there is no information available yet about resolving any of the “gotchas” so I thought I would share a a couple of them.

Coming from a Cisco background this was a little bit of a change. I am now using Dell Force10 switches and I have been trying to figure out how to get LLDP to advertise the management IP to its neighbors like CDP does. CDP does this by default and there is non-default configuration that must be done in order to get LLDP to do it. With LLDP you must add LLDP configuration to each neighbor facing interface. Below is an example of what that configuration would look like:

The next part of the NSX deployment is to get the NSX Manager registered with vCenter. The first thing to do for this is to browse to the NSX Manager IP that you chose during the OVF deployment. You will be presented with a login screen as seen below.

Vmware has made available their Disaster Recovery as a Service (DRaaS ) offering. It will be served out of the vCloud Hybrid Service datacenters. It is powered by the time proven VMware Site Recovery Manager and VMware Replication appliance.

The service is intended for mid-sized companies and promises to be a seamless integration with existing vSphere-based infrastructures. At a starting price of $835/month the service seems poised to hit the ground running.

When looking into performance on a virtualized workload, one of the most important statistics to watch is CPU Ready Time.

What is CPU Ready Time, you ask?

Well, CPU Ready Time is the amount of time that a vCPU is waiting for a time slot on a physical CPU core. In other words, if you are seeing a high CPU Ready Time, that means that your host is having a high amount of CPU contention and may be over subscribed.

There is a great VMware KB Article that explains how to calculate CPU Ready % from the CPU Ready summation values that you find on the performance tab in the vClient:

Sizing VM’s appropriately is very important. Just because you have a physical server that has 8 cores does not necessarily mean that its VM counterpart needs to have as many vCPUs. The best approach is to start small and grow as needed. A VM that is oversized can actually perform worse than one that is undersized.

If you have never had the “Oh So Wonderful” fun involved with replacing and/or updating SSL certificates within your VMware infrastructures, you should consider yourself fortunate. For those of us who have, VMware has delivered a tool to save our sanity. Enter vCenter Certificate Automation Tool. According to VMware, the main two purposes for the tool is:

Certificate Signing Request generation and Certificate update – Helps with certificate deployment and trust update. Note that the tool does not generate custom certificates for you. You are expected to generate these certificates offline following the instructions in this document.

Update Steps Planner – Allows you to plan the sequence of certificate updates for the components. This prevents errors in the process that might otherwise occur.

Per VMware, in order utilize the tool you must be able to meet all of the following requirements:

Administrative privileges on the server(s) on which you are running the tool. Although non-administrator users can download and launch the tool, all operations fail without the proper permissions.

Access to each server that has vSphere components for which the SSL certificate should be updated.

All vCenter Server components for which the certificates are to be updated are already installed and running.

The new certificates and private keys already exist and you know the location of the new certificates. For increased security, generate each certificate and private key on the machine where it will be used.

To get all of the complete details be sure to check out the VMware KB articles below: