VM /ETC

Posts Tagged ‘how to’

If you are looking at various options to automate virtual machine (VM) ip address reconfiguration when failing over virtual machines to a disaster recovery (DR) site, this post explains an option so simple it is beautiful. To give full credit, the Vizioncore vReplicator 2.5 Best Practices document enlightened me to the strategy of using a local only VMware vSwitch and an extra virtual NIC (vNIC) in each VM. It’s been a long time since I had a “ton of bricks” moment, but this concept crashed down on me with the realization of a configuration that works in any version of ESX, doesn’t require extra software or hardware, and better yet, doesn’t have to be scripted! Just configure some extra virtual networking and forget about it!

Here is a general outline for automating the DR ip addressing with this method:

At the Primary Site

• For these instructions assume the production vSwitch at the primary site has a Portgroup named VM Network
• Build a new vSwitch and do not attach any physical NICs (local only isolated switch). Create a Portgroup named DR Network
• For each VM you need to fail over to a DR site, add an extra vNIC and attach it to the DR Network Portgroup

At the DR Site

• Create your DR site production vSwitch, attach physical NICs and add a Portgroup named DR Network.
• Create another vSwitch and do not attach any physical NICs (local only isolated switch). Create a Portgroup named VM Network

All you have to do for this to work is

Read the rest of this entry »

How to increase the number of simultaneous VMotions of guests allowed between VMware ESX hosts has been covered many times already. In fact, check out the following blog posts on this topic for extra information and insight not provided here.

• Increase Simultaneous VMotions as well as Increase Performance
• Guest blog entry: VMotion performance » broche.net – VMware …
• VMware Communities: ESX Tips: Increase number of VMotions per host
• Increase number of VMotions per host

One possible scenario for changing this setting would be to temporarily increase VMotions allowed in order to evacuate ESX hosts within a short maintenance window. I prefer to leave the setting at the default, so for this scenario be sure to change it back after the maintenance is complete. if you read the links provided above, others suggest they have changed the settings permanently.

This rest of this post contains a cut and paste of the steps necessary to make the configuration change with a brief explanation about setting the appropriate value. I am pasting from a VMware Partner PDF communication assembled by Michael White, VMware engineer.

Read the rest of this entry »

vCenter Client Shortcuts by Bouke Groenescheij is post worth book marking by VMware admins who want to speed up their administration and management of vSphere. Check out the entire post for many, many more shortcuts than those listed here, but I am high-lighting some of the key navigational shortcuts for my own reference later (and making sure I have a backup link to Groenescheij’s post!).

The following screen shots show the Ctrl+Shift keystroke combinations to move between the most common VI Client management views:

Other Ctrl+Shift Navigational shortcuts Read the rest of this entry »

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 »

This post is just a quick how to reference for manually changing the VMware Update Manager (VUM) patch repository download location. Admins usually need to do this when the vCenter server is low on disk space on the partition that VUM was originally installed on, but there is a second partition that has enough capacity. To move the VUM patch repository follow the following steps found in the VUM Administrators Guide:

When you install Update Manager, you can select the location for downloading patches. To change the location after installation, you must manually edit the vci-integrity.xml
file.

Procedure

1. Log in to the Update Manager server as an administrator.
   
2. Stop the Update Manager service.
   
   1. Right-click My Computer and click Manage.
      
   2. In the left pane, expand Services and Applications and click Services.
      
   3. In the right pane, right-click the VMware Update Manager Service and click Stop.
      
3. Navigate to the Update Manager installation directory and locate the vci-integrity.xml file.
   
   1. The default location is C:\Program Files\VMware\Infrastructure\Update Manager.
      
4. Create a backup copy of this file in case you need to revert to the previous configuration.
   
5. Edit the file by changing the following fields:
   
   1. yournewlocation
   2. The default patch download location is: C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data\
      
   3. The directory path must end with \.
      
6. Save the file in UTF-8 format, replacing the existing file.
   
7. Copy the contents from the old patchstore directory to the new folder.
   
8. Restart the Update Manager service.
   

In order to create customized Windows 2003 and earlier virtual machines (VMs) the Microsoft Sysprep tools need to be added to VMware vCenter (also formerly known as VirtualCenter). Doing so is not a difficult process, but can be a bit confusing if an administrator has never used Sysprep before. Fortunately, VMware has a helpful KB article on the topic that explains where to download the Sysprep files from Microsoft and then where to put the extracted contents of those downloads on the vCenter Server. I’m going to high lite the instructions from VMware for downloading from Microsoft, but then I’ll explain how to get Sysprep from an alternate and arguably easier source – the Windows install CD.

Note that integrating the Sysprep files are still required in all versions of vCenter to customize VMs. This includes vCenter 4 for vSphere. Sysprep is no longer used for Server 2008, however, but VMware has added native customization of Server 2008 VMs in vCenter 4 without adding any additional files.

KB Article 1005593 titled Sysprep file locations and versions not only provides download links and extract to locations but also explains the common symptoms when Sysprep is not installed correctly on vCenter.

• When attempting to customize the deployment of a virtual machine the radio buttons are disabled (greyed out).
• When a virtual machine (VM) is deployed from a Template, you find that the SID is always the same, despite the fact that you chose the option to generate a new SID during Template deployment and guest operating system customization.
• When attempting to create a new virtual machine from a Template in ESX v3.5 you receive the following error message

Warning: Windows customization resources were not found on this server

• Message in the guestcust.log:

deploy doesn’t contain known sysprep files

The KB article explains the cause

Microsoft has a different version of Sysprep for each release and service pack of Windows. According to Microsoft, “You need to use the version of Sysprep specific to the operating system you are deploying”. The differences are not immediately visible in the packaging and documentation of the service packs, so it is necessary to manually investigate.

Use either of the following methods to obtain the appropriate Sysprep files. All instructions in this post assume vCenter has been installed in the default location. 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.