My hosting provider moved me to a new platform in September. By October I’d decided to move somewhere else based on the poor performance of the site and generally shoddy support experience. I’m now with SiteGround. They’re nice, fast and cheap enough for me. I’ve joined their affiliate program, so if you decide to sign up with them I can get some cash.
My blog got “hacked” yesterday. Someone put a redirect in place to a men’s performance pill site. Big thanks to Mike Yurick for pointing it out to me and to my colleague Josh for answering my pleas for help and stepping in and cleaning it up while I was on a plane inter-state. He used Wordfence to scan and clean up the site – check them out and make sure your backups are up to date. If it happens to you, and you don’t have a Josh, check out this guidance from WordPress.
The next Brisbane VMUG will be held on Tuesday February 21st. I’ll be putting up an article on it in the next few weeks. It will be sponsored by Veeam and should be great.
As part of a recent vSphere 5.5 deployment, I installed a small vSphere Replication 5.8 proof-of-concept for the customer to trial site-to-site replication and get their minds around how they can do some simple DR activities. The appliance is fairly simple to deploy, so I thought I’d just provide a few links to articles that I found useful. Firstly, esxi-guy has a very useful soup-to-nuts post on the steps required to deploy a replication environment, and the steps to recover a VM. You can check it out here. Secondly, here’s a link to the official vSphere Replication documentation in PDF and eBook formats – just the sort of thing you’ll want to read while on the treadmill or sitting on the bus on the way home from the salt mines. Finally, if you’re working in an environment that has a number of firewalls in play, this list of ports you need to open is pretty handy.
One problem we did have was that we’d forgotten what the password was on the appliance we’d deployed at each site. I’m not the greatest cracker in any case, and so we agreed that re-deploying the appliance would be the simplest course of action. So I deleted the VM at each site and went through the “Deploy from OVF” thing again. The only thing of note that happened was that it warned me I had previously deployed a vSphere Replication instance with that name and IP address previously, and that I should get rid of the stale version. I did that at each site and then joined them together again and was good to go. I’m now trying to convince the customer that SRM might be of some use to them too. But baby steps, right?
Note also that, if you want to deploy additional vSphere Replication VMs to assist with load-balancing in your environment, you need to use the vSphere_Replication_AddOn_OVF10.ovf file for the additional appliances.