Читать книгу VMware vSphere PowerCLI Reference - Graf Brian - Страница 10

In this chapter, you will learn to:

• Prepare for an Installation

• Customizing the vSphere ISO

• The Installation Medium

• Gathering Required Software

• Automate an Installation

• Customizing an Installation with Kickstart

• Postinstallation Configuration

There was a time when automating an installation and configuration of the vSphere Hypervisor was quite difficult. Fortunately, VMware has worked hard to simplify the overall process. Today 90 percent of the installation is automated out of the box. In this chapter we will briefly walk through the various installation methods before taking a deep dive into automating that last 10 percent. We will cover several techniques for streamlining the installation and configuration of vSphere.

Prepare for an Installation

The first step in preparing for an installation is to ensure that your install media is up-to-date and has all of the needed drivers and other vendor packages for your servers. This includes things like storage vendor plug-ins, as well as the Fiber Channel Host Based Adapter (HBA), NIC, SCSI controller, and IPMI/CIM drivers that enable vSphere to better interact with your hardware and provide increased performance, stability, and reporting. PowerCLI has a feature known as the Image Builder CLI, which enables you to manage the packages contained in the install ISO and customize them for your needs.

Customizing the vSphere ISO

VMware ships the ESXi ISO with many default packages. You may not need all of them. Often, you need additional drivers. The install image can be customized using PowerCLI. You can tailor it specifically for your environment and include only those packages that are required for your servers.

To get started, make sure that you have downloaded the offline bundle for the version of ESXi you plan to use. Offline bundles are zip files that typically are much larger than the default ISO download. Once you have downloaded an offline bundle, download to the same directory the driver packages that you need. Like the ESXi packages, if your vendor gives you options for online or offline bundles, choose the offline bundle.

To start, you need to add the packages that have been downloaded, which are treated as depots of software packages by PowerCLI. Listing 2-1 shows how to make the Image Builder CLI aware of a downloaded update package. We also want to make sure that the PSSnapin that provides the cmdlets has been added to the environment.

Listing 2-1: Adding an offline bundle package as a software depot

TIP VMware provides a public Internet–accessible repository of all images and update packages at this address:

https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Using this address as the location for the repository ensures that you always have access to the most recent versions of drivers and ESXi. Remember that you must have Internet connectivity, and be sure to take into account how long it will take to download the packages.

You can add as many of these bundles as needed to the cmdlet in Listing 2-2, which checks for packages that have been added and shows an example return.

Listing 2-2: Showing available bundles

Each bundle contains one or more software packages that will be combined, using the cmdlets, to make the customized install media for your installation. To list the available packages, use the Get-EsxSoftwarePackage cmdlet. The most interesting will be the non-VMware packages, since these are the ones you are probably trying to add to the default set. In Listing 2-3, we use PowerShell to show only those packages that are not part of VMware’s default bundle.

Listing 2-3: Listing non-VMware software packages

After you have downloaded the bundles, you can begin to modify the default images to customize them for your environment. Each bundle includes several image profiles; you can build an image profile to meet your needs from there. To view the existing image profiles, use the Get-ESXImageProfile cmdlet, as we did in Listing 2-4.

Listing 2-4: Showing available image profiles

The packages have three basic types: Standard, which includes VMware Tools; No-tools, which is self-explanatory; and those that have a name ending with “s,” which are security updates images. The steps for creating a package are as follows:

1. Clone the base profile.

2. Add and remove packages as needed.

3. Export the profile.

Listing 2-5 shows the PowerCLI used to execute those steps and ends by exporting the modified profile as an ISO image that can be used for loading your servers.

Listing 2-5: Modifying the ESXi profile

Pipelining the commands makes for an easy way to do all three operations (clone, add, and remove) in one simple step. The final operation is to export the newly customized installation profile to an ISO image (see Listing 2-6).

Listing 2-6: Exporting the customized image

The final parameter for the command can be either ExportToIso, which will output an ISO that can be used to install vSphere to the host, or ExportToBundle, which will output a bundle capable of being ingested by Update Manager or directly on the host for providing updates to packages.

Now that you have ensured the drivers and other packages for your physical servers are a part of the default install package, let’s investigate the different ways of loading the OS onto the physical host.

The Installation Medium

There are several different methods to install vSphere, ranging from the humble CD/DVD to the more complex, but more flexible, PXE. The installation method is the starting point from which you work backward. Once you have selected an install medium, you then tailor your automation and workflows to that method.

A large part of choosing the installation method is related to the size of your vSphere environment. Each of the available methods carries with it a series of trade-offs. We’ll cover each medium available, highlighting the advantages and disadvantages of each in addition to identifying a target environment size.

CD/DVD Old faithful, the CD/DVD, has been around since long before ESX, and it continues on with vSphere. This is the most basic medium because it offers no updating facility. CD/DVD is most commonly used in small environments with just a handful of hosts. It is, however, the simplest, which means that anyone can leverage this method.

Thumb Drive/USB Key The heir apparent to the optical drive, USB keys are the preferred installation medium for small/medium environments, generally those with fewer than 10 hosts. They have the inherent ability to be updated easily, and they are significantly faster than optical drives. Because they can be easily updated, they are also an excellent source for vSphere Kickstart-based installations.

PXE The most flexible (and usually fastest) of all installs, Preboot Execution Environment (PXE) has the most complex setup. Once configured, it’s easy to maintain and update the images as needed. The biggest downside is the infrastructure required to perform a PXE-based installation. Though not extreme, it is still overkill for small/medium environments. We consider PXE a minimum requirement for any environment with more than 10 hosts.

Gathering Required Software

We’re going to make the assumption that, since you’re reading a PowerCLI book, your management station is a Windows PC. Therefore, the following requirements apply:

