HomeLab Mk.3 - Planning Phase

Background

I kicked off my homelab refresh project not long ago, dubbed "HomeLab mk.3" as its the third iteration since circa 2010. I'm now well into the planning phase but I've found that I'm also overlapping into the procurement phase (as described herein).

So far, I've decided to replace my pre-Ryzen AMD-based full-tower hyperconverged system with another hyperconverged system, but this time it will be housed in an 18RU rack for providing a small amount of noise management, but also neaten up the office a little, which will have the added benefit of assisting in home improvement (flooring) later.

Key requirements;

1. Costs must be kept as low as possible
2. Software RAID (due to #1)
3. Hyperconverged system (due to item #1 and power constraints)
4. Nested virtulisation for EVE-NG/network modelling

Therefore based on requirements, the system (excluding the rack) will comprise of the following;

• One SSD for the hypervisor stack/host OS
• Up to six (6) 8Tb CMR disks for the storage of guests etc.
• 4RU ATX rackmount case (including rails of course) ✅
• As much memory as the mainboard allows which relates to key requirement #4

Challenges

The current challenges surrounding the build are;

1. Choice of Hypervisor (oVirt, libvirt, OpenStack, EVE-NG)
2. Choice of CPU architecture (due to key requirement #4 and likely challenge #1)
3. Possible Network re-architecture required to support the system including possible infrastructure Re-IP addressing.

Choice of Hypervisor

For item #1 the choices don't look that great, and I will probably stick with libvirt and the various virt toolsets, only because;

• oVirt appears to no longer be supported downstream by RedHat which means contributions to the upstream project (oVirt) will likely and eventually kill the project
• OpenStack is a pain to set up, even the all-in-one "packstack" which also means that could impact scalability in future if required
• EVE-NG appears to be an inappropriate choice. While it supports KVM/QEMU/qcow2 images, I'm not sure I want this as the underlying HomeLab hypervisor (unless certain constraints can be overcome - these are considered not in scope of this post).

Choice of CPU architecture

For item #2 the CPU architecture is important only because network vendor (QEMU/qcow2) images highlight strict CPU architecture requirements as being Intel-based, and AFAIK nested virtulisation requires that the guest architecture matches that of the host.

Possible Network re-architecture

Item #3 is not insurmountable, but it is still a challenge nonetheless as I'm not sure about whether I will change the Hypervisor guest networks (dev, prod, lab etc) to connect back upstream at L2 or L3.

Procurement

As I mentioned already, the project planning phase is somewhat overlapping with the procurement phase, the reason for this is so that I can not only procure certain less tech-depreciating items over time to allow project budget flexibility, but also allow a certain level of reduced risk in operation of the system:

Case in point: HDD's - I never risk buying them from the same batch in case of multiple catastrophic failures.

I've already purchased 3 HDD's, the 4RU rackmount case and rails and an 18RU rack to house the new gear along with the existing kit (switch, router and UPS).

I'll continue to procure the HDD's until I have enough to build the system then all that left is to purchase the key parts for the rack mount case/system (CPU, mainboard, memory & PSU) once CPU architecture/hypervisor testing (see Hardware selection below) and the design is complete.

Hardware selection (CPU architecture)

In order to determine whether the new system will be Intel or AMD will depend on the testing performed on my AMD Ryzen-based desktop. If EVE-NG and the required images work in nested virtualisation (and/or bare-metal) with said CPU architecture, then I will be in a good position to stick with AMD for this iteration (and likely future iterations) of the HomeLab. After all, AMD-based systems appear to have a good pricepoint which relates back to key requirement #1

VMPlayer Anoyances

Here's something that I discovered whilst trying to figure out why I could only start some VM's and not others on an ntfs3g volume.

# cat ntfs3g.txt
If you are running your Virtual Machine on an ntfs3g formatted volume and you encounter the following error:

VMware Player unrecoverable error: (vcpu-0)
Failed to allocate page for guest RAM!
A log file is available in "vmname.log".  Please request support and include the contents of the log file.  
To collect data to submit to VMware support, run "vm-support".
We will respond on the basis of your support entitlement.

Try adding the following line to your VMX (configuration file):

mainMem.useNamedFile=FALSE 

NOTE: replace vmname with the name of your Virtual Machine.

I found this out from the following VMware Communities forum thread here

Adventures in Open Source (Part 1)

Welcome to the "Adventures in Open Source Series"!

Since buying my Dell XPS M1730, I have been using Gentoo Linux on it exclusively and with surprisingly good results, however I have also learned allot more about certain open source software package in general, so here I will outline some of the these (and also some of the failures) that I've experienced so far.

Screen
I have learned to use screen in a much more powerful way than ever before. Until now I was not aware of screen's configuration file capabilities, so had never used it. I found that not only can you make screen automagically setup all your screens for you, but you can also do some awesome console customisation as well (see my ~/.screenrc bellow).

screen -t default
screen -t "compile (emerge)"
screen -t config
screen -t rtorrent rtorrent
screen -t misc
hardstatus alwayslastline
hardstatus string '%{= kG}%-Lw%{= kW}%50> %n%f* %t%{= kG}%+Lw%< %{= kG}%-=%c:%s%{-}'

Here is a picture of what it looks like:

PS: This is actually in use on my fileserver (also a Gentoo box), hence the different hostname.

TrueCrypt
Since I almost lost my band new 8Gb USB mass storage device at UNI last week, I have decided to start using cryptography, so I remembered reading a planet.gentoo.org article about it and considering I am using Linux at home and Windows *shudder* Vista at UNI, I thought I would give this a try, Not just for portability and security but for any easy backup mechanism also (all I have to backup/synchronise one single file rather than managing lots of files and folders).

I followed the guide on the Gentoo Wiki here, and created a new volume now all I have to do is mount it and it's all there!

dean@quagmire ~ $ truecrypt -u /media/UNI/uni-2008-semester1.dat /media/UNI/uni
Enter password for '/media/UNI/uni-2008-semester1.dat':
dean@quagmire ~ $ ls -alh /media/UNI/uni
total 24K
drwx------ 6 dean dean 4.0K 1970-01-01 08:00 .
drwxr-xr-x 4 dean root 4.0K 1970-01-01 08:00 ..
drwx------ 6 dean dean 4.0K 2008-03-23 12:30 csg2207
drwx------ 7 dean dean 4.0K 2008-03-23 12:30 csg3308
drwx------ 7 dean dean 4.0K 2008-03-23 12:30 csi2102
drwx------ 7 dean dean 4.0K 2008-03-23 12:30 csi3207

And of course here's the proof that it's all working:

dean@quagmire ~ $ mount |grep -i truecrypt
/dev/mapper/truecrypt0 on /media/UNI/uni type vfat (rw,uid=1000,gid=1000,umask=077)
dean@quagmire ~ $

Wine
Well, as you may or may not be aware, my wine success has been pretty hit and miss (more like miss when it comes to M$ products and games), but this is due to the fact that wine is considered to be in perpetual development and the fact that I am trying to run proprietary software on a non-native platform *wink*

VirtualBox OSE
Alright, I must admit that I had an issue with this piece of software, but once I got it working it ran like a dream... I've been able to install Windows XP and (of course) Gentoo into Virtual Machines with no hassles whatsoever!



So it seems that I am not only more productive with a powerful Linux desktop, but I am also a much happier computer user as a whole even with the few "glitches" the arise every now and again.

If you learned something, enjoyed reading this article or have anything to contribute (or correct) ,feel free to leave feedback as comments on this post.


Coming soon: "Adventures in Open Source (Part 2)"!