I recently got my hands on a copy* of Chris Wahl and Steve Pantol’s Networking for VMware Administrators and was very keen to read it – especially given the reputation of the authors. I came to the book as someone who is at CCNA level (although now expired) and someone who regularly designs complex VMware networks using standard and distributed switches. I would class myself as having a fairly decent understanding of networking, though not a networking specialist.
The book starts out at from a really basic level explaining OSI, what a protocol is etc. and builds on the foundation set out as it progresses. Part I of the book gives are really good explanation of not only the basics of networking, but a lot of the “why” as well. If you’ve done CCNA level networking exams then you will know most of this stuff – but it’s always good to refresh, and maybe cover any gaps.
Part II of the book translates the foundations set out in Part I into the virtual world and takes you through the similarities and differences with between virtual and physical. It gives a good overview of the vSphere Standard Switch (VSS) and vSphere Distributed Switch (vDS) and even has a chapter on the Cisco 1000v. One of the really useful parts of the book are the lab examples and designs, which takes you though the design process and considerations to get to the solution.
You can view the announcement and the full list here - http://blogs.vmware.com/vmtn/2014/04/vexpert-2014-announcement.html
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.