Log Descriptions and Locations

Overview

This topic covers the logs captured by the Support Bundle, and which you can use for troubleshooting. These include:

 

The following image shows examples of some of these files in the support bundle.

 

    

 

The following sections describe these files.


controller

This log lists all tasks executed by the controller (pancontroller), which is the central management system for vmPRO. The controller communicates with the GUI and Panshell (appliance shell), accepting user input, processing or passing this input to the intended service, and returning responses as output back to the user.  It receives timed requests for info from vm_proxy_fs and datastore_fs every 3 to 5 minutes by HTTP.

 

The controller also provides monitoring functions for the appliance, such as monitoring for the presence of core files, as well as monitoring disk space usage and license compliance.

 

Log location on system: /var/log/controller


datastore_fs

datastore_fs is the process that talks directly with the VMware vStorage and virtual infrastructure. The datastore_fs file collects hypervisor information, including the datastore name, type, and state. It also collects VM info and passes this info into the appliance through vm_proxy_fs and the controller.

 

Log location on system:  /var/log/datastore_fs


files_fs 

files_fs is the process responsible for making individual virtual machine files available for backup in /files. It exposes exported virtual machine files for file-level access.

 

Log location on system:  /var/log/files_fs

 

The image shows exposure of files in a virtual machine as opposed to images that can be backed up. The /export exposes VM images while /files exposes individual files in a VM.

 

The following screen shot is a capture of this file-level exposure.

 

 

 Larger Image 


import_fs

Import_fs is the process responsible for importing recovered virtual machine images back into the ESX datastore. After a VM image is brought into ESX datastore, the VM can be re-provisioned and booted. Import_fs eliminates the use of  the VMware converter, which involves many steps and is quite time-consuming.

 

Log location on system:  /var/log/import_fs

 


ls_bitmap_fs

ls_bitmap_fs is the service (daemon) responsible for determining the ‘in_useness’ bitmap of a flat VMDK file (the data or disk extent file). It looks at the device-mapper device of a flat file and determines the partition(s) or LVM volume(s), the file systems on the partition or LVM volume, and the bitmap of the file system(s). This bitmap information is used by vm_proxy_fs to determine the blocks of a flat VMDK file that are currently ‘in-use’. Vm_proxy_fs uses this ‘in-use’ information to skip ‘read’ operations for blocks that are not ‘in-use’ and returns 0’s for those not ‘in-use’ blocks. This reduces I/O access to the flat file of the VM on an ESX server and makes SmartRead possible.

 

Log location on system:  /var/log/ls_bitmap_fs

 


messages

The messages log contains errors from all other logs. Review this log first when troubleshooting.

 

Log location on system: /var/log/messages

 


 

recovery_fs

recovery_fs is responsible for enabling restore of virtual machine images from backup. After VM images are recovered and mounted from the appliance GUI, they can be accessed in /recover/images, which is available by CIFS or NFS mount.

 

Log  location on system:  /var/log/recovery_fs

 

The following screen shot of /recover/images shows virtual machine files backed up by the appliance and required for successful disaster recovery of the VM. All of the files are necessary and significant for successful disaster recovery of a VM. An additional file that would be required is the pancbt.vmdk file, which would be present if CBT is enabled for the VM prior to backup. The pancbt file captures block level changes for a VM following a full backup. For the VM shown “xp2” CBT was not enabled for it prior to the backup, hence there is not a pancbt.vmdk file.

 

 

  Larger Image 

 

 

Note that pancbt.vmdk files will never show up in /recover/images. When a flat.vmdk is read from /recover/images, recovery_fs is pulling the data from the flat OR pancbt file depending on which block is being read. So when you read from /recover/images, it is doing the pancbt + flat merge on the fly.


recovery_fs_files 

recovery_fs_files is the service that makes file-level restore possible. It takes backed-up virtual machine images, reads them, and renders the individual files for recovery. Once a VM's image is recovered and mounted through the appliance GUI for file-level access, the files can be accessed in /recover/files.

 

Log location on system:  /var/log/recovery_fs_files

 

In contrast to the screen shot shown for recovery_fs, which shows the VM image files, the screen shot for this section shows the content of image files. This screenshot shows the same recovered VM image files (seen under /recover/images as 5 files) exposed here (/recover/files) to filesystem level view by recovery_fs_files.

 

 

  Larger Image

 


smartmotion

The smartmotion log contains log entries for every file that is backed up using SmartMotion. Unlike the other logs, errors recorded in this log will not be seen in the messages log.

 

Log location on system:  /var/log/smartmotion

 

You can use the smartmotion log to determine when a SmartMotion backup was started. See the following log snippet for an example:

 

