In january when I started my new job at Transcendent Group there were developers that needed a test / lab environment for testing Team Foundation Server and other products. Since we’re only ~40 employees we don’t have the manpower to manage stuff like this manually. What better way to solve this problem than building a private cloud with Hyper-V and System Center Virtual Machine Manager 2012?!
I started off with installing Windows Server 2008 R2 complete with all patches and drivers. After activating Hyper-V I attached an iSCSI-disk to the server for storage of virtual machines. This is also for future possibility to build a cluster, easily converting that storage to a CSV.
The first thing I did was to create a new VM and installed SCVMM 2012 in that one. With that in place I could start configuring both my Hyper-V environment and the SCVMM solution to enable our users to create, use and destroy their own lab environments. I’m actually running my VMM-instance in a virtual machine which makes it easier, and since I’m connecting my data disk through iSCSI it won’t matter if I move the VM to another machine.
I decided to have five different clouds. Three for general use and two “private” since we are two internal users that needed our own environments. I created five internal networks, LabNet01 – 05 and one external that connects to our production network.
In Hyper-V it looks like this:
In each cloud there is one Smoothwall which is a Linux-based firewall with a very small footprint. These are used just for routing but could easily be used to publish services from each cloud. I chose this setup so we could separate services like DHCP and other “disturbing” services from our production network.
There’s also one domain controller in each cloud, with different domain names. The domains are named lab01.local – lab05.local. This gives the users the ability to join their lab computers to a domain, without having to clutter our production AD.
The naming conventions are planned so every user that uses each environment easily knows which lab user has access to which cloud. In the SCVMM self service portal there are five user accounts that are tied to our production Active Directory. These are named labuser01 – labuser05 with a common password known to everyone, the labs are open for everyone and booked as rooms through Outlook.
Using the clouds
Using the system is a matter of booking a cloud in Outlook, and then logging into the self service portal.
Logged on as LabUser02, which gives access to Cloud02.
Logged on as LabUser03, which gives access to Cloud03.
When the user wants to create a new machine, the wizard for new machine in the portal is used. Since each user only has access to one cloud there won’t be any users creating VM’s in each others environments.
Access to the lab environment
Reaching the VM’s on the internal networks is either done through the portal, or for the users not wanting to use a browser, through an RDS Gateway. The gateway is connected to each of the internal networks witch makes it possible to connect to any computer on the inside once it has an IP address.
In this case we’re not using the same credentials for the remote computer as we’re doing for the gateway. This is because the gateway belongs to our production domain, but the remote server belongs to the lab domain. The RDS gateway settings can be found under the Advanced tab in the RDP-client.
With that we’ve constructed an enviroment which lets the users logon, create, use and destroy their own lab. In the next post we’ll take a look at more specific settings and group policies which makes life easier for both administrators and users of this environment.
[socialwrap align=”left” ] [socialicon name=”fb” /] [socialicon name=”linkedin” /] [socialicon name=”twitter” /] [socialicon name=”google” /] [/socialwrap]