VMware vCenter Cookbook

This chapter covers some basic tasks and features administrators may need to use while working with vCenter. Most of the tips and advices in this chapter as well as in this book assume that you already have vCenter deployed and that it already has some hosts and datastores connected. You may be running vCenter with a trial license, which will work just fine if you decide to try some of the how-tos in this chapter. All features and settings described in this chapter exist in any vSphere 5 version unless otherwise noted.

The vCenter edition required for a particular environment is very much determined by the vSphere edition in use. The vSphere edition in turn is chosen based on the size of the environment and features that will be used.

If a VM has just been created and you are trying to install the operating system from a virtual CD-ROM, you can turn the VM on, connect the ISO image to the operating system, and reboot the VM. It will start booting from the CD-ROM right away.

If the operating system has already been installed and you need to boot this VM from the CD-ROM, it may be challenging, as the option to press Esc for Boot Menu is displayed for a very short period of time:

How it works...

Once Esc has been pressed, you'll get the Boot Menu options to choose from. Connect the ISO image, host or local CD-ROM in VM Settings, and choose CD-ROM drive from the Boot Menu:

One of the core vSphere features is vMotion. It allows administrators to move a running virtual machine from one host to another without interruption.

Unfortunately, one of the requirements for vMotion is to use hosts with the same processors so that the virtual machine that has been moved can keep running on a new host. This is due to the fact that newer processors, even within the same family, typically have additional features. New generations of processors can also have a different set of instructions. When features or instructions an application is using are not available, the application will crash.

Clusters consisting of hosts with different CPU generations can use Enhanced vMotion Compatibility (EVC) mode. In this mode, vCenter hides CPU features and instructions that are not available on older hosts. This way, it makes all hosts' CPUs in the cluster look like they are the same.

The obvious downside of using this feature is that the cluster's processors will all be the same or lower than the oldest host's CPU.

From time to time, VMware tools that have been working fine before refuse to start automatically when the Linux guest is rebooted. VMware tools can be started manually using the following command:

# /etc/vmware-tools/services.sh start

The following error message may be displayed:

In most cases, this issue is related to recent OS updates; in particular, the Linux kernel update, which breaks the existing VMware tools installation.

As servers are not rebooted often, it may be hard to correlate the issue of VMware tools not starting automatically and OS updates.

Administrators have three options when it comes to deploying the vCenter Server. vCenter can be imported as a Linux-based virtual appliance or it can be installed on a physical or virtual Windows Server.

There is a way to manage more than one vCenter Server from the same vCenter client. This is accomplished by using Linked Mode groups. Linked Mode group is a group of vCenter Servers that allows managing other members by connecting to any one of them.

vSphere 5 introduced a new web client, which can be used to manage the environment along with the traditional vSphere Client we used before.

vCenter Web Client is just another way to access the environment using a web browser. Three major browsers—Internet Explorer, Firefox, and Chrome—are supported.

Web Client becomes the main administrative interface starting with vSphere 5.1 and while vSphere Client can still be used, a lot of new features introduced in vSphere 5 are available only through Web Client.

Some of these new features are:

There's more…

Take a look at the following error message:

If the preceding error message is displayed, add port 9443 after the vCenter Server address or name in the URL: https://<vcenter-server>:9443/vsphere-client/. This will take you to the same login page, assuming vCenter was installed with default port settings.

In certain cases, you may need to access the ESXi host via SSH. This may be needed to run a script, troubleshoot an issue, or use a command or a feature not available via vSphere Client.

There's more…

Now you will be able to access the ESXi command line using the SSH client.

Note

Note that when SSH service is running on the host, vCenter marks it with a yellow exclamation mark as it is a configuration issue. Enabling SSH is considered to be an insecure practice.

When it comes to managing ESXi hosts, there are a few interfaces available to perform management tasks:

Remote TSM has been covered in the Accessing hosts via SSH recipe in this chapter. Local TSM and DCUI are console options available if you have physical access to the host or remote console access such as iDRAC.

