Deploying the vCenter Server Appliance

Technorati Tags: vCenter Server Appliace (vCSA),vSphere 5.1,Single Sign On

When you deploy the vCenter Server Appliance there is a few things that you should verify first.  Proper Name resolution is a must so ensure that the DNS in your environment is properly configured and that you have created an A or host record for your vCenter Server Appliance and a reverse lookup or PTR record. 

The installation of the vCenter Server Appliance is a little unorthodox as you actually need to exit the initial configuration wizard to properly install vCenter Single Sing On (SSO).

vCenter Single Sign On is a part of VMware Cloud Suite.  Although it can be installed separately it is an integrated feature starting with vCenter 5.1.  For additional information on SSO please refer to VMware’s vCenter Single Sign On FAQ.

The reason you need to exit the configuration wizard is that SSO is largely based on tokens and certificates and therefore the hostname of the vCenter Server Appliance (vCSA) must be properly set and verified before SSO is initialized. 

Deploying the appliance from OVF is a matter of importing it.  Let’s look at the steps once you have imported it and it is booted properly.

The vCSA will use DHCP by default.  To begin the configuration browse to the assigned IP and specify the proper port 5480 (i.e. http://192.168.10.220:5480) as shown in figure 1.01

   figure 1.10

The default login is root with the password “vmware”.  The wizard runs and prompts you to accept the license agreement; accept it and click Next.  On the Configure Options page you are prompted to cancel the wizard and properly configure the hostname and static IP address first before proceeding as shown in figure 1.11.

figure 1.11

After you cancel the wizard, select the network tab and configure the hostname and network properties including the static IP as shown in figure 1.12. 

The one thing I have noticed is that the hostname does not always apply properly through the graphical user interface.  As I mentioned however; it is important that the hostname is properly applied before SSO is configured and initiated.

  

figure 1.12

The other item that seems to throw errors if not first completed on the command line is joining the appliance to the domain. 

You can join the vCSA and configure the hostname from the command line.  The process is similar to adding a vMA (vSphere Management Assistant) virtual machine to the domain and uses the same domainjoin-cli command. 

The domainjoin-cli command is included in the vCSA and can be found in the /opt/likewise/bin directory.

SSH is enabled by default for the root account so you can either use the console or SSH to the vCSA.  The default password for the root account is “vmware” unless changed.  Using the domainjoin-cli you can update the hostname using the command domainjoin-cli setname [hostname] as shown in figure 1.13.

figure 1.13

After the hostname is set you can use domainjoin-cli once again to join the vCSA to the domain using the command domainjoin-cli join [domain name] [administrator@domain] as shown in figure 1.14.  You will be prompted for the password to complete the process.

figure 1.14

Once you have completed these two commands successfully you can log back into to the GUI and complete the wizard to setup the database and configure SSO.  The wizard also enables the Active Directory however now it should complete with no errors.

When you login to the GUI you will need to rerun the Setup Wizard from under the Utilities pane by clicking the Launch button.

Under the Configure Options select the “Set custom configuration” and click Next.

If you are using the native SQL database select embedded (otherwise put in your specific database settings) from the Database type dropdown and click Next.

If you are running the SSO on the vCSA select embedded from SSO deployment type dropdown and click Next.

On the Active Directory Settings page, select the Active Directory Enabled and put in your Domain, Administrator User and Administrator password and click Next as shown in the figure 1.15.

figure 1.15

Review the configuration and click “Start” to begin the configuration.  Ensure everything installs, configures and starts correctly.

The setup automatically installs SSO with a random password.  As it is randomly generated you cannot install the vSphere Web Client in another location as the installation requests SSO Administrator name and password and Lookup service URL. 

You can verify the SSO Lookup service URL through the command line by running the following command cat /etc/vmware/ls_url.txt as shown in figure 1.16.

figure 1.16

As we are going to look at the VMware vSphere Web Client in the next post I will leave the configuration and details till then.

VMware View Building a Successful Virtual Desktop

I am happy to say the book release of VMware View: Building a Successful Virtual Desktop was officially launched on December the 4rth.  It is an interesting process writing a book and I can honestly say I have learned a great deal over the last year.  I consider myself extremely lucky to have had the privilege of working with my team. From the initial acceptance of the project by Joan Murray, the Editor/Program Manager with Pearson, and her support throughout the process, and the tireless efforts of Eleanor “Ellie” Bru, my Primary technical editor, I am deeply grateful.

I also had great support from my two technical content reviewers: Stephane Asselin and Shawn Tooley. Stephane was a direct contributor to Chapter 5 and offered his expertise in all matters related to VMware View. Stephane is a leading expert in VMware View working with VMware. Shawn Tooley is a published author himself, and his suggestions greatly contributed to the polish of this book. I also want to thank Seth Kerney, who worked hard to put this book together.

I would also like to thank everyone for their feedback and support in the community.  I had the opportunity to discuss the project with Mike Laverick, who needs no introduction because of his extensive contributions. He offered many words of wisdom based on his broad experience which helped refine our approach. 

Federate Now; Extending to Cloud

Moving towards the IT as a Service (ITaaS) model is a complex process for most organizations.  It requires changes in technology, processes and skill sets.  As the current climate makes expenditures difficult, many IT departments are reluctant to start any major transformation.  The hunker down and ride it out mentality is delaying many strategic initiatives that would move IT departments closer to a Service Provider Model.

The overwhelming number of decisions on how to become more service orientated often delay any meaningful plans to get started.  Delaying however is just as hazardous as users become disenfranchised with internal IT and start to leverage unsanctioned Cloud services.  There is a better way which allows you to integrate the benefits of Cloud without having to work through all the complexities. 

As part of VMware’s vCloud Platform, VMware provides Cloud Connector.  Implementing Cloud Connector allows IT departments to federate their on premise Private Cloud with a VMware Certified Cloud Provider.  Most VMware Certified Cloud Providers have several different Cloud models; from traditional virtual infrastructure based on VMware vSphere to more self-service platforms based on vCloud Director.  The self-service models tend to take a more metered approach to billing, charging based on utilization vs. a flat per VM price.

Federating or connecting your traditional vSphere environment to a VMware Cloud Providers vCloud Director environment allows you to turn up certain Cloud like features for select workloads quickly and efficiently.  vCloud Director and Cloud Connector are designed to plug into enterprise private cloud environments. 

Unlike other Cloud services that are focused on the end user and do not provide an administrator console, vCloud Connector plugs into vCenter.  This allows you to continue to manage your Cloud virtual resources in the same manner and with the same toolsets as your current on premise environment.  You can still offer user self-service through the vCloud Director portal but administration can look and feel the same.  You access the vCloud Connector plug-in from your vSphere client; the vCloud Director resources appear as an extension of your environment as shown in figure 1.01.

figure 1.01

While this does not negate the need to deliver on ITaaS, it does enable a quick method of plugging in and turning up Cloud features while or in lieu of transforming your existing environment.  It also allows you to be very selective on what workloads you apply these Cloud features to.  This allows you to assess the business value without a large upfront commitment. 

I believe Cloud is forcing IT departments to rationalize which services they are extremely good at and which they should be looking for assistance on.  At the two ends of the spectrum are in-house and outsourced.  Recognize that federating provides a good middle ground in which you centrally manage the combination of services that you provide.  In this way you become the primary service provider to your organization while delivering a wider range of services but avoiding the development cost and time.