VMware
[an error occurred while processing this directive]

Document Last edited:   9/22/05

VMware VirtualCenter 1.3 Quick Tips

This document provides a brief description of critical VirtualCenter functions. For additional information refer to the VMware VirtualCenter 1.3 User's Manual   (pdf),   (html)

Quick Tips Contents

General VirtualCenter Tips

Licensing

The licensing status for ESX Server systems, GSX Server hosts, and VMotion is displayed on the VirtualCenter License screen.

To view the VirtualCenter License screen:

  1. From the VirtualCenter client, select Help > Enter Serial Number.
    The Licensing screen is displayed. It lists the licenses available for GSX Server host, ESX Server system, and VMotion.
  2. To add additional licenses, refer to the steps outlined in the manual.

Template Creation Quick Tips

For more detailed information refer to the chapter, Working with Templates

  • Network-based deploy:

    1. Manually create a local directory on the VirtualCenter Management Server to serve as your template upload directory. Once configured, do not change it.

    2. If you have an existing virtual machine you would like to use as a template, ftp the contents of the virtual machines' folders over to the VirtualCenter Management Server, using the directory specified in Step 1. Use binary mode.

    3. From the VirtualCenter client, select Template->New and specify the path to the .vmx file to add a template to the upload directory.

    4. You may also create a template from an existing virtual machine. First add the ESX Server system on which it runs to VirtualCenter, then select the virtual machine and choose "New template from this Virtual Machine."

    5. You are now ready to deploy new virtual machines using this template.

  • SAN-based rapid deploy (ESX Server Only):

    1. Create a new VMFS partition for your templates, setting its access mode to "public" and making it visible to all of your ESX Server systems.

    2. Deploy a new virtual machine onto one of your ESX Server systems, using a template from your local upload directory on the VirtualCenter Management Server.

    3. Once the virtual machine is deployed, right-click on the virtual machine via the VirtualCenter client and select "New template from this Virtual Machine." Make sure the virtual machine is powered off.

    4. When prompted to leave files or copy to the upload directory, you should leave the virtual disk where it is if it resides in a VMFS volume on the SAN -- this will enable the template to be rapidly deployed in the future by performing a local copy instead of a network copy.

    5. You may now rapidly provision this template onto any ESX Server system that has access to the VMFS template upload directory partition.

  • Notes on template requirements:

    • Templates may be created from Workstation 4.0, GSX 2.5.x or later, or ESX 2.x virtual machines.

    • Templates should not use IDE virtual disks.

    • The template upload directory cannot reside on a network share.

Customization Setup Quick Tips

For more detailed information refer to the chapter, Customizing Guest Operating Systems

  • Windows customization:

    Make sure you have installed the necessary Sysprep components on your VirtualCenter Server.

    You can download the Sysprep package from the Microsoft website at:

    http://www.microsoft.com/windows2000/downloads/tools/sysprep/default.asp

    Install the package in the following directory:

    [VirtualCenter install directory]\resources\windows\sysprep\1.1

  • Linux customization:

    Make sure you have installed the VMware Open Source Components package on your VirtualCenter Server.

    To download the Open Source Components, please register your serial key at:

    http://www.vmware.com/registernow

Email/SNMP Alert Quick Tips

For more detailed information refer to the chapter, Working with Alarms

  1. To enable VirtualCenter to send SNMP traps when an alarm is triggered, you need to set certain configuration parameters for the VirtualCenter Server through the client. Go to File->VirtualCenter Settings->Advanced to access the settings

  2. You can configure VirtualCenter to send traps to up to four SNMP trap receivers. They must be configured in order with the following information:

    • snmp.receiver.1.name = (DNS Name/IP address of SNMP receiver)

    • snmp.receiver.1.name = (Port number for receiver)

    • snmp.receiver.1.community = (community identifier)

  3. You can also configure VirtualCenter to send email alerts. To do so, you must set the following VirtualCenter settings:

    • mail.sender = (for example, cc-server@xyz.com)

    • mail.smtp.server = (DNS name or IP address of SMTP gateway to use for sending email)

    • mail.smtp.port = (port number for the SMTP gateway, typically 25)

ESX Server Quick Tips

VMotion Setup Quick Tips (ESX Server Only)

Note:VMotion does not apply to GSX Server hosts.

For more detailed information refer to the chapter, Migrating Virtual Machines

  • VMFS Volumes:

    VMotion requires that both the source and target ESX Server systems are using the same VMFS volume to store their virtual disks. VMotion will fail if you attempt to migrate virtual machines between ESX Server systems that do not share a VMFS volume.

    1. Configure your VMFS volumes in "public" mode and make them accessible to all of the ESX Server systems between which you would like to perform VMotion migrations.

    2. VMware recommends that you connect no more than 16 ESX Server systems to a single, public VMFS volume. Connecting more than 16 ESX Server systems to a single volume may result in SCSI reservation conflicts that prevent you from powering on virtual machines.

    3. VMware also recommends dividing up virtual machines across multiple VMFS volumes to reduce the risk of SCSI reservation conflicts. Each of these volumes may still be accessible across the same set of ESX Server systems, but deploying the virtual machines across separate volumes will enable you to connect the volumes to a larger number of ESX Server systems.

    4. Make sure that all VMFS volumes on your ESX hosts are using volume names and that the virtual machines are using the volume names for specifying virtual disks.

  • Clustered Applications:

    VMotion does not currently support the migration of clustered applications. You will need to store all of your clustered virtual machine disks on separate VMFS volumes from the virtual machines you wish to migrate using VMotion. Clustered virtual machines must be stored on VMFS volumes in "shared" mode.

  • Networking Setup:

    VMotion requires the setup of a Gigabit Ethernet migration network between all of the VMotion-enabled ESX Server systems. When you add VMotion capabilities to an ESX Server system, you will be asked to configure a unique network identity for the ESX Server system and connect it to the migration network.

  • Network Labels:

    Make sure you have created network labels for each of the vmnics on your ESX Server systems. These network labels can be used globally across all of your ESX Server systems. When migrating a virtual machine from one ESX Server system to another with VMotion, VirtualCenter will verify that the virtual machine has access to the same networks on the target ESX Server system as it had on the source ESX Server system. Using the network labels you provided through the management interface on the ESX Server systems, VirtualCenter will automatically map the virtual machine to the appropriate vmnic on the target ESX Server system during a VMotion migration.

VMotion Troubleshooting Tips (ESX Server Only)

Note:VMotion does not apply to GSX Server hosts.

  • If migration fails because VMotion is not enabled for a host:

    Verify that you have VMotion enabled for a host:

    • Open Properties for a host and check that it is enabled.

    • Enable it if it is not enabled.

  • While trying to enable VMotion if the following errors occur:

    • "Not enough migration licenses":

      Verify that you have enough VMotion licenses remaining by clicking on Help->Edit Licensing Information

    • "Failed to setup network configuration":

      Make sure you are supplying the proper parameters in configuring the migration network. For the network label, make sure that the network label corresponds to the migration network.

  • If VMotion seems to be properly enabled, but the virtual machine fails to migrate, there might be a networking problem.

    1. Open the properties page for both the source and the destination host. Look for the network label for the migration network used for VMotion and the IP and gateway address.

    2. Make sure that the IP addresses for the two hosts are different. Make sure the gateway address is correct.

    3. Make sure that the IP addresses given to the Migration NICs are not the same as those for the Console OS. The migration NIC needs to have a unique address that is valid on the network to which it is connected.

    4. To verify the network label, open a web browser to the Management Interface. Login, select the Option tab and look at "Network Connections" page and verify that the network label refers to the correct network adapter

    5. To verify the link status of the network adapter, logon to the Service Console and look at the contents of the file /proc/vmware/net//config where is the name of the network adapter seen on the "Network Connection" page (Such as cat /proc/vmware/net/vmnic0/config/).

      There should be a line "Link state:" that will indicate if the link is up or down. If the link is down, check the physical network connection.

      If the link is up, look at the "Speed:" row and verify that the correct speed is listed. For example, "1000 Mbps, full duplex".

  • Additional Tips

    • Verify the VMFS volumes have logical names by visiting the "Storage Configuration" page in the Management Interface.

    • Verify the virtual machines are using the volume names by right clicking on virtual machine and selecting "Properties". Look at all the configured hard disks and verify that VMFS volume names are used

    • Make sure that the VMFS volumes containing the disks for the virtual machines to be migrated are configured with their "Access Mode" set to "Public". The Access Mode can be viewed and set from the Storage Configuration page in the Management Interface.

      The "Shared" Access Mode is used for virtual machines running clustered applications. VMotion does not currently support clustered applications.

    • Verify that the source and target ESX Server systems both have CPUs from the same family (for example, PIII to PIII, PIV to PIV). VMotion does not currently support migrating virtual machines between servers with different CPU families.

    • Verify that both the source and target hosts ESX Server systems have access to the same VMFS volume, and are within the same server farm.

GSX Server Quick Tips

Startup Tips

  • Make sure that your managed GSX Server hosts have been upgraded to GSX Server 3 build 8465.
    Note: This is a special build for use with VirtualCenter K2.

Licensing

VirtualCenter requires GSX Server host specific licensing.

  1. Start VirtualCenter client for the first time.
    The License window is displayed.

  2. Click the Add Licenses button and browse and to locate the license key file.

    If you choose to add your licenses at a later time, click Close and follow the steps outlined in the manual.

  3. Click OK on the browse window.

    VirtualCenter adds the licenses to the VirtualCenter database.

    The licensing status for ESX Server systems, GSX Server hosts, and VMotion is displayed on the VirtualCenter License screen.

  4. Close the Licensing window. Click Close.

    You are now ready to use VirtualCenter add hosts and perform migrations.

Restrictions Using GSX Server host with VirtualCenter

  • GSX Server virtual machine configuration and .vmdk disk files must be stored locally to the GSX Server.

  • Cannot create templates from GSX Server virtual machines with IDE disks. This applies to external virtual machines being imported as templates and well as virtual machines on managed GSX Server hosts or ESX Server systems.

  • GSX Server feature that automatically starts virtual machines when the GSX Server starts is not supported in VirtualCenter.

  • The template repository must be local or on a Network Attached Storage (NAS).

  • GSX Server must be upgraded to the GSX Server 3.1 build 9089 version.

  • VMotion between GSX Server hosts is not supported at this time.

Configuring Users and File Permissions for a VirtualCenter Managed GSX Server

Virtual machines are composed of files on datastores, and a virtual machine runs as a process on the host. The following steps are required to enable VirtualCenter to run processes and execute operations on managed hosts.

  1. Prior to adding a GSX Server host to be managed through VirtualCenter, create or select a user on the managed host that will be performing operations on behalf of VirtualCenter (subsequently referred to as "VirtualCenterUser").

    The VirtualCenterUser may be configured on a Domain controller and may be used by VirtualCenter across multiple hosts.

    The user chosen will need to have access to network shares if VirtualCenter will be used to create and store Virtual machines on a network share.

  2. When adding a GSX Server host to a farm through the "Add Host Wizard", VirtualCenter requires two user names in the following order:
    • A user who will be used to connect to the GSX Server host (must have administrator privileges, and may be same/different as VirtualCenterUser.
    • The VirtualCenterUser chosen in step 1.

Configuring Datastores

On the host summary page the title bar that describes the host indicates if the host is a GSX Server host or ESX Server system.

One datastore is allowed per GSX Server. This datastore must be local to the GSX Server.

When a GSX Server host is added to VirtualCenter, the Add a Host wizard defaults the datastore location for all the virtual machines on that host. The default location is the path specified when GSX Server was installed on its host.

To specify a different directory location for the datastores of a particular GSX Server:

  1. View and select the host in VirtualCenter.

  2. Open the Host Properties box. Select the Datastore tab.

    If you selected an ESX Server host Properties, a VMotion tab is displayed. Both the GSX Server and ESX Server Properties box have the same Advanced tab.

  3. In the field, type the path to the datastore.

    This must be in the appropriate format, Linux or Windows path for a GSX Server and as a vmfs-label:disk-name for an ESX Server system.

    This must be a local directory. It cannot be a directory on a network share or a NGS mount path.

    To view the format, check the Host Summary page, Datastore field. The path specified there is appropriate for the host type, Linux or Windows.

Configuring Network Labels

Prior to using the migration feature in VirtualCenter network labels must be assigned to each network interface in each GSX Server host.

Background

VirtualCenter allows the management of GSX Server hosts, which is a powerful new feature. But VirtualCenter is centered around the concept of virtual machine migration, while the normal GSX Server console is centered around a single host. This different emphasis causes the two products to have very different views of virtual network connections. In VirtualCenter, the most important thing about a virtual network interface is what network it connects to, because that limits what possible hosts the virtual machine containing it could migrate to.

The normal GSX Server methods for specifying network interfaces ("Bridged", "NAT", "Host-Only", or "Custom") do not apply in the VirtualCenter environment. For example:

  • A VirtualCenter-managed farm might include three physical networks:
    • One which connects through a firewall to the Internet
    • One which is internal to the server room
    • One which is dedicated for connection to networked storage.
  • On a GSX Server host, these networks might be set up as
    • the "bridged" network,
    • a "custom" network on vnet4,
    • a network not even visible to the virtual machines directly
  • On a second GSX Server host, the network might be set up as
    • only one network card, connected to the server-room network only. On this host the network would be a "bridged" network.
Note: that in this example, knowing that a network is "bridged" is of no value at all in determining what network it is.

VirtualCenter must be able to identify the actual network that the interface connects to. This has to be manually set by someone who knows the physical connections and GSX Server custom settings.

Specifically, VirtualCenter provides a method by for assigning a label or name to each network connection on each host. This network name becomes a global identifier for the actual network. In the example above, the administrator might choose to call the first network the "main" or "corporate" or "intranet" network, the second network the "server link" network, and the third network the "storage" network.

These labels are used by VirtualCenter when a virtual machine is migrated. The virtual NICs are matched up to the networks on the new host by the network names.

So in order to provision network cards to virtual machines on GSX Server hosts using VirtualCenter, you must name the network interfaces on each GSX Server host. To do this, use the management interface. This naming need only be done once per network per host. Action

Use the VMware Management Interface to specify network labels for all the virtual NICs in your GSX Server virtual machines. This need only be done once. Refer to your GSX Server documentation for additional information.

  1. Log into the management interface as root and/or Administrator.
  2. Click the Options tab.
  3. Click the Network connections... link.
    A window displays a list of network adapters and network labels. On Linux systems all possible VMnets are displayed. On Windows systems only the adapters and lables that are enabled are displayed.
  4. Assign or change the labels as desired and click OK, or click Cancel to not accept the change.

To configure a virtual machine to use a named network:

  1. From the management interface, select the Hardware tab.
  2. Select either Add a New, or Edit an Existing network adapter.
  3. Select Network Connection then click the Named radio button.
  4. Select the appropriate network from the pull down menu.

Existing virtual machines on your GSX Server hosts continue to work, naming your networks does not modify the existing virtual machines in any way. Their virtual NICs continue to be read as "Bridged", "NAT", etc. If you edit the virtual machine configuration under VirtualCenter, you have the option of changing them from their current value to a network name value. Only VirtualCenter specific name options are offered. The GSX Server-specific values, such as Bridged, NAT, are not valid VirtualCenter options.

If you migrate the virtual machines to a different GSX Server host without changing the NIC settings, the GSX Server-style name are applied to the new host's environment. This might result in a sudden change of network topology.