When I was in Australia recently for the Sydney/Melbourne VMUG I had the chance to meet Alastair Cooke – and sit in on his presentation on AutoLab. Alastair is a VMware Certified Instructor (VCI) based in New Zealand, and is one of the hosts of the APAC VMTN Communities Podcast. In case you don’t know AutoLab is tool that will build for you using scripts a vSphere Lab environment – and its based on the principle of “nested ESX” or “vESX” – where ESX is run in VM on a physical ESX host. It’s was updated in Dec, 2012 to support vSphere 5.1.

I’ve had a renewed interested in homelabs, and how our vCommunity goes about learning new VMware technologies. That’s partly because I’m in that process myself as learn more about our vCloud Suite with a particular focus on vCloud Director at the moment. But its also because of my role here at VMware. I feel to some degree its my job to help/lead the community into learning more about our vCloud Suite, much in the way I did in the early days of ESX 2.x/vCenter 1.x back in 2003/4/5. That’s partly the reason why I’ve been looking at the concept of having “homelab” hosted in the cloud using just vESX – a concept I labelled “vINCEPTION” recently. If your interested check these posts out:

• Part 50: My vCloud Journey – vINCEPTION: Building vSphere vApp (1 of 4) – Physical Storage
• Part 51: My vCloud Journey – Building vSphere vApp in vCloud Director (2 of 4) – vESX in vCloud Director
• Part 52: My vCloud Journey – Building vSphere vApp in vCloud Director (3 of 4) – Accessing Physical Storage
• Part 53: My vCloud Journey – Building vSphere vApp in vCloud Director (4 of 4) – VM Networking

One idea I have is perhaps one of our vCloud Service Providers might offer a homelab-in-the-cloud as way of providing a service to the vCommunity. Whether they will is moot. It’s lot of expense for them, and they are “competing” with commiditized hardware – the PC. Perhaps there are too many in our  community who rather like the sanctuary of our man-caves filled with junk and PCs under the desk, rather than up in the clouds…?

At the VMUG I asked Aliastair whether he thought AutoLab would ever make into the cloud – he answered back – it already has by organization called baremetalcloud.com. I rather like the company name especially when we think of cloud we nearly always think of virtual machines, there are organizations are just as willing to deliver a physical server with the same ease of deployment as our beloved VM. The folks at baremetalcloud.com have an offering where you can order up a physical server, and they will deploy AutoLab for you. Building an AutoLab by hand with a powerful PC takes about 3-4hrs – building it with baremetalcloud.com about 30-40mins – and of course all you need is regular laptop and internet. I asked Alastair for introduction, and the guys offered me some credit to play around with their environment.

After that the Baremetalcloud folks have been kind enough to offer a special promo deal to mikelaverick.com readers – it’s just for the first 100 people so grab it while you can – the promo code is MAGICMIKE100

Initial Setup Routine:

After registering your account, and supplying your payment details – you get an email with your username and password. There is an official guide which you should probably bookmark and look at if you were going to use this service in anger:

Autolab 1.x running on baremetalcloud.com

1. Once logged in the “Add Server” option allows you pick physical server for your AutoLab – and hit the “Order” button. The recommended minimum is Dell M610 with 8GB of memory – of course the more your prepared to spend, the more resources you will have. I deliberately picked the lowest spec but according to the AutoLab an i7 CPU/16GB of RAM and an SSD of 120GB+ makes the whole experience a lot more responsive if you were building this at home. If you wanted to run ALL of the VMs in the AutoLab at the minimum memory assignments that would take around 16GB, leaving nothing to spare for your nested VMs. If you went for the maximum memory configurations (to improve the quality of your experience you would need more). Of course your nested VMs could be some uber-slim linux distribution such as SliTaz which when configured in a VM can take up as little as 128MB of RAM and 246MB IDE Drive.

