VMware Tips from vmware-land 2 of 2

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 () 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:

• 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):
• 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:
• 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
  

Virtual Machine:

How can I migrate my Vmware Server VM’s to ESX?
There are several methods for doing this that are listed below:

Method 1 – Vmware Converter running directly on Vmware Server (Cold clone)
• Install Vmware Converter on to the Vmware Server and reboot if prompted
• Shutdown the VM to be converted
• Run Converter and select Import Machine
• Click Next at the Welcome screen and Next again at the Source screen
• Select “Standalone virtual machine, backup or disk image” as your source and click Next
• Browse to your VM’s vmx file and click Next
• Select either “Import all disks and maintain size” or “Select volumes and resize to save or add space”, select your volumes and enter a new disk size if necessary and click Next
• Click Next at the Destination screen
• Select “VMware ESX Server or VirtualCenter virtual machine” as your destination and click Next
• At the destination login screen enter your VC/ESX server name and login credentials and click Next
• Enter a Virtual Machine name and folder and click Next
• Select a Host/Cluster and click Next then select a Datastore and click Next
• Enter your NIC information and click Next then click Next again at the customization screen
• Click Finish when it completes
• Edit your new VM’s settings and remove any extra hardware if not needed, ie. USB devices, serial and parallel devices, Floppy drive and change the SCSI adapter to LSI Logic if needed
• Power on your new VM and uninstall VMware tools (VMware server version)
• Restart server
• Remove old virtual machine hardware
    o Open CMD prompt and type “SET DEVMGR_SHOW_NONPRESENT_DEVICES=1” and then “DEVMGMT.MSC”
    o Select “Show Hidden Devices” from top menu
    o Remove old greyed-out non-present hardware, ie. old processor, disk drives, IDE/SCSI controllers, storage volumes, etc.
• Reboot and install VMware tools (ESX version) and you are finished

Method 2- Vmware Converter running directly on Virtual Machine (Hot clone)
• Install Vmware Converter on to the Virtual Machine and reboot if prompted
• Run Converter and select Import Machine
• Click Next at the Welcome screen and Next again at the Source screen
• Select “Physical Computer” as your source and click Next
• Select “This local machine” and click Next
• Select either “Import all disks and maintain size” or “Select volumes and resize to save or add space”, select your volumes and enter a new disk size if necessary and click Next
• Click Next at the Destination screen
• Select “VMware ESX Server or VirtualCenter virtual machine” as your destination and click Next
• At the destination login screen enter your VC/ESX server name and login credentials and click Next • Enter a Virtual Machine name and folder and click Next
• Select a Host/Cluster and click Next then select a Datastore and click Next
• Enter your NIC information and click Next then click Next again at the customization screen
• Click Finish when it completes
• Edit your new VM’s settings and remove any extra hardware if not needed, ie. USB devices, serial and parallel devices, Floppy drive and change the SCSI adapter to LSI Logic if needed
• Power on your new VM and uninstall VMware tools (VMware server version)
• Restart server
• Remove old virtual machine hardware
    o Open CMD prompt and type “SET DEVMGR_SHOW_NONPRESENT_DEVICES=1” and then “DEVMGMT.MSC”
    o Select “Show Hidden Devices” from top menu
    o Remove old greyed-out non-present hardware, ie. old processor, disk drives, IDE/SCSI controllers, storage volumes, etc.
• Reboot and install VMware tools (ESX version) and you are finished

