ghettoVCBg2 - Free alternative for backing up VMs in ESX(i) 3.5 and 4.x (no SSH console required!)

1 Kudo

Description:

This tool is the follow up release of the ghettoVCB

backup utility which allows users to perform backups of virtual machines residing on ESX(i) 3.5+/4.x+

servers using methodology similar to VMware's VCB

tool. By incorporating highly constructive feedback from the VMware community and utilizing the existing VI API, ghettoVCB’s framework was completely rewritten to be harder, better, faster, stronger

.

The primary motivation for ghettoVCBg2 was to provide ESXi users with access to the utility without relying on unlocking and utilizing the unsupported console. To satisfy this requirement, the rebuilt framework takes advantage of the

VI Perl Toolkit/vSphere SDK for Perl which is present in the

VIMA/vMA virtual appliance provided by VMware. As a result, ghettoVCBg2 provides a more proper backup solution that administrators can utilize in their virtual infrastructure.

As it stands, it is a requirement that ghettoVCB be invoked directly on each of the ESX servers hosting virtual machines in need of a backup. By taking advantage of VIMA/vMA, the entire backup process becomes centralized in turn eliminating the abovementioned requirement. Additionally, by leveraging the vi-fastpass library, unattended authentication between VIMA/vMA and target ESX servers is made possible. This alleviates the need to continually pass in credentials for each ESX server.

By centralizing the backup process, individual virtual machine backup lists pertaining to their respective ESX(i) servers are no longer required. ghettoVCBg2 has the ability to identify virtual machines and their respective hosts, potentially eliminating any past confusion associated with maintaining multiple lists.

In its current configuration, the script will allow up to 3 unique backups of the Virtual Machine before it will overwrite the previous backups; this however, can be modified to fit procedures if need be. Please be diligent in running the script in a test or staging environment before using it on production live Virtual Machines; this script functions well within our environment but there is a chance that it may not fit well into other environments.

Features

Support for logging (normal & verbose)
Single VM backup list across multiple ESX/ESXi host(s)
Credential-less backups (so long as host(s) are being managed by VIMA/vMA)
Online back up of VM(s)
Only valid VMDKs presented to the VM will be backed up
Support for multiple VMDK backup per VM
Preserve original powerState of VM(s)
Ability to shutdown guestOS, initiate backup process and power on VM afterwards with the option of hardpower timeout
Ensure that snapshot removal process completes prior to continuing the backup process
VM(s) that initially contain snapshots and Physical RDMs (raw device mapppings) will not be backed up
Support for VM(s) with Virtual RDMs
Ability to specify the number of backup rotations per VM
Output back up VMDKs in ZEROEDTHICK (default behavior), EAGERZEROEDTHICK, 2GB SPARSE or THIN format
Ouput backup VMDKs using either BUSLOGIC or LSILOGIC adapter type
Fully support VMDKs stored across multiple datastores
VM snapshot memory and quiesce options
Individual VM backup policy (supported on ESX(i) 3.5u2+ & ESX(i) 4.x+)
Email logs (Experimental Support) NEW!
Ability to include/exclude specific VMDK(s) per VM (requires individual VM backup policy setup) NEW!
Independent disk aware (will ignore VMDK) NEW!
Additional debugging information including dry run execution NEW!

Requirements:

VMs running on ESX(i) 3.5u2+ or ESX(i) 4.x+

VMware VIMA 1.0 or VMware vMA 4.x

ESX/ESXi Version Support Table

Version	Support	Alternative
ESX 3.5u2	Requires at least Foundation/Essentials license	ghettoVCB\
ESX 3.5u3	Requires at least Foundation/Essentials license	ghettoVCB\
ESX 3.5u4	Requires at least Foundation/Essentials license	ghettoVCB\
ESXi 3.5u2	Works for free	ghettoVCB\
ESXi 3.5u3	Works for free	ghettoVCB\
ESXi 3.5u4	Requires at least Foundation/Essentials license	ghettoVCB\
ESX 4.0	Requires at least Foundation/Essentials license	ghettoVCB\
ESXi 4.0	Requires at least Foundation/Essentials license	ghettoVCB\
ESX 4.1	Requires at least Foundation/Essentials license	ghettoVCB\
ESXi 4.1	Requires at least Foundation/Essentials license	ghettoVCB\

Setup:

1) Download ghettoVCBg2.tar.gz

to your VIMA 1.0/vMA 4.x system

2) Extract the contents of the tarball

[vi-admin@scofield ~]$ tar -zxvf ghettoVCBg2.tar.gz
ghettoVCBg2/
ghettoVCBg2/ghettoVCBg2-vm_backup_configuration_template
ghettoVCBg2/ghettoVCBg2.pl

3) The script should be in a directory called

ghettoVCBg2

Addings ESX/ESXi host(s) to VIMA/vMA

Prior to starting, ensure that the VMware VIMA/vMA host is managing the appropriate ESX(i) 3.5u2/4.x+ host(s)

1. Add ESXi hosts to VIMA/vMA managment using vifp

A password prompt for the vi-admin account and root password to the pertinent ESXi host(s) will be presented.

[vi-admin@vima-primp-industries ~]$ sudo vifp addserver olga.resnet.ucsb.edu
root@olga.resnet.ucsb.edu's password:
[vi-admin@vima-primp-industries ~]$

2. Verify that the appropriate hosts are being managed by VIMA/vMA

[vi-admin@vima-primp-industries ~]$ sudo vifp listservers
olga.resnet.ucsb.edu
himalaya.primp-industries.com

Configurations

The following variables (similar to that of ghettoVCB) need to be defined within the script prior to execution.

Defining the datastore in which the backups are stored:

my $VM_BACKUP_DATASTORE = "dlgCore-NFS-bigboi.VM-Backups";

Defining the name of folder that will contain backups (if folder does not exist, it will automatically be created):

my $VM_BACKUP_DIRECTORY = "WILLIAM_BACKUPS";

Defining the backup rotation per VM:

my $VM_BACKUP_ROTATION_COUNT = "3";

Defining the backup disk format (zeroedthick, eagerzeroedthick, thin, and 2gbsparse are available):

my $DISK_BACKUP_FORMAT = "zeroedthick";

Defining the adapter type for backed up VMDK (buslogic, and lsilogic are available):

my $ADAPTER_FORMAT = "buslogic";

Defining whether the VM is powered down or not prior to backup (1 = enable, 0 = disable):

Note: VM(s) that are powered off will not require snapshoting

my $POWER_VM_DOWN_BEFORE_BACKUP = "0";

Defining whether virtual machine memory is snapped and if quiescing is enabled (1 = enable, 0 = disable):

Note: By default both are disabled

my $VM_SNAPSHOT_MEMORY = "0";
my $VM_SNAPSHOT_QUIESCE = "0";

Defining the detail of logging (verbose or normal):

my $LOG_LEVEL = "normal";

*Defining VMDK(s) to backup from a particular VM either a list of vmdks or "all"

VM_VMDK_FILES="myvmdk.vmdk"

Experimental Support Configs:

Note: Port 25 by default

my $SEND_MAIL = "no";
my $EMAIL_HOST = "emailserver";
my $EMAIL_DOMAIN = "localhost.localdomain";
my $EMAIL_TO = 'William Lam <william@primp-industries.com.com>';
my $EMAIL_FROM = 'ghettoVCBg2 <ghettoVCBg2@primp-industries.com.com>';

