VirtualVCP IT Virtualization

Ok, so I'm going to have a little rant now...

After passing the VCDX Enterprise Admin Exam in July, I have booked the design exam for 20 September in the hope that if I pass the design exam, I will only have to sit the VCDX 4 design exam in order to qualify for the VCDX defence session. However, I received a notification from Pearson that VMware has asked to retire the VCDX 3 exams on 30 August 2010.

I therefore had to either reschedule the design exam to an earlier date or cancel the exam. As there are now no appointments available prior to 30 August I had to cancel the exam. This is slightly annoying as it means that rather than just having to pass the vSphere 4 design exam, I will now have to go and sit the VCDX Admin exam for vSphere 4 as well. And for those who don’t yet know, you DON’T want to sit that Admin exam twice!

Although there are “many” “new” features in vSphere 4.1, there are many changes that have been made “under the hood”. I noticed this whilst I was playing with the beta. One of these changes is the way the vpxa agent enforces admission control in ESX/ESXi.

When an ESX/ESXi host has been added to vCenter and the vpxa agent has been installed on the host, the vpxa agent will not allow any virtual machines state changes to be made directly from the host itself. You will still be able to use the vSphere client to connect directly to the ESX/ESXi host, but you will not be permitted to power on VMs directly on the ESX host. You will also be denied access to power on VM’s using the CLI. Only through vCenter will you now be able to power on a VM. What makes this awkward is this: The error message that is returned when the vpxa agent denies power on operations does not state the reason why your VM has failed to power on.

I got caught out by this after my vCenter Server (that was running as a VM) was powered down. I then connected directly to the ESX host where the vCenter VM was registered, but I was unable to power on the vCenter VM as vpxa was denying the power on operation. The way to get around this is to stop the vmware-vpxa daemon on the host “service vmware-vpxa stop). Only then will you be able to power on VMs directly.

I also have to state that I have not tried the GA build of vSphere 4.1, so the only experience I have with vSphere 4.1 is the beta. It would be interesting to see if it's still the same. Feel free to test it out and leave comments.

I've been working on the topic of replacing SSL Certificates for VMware vCenter and VMware Update Manager Server (VUM) for quite some time now. Earlier in May 2010, I had the privilege to consult a large financial institution in London on VMware and Virtualisation. The consultancy engagement was for only one week and one of my assignments was to create and document a procedure for replacing their SSL certificates on all of their very many vCenter and VUM servers. Now, at first when asked to this piece of work, I asked myself the question: "Other than maybe improving security, why would you want to replace these SSL certificates anyway?" I mean, the standard once generated when you install the vCenter and VUM servers seem to be working fine. However, the more I started to dig into their environment, the more I realised just why they wanted to replace the SSL certificates on these servers. Let me explain:

Large organisations, such as banks, will have quite a few very large data centres that are sometimes located all over the world. These organisations don't fool around when it comes to infrastructures. They don't have one data centre with maybe one or possibly two vCenter Servers. No, as I said, these guys have many data centres, each filled with thousands of physical servers. They could have 5 vCenter servers in each data centre, and each one of those vCenter servers will manage say 10 HA/DRS clusters with 8 ESX host each running thousands of Virtual Machines. To top this, each vCenter server will have its own stand-alone VMware Update Manager Server. To make managing these vCenter Servers easier, they will use vCenter a linked-mode configuration. This allows them to managed all of their vCenter and VUM Servers from a single vSphere Client instance.

Now here is where the SSL certificate story makes sense. For simplicity, I'm going to scale down the numbers a bit. Let's say they have two data centres. Each data centre has two vCenter Servers and two VUM servers. These vCenter Servers are configured with linked-mode. This means that when logging into one vCenter Server, one will be able to manage four vCenter Servers and four VUM Servers from the same console. Each one of these vCenter and VUM servers will have a self generated and signed SSL Certificate that was generated and installed during the vCenter and VUM installation. So when a user logs into one of the vCenter Servers for the first time using the vSphere client, that poor user will have to click the "Ignore" button on a security warning similar to the one below a whopping eight times!!! Yes, that's right, one for every vCenter Server and one for every VUM server in linked-mode.

Replacing the original SSL certificates on the vCenter and VUM servers with SSL certificates that have been generated by a CA that has a CA certificate in the client computer's Root Certificate Authority store will prevent the message from being displayed.

 When I originally set out to write a post on SSL Certificate Replacement for VMware vSphere vCenter Server and VMware vSphere Update Manager Server, I had planned to write a single blog article to cover the whole topic. However, as I started to document the procedure for replacing SSL Certificates earlier in May 2010, I realised that when all the screen captures are included (which is what I had planned for) the article was simply way too long for a single blog post. For this reason I have decided to cover SSL Certificate Replacement in separate articles all linked together to form a "tutorial" like post. I hope it works!

Anyway, I have decided to break the SSL Certificate Replacement topic down into the following "Steps":

1. Prepare the Certificate Authority Server with IIS, OpenSSL and Microsoft Certificate Services
2. Create a Certificate Request using OpenSSL on Windows
3. Submit the Certificate Request to the Microsoft Certificate Services CA
4. Create a new PFX-Formatted Certificate
5. Replace the vCenter Server SSL Certificates
6. Replace the VMware Update Manager SSL Certificates. (Article is yet to be published)
   

To create this article and screen shots, I made use of a lab that was especally prepared for this exercise. This lab contained the following components:

The Steering Committee are pleased to announce the next UK London VMware User Group meeting, kindly sponsored by EMC to be held on Thursday 15th July 2010. We hope to see you at the meeting, and afterwards for a drink or two, courtesy of VMware.

Our meeting will be held at the Thames Suite, London Chamber of Commerce and Industry, 33 Queen Street, London EC4R 1AP, +44 (0)20 7248 4444. The nearest tube station is Mansion House, location information is available here. Reception is from 1230 for a prompt 1pm start, to finish around 5pm. Our agenda looks something like this:

1100 – 1200 (Optional) Interactive PowerCLI / Powershell workshop – Alan Renouf
Note: If you would like to participate in Alan’s workshop, please bring a laptop, preferably with the most current PowerCLI and PowerShell binaries installed.

12:30 – 13:00 Arrive & Refreshments
13:00 – 13:20 Welcome & News – Alaric Davies
13:20 – 14:00 Sponsor Presentation, Why EMC for VMware? – Alan Renouf, Simon Seagrave

• Thin Storage in a Virtual World – Chris Evans, ‘The Storage Architect’
• Towards a Virtual Desktop – Stuart McHugh, Withers Worldwide
• Experiences with Hyper-V – Mike Laverick, RTFM Education

15:00 – 15:20 Refreshment break

• Preparation steps towards the VCDX – Simon Gallagher, Ioko
• ESX in the DMZ – Steve Bruck, Associated News and Matt Northam, VMware
• vSphere 4.1 new features – James Smith, VMware

16:45 – 17:00 Close
17:00 – Pub

To register your interest in attending, please send an email to londonvmug at yahoo dot com with up to two named attendees from your organisation. If you do not receive a confirmation mail, please don’t just turn up since we will not be able to admit you to the meeting. Please separately mention if you intend attending Alan’s PowerCLI workshop at 1100. Content from the meetings will continue to be uploaded to www.box.net/londonug, NDA permitting.

Sincerely, and with regards,

The UKLVMUG Steering Committee