Method 3 – Use FastSCP and vmkfstools to copy the disk to ESX and convert it to VMFS3 format
• If your Server VM uses IDE disks you will have to convert them to SCSI disks prior to using this method since ESX does not support IDE hard drives. To convert your disks to IDE follow the steps in this VMware knowledge base article: Once you complete the conversion to SCSI you can proceed with the below steps.
• Download FastSCP () and install on the VMware Server, FastSCP requires the dot net framework 2.0 so download and install this first if you do not have it (), alternately you can use WinSCP () which is a bit slower then FastSCP
• Once FastSCP is installed run it, click “Add Server” enter your ESX server name/IP, the default port of 22, username and password and click Finish
• Connect to your ESX server, browse to your /vmfs/volumes/ and select New Folder and call it “temp” or whatever you want
• Shutdown the VM from Server that you will be copying the vmdk file from
• Using Windows Explorer, browse to your vmdk files and select both the descriptor vmdk file (small file) and the data vmdk file (-flat large file)
• Paste these into your temp directory on the ESX server and the transfer will begin
• Once the transfer completes login to your ESX service console and change to your temp directory, ie. cd /vmfs/volumes//temp
• To import the file to VMFS3 format type “vmkfstools –i ” the file name is the name of the small descriptor vmdk file, ie. “vmkfstools –i Win2003vm1.vmdk Win2003vm1-new.vmdk”. This create a new copy of your source vmdk file in VMFS3 format, it will automatically create both the descriptor and the data vmdk files
• Create a new VM on your ESX server, select Custom and then select the VM’s configuration. When you get to Select a Disk choose “Use an Existing Disk” and browse to you destination file name you selected above
• Power on your new VM and you should be all set, you can delete your original source file from the temp directory
• Optionally you can move your vmdk files from the temp directory to the VM’s directory that it created
    o Shutdown your VM
    o Login to the Service Console
    o Change to your VM’s directory, ie. cd /vmfs/volumes//myVM1
    o Copy file from the temp directory to the VM’s directory using vmkfstools, ie. vmkfstools –i /vmfs/volumes//temp/Win2003vm1-new.vmdk myVM1.vmdk This will make a copy of your vmdk file in your VM’s directory, you can also change the destination file name to match your VM’s name
    o In the VI Client, edit your VM’s settings, remove the current hard disk (don’t delete it yet) and add new new hard disk, select “Use an Existing Disk” and browse to the new vmdk file in your VM’s directory
    o Power on the VM and if it boots OK you can delete the original virtual disk, you can use FastSCP for this or right-click on your Datastore in the VI Client and select “Browse your Datastore” with the VI Client to delete the two original virtual disk files

How can I kill a stuck virtual machine?
ESX 3.0 method
• Login to the service console
• You can check the VM state by typing “vmware-cmd //server.vmx getstate”
• Type “ps -ef | grep ”
• The second column is your pid of the vmkload_app of the Virtual Machine, you can also type “ps –eaf” to see all running processes
• Type “kill -9 ”
• Check VM state again, it should now be off
• Type “vmware-cmd //server.vmx start” to power on VM

ESX 3.0 Alternate method
• Login to the service console
• Type “vmware-cmd –l” to get a list of all VM’s and there paths
• You can check the VM state by typing “vmware-cmd //server.vmx getstate”
• To forcibly stop type vmware-cmd //server.vmx stop hard”
• Check VM state again, it should now be off
• Type “vmware-cmd //server.vmx start” to power on VM

ESX 3.0 Alternate method
• Login to the service console
• Get the vmid of the VM you want to kill by typing “vm-support –x”
• Kill the VM and generate core dumps and logs by typing “vm-support –X ”
• You will be prompted if you want to include a screenshot of the VM, send an NMI to the VM and send a ABORT to the VM, you must answer Yes to the ABORT question to kill the VM. The entire process will take about 5-10 minutes to run. It will create a tar archive in the directory you run it in.

ESX 2.5 method
• Log into the MUI, and get the PID of the VM from there
• Login to the service console
• Type “kill -9 ” Note - In rare conditions, doing a kill -9 on a VM can take down the entire host

How do I upgrade a existing virtual disk from BusLogic to LSI Logic?
If you upgraded a server from Win2000 to Win2003 it will usually blue screen if you just change the SCSI controller. It will still try and load the BusLogic driver and will not be able to boot. Use this procedure to force it to load the LSI driver prior to changing the controller type to LSI Logic
• Power off the VM you want to change controllers on
• Connect to the Service Console and edit the vmx file for the VM
• Add the following lines to the vmx file o scsi1.present = "true" o scsi1.virtualDev = "lsilogic"
• Power on the VM and it will discover the new SCSI card
• Power off the VM and edit the SCSI Controller settings, change the type to LSI Logic
• Power VM back on, answer Yes for the adapter change message
• Once it boots successfully shut the VM down again (it will have to LSI controllers at this point)
• Edit the vmx file and remove the lines you added above
• Power on the VM again and you will be all set

How can I hide the Vmware tools icon in the system tray?
Edit the registry key “HKEY_CURRENT_USER\Software\VMware, Inc.\VMware Tools” and set ShowTray equal to 0