2. Next you can select what will be installed to the physical server. There’s 4 options. AutoLab 1.0 is based on vSphere 5.0 and AutoLab 1.1 is based on vSphere 5.1. The “Tasks” is a reference to the AutoLab documentation which is broken up into a series of different stages called “Tasks”.

Task 1 leaves you with a very basic AutoLab configuration with many of the scripts that make up AutoLab to be run, whereas AutoLab 1.1 completes the vast majority steps – leaving you with a lab ready to power on. Why chose one over anyother?

Task 1 builds a basic AutoLab leaving the user to do remained of the build process which allows for more granular control over what to run and not run – for example you could do the install of vCenter manually because you want to learn this process or you could use a script to build vCenter instead. Task 5 builds an entire AutoLab environment would probably appeal to some one who needed to spin up a vSphere layer as quickly as possible ready to use the platform for some other task – like learning Horizon View or vCloud Director. I opted for AutoLab 1.1 and Task5.

3. This triggers a cloning process as baremetalcloud uses the open-source CloneZilla to quickly provision the entire AutoLab environment. Whilst this clone process is happen you can watch the status information, being a curious kind of chap I noticed the web-page allowed for DRAC connection (baremetalcloud uses Dell Hardware) to the physical server where I could watch the cloning process in action.

4. Once the cloning process has completed the physical host is given a public IP address, and random password is assigned to the root account. You can find out the IP of the host from the web-page by double-clicking it (or the DRAC Console windows) and the root password as well. It’s worth mentioning that the IP address the physical host receives is from DHCP server – so if your physical box is shutdown for a long period – you will find it comes up with a different IP address.

I was able to point the vSphere Client to the physical ESX host, and found the responsiveness pretty good considering the distances involved (I’m in the UK and my server is in Miami). The round-trip time from my colocation was 52ms, and from it was 140ms.  I setup a hosts file referrence for the ESX hosts, and reset the root password after my login had completed [bearing mind that the physical hosts IP address could change because this is assigned by DHCP address]

Note: Depending on the generation of AutoLab your using in the BareMetalCloud, you might find the NAS box is called either Lab_NAS or vSphereAutoLabESXi or just NAS. Either way its the first VM to be powered on, and provide NAS storage back to the physical ESX host.

In the AutoLab:

The next stage is powering up the VM that make up AutoLab – these have to be done a particular order – in fairness you should find all the VMs are powered up in the right already – just in case they are not:

1. vSphereAutoLabESXi (in different releases this maybe called the LabNAS. Its a copy of FreeNAS in a VM and offers storage to your ESX hosts it offers a NFS Target on 192.168.99.7 with export of /mnt/LABVOL/Build)
2. LabDC (Domain Controller!)
3. LAB VC (vCenter)
4. Lab Host 1&2 (vESX hosts in vINCEPTION Level1)

They are other VMs on the list – of course including:

• LabRouter – which allows for inbound/outbound access for the AutoLab
• Lab_V1/VBR – Veeam One & Backup & Replication VMs – Veeam are the main sponsors of the AutoLab
• CS1/CS2/SS1 – Two View Connection Servers and one Security Servers for Horizon View environment
• Lab_vCloud – a vCloud Director instance
• TTYLinux – Is a micro linux distribution that just takes up 32mb of RAM and 32mb of disk space. There other similar distributions available that are simpler – and I have couple to download from here under “Download“. In fact I was so inspired I did a little review of the distributions available, as well as packaging up some of these skinny-linux distros into VMware OVFs/OVAs in my download page.

[ASIDE]

The default password for most of the AutoLab systems is VMware1! – beware of the VMA which has password requirements that prevent this password for being used.

If you open a console on the Lab_DC you might be challenged to reset your password or you might like to… This because when AutoLab was designed no-one thought a lab would live beyond 60-days the default evaluation period for VMware products. I think its good practise to have your own unique “administrator” password for the lab itself as well as a unique password for your “vi-admin” account. If you login into the Lab_DC and Lab_VC allows you can to change the password for the accounts which is used to authenticate to vCenter. The “vi-admin” is also the account that backs the SQL installation on Lab_DC which is used by vCenter – so you might need to update the Services Account in the SQL Server Configuration Manager. I think its good step to run the “validate” scripts on the Lab_DC and Lab_VC VMs before doing anything just in case.

