If you listen to or attend the #vBrownBags on a regular basis, then chances are you’ve heard of the AutoLab. If you haven’t, then allow me. DUDE, you should check out the AutoLab! 🙂
The AutoLab is brought to you by APAC vBrownBag host Alastair Cooke (web/twitter), and our mad genius behind the boards, Nick Marshall (web/twitter). Its mission is simple: to provide an easy way to deploy a vSphere lab on ESXi or Workstation. If you have a laptop with about 8GB RAM and a modern CPU, then you can probably run the AutoLab! Sure, it won’t be like running a quad-socket 8 core beast with 1TB of RAM and EFD, but it’ll get you labbing, and that’s all that counts. If you’d like to get started, head over to labguides.com and download the AutoLab. I won’t go into detail on getting it setup, but I do want to outline a few minor alterations I did to get vCloud Director up and running.
First, I changed up the way Workstation manages the memory. I only have 8GB of RAM in this laptop, so overhead is a bit tight, especially if I’m running my WinXP VM as well, which I use as a personal VM inside my corporately imaged laptop. The AutoLab instructions say to go into Workstation’s Preferences menu and set the memory to “Fit all virtual machine memory into reserved host RAM”, which is essentially a memory reservation within Workstation. That approach works well, and I imagine that it helps to reduce swapping, especially on computers with spinning disks. Since my laptop runs SSD, I wanted to have more VMs running at once without having Workstation complain about running out of memory. I changed the memory setting to “Allow most virtual machine memory to be swapped”.
Another change I had to make was to increase the memory allocated to the Host1 and Host2. Staying with the default 2GB works for vSphere labbing, but once you install vCloud Director, you might want some memory available to power on VMs within vCD. I also went into the DC VM’s DHCP panel and increased the lease times. My reasoning for that is since I’m using the vCloud Director appliance; it does all of it’s setup business based on the DHCP addresses it receives at first power-on. If those addresses change, your vCD won’t run. Sure, you can go in and fix it, but it’s a PITA (IMO), so why bother? 🙂
After your AutoLab is setup, download the vShield Manager and vCloud Director appliances. The vShield Manager appliance has a EULA that goes crazy on my copy of Workstation, so I “fixed” it by unzipping the ova (it’s a zip file, after all, just a different extension), deleting the .mf & .cert files, and removing all the text between the <License> tags within the .ovf file’s XML. Before you delete the EULA, you should probably read and understand what you’ll be agreeing to. 🙂 Don’t bother rezipping into an .ova, just open the .ovf file with Workstation, agree to the now non-existent license (remember, you agreed when you read then deleted it) and let the install complete. Once it finishes, change the network from Bridged to the VMnet3 you created when you deployed the AutoLab, and set the memory to 384MB instead of 3GB. Power on the vShield Manager VM and wait for the startup to complete. Login to the vShield VM using the credentials of admin/default, enter privileged mode with the en command and the password default and type setup. You’ll be presented with a setup wizard of sorts; I used 192.168.199.8 for the IP, 255.255.255.0 for the subnet mask, 192.168.199.2 for the gateway, 192.168.199.4 for DNS, and lab.local for the DNS domain search list. After the vShield Manager setup completes, go over to the DC VM’s DNS panel and create a forward and reverse lookup for the vShield Manager VM, whose hostname will be manager by default. You may also want to setup a DHCP reservation for that IP address (if you want to be extra sure it won’t lose its IP); you can find the vShield Manager’s MAC address by logging into privileged mode and issuing the command show interface.
If you haven’t installed vCD previously, or if you have previous vShield experience outside of vCloud Director, the process is a bit different when using vShield in conjunction with vCenter. First, you won’t need to register your vShield Manager VM within vCenter, as it will be controlled by vCloud Director. Second, if you need to license it for whatever reason, the licensing is handled via vCenter’s Licensing panel. vCenter becomes aware of it once you connect vShield to vCloud Director and vCloud Director is connected to a vCenter.
Next up, open the vCloud Director appliance’s .ova file and add it to Workstation. Be sure to change the two bridged network adapters over to VMnet3, or your appliance will either wait forever for an IP address, or get one from the DHCP server on your Workstation’s LAN. Either way, at this point it’s simpler just to delete the VM and start over. The vCloud Director initial setup will take a while, so be patient until it completes. Interrupting it will most likely break it, so you’ll be back to the “delete and re-install shuffle” if you’re impatient. You’ll know it setup correctly if you can browse to the address displayed on the VM console (minus the 5480 port) and see the vCloud Director setup page.
At this point you can complete the vCloud Director web-based setup, but don’t go so far as to connect vCenter. If you have any troubles with name resolution to either vCenter or your vShield Manager VM, check DNS. When that is done, hop back over to the vCloud Director VM’s console and choose the Configure Network option. Change the hostname to something other than localhost, take note of the IP addresses it pulled from DHCP, save your changes and exit the network configuration screen. Next, choose the Login option, use the root/Default0 credentials and issue the command ifconfig to get the MAC addresses for the network interfaces if you want to do DHCP reservations over on the DC VM. You will want to add forward and reverse DNS records for the vCloud Director VM.
Once all the setup is completed, you can head over to the VC VM and use that to launch the vSphere client and point the browser towards the vCloud Director web page. If the rest of your lab is up and running, feel free to connect vCenter and start building out your provider virtual datacenter.
Happy AutoLabbing!
hi all,
How connect auto lab v0.8 on vCloud Director .please help ………………………
I tried getting the vCD 1.5.1 Virtual Appliance setup on Workstation 8 just like you described, but I can’t get the vCloud Director application URL to come up. I noticed that upon statup, the vaos service comes up with the following:
Waiting for network to come up (attempt 1 of 10)…
No value found
No value found
This script is executed on all boots, except the first one.
On ESXi 5, this is the output for vaos:
Waiting for network to come up (attempt 1 of 10)…
Appliance Name – VMware_vCloud_Director
Configuration for eth0 found
Configuration for eth1 found
Device : eth0
Ip : 192.168.2.230
Netmask : 255.255.255.0
Gateway : 192.168.2.1
Device : eth1
Ip : 192.168.2.231
Netmask : 255.255.255.0
Gateway : 192.168.2.1
Dns : 192.168.2.254
This script is executed on all boots, except the first one.
My hunch is that in ESXi5 the OVF settings are saved and read for vaos, as the options tab in the VM properties displays the OVF settings that were collected in the import wizard for the OVF. But since Workstation 8 doesn’t have a place (that I am aware) to keep the OVF settings, vaos can’t find the values.
Curious to see what’s different about your setup to make it work. Any info would be much appreciated. Thanks,
Hi Chris – thanks for commenting!
TBH, I haven’t tried the 1.5.1 vCD OVA, but this walkthrough was done with 1.5.0. I have manually upgraded the appliance to 1.5.1, FWIW.
When you did the first power-on of the vCD appliance in Workstation, were both NICs connected to a network with a DHCP service available? If there was no DHCP service, then I don’t believe the vCD appliance installs correctly. If you’ve changed virtual networks, or tried to change the IP address(es) of the appliance, I’ve had to re-run the vCD configuration script to rebuild the SSL certificates and get everything connected properly.
1.) Login to the appliance using root/Default0
2.) service vmware-vcd stop
3.) /opt/vmware/vcloud-director/bin/configure -r /opt/vmware/vcloud-director/etc/responses.properties
4.) service vmware-vcd start
Hope this helps!
Damian, I tried many different ways to no avail:
– vConverted a working vCD VM off a ESXi 5.0 to Workstation 8
– Install a new VM on Workstation 8 with Bridged NICs and received/used the DHCP addresses
– Install a new VM on Workstation 8 with Net3 and later configure IP addresses
– /opt/vmware/vcloud-director/bin/configure -r /opt/vmware/vcloud-director/etc/responses.properties (but the response.properties file is not found)
I have an ESXi 5 host as noted, but in order for the vCD agent to install, the ESXi host has to be put into maintenance mode and that cannot be done with running VMs. What I have done to get around this was temporarily use another computer I have and install ESXi on a USB key to run the vCD appliance, vCenter VM, Active Directory DC VM, and vShield VM off of just to get the darn agent installed. I have moved all the VMs back to the intended ESXi 5 host. But it was a lot of work and copy time. Let me know if anyone else knows how to use a single ESXi server with all the vCD 1.5.x and vSphere components already on the host to work without having to put it into maintenance mode.
Thanks,
Chris
I use the AutoLab on Workstation 8. The router, NAS, DC, VC, and 2 host VMs run alongside the vCloud & vShield Manager VMs. That way, I can add the cluster to vCloud Director and the agent will install just fine with them in maintenance mode. The only other way that I could think of running everything on a single ESXi host would be to nest ESXi (providing you have the proper CPU and virtualization features supported). You can read more about that at @lamw’s site: http://www.virtuallyghetto.com/2011/07/how-to-enable-support-for-nested-64bit.html. Basically, you’ll have a physical ESXi host and multiple virtual ESXi VMs running alongside domain controllers, vCenter, vShield, etc. as needed.
As for the responses.properties file not being found, it should be there if the automated vCD first-time install completed. FWIW, it’s there on 1.5.0 — I don’t have access to a 1.5.1 OVA, but I wouldn’t imagine that behavior would change.
I hope this helps! If you’re on Twitter, hit me up at @sixfootdad if you’d like.
D
Thanks Damian. Your steps in the comments helped me with my vCloud director appliance issue. 🙂
Screen shots would be nice for the users. What do you think Damien? But still the post is rocking.
Hi Damian,
Thanks for your writeup on the AutoLab.
We might use your knowledge to integrate a vCD “option” to the scripted install at some point. There’s also plans to add a VMware View option after we release v1.0 too.
As this is a community project, any ideas or help are welcomed! Email Alastair and I: feedback@labguides.com
Cheers,
Nick Marshall