What are all the files that are located in my virtual machines directory on the ESX server for?
*.nvram file – This file contains the CMOS/BIOS for the VM. The BIOS is based off the PhoenixBIOS 4.0 Release 6 and is one of the most successful and widely used BIOS and is compliant with all the major standards, including USB, PCI, ACPI, 1394, WfM and PC2001. If the NVRAM file is deleted or missing it will automatically be re-created when the VM is powered on. Any changes made to the BIOS via the Setup program (F2 at boot) will be saved in this file. This file is usually less then 10K in size and is not in a text format (binary).

vmdk files – These are the disk files that are created for each virtual hard drive in your VM. There are 3 different types of files that use the vmdk extension, they are:
• *–flat.vmdk file - This is the actual raw disk file that is created for each virtual hard drive. Almost all of a .vmdk file's content is the virtual machine's data, with a small portion allotted to virtual machine overhead. This file will be roughly the same size as your virtual hard drive.
• *.vmdk file – This isn't the file containing the raw data anymore. Instead it is the disk descriptor file which describes the size and geometry of the virtual disk file. This file is in text format and contains the name of the –flat.vmdk file for which it is associated with and also the hard drive adapter type, drive sectors, heads and cylinders, etc. One of these files will exist for each virtual hard drive that is assigned to your virtual machine. You can tell which –flat.vmdk file it is associated with by opening the file and looking at the Extent Description field.
• *–delta.vmdk file - This is the differential file created when you take a snapshot of a VM (also known as REDO log). When you snapshot a VM it stops writing to the base vmdk and starts writing changes to the snapshot delta file. The snapshot delta will initially be small and then start growing as changes are made to the base vmdk file, The delta file is a bitmap of the changes to the base vmdk thus is can never grow larger than the base vmdk. A delta file will be created for each snapshot that you create for a VM. These files are automatically deleted when the snapshot is deleted or reverted in snapshot manager.

*.vmx file – This file is the primary configuration file for a virtual machine. When you create a new virtual machine and configure the hardware settings for it that information is stored in this file. This file is in text format and contains entries for the hard disk, network adapters, memory, CPU, ports, power options, etc. You can either edit these files directly if you know what to add or use the Vmware GUI (Edit Settings on the VM) which will automatically update the file.

*.vswp file – This is the VM swap file (earlier ESX versions had a per host swap file) and is created to allow for memory overcommitment on a ESX server. The file is created when a VM is powered on and deleted when it is powered off. By default when you create a VM the memory reservation is set to zero, meaning no memory is reserved for the VM and it can potentially be 100% overcommitted. As a result of this a vswp file is created equal to the amount of memory that the VM is assigned minus the memory reservation that is configured for the VM. So a VM that is configured with 2GB of memory will create a 2GB vswp file when it is powered on, if you set a memory reservation for 1GB, then it will only create a 1GB vswp file. If you specify a 2GB reservation then it creates a 0 byte file that it does not use. When you do specify a memory reservation then physical RAM from the host will be reserved for the VM and not usable by any other VM’s on that host. A VM will not use it vswp file as long as physical RAM is available on the host. Once all physical RAM is used on the host by all its VM’s and it becomes overcommitted then VM’s start to use their vswp files instead of physical memory. Since the vswp file is a disk file it will effect the performance of the VM when this happens. If you specify a reservation and the host does not have enough physical RAM when the VM is powered on then the VM will not start.

*.vmss file – This file is created when a VM is put into Suspend (pause) mode and is used to save the suspend state. It is basically a copy of the VM’s RAM and will be a few megabytes larger than the maximum RAM memory allocated to the VM. If you delete this file while the VM is in a suspend state It will start the VM from a normal boot up instead of starting the vm from the state it was when it was suspended. This file is not automatically deleted when the VM is brought out of Suspend mode. Like the Vswp file this file will only be deleted when the VM is powered off (not rebooted). If a Vmss file exists from a previous suspend and the VM is suspended again then the previous file is re-used for the subsequent suspensions. Also note that if a vswp file is present it is deleted when a VM is suspended and then re-created when the VM is powered on again. The reason for this is that the VM is essentially powered off in the suspend state, it’s RAM contents are just preserved in the vmss file so it can be quickly powered back on.

