Welcome to Kraft Kennedy

Discovering that your ESX hosts have been unknowingly creating open snapshots can be an alarming, not to mention dangerous, event.

Third party storage and backup vendors frequently call the vCenter API to issue a snapshot creation of running virtual machines before they grab a copy of the virtual machine’s hard disk – VMDK files – which are located on the VMware VMFS datastore. This process is typically followed by an immediate deletion of the snapshot file which will merge the changes back into the initial VMDK file. Problems can occur when this process does not complete successfully leaving you with an “open” snapshot. This problem is compounded when it occurs multiple times against the same guest.

Each open snapshot can significantly degrade virtual machine performance and also contribute to poor storage utilization. Unless you monitor each of your virtual machines on a daily basis, you could quickly be left with an uncomfortable situation on your hands.

Continue reading…

When managing a VMware ESX host, most functions can be done via the VI Client. The VI Client offers an easy to use GUI interface for management and configuration of one or multiple ESX hosts. That said, there are times when connecting to the Service Console of the ESX host is required. Often times multiple administrators will login to the Service Console as the root (highest level access) user, making it difficult to know which administrator performed any task.

It is not recommended that all administrators connect to the ESX host as the root user. Further, as a security best practice connecting to the ESX host via SSH as the root user is restricted by default.

With these restrictions and best practices, how should Service Console access be managed on ESX hosts? In truth, ESX hosts are like all other servers and best practices for security and auditing should be followed – that is, all administrators that have to login to the ESX host should do so with their own account.

For administrators, managing multiple logins for different systems can be difficult and can lead to the use of weak or common passwords. To get around this issue with VMware ESX, administrators can enable Active Directory authentication which allows them to login with their domain credentials instead of a local Linux account.

The following steps must be completed on each ESX host in the environment in order to enable AD authentication:

Configure Active Directory Authentication on ESX

1. Connect to the ESX host as the root user. Issue the following command:

   esxcfg-auth –enablead –addmoain=ActiveDirectoryDomain –addc=FQDN.of.domain.controller
   

   For example, configuring AD authentication for Kraft Kennedy’s Research domain research.kraftkennedy.com with a domain controller named nyrdc01.research.kraftkennedy.com would look like the following:

   esxcfg-auth –enablead –addomain=research.kraftkennedy.com –addc=nyrdc01.research.kraftkennedy.com
   

   Additional domain controllers can be added via additional –addc command and should be done to provide some redundancy.

2. Create Linux accounts for each administrator that needs to connect to the ESX Service Console

   Useradd username
   

   To add the “admin.liebowitz” account to the ESX host, the command would be:

   useradd admin.liebowitz
   

   As administrators leave the organization, their accounts can be removed with the following command:

   userdel username
   

3. Once authenticated, if additional access is required the administrator can issue the following command to elevate to root level access:

   su -
   

Once the above steps have been completed, administrators can login to the ESX host via SSH using their AD credentials. This allows organizations to maintain best practices by restricting root level SSH access as well as makes it easier to see which administrators have logged into a particular server.

Yesterday VMware released Update 4 for ESX 3.5 and ESXi 3.5. It includes a few new features but no major enhancements. It also has some limitations to go with it that are important to note.

Here are some of the highlights:

• ESX 3.5 U4 does not work with all versions of vCenter 2.5. For example, you will need to have vCenter updated to at least Update 3 in order to be able to use it to manage ESX 3.5 Update 4. There is a compatibility matrix of which versions of ESX work with specific versions of vCenter here (this link opens a PDF).
• You can now enable the Enhanced vmxnet driver for 32-bit operating systems. Previously you had to set the guest OS to a supported type (like Server 2003 x64), enable the Enhanced vmxnet NIC, and then change the OS back. This is no longer required. This driver enables advanced networking features like TCP Segmentation Offload.
• VMware has included experimental support for PXE booting ESXi hosts. This would allow you to have a completely stateless and diskless server with ESXi installed on a flash drive able to PXE boot and be ready to host virtual machines in minutes.
• A large number of new hardware devices are supported, including NICs, SATA controllers, etc.

The full release notes can be found here for ESX 3.5 and here for ESXi 3.5.

As with any update to ESX, make sure you do it in the proper order. First upgrade vCenter and your database and then update each of your hosts.