As we all know by now, PernixData was gobbled up by Nutanix a while back, and since then there has been a nothing but silence on the future of the FVP and Architect products. Now it seems it’s over. The acquisition trigged a bunch of PernixData employees moving elsewhere, and now it’s the products time to move on as well.
As a part of my Homelab project, I’ve created a proper bash script to provide dynamic DNS updates for external resources, via CloudFlare. More details on the reasoning behind it can be found in Using CloudFlare for Dynamic DNS, but since that was posted I’ve fleshed the script out quite a bit more.
In my previous post, I tried to lay out the foundation and reasoning behind requiring a Dynamic DNS Service, and here is how I solved it using CloudFlare.
First of all, I moved my chosen domain name to CloudFlare, and made sure everything resolved ok with static records. Once that was working, I started playing around with the CloudFlare API, using Cocoa Rest Client. I’m no developer (as is probably very apparent by the script below), nor API wizard of any kind, but it was fairly easy figuring out how to craft a request that lists my DNS zone.
While working on my new Homelab setup, I’ve been investigating ways to provide hostname based access to several web services located in my DMZ zone. Since my provider doesn’t provide static IP addresses, I also need an external Dynamic DNS service, to provide said hostname mappings through the reverse proxy on the inside.
There are loads of Dynamic DNS services available, most of them lets you use some sort of predefined domain name scheme, and point it to your external IP, but I wanted to use a domain name that I own and control. Since I use CloudFlare to provide DNS services (amongst other things) for this very site, it was a natural choice to see if they could fit the bill for my lab needs as well. Turns out, not only can they provide the services I need for free, they also allow me to play around and have fun at the same time!
Way back in 2013, I published Preserve your Veeam B&R Backups Jobs when Moving vCenter, outlining how to «cheat» (by using a CNAME alias) to preserve your Veeam Backup & Replication jobs if you replace your VMware vCenter.
Naturally, when there is a new vCenter instance, all the Virtual Machine Managed Object Reference’s (MoRef) change, which makes Veeam Backup & Replication start a new backup/replication chain, since all VMs are treated as new ones. Not ideal by any means, but at least you wouldn’t have to recreate all your jobs.
A few days ago I decided to go full-on mad scientist in documenting my new home lab / network setup, and I’ve even created a GitHub repository for it. The idea is to create a framework for developing this kind of documentation, heavily influenced by the VCDX methodology and framework. Over time, Conceptual, Logical and Physical designs will be added, as well as configuration settings and operational procedures. Hopefully it’ll also contain some useful diagrams.
While I was away on a two week holiday on the Croatia’s sunny Makarska Rivijera, Eric Siebert announced the result of his annual Top vBlog, and much to my surprise vNinja did quite the jump from last years 46th spot to this years 27th! Honestly, I thought the site would drop out of the the top 50 list this year, but once again I’m proven to be mistaken. Some times being wrong is just great!
A little while ago William Lam published a little python script called extract_vsphere_deployment_topology.py that basically lets you export your current vSphere PSC topology as a DOT (graph description language) file. Great stuff, and in itself useful as is, especially if you run it through webgraphviz.com as William suggests.
The thing is, you might want to edit the topology map, change colours and fonts, and even move the boxes around, after you get the output. If you have a large environment, you might want to combine all your PSC topologies into a single document? It turns out, that’s pretty easy to do!