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.
VMs running on ESX(i) 3.5u2+ or ESX(i) 4.x+
VMware VIMA 1.0 or VMware vMA 4.x
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\ |
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
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
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:
Defining the name of folder that will contain backups (if folder does not exist, it will automatically be created):
Defining the backup rotation per VM:
Defining the backup disk format (zeroedthick, eagerzeroedthick, thin, and 2gbsparse are available):
Defining the adapter type for backed up VMDK (buslogic, and lsilogic are available):
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
Defining whether virtual machine memory is snapped and if quiescing is enabled (1 = enable, 0 = disable):
Note: By default both are disabled
Defining the detail of logging (verbose or 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 ##########################
[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
--output
--config_dir
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
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 ==============================
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 ==============================
[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 ==============================
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:
Setup: NFS on Linux where the underlying volume is EXT3 filesystem
and backups are failing primarily around larger sized VMs ( > 150GB).
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.
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
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.
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
07/20/10 - build 4.3
Enhancements:
Bug Fixes:
03/27/10 - build 4.2
Enhancements:
03/27/10 - build 4.1
Enhancements:
02/24/09 - build 4.1
Bug Fixes:
05/26/09 - build 2.5.1
Enhancements:
Bug Fixes:
04/25/09 - build 2.5
Enhancements:
Bug Fixes:
02/21/09 - build 2.0
Initial release
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!";
}
Cheers works perfectly now.
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.
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?
@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.
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.
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
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.
@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.
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
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?
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).
Same thing happened again with a different VM (EX03 was decomissioned). What can I do to troubleshoot?
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 ...
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 ==============================
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:
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
If you find this information useful, please award points for "correct" or "helpful".
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.
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?
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.
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
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
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.
@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
@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.
@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
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/