Disclaimer: Vembu are a sponsor of Virtual Tassie and this post is a sponsored blog post. This post has been written in my own words but may contain some material supplied by Vembu for an upcoming release or announcement. Vembu have been hard at work behind the scenes on a new version of their BDR suite and version 4.0 is due for release soon. As a quick recap, the BDR Suite is a range of products available from Vembu to help businesses with data protection and disaster recovery of their workloads.

Update 27th October 2018: I was meant to provide this update last weekend, but it has been a hectic week. Within a few hours of posting this issue, a few people at VMware reached out to me to understand more about my configuration, asked me to upload the logs and a few of the smart guys and gals at VMware had been able to reproduce the issue. As it turns out, the key in the APPLMGMT_PASSWORD vecs store is used when a file based backup of the VCSA is scheduled.

Runecast were the last company I had the pleasure of being a delegate for at the Tech Field Day Extra at VMworld US 2018. I’ve written about Runecast on this blog before, and I really like who they are and what they do. Runecast is a proactive VMware management solution, delivered as a pre-packaged appliance, that aims to provide you with issue prevention, security compliance and log analytics for your VMware environment before any major outages occur.

DISCLAIMER: During VMworld 2018 US (Las Vegas), I was invited as a delegate to the Tech Field Day Extra (TFDx) event. I was not compensated in any way, my conference pass was complimentary as I was a speaker at the event and other expenses were covered by my employer, Parallo. I’m not required to write this blog post, I chose to do so of my own accord. This blog post is aimed to summarise the presentation that I was present for and also to provide some additional information about the company or solution presented on, which is all based on my opinion.

Next week the “ANZ” vForum event will be held once again in Sydney, Australia. The conference is returning to Sydney’s Luna Park where is was held 4 years ago in 2014 (from memory to celebrate a 10 year milestone of sorts), and that event was also my first vForum. vForum is also returning as a two day event after the format was changed last year to a one day event. I’m honestly not sure what the feedback was around it being a one day event, but VMware adjusting it back to two days speaks for itself.

Last night I was working in an environment that has a reasonably well locked down NSX distributed firewall, and I was having some issues with PowerCLI. PowerCLI 10.2 on Windows, connecting to vCenter Server 6.7, to be specific. Port 443 was allowed from the jump host to vCenter Server, but I was seeing some odd issues still. I was trying to run an as built report for the environment, but I could not seem to establish a connection to NSX manager when running the script, and VUM cmdlets that are called in the script were also failing, such as:

Well, that rolled around quickly. I remember booking the flights, accommodation and registration for VMware’s flagship VMworld event months ago and I’m now writing this from the plane about half way through the 27 hour journey from my home in Tasmania, Australia, to Las Vegas. This isn’t going to be a post on my recommendations, tips and tricks, or “how to attend if you aren’t attending”. There are lots of resources out there for this content and I urge you to go and read some of the blogs by others as there are some really great pointers!

Disclaimer: Vembu are a sponsor of Virtual Tassie and this post is a sponsored blog post. This post has been written in my own words and is not a direct redistribution of a blog post written by Vembu. With that said, I am new to the Vembu suite and have not had time since taking them on as a sponsor to use all aspects of their solution, so some of the content above has been comprised using information from Vembu’s website.

Recently I was playing around with NSX-V in the lab and getting myself more familiar with the automation options available. During the deployment of one of my environments, I couldn’t get the NSX Controllers to come up without failing. NSX Manager would deploy the controller VM, but it sat in a “deploying” state for around 45 minutes and then failed with a message “no route to host”. I checked out the console of one of the controllers directly after deployment and as soon as it booted up it went to the following GRUB boot loader screen:

That title is a bit of a mouthful, but it’s Friday night and that’s the best I’ve got! I was recently working through some recovery scenarios for NSX in the lab, as I was interested to understand what the process was for various scenarios such as: Losing NSX Manager and restoring Losing NSX Manager, DLR and ESG’s and restoring Losing the entire cluster (including ESXi hosts) and restoring NSX manager in to a new cluster The third scenario is reasonably obscure, and I’m not sure if you would follow a different restore process than what I did if this did actually happen.