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:
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
