Many, many moons ago I played with vCloud Director 1.0 that was when I was affliated to TechTarget and still an independent guy. Back then your only option with vCloud Director was setting up two instances of Linux – one to be the first vCD “Cell” (cell is the term describe an instance of vCD, and you can have more than one “cell” or vCD instance in the same namespace – and load-balance and offer high-availability) and the other to hold the Oracle Database for vCD. Since I last looked at vCD you can now download it as pre-packaged appliance. That makes the configuration so much easier than my previous attempts. In my previous attempts with vCD I used Oracle XE inside an Oracle Linux instance – with the vCD appliance it looks as if Oracle XE has been embedded into the appliance itself. I opted for the vCD appliance because I’m just learning about key concepts and management – and don’t require a “multi-cell” configuration – remember the vCD appliance is just for evaluations right now, and not intended for production use. But I don’t think it would take a rock scientist to work out that could easily change in the future. It’s not like we have been keeping our virtual appliance vision a secret or anything. Please don’t take that last comment to mean something – could doesn’t mean it will. And it’s not like I have any say about those sorts of decisions within VMware! :-p
So for right now the vCD appliance is great for home labs, PoCs perhaps and demos. OK?
Just like any appliance when import it you can configure the IP addresses. As you might know vCD has two NICs – one for management of the “cell” and one for what’s called the “Console Proxy”. This is used to broker “remote console” sessions to VMs within vCD (aka getting a window on a VM). So you will need a portgroup on a vSwitch for Management and portgroup for the Console Proxy. I registered the management IP address with my DNS and I was ready to start the first part of the post-configuration in the faction of the time compared to when I was installing vCD into Linux.
So One vCD server, many equals a vCD “Cells” – they offer availability and when load-balanced scale-horizonitally. Each cell is connected to a back-end databases and web console from which to do management. There’s support for a representational state transfer or REST-based API. At the ESX level – rhe vCloud Agent – known as VSLAD is installed to each ESXi host its job is to implement and expose host-level functionality that is not available on a regular ESX/ESXi host and/or is not accessible through the VIM API. Even in a multi-cell environment – only one cell listens for vCenter information. vCenter Proxy listens to vCenter – and send those on to service called VC Control – it decides which vCenter gets the instructions from vCloud Director. VC Inventory inventory caches vCenter information – and auto updates if things change.
Accepting the EULA and adding in the license key is simple affair as you’d expect. The next step “create the system administrator account” creates a local administrator to the vCD “cell”, but it is possible to add in other directory sources such as Microsoft AD, and give those accounts rights. This system administrator account is a super-user has rights throughout the whole of vCloud Director – so lets justs say “P@$$w0rd” isn’t the best one to use, right?
The system settings allow you to set the system name and installation ID. These have to be unique because vCD has it own pool for allocating MAC address. This needs to be unique for each cell or instance that is created and subsequently added to the “cell” cluster.