Ensure that you do not edit past this section:

########################## DO NOT MODIFY PAST THIS LINE ##########################

Usage:

[vi-admin@scofield ~]$ ./ghettoVCBg2.pl
Required command option 'vmlist' not specified.

Synopsis: ./ghettoVCBg2.pl OPTIONS


Command-specific options:
   --config_dir
      Name of directory containing VM(s) backup configurations
   --dryrun (default '0')
      Set to 1 to enable dryrun mode (default 0)
   --output (default '/tmp/ghettoVCBg2.log')
      Full path to output log (default /tmp/ghettoVCBg2.log)
   --vmlist (required)
      A file containing a list of virtual machine(s) to be backed up on host

Common VI options:
   --config (variable VI_CONFIG)
      Location of the VI Perl configuration file
   --credstore (variable VI_CREDSTORE)
      Name of the credential store file defaults to <HOME>/.vmware/credstore/vicredentials.xml on Linux and <APPDATA>/VMware/credstore/vicredentials.xml on Windows
   --encoding (variable VI_ENCODING, default 'utf8')
      Encoding: utf8, cp936 (Simplified Chinese), iso-8859-1 (German), shiftjis (Japanese)
   --help
      Display usage information for the script
   --passthroughauth (variable VI_PASSTHROUGHAUTH)
      Attempt to use pass-through authentication
   --passthroughauthpackage (variable VI_PASSTHROUGHAUTHPACKAGE, default 'Negotiate')
      Pass-through authentication negotiation package
   --password (variable VI_PASSWORD)
      Password
   --portnumber (variable VI_PORTNUMBER)
      Port used to connect to server
   --protocol (variable VI_PROTOCOL, default 'https')
      Protocol used to connect to server
   --savesessionfile (variable VI_SAVESESSIONFILE)
      File to save session ID/cookie to utilize
   --server (variable VI_SERVER, default 'localhost')
      VI server to connect to. Required if url is not present
   --servicepath (variable VI_SERVICEPATH, default '/sdk/webService')
      Service path used to connect to server
   --sessionfile (variable VI_SESSIONFILE)
      File containing session ID/cookie to utilize
   --url (variable VI_URL)
      VI SDK URL to connect to. Required if server is not present
   --username (variable VI_USERNAME)
      Username
   --verbose (variable VI_VERBOSE)
      Display additional debugging information
   --version
      Display version information for the script

Note: There are some additional command line arguments that can be provided upon runtime: --debug, --output and --vmlist. --vmlist is the only parameter required. The rest will have defaults if not explicitly defined.

--dryrun

Dry run information will be written to the log and no backup will take place

--output

Name of the output log, if the same log is used, it will automatically append (ensure you provide full path e.g. /tmp/ghettoVCBg2.log)

--config_dir

This directory will contain the individual VM backup policy files. If a virtual machine has an associated policy file, the global configuration will be ignored for that backup instance.

The input to this script is a file that contains the display name of the virtual machine(s) separated by a newline. When creating this file on a non-Linux/UNIX system, you may introduce a ^M character which may cause the script to misbehave. To ensure that this does not occur, please create the file on the ESX/ESXi host.

Provided is a sample of what the file should contain:

[vi-admin@scofield ~]$ cat virtual_machine_backup_list
VIMA
vMA-2

Sample Execution

Backup VMs located in a list
Backup VMs based on individual VM backup policies
Debug Mode
Dry run Mode

Backup VMs located in a list

Log verbosity: info (default)
Log output: /tmp/ghettoVCBg2.log (default)

DISK_FORMAT	2gbsparse
ADAPTER_FORMAT	buslogic
LOG_LEVEL	info
VM_SNAPSHOT_MEMORY	0
VM_SNAPSHOT_QUIESCE	0
VMS_TO_BACKUP	(VIMA,vMA-2)

[vi-admin@scofield ~]$ ./ghettoVCBg2.pl --vmlist virtual_machine_backup_list

[vi-admin@scofield ~]$ cat /tmp/ghettoVCBg2.log
        11-13-2009 23:34:53 --  info: ============================== ghettoVCBg2 LOG START ==============================
        11-13-2009 23:34:53 --  info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
        11-13-2009 23:34:53 --  info: CONFIG - VM_BACKUP_DATASTORE = dlgCore-NFS-bigboi.VM-Backups
        11-13-2009 23:34:53 --  info: CONFIG - VM_BACKUP_DIRECTORY = WILLIAM_BACKUPS
        11-13-2009 23:34:53 --  info: CONFIG - DISK_BACKUP_FORMAT = 2gbsparse
        11-13-2009 23:34:53 --  info: CONFIG - ADAPTER_FORMAT = buslogic
        11-13-2009 23:34:53 --  info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
        11-13-2009 23:34:53 --  info: CONFIG - VM_SNAPSHOT_MEMORY = NO
        11-13-2009 23:34:53 --  info: CONFIG - VM_SNAPSHOT_QUIESCE = NO
        11-13-2009 23:34:53 --  info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-11-13
        11-13-2009 23:34:53 --  info: CONFIG - VM_VMDK_FILES = all

        11-13-2009 23:34:58 --  info: Initiate backup for VIMA found on himalaya.primp-industries.com
        11-13-2009 23:35:18 --  info: VIMA has 1 VMDK(s)
        11-13-2009 23:37:37 --  info: Backup completed for VIMA!

        11-13-2009 23:37:37 --  info: Initiate backup for vMA-2 found on himalaya.primp-industries.com
        11-13-2009 23:37:47 --  info: vMA-2 has 1 VMDK(s)
        11-13-2009 23:40:07 --  info: Backup completed for vMA-2!

        11-13-2009 23:40:10 --  info: ============================== ghettoVCBg2 LOG END ==============================

Backup VMs based on individual VM backup policies and log output to /tmp/ghettoVCB.log

Log verbosity: info (default)
Log output: /tmp/ghettoVCB.log (default)

VIMA

VM_BACKUP_DATASTORE	dlgCore-NFS-bigboi.VM-Backups
VM_BACKUP_DIRECTORY	WILLIAM_BACKUPS
DISK_FORMAT	zeroedthick
ADAPTER_FORMAT	buslogic
LOG_LEVEL	debug
VM_SNAPSHOT_MEMORY	1
VM_SNAPSHOT_QUIESCE	1
VM_VMDK_FILES	VIMA_1.vmdk

vMA-2

VM_BACKUP_DATASTORE	dlgCore-NFS-bigboi.VM-Backups
VM_BACKUP_DIRECTORY	vGHETTO_BACKUPS
DISK_FORMAT	thin
ADAPTER_FORMAT	lsilogic
LOG_LEVEL	info
VM_SNAPSHOT_MEMORY	0
VM_SNAPSHOT_QUIESCE	0
VM_VMDK_FILES	all

1. Create folder to hold individual VM backup policies (can be named anything):

[vi-admin@scofield ~]$ mkdir backup_config

2. Create individual VM backup policies for each VM and ensure each file is named exactly as the display name of the VM being backed up (use provided template to create duplicates):

[vi-admin@scofield backup_config]$ cp ghettoVCBg2-vm_backup_configuration_template VIMA
[vi-admin@scofield backup_config]$ cp ghettoVCBg2-vm_backup_configuration_template vMA-2

4. Using a preferred editor (nano or vi), edit each VM backup policy file

