Sam has been working in the IT industry for nearly 20 years now, and is currently working for VMware as a Senior Technical Marketing Manger in the Cloud Management Business Unit (CMBU) focussed on Automation. Previously, he has worked as consultant for VMware PSO, specializing in cloud automation and network virtualization. His technical experience includes design, development and implementation of cloud solutions, network function virtualisation and the software defined datacentre. Sam specialises in automation of network virtualisation for cloud infrastructure, enabling public cloud solutions for service providers and private or hybrid cloud solutions for the enterprise.
Sam holds multiple high level industry certifications, including the VMware Certified Design Expert (VCDX) for Cloud Management and Automation. He is also a proud member of the vExpert community, holding the vExpert accolade from 2013-present, as well as being selected for the vExpert NSX, vExpert VSAN and vExpert Cloud sub-programs.
I’ve been playing about with a compact SRM install in my lab - since I have limited resources and only one site I wanted to create a run-through for anyone learning SRM to be able to do it in their own lab too. I am creating two sites on the same IP subnet (pretend it’s a stretched LAN across two sites) and will be protecting a single, tiny Linux web server using vSphere Replication.
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:
After having a play with Virtual Flash and Host Caching on one of my lab hosts I wanted to re-use the SSD drive, but couldn’t seem to get vFlash to release the drive. I disabled flash usage on all VMs and disabled the Host Cache, then went to the Virtual Flash Resource Management page to click the “Remove All” button. That failed with errors:
“Host’s virtual flash resource is inaccessible.”
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.
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’s no doubt that vCOps is a great product for proactively monitoring your vSphere environment, but it’s a hefty package for the lab. The minimum recommended RAM is a whopping 16GB – in my lab that’s the whole of my management host! I recently needed to do some testing so I wanted to get it running in the lab with the barest minimum I could get working, and it turns out you can get working with just 4GB and 2 CPU…albeit you wouldn’t want to monitor much!
2013 has been an amazing year for me – I was awarded the vExpert title, I’ve taken and passed my VCP5-DCV, VCAP5-DCA and VCAP5-DCD and spoken at the London and UK national VMUGs. I’ve attended my first VMworld and spent countless hours in the lab and on study, generating about 30 blog posts. All I can say is that it’s been a truly blessed year.
After two and a half years working as a Senior Infrastructure Analyst for a global insurance company, the time has come for a change!
In my post yesterday (vexpert.me/hS) I talked about how to recover from an expired default SSO administrator password – this prompted a discussion on twitter with Anthony Spiteri (@anthonyspiteri) and Grant Orchard (@grantorchard) about the defaults for expiration and how to mitigate the risk.
The first solution is to modify the password expiration policy for SSO. I’m not advocating this necessarily – I think that expiring passwords ensure that you change them regularly and increase the overall security of your SSO solution.
Today I found out that in vSphere 5.1 the SSO administrator account (admin@system-domain) has a password that expires after 365 days. See KB2035864:
vCenter Single Sign-On account (SSO) passwords expire after 365 days, including the password for admin@system-domain.
Awesome.
In vSphere 5.5 it gets even better – the password expires every 90 days by default! (See the vSphere 5.5 SSO documentation)
By default, vCenter Single Sign-On passwords, including the password for administrator@vsphere.
