VM /ETC

Posts Tagged ‘esx’

As reported on vreference.com, there is a dangerous default in ESX 4. Before I expand on this potential problem I want to point out that a bug report has been files with VMware for correcting this in future releases, but for now VI admins need to be aware of the issue – If the key combination of Ctrl+Alt+Del is entered at the Service Console the ESX host will begin a shutdown which will stop all virtual machines running on the host in the process. Read the full vreference post for more details.

I tested this on an ESX 4 host running in a VMware Player VM on my notebook and captured the shutdown and reboot in this video.

DON’T HIT CTRL + ALT + DEL ON ESX 4 from Rich Brambley on Vimeo.

Fortunately, there is a manual workaround to disable this default behavior until VMware provides an update. I’ll use the instructions provided in the previously mentioned vreference.com post. Read the rest of this entry »

Unlike it’s big brother VMware Workstation 7, nowhere is it published that ESX/ESXi 4 is a supported guest OS of VMware Player 3.0. In fact, ESX 4 is not even among the listed choices in the Version drop down box when building a new virtual machine (VM), nor is it mentioned in the VMware Player Release Notes or Getting Started Guide. I was surprised when I was able to perform an Easy Install of ESXi 4, and just like ESXi 4 VMs running on Workstation 7, VMware Player nested ESXi successfully hosted guests. Best of all, ESXi 4 in VMware Player 3.0 can be run without any additional manual (ESX in a box) configurations (just like VMware Workstation 7).

Interestingly enough, the full Console ESX 4 install DVD is not recognized by VMware Player 3.0 for an Easy Install. However, performing a full ESX 4 Easy Install is possible with a last minute switch of the install media. That is, first browse to the ESXi 4 .ISO, complete the new VM Easy Install wizard, but modify the hardware before booting and change to the ESX 4 DVD .ISO. Watch the video at the end of this post for a demonstration on getting full ESX4 to work.

The rest of this post highlights the important parts of the Easy Install of ESXi 4 on VMware Player 3.0 with screen shots. To get an idea of more of the Easy Install screens check out my post about installing Windows 7 as a VM in Workstation earlier this year. Read the rest of this entry »

This VMworld 2009 session took place Thurs at 9:30 am in room 134

Points made by the presenter worth remembering.

• Physical failure is unavoidable, and an ounce of prevention is worth a pound of cure
• There is a 50% chance that pieces of an ESX Cluster will fail and take down critical services and servers.
• You’re not usually staring at a monitoring screen, and you want to be notified as the hardware degrades not afterwards.
• You want as much hardware info about a host, from multiple different vendor platforms, and on a single screen
• Physical failure is a fact of virtual life
• Be proactive about hardware failure and use DRS + hardware monitoring + Alarms

An interesting demo in this session showed the use of  the built in vCenter 4 host hardware temperature status alarm generating SNMP traps as well as automatically putting a host in maintenance mode so an administrator can investigate. This action instigated a VMotion evacuation of the VMs on the impacted host and effectively isolated the hardware issue in the environment with minimal or zero impact.

My key take away of this session is that numerous “out of the box” vCenter event based alarms can be leveraged during the warning phase of hardware failures. This includes alerts covering power, fans, cpus, memory, batteries, etc. The ESX host hardware monitoring feature is detected and available automtically in vSphere 4.

My notes: Read the rest of this entry »

In my previous post 730 Days Later I pointed out the default VirtualCenter SSL certificate was only good for 2 years. If the untrusted certificate installed with vCenter and ESX was not replaced by the VI admin problems could arise when connecting with the VI Client or via the ESX 3.X web interface. Now with vSphere the default vCenter 4 and ESX 4 SSL certificate still needs to be changed, but it has been updated and is now good for 10 years giving admins a little more breathing room.

VMware has also updated it’s PDF on how to replace the cert. Be sure to download the new guide for Replacing VirtualCenter Server Certificates. Here is some brief info from the first paragraph of this document:

Certificates are automatically generated when you install vCenter Server and ESX/ESXi. These default certificates are not signed by a commercial certificate authority (CA) and may not provide strong security. You can replace default vCenter Server and ESX/ESXi certificates with certificates signed by a commercial CA.

This Technical Note includes the following topics:
“About vCenter Server Certificates” on page 1
“Pre?Trusting Server Certificates” on page 2
“Certificate Specifications” on page 2
“Certificate Locations” on page 2
“Replacing Default Server Certificates with Certificates Signed by a Commercial CA” on page 2
“Replacing Default Server Certificates with Self?Signed Certificates” on page 5
“Related Publications” on page 8

NOTE   If you have replaced the default vCenter Server or ESX/ESXi host certificates with certificates signed by a commercial CA, you do not need to perform the tasks in this document. You can configure server?certificate verification settings using the vSphere Client. See the Basic System Administration Guide for more information.

The vSphere Basic System Administration Guide can be found here.

VMware also has a couple of KB articles about best practices using SSL keys for communicating with VirtualCenter. Go here or here

An administrator can also decide to turn off the verification of SSL certificates. To do this go to the vCenter Settings from the vSphere Client and disable this feature in the SSL Settings section. This is also explained in the System Administration Guide mentioned previously.

Admins of heavily consolidated VMware VI 3 Clusters should make plans as soon as possible to download Update 5 of VMware vCenter Server to take advantage of increased performance and scalability. The latest update to vCenter 2.5 was released on July 10 and boasts improvements to support fail over management of up to 80 VMs per ESX/ESXi host in a HA (High Availability) Cluster.

The following details were taken from the VMware VirtualCenter 2.5 Update 5 Release Notes:

What’s New

Support for High Consolidation in VMware HA Clusters – VirtualCenter 2.5 Update 5 includes significant performance and scalability improvements to VMware HA. Use VirtualCenter 2.5 Update 5 for environments with more than 35 virtual machines (VMs) per host in an HA cluster.

For information on the ESX Server host settings required for this scalability improvement, see ESX Server host settings required for environments with up to 80 virtual machines per host in an HA Cluster (KB 1012002).

Upgrading or Migrating to VirtualCenter 2.5 Update 5

This release supports upgrading from VirtualCenter 1.4.1, VirtualCenter 2.0.2 (including Update 1, Update 2, Update 3, Update 4, and Update 5), VirtualCenter 2.5, VirtualCenter 2.5 Update 1, VirtualCenter 2.5 Update 2, VirtualCenter 2.5 Update 3, or VirtualCenter 2.5 Update 4, to VirtualCenter 2.5 Update 5. Review the detailed upgrade and migration instructions and guidelines that are provided in the Upgrade Guide.

Following the above link to KB 1012002 explains that upgrading vCenter 2.5 to U5 is just the start. VI 3 admins also need to make some additional configurations on ESX/ESXi hosts to achieve the 80 VMs per host improvements.

“Starting with the VirtualCenter 2.5 Update 5 release, an ESX Server host in an HA cluster can support up to 80 virtual machines. For all virtual machines to power on on other hosts in the cluster, if hosts within the failover capacity limit fail, you need to ensure that the following parameters in the ESX Server hosts are set with the following values:

Read the rest of this entry »

If you’ve ever had to manually trace the cables from servers to network switches in a rack you probably were not very happy about it. In fact, if you’ve ever had to trace 10 cables from each ESX host to multiple network switches you were most likely aggravated to say the least. The good news is that if you have ESX 3.5 and Cisco switches you can determine the switch ports in use via the Cisco Discovery Protocol (CDP). Even better, the VMware administrator doesn’t even need access to the network switch and can obtain the switch port information directly from the VI Client.
Read the rest of this entry »