This is the third part of my series on building my lab environment. In Part I, I laid out the hardware that I would use for my lab. Part II covered the installation of VMware vSphere 5 on the hardware. In this post I will cover the vSphere 5 network settings.
Configuring the vSphere 5 switches
I created two vSwitches with no physical adapters for my Development and Production LANs. The reason I created two vSwitches with no physical adapters was for two reasons.
The first and primary reason is that on my home router I have MAC address filtering turned on. I turned this on for better security for my Wi-Fi connections, but as it turned out, it also enabled filtering on the physical connections as well. If I used the default vSwitch0, every time I create a virtual machine, I would have to add its MAC address to the router as well as a DHCP reservation.
So after putting together all the hardware that I listed in Building My Lab Environment – Part I: The Hardware, it’s time to install vSphere 5.
As far as the BIOS goes, there was only three things I changed from the defaults.
- I set the CD-ROM to be the first boot device
- Set the system time and date to current
- Enabled VT-D – This allows virtual machines direct access to hardware. For instance I have three physical hard drives. One of them controlled by vSphere and setup as a datastore. I could then create an OpenFiler virtual machine that connected directly to and managed the remaining two physical hard drives. Then I could create LUNs and add those back to the vSphere server as iSCSI datastores. It’s a bit convoluted, but this would allow all the tinkering and benefits of a SAN, without the extra physical server. The physical drives are still there, it’s just the OS that is managing them is virtual.
VMware has a “Performance Best Practices for VMware vSphere 5.0” document that goes into great detail on things like BIOS settings, virtual machine configurations and more. You can find it on their site here.
Now on to the installation.
In order to build and deploy STIG images for testing (which is the whole reason I started this blog) I need a lab environment to work in. This is the first part of a series that will cover how I set up my lab and the reasons for some of the choices I made.
This particular post will focus on the hardware I chose for my lab.
For the past 12 years, I have primarily worked in the IT field for the Department of Defense. I’ve done helpdesk, helpdesk supervisor, data warehouse developer, data analyst/report developer, and systems administration. I started this blog to document and share what I have learned about different topics in the IT field. Hopefully some of what I have learned I can pass on to others and likewise get useful feedback or alternative ways to proceed in different areas of interest to me.
Some of my areas of interest that I will no doubt be going into here are system imaging and deployment, STIGing and installing applications on STIGed servers, ITIL, data warehousing, SQL Server Integration Services, and whatever else tickles my fancy.
Due to some of my recent work, and the lack of useful resources on the internet, I’m going to be building a STIGed lab environment for testing and to work out what modifications are required to get different applications to run in a least privilege setting. One such setting is FIPS. FIPS is a U.S. government security standard that, when enabled, prevents some applications from working correctly, one of them being SharePoint. By finding these different incompatibilities and documenting them, it will both make my life easier at work as well as increase my knowledge. It will also provide a resource for others in the same situation to get their applications installed and documented.
For the record however, I am by no means a security expert nor have I ever worked in the security field. My posts come without warranty and I am in no way responsible if you bring down your network. Always test in a lab environment first. 🙂