Listing of VM backup policy within backup configuration directory

[vi-admin@scofield backup_config]$ ls
ghettoVCBg2-vm_backup_configuration_template  VIMA  vMA-2

5. Pass in the value, backup_config, into the --config_dir parameter

(e.g.)
--config_dir backupConfigs

Example of two distinct VM backup policies will be applied to VIMA and vMA-2

Backup policy for "VIMA" (backup only 1 specific VMDKs)

[vi-admin@scofield backup_config]$ cat VIMA
VM_BACKUP_DATASTORE = "dlgCore-NFS-bigboi.VM-Backups"
VM_BACKUP_DIRECTORY = "WILLIAM_BACKUPS"
VM_BACKUP_ROTATION_COUNT = "3"
DISK_BACKUP_FORMAT = "zeroedthick"
ADAPTER_FORMAT = "buslogic"
POWER_VM_DOWN_BEFORE_BACKUP = "0"
VM_SNAPSHOT_MEMORY = "1"
VM_SNAPSHOT_QUIESCE = "1"
LOG_LEVEL = "debug"
VM_VMDK_FILES = "VIMA_1.vmdk"

Backup policy for VM "vMA-2" (backup all VMDKs found)

VM_BACKUP_DATASTORE = "dlgCore-NFS-bigboi.VM-Backups"
VM_BACKUP_DIRECTORY = "vGHETTO_BACKUPS"
VM_BACKUP_ROTATION_COUNT = "3"
DISK_BACKUP_FORMAT = "thin"
ADAPTER_FORMAT = "lsilogic"
POWER_VM_DOWN_BEFORE_BACKUP = "0"
VM_SNAPSHOT_MEMORY = "0"
VM_SNAPSHOT_QUIESCE = "0"
LOG_LEVEL = "info"
VM_VMDK_FILES = "all"

The following is an output of the script when utilizing the new --config_dir parameter with debug mode enabled.

Note: --vmlist is still a required parameter with the exception that backup policy files must exist for each VM in the list else the VM will be ignored in the backup process.

Execution of backup

[vi-admin@scofield ~]$ ./ghettoVCBg2.pl --config_dir backup_config --vmlist virtual_machine_backup_list

