Installing VMware View starts with the installation of vSphere and related components. With vSphere 5, there are two options for vSphere: installable and embedded. Installable is an installation of vSphere ESXi because vSphere 5 no longer supports ESX native or the version that had the console operating system (COS) for management purposes. You can download the ESXi binaries from VMware at https://my.vmware.com/web/vmware/try-vmware or order the server with the embedded version.
If you download the binaries, it is possible to create a manual embedded version by installing to a USB drive in an internal or external port on the server. The embedded version is supplied by the hardware vendors and incorporates their specific tools to enable greater visibility on the hardware and software layer. For example, you can download an ESXi version from HP, Dell, IBM, and CISCO. One of the drawbacks of the embedded option is that the build from the vendor may not have the latest and greatest utilities or tools. With vSphere 5, this issue is addressed by providing an automated build option that allows you to add OEM packs to the installation. Let’s review the installation:
To install ESXi installable, follow these steps:
Boot from the ISO file. After it boots, the splash screen comes up, and the necessary files to start the installer are loaded, as shown in Figure 3.36.
Figure 3.36. ESXi splash screen.
You can maneuver around the installer by using the Tab key. To continue the installation, press the Tab key and press Enter on the keyboard, as shown in Figure 3.37.
Figure 3.37. Select Enter to continue.
Press F11 to accept the license agreement shown in Figure 3.38 and continue.
Figure 3.38. Press F11 to accept the license agreement.
Select a disk to install or upgrade, as shown in Figure 3.39. It is considered a best practice to install vSphere ESXi first before presenting storage so that you can be assured that you are installing ESXi on the right drive unless you intend to boot from SAN. Once you have selected the drive press Enter.
Figure 3.39. Select the storage device where you would like to install ESXi.
Select the correct keyboard layout (US Default), as shown in Figure 3.40, and press Enter to continue.
Figure 3.40. Select the keyboard layout.
Specify a password for the root account, as shown in Figure 3.41, and press Enter.
Figure 3.41. Specify the password.
Confirm the parameters, as shown in Figure 3.42, and press F11 to begin the installation.
Figure 3.42. Press F11 to install.
If you are installing ESXi to a USB stick, you need to verify that your server is on the supported Hardware Compatibility List (HCL) and that the USB device is supported by the server vendor. If both conditions are met, the USB device shows up as an installable location. Rather than select a local drive, you can select the USB location to install ESXi. For detailed instructions, refer to VMware’s Knowledge Base article located at http://kb.vmware.com/selfservice/documentLinkInt.do?micrositeID=&popup=true&languageId=&externalID=2004784.
One of the other options you have is to use the new Auto Deploy feature, which essentially allows you to provision a vSphere 5 ESXi Server and apply the configurations in an unattended manner through the Configuration Manager to create a truly stateless host. Why would you use Auto Deploy in a VDI environment? VDI is a technology that scales quite quickly. To reduce the time it takes to provision additional capacity, Auto Deploy may be a good option. In addition, it allows you to design the ESXi configuration once and have it consistently applied across the board. It does require extra consideration if you are going to run vCenter in a virtual machine, however.
When you use Auto Deploy, you are creating a major dependency on the service for all hosts that are set up to use it. You therefore need to run two ESXi hosts that are not dependent on Auto Deploy in a cluster. A separate cluster ensures that your vCenter and Auto Deploy Server can reside on a set of hosts that are running vSphere HA with the boot priority properly set on the VMs so that the service is readily available all the time. Before we get too far ahead ourselves, though, let’s look at the requirements and process.
To deploy the Auto Deploy feature, you need a few additional components:
- PowerShell installed on the vCenter Server
- The PowerCLI from VMware
- A TFTP Server for downloading the files
- The ESXi downloadable files (The files can be downloaded from the VMware website.)
Using the vCenter that you have installed and running, you can add these additional components to take advantage of rapid provisioning of stateless ESXi hosts in the VDI environment.
The architecture of Auto Deploy is made up of the following components, also shown in Figure 3.43:
- A TFTP Server to store the boot loader files
- Attributes in the DHCP scope to identify the TFTP Server and boot loader files
- Rules in the vCenter Server Auto Deploy feature to associate a physical ESXi Server to an image file
- A software depo where the ESXi installable files are located
Figure 3.43. Auto Deploy components.
Let’s enable and step through each of the components.
PowerShell is included in Windows 2008 R2, but you do have to add it as a feature. PowerShell should be installed on the vCenter Server along with the VMware PowerCLI. To install PowerShell, follow these steps:
- To add PowerShell, open Server Manager.
- Browse to the Add Features module and right-click Add Feature.
- Select the Windows PowerShell Integrated Scripting Environment.
- Click Install.
- Open a PowerShell script window, browsing to Start\Programs\Administrative tools and opening a Windows PowerShell Module.
- Enable the PowerCLI by changing the remote execution policy for scripts by typing Set-ExecutionPolicy RemoteSigned. This allows scripts that are not signed by a vendor to run on the vCenter Server.
You can download the VMware PowerCLI directly from VMware. After downloading it, simply follow these steps to install it properly:
- Run the VMware Power CLI executable.
- Click Next on the Installer screen.
- Click Next on the Patent information screen.
- Accept the license agreement and click Next.
- Accept the default location and click Next.
- Click Install.
- Click Finish.
To get the boot loader files, you need to install the plug-in in vCenter for Auto Deploy. You can install the plug-in using the VMware vCenter Installer:
Click the VMware Auto Deploy, as shown in Figure 3.44, and click Install.
Figure 3.44. Select VMware Auto Deploy.
- Choose the setup Language and click OK.
- Click Next on the Auto Deploy Installation Wizard.
- Click Next on the patent information screen.
- Accept the license agreement and click Next.
- Accept the default location and set the Auto Deploy Repository location and size. The default repository size is 5 GB. Because Auto Deploy is being used to provide ESXi images, the default size is sufficient.
Enter the IP address or hostname of the server, leave the default HTTP port, and enter the username and password. Then click Next.
- The default Auto Deploy Server Port is 6501. Leave this setting and click Next.
Specify how vSphere Auto Deploy should be identified on the network and click Next.
My recommendation is to use the IP address so that name resolution is not required for the deployment server to run.
- Click Install.
- Click Finish.
When you reconnect to vCenter, you see a new administration plug-in called Auto Deploy. Launch the Auto Deploy plug-in, which should look similar to the one in Figure 3.45.
Figure 3.45. Auto Deploy appears under Administration.
The plug-in displays the boot loader filename, which in this case is undionly.kpxe.vmw-hardwired. The boot loader files can be downloaded from here, as shown in Figure 3.46.
Figure 3.46. Download bootloader files.
Now that you have the name of the boot loader file and the zip files containing those files, you can set the attributes for your DHCP scope and unzip the files on your TFTP Server. The files are downloaded as deploy-tftp.zip. When you unzip them, by default, they are placed in a subdirectory of your root folder (deploy-tftp) on your TFTP Server. To ensure you can find the files, unzip them in the root directory of your TFTP Server without the default subdirectory.
It is recommended that you restrict your Auto Deploy process to a service network. This means that your builds should happen on an isolated network segment separate from your production network. By doing so, you ensure that even though the building of an ESXi host involves a very small image file, the downloading and installing do not interfere with production traffic. In addition, DHCP is required for this process to work. From a security perspective, DHCP traffic should not be run on the same network as your ESXi management traffic. If you do not have the flexibility of separating your management and Auto Deploy service network, use nonroutable IP addresses to build the hosts and then apply production IPs afterward. A separate Auto Deploy network may require a dedicated port group on your vSphere ESXi vSwitches, so make sure that you build this into your planning.
When the boot loader files are in place, update options 66 and 67. In a Windows-based DHCP Server, follow these steps:
- From the DHCP Management Utility, browse to the scope that you will be using to enable the Auto Deploy process.
- Expand the scope and select Options. Then right-click and select Configure Options.
- Under Available Options on the General tab, select 066 and add the IP address of your TFTP host under the string value.
- Select 067, and under the string value, add the name of the boot loader file, which in this case, is undionly.kpxe.vmw-hardwired.
- Click OK.
At this point, you should have the boot loader process running. If you boot a physical server, it gets a DHCP address, contacts the TFTP Server, and downloads the boot loader file. It connects to the Auto Deploy service on the vCenter Server and halts because no rules have been configured to tell the server which image profile is assigned to the host. After downloading the boot loader file, the server contacts the vCenter Server but stops because the image profile has not been assigned to the host yet, as shown in Figure 3.47.
Figure 3.47. The server contacts vCenter.
To complete the Auto Deploy configuration, you must run some PowerCLI scripts from the vCenter Server to specify a software depo. Extract the ESXi downloadable images into the software depo and create a rule to associate the image with an image profile. The final step is to make this the default image profile.
Log in to your vCenter Server and start the PowerCLI interface. If you get an error message, it is likely that you have not set the execution policy properly in PowerShell. In this instance, run PowerShell and set the execution policy, as shown in Figure 3.48:
Figure 3.48. Set the execution policy to unsigned.
This command allows code that has not been signed by a trusted publisher such as Microsoft to run.
Run vSphere PowerCLI and connect to your vCenter Server by typing Connect-VIServer [servername], which results in the output shown in Figure 3.49.
Figure 3.49. Connect to your vCenter Server.
After you are connected, you need to create a software or repository. You do this by running the Add-EsxSoftwareDepot command along with the path to your ESXi downloadable files. For example:
After creating the software depo, you should verify it is set up properly by running the Get-EsxImageProfile command. The command should return information on the image profiles available in the software depository, like those shown in Figure 3.50.
Figure 3.50. Image profiles.
Although the initial images are fine for a proof of concept, you need the vSphere HA modules for production deployment. These modules are part of the Auto Deploy software depot and can be added by running Add-EsxSoftwareDepot http://vCenterServer/vSphere-HA-depot. The output is shown in Figure 3.51.
Figure 3.51. Add the software depository URL.
To add the HA options, add the HA software depot on the vCenter Server, as shown in Figure 3.52.
Figure 3.52. Add HA to your ESXi image.
After adding the HA files, you need to create a copy of the existing images so that you can add the new files to it. To take one of the existing images and clone it, run the following command:
PowerCLI> New-EsxImageProfile -CloneProfile ESXi-5.0.0-469512-standard -Name "ESXi-5.0.0-469512-HA"
In this example, you are taking the ESXi-5.0.0-469512-standard image and copying it to one called ESXi-5.0.0-469512-HA, shown in Figure 3.53 (Note that the HA components were not included in the original ESX software depo zip files, but now they are).
Figure 3.53. Make a copy of the original image.
If you rerun the Get-EsxImageProfile command, you see an additional image profile. You still need to add the vmware-fdm or HA package to the image. You do this by running the following command:
PowerCLI> Add-EsxSoftwarePackage -ImageProfile "ESXi-5.0.0-469512-HA" -SoftwarePackage vmware-fdm
After verifying that the software depository is working and that you have images available, you can create a deployment rule. The syntax for creating a deployment rule is
New-Deployment—Name "Name of Rule"—Item "Image Name"
You have the option of pattern matching or making this image file available as the default by adding switches. The –Allhosts switch applies the rule to any server, and the –pattern switch allows you to specify specific attributes to match, such as vendor=VMware, Inc. You can concatenate multiple patterns by separating each with a comma. Perhaps the most useful of the patterns is specifying an IP range. If you have separated your build network and use a set range of IP addresses, you can restrict the build process to that range.
The syntax used in this example is as follows (see Figure 3.54):
PowerCLI> New-DeployRule -Name "ESXi Default Build v.01" -Item "ESXi-5.0.0- 469512-HA" -Pattern "ipv4=18.104.22.168-22.214.171.124"
Figure 3.54. Associate the image to an IP pattern.
After creating the build rule, you must activate it. The command to activate it is Add-DeployRule –DeployRule “Name”, as in this example:
Add-DeployRule –DeployRule "ESXi Default Build v.01"
One point to keep in mind with Auto Deploy is that the deployment can generate a significant load on the Auto Deploy service. Because the location of the image file is essentially a web server, it is possible to use reverse proxies to offload some of the overhead. A reverse proxy can also store the image file. It is possible to redistribute the load to the reverse proxy by editing one of the boot loader files. If you go into the TFTP root directory and edit a file called tramp, you can specify alternate locations. If you open the tramp file, you can easily specify alternate locations, as shown in Figure 3.55.
Figure 3.55. Edit the tramp file.
After you set up Auto Deploy, essentially you have ESXi Servers that are running, but they do not yet have a production configuration applied to them. The other component to vCenter that you need to integrate is host profiles.
Host profiles allow you to create a set of configurations that can be consistently applied across the environment. They eliminate the manual configuration of ESXi hosts on an individual basis. Host profiles also allow you to force compliancy across your environment because after a host profile is associated, any changes made are identified and remediated. Because Auto Deploy essentially creates an installed ESXi, you need to use host profiles to apply a consistent production configuration. There are two ways to configure a host profile: You can import an existing profile through the vCenter console or create one from an existing ESXi host. Unless you have a company standard (and this should be adjusted for a VMware View environment), the easiest way is to just configure an ESXi host as you would like and create one from the host. A host profile assumes that the EXi hosts are configured the same way, so it is important to have everything configured properly on your reference ESXi Server.
Using host profiles is a four-step process:
- Create a reference profile from an ESXi host.
- Attach the profile to an existing host or cluster.
- Run a comparison against the hosts assigned to the profile and the profile itself.
- Apply the profile to fix any differences between the assigned hosts and the profile.
The actual process is as follows:
- From vCenter, navigate to Home, Management and Host Profiles.
Click the Create Profile button and provide a name and description for the profile, as shown in Figure 3.56. Then click Next.
Figure 3.56. Create a host profile.
You can edit the profile to make any additional changes. Simply open the profile and expand the profile policies to update the settings, as shown in Figure 3.57.
Figure 3.57. Expand the profile policies to edit settings.
- You can select to attach the profile to an ESXi host or cluster.
- After attaching the profile, click Check Compliance.
- If anything is noncompliant, click Apply Profile to have the changes made.
At this point, you have deployed vCenter and have the ESXi hosts coming online. Now make sure that the reference server is properly configured before you build your host profile. For an ESXi Server, you should ensure that the storage is properly attached and that key features such as VMotion and DRS are set up and working. Let’s review each of the technologies and the configuration so that the reference server is representative of what you want in production.
VMotion allows the virtual machine to be hot migrated from one ESXi host to another. To set up VMotion properly, you must make sure that any ESXi host you are migrating to and from has access to the same storage. ESXi supports just about every type of shared storage configuration out there, whether it is Fiber Channel (FC), iSCSI, or NFS.
VMware View environments are unique in that you have two kinds of I/O to contend with: operational I/O and burst I/O. Operational I/O is essentially the storage throughput requirement while the virtual desktop is on, whereas burst I/O, or “boot storms,” is typically experienced when multiple virtual machines are being created. We look at the design principles in Chapter 12, “Performance and Monitoring,” when we review performance, but for now let’s talk mechanics. Rather than go into every aspect regarding storage considerations and configurations, let’s stick to a few important considerations in setting up storage.
No matter which storage solution you select for your VMware View installation, you should understand and have calculated your throughput requirement. In addition, your storage connections from the ESXi host to the storage solution should use multipathing. Multipathing allows you to segregate the storage paths on isolated networks and ensure there are redundant paths to the same storage pool.
vSphere 5 has simplified the setting up of multipathing using the iSCSI software initiator. In vSphere 5, a new graphical interface allows you to set up multipathing. You therefore can set up multiple VMkernel ports quickly and easily. You can now bind multiple VMkernel ports to the iSCSI software initiator. After you do so, however, the iSCSI traffic must be restricted to layer 2 traffic or nonroutable. If you use a single VMkernel port, you can route iSCSI traffic. In addition, if you have both VMkernel ports on the same vSwitch with two uplinks, one must be active and the other passive. Let’s look at the configuration to understand how this works.
If you want two active paths to your iSCSI storage device, you need to create two separate vSwitches with two separate VMkernel ports with one active uplink each. This configuration has a separate management network and two separate paths to the iSCSI appliance, as you can see in Figure 3.58.
Figure 3.58. Two separate paths to the iSCSI appliance.
When you have the networking configuration in place, you can bind the second VMkernel port to the software initiator using the following process:
- Log in to the vCenter.
- Select the Configuration tab from the ESXi host.
- Select Storage Adapters and the properties of the software iSCSI initiator.
- Under the Network Configuration tab, add the second VMkernel port.
After the second VMkernel port is added, check the paths to ensure you have the appropriate number of paths, as shown in Figure 3.59:
Figure 3.59. Check to ensure you have multiple paths.