Note: If you not challenged for a password reset the default password for both LAB\Administrator and LAB\vi-admin is usually VMware1!

[/END OF ASIDE]

You can load up the vSphere Client on the vCenter desktop itself – and from there see the vESX environment. With the BareMetalCloud Task5 configuration the vCenter setup is done for you. I guess you could easily undo this by putting the hosts in maintenance mode, and deleting the cluster – and removing the hosts – this would leave you with a more “blank slate” style environment – alternatively you would use a Task1 build – and run through the AutoLab scripts. Once your into the vCenter configuration you should see two vESX hosts (host1.lab.local and host1.lab.local) together with a sample VM and sample template. Notice the vESX have just 2GB of RAM by default – and that will clearly limit the number of nested VMs you will get – as ever its all down to memory in the end. The more you have, the more you can assign:

Note: Remember default root password for these hosts is VMware1!

Shutdown and Cloning

It’s possible to shutdown the lab environment from a script on the vCenter Desktop, and also BareMetalCloud allows to capture your configuration. I’m think this cloning process would allow you to subscribe to small number of physical boxes, and just clone them for what ever purpose you were looking for.

You can trigger the shutdown process using option 7. This will shutdown everything except the Lab_Router and the Lab_NAS – these have to be shutdown manually.

Notice how you can enable a route to allow VMware Update Manager the right to download updates – that offer the tempting opportunity to upgrade the lab environment from one flavour of vSphere to another.

The Cloning of your current configuration can be triggered from their management page… Once an image has been created you can erase the disk – and use the physical box for another build or restore the image…

You can monitor the process from the same web-page, and by cranking up the DRAC on the physical server as well:

Conclusion:

So the big question. Is it worth it? This question is important because it strikes at the heart of any “homelab in the cloud” concept that is delivered either virtually (vINCEPTION concept) or physically (baremetalcloud.com).  The fundmental question I think a lot of people will ask  – is it more cost affect than having a homelab? Is it more flexible than homelab?

I guess much depends on hardcore VMware you really you are . I’m hardcore. But I do recognise that there some folks for whom VMware/Virtualization/Cloud is one part of what they do. Perhaps that VMware part of your work is a more modest one. If you are one of these people, and need to quickly spin up a VMware environment suitable for studying for the VCP then I think this approach might just work for you – especially if the requirements you have are modest. In fact most homelabs are pretty modest affairs, and could be less well spec’d than baremetalcloud or a homelab-in-the-cloud. There’s also the level automation that labs in the cloud offer – especially in them being reset when your done with them – that saves an awful lot of time in building and rebuilding your lab. Remember with something AutoLab+BareMetalCloud you can clone and save many different configurations simply and easily. How easy is that to do with your homelab?

The other thing that I think could be interesting is this. I imagine few employees could persuade their management to pay for the construction and maintenance of private home lab. After all the thing would be your asset, not the company. But, perhaps a manger would approve a monthly spend on a service – where the on-ramp in terms of costs is nominal  Heck, you might even get your lab through your corporate credit without having to even produce receipts for your expense system – it depends on what you limits are on the credit card. According to the folks at Baremetalcloud – their version of the AutoLab could cost as little as 0.50c an hour to run…

So folks who have ALREADY invested quite heavily in a homelab its hard to see how they would be tempted to move away from what they have – but for new home labbers I think things like AutoLab and/or baremetalcloud is most certainly worth looking at. What I love to see is more choice – with the vCloud Service Providers stepping up to the plate to offer a fully virtualized homelab-in-the-cloud. The trouble is – do they see a value in it? And for the homelabbers out there right now – do you love your mancave of bits cobbled together so much that you’d rather keep it than go to the cloud?