A few days ago I tweeted about managing my ESXi HomeLab from the Xbox. Whilst this is a bit of a novelty (I’m holding out for the Minecraft ESXi plugin fling), it highlights the management possibilities that the new HTML-based (rather than Flash or Windows based) client creates.Continue reading
If you run a HomeLab, or have ever considered setting one up, you should check out the new Open HomeLab Project. This is a new wiki-based initiative to collect together information on the Home Lab ecosystem for newbies and hardened enthusiasts alike.
The Project was kicked off by Alex Galbraith following the London VMUG event in April and in the build up to today’s public launch a team has been busy collating together plenty of information on the uses, costs, hardware, and software of a HomeLab. If you’re learning about IT infrastructure and want somewhere to experiment, or if you just feel the need for a semi-enterprise IT environment in your house or garage, then there’s something here for you and the project would love to have input on what you’re up to.
I’m a relative newcomer to the “proper” HomeLab scene, having started in earnest back in January (check out my HomeLab series here), but found myself as one of the founding members of the project and have already been able to contribute some content from my experiences. This is proof that this can be a real community driven resource- you don’t need to be a multi-qualified VCDX, MCP wielding enterprise architect to be able to participate and share your knowledge and experience with others.
The site is now in a public Alpha, so here’s your chance to get in early. Go and have a look, peruse, and add content: http://openhomelab.org/
If you’re running the HTML ESXi Host Client that comes with version 6.0 Update 2, you may find your screen reverting to the login prompt after only a short period of inactivity. This is because there’s an Application Timeout setting that defaults to 15 minutes.
To change this setting login to the host client and locate the [email protected] drop down menu in the top right hand corner, select “Client Settings” and then “Application timeout”. The timeout can be set to 15, 30, 60, or 120 minutes, or disabled completely.
In an important production environment it’s obviously more secure to keep this enabled as it will prevent you accidentally leaving yourself logged into the client and open to malicious passers wreaking havoc on your infrastructure. However, in a test environment, or your Home Lab, it’s probably quite safe to lengthen or disable this timeout assuming that you’re not concerned about small family members or pets getting hold of the mouse and playing with your VMs.
With ESXi 6.0 update 2 we were treated to a HTML-based web host client. This meant we were no longer confined to using the Windows (“C++”) client for host management, however it was still necessary to use the Flash-based web client for managing a vCenter infrastructure. The vSphere HTML5 Web Client is the solution to this- providing a HTML5, standards-based, web front end to a VMware virtual infrastructure. The product is currently in the “Fling” stage- so it’s out there to try but not quite finished to “production” standards yet.
In my Homelab environment, installation was simple- I downloaded and deployed the OVA from the Flings website and then followed the comprehensive instructions on the vSphere Blog. Within a few minutes I had the client up and running and it sits alongside the existing host client and flash-based vCenter client (via VCSA) so all my existing management interfaces are preserved.So, what does this give me? Well, apart from giving an insight into the future direction of the VMware hypervisor management console, it allows me to do basic vCenter management tasks from my mobile phone or non-flash compatible portable devices (although there’s a little way to go to make the app really usable on my mobile at least- see screenshot). I’ve blogged before about using the Host client on the Xbox One, and now it’s possible to manage some vCenter functions from the console too.
With the news that the “fat” C++ based Windows client will be depreciated in the next release of vSphere having started being phased out in version 5.5, I’m looking forward to seeing where this goes.
I’m commencing a project with my HomeLab- I’m going to build a system whereby I can produce custom mini-lab environments by means of a script. There are off the shelf solutions to do this (see AutoLab as an example) but if I build this myself I get something tailored exactly to my needs (and available resources) and hopefully learn something along the way- which is what the HomeLab is all about really. This is the first post in what should develop into a series showing how I work through the process to create my automation system.
a.k.a. what I want to achieve
- The ability to run a script to deploy a predefined lab environment. For example running “Build-Project-Lab-One.ps1” makes 3 Windows Server VMs, connected on a private switch, with one running AD/DNS/DHCP roles, one acting as a Gateway, and one ready for whatever experiment I throw at it
- The ability to quickly and easily modify a copy of that script to produce a lab with a different configuration. Then I can have a script that builds me a WDS platform, or another one that produces a SCOM test environment. I can use this library to quickly rebuild, or build a copy of, and of my environments within the HomeLab
- This script should also create a second script for decommissioning /destroying the lab environment when I’ve finished.
- Whilst perhaps not meeting full “production” standards, the scripts should be at least in a state whereby I can post them online and not have to hide in a cave for the next decade whilst they get laughed at.
a.k.a. what I have to play with
- One Intel NUC host running vSphere ESXi 6 providing some compute, memory, storage
- One VMUG Advantage Subscription complete with VMware EVAL Experience licensing- this provides VMware vCenter amongst other things.
- One Microsoft DreamSpark Subscription and Microsoft Evaluation Licensing (see “Microsoft Licensing” on the Open Homelab Project for details on how to get these)
- Me with my knowledge of Windows, vSphere, PowerShell, PowerCLI, and how to Google for stuff.
- The community who not only kindly put content up on the internet for me to Google for but also are there for me to tweet, slack, and (shock, horror) talk to when I encounter problems or lose direction.
a.k.a. How I’m hoping to achieve those aims with those resources.
To do all this I’m starting out by preparing a vSphere template of Windows Server 2012R2. I can deploy this- with customisations- using PowerCLI to form the building blocks of the lab environment. Once I have Windows VMs deployed I need to be able to configure them- this is where PowerShell remoting will come in handy- I can deploy roles and features and do some basic configuration. I’ll put together a PowerShell function to do all that. This function can then be re-used in the script to deploy multiple VMs with different configurations. For example:
CreateVM "Server2" $TemplateName $CustomizationSpec "WDS"
I’ll use PowerCLI to deploy a private network within the Hypervisor and connect the VMs to it. This method will also be used to configure the connections to the gateway -one NIC pointing at the private switch and one at the internet-facing vSwitch already in place.
Some more in-depth PowerShell (possibly also arranged into reusable functions) to do the in-depth configuration of the roles. For example, when the script completes I want the Active Directory to be up and running, the Gateway providing an internet connection to the VMs, the VMs getting IP addresses from the lab DHCP and domain-joined. Basically I want to be able to run the script, make a brew, and come back and find a fully configured system ready to go.
Coming Soon- Part 2, full of scripting goodness.