All interfaces except vSphere API can be managed from vCenter under host Configuration | Security Profile | Services:

Both TSM options can also be configured from the DCUI console.

The following table summarizes different management interfaces and where each one can be configured:

VMware offers a way to secure management access to hosts called Lockdown mode.

Lockdown mode is a security feature, which limits the administrator's ability to manage the ESXi host only through vCenter. When a host is in this mode, the administrator cannot use the command line or run scripts. Also, any third-party software cannot get or change any settings on this host.

The following table summarizes each management interface's behavior in Normal and Lockdown modes:

Additional security always means inconvenience. If the vCenter VM crashed or didn't come up after the reboot, and access to vCenter has been lost, ESXi has to be reinstalled on hosts that are in Lockdown mode to restore access.

How to do it...

To enable lockdown mode from vCenter, execute the following steps:

1. Lockdown mode can be enabled per host by going to Configuration | Security Profile:

   

2. Click on Edit next to Lockdown Mode, select Enable Lockdown Mode, and click on OK:

   

Note

All the existing vCenter Client connections to the host will be dropped immediately.

Users that are currently logged in to DCUI or TSM will still have access after Lockdown mode has been enabled until they log off. Logged in users will not be able to switch Lockdown mode off in this case.

All the existing user and group permissions will be restored once Lockdown mode is disabled if it was enabled from vCenter.

To enable Lockdown Mode from Web Client, execute the following steps:

1. Select a host.

2. Go to Manage | Settings | Security Profile.

3. Scroll down to the Lockdown Mode section.

4. Click on the Edit next to the section.

5. Check Enable Lockdown Mode.

6. Click on OK.

   

Enable Lockdown mode from the ESXi console

To enable Lockdown mode from DCUI, press F2, log in with the root user, move the cursor to the Configure Lockdown Mode item, and press Enter.

Tip

All the existing user and group permissions will be lost once Lockdown mode is enabled from DCUI so the best practice is to use vCenter to enable Lockdown.

ESXi server logs are stored locally by default on each host in the /var/log directory. In certain cases, there is a requirement to store logs on a datastore.

Possible scenarios are hosts without local storage, where all locally stored logs disappear after reboot, compliance requirements where there is a requirement to store logs in an alternative location, or space concerns where there are many hosts and the administrator has to keep older logs.

How to do it...

vCenter allows redirecting ESXi logs to one of the datastores accessible to the host. This can be accomplished by going to Configuration | Advanced Settings | Syslog by changing the variable Syslog.global.logDir to an appropriate value [Datastore]/Folder:

In vCenter Web Client, these options can be found by going to Host | Manage | Settings | Advanced System Settings, as shown in the following figure:

esxcli system syslog config get

For compliance and security reasons, administrators may need to redirect ESXi logs to a remote syslog server.

How to do it...

This configuration is done by going to Configuration | Advanced Settings | Syslog and changing the variable Syslog.global.logHost to <protocol>://<syslog host>:<port> as shown in the following screenshot:

From Web Client, perform the following steps:

1. Go to Manage | Settings | Advanced System Settings.

2. Select the Syslog.global.logHost option in the list.

3. Click on the Edit button above the list.

4. Adjust the value of the Syslog.global.logHost option.

5. Click on OK.

   

Note

In most cases, syslog uses UDP and that's why in case of high logging volume or high network utilization, some log entries may be lost. Consider this when planning the logging infrastructure.

You can configure the syslog and datastore logging mentioned in storing host logs on a shared datastore at the same time for each host.

Also, administrators may need to configure the ESXi firewall to allow outbound syslog traffic. This is done by going to Configuration | Security Profile | Firewall and performing the following steps:

1. Click on Properties next to the Firewall section.

2. Make sure syslog is chosen.

3. Click on OK.

   

Alternatively, from Web Client, perform the following steps:

1. Select a host.

2. Go to Manage | Settings | Security Profile.

3. Click on the Edit button next to the Firewall section.

4. Select syslog in the list.

5. Click on OK.

   

Once this configuration is completed the remote syslog server will start receiving logging data.