I’m fairly new to SRM, but even so this one seemed like a real head-scratcher! If you happen to be using CA signed certificates on your “protected site” vCenter and “recovery site” vCenter servers, when you come to linking the two SRM sites you encounter SSLHandShake errors – basically SRM assumes you want to use certificates for authentication because you’re using signed certificates. If you use the default self-signed certificates, SRM will default to using password authentication (see SRM Authentication). Where the process fails is during the “configure connection” stage, if either one of your vCenter servers does not have CA signed and the other does (throws an error that they are using different authentication methods) or that you are using self-signed certificates for either SRM installation (throws an error that the certificate or CA could not be trusted).
SRM server 'vc-02.definit.local' cannot do a pair operation. The reason is: Local and remote servers are using different authentication methods.
This had me scratching my head, what seemed to be a common problem wasn’t fixed by the common solution. It was actually my fault – too familiar with the product and setting things up too quickly to test.
I installed a VCSA 5.5 instance in my lab as a secondary site for some testing and during the process found I couldn’t log on to the web client – it failed with the error:
Failed to connect to VMware Lookup Service https://vCVA_IP_address:7444/lookupservice/sdk - SSL certificate verification failed.
I had a closer look at the certificate being generated and noticed that the Subject Name was malformed “CN=vc-02.definit.loca” – that led me to the network config of the VCSA. I’d entered the FQDN into the “host name” field, which was in turn being passed to the certificate generation, truncated and throwing the SSL error. Changing the FQDN back to the host name “VC-02” and regenerating the certificate resolved the issue.
If you do have to follow that process, remember to disable the SSL certificate regeneration after it’s fixed – otherwise you’ll suffer slow boot times!
I’ll put that one down to over-familiarity with the product!
So this morning I took the VMware Infrastructure as a Service exam (VCPVCD510) to gain the VCP5-Cloud qualification. The IaaS exam is available for existing VCP5-DCV holders to take without any other pre-requisites. I am very pleased to say I finished the exam in good time and scored 466/500 – the pass mark is 300.
As a proof of concept I recently tried to virtualize OS X (Mountain Lion) - It is important to note that VMware is now licensed to do so and you can read more here.
The following is an overview of the steps I followed to achieve my goal in some cases it was trial an error as I am not a regular Mac user.
As OS X requires Apple hardware to run you will have to find yourself a Mac that will install and run ESXi. You can check VMware's HCL even though the results only listed MacPro5,1 I was able to run ESXi 5.1 on a MacPro4,1. I did try it on an earlier MacPro but no joy. For this proof of concept test i have the following hardware.
- 2x 4core MacPro4,1
- 7GB Ram
- Single 1TB SATA Drive
I am also aware others have used Mac mini's as Lab machines but I will not cover that here.
The installation is simple, by burning an ISO with ESXi 5.1 and booting the MacPro from the CD and then follow the usual steps to deploy ESXi.
Note - if you find nothing happens and you end up with a black screen with "Select CD-ROM boot type" its likely your MacPro cannot run ESXi though I have read a few article where individuals have performed firmware updates etc.
Once you have have ESXi installed configure it in what ever fashion you wish (a static IP is never a bad idea)
According to VMware, Infrastructure Navigator is
…a component of the VMware vCenter Operations Management Suite. It automatically discovers application services, visualizes relationships and maps dependencies of applications on virtualized compute, storage and network resources.
Effectively it takes a look at the network connections that are running between your VMs (and physical servers) and works out which applications and services are running on each, and the dependencies – both upstream and downstream – for each VM.
This is particularly useful in large enterprise environments where perhaps application developers have not (shock) documented the dependencies for a particular application. I can think of several times when I’ve been 100% confident that (according to all the documentation provided) I can decommission a server, or the service running on a server, only to have to turn it back on due to a production outage – because an un-documented dependency exists.
Effectively, Infrastructure Navigator leverages VMware Tools to run a netstat command on each VM and work out what connections are being used. It comes with a library of already classified services – e.g. MSSQL running on port 1433 is a pretty obvious service. Non-classified services (or services configured for running on a non-standard port) can be easily added to the library to build up a detailed picture of which VMs depend on each other (as well as “unmanaged” servers/services that are out of the scope of vCenter).