[vi-admin@scofield ~]$ cat /tmp/ghettoVCBg2.log
        11-14-2009 00:18:41 --  info: ============================== ghettoVCBg2 LOG START ==============================
        11-14-2009 00:18:45 --  info: CONFIG - USING CONFIGURATION FILE = VIMA
        11-14-2009 00:18:45 --  info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
        11-14-2009 00:18:45 --  info: CONFIG - VM_BACKUP_DATASTORE = dlgCore-NFS-bigboi.VM-Backups
        11-14-2009 00:18:45 --  info: CONFIG - VM_BACKUP_DIRECTORY = WILLIAM_BACKUPS
        11-14-2009 00:18:45 --  info: CONFIG - DISK_BACKUP_FORMAT = zeroedthick
        11-14-2009 00:18:45 --  info: CONFIG - ADAPTER_FORMAT = buslogic
        11-14-2009 00:18:45 --  info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
        11-14-2009 00:18:45 --  info: CONFIG - VM_SNAPSHOT_MEMORY = YES
        11-14-2009 00:18:45 --  info: CONFIG - VM_SNAPSHOT_QUIESCE = YES
        11-14-2009 00:18:45 --  info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-11-14
        11-14-2009 00:18:45 --  info: CONFIG - VM_VMDK_FILES = VIMA_1.vmdk

        11-14-2009 00:18:45 --  info: Initiate backup for VIMA found on himalaya.primp-industries.com
        11-14-2009 00:18:55 --  debug: VIMA original powerState: poweredOn
        11-14-2009 00:18:55 --  debug: Creating Snapshot "ghettoVCBg2-snapshot-2009-11-14" for VIMA
        11-14-2009 00:19:45 --  info: VIMA has 2 VMDK(s)
        11-14-2009 00:19:45 --  debug: findVMDKFile: Found VMDK File: VIMA_1.vmdk
        11-14-2009 00:19:45 --  debug: backupVMDK: Backing up "[http://himalaya-local-SAS.Savvio|http://himalaya-local-SAS.Savvio] VIMA/VIMA_1.vmdk" to "[http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/VIMA/VIMA-2009-11-14/VIMA_1.vmdk"
        11-14-2009 00:19:45 --  debug: backupVMDK: Signal copyThread to start
        11-14-2009 00:19:45 --  debug: backupVMDK: Backup progress: Elapsed time 0 min
        11-14-2009 00:19:45 --  debug: copyTask: Wake up and follow the white rabbit, with status: doCopy
        11-14-2009 00:19:45 --  debug: CopyThread: Start backing up VMDK(s) ...
        11-14-2009 00:19:52 --  debug: copyTask: send copySuccess message ...
        11-14-2009 00:19:52 --  debug: copyTask: waiting for next job and sleep ...
        11-14-2009 00:20:46 --  debug: backupVMDK: Successfully completed backup for [http://himalaya-local-SAS.Savvio|http://himalaya-local-SAS.Savvio] VIMA/VIMA_1.vmdk Elapsed time: 1 min
        11-14-2009 00:20:49 --  debug: Removing Snapshot "ghettoVCBg2-snapshot-2009-11-14" for VIMA
        11-14-2009 00:20:51 --  debug: checkVMBackupRotation: Starting ...
        11-14-2009 00:20:57 --  debug: Purging [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/VIMA/VIMA-2009-11-13--3 due to rotation max
        11-14-2009 00:21:05 --  info: Backup completed for VIMA!

        11-14-2009 00:21:05 --  debug: reConfigureBackupParams: VM - vMA-2
        11-14-2009 00:21:05 --  info: CONFIG - USING CONFIGURATION FILE = vMA-2
        11-14-2009 00:21:05 --  info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
        11-14-2009 00:21:05 --  info: CONFIG - VM_BACKUP_DATASTORE = dlgCore-NFS-bigboi.VM-Backups
        11-14-2009 00:21:05 --  info: CONFIG - VM_BACKUP_DIRECTORY = vGHETTO_BACKUPS
        11-14-2009 00:21:05 --  info: CONFIG - DISK_BACKUP_FORMAT = thin
        11-14-2009 00:21:05 --  info: CONFIG - ADAPTER_FORMAT = lsilogic
        11-14-2009 00:21:05 --  info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
        11-14-2009 00:21:05 --  info: CONFIG - VM_SNAPSHOT_MEMORY = NO
        11-14-2009 00:21:05 --  info: CONFIG - VM_SNAPSHOT_QUIESCE = NO
        11-14-2009 00:21:05 --  info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-11-14
        11-14-2009 00:21:05 --  info: CONFIG - VM_VMDK_FILES = all

        11-14-2009 00:21:05 --  info: Initiate backup for vMA-2 found on himalaya.primp-industries.com
        11-14-2009 00:21:15 --  info: vMA-2 has 1 VMDK(s)
        11-14-2009 00:23:22 --  info: Backup completed for vMA-2!

        11-14-2009 00:23:25 --  info: ============================== ghettoVCBg2 LOG END ==============================

Dry run Mode (no backup will take place)

Log verbosity: drymode
Log output: /tmp/ghettoVCB.log (default)

[vi-admin@scofield ~]$ ./ghettoVCBg2.pl --config_dir backup_config --vmlist virtual_machine_backup_list --dryrun 1

[vi-admin@scofield ~]$ cat /tmp/ghettoVCBg2.log
        11-14-2009 00:26:29 --  info: ============================== ghettoVCBg2 LOG START ==============================
        11-14-2009 00:26:34 --  info: CONFIG - USING CONFIGURATION FILE = VIMA
        11-14-2009 00:26:34 --  info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
        11-14-2009 00:26:34 --  info: CONFIG - VM_BACKUP_DATASTORE = dlgCore-NFS-bigboi.VM-Backups
        11-14-2009 00:26:34 --  info: CONFIG - VM_BACKUP_DIRECTORY = WILLIAM_BACKUPS
        11-14-2009 00:26:34 --  info: CONFIG - DISK_BACKUP_FORMAT = zeroedthick
        11-14-2009 00:26:34 --  info: CONFIG - ADAPTER_FORMAT = buslogic
        11-14-2009 00:26:34 --  info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
        11-14-2009 00:26:34 --  info: CONFIG - VM_SNAPSHOT_MEMORY = YES
        11-14-2009 00:26:34 --  info: CONFIG - VM_SNAPSHOT_QUIESCE = YES
        11-14-2009 00:26:34 --  info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-11-14
        11-14-2009 00:26:34 --  info: CONFIG - VM_VMDK_FILES = VIMA_1.vmdk

        11-14-2009 00:26:34 --  info: ---------- DRYRUN DEBUG INFO VIMA ----------
        11-14-2009 00:26:34 --  info: DEBUG - Host Build: VMware ESX 4.0.0 build-164009
        11-14-2009 00:26:34 --  info: DEBUG - Host: himalaya.primp-industries.com
        11-14-2009 00:26:34 --  info: DEBUG - Virtual Machine: VIMA
        11-14-2009 00:26:34 --  info: DEBUG - VM ConfigPath: [http://himalaya-local-SAS.Savvio|http://himalaya-local-SAS.Savvio] VIMA/VIMA.vmx
        11-14-2009 00:26:34 --  info: DEBUG - VMX File: VIMA.vmx
        11-14-2009 00:26:34 --  info: DEBUG - BackupConfigPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/VIMA/VIMA-2009-11-14/VIMA.vmx
        11-14-2009 00:26:34 --  info: DEBUG - BackupPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/VIMA/VIMA-2009-11-14
        11-14-2009 00:26:34 --  info: DEBUG - VM Datastore: himalaya-local-SAS.Savvio
        11-14-2009 00:26:34 --  info: DEBUG - VMDK(s):
        11-14-2009 00:26:34 --  info: DEBUG - [http://himalaya-local-SAS.Savvio|http://himalaya-local-SAS.Savvio] VIMA/VIMA.vmdk
        11-14-2009 00:26:34 --  info: DEBUG - [http://himalaya-local-SAS.Savvio|http://himalaya-local-SAS.Savvio] VIMA/VIMA_1.vmdk
        11-14-2009 00:26:34 --  info: ---------- DRYRUN DEBUG INFO VIMA ----------

        11-14-2009 00:26:34 --  debug: reConfigureBackupParams: VM - vMA-2
        11-14-2009 00:26:34 --  info: CONFIG - USING CONFIGURATION FILE = vMA-2
        11-14-2009 00:26:34 --  info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
        11-14-2009 00:26:34 --  info: CONFIG - VM_BACKUP_DATASTORE = dlgCore-NFS-bigboi.VM-Backups
        11-14-2009 00:26:34 --  info: CONFIG - VM_BACKUP_DIRECTORY = vGHETTO_BACKUPS
        11-14-2009 00:26:34 --  info: CONFIG - DISK_BACKUP_FORMAT = thin
        11-14-2009 00:26:34 --  info: CONFIG - ADAPTER_FORMAT = lsilogic
        11-14-2009 00:26:34 --  info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
        11-14-2009 00:26:34 --  info: CONFIG - VM_SNAPSHOT_MEMORY = NO
        11-14-2009 00:26:34 --  info: CONFIG - VM_SNAPSHOT_QUIESCE = NO
        11-14-2009 00:26:34 --  info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-11-14
        11-14-2009 00:26:34 --  info: CONFIG - VM_VMDK_FILES = all

        11-14-2009 00:26:34 --  info: ---------- DRYRUN DEBUG INFO vMA-2 ----------
        11-14-2009 00:26:34 --  info: DEBUG - Host Build: VMware ESX 4.0.0 build-164009
        11-14-2009 00:26:34 --  info: DEBUG - Host: himalaya.primp-industries.com
        11-14-2009 00:26:34 --  info: DEBUG - Virtual Machine: vMA-2
        11-14-2009 00:26:34 --  info: DEBUG - VM ConfigPath: [http://himalaya-local-SAS.Constellation|http://himalaya-local-SAS.Constellation] vMA-2/vMA-2.vmx
        11-14-2009 00:26:34 --  info: DEBUG - VMX File: vMA-2.vmx
        11-14-2009 00:26:34 --  info: DEBUG - BackupConfigPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] vGHETTO_BACKUPS/vMA-2/vMA-2-2009-11-14/vMA-2.vmx
        11-14-2009 00:26:34 --  info: DEBUG - BackupPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] vGHETTO_BACKUPS/vMA-2/vMA-2-2009-11-14
        11-14-2009 00:26:34 --  info: DEBUG - VM Datastore: himalaya-local-SAS.Constellation
        11-14-2009 00:26:34 --  info: DEBUG - VMDK(s):
        11-14-2009 00:26:34 --  info: DEBUG - [http://himalaya-local-SAS.Constellation|http://himalaya-local-SAS.Constellation] vMA-2/vMA-2.vmdk
        11-14-2009 00:26:34 --  info: ---------- DRYRUN DEBUG INFO vMA-2 ----------

        11-14-2009 00:26:37 --  info: ============================== ghettoVCBg2 LOG END ==============================

FAQ

0Q: I'm having some issues or would like to provide feedback

0A: Please join the ghettoVCBg2 Group to post your comments/questions

1Q: I'm using ESXi and free licensed version ( I did not pay for anyting ), will this script still work?

1A: No, you need to have a licensed version of ESXi to use this script.

2Q: I have a VM listed in my backup file but no backup of that VM took place. The log stated that the VM could not be found. How could this be? I know that it’s running on host X…

2A: Ensure the ESX/ESXi host is being managed by VMware VIMA/vMA (sudo vifp listservers to verify)

3Q: Can I schedule backups to take place hourly, daily, monthly, yearly?

3A: Yes, do a search online for crontab.

4Q: I want to schedule my backup on Windows, how do I do this?

4A: Do a search for

plink. Make sure you have paired SSH keys setup between your Windows system and VIMA/vMA.

5Q: Do I have to use VMware VIMA/vMA to initiate the backup?

5A: Yes, vi-fastpass is being used and only VIMA/vMA provides this capability. However, you can kickoff the process from another host (*nix/win)

4Q: I only have a single ESXi host. I want to take backups and store them somewhere else. The problem is: I don't have NFS, iSCSI nor FC SAN. What can I do?

4A: You can use local storage to store your backups assuming that you have enough space on the destination datastore. Afterwards, you can use scp (WinSCP/FastSCP) or vifs (vCLI) to transfer the backups from the ESXi host to your local desktop.

5Q: I’m pissed; the backup is taking too long. My datastore is of type X?

5A: YMMV, take a look at your storage configuration and make sure it is optimized.

6Q: I noticed that the backup rotation is occurring after a backup. I don't have enough local storage space, can the process be changed?

6A: This is primarily done to ensure that you have at least one good backup in case the new backup fails. If you would like to modify the script, you're more than welcome to do so.

7Q: What is the best storage configuration for datastore type X?

7A: Search the VMTN forums; there are various configurations for the different type of storage/etc.

8Q: I want to setup NFS Server to run my backups. Which is the best and should it be virtual or physical?7

8A: Please refer to answer 7A. From experience, we’ve seen physical instances of NFS servers to be faster than their virtual counterparts. As always, YMMV.

9Q: When I try to use the script I get an error stating: "restricted version". What the heck is this?

9A: Please take a look at the ESX/ESXi Version Support Table in this document. The reason is explained here.

10Q: I'm getting error X when using the script or I'm not getting any errors, the backup didn’t even take place. Oh what could be wrong?

10A: First, you'll want to check the log (default /tmp/ghettoVCBg2) and see if there are any obvious errors. If not, please provide the entire output of the log, a short description of your environment and the type of VM(s) you're trying to backup—I will try to provide some assistance.

11Q: I have VMs that have snapshots. I want to back these things up but the script doesn’t let me do it. How do I fix that?

11A: VM snapshots are not meant to be kept for long durations. When backing up a VM that contains a snapshot, you should ensure all snapshots have been committed prior to running a backup. No exceptions will be made…ever.

12Q: I would like to restore from backup, what is the best method?

12A: The restore process will be unique for each environment and should be determined by your backup/recovery plans. At a high level you have the option of mounting the backup datastore and registering the VM in question or copy the VM from the backup datastore to the ESX/ESXi host. The latter is recommended so that you're not running a VM living on the backup datastore or inadvertently modifying your backup VM(s).

13Q: When using the experimental feature: Individual VM backup policy, if I don't have a policy will it use the default configurations defined in the script?

13A: No, this use case will not be supported, ever. If you decide to use the per VM policy, then the global configuration in the script is ignored. If a VM policy config is not found, the VM will not be backed up even if it's in the –-vmlist.

14Q: In vMA 4.0, vCenter target will be supported, can I just add vCenter target and assume this will work?

14A: At the moment, this is not a supported feature. You will need to add each ESX/ESXi host for the vi-fastpass library to be able to locate the host(s).

15Q: When I try to run the script I get: "-bash: ./ghettoVCBg2.pl: Permission denied", what is wrong?

15A: You need to change the permission on the script to be executable, chmod +x ghettoVCBg2.pl

16Q: Where can I download the latest version of the script?

16A: The latest version is available on this page at the bottom. To get the version of the script run

./ghettoVCBg2.pl --version

17Q: I'm running into an issue when I backup my VMs using NFS on Linux, I'm able to either get 1 successful backup and all subsequent backups fail OR I'm having issues where snapshots are not being removed upon completition and future backups fail.

17A: This problem/issue has been reported by quite a few users in the community and only affects a very small percentage of users overall under a specific configuration. The problem as I understand it today which is still an on-going investigation by myself and the community is as follows:

The Setup

Setup: NFS on Linux where the underlying volume is EXT3 filesystem

and backups are failing primarily around larger sized VMs ( > 150GB).

The Observed Problem

The issue is during the final phase of a VM being backed-up in the rotation function where a request is sent out to the NFS server to either A) rotate/rename a directory B) delete an old backup. There is either a disconnect or delay that severely affects the backup process that may lead to a whole slew of "unexpected" behavior from having only 1 backup complete successful and all subsquent backups failing/etc.

First off, there is nothing wrong with the script from what we've found it and has to do with NFS server and specifically the volume that the backup datastore is hosted on. Thanks to community user

ralfoertner who had a simliar problem using

ghettoVCBg2 using Debian with EXT3 base filesystem for his NFS volume. He decided to do some additional troubleshooting to further isolate the problem and actually found by changing the underlying filesystem from EXT3 to XFS that the issue went away and resolve all issues he had ran into regarding an NFS on Linux backup solution.

The Theory

Now, we're still 100% sure why the above solution has resolved the problem or what the actual problem is but I'll explain the current theory:

EXT3 is a journaled filesystem, you can do a search online for more information. There's a few advantages with EXT3 from it's predcessor EXT2, but one difference is in the approach it takes with journaling as explained here in greater detail:

http://www.ibm.com/developerworks/library/l-fs7.html

Basically EXT2 does only "metadata journling" whereas EXT3 does both data and metadata journaling, this would ensure that all changes to the filesystem where it's data or metadata is consistent in the event of an unexpected system crash. With EXT3, there are 3 journaling options: (

data=writeback mode,data=ordered mode,data=journal mode ) and by default it uses

data=ordered mode to ensure the consistency as described from above.

One easy method to check what mount options are configured, on a Linux system you can check /proc/mounts:

[vi-admin@scofield ~]$ cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
/dev /dev tmpfs rw 0 0
/proc /proc proc rw 0 0
/sys /sys sysfs rw 0 0
/proc/bus/usb /proc/bus/usb usbfs rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/VolGroup00/var /var/log ext3 rw,data=ordered 0 0
/dev/sda1 /boot ext3 rw,data=ordered 0 0
tmpfs /dev/shm tmpfs rw 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0

So now what does this have to do with XFS and EXT3? With the defaults of EXT3, it may not always give you the best performance due to the extra overhead of the way it does its journaling, if you were to change the options to

data=writeback mode, you'll notice that this is simliar journaling method found in

XFS,JFS and ResierFS as described here:

http://www.ibm.com/developerworks/library/l-fs8.html

The Conclusion

I believe that there are some additional overheads that maybe caused by using NFS on EXT3, which may explain the issue that users are seeing and that moving from EXT3 to XFS has "seemed" to solve the issues for those who have implemented the change. Though, before you go out and make this change, you need to understand your environment and what this change would exactly mean, please refer to differences in EXT2/XFS and EXT3, especially around a power interruption or system crash.

In conclusion, I'm not recommending one way or the other, it really depends on your environment. Though this has shown to resolve the issue as users have implemented to get around this problem, but it's definitely worth while to really understand the problem in your environment and figure out why and decide on the best solution. I would also recommend users perform their own tests to further isolate the problem in their environment and try local storage, using iSCSI to see if they can pin-point the problem.

Useful Links:

If you have found this script or other scripts to be useful and would like to contribute back, please click

here to donate! Thank You

Change Log

07/20/10 - build 4.3

Enhancements:

Support for vSphere 4.1 (ESX and ESXi)

Bug Fixes:

Due to changes in the VIFP Library introduced with vMA 4.1, the script has been updated to work on both vMA 4.0 and vMA 4.1. Only upgrade to vMA 4.1 if you're managing ESX(i) 4.1 hosts

03/27/10 - build 4.2

Enhancements:

Added a check to see if ESX(i) host is in a connected state
Added a check to see if ESXi host is using the free license, if so, skip host
Added FAQ #0

03/27/10 - build 4.1

Enhancements:

Updated FAQ #17 regarding "NFS" issue

02/24/09 - build 4.1

Bug Fixes:

There was a typo in handling the case of a VM's VMDK(s) being distributed across multiple datastores in which the backup was not creating the directory to reflect this layout, thanks to briandatamatters for finding this bug.

05/26/09 - build 2.5.1

Enhancements:

N/A

Bug Fixes:

Implemented shorterm solution fix for bug in VMware vCLI's vifs
Updated logic to allow virtual RDM to be backed up

04/25/09 - build 2.5

Enhancements:

Added experimental feature Individual VM backup policy
Added VM snapshot memory & quiesce options

Bug Fixes:

N/A

02/21/09 - build 2.0

Initial release

tschneider · ‎10-21-2010

Paul,

if you search for vima-release in the script I simply changed the order of nest "if" statement to this:

if(-f "/etc/vma-release") {

open(VIMA_REL, "/etc/vma-release") || die "Couldn't open the /etc/vma-release!";

} elsif(-f "/etc/vima-release") {

open(VIMA_REL, "/etc/vima-release") || die "Couldn't open the /etc/vima-release!";

}

pensord · ‎10-25-2010

Cheers works perfectly now.

sassaints · ‎10-25-2010

Even after reading and trying all the suggestions listed here, I'm still having an issue running ghettoVCBg2.pl from cron. I created a shell script which invokes the perl script with the necessary arguments and also appends the date and time to a log file in /tmp. This script works fine when invoked manually. When run by cron, the log file is updated with the date & time, but ghettoVCBg2.pl produces no output. I've even set it to just spit out the version with --version, but no output is generated. I have copied vi-admin's SHELL, LD_LIBRARY_PATH, and PATH environment settings into the script from env.

Any suggestions? Any reason why ghettoVCBg2.pl seems to refuse to run under cron?

Here's the shell script I'm currently using to test this. Set to run every minute by cron.

#!/bin/sh

TMPFILE=/tmp/testdwm

touch $TMPFILE

date >> $TMPFILE

SHELL=/bin/bash

LD_LIBRARY_PATH=:/opt/vmware/vma/lib64:/opt/vmware/vma/lib

PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/java/jre-vmware/bin:/sbin:/usr/sbin:/home/vi-admin/bin

GHETTOVCB=/opt/ghettoVCBg2/ghettoVCBg2.pl

VMLIST=/opt/ghettoVCBg2/ghettoHosts

$GHETTOVCB --version 2>&1 >> $TMPFILE

Update: Got it to work by using vi-admin's crontab file instead of /etc/crontab.

minerat · ‎10-25-2010

I've worked through my issues getting the script to run in cron as root (updating crontab with the required PATH) but I keep getting

"Can't get vim_service - the session object is uninitialized or not logged in" - this is from stderr.

The script log shows this as the last two lines for the first VM it attempts to back up.

10-23-2010 22:00:11 -- debug: CopyThread: Start backing up VMDK(s) ...

10-23-2010 22:00:11 -- debug: backupVMDK: Backup progress: Elapsed time 0 min

Any ideas?

sassaints · ‎10-25-2010

@minerat,

My only thought with those errors is that you have not run through the documentation to authenticate your vMa appliance with VC / esx. If you have, maybe the authentication is stored with the user account and you need to do it as root as well.

minerat · ‎10-25-2010

Yeah, that'd make sense from the error:

Can't get vim_service - the session object is uninitialized or not logged in at /usr/lib/perl5/5.8.8/VMware/VICommon.pm line 1654

A thread exited while 2 threads were running.

However, I added the servers and confirmed with sudo vifp listservers. For the hell of it I removed and re-added. The problem persists interactively even as vi-admin. I had a successful manual backup at some point in time, but it started failing with can't get vim_service when run from cron. A reboot previously allowed me to run it manually again, but no such luck anymore. dryrun always works. If all else fails I'll reinstall the vMA.

snakemiesen · ‎10-27-2010

Think it's possible to show the percentage of the backup status on screen in your ssh session? and add the start and end time for each vm in the mail log?

regards

Jimmy

sjwk · ‎10-27-2010

I'm occasionally getting an error when running ghettoVCBg2:

Can't call method "rootFolder" on an undefined value at /usr/lib/perl5/5.8.8/VMware/VICommon.pm line 1218.

A thread exited while 2 threads were running.

It doesn't do this all the time, but it's done it maybe half a dozen times so far, usually several servers into a list of machines to backup. I can run the script again, passing the same file and it'll work. It's infrequent enough that (until now) I've not attempted to chase it up.

VMWare hosts are 3.5, virtual center 2.5. Backing up to a NAS via NFS.

Any ideas?

Steve.

minerat · ‎10-29-2010

@sassaints

I've tracked it down to enabling $VM_SNAPSHOT_MEMORY = "1";

I get full backups with it set to 0. When I enable the snaps it copies the vmx, then bombs (no vmdks, no snap created) and sends this to stderr

Can't get vim_service - the session object is uninitialized or not logged in at /usr/lib/perl5/5.8.8/VMware/VICommon.pm line 1654

A thread exited while 2 threads were running.

Any ideas? I'd really like snaps on everything except my DC/Exchange server.

kswail · ‎10-29-2010

Hi there,

I've been using ghettovcbg2 for a while and it has been working really well, thanks alot for this script!

I have a question I was hoping there was an answer for.

Each folder where a backup of a vm is made is suffixed with "~~#". For example "~~1", "--2", etc...

Is there a way to avoid this from happening?

In my environment, once ghettovcb is done, I sync the backup datastore to an external device, but since each folder is always renamed, it causes all my past jobs to be copied over as well since there was a change in the directory name. I'd prefer if only the last iteration of the backup files were copied over.

If anyone has any tips I'd appreciate it.

thx

kswail

riddweise · ‎11-05-2010

hi,

I have esxi 3.5, vcenter 4.1 and vcenter client v4.1. I have VMA v4.1 also. I'm running the script on the vma. The backup space is mounted to the vma via nfs. I verified that I can write to the mount. I'm trying to backup one vm and I keep getting the error listed below. The dryrun works without a hitch. Also I should mention the vma does control the server 'vifp listservers'.

The config:

VM_BACKUP_DATASTORE = "foo.mycompany.com:/vmbackup"

VM_BACKUP_DIRECTORY = "goo"

VM_BACKUP_ROTATION_COUNT = "3"

DISK_BACKUP_FORMAT = "zeroedthick"

ADAPTER_FORMAT = "lsilogic"

POWER_VM_DOWN_BEFORE_BACKUP = "0"

VM_SNAPSHOT_MEMORY = "0"

VM_SNAPSHOT_QUIESCE = "0"

LOG_LEVEL = "debug"

VM_VMDK_FILES = "all"

The error is: (the script was run as root)

Can't get vim_service - the session object is uninitialized or not logged in at /usr/lib/perl5/5.8.8/VMware/VICommon.pm line 1654

A thread exited while 2 threads were running.

Can anybody shed some light on this?

minerat · ‎11-08-2010

More problems - ran through part of a cron job, then bombed out on a VM after copying the vmx.

This went to stderr:

Can't call method "rootFolder" on an undefined value at /usr/lib/perl5/5.8.8/VMware/VICommon.pm line 1218.

A thread exited while 2 threads were running.

This is from the ghettolog

11-06-2010 21:05:09 -- info: EX03 has 4 VMDK(s)

11-06-2010 21:05:09 -- debug: backupVMDK: Backing up "[11nx-vmfs] EX03/EX03.vmdk" to "[VMBackups] /EX03/EX03-2010-11-06/EX03.vmdk"

11-06-2010 21:05:09 -- debug: backupVMDK: Signal copyThread to start

11-06-2010 21:05:09 -- debug: backupVMDK: Backup progress: Elapsed time 0 min

11-06-2010 21:05:09 -- debug: copyTask: Wake up and follow the white rabbit, with status: doCopy

11-06-2010 21:05:09 -- debug: CopyThread: Start backing up VMDK(s) ...

11-06-2010 21:05:14 -- debug: copyTask: send copySuccess message ...

11-06-2010 21:05:14 -- debug: copyTask: waiting for next job and sleep ...

11-06-2010 21:06:09 -- debug: backupVMDK: Successfully completed backup for EX03/EX03.vmdk Elapsed time: 1 min

11-06-2010 21:06:10 -- debug: checkVMBackupRotation: Starting ...

11-06-2010 21:06:12 -- info: Backup completed for EX03!

As you can see, it detected 4 vmdks, but only tried to copy 1 (which it did not do - the only file in the VM's backup folder is the vmx).

minerat · ‎11-15-2010

Same thing happened again with a different VM (EX03 was decomissioned). What can I do to troubleshoot?

xystus · ‎11-25-2010

Hi William,

I am fresh for this script, I follow your instruction to copy one VM from one Esxi to another Esxi (within the same VCenter).

& for the below error.

Can't get vim_service - the session object is uninitialized or not logged in at /usr/lib/perl5/5.8.8/VMware/VICommon.pm line 1654

& below is the log

11-25-2010 21:02:49 -- info: ============================== ghettoVCBg2 LOG START ==============================

11-25-2010 21:02:49 -- debug: copyTask: Task START

11-25-2010 21:02:49 -- debug: copyTask: waiting for next job and sleep ...

11-25-2010 21:02:49 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log

11-25-2010 21:02:49 -- info: CONFIG - VM_BACKUP_DATASTORE = backup-datastore01

11-25-2010 21:02:49 -- info: CONFIG - VM_BACKUP_DIRECTORY = VM-Backup

11-25-2010 21:02:49 -- info: CONFIG - DISK_BACKUP_FORMAT = thin

11-25-2010 21:02:49 -- info: CONFIG - ADAPTER_FORMAT = lsilogic

11-25-2010 21:02:49 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO

11-25-2010 21:02:49 -- info: CONFIG - VM_SNAPSHOT_MEMORY = NO

11-25-2010 21:02:49 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = NO

11-25-2010 21:02:49 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2010-11-25

11-25-2010 21:02:49 -- info: CONFIG - VM_VMDK_FILES = all

11-25-2010 21:03:09 -- debug: Main: Login by vi-fastpass to: vmware07.brk.corp.yuanta.com

11-25-2010 21:03:12 -- info: Initiate backup for Server02 found on vmware07.brk.corp.yuanta.com

11-25-2010 21:03:14 -- debug: Server02 original powerState: poweredOff

11-25-2010 21:03:14 -- info: Server02 has 2 VMDK(s)

11-25-2010 21:03:14 -- debug: backupVMDK: Backing up "[Datastore_1] Server02/Server02.vmdk" to "[backup-datastore01] VM-Backup/Server02/Server02-2010-11-25/Server02.vmdk"

11-25-2010 21:03:14 -- debug: backupVMDK: Signal copyThread to start

11-25-2010 21:03:14 -- debug: copyTask: Wake up and follow the white rabbit, with status: doCopy

11-25-2010 21:03:14 -- debug: CopyThread: Start backing up VMDK(s) ...

11-25-2010 21:03:14 -- debug: backupVMDK: Backup progress: Elapsed time 0 min

11-25-2010 21:03:16 -- debug: copyTask: send copySuccess message ...

11-25-2010 21:03:16 -- debug: copyTask: waiting for next job and sleep ...

11-25-2010 21:04:14 -- debug: backupVMDK: Successfully completed backup for Server02/Server02.vmdk Elapsed time: 1 min

11-25-2010 21:04:14 -- debug: backupVMDK: Backing up "[Datastore_1] Server02/Server02_1.vmdk" to "[backup-datastore01] VM-Backup/Server02/Server02-2010-11-25/Server02_1.vmdk"

11-25-2010 21:04:14 -- debug: backupVMDK: Signal copyThread to start

11-25-2010 21:04:14 -- debug: backupVMDK: Backup progress: Elapsed time 0 min

11-25-2010 21:04:14 -- debug: copyTask: Wake up and follow the white rabbit, with status: doCopy

11-25-2010 21:04:14 -- debug: CopyThread: Start backing up VMDK(s) ...

11-25-2010 21:04:18 -- debug: copyTask: send copySuccess message ...

11-25-2010 21:04:18 -- debug: copyTask: waiting for next job and sleep ...

11-25-2010 21:05:14 -- debug: backupVMDK: Successfully completed backup for Server02/Server02_1.vmdk Elapsed time: 1 min

11-25-2010 21:05:15 -- debug: checkVMBackupRotation: Starting ...

reusensj · ‎12-04-2010

Meanwhile, rootcause was a slow disk (Green WD). Replaced it with a faster one..

Now I have the following problem:

I backup several virtual machines successfully but it fails with one.

The difference is that the datastore's are bigger: 200 Gb, 250 Gb. as compared to 50Gb for the successfull VM's.

Log says "unable to locate VM" (see below ).

In the vsphere client there is an error message saying

"

Create virtual machine snapshot sol10

File

":

LOG in /tmp/ghettoVCBg2.log:

12-04-2010 02:34:48 -- info: ============================== ghettoVCBg2 LOG START ==============================

12-04-2010 02:34:48 -- debug: Main: Login by vi-fastpass to: vmware.reusens.com

12-04-2010 02:34:48 -- debug: copyTask: Task START

12-04-2010 02:34:48 -- debug: copyTask: waiting for next job and sleep ...

12-04-2010 02:34:50 -- debug: reConfigureBackupParams: VM - sol10

12-04-2010 02:34:50 -- info: CONFIG - USING CONFIGURATION FILE = sol10

12-04-2010 02:34:50 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log

12-04-2010 02:34:50 -- info: CONFIG - VM_BACKUP_DATASTORE = VM-Backups

12-04-2010 02:34:50 -- info: CONFIG - VM_BACKUP_DIRECTORY = VMWARE_BACKUPS

12-04-2010 02:34:50 -- info: CONFIG - DISK_BACKUP_FORMAT = zeroedthick

12-04-2010 02:34:50 -- info: CONFIG - ADAPTER_FORMAT = buslogic

12-04-2010 02:34:50 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO

12-04-2010 02:34:50 -- info: CONFIG - VM_SNAPSHOT_MEMORY = NO

12-04-2010 02:34:50 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = NO

12-04-2010 02:34:50 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2010-12-04

12-04-2010 02:34:50 -- info: CONFIG - VM_VMDK_FILES = all

12-04-2010 02:34:50 -- info: Initiate backup for sol10 found on vmware.reusens.com

12-04-2010 02:35:02 -- debug: sol10 original powerState: poweredOn

12-04-2010 02:35:02 -- debug: Creating Snapshot "ghettoVCBg2-snapshot-2010-12-04" for sol10

12-04-2010 02:35:12 -- debug: Main: Disconnect from: vmware.reusens.com

12-04-2010 02:35:12 -- error: getFinalList: ERROR - Unable to locate VM: sol10

12-04-2010 02:35:12 -- debug: Main: Calling final clean up

12-04-2010 02:35:12 -- debug: cleanUP: Thread clean up starting ...

12-04-2010 02:35:12 -- debug: cleanUp: CopyTask was never started, send copyTaskStart

12-04-2010 02:35:12 -- debug: cleanUp: Send exit to copyThread

12-04-2010 02:35:12 -- debug: copyTask: Wake up and follow the white rabbit, with status: exit

12-04-2010 02:35:12 -- debug: copyTask: die ...

12-04-2010 02:35:12 -- debug: cleanUp: Join passed

12-04-2010 02:35:12 -- info: ============================== ghettoVCBg2 LOG END ==============================

lamw · ‎12-04-2010

The is an issue if you have a VM stored on multiple datastores and the source VMFS volume in which the VM's configuration file is stored in a VMFS volume that has a smaller blocksize than the other VMFS datastores. The snapshot actually fails.

To resolve this, migrate the VM's configuration file to the VMFS datastore with the larger blocksize OR keep your VMFS blocksize consistent.

Here's a little more detail on the issue that we personally ran into - http://www.virtuallyghetto.com/2010/05/vsphere-esx-40-crash-vm-bug.html

=========================================================================

William Lam

VMware vExpert 2009,2010

VMware VCP3,4

VMware VCAP4-DCA

VMware scripts and resources at:

Twitter: @lamw

vGhetto Script Repository

Getting Started with the vMA (tips/tricks)

Getting Started with the vSphere SDK for Perl

VMware Code Central - Scripts/Sample code for Developers and Administrators

VMware Developer Community

If you find this information useful, please award points for "correct" or "helpful".

minerat · ‎12-05-2010

It finally worked this weekend. I think one of my hosts had nearly run out of disk space and when the script would get to a VM on that host it would bomb out. I deleted a lot of big logs from an old case. Whether this was the root cause or not, I don't know, but it's worth a shot if anyone else has a similar problem.

dekopolis · ‎12-18-2010

I'm currently using the vSphere Hypervisor (free) version. I'm considering buying the Essentials Kit. Will that be enough to get this script to work?

lamw · ‎12-18-2010

dekopolis

Yes, anything other than the "free" version will work. If you decide you want to use the free version, then you'll have to use the ghettoVCB, unfortunately there is a permission issue on the forums and you will not be able to access the document until the problem is resolved. You can do a search on the tnternet or access the most recent cached version if you're interested.

reusensj · ‎12-20-2010

Hi William,

I also did a vima-update, and when it was running the shivers ran down my spine...

Should I step back?

I get following error message:

Use of inherited AUTOLOAD for non-method vifplib_perl::CreateVIUserInfo() is deprecated at /home/vi-

admin/ghettoVCBg2/ghettoVCBg2.pl line 305.
Undefined subroutine &vifplib_perl::CreateVIUserInfo called at /home/vi-admin/ghettoVCBg2/ghettoVCBg2.pl line 305

I use following version:

/home/vi-admin/ghettoVCBg2/ghettoVCBg2.pl --version gives:
SDK for Perl version: 4.1
Script 'ghettoVCBg2.pl' version: 4.3

Env variables:
LD_LIBRARY_PATH=:/opt/vmware/vma/lib64:/opt/vmware/vma/lib
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/java/jre-vmware/bin:/usr/java/jre1.5.0_15/bin:/sbin:/usr/sbin:/home/vi-admin/bin:/sbin:/usr/sbin

Linux version 2.6.18-164.9.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46))

Thanks in advance

Johnny Reusens

FRCRUTJO · ‎12-30-2010

Hi everybody, i hope to post at the right "place"

I am new here and i am trying to find information about backuping virtual machines and understand at the same time.

I read a lot of doc..post..answers..etc..but i still have the same problem, that's why i want experts advices to be sure that what can i do what i can't...

First, i tried the ghettoVCBg2.pl perl script with vMA (OVF) like this: ./ghettoVCBg2.pl --vmlist test-list and i have the following error in the /tmp/ghettoVCBg2.log :

12-30-2010 08:42:51 -- warn: xxxxxx.y.z is using free license & can't support VM backups!
12-30-2010 08:42:51 -- debug: Main: Disconnect from: xxxxxx.y.z

For information, i connected well my ESXi like target with vifptarget -s xxxx and i can see it with vifp listservers

That's strange because at the top of this web page, this written that Esxi4.1 can do that and here the version and build of mine:

VMware ESXi, 4.1.0, 260247

VinceMic · ‎01-03-2011

Hello and happy new year to you all,

We've started using ghettoVCBg2 to backup our vSphere 4.0 farm with great success.

I have witnessed a peculiar behaviour though: if for some reason the target ESX host doesn't have write access to the target NFS datastore for backups, there's no notification apparently making its way to the ghettoVCBg2 logs. The operation still appears to have completed successfully (although this happens too quickly for being real). Is this a known limitation?

I have a question about the ADAPTER_FORMAT parameter too. Is it really required for a backup operation? It seems that vmkfstool only uses it when creating a VMDK. Having to set it up properly gets in my way for having a single, unified configuration file to back up all my VMs.

lamw · ‎01-03-2011

@FRCRUTJO,

As the document states, this script is only supported with a paid license of ESX and/or ESXi, the free version of ESXi will not work. You can take a look at an alternative and actually the original ghettoVCB script which supports both a licensed and free version of ESXi, currently the document is inaccessible due to a bad conversion from VMware while upgrading the forum software. I'm hoping this will get resolved asap but in the meantime you should still be able to access it via google cache

lamw · ‎01-03-2011

@VinceMic,

Thanks for the feedback. Regarding write access to an NFS datastore, I'm going to assume the host in question has this privledge, but yes, you're right it should do a better job of alerting on this. I would have assumed that if the write failed, it would have thrown an error which would have been caught. Though, this is not really use case I test, it's something I can look into for a future release but there are certain things that I will assume such as destination datastore has sufficient space to backup a VM or that it's writable. These are things an admin should be monitoring and keeping an eye on.

Regarding the ADAPTER_FORMAT, you don't need to specify this for each and every VM, you have the ability to specify within the global configuration file. This is merely there for backwards compatibility as vmkfstool used to require you to spcify the exact format. In the past, the default was actually buslogic but now I believe if you don't specify, it'll use the source's adapter which is what you want. The issue is providing consistent backwards compatibility and this is just something I haven't had time to really look or think about.

FRCRUTJO · ‎01-04-2011

@LAMW,

Hi, first, thank you answering my question. You right, i already tested the ghettoVCB and it works (only because i modified their script wich check 4.0.0 ESXi's version and mine is 4.1.0).

I wanted to test the "ghettoVCBg2" because i found it more intuitive for the differents types of Hard disk backup's type. That's because i'm french and i didn't understand the differences of all these types "eager...thin..etc.."

Thank you again

lamw · ‎01-31-2011

Hello Everyone,

I have recently closed the comments section and decided to create a dedicated VMTN group for ghettoVCBg2. Please join the group for discussions related to questions, issues/troubleshooting, feature requests/etc. By subscribing you will also be receiving the latest updates with this script. The comments section will still be available as read-only.

Thank you for your support.

--William Lam
http://www.virtuallyghetto.com/

All

ghettoVCBg2 - Free alternative for backing up VMs in ESX(i) 3.5 and 4.x (no SSH console required!)