CD/DVD For a CD/DVD installation, you will need an ISO Image editing tool such as ImgBurn, available for download from www.imgburn.com/.

Thumb Drive/USB Key For a thumb drive/USB key installation, you’ll need UNetbootin, available from http://unetbootin.sourceforge.net/.

PXE A multitude of PXE implementations are available, most of them based on Linux. That said, we recommend you use what you’re comfortable with, and if you have no comfort zone, we recommend Carl Thijssen’s Ultimate Deployment Appliance (UDA), available from www.ultimatedeployment.org/.

Automate an Installation

Automating a vSphere installation can mean many different things. At its core, it means you have a zero-touch installation. As you learned earlier, this can be accomplished regardless of the media you choose. You will, however, outgrow this minimal automation solution very quickly, as it doesn’t help solve the bigger problem of host configuration. To resolve that issue, you must first answer one simple, multiple-choice question.

Are you more comfortable using:

1. BusyBox/Python

2. PowerCLI

3. Host profiles

4. All of the above

If you chose option A, you will want to try to do as much as possible with the first boot and postinstall sections within Kickstart – but you will find you cannot do everything. The advantage of option A is that there are no external requirements. This is a great solution for small environments. If you have the time and skill set to configure a vSphere host via BusyBox/Python, it is possible to automate just about every aspect of vSphere.

TIP Although this looks and feels very similar to a traditional Linux Kickstart, it’s not! Do not assume that because something works in Linux Kickstart that it will work with vSphere.

If you chose option B, you will want to configure the bare minimum via Kickstart. Most likely, you’ll configure the management vmknic and partition assignment. That said, it is exponentially easier to perform some actions, like password and license assignment, from Kickstart.

If you chose option C, you undoubtedly have Enterprise+ licensing and want to use this advanced feature. Unfortunately, there are some things that you cannot do using host profiles (see Chapter 5, “Using Advanced vSphere Features,” for more information). Host profiles do offer a compelling capability – compliance. Anything that can be done via host profiles should be done via host profiles, because they will ensure that your hosts continue to be configured correctly.

If you haven’t figured it out already, option D is the best answer. You should use a combination of all three, assuming you have sufficient licensing to use host profiles. There are some aspects of vSphere configuration that are just easier to do while loading the host. Some matters are best left to host profiles. PowerCLI is the glue in all this that will bridge these two disparate worlds. If host profiles are off the table, take the path of least resistance and use both Kickstart and PowerCLI.

Customizing an Installation with Kickstart

As of ESXi 4.1, VMware supports a scripted installation mode: Kickstart. Kickstart is a configuration file that the installer reads in and then uses to perform a silent installation. Exploring the full set of options and capabilities of the Kickstart configuration file is beyond the scope of this book, but we will go over the basics, starting with how to have a non-interactive installation from the CD/DVD and USB installation mediums (see Listing 2-7).

Listing 2-7: A Kickstart configuration for non-interactive installation

TIP Refer to the VMware documentation and knowledge base for full information about all of the possible commands and options that can be used as a part of the Kickstart process.

Using a USB key for the installation media makes including Kickstart files incredibly easy. Simply create a directory in the root of the drive and place the file there. Figure 2-1 shows the file structure of the install media after it has been loaded. This USB device was created by taking a customized ISO and leveraging UNetbootin to copy the media to the drive.

Notice in Figure 2-1 that a folder named kickstarts was created at the root of the device. Simply copy any Kickstart files to that folder location, but don’t forget their names! After booting to the USB device you will need to specify the Kickstart location at the boot loader prompt.

Figure 2-1: USB installation media file layout

Figure 2-2 shows the host after booting to the USB media. When the boot menu screen is displayed, press any key to interrupt the process. Press the Tab key to edit the boot options for your device and append ks=usb:/kickstarts/ks.cfg, where ks.cfg is the name of your Kickstart file. Once you provide the path to your Kickstart file (Figure 2-3), simply press Enter and go get a cup of coffee (but don’t bring it in the datacenter!).

Figure 2-2: Host boot screen

Figure 2-3: Boot configuration customization

If this is too much effort for you, you can edit the file ISOLINUX.CFG in the root of your USB media. Find the line under the “LABEL install” section that contains the APPEND descriptor and append the same text we used earlier. Listing 2-8 shows what the file should look like after editing.

Listing 2-8: A completely hands-off ISOLINUX.CFG

Postinstallation Configuration

As we indicated earlier, you have several options for postinstallation configuration. They all fall into one of two categories: online or stand-alone. An example of a stand-alone installation is the traditional monolithic Kickstart.

A stand-alone installation should only be used in scenarios where the network connectivity cannot be assumed. In such an install, all the postconfiguration tasks must be handled via the Kickstart %post and %firstboot scripts. This is neither easy nor recommended, but under certain conditions, it is the only way to automate all parts of installation. For instance, when you port-channel all network connections to your host, it will not be able to connect to the network until the load-balance configuration has been done on the vSwitch. Because this is a prerequisite for network connectivity, it cannot be done remotely.

As shown in Listing 2-9, you can use a script as the %post section of a Kickstart configuration file. This two-line script adds a second NIC to the standard vSwitch and enables an IP hash load-balancing scheme.

Listing 2-9: Configuring vSwitch load balancing using Kickstart

An online installation is the preferred method for configuring vSphere. Host profiles fall into this category because they require network access to function. It is possible to perform online postinstallation configuration as either a semiautomated or fully automated task. For instance, you could manually run a PowerCLI/vCLI script to configure a fresh vSphere host. This approach is still far better than the completely manual process. For example, Listing 2-10 takes a fresh vSphere host and performs the following configuration tasks: