VMWare Questions

How to change the blocksize of a VMFS filesystem

By default, VMWare ESX server uses a 1M block size which limits you to having a maximum of
256GB in any single virtual machine. By changing the block size of your vmfs partition, you can
increase the maximum amount of disk you can have. A 2M block size yields a maximum disk
size of 512 GB, 4M yields 1TB, and 8M yields 2TB. There is no support for anything larger under
vmfs3. Vmfs2 had a maximum block size of 16M, but that has been removed in the vmfs3
specification.

To change the block size of a vmfs filesystem, you need to use
vmkfstools to reformat the partition.
The command is:vmkfstools ‐‐createfs vmfs3 ‐‐blocksize 8M vmhba0

Troubleshooting a non‐responsive virtual machine

Symptoms

The virtual machine stops responding and cannot be controlled
The virtual machine experiences a core dump
The virtual machine suffers from performance problems
The virtual machine experiences network connectivity issues
Any task done shows "In Progress" in Virtual Infrastructure tasks and never completes

You receive the following error:
Not enough resources to Power On the virtual machine

Resolution
Please validate that each troubleshooting step below is true for your environment. Each step
will provide instructions or a link to a document, in order to eliminate possible causes and take
corrective action as necessary. The steps are ordered in the most appropriate sequence to
isolate the issue and identify the proper resolution. Please do not skip a step.

Step‐1. Verify that the virtual machine is not in an unresponsive state.

In a non‐responsive system, the operating system seems to be paralyzed, no error messages
are displayed, and the screen freezes or the application does not respond to users' actions.
Keyboard input or mouse clicking has no effect, regardless of where the cursor is placed, but
the operating system is still running. Unlike a failure, sometimes a non‐responsive system
resolves itself, and the application resumes its normal execution without your involvement.

A failure is a situation where the operating system has terminated and is no longer running.
There may be a purple diagnostics screen or error message visible in it's place.
Note: There is a difference between a virtual machine failing and the guest operating system
failing. If the virtual machine fails, it powers off and vmware‐core files are created in the virtual
machines host directory. In the vmware.log file, you may see an entry similar to:
Sep 13 19:46: vcpu‐1| MONITOR PANIC: ASSERT failed
Sep 13 19:46: vcpu‐1| Core dump with build build‐10104
Sep 13 19:46: vcpu‐1| Writing monitor corefile
"/root/vmware/vm1/vmware‐core0.gz"
In some cases VirtualCenter and the ESX hosts get into a state where they are not reporting a
virtual machines state properly

You must restart the VirtualCenter and ESX host service.
To restart the services:

A. On the ESX host, run the following commands:
# service vmware‐vpxa stop to stop the vxpa agent.
# service mgmt‐vmware stop to stop the management services.
# service xinetd restart to restart xinetd.
# service mgmt‐vmware start to start the management services.
Note: At this stage, the VMware Virtual Infrastructure Client sessions to both the ESX host and
the VMware VirtualCenter server are terminated.

B.Connect to the VMware VirtualCenter server via the console or an RDP session. Restart the
VMware VirtualCenter Server service.
To restart the VirtualCenter Server service:
1. Click Start > Run > services.msc .
2. Locate the VMware VirtualCenter Server service.
3. Restart the service.

C.On the ESX host run the following command:
# service vmware‐vpxa start
D. Open a VMware Virtual Infrastructure Client session to the VMware VirtualCenter Server
and power on the virtual machine.

STEP‐2.Ensure you do not have missing or locked files.

Often, you receive the following error when there are missing or locked files:
Error:"unable to locate vm swap file. failed to power on vm"

For more details read the following article
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&ext
ernalId=10051

Step‐3 Ensure you have enough resources available to run your virtual machine.

Resolution
To verify the virtual machine is configured with enough resources:

1. Connect to the ESX Server host directly using VMware Infrastructure Client (VI Client).
2.Log in as a user with administrator privileges.
3.Right‐click the virtual machine from the Inventory panel and click Edit settings.
4.Click the Resources tab.
5.Check if the Memory and CPU reservations are set correctly.
6.Click OK to save changes and try Powering On the virtual machine.

If the virtual machine is part of a Cluster and Resource Pool configuration:

1.Connect to the ESX Server host directly using VI Client.
2.Log in as user with administrator privileges.
3.Right‐click on the Resource Pool where the virtual machine is and click Edit settings.
4.Check if both CPU Resources and Memory Resources are set to the appropriate level to
accomodate all the virtual machines.

New Topic :‐Memory management in esx server

Interview questions:‐

1.What are the various techniques uses by esx server to manage the memory management and
how they work..
2.what is ballooning
3.Which driver handles the ballooning

Answers:‐

1.The ESX kernel uses transparent page sharing, ballooning and swapping to reclaim memory.
Ballooning and swapping are used only when the host is running out of machine memory or a
VM limit is hit

2.When the ESX host’s machine memory is scarce or when a VM hits a Limit, The kernel needs
to reclaim memory and prefers ballooning over swapping. The balloon driver is installed inside
the guest OS as part of the VMware Tools installation and is also known as the vmmemctl driver.
When the ESX kernel wants to reclaim memory, it instructs the balloon driver to inflate. The
balloon driver then requests memory from the guest OS. When there is enough memory
available, the guest OS will return memory from its “free” list. When there isn’t enough
memory, the guest OS will have to use its own memory management techniques to decide
which particular pages to reclaim and if necessary page them out to its swap‐ or page‐file.
In the background, the ESX kernel frees up the machine memory page that corresponds to the
physical machine memory page allocated to the balloon driver. When there is enough memory
reclaimed, the balloon driver will deflate after some time returning physical memory pages to
the guest OS again.
This process will also decrease the Host Memory Usage parameter
Ballooning is only effective it the guest has available space in its swap‐ or page‐file, because
used memory pages need to be swapped out in order to allocated the page to the balloon
driver. Ballooning can lead to high guest memory swapping. This is guest OS swapping inside
the VM and is not to be confused with ESX host swapping
3.Vmmemctl driver

vmware converter

Interview Questions :‐
1.How vmware converter works.

2.Can we able to change the ram and disk size of the machine to be converted to vm through
vconverter..
Ans:‐ Yes we can change ram and disk size

3. what preparations you will make before and after converting a physical machine to vm

Ans:‐1. Agent Installation Location
• Locally: Install Converter and agent directly on source machine if converting directly into ESX
Server
• Remotely: Connect to source machine over network to install agent

2. Agent Installation
• Use local administrator account
• Avoid domain accounts that have restrictive policies
• Allow reboot for Windows NT 4.0 and 2000 sources

3. Machine Preparation
• Do not deactivate services or harden security
> Workstation service
> Server service
> TCP/IP NetBIOS Helper service
> Volume Shadow Copy service (Windows 2003 or XP)
• Ensure sufficient free disk space (at least 200MB)
• Mirrored or striped volumes across multiple disks should be broken
• Dynamic disks with utility partitions should use cold cloning
• Disable Windows Simple File Sharing (Windows XP only)
• Disable anti‐virus software
• Defrag hard disks
• Shutdown any un‐needed Windows Services
• Clean‐up any temporary files and un‐needed data
• Run chkdsk
• Keep users off if possible
• Power off VM if not using hot cloning
• VCB VM exports need editing prior to import
> Edit virtual disk filenames inside .vmx
> Rename filenames for .vmdk files to match those listed in .vmx
> Edit index .vmdk file to change references to span files

4. Network Preparation
• Open TCP/UDP ports 139, 445, and 902 (Converter 3.0.0) or 443 (Converter 3.0.1)
• Open network ports between source and destination
> Alternative is to create a VM visible to source, copy VM files to location visible to destination,
and import VM
• Use FQDN to connect to both source and VI3

5. Converter Preparation
• Run on OS greater than or equal to source if source is
> VM and powered off, or
> Symantec Livestate System Image

6. Cloning
• Starter edition limitations and workarounds
> Cannot remote hot clone directly into VI3
‐ Workaround 1: install Converter on source machine
‐ Workaround 2: select standalone VM as destination, and then import VM to VI3 using two
steps
> Cannot run multiple tasks concurrently
‐ Workaround: run multiple copies of Converter
> Cannot cold clone
‐ Workaround: create new VM, use third‐party cloning application such as Ghost, and run
Converter configure
• Do not resize volume for fastest clone speed (block‐level copying)
• Resize volumes if source disks have inefficient utilization (resorts to file‐level copying)
• Use cold‐cloning disk‐based cloning (not volume‐based) for non‐Windows systems
• Use hot cloning for Windows NT 4.0 systems to avoid NTFS upgrade
• Destination needs to be writeable

7. Configure
• Avoid cloning utility partitions
• Check partition numbers in boot.ini
• Automatic “Install VMware Tools” option is only available for ESX Server VMs

8. Clean‐Up Prior to Power On
• Edit VM settings according to desired goal
> Number of vCPUs
> Add/Delete USB devices
> Add/Delete Serial and parallel devices
> Remove Floppy drive if not needed
> SCSI controller type (BusLogic vs. LSI Logic)
• OEM source may require license activation
> SMBIOS.reflectHost = “TRUE” in .vmx may avoid reactivation
> Requires destination host to have same hardware

9. Clean‐Up After Power On
• Detect hardware
> VMware Tools installation may hang if hardware not detected
• Allow reboots to occur
> Detect hardware and VMware Tools installation
• Verify HAL and change if necessary
• Remove non‐present old hardware
> CMD prompt type set DEVMGR_SHOW_NONPRESENT_DEVICES=1
> Next type DEVMGMT.MSC and select Show Hidden Devices
> Delete any old grayed out non‐present hardware

10. Guest Troubleshooting
• Blue screen after powering on
> Start Windows in Safe Mode and uninstall hardware‐specific applications or services
> Attach VM to “Helper VM” to remove hardware‐specific drivers or to correct the boot.ini
• No keyboard/mouse
> Select Workstation/Server VM instead of ESX Server, then import VM to ESX Server
> Use PS/2 keyboard/mouse on source
• Display problems
> Uninstall PC Anywhere prior to installing VMware Tools

4.What different problems you faced at the time of converting a physical machine to vm

Converter FAQ

What are the requirements for Converter?
For cold cloning the minimum memory requirements is 264MB, the recommended memory is
364MB. Converter uses a RAM disk while cold cloning and will not work with less then 264MB.
Also the operating system on which Converter runs must be equal to, or greater, than the
operating system on the source machine. For example if your source machine is running
Windows 2003 and you are running Converter remotely, you must run it on a Windows XP or
2003 machine. You will not be able to run it on a Windows 2000 machine. If you run Converter
on 2003 or XP you should be able to convert any operating system since they are the latest
operating systems.

What platforms can Converter be installed on?
VMware Converter 3 can be installed on the following platforms: Windows XP Professional,
Windows 2003 Server, Windows 2000 Professional, Windows 2000 Server and Windows NT
SP6+ (IE5 or higher required)

What import formats does Converter support?
Source formats supported include: Physical Machines running supported OS, Microsoft Virtual
PC (version 7 and higher), Microsoft Virtual Server (any version), Symantec Backup Exec System
Recovery images (also Ghost 9 or higher), VMware Workstation 4.x virtual machine (compatible
with VMware GSX Server 3.x), VMware Workstation 5.x virtual machine (compatible with
VMware Player and VMware Server 1.x), VMware ESX Server 3.x, VMware ESX Server 3.x (when
managed by VirtualCenter 2.x), VMware ESX Server 2.5.x (when managed by VirtualCenter 2.x)

What export formats does Converter support?
Destination formats supported include: VMware Workstation 4.x virtual machine (compatible
with VMware GSX Server 3.x, ESX Server 2.5.x), VMware Workstation 5.x virtual machine
(compatible with VMware Player and VMware Server 1.x), VMware ESX Server 2.5.x (when
managed by VirtualCenter 2.x), VMware ESX Server 3.x (when managed by VirtualCenter 2.x),
VMware ESX Server 3.x Note: VMware ESX Server 2.5.x when managed by VirtualCenter 1.x
and VMware ESX Server 2.5.x unmanaged are not supported

What are the supported guest operating systems?
The following 32‐bit guest operating systems are fully supported by VMware Converter 3:
Windows NT, Windows 2000 Professional, Windows 2000 Server, Windows XP Professional,
Windows 2003 Server

The following 64‐bit guest operating systems are fully supported by VMware Converter 3:
Windows XP Professional, Windows 2003 Server

Support for the following guest operating systems is Experimental. VMware Converter 3 can
clone source images containing these operating systems, but the destination virtual machine
may or may not work without additional configuration after import. In particular, if the source
image contains unsupported hardware, you may need to modify the configuration of the
destination virtual machine before using it: Linux, Windows NT 3.x, Windows ME, Windows 98,
Windows 95, MS‐DOS

What TCP/IP ports are used by Converter?
Converter 3.0.0 uses the following ports:
• Converter application to remote physical machine ‐ 445 and 139
• Converter application to VirtualCenter Server ‐ 902
• Converter application to ESX Server 3.x ‐ 902
• Physical machine to VirtualCenter Server ‐ 902
• Physical machine to ESX Server 3.x ‐ 902

Converter 3.0.1 uses the following ports:
• Converter application to remote physical machine ‐ 445 and 139
• Converter application to VirtualCenter Server ‐ 443
• Converter application to ESX Server 3.x ‐ 443
• Physical machine to VirtualCenter Server ‐ 443
• Physical machine to ESX Server 3.x ‐ 443

*** If you are using Converter 3.0.1 make sure you do not have a web server using port 443
while running Converter

When you select VirtualCenter as a destination and then chose a ESX host, Converter will first
make a connection to VirtualCenter and then the ESX host, so you will need to make sure these
ports are not being blocked for both the VirtualCenter server and ESX server

What Windows Services need to be running for Converter to work properly?
The Windows Server and TCP/IP Netbios Helper services must be running for Converter to work
properly. Also for Windows 2003 Servers the Volume Shadow Copy service must not be
disabled (can be Manual or Automatic)

What should I do before running Converter?
First, once you install Converter on the source system to do a Hot clone, you must reboot the
system before running it. Once you reboot, make sure the Vmware Converter service is started
and running before you begin. Next shutdown any un‐needed Services, the less Services
running the better your chances for a successful conversion. This includes backup agents, virus
scanners, applications, etc.

What types of servers should not be converted?
In general, Active Directory domain controllers, database servers (SQL/Oracle), Exchange
servers and any servers that have sensitive applications are not good candidates for
conversions. If you do try and convert these types of servers the best method is to cold‐clone
them. If you must hot‐clone them make sure all applications and services are shutdown before
starting the conversion. Database servers are particularly sensitive to corruption when being
converted. It is also best if you do not change the drive sizes when converting these servers. If
you re‐size hard drives this changes the copy method that Converter uses to migrate the data
to the destination. Domain controllers have been known to have USN rollback problems after
being converted. See the following Microsoft knowledge base articles for more information:
http://support.microsoft.com/kb/885875/ and http://support.microsoft.com/kb/875495/ and
also http://support.microsoft.com/kb/888794/en‐us

What is the difference between the Starter and Enterprise edition of Converter?
The differences are Enterprise includes support, the ability to cold‐clone with the boot CD, able
to do multiple simultaneous conversions and perform remote conversions

How do I get a Enterprise license for Converter?
Vmware Converter Enterprise is available at no additional cost to existing and new
VirtualCenter Management Server customers and P2V Assistant customers, with valid support
and subscription contracts. First go to http://www.vmware.com/download/licensing.html and
click on the Manage VMware Product Licenses link. If you are entitled to Converter licenses you
will see Vmware Converter 3.0 Enterprise listed once you log in. Once you activate the license
and download the license file you can go to http://www.vmware.com/download/converter/
and click on the Enterprise Edition link to download the ISO file for cold‐cloning. The
installation program for hot‐cloning is the same for Starter and Enterprise editions. Once you
select a license file in Converter it will unlock the Enterprise features. One thing to note is that
the license file you download for Converter does not work with the License Manager server.
Even though it is in the same format as the ESX licenses the License Server will not recognize it.
To use your Converter license file simply copy it to the server that Converter is installed on and
launch the Converter application and select Administration, Licensing Information and click
Add License and browser and select your Converter license file

Is there support available for Converter?
Support is available for the Starter edition but needs to be purchased on a per incident basis
($90 per incident). If you have the Enterprise edition support is included as part of the
VirtualCenter Management Server. Also the Vmware Converter forum is a great resource for
answering Converter questions and solving problems

Can I convert Linux servers with Converter?
The Converter documentation states: “Experimental support only is available for Linux‐based
physical to virtual machine conversions using the Vmware Converter BootCD (cold cloning) if
the source physical machine has SCSI disks.” Some people have had success converting Linux
machines, others have not. If Converter does not work on your Linux machine you can try a
commercially available conversion product from Platespin called PowerConvert which has full
Linux support.

Why are ESX and VirtualCenter grayed out as destinations when I run Converter?
If you are using the Starter edition you must run it on the physical server that is being
converted for ESX Server and VirtualCenter to be available as destinations. If you do not run it
on the server being converted then only the Vmware standalone virtual machine option is
available. Enterprise edition does not have this restriction

What should I do after I successfully convert my virtual machine?
If you change from a multi‐processor system to a uni‐processor system you need to manually
change the HAL on the Windows server after the conversion. To do this go into Device
Manager after the machine first boots and discovers it's new hardware and then click on
Computer then right‐click on the processor and select Update Driver. Then select Install from
specific location and then Don't search I will choose the driver to install. Then select show All
compatible hardware and select the appropriate processor. For example, if you went from a
dual cpu to a single cpu then select ACPI uni‐processor PC instead of ACPI multi‐processor PC.
You will need to reboot once you change this. To verify what HAL you are using you right‐click
your hal.dll in c:¥windows¥system32 and select the Version tab and select Internal Name and it
should say halmacpi.dll for multi‐processor acpi and halacpi.dll for uni‐processor acpi. Next
clean up all the non‐present hardware after the P2V conversion. To do this go to a CMD prompt
and type SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 and then DEVMGMT.MSC and then
select Show Hidden Devices. Delete any old grayed out hardware. Next remove any vendor
specific applications/drivers. For example on a HP server you should go to Add/Remove
programs and remove any HP management agents, survey utility, array config utility, version
control agent, etc. Also check your NIC and make sure there are no vendor specific drivers
there (ie. teaming).

What TCP/IP ports are used by ESX, VirtualCenter and the License Server?
The ports that are used are very well documented in the Server Configuration guide on pages
183 – 188. Here’s a summary of the core TCP/IP ports:
• Port 80 – HTTP access ‐ The default non‐secure TCP Web port typically used in conjunction
with port 443 as a front end for access to ESX Server networks from the Web [Incoming TCP]
• Port 443 – HTTPS access ‐ The default SSL Web port used for Connection to VI Web Access
from the Web, VI Web Access and third‐party network management client connections to the
VirtualCenter Server and direct VI Web Access and third‐party network management clients
access to ESX Server hosts [Incoming TCP]
• Port 902 ‐ Authentication traffic for the ESX Server host and virtual machine configuration ‐
Used for VI Client access to the VirtualCenter Server, VirtualCenter Server access to ESX Server
hosts, direct VI Client access to ESX Server hosts and ESX Server host access to other ESX Server
hosts for migration and provisioning [Incoming TCP] [Outgoing UDP]
• Port 903 ‐ Remote console traffic generated by user access to virtual machines on a specific
ESX Server host ‐ Used for VI Client access to virtual machine consoles and VI Web Access Client
access to virtual machine consoles [Incoming TCP]
• Port 2049 ‐ Transactions from your NFS storage devices ‐ Used on the VMkernel interface
rather than the service console interface [Incoming TCP] [Outgoing TCP]
• Ports 2050‐5000 ‐ Traffic between ESX Server hosts for VMware High Availability (HA) and
EMC Autostart Manager [Outgoing TCP] [Incoming UDP] [Outgoing UDP]
• Port 3260 ‐ Transactions from your iSCSI storage devices ‐ Used on the VMkernel interface
rather than the service console interface [Outgoing TCP]
• Port 8000 ‐ Incoming requests from Vmotion ‐ Used on the VMkernel interface rather than
the service console interface [Incoming TCP] [Outgoing TCP]
• Port 8042‐8045 ‐ Traffic between ESX Server hosts for HA and EMC Autostart Manager
[Outgoing TCP] [Incoming UDP] [Outgoing UDP]
• Port 27000 ‐ License transactions from ESX Server to the license server ‐ [Outgoing TCP]
• Port 27010 ‐ License transactions from the license server ‐ [Incoming TCP]
Additional optional ports:
• Port 22 – Used by ESX for SSH server access ‐ [Incoming TCP]
• Port 123 – Used by ESX if you setup NTP to sync from a time source ‐ [Outgoing UDP]

Troubleshooting:

How do I troubleshoot ESX server issues?

Panicking at the onset of a high impact technical problem can cause impulsive decision making
that enhances the problem. Before trying to troubleshoot any problem, pause and relax to
approach the task with a clear mind, then address each symptom, possible cause and
resolution appropriately.
In this series, I offer solutions for many common problems that arise with VMware ESX host
servers, VirtualCenter, and virtual machines in general. Let's begin by addressing common
issues with VMware ESX host servers.
Windows server administrators have long been familiar with the dreaded Blue Screen of Death
(BSOD), which signifies a complete halt by the server. VMware ESX has a similar state called the
purple screen of death (PSOD) which is typically caused by hardware problems or a bug in the
VMware code.
Troubleshooting a purple screen of death
When a PSOD occurs, the first thing you want to do is note the information displayed on the
screen. I suggest using a digital camera or cell phone to take a quick photo. The PSOD message
consists of the ESX version and build, the exception type, register dump, what was running on
each CPU at the time of the crash, back‐trace, server up‐time, error messages and memory
core dump info. The information won't be useful to you, but VMware support can decipher it
and help determine the cause of the crash.
Unfortunately, other than recording the information on the screen, your only option when
experiencing a PSOD is to power the server off and back on. Once the server reboots you
should find a vmkernel‐zdump‐* file in your server /root directory. This file will be valuable for
determining the cause. You can use the vmkdump utility to extract the vmkernel log file from
the file (vmkdump –l ) and examine it for clues as to what caused the PSOD. VMware support
will usually want this file also. One common cause of PSOD's is defective server memory; the
dump file will help identify which memory module caused the problem so it can be replaced.
Checking your RAM for errors
If you suspect your system's RAM may be at fault you can use a built‐in utility to check your
RAM in the background without effecting your running virtual machines. The RAM check utility
runs in the VMkernel space and can be started by logging into the Service Console and typing
Service Ramcheck Start.
While RAM check is running it will log all activity and any errors to the /var/log/vmware
directory in files called ramcheck.log and ramcheck‐err.log. One drawback, however, is that it's
hard to test all of your RAM with this utility if you have virtual machines (VMs) running, as it
will only test unused RAM in the ESX system. A more thorough method of testing your server's
RAM is to shutdown ESX, boot from a CD, and run Memtest86+.
Using the vm‐support utility
If you contact VMware support, they will usually ask you to run the vm‐support utility that
packages all of the ESX server log and configuration files into a single file. To run this utility,
simply log in to the service console with root access, and type "vm‐support" without any
options. The utility will run and create a single Tar file that will be named "esx‐‐‐..tgz". You can
send it via FTP to VMware support. Make sure you delete the Tar file from the ESX Server once
you are done to save disk space.
Alternatively, you can generate the same file by using the VMware Infrastructure Client (VI
Client). Select Administration, then Export Diagnostic Data, and select your host (VirtualCenter
data optional) and a directory on your local PC to store the file that will be created.
Using log files for troubleshooting
Log files are generally your best tool for troubleshooting any type of problem. ESX has many log
files. Which ones you should check depends on the problem you are experiencing. Below is the
list of ESX log files that you will commonly use to troubleshoot ESX server problems. The
VMkernel and hosted log files are usually the logs you will want to check first.
• VMkernel ‐ /var/log/vmkernel – Records activities related to the virtual machines and ESX
server. Rotated with a numeric extension, current log has no extension, most recent has a ".1"
extension.
• VMkernel Warnings ‐ /var/log/vmkwarning – Records activities with the virtual machines, a
subset of the VMkernel log and uses the same rotation scheme.
• VMkernel Summary ‐ /var/log/vmksummary ‐ Used to determine uptime and availability
statistics for ESX Server; readable summary found in /var/log/vmksummary.txt.
• ESX Server host agent log ‐ /var/log/vmware/hostd.log ‐ Contains information on the agent
that manages and configures the ESX Server host and its virtual machines. (Search the file
date/time stamps to find the log file it is currently outputting to, or open hostd.log, which is
linked to the current log file.)
• ESX Firewall log ‐ /var/log/vmware/esxcfg‐firewall.log – Logs all firewall rule events.
• ESX Update log ‐ /var/log/vmware/esxupdate.log – Logs all updates done through the
esxupdate tool.
• Service Console ‐ /var/log/messages ‐ Contains all general log messages used to troubleshoot
virtual machines or ESX Server.
• Web Access ‐ /var/log/vmware/webAccess ‐ Records information on web‐based access to ESX
Server.
• Authentication log ‐ /var/log/secure ‐ Contains records of connections that require
authentication, such as VMware daemons and actions initiated by the xinetd daemon.
• Vpxa log ‐ /var/log/vmware/vpx ‐ Contains information on the agent that communicates with
VirtualCenter. Search the file date/time stamps to find the log file it is currently outputting to
or open hostd.log which is linked to the current log file.
As part of the troubleshooting process, often times you'll need to find out the version of
various ESX components and which patches are applied. Below are some commands you can
run from the service console to do this:
• Type vmware –v to check ESX Server version, i.e., VMware ESX Server 3.0.1 build‐32039
• Type esxupdate –l query to see which patches are installed.
• Type vpxa –v to check the ESX Server management version, i.e. VMware VirtualCenter Agent
Daemon 2.0.1 build‐40644.
• Type rpm –qa | grep VMware‐esx‐tools to check the ESX Server VMware Tools installed
version – i.e., VMware‐esx‐tools‐3.0.1‐32039.
If all else fails, restart the VMware host agent service
Many ESX problems can be resolved by simply restarting the VMware host agent service
(vmware‐hostd), which is responsible for managing most of the operations on the ESX host. To
do this, log into the service console and type service mgmt‐vmware restart.
NOTE: ESX 3.0.1 contained a bug that would restart all your VMs if your ESX server was
configured to use auto‐startups for your VMs. This bug was fixed in a patch for 3.0.1 and also in
3.0.2, but appeared again in ESX 3.5 with another patch released to fix it. It's best to
temporarily disable auto‐startups before you run this command.
In some cases restarting the vmware‐vpxa service when you restart the host agent will fix
problems that occur between ESX and both the VI Client and VirtualCenter. This service is the
management agent that handles all communication between ESX and its clients. To restart it,
log into the ESX host and type service vmware‐vpxa restart. It is important to note that
restarting either of these services will not impact the operation of your virtual machines (with
the exception of the bug noted above).
Fixing a frozen service console
Another problem that can occur is your Service Console can hang and not allow you to log in
locally. This can be caused by hardware lock‐ups or a deadlocked condition. Your VMs may
continue to operate normally when this occurs, but rebooting ESX is usually the only way to
recover. Before you do that, however, try shutting down your guest VMs and/or using VMotion
to migrate them to another ESX host. To do this, use the VI Client by connecting remotely via
SSH or by using one of alternate/emergency consoles, which you can access by pressing Alt‐F2
through Alt‐F6. You can also press Alt‐F12 to display VMkernel messages on the console screen.
If you are able to shutdown or move your VMs, then you can try rebooting the server by issuing
the reboot command through the VI Client or alternate consoles. If not, cold‐booting the server
is your only option.

How do I check my ESX & VirtualCenter versions?

• ESX Server
>Login to service console
>Type “vmware –v” – ie. “VMware ESX Server 3.0.1 build‐32039”
>Type “esxupdate –l query” to see what updates are installed.
• ESX Server management agent
>Type “vpxa –v” – ie. “VMware VirtualCenter Agent Daemon 2.0.1 build‐40644”
• VirtualCenter Server
>Check VC Server log file with the latest date in C:¥WINDOWS¥Temp¥vpx – ie. “Log for
VMware VirtualCenter, pid=4928, version=2.0.1, build=build‐40644”
>Optionally local the VI Client on the VirtualCenter server and select Help, then About.
• License Server
>On the License Server, load the Vmware License Server Tools (LMTools) client and select Help,
About – ie. 10.13
>Optionally, right‐click on either lmgrd.exe or lmtools.exe which is usually located in
C:¥Program Files¥Vmware¥Vmware License Server and select properties, then click on the
Version tab and select “File Version”
• Virtual Infrastructure Client
>Load client
>Select Help from the top menu and then About Virtual Infrastructure – ie. “Version 2.0.1 Build
40644” this should match your VC Server
• Vmware Tools (on a VM)
>Right‐click on icon inside VM
>Click on About tab – ie. “build‐32039” this should match your ESX server version
• Vmware Tools (on a ESX Server)
>Type “rpm –qa | grep VMware‐esx‐tools” – ie. “VMware‐esx‐tools‐3.0.1‐32039

How do I troubleshoot VirtualCenter issues?

VirtualCenter (VC) is the heart of any large VMware ESX environment. ESX can still run without
it, but features such as VMware Distributed Resource Scheduler (DRS) and VMotion are not
available, which makes host management more difficult.
When trouble occurs with VirtualCenter it is important to have it working properly as soon as
possible. This article will give you some tips for troubleshooting VirtualCenter and help you to
resolve any problems that occur with it.
Restarting a stopped Windows service
Typically when a problem occurs within VirtualCenter its Windows service will be stopped. If
you have an enterprise monitoring system, you should set both the VirtualCenter Server and
License Server services to alert you when this happens. Depending on the source of the
problem, restarting the service may bring it back up (i.e., the database was down or network
connectivity to the database server was lost).
Beginning with VC version 2.0.2, the recovery option for the service is set to automatically
restart in the event of a failure. If this is not the case on your server, then you can manually set
it by editing the properties of the VirtualCenter Server service. Select the Recovery tab and
then change the First, Second and Subsequent Failure options to "Restart the Service."
VirtualCenter will subsequently keep trying to restart itself and will be able to recover from any
temporary problems on its own.
General VirtualCenter troubleshooting
The first place to start when troubleshooting VirtualCenter problems is with the log files. The
main VC log file is the vpxd‐#.log (located in C:¥Windows¥Temp¥VPX for VC 2.0.x
and %allusersprofile%¥Application Data¥VMware¥VMware VirtualCenter¥Logs for VC 2.5.x,
multiple logs are automatically rotated), which should give you a good idea of what the cause
of the problem is.
Check the vpxd‐index file to see which number log file is currently in use or sort by modified
date. You should also check the Windows Event Log for any errors. You can also enable detailed
database logging by editing the vpxd.cfg file. To do this, insert the trace lines below and then
start the VirtualCenter service (vpxd.cfg is only read on VirtualCenter startup and is located in
the %allusersprofile%¥Application Data¥VMware¥VMware VirtualCenter directory). Also, to
enable the most detailed logging change the log level in either the vpxd.cfg or the VMware
Infrastructure Client to trivia (extended verbose).

http://searchvmware.techtarget.com/tip/0,289483,sid179_gci1317707,00.html

In addition to the logs on the VC server you may want to check the VC related logs on the ESX
Server. They are: /var/log/vmware/vpx/vpxa‐#.log (vc agent) and /var/log/vmware/hostd‐#.log
(host agent)
How to fix VirtualCenter database issues
Many VirtualCenter problems are caused by issues with the database that VC uses to store its
information. It's usually best to let a qualified database adminstrator (DBA) handle database
maintenance issues if possible. Some common database problems and how to handle them are
below:
• Loss of connectivity to the database server
Check for any network issues on your VC server including speed/duplex mis‐matches and
defective ports/cables. Any momentarily loss of connectivity between VC and the database
server can cause VC to quit. Your network administrator should be able to determine if there
are any issues with the physical network between the two servers. If your VC and/or database
server are running on a virtual machine check for resource constraints on your hosts to ensure
the virtual machine (VM) is getting the resources it needs to function properly.
• Database server is out of disk space
If you are using SQL Server this is typically caused by the transaction logs filling up. If you are
using the default Full Recovery Model consider switching to the Simple Recovery Model which
greatly reduces the size of the transaction logs. You can also shrink the transaction log to
reduce its size. See how in this KB article.
• Maximum tablespace size reached (Oracle only)
For Oracle databases, the tablespace that your database uses may not be set to auto‐extend
once it reaches its maximum size (defined when it was created). Many DBAs do not like to have
this set to auto‐extend by default. Have your DBA check this, and extend it if necessary. For
more information see this KB Article.
Possible problems with VirtualCenter upgrades
Another common problem can occur when upgrading VirtualCenter to a newer release. Each
new release of VirtualCenter is a full version and will overwrite the previous version. Take care
when upgrading and carefully answer the upgrade questions. Many users have inadvertently
wiped out and re‐initialized their databases while upgrading.
In later versions of VirtualCenter, the prompts have been changed to decrease the chances of
this happening. As part of the VC server upgrade, the VC agent on each ESX server that it
manages is also upgraded. Many times this does not complete successfully and afterwards
some of your ESX servers will appear as disconnected in VC.
There are several preventative measures. With some versions of ESX 3.0.x, you have to ensure
that the /tmp/vmware‐root directory exists on each ESX server or the VC agent install may fail.
This KB article has some options for dealing with this.
Fixing an ESX server that appears as disconnected
If you should find yourself in a situation where some of your ESX servers appear as
disconnected, you can first try restarting the hosted service on the server that is showing as
disconnected. Log into the Service Console and type "service mgmt‐vmware restart." Next try
restarting the vpx and authd services by typing "service vmware‐vpxa" and "service
vmware‐vmkauthd restart."
If the server still displays as disconnected, you can try manually installing the VC agent on the
ESX server by following these steps:
• On the VC server, locate the upgrade folder under your VC server program directory. Open
the bundleversion.xml file and look for the bundle ID that corresponds to your ESX version (ie.
ESX 3.0.x = 6, ESX 3.5.x = 7)
• Copy the appropriate vpx‐upgrade file for your bundle ID to a temp directory on your ESX
server (ie. vpx‐upgrade‐esx‐6‐linux‐)
• Install the file by typing the following from the Service Console in the directory that you
copied the file to: sh ./
• Once it completes restart the hostd and vpx services on the ESX host by typing "service
vmware‐vpxa restart" and "service mgmt‐vmware restart"
• If your server still shows disconnected, then a reboot of the ESX server is usually needed to
recover from this.
Generating a log bundle
If you need to contact support, they will usually want you to generate a log bundle for their
information. This is the VC equivalent of running VM support on an ESX server, and includes log
and configuration files that the support people will need to help troubleshoot your problem.
You can run this from the Start menu on the VC Server; it is located in the VMware folder and
called "Generate Virtual Center Server log bundle." If your Virtual Center server is running you
can select Administration, Export Diagnostic Data, uncheck any ESX hosts and make sure
"Include information from VC Server and VI Client" is checked to create a log bundle for VC.

How can I specify an alternate location for VM snapshot files?

To specify a new directory or datastore for snapshot files follow the below procedure. When you
specify a new working directory for a VM the vswp file that is created when the VM is powered on
is also stored in that location. If your VM is on shared storage and you specify local storage as a
location you will not be able to use Vmotion/HA/DRS.
• Power off your VM
• Login to service console
• Edit the VMX file of your VM with Nano or Vi
• Add a new line using the following syntax: workingDir =
"/vmfs/volumes/SnapVolume/Snapshots/"
• Optionally if you want your vswp file to stay in the VM’s directory add the following line to the
VMX file: sched.swap.dir = "/vmfs/volumes/VM‐Volume1/MyVM/" (You do not need to worry about
updating the existing “sched.swap.derivedName” parameter, it is generated by the VM and written
to the config file each time the VM powers on.)
• Power on your VM, your vswp, vmsn and snapshot (delta‐vmdk) files will now be located in this
directory

What are the ESX specific commands that can be used on the Service Console?

Below is a list of the commands, more detail for using these commands can be found in the Server
Configuration Guide (http://www.vmware.com/pdf/vi3_server_config.pdf). In general (with a few
exceptions) anything that can be done with these commands can also be done in the VI client,
sometimes the situation requires doing these directly on the service console. Also Mike Laverick has
put together a great guide on using a lot of these commands

Networking
Esxcfg‐firewall – Configures the service console firewall ports
Esxcfg‐nics – Prints a list of physical network adapters along with information on the driver, PCI
device, and link state of each NIC. You can also use this command to control a physical network
adapter’s speed and duplexing
Esxcfg‐route – Sets or retrieves the default VMkernel gateway route
Esxcfg‐vmknic ‐ Creates and updates VMkernel TCP/IP settings for VMotion, NAS, and iSCSI
Esxcfg‐vswif – Creates and updates service console network settings. This command is used if you
cannot manage the ESX Server host through the VI Client because of network configuration issues
Esxcfg‐vswitch – Creates and updates virtual machine (vswitch) network settings

Storage
Esxcfg‐mpath ‐ Configures multipath settings for your Fibre Channel or iSCSI disks
Esxcfg‐nas – Manages NAS mounts. You use this command to add, delete, list, and change the
attributes of NAS devices
Esxcfg‐swiscsi – Configures your software iSCSI software adapter
Esxcfg‐vmhbadevs – Prints a map of VMkernel storage devices to service console devices (no VI
client equivalent)

General
Esxcfg‐advcfg ‐ Configures advanced options for ESX Server.
Esxcfg‐auth – Configures authentication (no VI client equivalent)
Esxcfg‐info ‐ Prints information about the state of the service console, VMkernel, various
subsystems in the virtual network, and storage resource hardware
Esxcfg‐resgrp ‐ Restores resource group settings and lets you perform basic resource group
management
Esxcfg‐upgrade ‐ Upgrades ESX Server from ESX Server 2.x to ESX Server 3.x. This command is not
for general use

Boot/diagnostic
Esxcfg‐boot – Configures bootstrap settings (no VI client equivalent)
Esxcfg‐dumppart ‐ Configures a diagnostic partition or searches for existing diagnostic partitions
Esxcfg‐init ‐ Performs internal initialization routines (no VI client equivalent)
Esxcfg‐linuxnet ‐ Converts vswif to eth when booting ESX Server into service‐console‐only mode
rather than into ESX mode (no VI client equivalent)
Esxcfg‐module ‐ Sets driver parameters and modifies which drivers are loaded during startup (no VI
client equivalent)

How can I display disk/directory information on the Service Console?
Type “df –h” to show drives and space
Type “fdisk –l” to show physical drive information
Type “cat /proc/scsi/scsi” to show SCSI device information
Type “vdf –h” to show vmfs volumes and space
Type “ls –ltr” to show files and space

How do I manually install the VC management agent?

If after upgrading VirtualCenter you find some of your ESX hosts disconnected you can manually
upgrade the management agent on the ESX server by following the below steps:
• First log into the ESX server console and check the version on the servers that are disconnected by
typing “vpxa‐ v” The version needs to match the version of VirtualCenter being used.
‐ VC 2.0.1 build number is 32042
‐ VC 2.0.1 build number is 32042
‐ VC 2.0.1 Patch 1 build number is 33643
‐ VC 2.0.1 Patch 2 build number is 40644
• Open the folder for the VC 2.0 installation. By default this will be "C:¥Program
Files¥VMware¥VMware VirtualCenter 2.0¥upgrade"
• You need to use the correct file for different version of ESX server. You can find your answer in
bundleversion.xml
‐ 2.0.1+ = vpx‐upgrade‐esx‐0‐linux‐*
‐ 2.5.0 = vpx‐upgrade‐esx‐2‐linux‐*
‐ e.x.p = vpx‐upgrade‐esx‐6‐linux‐*
• Copy file "vpx‐upgrade‐esx‐y‐linux‐xxxxx" to your ESX host, where y and xxxxx are based on
bundleversion.xml. xxxxx is the build number, ie. vpx‐upgrade‐esx‐6‐linux‐40644. Use a secure copy
utility such as WinSCP or PuTTY PSFTP to copy this file to the ESX server.
• Login to the ESX server as root.
• In the directory where you copied the upgrade bundle run the command: sh ./
vpx‐upgrade‐esx‐y‐linux‐xxxxx (xxxxx is the build number)
• Once the install is complete run the command “service vmware‐vpxa restart” followed by “service
mgmt‐vmware restart”
• Check the version again by typing “vpxa –v”, the version should now be the new version. Now
open your VI Client, try to connect to the ESX host.

How can I purge old statistic data from the VirtualCenter database?
The size of the Statistics database (VPX_HIST_STAT) will vary based on the number of hosts & VM’s
managed, frequency of performance data collection, collection level and type of database. Each stat
sample collected is about 60 bytes for SQL, 100 bytes for Oracle, and each event stored is 1600
bytes for SQL, 600 bytes for Oracle. Using default settings, the statistical data for 25 hosts running
8‐16 VMs per host will plateau around 40‐60 MB in a year (80‐140 MB if set to “full”). Each month,
the average number of events generated will also consume about 190 MB in SQL, and 70 MB in
Oracle. Total DB size after a year is expected to be around 2.20 Gb in SQL, and 1.0 Gb in Oracle.
Using default settings, the statistical data for 75 hosts running 8‐16 VMs per host will plateau
around 90‐150 MB in a year (200‐330 MB if set to “full”). Each month, the average number of
events generated will also consume about 190 MB in SQL, and 70 MB in Oracle. Total DB size after a
year is expected to be around 2.40 Gb in SQL, and 1.2 Gb in Oracle.

The statistic sample frequency and retention is specified in the VI client. Select Administration,
VirtualCenter Management Server Configuration from the top menu then select Statistics. The
default settings are:

• Past Day – 5 minutes per sample, 288 total samples
• Past Week – 15 minutes per sample, 672 total samples
• Past Month ‐ 60 minutes per sample, 720 total samples
• Past Year – 1440 minutes per sample, 365 total samples

For example if you wanted to collect less statistical data you could change the settings to something
like below:


Or if you wanted to collect more statistical data you could change the settings to something like
below (caution your database will be very large):


You can also delete any ones you do not want, for example if you only want a weeks worth of data
then delete the Past Month and Past Year. Once the total samples number has been reached the
older samples are automatically purged from the database. If you modify these values you must
follow these rules:

• The new sampling period must be a multiple of a previous one. In the defaults you’ll notice that
week (15) is a multiple of day (5), month (60) is a multiple of week(15) and year (1440) is a multiple
of month (60).
• The new sampling length must be longer than a previous one. Week (15) is longer then day (5),
etc.
• The user‐specified name of the historical interval must be unique. (In case you add new ones)

Note: Existing data is reset (lost) when you change the interval configuration. However, only the
data for that interval is reset. For example, if you change only the weekly time interval, the daily
and monthly data are retained.

You can also specify the amount of statistical detail that is captured by setting the Statistic
Collection Level. The default for this setting is Level 1 which includes basic metrics, it can be
changed anywhere up to Level 4 which provides the most statistical detail but can significantly
increase the size of the database and can cause additional performance overhead. You can also
change the number of threads that are used for collecting performance statistics from managed
hosts. Use multiple threads to increase the number of managed hosts and take advantage of the
additional processor.

How can I purge old Event and Task data from VirtualCenter?
VirtualCenter does not support doing this directly, the only way you can do this by deleting directly
from the database tables. It is strongly recommend to have a functional backup of the VC database
before clearing these tables in case of an unforeseen problem. Also the the VC service must be
stopped in order to avoid data corruption. This is not a supported procedure by Vmware but should
be in my opinion, these tables can get pretty large in big environments as every single task and
event is preserved in the database.

The tables where the data is stored are VPX_TASK (Tasks) and VPX_EVENT, VPX_EVENT_ARG
(Events). The VPX_EVENT_ARG will usually have more rows then the VPX_EVENT table. This is
because the VPX_EVENT table only has one row per event but the VPX_EVENT_ARG table can have
multiple rows per event (The link between the 2 tables is the EVENT_ID column).

• Shutdown the VirtualCenter service
• Connect to the database server that is hosting the VC database with a SQL browser/client. You can
use a free tool like WinSQL Lite (http://www.snapfiles.com/get/winsql.html) for this.
• To delete all data in the tables type: ‘delete from VPX_TASK’ then ‘delete from VPX_EVENT’ and
then ‘delete from VPX_EVENT_ARG’ and finally ‘Commit’
• Optionally you can do ‘truncate table VPX_TASK’ then ‘truncate table VPX_EVENT’ and then
‘truncate table VPX_EVENT_ARG’ (Truncate is faster and does not use as much undo space as
delete)
• To selectively delete data older then 30 days: ‘delete from VPX_TASK where complete_time <
sysdate ‐ 30)
• To selectively delete data older then 30 days from VPX_EVENT and VPX_EVENT_ARG is trickier
because VPX_EVENT_ARG does not have a date field and it tied to the events in VPX_EVENT by the
Event_id field.
• First delete from the child table (VPX_EVENT_ARG): ‘delete from vpx_event_arg where event_id
in (select a.event_id from vpx_event_arg a, vpx_event b where a.event_id = b.event_id and
create_time < sysdate ‐ 30)
• Next commit the delete by typing ‘Commit’
• Then delete from the parent table (VPX_EVENT): ‘delete from vpx_event where create_time <
sysdate – 30’
• Finally commit again by typing ‘Commit’
• Start the VirtualCenter service

What data is stored in the VirtualCenter database?
As of version 2.0.1 of VirtualCenter the database consists of the following tables. The database
mainly consists of alarm/event data, HA/DRS data, ESX host information, task/scheduled tasks and
VM information. All ESX server and VM configuration data is stored on each ESX server and is simply
read and displayed by VC. VC is just a central management front end to set configuration
information and displays information that is read from all ESX hosts instead of having to manage
each server individually. You can also use the VIC to connect directly to the ESX servers without
VirtualCenter and modify the same configuration data. Once you add a ESX host back into VC it
reads all the configuration info from that host.

The database is not critical to the operation of ESX servers or their virtual machines, they would
continue to function normally if VC or it’s database were unavailable (Except for DRS and vMotion
which would not work, HA would still work). If the database were to crash and a new one created
you could add your ESX servers back in and it would repopulate the configuration information. The
only data unique to the database is performance statistics, alarms, events, tasks, resource pools and
custom attributes. This is not official documentation and is based on my browsing the database
schema and data with a SQL client. Using a SQL client like Toad (Quest Software) or WinSQL Lite
(Free) you can browse the data contained in these tables, you can also write SQL code to query
information contained in the tables. Below is some sample SQL code to query information on VM’s
and hosts. For information on the views defined in VirtualCenter see this white paper:
http://www.vmware.com/pdf/vc_dbviews_2x.pdf
• VPX_ACCESS – Used to store VC users and groups. This table has 5 columns and as many rows as
you have users & groups defined in VC.
• VPX_ALARM – Used to store VC alarm definitions. This table 10 has columns and as many rows as
you have defined alarm definitions.
• VPX_ALARM_ACTION – Used to store VC alarm actions and triggers. This table has 10 columns
and two rows for every defined alarm definition.
• VPX_ALARM_EXPRESSION – Used to store alarm conditions and expressions. This table has 9
columns and two rows for every defined alarm definition.
• VPX_ALARM_REFRESH – Has to do with alarms, not sure what it is used for. This table has 3
columns and had no rows in my case.
• VPX_ALARM_RUNTIME – Used to store alarm events for each host or VM that is covered by a
defined alarm, this table has 7 columns and as many rows as hosts/VM’s that have alarms
configured. For example if you had 10 VM’s and each had 3 alarms assigned to them you would
have 30 rows.
• VPX_COMPUTE_RESOURCE – Used to store resource information for DRS, This table has 15
columns and a small amount of rows depending on how many resource pools are defined.
• VPX_COMPUTE_RESOURCE_DAS_VM – Used to store resource information for HA (priority, # of
failure, retry period, power off/on isolation). This table has of 6 columns and as many rows as you
have VM’s that are part of HA.
• VPX_COMPUTE_RESOURCE_DRS_VM – Used to store resource information for DRS (enabled,
behavior). This table has 4 columns and as many rows as you have VM’s that are part of DRS.
• VPX_CUSTOMIZATION_SPEC ‐ Not sure what it is used for, this is usually a small table consisting of
6 columns and had no rows in my case.
• VPX_DATACENTER – Used to store Data Center information in VC, This table has 4 columns and as
many rows as you have defined Data Centers.
• VPX_DATASTORE – Used to store VMFS/NAS datastore information (storage URL, capacity, free
space, type). This table has 9 columns and as many rows as you have defined data stores (RDM’s will
not show up here).
• VPX_DS_ASSIGNMENT – Used to store what datastores are assigned to each VM (mount path, id,
mode). This table has 6 columns and as many rows as each of your VM’s assigned datastores.
• VPX_ENTITY – Used to store the names and ID’s of all entities in VC (VM’s, ESX hosts, Folders, Data
Centers). This table has 4 columns and as many rows as you have individual entities.
• VPX_EVENT – Used to store all events as a result of tasks or alarms in VC (event type, date/time,
VM name, username, category, hostname), this table is typically large and has 15 columns and
usually a large amount of rows but is generally small in megabytes, 50,000 rows will equal
approximately 9MB.
• VPX_EVENT_ARG – This corresponds to the VPX_EVENT table and contains event ids, argument
types & data and miscellaneous IDs. This table is usually pretty large and contains the text of the
events from the VPX_EVENT table. This table has 14 columns and usually has more records then the
VPX_EVENT table, 150,000 records will generally use about 20MB of space.
• VPX_FIELD_DEF – Used to store custom attribute names that are displayed in the VI client. This
table has 2 columns, id and name, and as many records as custom attributes that you have defined.
• VPX_FIELD_VAL – Used to store custom attribute values that are displayed in the VI client. This
table has 3 columns, field id (corresponds to VPX_FIELD_DEF table), entity id (corresponds to
VPX_ENTITY table) and value. It will have as many rows as you have values for custom attributes.
• VPX_GUEST_DISK – Used to store disk space information for VM’s. This table has 4 columns, vm id
(corresponds to VPX_VM table), path (drive letter), disk capacity and free space. It will have a row
for each drive partition that a VM has configured.
• VPX_GUEST_IP_ADDRESS – Used to store IP address information for VM’s. This table has 3
columns, vm id (corresponds to VPX_VM table), device id (usually 4000, increments if you have
more then one IP address), and ip address. It will have a row for each ip address that a VM has
configured.
• VPX_GUEST_NET_ADAPTER – Used to store the VM network name for each network adapter,
these correspond to the network names in each vswitch configuration. This table has 5 columns vm
id (corresponds to VPX_VM table), device id (usually 4000, increments if you have more then one IP
address), mac address, is connected and network name. It will have a row for each network adapter
that a VM has configured.
• VPX_HIST_STAT – Used to store historical performance statistics that are collected by
VirtualCenter. This is the biggest table and only has 5 columns (sample id, stat id, entity id, device id
and stat value) but can have millions of rows in it.
• VPX_HOST – Used to store ESX server host information. This table has 46 columns (host
configuration data) and will have a row for each host in VC.
• VPX_HOST_CPU – Used to store ESX server host CPU information. This table has 6 columns (host
id, cpu index, hertz, bus hertz, cpu description and cpu vendor) and will have a row for each CPU
(not core) that a ESX server has in it.
• VPX_HOST_CPUID_FEATURE – Used to store ESX server host CPU Identification masks. This table
has 7 columns (host id, feature level, feature vendor, EAX mask, EBX mask, ECX mask, EDX mask)
and usually has 5 rows for each ESX server that you have regardless of the number of CPUs in each
host.
• VPX_HOST_CPU_CPUID_FEATURE – Similar to the previous table. This table has 8 columns (same
as above plus a cpu index column) and usually has 10 rows per ESX server that you have regardless
of the number of CPUs in each host.
• VPX_HOST_CPU_THREAD – Used to store ESX server host CPU thread information. This table has 3
columns (host id, cpu index, thread id) and a row for each CPU core in each ESX server. If you had a
dual‐core server there would be 4 rows with thread ID’s of 0,1,2 and 3.
• VPX_HOST_NODE – Used to store ESX server host memory information. This table has 4 columns
(host id, numa id, mem range begin, mem range length) and a row for each CPU (not core) that a
ESX server has in it.
• VPX_HOST_NODE_CPU – Used to store ESX server host CPU and memory id’s. This table has 3
columns (host id, cpu id, numa id) and a row for each CPU core in each ESX server.
• VPX_HOST_PCI_DEVICE – Used to store ESX server host hardware information. This table has 12
columns (host id, pci id, class id, bus, slot, pci function, vendor id, sub vendor id, vendor name,
device id, sub device id, device name) and a row for each hardware device in each ESX server
(approx. 32). This includes NIC, FC cards, processors, video cards, USB, etc.
• VPX_HOST_VM_CONFIG_OPTION – Unsure what this is used for, as the name implies it has
something to do with VM configs. This table has 4 columns (host id, config option ver, data, array
index) and 2 rows for each ESX server.
• VPX_LICENSE – Used to store ESX server license information. This table has 3 columns (serial
number, serial key, type) amd appears to not be used if you use a License Server in your
environment. Possible used if you use host based licenses instead of a license server.
• VPX_LOCK ‐ Unsure what this is used for, as the name implies it has something to do with locks.
This table only has one column (id) and only one row that has a value of 0.
• VPX_NETWORK – Used to store ESX server host network name configurations, these correspond
to the network names in each vswitch configuration. This table has 3 columns (id, name, data
center id) and a row for each unique network name configuration.
• VPX_NW_ASSIGNMENT – Used to store VM to network name mappings. This table has 2 columns
(network id, entity id) and a row for each NIC that every VM has configured.
• VPX_OBJECT_TYPE – Used to store object type names for VirtualCenter (ie. vm, host, alarm, task).
This table has 2 columns (id, name) and usually 12 rows.
• VPX_PARAMETER – Used to store VirtualCenter configuration parameters (ie. smtp settings, snmp
settings, port numbers, time outs). This table has 2 columns (name, value) and approximately 42
rows.
• VPX_PRIV_ROLE – Used to store all VirtualCenter privileges (ie. VirtualMachine.Interact.PowerOn,
ScheduledTask.Run) that can be assigned to users and groups. This table has 2 columns (privilege
name, role id) and as many rows as there are unique privileges (approximately 293).
• VPX_RESOURCE_POOL – Used to store Resource Pool information. This table has 13 columns (id,
config spec, allocated cpu, allocated vm cpu, allocated mem, allocated vm mem, available pool
mem, available vm mem, current cpu, current mem, overall status) and as many rows as you have
resource pools defined.
• VPX_ROLE – Used to store all VirtualCenter Role information (ie. VirtualMachineAdministrator,
VirtualMachineUser). This table has 2 columns (id, name) and will have as many rows as roles that
are defined.
• VPX_SAMPLE – Used to store historical statistic sample times and intervals, corresponds with
VPX_HIST_STAT table. This table has 3 columns (id, sample time, sample interval) and usually a large
amount of rows (although now where near as large as VPX_HIST_STAT).
• VPX_SCHEDULED_TASK – Used to store scheduled task information in VirtualCenter. This table has
15 columns and will have as many rows as scheduled tasks that are defined.
• VPX_SCHED_ACTION – Used to store scheduled task action information in VirtualCenter. This
table has 3 columns (scheduled task id, action type, action data) and will have as many rows as
scheduled tasks that are defined.
• VPX_SCHED_SCHEDULER ‐ Used to store scheduled task scheduler information in VirtualCenter.
This table has 16 columns and will have as many rows as scheduled tasks that are defined.
• VPX_SEQUENCE ‐ Unsure what this is used for. This table has 2 columns (id, name) and in my case
0 rows.
• VPX_SNAPSHOT – Used to store snapshot information for VM’s. This table has 11 columns (id,
host snapshot id, vm id, snapshot name, snapshot desc, create time, power state, is quiesced,
parent snapshot id, is current snapshot, config) and will have a row for as many snapshots that exist
for your VM’s.
• VPX_STAT_CONFIG – Used to store statistic collection intervals in VirtualCenter. This table has 3
columns (length, name, sample interval) and as many rows as you have collection intervals defined
(usually 4).
• VPX_STAT_DEF – Used to store statistic definitions in VirtualCenter. This table has 7 columns (id,
rollup type, name, group name, type, unit, associate ids) and has approximately 168 rows.
• VPX_ TASK – Used to store all task information (ie. VM Power On, VM Re‐configure, Alarm Create)
that occurs in VirtualCenter. This table has 27 columns and as many rows as tasks that have
occurred in VirtualCenter (can be thousands).
• VPX_VERSION – Used to store VirtualCenter database version (ie. VirtualCenter Database 2.0).
This table has 2 columns (ver id, version value) and usually one row .
• VPX_VM – Used to store virtual machine configuration information (ie. vm id, path to vmx file,
uuid, os, state, memory, resource group, ip address, vmware tools version, etc.) read from the ESX
server it is hosted on. This table has 41 columns and as many rows as VM’s that are managed by
VirtualCenter.
• Sample SQL code to query Disk Space info from all VM’s (in gigabytes):
o select b.name, path, round(capacity/1073741824,2) "Total", round(free_space/1073741824 ,2)
"Free" from vpx_guest_disk a, vpx_entity b where a.vm_id = b.id order by b.name
• Sample SQL code to display Up Time info from all VM’s:
o select b.name, (to_char(sysdate, 'J') ‐ to_char(boot_time, 'J')) "Up Days" from vpx_vm a,
vpx_entity b where a.id = b.id order by b.name
How can I migrate my VirtualCenter database from MSDE to SQL server?
Note: This has only been tested on SQL 2000 but should work OK on SQL 2005
• Shutdown the VirtualCenter Server so it disconnects from the SQL database.
• At a CMD prompt type “osql –E –D <ODBC datasource name>” ie. “osql –E –D ‘VMware
VirtualCenter’” This will load the osql command line SQL client for MSDE, login using the local
trusted connection and connect using the VC ODBC data source.
• At the 1> prompt type the following, “use master” closes the connection to the vcdb so it can be
detached, go executes the previous SQL statements.
• Use master
• Exec sp_detach_db ‘vcdb’
• Go
• Copy the two database files (vcdb.mdf and vcdb.ldf) to the destination SQL server data directory.
• Load SQL Enterprise Manager on the destination database server.
• Select Security and then right click on Logins and select “New Login”. In this example we are using
vpxadmin as the SQL user account.
• On the General tab specify the username, if using SQL authentication make sure the password
also matches and click OK.
• Right click on “Databases” and select “All Tasks” and then “Attach Database”
• Browse to the directory that you copied the database and log files to and select the MDF file for
VC, select vpxadmin as the owner and click OK.
• Select Security and Logins, right‐click on the vpxadmin user and select “Properties”.
• Change the Default Database from “Master” to “VCDB”
• On the VC Server, edit the existing ODBC connection for VC under the System DSN tab. Change the
Server from MSDE to the appropriate SQL Server and click Next.
• Select the appropriate authentication method, if using SQL authentication enter the
username/password that you created in the Security step above and click Next.
• Click Next again, the default database should already be VCDB, click Finish and that’s it.
• Click the “Test Datasource” button to verify that it works and then OK.
• On the VC server, run the VC installation program, click Next at the Welcome screen and then
select Repair and click Next.
• Select “Use an existing database server” and click Next, enter the SQL db username and password
and click Next.
• At the Overwrite Data message select NO.
• At the License Server screen select the appropriate option (usually use an existing license server)
and click Next.
• Enter the appropriate license server address (usually 27000@localhost) and click Next.
• Enter the appropriate port information (usually the default is fine) and click Next.
• Enter the appropriate Apache web server port (usually 8086) and click Next then click the Install
button.
• Start the VC server and that should be it. If the VC Server fails to start check the log files localed in
C:¥Windows¥Temp¥VPX for the reason why.

How can I move my VirtualCenter SQL database to another SQL server?
Note: This has only been tested on SQL 2000 but should work OK on SQL 2005.
• Shutdown the VirtualCenter Server so it disconnects from the SQL database.
• Load SQL Enterprise Manager on the source database server.
• Right click on the VirtualCenter database and select “Detach Database”
• Click “OK” to detach the database.
• Copy the VC database (MDF) and log file (LDF) from the SQL Data directory on the source server
to the SQL Data directory on the new SQL server.
• Load SQL Enterprise Manager on the destination database server.
• Select Security and then right click on Logins and select “New Login”. In this example we are using
vpxadmin as the SQL user account.
• Specify the same SQL username as the previous SQL server, if using SQL authentication make sure
the password also matches. Accept the defaults and click OK.
• Right click on “Databases” and select “All Tasks” and then “Attach Database”
• Browse to the directory that you copied the database and log files to and select the MDF file for
VC, leave SA as the owner and click OK.
• If you are using a local SQL or Windows account for VC you will have to fix the orphaned usersid
on the destination server, you can use the below procedure or download the Sync SQL Logins utility
to do this.
• Load Query Analyzer, login as the SA account.
• Verify the orphaned user (vpxadmin) by executing the below SQL, it should return one orphaned
username and usersid.
• use virtualcenter
• exec sp_change_users_login 'report'
• Fix the orphaned user by executing the below SQL, this will link the old vpxadmin account to the
new and correct the SID.
• exec sp_change_users_login 'update_one', 'vpxadmin', 'vpxadmin'
• Verify the orphaned user (vpxadmin) has been fixed by executing the below SQL, it should nothing.
• exec sp_change_users_login 'report'
• On the VC Server open the ODBC connection for VirtualCenter and click Configure
• Select or type in your new SQL Server name and click Next
• Select your authentication method and enter the username/password and click Next.
• Select Change the Default Database To and choose the VC database and click Next.
• Click Finish and then click the Test DataSource button to verify connectivity.
• Start the VirtualCenter server and you should be all set. If the service will not start check the VC
log files in the c:¥windows¥temp¥vpx directory for any errors.
• Reference these Microsoft kb articles for more information:
• Moving DB's between Servers ‐ http://www.support.microsoft.com/?id=314546
• How to Resolve Permission Issues When a Database Is Moved Between SQL Servers ‐
http://www.support.microsoft.com/?id=240872
• How To Transfer Logins and Passwords Between SQL Servers ‐
http://www.support.microsoft.com/?id=246133
• Troubleshooting Orphaned Users ‐ http://support.microsoft.com/kb/274188/
• User Logons and Permissions Incorrect after a Database Restore ‐
http://support.microsoft.com/?id=168001
• Sync SQL Logins utility ‐ http://www.dbmaint.com/SyncSqlLogins.asp
• MapSids Utility ‐ http://support.microsoft.com/?id=298897

How can I find out information about my VirtualCenter SQL database?
You can use the sp_helpfile stored procedure to get general information on your VC SQL database.
• Load the SQL Query Analyzer on the SQL Server and login with your virtualcenter database
credentials.
• Type the following in the query window
• Use <database name> ie. virtualcenter
• Sp_helpfile
• Press F5 or the Execute Query icon.
• The results window will return the database file names (ie. virtualcenter_Data.mdf,
virtualcenter_Log.mdf), the current size, maximum size, automatic growth percentage and usage.

To find more detail on individual tables in the VC database you can use the sp_spaceused stored
procedure.
• Load the SQL Query Analyzer on the SQL Server and login with your virtualcenter database
credentials
• Type the following in the query window
• Use <database name> ie. virtualcenter
•EXEC Sp_spaceused ‘table name’ ie. vpx_hist_stat
• Press F5 or the Execute Query icon.
• The results window will return the table name, number of rows (records), total amount of space
reserved for the table, total amount of space used by the data, total amount of space used by
indexes and the total amount of space reserved but not yet used.

Everything about HA and Troubleshooting

The following link will provide u the details

http://xtravirt.com/xd10005

Understanding VMWare snapshots

Virtual Machine Snapshot is the major feature VMware. A snapshot is a picture of your system at
the time the snapshot is taken. It is as an image of your computer’s hard drive and configuration for
that virtual machine when you take a snapshot. The snapshot files that are created contain only the
changes that have occurred to the virtual machine since the snapshot was taken. Thus, over time,
the snapshot files will grow as the machine is used more and more.

∙ <machine name>‐SnapshotX.vmsn (Where X is the number of the snapshot taken) This file stores
the state of the virtual machine when the snapshot was taken.

∙ <machine name>‐SnapshotX.vmem (Where X is the number of the snapshot taken) This file stores
the state of the virtual machine memory when the snapshot was taken.

∙ <machine name>‐n.vmdk (where n is the number of the disk image)

Snapshots are the easiest way to restore the system within few minutes back to its state when
snapshot was taken. So if you are planning to perform a change to your server so its s good idea to
take a snapshot before performing the change so that if anything goes wrong you can switch back
to initial state after restoring snapshot.

Taking Snapshot of a Virtual Machine ‐

Taking a snapshot is very simple. You can take snapshot either by using Virtual Infrastructure Client
or Command line.

Using VI client to take a snapshot select Virtual Machine, then right click, then go to “Snapshot”
option in menu and select “Take Snapshot”. Fill in Snapshot Name and Description and click “ok” to
take snapshot.

Using command line use following command to take snapshot –

#vmware‐cmd <path to Virtual machine’s vmx file> createsnapshot <name> <description> <quiesce
“yes/no”> <memory “yes/no”>

Choosing yes for quiesce will quiesce file system writes before taking the snapshot. Choosing yes for
memory will snapshot the VM's memory state.

Reverting to a Snapshot –

You can revert to a snapshot using VI client or to last snapshot using command line.

Using VI client right click on virtual machine, then select “Snapshot” from menu and then click on
“Revert to Snapshot” to revert to last snapshot or click on “Snapshot Manager” to view all available
snapshots. Click on snapshot to which you want to revert to and click “go to” button.

Using command line, run the following command to revert to last snapshot‐

#vmware‐cmd <path to Virtual machine’s vmx file> revertsnapshot

Capacity Planning for Taking Snapshots –

Though snapshot makes the system restore easy but there is disk space overhead. Snapshot
requires additional disk space as it creates new vmdk file (a redo file) which grows with time as
changes are made to the virtual disk.

This new vmdk file which gets created after taking snapshot can grow maximum upto the size of
virtual disk in the server. It is suggested that snapshots should not be kept for long and should be
deleted as soon as possible because deleting snapshot merge the new vmdk file to original one and
if new vmdk file has grown large then the merging can become time consuming and lead to host
instability resulting vmdk file corruption.

Once you take the snapshot, the original vmdk file gets locked and a new vmdk file gets created
which starts growing little faster then the amount of disk write you are doing on the server. Please
note that moving files from one location to other on the same drive doesn’t affect the size of newly
created vmdk file after taking snapshot. Also deleting a file from disk doesn’t affect the size of
newly created vmdk file after taking snapshot.

So in simple mathematics if you have 10GB disk in our server and you are writing an average of
100MB of data daily then after taking snapshot a new vmdk file will be created and will grow little
more than 100MB daily until it reaches 10GB.

Lets take another scenario in which you already have one snapshot in the server of which I took
example in above paragraph. Suppose before taking second snapshot the size of vmdk file created
after taking first snapshot is 5GB. Now once you take second snapshot the orginal vmdk file and the
vmdk file which got created after taking first snapshot gets locked and a new vmdk file gets created
which starts growing as changes are made to the disk. This newly created file can again grow till the
size of disk i.e 10GB.

I hope this might have given you an idea about capacity planning for taking snapshot.

Deleting Snapshots –

As I suggested above, snapshots should not be kept for long as they grows with time and can result
in system instability and disk corruption. Snapshots can be deleted using VI Client or using
command line by login to the host directly.

Using VI client right click on Virtual Machine and then go to “Snapshot” from menu and then click
on “Snapshot Manager”. It will open another window showing all the snapshots taken for that VM.
To delete a particular snapshot select it and click on “Delete” button at the bottom. To delete all
snapshots you can click on “Delete All” option.

Using command line use following command to delete all the snapshot for the Virtual Machine
name used in command –

#vmware‐cmd <path to Virtual machine’s vmx file> removesnapshots

If new vmdk file has already grown large then deleting snapshot can become time consuming and
lead to system instability. So avoid such conditions by not keeping snapshots for long.

Also if you have one snapshot and size of new vmdk file is 5GB and original disk size is 10 GB then
while deleting snapshot 5GB file will be first merged to original 10GB vmdk file and hence disk
usage at that time will be 20GB (15 +5), so you have have suffient free space while deleteling
snapshot.

Another example if you are having two snapshots with original vmdk as 10GB, first vmdk file after
taking first snapshot as 5 GB and second vmdk file after taking second snapshot as 3 GB then on
deleting all snapshots second vmdk will be first merged to first vmdk file making it 8GB and then it
will be merged to original vmdk file making it 18GB. So in this case ou should have total free space
of 26GB (18+5+3).

Another way to delete snapshot which didn’t get deleted with above is following –

Another method is to shutdown the VM, login to the Service Console, switch to the VM's directory
and clone the VM's disk file by using vmkfstools and specifying the snapshot file as the source disk,
i.e. "vmkfstools –i myvmname‐000001.vmdk myvmnamenew.vmdk" Once it completes go into the
settings for the VM, remove (don't delete) the hard disk, add a new hard disk and browse to the
newly created disk file. Power on the VM and verify everything is working before you delete the old
disk and delta files.

Command line snapshot management (create, delete, status etc)

a) Command to create snapshot –

#vmware‐cmd <path to Virtual machine’s vmx file> createsnapshot <name> <description> <quiesce
“yes/no”> <memory “yes/no”>

b) Command to revert to last snapshot –

#vmware‐cmd <path to Virtual machine’s vmx file> revertsnapshot

c) Command to check if VM has snapshots –

#vmware‐cmd <path to Virtual machine’s vmx file> hassnapshot

d) Command to remove all snapshots –

#vmware‐cmd <path to Virtual machine’s vmx file> removesnapshots

Never expand a disk file with a snapshot running

If you expand a disk while snapshot is running then you will not be able to power on the VM and
you will receive an error: "Cannot open the disk ".vmdk" or one of the snapshot disks it depends on.
Visit http://www.vmworld.com/vmworld/static/sessions/2007/IO44.html to see how to fix.

Be warned, though. If your VM is on shared storage and you specify local storage as a location you
will not be able to use features like VMotion/HA/DRS. To do this follow these steps:

1. Power off your VM and login to the Service Console.
2. Edit the VMX file of your VM with Nano or Vi
3. Add a new line using the following syntax: workingDir =
"/vmfs/volumes/SnapVolume/Snapshots/"
4. If you want your vswp file to stay in the VM's directory, add the following line to the VMX file:
sched.swap.dir = "/vmfs/volumes/VM‐Volume1/MyVM/". This step is optional. Furthermore, you do
not need to worry about updating the existing "sched.swap.derivedName" parameter because it is
generated by the VM and written to the config file each time the VM powers on.
5. Power on your VM and your vswp, vmsn and snapshot (delta‐vmdk) files will now be located in
this directory

Using VMotion with snapshots:
If you try to VMotion a VM with running snapshots from one host to another you will receive the
following warning: "Reverting to snapshot would generate error (warnings) on the destination
host." This simply warns that if you have changed the default locations for any files of the VM (like
snapshot or vswp files as detailed above), the VM will crash when the migration is complete. This is
true if the destination host cannot access the same storage that the files are located on as the
source host.

So if your VM was on shared storage and configured so that the snapshot files were on local storage,
then you would have a problem if you VMotioned the VM to another host. If your VM has all its files
on shared storage, and that storage is accessible to all ESX hosts then you're in good shape.
VMware recommends that you commit all snapshots before VMotioning VMs. But if you do not do
this, it will work just fine.

VMWare Questions

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

VMWare Questions

Transféré par

Droits d'auteur :

Formats disponibles

Vous aimerez peut-être aussi