This is the first part of the 3rd article in a series about how to build-out a simple vCAC 6 installation to a distributed model. By the end of this part, we will not have modified the vCAC deployment in any way, we’ll just have 3 configured load balanced URLs An overview of the steps required are below: Issue and install certificates Deploy an external vPostgres appliance and migrate the vCAC database Configure load balancing Deploy a second vCAC appliance and configure clustering Install and configure additional IaaS server Deploy vCenter Orchestrator Appliance cluster Deploy a vShield Edge appliance Log in to your vShield Manager and select your Datacenter, then the Network Virtualisation tab
This is the first article in a series about how to build-out a simple vCAC 6 installation to a distributed model. In a simple installation you have the Identity Appliance, the vCAC appliance (which includes a vPostgres DB and vCenter Orchestrator instance) and an IaaS server. The distributed model still has a single Identity Appliance but clusters 2 or more vCAC appliances behind a load balancer, backed by a separate vPostgres database appliance.
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.
It was with great honor both Sam and I were awarded vExpert 2014 (my first and Sam's second award!) we are both proud to be listed alongside so many others in the vExpert programme. 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).
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:
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. The Exam The exam itself is 85 multiple choice questions, and gives you 90 minutes to do them.
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. The Hardware As OS X requires Apple hardware to run you will have to find yourself a Mac that will install and run ESXi.
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.
There are different schools of thought as to whether you should have SSH enabled on your hosts. VMware recommend it is disabled. With SSH disabled there is no possibility of attack, so that’s the “most secure” option. Of course in the real world there’s a balance between “most secure” and “usability” (e.g. the most secure host is powered off and physically isolated from the network, but you can’t run any workloads ).