*.log file – This is the file that keeps a log of the virtual machine activity and is useful in troubleshooting virtual machine problems. Every time a VM is powered off and then back on a new log file is created. The current log file for the VM is always vmware.log. The older log files are incremented with a -# in the filename and up to 6 of them will be retained. (ie. vmware-4.log) The older .log files are always deleteable at will, the latest .log file can be deleted when the VM is powered off. As the log files do not take much disk space, most administrators let them be.

*.vmxf file – This is a supplemental configuration file in text format for virtual machines that are in a team. Note that the .vmxf file remains if a virtual machine is removed from the team. Teaming virtual machines is a Vmware Workstation feature and includes the ability to designate multiple virtual machines as a team, which administrators can then power on and off, suspend and resume as a single object — making it particularly useful for testing client-server environments. This file still exists with ESX server virtual machines but only for compatibility purposes with Workstation.

*.vmsd file – This file is used to store metadata and information about snapshots. This file is in text format and will contain information such as the snapshot display name, uid, disk file name, etc. It is initially a 0 byte file until you create your first snapshot of a VM and from that point it will populate the file and continue to update it whenever new snapshots are taken. This file does not cleanup completely after snapshots are taken. Once you delete a snapshot it will still leave the fields in the file for each snapshot and just increment the uid and set the name to “Consolidate Helper” presumably to be used with Consolidated Backups.

*.vmsn file - This is the snapshot state file, which stores the exact running state of a virtual machine at the time you take that snapshot. This file will either be small or large depending on if you select to preserve the VM’s memory as part of the snapshot. If you do choose to preserve the VM’s memory then this file will be a few megabytes larger then the maximum RAM memory allocated to the VM. This file is similar to the vmss (Suspend) file. A vmsn file will be created for each snapshot taken on the VM, these files are automatically deleted when the snapshot is removed.

How can I limit the number of vmware.log files that are created for my virtual machine?
You can do this by powering off the VM and then Edit the Settings on the VM.
• Select the Options tab and then Advanced and then click the Configuration Parameters button
• Click the Add Row button and enter log.keepOld for the Name and as many historical log files as you would like to keep for the value (in addition the the original vmware.log file), ie. 3
• Click the Add Row button again and enter log.rotateSize for the Name and a maximum size in bytes for the log files to grow to, ie. 500000 for 500kb
• Click OK and power the VM back on, it will now create vmware.log files up to the size you specified and also only keep as many as you specified.
• Alternately you can disable VM logging by de-selecting “Enable logging” on the Options tab, Advanced page.
• If you do this all logging except for Vmware tools logging will be disabled. If you also wish to disable that you can add a additional row in Configuration Parameters with a name isolation.tools.setinfo.disable with a value of true

How can I disable Copy & Paste operations between the guest operating system and remote console?
You can do this by powering off the VM and then Edit the Settings on the VM.
• Select the Options tab and then Advanced and then click the Configuration Parameters button.
• Click the Add Row button and add the following names with values of false: isolation.tools.copy.enable, isolation.tools.paste.enable and isolation.tools.setGUIOptions.enable
• Click OK and power the VM back on, copy & paste operations will no longer work in the remote console.

What happens to virtual machines in case of a active path failure to my SAN?
When a cable is pulled, I/O freezes for approximately 30-60 seconds, until the SAN driver determines that the link is down, and failover occurs. During that time, the virtual machines (with their virtual disks installed on a SAN) may appear unresponsive, and any operations on the /vmfs directory may appear to hang. After the failover occurs, I/O should resume normally. Even though ESX Server's failover feature ensures high availability and prevents connection loss to SAN devices, all connections to SAN devices may be lost due to disastrous events, that include multiple breakages. If all connections to the storage device are not working, then the virtual machines will begin to encounter I/O errors on their virtual SCSI disks. Also, operations in the /vmfs directory may eventually fail after reporting an "I/O error".

For QLogic cards, you may want to adjust the PortDownRetryCount value in the QLogic BIOS. This value determines how quickly a failover occurs when a link goes down. If the PortDownRetryCount value is , then a failover typically takes a little longer than multiplied by 2 seconds. A typical recommended value for is 15, so in this case, failover takes a little longer than 30 seconds. For more information on changing the PortDownRetryCount value, refer to your QLogic documentation.