2012-06-19 14:36:27,874 smartmotion/WARNING:: ControllerCommands.py:2450 SmartMotion backup starting, cmd: a97047ea-79f3-403a-b47b-eac395ae17df

 

The following log example shows when a SmartMotion backup was aborted.

 

==========================================================================
2012-06-12 14:53:57,856 smartmotion/WARNING:: Tomato.py:661 Doing full copy for : /export/10.30.240.40/b4boot_5139
2012-06-12 14:53:57,859 smartmotion/WARNING:: Tomato.py:411 Running SmartMotion copy: ['/usr/local/pancetera/bin/cp_semi_sparse', '--preserve=timestamps', '--sparse=always', '/export/10.30.240.40/b4boot_5139/b4boot_5139.cfg', '/storage/.5fe77478-95f5-49cd-b9af-d86e1fedb49c/qa/garytestdata/asdf_zoplwef/2012-06/2012-06-12-1453/10.30.240.40/b4boot_5139']
2012-06-12 14:53:57,859 smartmotion/WARNING:: Tomato.py:426 Copying file: /export/10.30.240.40/b4boot_5139/b4boot_5139.cfg
2012-06-12 14:53:57,920 smartmotion/WARNING:: Tomato.py:411 Running SmartMotion copy: ['/usr/local/pancetera/bin/cp_semi_sparse', '--preserve=timestamps', '--sparse=always', '/export/10.30.240.40/b4boot_5139/b4boot_5139.vmx', '/storage/.5fe77478-95f5-49cd-b9af-d86e1fedb49c/qa/garytestdata/asdf_zoplwef/2012-06/2012-06-12-1453/10.30.240.40/b4boot_5139']
2012-06-12 14:53:57,921 smartmotion/WARNING:: Tomato.py:426 Copying file: /export/10.30.240.40/b4boot_5139/b4boot_5139.vmx
2012-06-12 14:53:57,966 smartmotion/WARNING:: Tomato.py:411 Running SmartMotion copy: ['/usr/local/pancetera/bin/cp_semi_sparse', '--preserve=timestamps', '--sparse=always', '/export/10.30.240.40/b4boot_5139/b4boot_5139.vmdk', '/storage/.5fe77478-95f5-49cd-b9af-d86e1fedb49c/qa/garytestdata/asdf_zoplwef/2012-06/2012-06-12-1453/10.30.240.40/b4boot_5139']
2012-06-12 14:53:57,967 smartmotion/WARNING:: Tomato.py:426 Copying file: /export/10.30.240.40/b4boot_5139/b4boot_5139.vmdk
2012-06-12 14:53:58,923 smartmotion/WARNING:: Tomato.py:411 Running SmartMotion copy: ['/usr/local/pancetera/bin/cp_semi_sparse', '--preserve=timestamps', '--sparse=always', '/export/10.30.240.40/b4boot_5139/b4boot_5139-flat.vmdk', '/storage/.5fe77478-95f5-49cd-b9af-d86e1fedb49c/qa/garytestdata/asdf_zoplwef/2012-06/2012-06-12-1453/10.30.240.40/b4boot_5139']
2012-06-12 14:53:58,924 smartmotion/WARNING:: Tomato.py:426 Copying file: /export/10.30.240.40/b4boot_5139/b4boot_5139-flat.vmdk
2012-06-12 14:55:49,769 smartmotion/WARNING:: ControllerCommands.py:2567 Preparing to abort running SmartMotion
2012-06-12 14:55:49,775 smartmotion/WARNING:: ControllerCommands.py:2590 Executing abort of SmartMotion command fb10a2c4-1f85-401c-b878-4f9c01c75894

 

 Note: As of the 3.0 release, you can ignore the smartmotion log WARNINGs. This may change in a future release, but as of now they are not really warnings.

 


vm_proxy_fs

vm_proxy_fs is the process that is responsible for exporting virtual machine images and making them available for backup. Vm_proxy_fs communicates with datastore_fs, and with the controller. It receives virtual machine disk information from datastore_fs and provides the state of virtual machines to the controller.

 

Log location on system:  /var/log/vm_proxy_fs

 

The following screenshot shows how Vm_proxy_fs exposes virtual machine image files for access in /export for backup.

 

 

 

 Larger Image

 

Datastore Cache Files

The Datastore Cache Files are included in the support bundle on a different part of the file tree from the Support Logs. You can use the contents of these files to determine information about the environment’s datastores. See the next topic for details.

 


Resources

Quantum vmPRO Status and Log Locations job aid

 

Collecting vmPRO Logs from the Command Line

 


What's Next?

Referencing Datastore Cache Files >

Attachments
Title Last Updated Updated By
vmPRO Status and Log Locations job aid
04/20/2015 05:41 PM James Bell


This page was generated by the BrainKeeper Enterprise Wiki, © 2018