For the Windows 2000 and Windows Server 2003 guest operating systems, you may want to increase the standard disk TimeOutValue so that Windows will not be extensively disrupted during failover. For a VMware environment, the Disk TimeOutValue must be set to 60 seconds. o Select Start > Run, type regedit.exe, and click OK. o In the left panel hierarchy view, double-click HKEY_LOCAL_MACHINE, System, CurrentControlSet, Services, then Disk. o Select the TimeOutValue if it exists and set the Data value to x03c (hexadecimal) or 60 (decimal). By making this change, Windows waits at least 60 seconds, for delayed disk operations to complete, before generating errors. o If the TimeOutValue does not exist, select New from the Edit Menu and then DWORD value. In the Name field type TimeOutValue and then set the Data value to x03c (hexadecimal) or 60 (decimal). o Click OK and exit the Registry Editor program.

What is the vswp file that is in my VM’s directory on the VMFS volume?
The vswp file is created to allow for memory overcommitment on a ESX server. By default when you create a VM the memory reservation is set to zero, meaning no memory is reserved for the VM and it can potentially be 100% overcommitted. As a result of this a vswp file is created equal to the amount of memory that the VM is assigned minus the memory reservation that is configured for the VM. So a VM that is configured with 2GB of memory will create a 2GB vswp file when it is powered on, if you set a memory reservation for 1GB, then it will only create a 1GB vswp file. If you specify a 2GB reservation then it creates a 0 byte file that it does not use. When you do specify a memory reservation then physical RAM from the host will be reserved for the VM and not usable by any other VM’s on that host.

A VM will not use it vswp file as long as physical RAM is available on the host. Once all physical RAM is used on the host by all it’s VM’s and it becomes overcommitted then VM’s start to use their vswp files instead of physical memory. Since the vswp file is a disk file it will effect the performance of the VM when this happens. If you specify a reservation and the host does not have enough physical RAM when the VM is powered on then the VM will not start. If you change a memory reservation for a VM it will not take effect until the VM is powered off and then back on. Simply restarting a VM is not enough. The vswp file is only create and deleted at power on/off, once you power off a VM it’s vswp file is deleted until it is powered back on at which time it is re-created.

By default the vswp file is kept in the same directory as the VM’s virtual disk. It’s a good idea to either create partial memory reservation for your VM’s or specify an alternate location for this file so it does not use up valuable VMFS SAN space. By creating a partial memory reservation you can decrease the size of this file and still allow for memory overcommitment, you also allow for ESX to use it’s advanced memory techniques such as page sharing. Alternately you can specify an alternate location for the vswp file so it is not stored in the same directory as your vmdk file. You can do this be editing the vmx file for the machine and adding a parameter “sched.swap.dir = ”. Alternately you can do this through VirutalCenter by powering off the VM and editing the settings for the VM. Then click on “Options” then “Advanced” then “Configuration Parameters”. Click on “Add Row” to add the parameter and it’s value. The value is the path to the directory you want to store the vswp file, ie. “/vmfs/volumes/ServerA-Local/Swap/” Note it is OK to use the symbolic link name of a VMFS volume instead of the UUID. 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. Thus any changes you make to that file before you power-on the VM will be overwritten by the VM when it powers on. Make sure the directory you set it to is on a shared VMFS volume if you want to still be able to VMotion the VM or have it work under DRS and HA.

How can I disable my VM’s from page sharing?
Page sharing, which is the process ESX uses to conserve memory by eliminating duplicate memory pages, can be disabled by changing a VM’s memory reservation to be the same as the amount of memory allocated to the VM. With a 100% memory reservation the VM will be excluding from any page sharing. Page sharing can be beneficial to the VM’s performance and thought should be given to this before disabling this feature.

Why does VirtualCenter show my VM’s Host Memory Usage higher then the amount of memory that is assigned to the VM?
Host Memory Usage is the amount of memory used by the host that is the VM's memory plus the host memory (overhead) or the amount of memory used to manage the environment. That is why the Host Memory Usage can be higher then what the VM is configured for.

Why does my VM show a high Guest Mem % when it first boots even though it is not using that much RAM?
This is common when a virtual machine first boots. Windows zeroes the contents of all pages in physical memory while booting. This causes the system to become overcommitted almost immediately, as each VM accesses all of its memory. Since the Windows balloon drivers are not started until late in the boot sequence, ESX Server is forced to start paging to disk. Soon after booting the amount of shared memory drops rapidly, and ESX Server compensates by using ballooning to reclaim memory. Page sharing continues to exploit sharing opportunities over time saving additional memory. See this white paper for more on this.  

How can I clear an active vmware.log file that is large without restarting the VM?
Normally a new vmware.log file is created everytime a VM is started. Old log files have -# (ie. vmware-9.log) appended to them and by default VMware will save 6 old log files. You can change this behavior as documented in another tip. If you need to clear a large vmware.log file without restarting the server you can use the below technique. “Cat /dev/null >file” deletes the contents of a file, but preserves the file itself, with all attendant permissions.
• Login to the ESX Service Console
• Switch to the VM’s sub-directory, ie. cd /vmfs/volumes/MyVolume/MyVM
• Type “cat /dev/null > vmware.log” this will make the file 0 bytes without effecting the VM.

How can I hot clone a VM without using VMware Converter?
You cannot hot clone a VM with VirtualCenter, a VM must be shutdown to be able to clone it. One option to hot clone a running VM is to install VMware Converter on it. A reboot will not be required if it is running Windows 2003 or Windows XP. Windows 2000 and earlier require reboots because a special driver is installed on the system. Another option to hot clone is using snapshots and vmkfstools, creating a snapshot will prevent any writes to the VM’s original vmdk file as all subsequent writes are written to the –delta.vmdk files that the snapshot creates. You can also use this procedure to cold clone a VM if you do not have VirtualCenter. To cold clone power off your source VM first and there is not need to create a snapshot, you can omit steps 3 and 9 below.
1) Login to the Service Console
2) Switch to your VM’s directory, ie. cd /vmfs/volumes/MyVolume/MyVM1
3) To create a snapshot type through the command line you can use vmware-cmd, the syntax is: “vmware-cmd createsnapshot ” ie. vmware-cmd MyVM1.vmx createsnapshot “MyVM1 Snapshot” “Clone snapshot” 1 0. Setting memory to 0 prevents the snapshotting of the VM’s memory which we do not want for the clone. It will return “createsnapshot(MyVM1 Clone snapshot 1 0) = 1” when it successfully creates the snapshot. Optionally you can create the snapshot using the Snapshot Manager in the VI Client.
4) Next create a new VM (for this example we will call it MyVM2) on the ESX host using the VI Client. It’s best to assign the NIC for this VM to an Internal Only vswitch (no physical NIC’s assigned to the vswitch) so it does not conflict with the existing VM. When it comes to the hard drive you can accept the 4GB default or make it smaller since you will be deleting it anyway. Do not power this new VM on.
5) Switch to your new VM’s directory and delete the vmdk files it created. Ie. “cd /vmfs/volumes/MyVolume/MyVM2” and then “rm *.vmdk”, you will be prompted for deletion confirmation of the two vmdk files for the VM.
6) Switch back to your original VM’s directory, ie. “cd /vmfs/volumes/MyVolume/MyVM1”
7) Use vmkfstools to copy your original disk to the new VM’s directory, the format is “vmkfstools –i ” ie. “vmkfstools –i MyVM1.vmdk /vmfs/volumes/MyVM2/MyVM2.vmdk”
8) Once the copy completes power on your new VM, you might run chkdsk on it once it boots since you effectively powered off the VM while running and powered it back on.
9) You can now delete the original snapshot by typing “vmware-cmd removesnapshots” which will remove all snapshots for the VM. Optionally you can remove the snapshot using Snapshot Manager in the VI Client.

How can I disable serial and parallel ports so my VM does not see them?
It is generally a best practice to disable these ports unless your VM needs them, in most cases they do not.
• To do this reboot your VM and hit F2 quickly at the Vmware BIOS screen, there is a small window to do this and it might take you several tries. It is usually easier if you open a console window to the VM while it is powered on and reboot it, then clicking inside the console window quickly when the BIOS screen comes up then hitting F2.
• On the Advanced tab arrow down and select ‘I/O Device Configuration’ and hit Enter
• Using the plus or minus keys change Serial port A, Serial port B, Parallel port and also floppy disk controller if you’d like to Disabled.
• Next hit F10 to Save and Exit and select Yes at the confirmation window

Optionally if your VM already had Windows installed when you complete this the ports will no longer be visible in Device Manager. You can cleanup the old ports by going to a CMD prompt and typing “set devmgr_show_nonpresent_devices=1” then in the same window “devmgmt.msc”. Once Device Manager loads select “Show Hidden Devices” and you will see the old greyed out ports which you can uninstall.