| Version | Support | Alternative |
| ESX 3.5u2 | Requires at least Foundation license | ghettoVCB\ |
| ESX 3.5u3 | Requires at least Foundation license | ghettoVCB\ |
| ESX 3.5u4 | Requires at least Foundation license | ghettoVCB\ |
| ESXi 3.5u2 | Works for free | ghettoVCB\ |
| ESXi 3.5u3 | Works for free | ghettoVCB\ |
| ESXi 3.5u4 | Requires at least Foundation license | ghettoVCB\ |
| ESX 4.0 | Requires at least Foundation license | ghettoVCB\ |
| ESXi 4.0 | Requires at least Foundation license | ghettoVCB\ |
[vi-admin@vima-primp-industries ~]$ sudo vifp addserver olga.resnet.ucsb.edu
root@olga.resnet.ucsb.edu's password:
[vi-admin@vima-primp-industries ~]$
[vi-admin@vima-primp-industries ~]$ sudo vifp listservers
olga.resnet.ucsb.edu
himalaya.primp-industries.com
########################## DO NOT MODIFY PAST THIS LINE ##########################
[vi-admin@vima ~]$ ./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
--debug (default '0')
Set to 1 to enable debug 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
--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
| DISK_FORMAT | 2gbsparse |
| ADAPTER_FORMAT | buslogic |
| LOG_LEVEL | normal |
| VM_SNAPSHOT_MEMORY | 0 |
| VM_SNAPSHOT_QUIESCE | 0 |
| VMS_TO_BACKUP | (Devastator,grimlock) |
[vi-admin@vima ~]$ ./ghettoVCBg2.pl --vmlist virtual_machine_back_list
[vi-admin@vima ~]$ cat /tmp/ghettoVCBg2.log
============================== 05-17-2009 15:17:34 -- ghettoVCBg2 LOG START ==============================
05-17-2009 15:17:43 -- Initiate backup for "Devastator" found on himalaya.primp-industries.com!
05-17-2009 15:17:52 -- Devastator has 1 VMDK(s)
05-17-2009 15:23:24 -- Backup completed for "Devastator"!
05-17-2009 15:23:24 -- Initiate backup for "grimlock" found on himalaya.primp-industries.com!
05-17-2009 15:23:33 -- grimlock has 1 VMDK(s)
05-17-2009 15:28:53 -- Backup completed for "grimlock"!
05-17-2009 15:28:53 -- ERROR - Unable to locate VM: slag
============================== 05-17-2009 15:28:53 -- ghettoVCBg2 LOG END ==============================
| DISK_FORMAT | thin |
| ADAPTER_FORMAT | lsilogic |
| LOG_LEVEL | verbose |
| POWER_DOWN_VM | 1 |
| VM_SNAPSHOT_MEMORY | 0 |
| VM_SNAPSHOT_QUIESCE | 0 |
| VMS_TO_BACKUP | (Soundwave,Jetfire) |
[vi-admin@rafaeli ~]$ ./ghettoVCBg2.pl --vmlist virtual_machine_back_list
[vi-admin@rafaeli ~]$ cat /tmp/ghettoVCBg2.log
============================== 05-21-2009 16:50:59 -- ghettoVCBg2 LOG START ==============================
05-21-2009 16:50:59 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
05-21-2009 16:50:59 -- CONFIG - VM_BACKUP_DATASTORE = dlgCore-NFS-bigboi.VM-Backups
05-21-2009 16:50:59 -- CONFIG - VM_BACKUP_DIRECTORY = WILLIAM_BACKUPS
05-21-2009 16:50:59 -- CONFIG - DISK_BACKUP_FORMAT = thin
05-21-2009 16:50:59 -- CONFIG - ADAPTER_FORMAT = lsilogic
05-21-2009 16:50:59 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = YES
05-21-2009 16:50:59 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-21-2009 16:50:59 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-21-2009 16:50:59 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-05-21
05-21-2009 16:51:04 -- Initiate backup for "Soundwave" found on everest.primp-industries.com!
05-21-2009 16:51:14 -- Soundwave original powerState: poweredOn
05-21-2009 16:51:43 -- Successfully shutdown Soundwave!
05-21-2009 16:51:45 -- Soundwave has 3 VMDK(s)
05-21-2009 16:51:45 -- Backing up "[everest-local-storage] Soundwave_1/Soundwave.vmdk" to "[http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Soundwave/Soundwave-2009-05-21/Soundwave.vmdk"
05-21-2009 16:53:43 -- Backup completed for [everest-local-storage] Soundwave_1/Soundwave.vmdk
05-21-2009 16:53:43 -- Backing up "[everest-local-storage] Soundwave_1/Soundwave_1.vmdk" to "[http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Soundwave/Soundwave-2009-05-21/Soundwave_1.vmdk"
05-21-2009 16:53:49 -- Backup completed for [everest-local-storage] Soundwave_1/Soundwave_1.vmdk
05-21-2009 16:53:49 -- Backing up "[everest-local-storage] Soundwave_1/Soundwave_2.vmdk" to "[http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Soundwave/Soundwave-2009-05-21/Soundwave_2.vmdk"
05-21-2009 16:53:54 -- Backup completed for [everest-local-storage] Soundwave_1/Soundwave_2.vmdk
05-21-2009 16:54:03 -- Successfully powered back on Soundwave!
05-21-2009 16:54:13 -- Backup completed for "Soundwave"!
05-21-2009 16:54:13 -- Initiate backup for "Jetfire" found on everest.primp-industries.com!
05-21-2009 16:54:24 -- Jetfire original powerState: poweredOff
05-21-2009 16:54:24 -- Jetfire has 1 VMDK(s)
05-21-2009 16:54:24 -- Backing up "[everest-local-storage] Jetfire/Jetfire.vmdk" to "[http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Jetfire/Jetfire-2009-05-21/Jetfire.vmdk"
05-21-2009 16:56:33 -- Backup completed for [everest-local-storage] Jetfire/Jetfire.vmdk
05-21-2009 16:56:39 -- Backup completed for "Jetfire"!
============================== 05-21-2009 16:56:41 -- ghettoVCBg2 LOG END ==============================
| DISK_FORMAT | thin |
| ADAPTER_FORMAT | lsilogic |
| LOG_LEVEL | normal |
| DEBUG_MODE | 1 |
| VM_SNAPSHOT_MEMORY | 0 |
| VM_SNAPSHOT_QUIESCE | 0 |
| VMS_TO_BACKUP | (Soundwave,Jetfire) |
[vi-admin@rafaeli ~]$ ./ghettoVCBg2.pl --vmlist virtual_machine_back_list --debug 1
[vi-admin@rafaeli ~]$ cat /tmp/ghettoVCBg2.log
============================== 05-21-2009 17:43:25 -- ghettoVCBg2 LOG START ==============================
05-21-2009 17:43:25 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
05-21-2009 17:43:25 -- CONFIG - VM_BACKUP_DATASTORE = dlgCore-NFS-bigboi.VM-Backups
05-21-2009 17:43:25 -- CONFIG - VM_BACKUP_DIRECTORY = WILLIAM_BACKUPS
05-21-2009 17:43:25 -- CONFIG - DISK_BACKUP_FORMAT = thin
05-21-2009 17:43:25 -- CONFIG - ADAPTER_FORMAT = lsilogic
05-21-2009 17:43:25 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = YES
05-21-2009 17:43:25 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-21-2009 17:43:25 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-21-2009 17:43:25 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-05-21
05-21-2009 17:43:29 -- ---------- DEBUG INFO Soundwave ----------
05-21-2009 17:43:29 -- DEBUG - Host Build: VMware ESX 4.0.0 build-140815
05-21-2009 17:43:29 -- DEBUG - Host: everest.primp-industries.com
05-21-2009 17:43:29 -- DEBUG - Virtual Machine: Soundwave
05-21-2009 17:43:29 -- DEBUG - VM ConfigPath: [everest-local-storage] Soundwave_1/Soundwave.vmx
05-21-2009 17:43:29 -- DEBUG - VMX File: Soundwave.vmx
05-21-2009 17:43:29 -- DEBUG - BackupConfigPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Soundwave/Soundwave-2009-05-21/Soundwave.vmx
05-21-2009 17:43:29 -- DEBUG - BackupPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Soundwave/Soundwave-2009-05-21
05-21-2009 17:43:29 -- DEBUG - VM Datastore: everest-local-storage
05-21-2009 17:43:29 -- DEBUG - VMDK(s):
05-21-2009 17:43:29 -- DEBUG - [everest-local-storage] Soundwave_1/Soundwave.vmdk
05-21-2009 17:43:29 -- DEBUG - [everest-local-storage] Soundwave_1/Soundwave_1.vmdk
05-21-2009 17:43:29 -- DEBUG - [everest-local-storage] Soundwave_1/Soundwave_2.vmdk
05-21-2009 17:43:29 -- ---------- DEBUG INFO Soundwave ----------
05-21-2009 17:43:30 -- ---------- DEBUG INFO Jetfire ----------
05-21-2009 17:43:30 -- DEBUG - Host Build: VMware ESX 4.0.0 build-140815
05-21-2009 17:43:30 -- DEBUG - Host: everest.primp-industries.com
05-21-2009 17:43:30 -- DEBUG - Virtual Machine: Jetfire
05-21-2009 17:43:30 -- DEBUG - VM ConfigPath: [everest-local-storage] Jetfire/Jetfire.vmx
05-21-2009 17:43:30 -- DEBUG - VMX File: Jetfire.vmx
05-21-2009 17:43:30 -- DEBUG - BackupConfigPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Jetfire/Jetfire-2009-05-21/Jetfire.vmx
05-21-2009 17:43:30 -- DEBUG - BackupPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Jetfire/Jetfire-2009-05-21
05-21-2009 17:43:30 -- DEBUG - VM Datastore: everest-local-storage
05-21-2009 17:43:30 -- DEBUG - VMDK(s):
05-21-2009 17:43:30 -- DEBUG - [everest-local-storage] Jetfire/Jetfire.vmdk
05-21-2009 17:43:30 -- ---------- DEBUG INFO Jetfire ----------
============================== 05-21-2009 17:43:31 -- ghettoVCBg2 LOG END ==============================
##################################
### VM BACKUP CONFIGURATIONS ###
##################################
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"
LOG_LEVEL = "verbose"
VM_SNAPSHOT_MEMORY = "1"
VM_SNAPSHOT_QUIESCE = "1"
[vi-admin@vima ~]$ mkdir backupConfigs
[vi-admin@vima ~]$ cp vm-backup-config-template backupConfigs/my_vm1
[vi-admin@vima ~]$ cp vm-backup-config-template backupConfigs/my_vm2
[vi-admin@vima ~]$ cp vm-backup-config-template backupConfigs/my_vm3
....
| 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 |
| LOG_LEVEL | normal |
| VM_SNAPSHOT_MEMORY | 1 |
| VM_SNAPSHOT_QUIESCE | 1 |
| VM_BACKUP_DATASTORE | himalaya-local-SATA.Storage |
| VM_BACKUP_DIRECTORY | VGHETTO_BACKUPS |
| VM_BACKUP_ROTATION_COUNT | 1 |
| DISK_BACKUP_FORMAT | thin |
| ADAPTER_FORMAT | lsilogic |
| POWER_VM_DOWN_BEFORE_BACKUP | 1 |
| LOG_LEVEL | verbose |
| VM_SNAPSHOT_MEMORY | 0 |
| VM_SNAPSHOT_QUIESCE | 0 |
[vi-admin@vima backupConfigs]$ pwd
/home/vi-admin/backupConfigs
[vi-admin@vima backupConfigs]$ ls -Fal
total 24
drwxr-xr-x 2 vi-admin root 4096 May 19 21:58 ./
drwx------ 17 vi-admin root 4096 May 20 22:15 ../
-rw-r--r-- 1 vi-admin root 401 May 17 14:39 Devastator
-rw-r--r-- 1 vi-admin root 393 May 17 14:39 grimlock
-rw-r--r-- 1 vi-admin root 401 May 19 07:59 vm-backup-config-template
[vi-admin@vima backupConfigs]$ cat Devastator
##################################
### VM BACKUP CONFIGURATIONS ###
##################################
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"
LOG_LEVEL = "normal"
VM_SNAPSHOT_MEMORY = "1"
VM_SNAPSHOT_QUIESCE = "1"
[vi-admin@vima backupConfigs]$ cat grimlock
##################################
### VM BACKUP CONFIGURATIONS ###
##################################
VM_BACKUP_DATASTORE = "himalaya-local-SATA.Storage"
VM_BACKUP_DIRECTORY = "VGHETTO_BACKUPS"
VM_BACKUP_ROTATION_COUNT = "1"
DISK_BACKUP_FORMAT = "thin"
ADAPTER_FORMAT = "lsilogic";
POWER_VM_DOWN_BEFORE_BACKUP = "1"
LOG_LEVEL = "verbose"
VM_SNAPSHOT_MEMORY = "0"
VM_SNAPSHOT_QUIESCE = "0"
[vi-admin@vima ~]$ cat virtual_machine_back_list
Devastator
grimlock
slag
[vi-admin@vima ~]$ ./ghettoVCBg2.pl --config_dir backupConfigs --vmlist virtual_machine_back_list --debug 1
[vi-admin@vima ~]$ cat /tmp/ghettoVCBg2.log
============================== 05-17-2009 11:50:25 -- ghettoVCBg2 LOG START ==============================
05-17-2009 11:50:28 -- ERROR - Unable to locate configuration file for VM: slag!
05-17-2009 11:50:33 -- CONFIG - USING CONFIGURATION FILE = Devastator
05-17-2009 11:50:33 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
05-17-2009 11:50:33 -- CONFIG - VM_BACKUP_DATASTORE = dlgCore-NFS-bigboi.VM-Backups
05-17-2009 11:50:33 -- CONFIG - VM_BACKUP_DIRECTORY = WILLIAM_BACKUPS
05-17-2009 11:50:33 -- CONFIG - DISK_BACKUP_FORMAT = zeroedthick
05-17-2009 11:50:33 -- CONFIG - ADAPTER_FORMAT = buslogic
05-17-2009 11:50:33 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
05-17-2009 11:50:33 -- CONFIG - VM_SNAPSHOT_QUIESCE = YES
05-17-2009 11:50:33 -- CONFIG - VM_SNAPSHOT_QUIESCE = YES
05-17-2009 11:50:33 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-05-17
05-17-2009 11:50:33 -- ---------- DEBUG INFO Devastator ----------
05-17-2009 11:50:33 -- DEBUG - Host Build: VMware ESX Server 3.5.0 build-110268
05-17-2009 11:50:33 -- DEBUG - Host: himalaya.primp-industries.com
05-17-2009 11:50:33 -- DEBUG - Virtual Machine: Devastator
05-17-2009 11:50:33 -- DEBUG - VM ConfigPath: [http://himalaya-local-SATA.SSDstorage|http://himalaya-local-SATA.SSDstorage] Devastator/Devastator.vmx
05-17-2009 11:50:33 -- DEBUG - VMX File: Devastator.vmx
05-17-2009 11:50:33 -- DEBUG - BackupConfigPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Devastator/Devastator-2009-05-17/Devastator.vmx
05-17-2009 11:50:33 -- DEBUG - BackupPath: [http://dlgCore-NFS-bigboi.VM-Backups|http://dlgCore-NFS-bigboi.VM-Backups] WILLIAM_BACKUPS/Devastator/Devastator-2009-05-17
05-17-2009 11:50:33 -- DEBUG - VM Datastore: himalaya-local-SATA.SSDstorage
05-17-2009 11:50:33 -- DEBUG - VMDK(s):
05-17-2009 11:50:33 -- DEBUG - [http://himalaya-local-SATA.SSDstorage|http://himalaya-local-SATA.SSDstorage] Devastator/Devastator.vmdk
05-17-2009 11:50:33 -- ---------- DEBUG INFO Devastator ----------
05-17-2009 11:50:34 -- CONFIG - USING CONFIGURATION FILE = grimlock
05-17-2009 11:50:34 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
05-17-2009 11:50:34 -- CONFIG - VM_BACKUP_DATASTORE = himalaya-local-SATA.Storage
05-17-2009 11:50:34 -- CONFIG - VM_BACKUP_DIRECTORY = VGHETTO_BACKUPS
05-17-2009 11:50:34 -- CONFIG - DISK_BACKUP_FORMAT = thin
05-17-2009 11:50:34 -- CONFIG - ADAPTER_FORMAT = lsilogic
05-17-2009 11:50:34 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = YES
05-17-2009 11:50:34 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-17-2009 11:50:34 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-17-2009 11:50:34 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-05-17
05-17-2009 11:50:34 -- ---------- DEBUG INFO grimlock ----------
05-17-2009 11:50:34 -- DEBUG - Host Build: VMware ESX Server 3.5.0 build-110268
05-17-2009 11:50:34 -- DEBUG - Host: himalaya.primp-industries.com
05-17-2009 11:50:34 -- DEBUG - Virtual Machine: grimlock
05-17-2009 11:50:34 -- DEBUG - VM ConfigPath: [http://himalaya-local-SATA.Storage|http://himalaya-local-SATA.Storage] grimlock/grimlock.vmx
05-17-2009 11:50:34 -- DEBUG - VMX File: grimlock.vmx
05-17-2009 11:50:34 -- DEBUG - BackupConfigPath: [http://himalaya-local-SATA.Storage|http://himalaya-local-SATA.Storage] VGHETTO_BACKUPS/grimlock/grimlock-2009-05-17/grimlock.vmx
05-17-2009 11:50:34 -- DEBUG - BackupPath: [http://himalaya-local-SATA.Storage|http://himalaya-local-SATA.Storage] VGHETTO_BACKUPS/grimlock/grimlock-2009-05-17
05-17-2009 11:50:34 -- DEBUG - VM Datastore: himalaya-local-SATA.Storage
05-17-2009 11:50:34 -- DEBUG - VMDK(s):
05-17-2009 11:50:34 -- DEBUG - [http://himalaya-local-SATA.Storage|http://himalaya-local-SATA.Storage] grimlock/grimlock.vmdk
05-17-2009 11:50:34 -- ---------- DEBUG INFO grimlock ----------
============================== 05-17-2009 11:50:34 -- ghettoVCBg2 LOG END ==============================
[vi-admin@vima ~]$ ./ghettoVCBg2.pl --config_dir backupConfigs --vmlist virtual_machine_back_list
[vi-admin@vima ~]$ cat /tmp/ghettoVCBg2.log
============================== 05-17-2009 11:51:32 -- ghettoVCBg2 LOG START ==============================
05-17-2009 11:51:35 -- ERROR - Unable to locate configuration file for VM: slag!
05-17-2009 11:51:40 -- Initiate backup for "Devastator" found on himalaya.primp-industries.com!
05-17-2009 11:52:06 -- Devastator has 1 VMDK(s)
05-17-2009 11:57:57 -- Backup completed for "Devastator"!
05-17-2009 11:57:57 -- CONFIG - USING CONFIGURATION FILE = grimlock
05-17-2009 11:57:57 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
05-17-2009 11:57:57 -- CONFIG - VM_BACKUP_DATASTORE = himalaya-local-SATA.Storage
05-17-2009 11:57:57 -- CONFIG - VM_BACKUP_DIRECTORY = VGHETTO_BACKUPS
05-17-2009 11:57:57 -- CONFIG - DISK_BACKUP_FORMAT = thin
05-17-2009 11:57:57 -- CONFIG - ADAPTER_FORMAT = lsilogic
05-17-2009 11:57:57 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = YES
05-17-2009 11:57:57 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-17-2009 11:57:57 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-17-2009 11:57:57 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-05-17
05-17-2009 11:57:57 -- Initiate backup for "grimlock" found on himalaya.primp-industries.com!
05-17-2009 11:58:05 -- grimlock original powerState: poweredOn
05-17-2009 11:58:11 -- Hard power off, VMware Tools is not installed on grimlock!
05-17-2009 11:58:13 -- grimlock has 1 VMDK(s)
05-17-2009 11:58:13 -- Backing up "[http://himalaya-local-SATA.Storage|http://himalaya-local-SATA.Storage] grimlock/grimlock.vmdk" to "[http://himalaya-local-SATA.Storage|http://himalaya-local-SATA.Storage] VGHETTO_BACKUPS/grimlock/grimlock-2009-05-17/grimlock.vmdk"
05-17-2009 12:05:43 -- Backup completed for [http://himalaya-local-SATA.Storage|http://himalaya-local-SATA.Storage] grimlock/grimlock.vmdk
05-17-2009 12:05:49 -- Successfully powered back on grimlock!
05-17-2009 12:05:56 -- Backup completed for "grimlock"!
============================== 05-17-2009 12:05:56 -- ghettoVCBg2 LOG END ==============================
Hi smyle,
I'm sorry, I think when I originally started writing the script I was implementing the features in ghettoVCB which did not support RDM period...I'm looking at the code right now and it is in fact blocking RDM's all together, let me jot that down as a note and I'll get back to you.
Thanks
Everyone,
There is a known bug at the moment with vMA 4.0 and vSphere ESX(i) 4.0 that will not allow you to backup more than 1 VM, the logs will state that VM X can not be found after the first VM on the list is completed. I initially saw this with vMA 4.0 GA with vSphere ESX 4.0 RC but was hoping this might be due to the miss-match of the build. Something was dramatically alter/changed during RC release of vMA 4.0 and the GA release of vMA 4.0 that's causing this problem. I'll be investigating the root cause, but with VIMA 1.0 & ESX(i) 3.5u2+ will work and has been tested/verified.
Please let me know if you run into any other issues.
Thanks
The bug has been identified and the issue actually lies with the vSphere CLI's version of vifs, I'm still awaiting feedback from VMware to confirm the issue.
Some details can be found here: http://engr.ucsb.edu/~duonglt/vmware/vifs_bug.html
Once the issue has been identified, I'll push out a temporarily fix to remediate the issue.
Just updated the script to fix both the virtual RDM issue & a bug with VMware's vifs, let me know if anyone runs into any other issues
Hi,
It does not work for me with ESXi 4. It exits in 10-15 seconds. Looks like it fails to take a snapshot. I tried different types of the snapshots - same result. This is the latest version (same problem with the previous one).
Here is a typical log.
Are you using the free version of ESXi unlicensed? Licensed ESXi 4.0 or eval ESXi 4.0? I assume you're using vMA 4.0?
Can you please re-run the script and set the loglevel to "verbose" and attach the entire log as an attachment. Also run the script passing in the commandline param: --debug 1 and provide the entire log output as an attachment.
Sorry, I could not figure out how to attach a file, so have to add the log inline.
It is Free ESXi 4 with a registered license (not eval).
Verbose mode run, followed by debug:
============================== 05-28-2009 18:16:52 -- ghettoVCBg2 LOG START ==============================
05-28-2009 18:16:52 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
05-28-2009 18:16:52 -- CONFIG - VM_BACKUP_DATASTORE = backup
05-28-2009 18:16:52 -- CONFIG - VM_BACKUP_DIRECTORY = backups
05-28-2009 18:16:52 -- CONFIG - DISK_BACKUP_FORMAT = thin
05-28-2009 18:16:52 -- CONFIG - ADAPTER_FORMAT = lsilogic
05-28-2009 18:16:52 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
05-28-2009 18:16:52 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-28-2009 18:16:52 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-28-2009 18:16:52 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-05-28
05-28-2009 18:17:49 -- Initiate backup for "winxp" found on aaa.bbb.ccc.ddd!
05-28-2009 18:18:28 -- winxp original powerState: poweredOff
05-28-2009 18:18:28 -- winxp has 1 VMDK(s)
05-28-2009 18:18:28 -- Backing up "nexenta_nfs winxp/winxp.vmdk" to "backup backups/winxp/winxp-2009-05-28/winxp.vmdk"
05-28-2009 18:18:33 -- Backup completed for nexenta_nfs winxp/winxp.vmdk
05-28-2009 18:18:39 -- Backup completed for "winxp"!
============================== 05-28-2009 18:18:39 -- ghettoVCBg2 LOG END ==============================
============================== 05-28-2009 18:27:08 -- ghettoVCBg2 LOG START ==============================
05-28-2009 18:27:08 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
05-28-2009 18:27:08 -- CONFIG - VM_BACKUP_DATASTORE = backup
05-28-2009 18:27:08 -- CONFIG - VM_BACKUP_DIRECTORY = backups
05-28-2009 18:27:08 -- CONFIG - DISK_BACKUP_FORMAT = thin
05-28-2009 18:27:08 -- CONFIG - ADAPTER_FORMAT = lsilogic
05-28-2009 18:27:08 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
05-28-2009 18:27:08 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-28-2009 18:27:08 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
05-28-2009 18:27:08 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-05-28
05-28-2009 18:27:12 --
Is your license either Foundation, Standard or Enterprise?
It is a Free license (I just downloaded and requested the license)
Product: ESXi 4 Single Server Licensed for 1 physical CPUs (1-6 cores per CPU)
Please take a look at the FAQ section, specifically 9A for your answer.
Hi William
Good work on the scripts, not had a chance to try out this new script yet.
Love the centralized feature, will save on having to setup the NFS share on each ESXi host.
just wondering if you plan on adding in a feature where we don't have to keep lists of VM's at all, basically assuming that the user will always want to backup every VM they have. I know you now only have to keep the single list but I find I have so many VM's which come and go I often forget to add them to the backup list.
Cheers
Hi William,
thanks for this great script, this is exactly what I looked for.
But I have a small problem: The cloning doesn't work 
I'm on ESXi 3.5u3 with vMA 4.0
When I'm on the ESXi via ssh and do the cloning with vmkfstools -i this works.
Your script displays "Unable to clone virtual disk : destName"
This is what it says:
vi-admin@service01 ~$ ./ghettoVCBg2.pl --config_dir backupConfigs --vmlist vmlist --debug 0
Unable to clone virtual disk : destName
Thanks for the comments.
There will be no plans on changing the script to automatically assume all VM(s) will be backed up. If you need this feature you can modify the script accordlying, it's not that hard 
I know I ran into some oddities with VIMA 1.0's version of vmkfstools.pl but since you're using vMA 4.0, there should not be any issues. I've tested vMA with ESX 3.5u3 but not with ESXi and it should not matter in either case.
Looking at the logs, everything looks okay to me and I can't see anything that could be off. Can you provide the debugging output by running the following:
./ghettoVCBg2.pl --config_dir backupConfigs --vmlist vmlist --debug 1
$vmkfstools_cpy = `$vmkfstools_cmd --server "$host" --username "$host_username" --password "$host_password" - i "$_" -a $ADAPTER_FORMAT -d $DISK_BACKUP_FORMAT "$vmdk_backup_destination" 2>&1`;
$vmkfstools_cpy = `$vmkfstools_cmd --server "$host" --username "$host_username" --password "$host_password" - i "$_" -a $ADAPTER_FORMAT -d $DISK_BACKUP_FORMAT "$vmdk_backup_destination"`;
print "Copy command: ", $vmkfstools_cpy,"\n";
./ghettoVCBg2.pl --config_dir backupConfigs --vmlist vmlist
Mea culpa!
Got it...
After an hour of debugging and digging in my great Perl knowledge I found the problem in the backupconfig:
ADAPTER_FORMAT = "buslogic";
That small semicolon at the end of the line leads to the ADAPTER_FORMAT variable being empty
So the vmkfstools command fails because -d needs a parameter.
Everything works now, thanks for the good work.
regards,
Martin
Tried the script, great work. If anyone else is backing up to NFS datastores you can mount the same store in the VMA appliance using the following:
sudo service portmap start
sudo service nfs start
sudo chkconfig portmap on
sudo chkconfig nfs on
sudo vi /etc/fstab (Add your nfs entry here e.g.)
10.192.4.99:/vmware /backup_vmware nfs defaults 0 0
sudo mount -a
Hope this helps
Thanks for this great script and documentation.
Some small errors:
In "vm-backup-config-template" there is a semicolon at the of of ADAPTER_FORMAT which breaks the script when using config_dir
And some text in the log output is wrong QUIESCE where it should be MEMORY:
Thanks, a new vm-backup-config-template has been uploaded.
Is there any reason you would mount the backup datastore to vMA? In general, I would recommend locking down the NFS datastore to only ESX(i) hosts that way no accidental mounting from another host is allowed.
Thanks, a new vm-backup-config-template has been uploaded.
THANK YOU for this script. It's a real life saver. However, GhettoVCBg2 will be the deciding factor of whether or not people upgrade from ESXi 3.5u3. You could remedy that by adding thin provisioning support and a logging fix to GhettoVCB4i.
There are many people just getting in to virtualization who are not going to buy a foundation license. They will grow with the first virtualization vendor that has a solution that makes businesses sense for their current need, which includes a backup. Those who buy a foundation license, automatically receive VMware's VCB. For one or two servers, I would rather use GhettoVCB4i and a Windows machine to schedule it. People will need custom oem.tgz files with ESXi to address their needs for the foreseeable future anyway.
Please consider adding thin provisioning support and a logging fix to GhettoVCB4i, with the thin provisioning being the most important.
Thanks!
Hello lamw,
thanks a lot for your work but i got problems to run it.
Just after the snapshot, i got an error to copy virtual disk. It say: "general fault cause by file. One of the parameters supplied is invalid."
I use ESXi 3.5U3 with vMA4.0.
I tried with 2 differents VMs, with the local datastore and one NFS store and it still...
in /var/log/messages:
Jun 26 13:46:52 Hostd: 2009-06-26 13:46:52.014 'VdisksvcPlugin' 114696 warning Invalid desination disk format 'preallocated'
Jun 26 13:46:52 Hostd: 2009-06-26 13:46:52.050 'BaseLibs' 114696 info DISKLIB-LIB : Opened "/vmfs/volumes/4a4470d9-522186bf-68b6-0016355d8d4b/w2k3oem/w2k3oem.vmdk" (flags 0x6). A821FA4
Jun 26 13:46:52 Hostd: 2009-06-26 13:46:52.050 'BaseLibs' 114696 info DISKLIB-LIB : Invalid type (0)
Jun 26 13:46:52 Hostd: 2009-06-26 13:46:52.050 'BaseLibs' 114696 info DISKLIB-LIB : Failed to clone : One of the parameters supplied is invalid (1).
Jun 26 13:46:52 Hostd: 2009-06-26 13:46:52.050 'VdisksvcPlugin' 114696 warning Failed to clone disk : One of the parameters supplied is invalid (1).
Hi lamw,
Thanks for the script. I think it will be exactly what we are looking for but I am having some issues getting it to work. I am running it from VMA 4.0 and connecting to 2 ESXi 3.5 hosts. I have attached the log with a trial run and a debug run. Looks like it is having troubles doing a snapshot. Would really appreciate if you could take a look and give me some ideas. Thanks.
============================== 06-27-2009 22:09:00 -- ghettoVCBg2 LOG START ==============================
06-27-2009 22:09:00 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
06-27-2009 22:09:00 -- CONFIG - VM_BACKUP_DATASTORE = /vmfs/volumes/SANDisk2
06-27-2009 22:09:00 -- CONFIG - VM_BACKUP_DIRECTORY = Backups
06-27-2009 22:09:00 -- CONFIG - DISK_BACKUP_FORMAT = zeroedthick
06-27-2009 22:09:00 -- CONFIG - ADAPTER_FORMAT = buslogic
06-27-2009 22:09:00 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
06-27-2009 22:09:00 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
06-27-2009 22:09:00 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
06-27-2009 22:09:00 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-06-27
06-27-2009 22:09:02 -- Initiate backup for "AntivirusServer" found on esx2.brwmsc!
06-27-2009 22:09:06 -- AntivirusServer original powerState: poweredOn
06-27-2009 22:09:06 -- AntivirusServer has 1 VMDK(s)
06-27-2009 22:09:06 -- Backing up "SANDisk2 Antivirus Server/Antivirus Server.vmdk" to "[/vmfs/volumes/SANDisk2] Backups/AntivirusServer/AntivirusServer-2009-06-27/Antivirus Server.vmdk"
06-27-2009 22:09:07 -- Backup completed for SANDisk2 Antivirus Server/Antivirus Server.vmdk
06-27-2009 22:09:07 -- WARNING: Snapshot "ghettoVCBg2-snapshot-2009-06-27" not found
06-27-2009 22:09:08 -- Unable to purge "[/vmfs/volumes/SANDisk2] Backups/AntivirusServer/GET https:esx2.brwmscfolderBackupsAntivirusServer?dsName=vmfsvolumesSANDisk2 unsuccessful : 404 Not Found" due to rotation max
06-27-2009 22:09:08 -- Backup completed for "AntivirusServer"!
============================== 06-27-2009 22:09:08 -- ghettoVCBg2 LOG END ==============================
============================== 06-28-2009 14:30:24 -- ghettoVCBg2 LOG START ==============================
06-28-2009 14:30:24 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
06-28-2009 14:30:24 -- CONFIG - VM_BACKUP_DATASTORE = /vmfs/volumes/SANDisk2
06-28-2009 14:30:24 -- CONFIG - VM_BACKUP_DIRECTORY = Backups
06-28-2009 14:30:24 -- CONFIG - DISK_BACKUP_FORMAT = zeroedthick
06-28-2009 14:30:24 -- CONFIG - ADAPTER_FORMAT = buslogic
06-28-2009 14:30:24 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
06-28-2009 14:30:24 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
06-28-2009 14:30:24 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
06-28-2009 14:30:24 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-06-28
06-28-2009 14:30:25 --
Hello thanks for this script, I am still using your older script! Trying your new script gives me some errors
I have some problem to backup a VM in my esxi 4.0 server. I always receive this error:
/vmfs/volumes/48d3c7c5-9c6dddaa-59ff-001ec9b5cb21 # sh ghettoVCB4i.sh test
Taking backup snapshot for ANTHEAPRO ...
DiskLib_Check() failed for source disk The file specified is not a virtual disk (15).
Destination disk format: VMFS zeroedthick
Cloning disk '/vmfs/volumes/datastore1/antheapro.GruppoAnthea.local/antheapro.GruppoAnthea.local.vmdk'...
Clone: 100% done.
Removing snapshot from ANTHEAPRO ...
sh: /vmfs/volumes/VMBACKUP/ESX15/ANTHEAPRO/ANTHEAPRO-2009-06-27: bad number
ghettoVCB4i.sh: line 349: syntax error: /vmfs/volumes/VMBACKUP/ESX15/ANTHEAPRO/ANTHEAPRO-2009-06-27+1
/vmfs/volumes/48d3c7c5-9c6dddaa-59ff-001ec9b5cb21 #
I can't see anything out of the ordinary, just make sure you don't have any "semi-colon" in your configuration file and that you're abiding by the "ESX/ESXi Version Support Table" on this page.
Looks like it's complaining about a param that's not correct or unable to parse, what version of ESX(i) and VIMA/vMA are you using? I would suggest keeping the two consistent between the old VI 3.5 and vSphere 4.0
Also make sure you don't have any "semi-colon" in your configuration file
Not sure why you're getting this issue, are you using the latest ghettoVCB4i.sh script? Is it just failing for this single VM?
Yes I'm using the last ghettoVCB4i.sh script.
The script is used to backup 20 vms and this is the only one that has some problems.
Hi William,
I still have problems here.
I have 2 ESXi 3.5u3 with one VMA4 each.
And on both systems the script can't find the snapshot it created prior to copying the disks.
This is what I get every night on both systems:
============================== 07-03-2009 02:00:01 -- ghettoVCBg2 LOG START ==============================
07-03-2009 02:00:04 -- CONFIG - USING CONFIGURATION FILE = stobae03
07-03-2009 02:00:04 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
07-03-2009 02:00:04 -- CONFIG - VM_BACKUP_DATASTORE = nas_9_backup
07-03-2009 02:00:04 -- CONFIG - VM_BACKUP_DIRECTORY = sicherung
07-03-2009 02:00:04 -- CONFIG - DISK_BACKUP_FORMAT = thin
07-03-2009 02:00:04 -- CONFIG - ADAPTER_FORMAT = lsilogic
07-03-2009 02:00:04 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
07-03-2009 02:00:04 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
07-03-2009 02:00:04 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
07-03-2009 02:00:04 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-07-03
07-03-2009 02:00:04 -- Initiate backup for "stobae03" found on 5.20.33.17!
07-03-2009 02:00:18 -- stobae03 original powerState: poweredOn
07-03-2009 02:00:20 -- Creating Snapshot "ghettoVCBg2-snapshot-2009-07-03" for stobae03
07-03-2009 02:00:20 -- stobae03 has 2 VMDK(s)
07-03-2009 02:00:20 -- Backing up "datastore1 stobae03/stobae03.vmdk" to "nas_9_backup sicherung/stobae03/stobae03-2009-07-03/stobae03.vmdk"
07-03-2009 02:05:01 -- Backup completed for datastore1 stobae03/stobae03.vmdk
07-03-2009 02:05:01 -- Backing up "datastore1 stobae03/stobae03_1.vmdk" to "nas_9_backup sicherung/stobae03/stobae03-2009-07-03/stobae03_1.vmdk"
07-03-2009 04:52:35 -- Backup completed for datastore1 stobae03/stobae03_1.vmdk
07-03-2009 04:52:35 -- WARNING: Snapshot "ghettoVCBg2-snapshot-2009-07-03" not found
07-03-2009 04:52:42 -- Backup completed for "stobae03"!
============================== 07-03-2009 04:52:42 -- ghettoVCBg2 LOG END ==============================
Great job on the script, I've got it backing up 3 Virtual Machine guests to a Windows XP 64 bit target.
One of the VMs works perfectly as expected, but two of them fail to close the Snapshots and move on to the next virtual machine.
I've checked the names and the scripts (and the logs) and the script tries to close snapshots with exactly the same name as it opens, but for some reason fails. Any ideas?
I think this has to do with the NFS mount (OpenFiler 2.3) that both ZEROEDTHICK and EAGERZEROEDTHICKas the disk type result in 'General fault caused by file. One of the parameters supplied is invalid' in the VI client.
When using disk type 'THIN' the backup completes, but the snapshot if left open and the log says it failed to find the snap - even though it's exactly the same name of the snap it created!
Hi, angelone and William.
We have the same problem with 'angelone' with backup more than 2 vm`s (ESXi 4, vMA 4).
We try to separate backups for Unix and Windows machines. Backup for Unix (Linux and FreeBSD) machines working perfectlty (3 vm`s), but for Windows machines backup work only for one, that located on top of backup list. Log:
============================== 07-10-2009 08:57:50 -- ghettoVCBg2 LOG START ==============================
07-10-2009 08:57:50 -- CONFIG - BACKUP_LOG_OUTPUT = /var/log/ghettoVCBg2.log
07-10-2009 08:57:50 -- CONFIG - VM_BACKUP_DATASTORE = Backup
07-10-2009 08:57:50 -- CONFIG - VM_BACKUP_DIRECTORY = BACKUPS
07-10-2009 08:57:50 -- CONFIG - DISK_BACKUP_FORMAT = zeroedthick
07-10-2009 08:57:50 -- CONFIG - ADAPTER_FORMAT = lsilogic
07-10-2009 08:57:50 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
07-10-2009 08:57:50 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
07-10-2009 08:57:50 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
07-10-2009 08:57:50 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-07-10
07-10-2009 08:57:54 -- Initiate backup for "maildat.xxx" found on c3000-box1-vmware2.xxx!
07-10-2009 08:58:03 -- maildat.xxx original powerState: poweredOn
07-10-2009 08:58:05 -- Creating Snapshot "ghettoVCBg2-snapshot-2009-07-10" for maildat.xxx
07-10-2009 08:58:05 -- maildat.xxx has 1 VMDK(s)
07-10-2009 08:58:05 -- Backing up "Array10-1 maildat.xxx/maildat.xxx.vmdk" to "Backup BACKUPS/maildat.xxx/maildat.xxx-2009-07-10/maildat.xxx.vmdk"
07-10-2009 09:13:56 -- Backup completed for Array10-1 maildat.xxx/maildat.xxx.vmdk
07-10-2009 09:13:59 -- Removing Snapshot "ghettoVCBg2-snapshot-2009-07-10" for maildat.xxx
07-10-2009 09:14:30 -- Backup completed for "maildat.xxx"!
07-10-2009 09:14:33 -- ERROR - Unable to locate VM: FC.xxx
07-10-2009 09:14:33 -- ERROR - Unable to locate VM: R2D2.xxx
07-10-2009 09:14:33 -- ERROR - Unable to locate VM: ts.xxx
07-10-2009 09:14:33 -- ERROR - Unable to locate VM: n2000-bms.xxx
Sometimes backup completed successfully, but error for 'top' machine persist:
07-09-2009 12:31:29 -- WARNING: Snapshot "ghettoVCBg2-snapshot-2009-07-09" not found
And we can delete snapshot with Snapshot Manager 'by hand'.
I can e-mail verbose logging for this situations.
Thanks for future help.
now, does anyone know why removing all snapshots with the GUI manager works and "removeallsnapshots" from CLI tells me that there are no snapshots?
Sorry for the delay of response but I've been extremely busy over the last month and I currently do not have the cycles to look into the current issues. I'm aware there are some interesting problems being faced that may all be related. I will provide some more details when I get a chance to take a look at the issue hopefully in a few weeks after my VCP4 exam. Thanks for your patience
Hm, I don't think this is the problem here since ghettoVCB doesn't set these flags.
Our problem is that the snapshots aren't found and therefore can't be deleted.
Above KB article says, that you can't delete your snapshots because the left over flag phobits it.
I've read through this thread and I am really interested in using this script to backup my VMs. I am still learning how to use ESXi 4, so this might be a repeat question.
Can I use this script on my ESXi 4 host if I am using the "free" version? I saw something about it not working if you have not paid for a license due to some CLI thingy missing. If this is the case, then what to do for backup?
Thanks
Please re-read the document/requirements, specifically the section labeled "ESX/ESXi Version Support Table".
Correct, that has nothing to do with the issues being seen now. The KB relates to using vDR (VMware Data Recovery) where snapshots are not being removed and there has been a fix for that which is NOT related to this script at all, unless you're using vDR.
For those that are running into issues where backups are occurring but snapshots are not being removed or other issues that are similarly related, please take a look here http://tinyurl.com/layekn
The drawing starts today and you have ~1week to enter. Thanks everyone
Is there any way to prevent the script from backing up all vmdks attached to the VM?
I just want to backup the primary vmdk, not vmdks across multiple datastores.
Right now when I backup a VM, the primary vmdk processes fine, but when it hits the secondardy vmdk on another datastore, it gives an error that the file is locked or in use.
Thanks in advance!
No, that is not a supported feature of the script. You're more than welcome to add logic to exclude certain VMDK(s), no support will be provided for this.
The script should work if you have multiple VMDK(s) across multiple datastores. Is the script taking snapshots prior to backup? Please provide more details and take a look at FAQ #10
Yes I am doing snapshots prior to the backup.
The second disk is configured as an Independant Disk which is why snapshots will not run, I assume.
I was hoping by using it as an Independant disk, the backup would skip it.
Bingo, Independant Disk can not be snapshotted hence the error that its locked since w/o the snapshot and I assume the VM was powered on, it would be locked for write access.
Hello,
I'm trying to use the script on two similar configuration: ESXi 3.5u3 free licensied and vMA 4.0
I got always same problems.
Snapshot is not removed.
VMs turned off are not turned on
The backup rotation isn't working either.
Curious, have you tried to backup the 3 VMs but instead of using the configuration file just a flat file containing the VMs that need to be backed up. I know few others have ran into similar situations and so far everyone has been using the configurations to execute their backups. Just wondering if there is a bug in the configuration backup method or if this is a general issue.
I made a test on saturday on a similar architecture.
I launched manually the script for each VM (so I modified each time vmlist file) without configuration file.I didn't try the backup rotation and power off VM.
All is ok for the first VM but for the two others, snapshot still not found.
It's really strange because, like i told you, i launched each backup process independently.
Can you do the same test but with all 3 VMs on 1 backup vmlist and post your results.
Hello,
i did the same test with 3 VMs on 1 backup vmlist. I post the result.
============================== 08-08-2009 11:28:24 -- ghettoVCBg2 LOG START ==============================
08-08-2009 11:28:24 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
08-08-2009 11:28:24 -- CONFIG - VM_BACKUP_DATASTORE = NFS
08-08-2009 11:28:24 -- CONFIG - VM_BACKUP_DIRECTORY = WEEKLY
08-08-2009 11:28:24 -- CONFIG - DISK_BACKUP_FORMAT = thin
08-08-2009 11:28:24 -- CONFIG - ADAPTER_FORMAT = lsilogic
08-08-2009 11:28:24 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
08-08-2009 11:28:24 -- CONFIG - VM_SNAPSHOT_QUIESCE = YES
08-08-2009 11:28:24 -- CONFIG - VM_SNAPSHOT_QUIESCE = YES
08-08-2009 11:28:24 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-08-08
08-08-2009 11:28:28 -- Initiate backup for "SRVAD" found on 192.128.10.250!
08-08-2009 11:28:38 -- SRVAD original powerState: poweredOn
08-08-2009 11:36:17 -- Creating Snapshot "ghettoVCBg2-snapshot-2009-08-08" for SRVAD
08-08-2009 11:36:17 -- SRVAD has 1 VMDK(s)
08-08-2009 11:36:17 -- Backing up "datastore1 SRVAD/SRVAD.vmdk" to "NFS WEEKLY/SRVAD/SRVAD-2009-08-08/SRVAD.vmdk"
08-08-2009 12:04:06 -- Backup completed for datastore1 SRVAD/SRVAD.vmdk
08-08-2009 12:04:41 -- Removing Snapshot "ghettoVCBg2-snapshot-2009-08-08" for SRVAD
08-08-2009 12:04:50 -- Backup completed for "SRVAD"!
08-08-2009 12:04:50 -- Initiate backup for "SRVTSE" found on 192.128.10.250!
08-08-2009 12:05:00 -- SRVTSE original powerState: poweredOn
08-08-2009 12:13:45 -- Creating Snapshot "ghettoVCBg2-snapshot-2009-08-08" for SRVTSE
08-08-2009 12:13:45 -- SRVTSE has 2 VMDK(s)
08-08-2009 12:13:45 -- Backing up "datastore1 SRVTSE/SRVTSE.vmdk" to "NFS WEEKLY/SRVTSE/SRVTSE-2009-08-08/SRVTSE.vmdk"
08-08-2009 12:55:26 -- Backup completed for datastore1 SRVTSE/SRVTSE.vmdk
08-08-2009 12:55:26 -- Backing up "datastore1 SRVTSE/SRVTSE_1.vmdk" to "NFS WEEKLY/SRVTSE/SRVTSE-2009-08-08/SRVTSE_1.vmdk"
08-08-2009 14:39:29 -- Backup completed for datastore1 SRVTSE/SRVTSE_1.vmdk
08-08-2009 14:39:30 -- WARNING: Snapshot "ghettoVCBg2-snapshot-2009-08-08" not found
08-08-2009 14:39:39 -- Backup completed for "SRVTSE"!
08-08-2009 14:39:39 -- ERROR - Unable to locate VM: SRVEXCHANGE
============================== 08-08-2009 14:39:39 -- ghettoVCBg2 LOG END ==============================
Could this be a time stamp issue?
I was backing up my domain controller, and it usually only takes 2-3 minutes with no issues. I was testing a new NFS share and it took almost an hour, and had the error that it could not find the snap shot. I usually only have snap shot issues with my larger VM's that take at least an hour or more to backup.
I'm just lending my voice to state that I have experienced the same phenomenon as Al3xandr3. I haven't yet tried to determine if the order of running individual backups affects the result or if it's a specific fault of one of the VM's. I have experienced it with multiple VMs in one list and also individually listed VMs with manual starts. With all of my VM's in a single list, in order:
(1st) Win2k TS (not the assigned names, there are no spaces): OK
(2nd) Win2k3 App: Snapshot not removed. Once I found that the snapshot not only wasn't removed but also didn't show up in the VI Client to be deleted and required manual creation of a snapshot to then show 2 snapshots and deleting them then.
(etc) The rest: Backup doesn't begin
When I find the logs I'll review and post them up, hopefully correlating the same errors.
Are there any plans to add compression to this version of ghettoVCB like there is in generation 1? Compression is key to our off-site backup regimen.
ghettoVCB compression is currently at an experimental support, no plans for g2 yet. There are still some outstanding issues that I've yet had the cycles to investigate for ghettoVCBg2 and I'm hoping I'll have some time before VMworld else it'll have to be after.
Seems I am getting the same errors in the logs as Al3xandr3.
Backup log:
============================== 08-15-2009 05:27:09 -- ghettoVCBg2 LOG START ==============================
08-15-2009 05:27:09 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
08-15-2009 05:27:09 -- CONFIG - VM_BACKUP_DATASTORE = Thecus_iSCSI_BkUp
08-15-2009 05:27:09 -- CONFIG - VM_BACKUP_DIRECTORY = vMA_Backups
08-15-2009 05:27:09 -- CONFIG - DISK_BACKUP_FORMAT = thin
08-15-2009 05:27:09 -- CONFIG - ADAPTER_FORMAT = lsilogic
08-15-2009 05:27:09 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
08-15-2009 05:27:09 -- CONFIG - VM_SNAPSHOT_QUIESCE = YES
08-15-2009 05:27:09 -- CONFIG - VM_SNAPSHOT_QUIESCE = YES
08-15-2009 05:27:09 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-08-15
08-15-2009 05:27:13 -- Initiate backup for "CapServer_New" found on myESX.domain.dc!
08-15-2009 05:27:24 -- CapServer_New original powerState: poweredOn
08-15-2009 05:28:14 -- Creating Snapshot "ghettoVCBg2-snapshot-2009-08-15" for CapServer_New
08-15-2009 05:28:14 -- CapServer_New has 1 VMDK(s)
08-15-2009 05:28:14 -- Backing up "COS_Datastore CapServer_New/CapServer_New.vmdk" to "Thecus_iSCSI_BkUp vMA_Backups/CapServer_New/CapServer_New-2009-08-15/CapServer_New.vmdk"
08-15-2009 05:53:48 -- Backup completed for COS_Datastore CapServer_New/CapServer_New.vmdk
08-15-2009 05:53:50 -- Removing Snapshot "ghettoVCBg2-snapshot-2009-08-15" for CapServer_New
08-15-2009 05:54:00 -- Backup completed for "CapServer_New"!
08-15-2009 05:54:01 -- Initiate backup for "BrisSteelADS01" found on myESX.domain.dc!
08-15-2009 05:54:11 -- BrisSteelADS01 original powerState: poweredOn
08-15-2009 05:58:10 -- Creating Snapshot "ghettoVCBg2-snapshot-2009-08-15" for BrisSteelADS01
08-15-2009 05:58:10 -- BrisSteelADS01 has 2 VMDK(s)
08-15-2009 05:58:10 -- Backing up "COS_Datastore BrisSteelADS01/BrisSteelADS01.vmdk" to "Thecus_iSCSI_BkUp vMA_Backups/BrisSteelADS01/BrisSteelADS01-2009-08-15/BrisSteelADS01.vmdk"
08-15-2009 06:14:03 -- Backup completed for COS_Datastore BrisSteelADS01/BrisSteelADS01.vmdk
08-15-2009 06:14:03 -- Backing up "COS_Datastore BrisSteelADS01/BrisSteelADS01_2.vmdk" to "Thecus_iSCSI_BkUp vMA_Backups/BrisSteelADS01/BrisSteelADS01-2009-08-15/BrisSteelADS01_2.vmdk"
08-15-2009 06:31:22 -- Backup completed for COS_Datastore BrisSteelADS01/BrisSteelADS01_2.vmdk
08-15-2009 06:31:22 -- WARNING: Snapshot "ghettoVCBg2-snapshot-2009-08-15" not found
08-15-2009 06:31:37 -- Backup completed for "BrisSteelADS01"!
08-15-2009 06:31:37 -- ERROR - Unable to locate VM: CapServer2_New
============================== 08-15-2009 06:31:37 -- ghettoVCBg2 LOG END ==============================
I get "Hard power off, VMware Tools is not installed" when try to use power off before backup feature.
The tools are there and VIC says "OK" for the tools status.
Has the feature ever been tested?
Another bug?
I thought to use the power off option it as a workaround since I had never succeeded backing up "hot" due to a known bug with non-deleted snapshots, but it does not seem to work properly either.
This feature has been tested and has worked. Please provide the following pieces of information on your environment:
1) What version of ESX(i)?
2) Are you using vCenter? What version? Are you using vMotion?
3) What version of VIMA/vMA are you running?
4) Please execute the following script to verify your VMware Tools status on your VMs: getVMToolsStatus.pl
Hello,
I would like to use this nice script but I also have the problem that the first VM gets backuped, the snapshot does not get deleted and the following VMs cannot be found.
I am using VIMA 1.0.
Here are the logfiles:
Is this a valid perl statement, as I have not found an example of using it anywhere else.
line 699 - $ref = $subRef if ($subCount);
I have changed it to the following, and it look good so far.
if ($subCount) {
$ref = $subRef;
}
It's a valid Perl statement, test it out for yourself.
Here's a quick example:
[vi-admin@scofield]$ cat test.pl
#!/usr/bin/perl -w
use strict;
use warnings;
my $subCount = 1;
my $subRef = "hello world";
my $ref = "not hellow world";
$ref = $subRef if($subCount);
print $ref . "\n";
I figured the problem with VM not being powered down was in the Tools being out of date, so sorry for the false alarm.
However, now the VM does not being powered back up after the backup. Even though I can see the code is there.
The script just quits after the last VMDK backup by saying "Backup completed", but without the "LOG END".
What could be wrong?
Hey William,
First off, thanks so much for making these scripts. Between ghettoShutdown.pl and ghettoVCBg2.pl (if I ever get it working) I'll have everything I need to run ESXi without worry!
That being said... I'm having some issues with getting ghettoVCBg2.pl working
Environment Setup:
Hi William,
First of all, works great. Easy to configure and very fast free alternative.
I have a question, is it possible to have the status mailed to me.
Case of a backup error, I like to have a email.
Menno
Hi
I will try as described but i am hanging by creating a NFS-datastore in my ESXi/vMA
If I understand correctly the NFS-datastore have to be mounted on vMA (central)
But how to do ?
regards
Martin
Hi Menno,
you could pipe the cron output to mail.
Just append something like
| mail -s "ghettoVCBg2 <your vMA server>" someone@mydomain.com
at the end of the cron entry.
But this way you will get the mail everytime the cronjob runs, not just in case of errors.
@martin
You have to mount the datastore on your ESXi to backup to it.
You can do this via the vCenter.
Following Log, whats going wrong here, NFS_datastore is mounted on esxi03 !
William,
Phenomenal work and effort on this project, and thanks for all your support for the community! I have just executed a few initial trials, and like Shawn and martingreiner I am seeing a "404 Not Found due to rotation max" error. I have vMA and ESXi 3.5 build 184236 along with ghettoVCBg2.pl version 2.5.1. I was wondering if you had an idea what might be causing this error?
(debug output below):
============================== 09-17-2009 08:21:03 -- ghettoVCBg2 LOG START ==============================
09-17-2009 08:21:03 -- CONFIG - BACKUP_LOG_OUTPUT = ghettoVCBg2.log
09-17-2009 08:21:03 -- CONFIG - VM_BACKUP_DATASTORE = DSS1-bkupvm-eth4
09-17-2009 08:21:03 -- CONFIG - VM_BACKUP_DIRECTORY = ghettoVCB
09-17-2009 08:21:03 -- CONFIG - DISK_BACKUP_FORMAT = zeroedthick
09-17-2009 08:21:03 -- CONFIG - ADAPTER_FORMAT = buslogic
09-17-2009 08:21:03 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
09-17-2009 08:21:03 -- CONFIG - VM_SNAPSHOT_QUIESCE = YES
09-17-2009 08:21:03 -- CONFIG - VM_SNAPSHOT_QUIESCE = YES
09-17-2009 08:21:03 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-09-17
09-17-2009 08:21:08 -- Initiate backup for "actitime" found on 192.168.50.7!
09-17-2009 08:21:24 -- actitime original powerState: poweredOn
09-17-2009 08:21:24 -- actitime has 1 VMDK(s)
09-17-2009 08:21:24 -- Backing up "DSS1-bond0 actitime/actitime.vmdk" to "DSS1-bkupvm-eth4 ghettoVCB/actitime/actitime-2009-09-17/actitime.vmdk"
09-17-2009 08:21:30 -- Backup completed for DSS1-bond0 actitime/actitime.vmdk
09-17-2009 08:21:30 -- WARNING: Snapshot "ghettoVCBg2-snapshot-2009-09-17" not found
09-17-2009 08:21:34 -- Unable to purge "DSS1-bkupvm-eth4 ghettoVCB/actitime/GET https:192.168.50.7folderghettoVCBactitime?dsName=DSS1-bkupvm-eth4 unsuccessful : 404 Not Found" due to rotation max
09-17-2009 08:21:34 -- Backup completed for "actitime"!
09-17-2009 08:21:34 -- ERROR - Unable to locate VM: operator
============================== 09-17-2009 08:21:34 -- ghettoVCBg2 LOG END ==============================
Hi All,
I have been hacking this script to find out what the problem is with the snap shots not being deleted and have changed the call from the internal function to the external script snapshotmanager.pl.
#&remove_snapshot($vm_view, $snapshot_name, $vm_name);
my $res = `/home/vi-admin/bin/snapshotmanager.pl -server vc1 --operation remove --vmname $vm_name --username ******* --password ******** --snapshotname $snapshot_name --children 0`;
print LOG timeStamp('MDYHMS'), "Remove Snapshot $snapshot_name from VM $vm_name with results: $res";
This has been on my to-do list, I'm wondering if the connection eventually times out while it's executing the backup ... I have few others that are running into the same issue with removing the snapshot, but I haven't had a chance to replicate the issue. Drop me your email via VMTN PM and I'll send out an email this weekend regarding the next steps and perhaps a live support chat.
Thanks for your patience
I had this error and traced it (via perl debugger) to the 'restricted version' error. I had the script working perfectly and all of a sudden it stopped with a message like yours. Turns out that while I was evaluating the product it allows writeable CLI. I never used the script for a while, but sometime later I grabbed free licenses and applied it to all of my ESX4i servers. I'm guessing that this is what has changed the CLI to be read-only and therefor ghetto no longer works ! Can anyone confirm this ?
<RANT>
If this is true then I will for sure be moving all my servers over to Xenserver 5.5 sure it has restrictions also but none as ridiculous as ESXi and the read only CLI. It does have Xenmotion (like vmotion) Xencenter (like vcenter) and a writeable CLI unlike the 'free' ESXi.
</RANT>
Take a look at this article for your answer: http://vmetc.com/2009/03/31/esxi-u4-ends-free-version-read-and-write-access-from-the-rcli/
The API was never meant for full read/write, this was a bug in VMware's code between U2 and U3 which was remediated in U4 and subsequent release in vSphere. I can understand where VMware's coming from, though I may not agree ... but you pay for you what you get. You still have the ability to use the unsupported SSH console for automating various set of tasks and licensed version of ESXi gives you more than just vCLI access and that is what makes them a leader in this space.
Good luck.
Thanks William,
I had read the article previously and it did not specifically mention ESX4i. I suppose I am disappointed because your excellent script worked during the evaluation and now it doesn't.
I have enabled 'tech support' mode on all 3 servers but I fear that it too one day soon will disappear.
The article was published well before vSphere came out, but again this was an internal bug that VMware had and the API was never intended to be free (both read/write), so once this was fixed it would be the case for ESXi 4.0 as well.
Take a look at this comparison chart for the various licensing versions: http://www.vmware.com/products/vsphere/buy/editions_comparison.html as you can see even the simplest licensed version provides much value added than just full r/w access to the API.
Regarding the unsupported console in ESXi, it's VMware's direction to go to the ESXi platform and eventually the classic ESX will no longer be around ( I wouldn't hold my breath anytime soon, but eventually). They may eventually remove the Busybox console as well but again, it'll take time but enjoy it for now.
Hi William,
when i run the script, i get the following output:
hi, I suppose the script can't write to the directoy or to the logfile you specified.
Try /tmp/ghettoVCB2.log that should work.
regards,
Martin
I wanted to give an update to everyone that may be using this script.
The issues that have been mentioned are being actively worked on, as you know I do support many many other scripts and there's only so many hours in each day I do assure you, I've not forgotten about you guys/gals and the issues being reported. I do ask for you patience and I'll provide an update as soon as I have one.
Stay tuned ...
Hi all here!
I/We have 3 ESX4 machines with a shared SAN datastore (all machines can see all SAN datastores). One machine has a "big" Local Storage and I want to backup remote VMs to the Local Storage using SAN, not over a network. Is it possible to configure ghettoVCBg2 to backup VMs this way?
Hi everyone,
I'm currently in development (as time permits) on some new features for the ghettoVCBg2 script and I'm looking for some individuals that may be interested in taking part in a BETA. The requirement is pretty simple, willing to help test and provide feedback on the next version of the script (remember to test on non-production VMs)
If you're interested, please PM on VTMN with your email address and the script you would like to take part in and I'll be selecting a group users and send out email notification in the coming weeks.
Thanks
When i make a backup from a big VM with 300-500 GB, the VM does not get started automatically after backup prozess.
What could be the matter of this? With smaller VMs it works.
This is a known issue with larger VMs and will be fixed in a future release.
OK, thank you for the fast answer.
Do you already know what causes this issue? Maybe i can fix it byself.
Nope the solution is actually pretty complicated, we're pretty much there but requires further testing which will be part of the BETA. I won't go into further details, if you're already emailed me then you'll know in the coming weeks if you're one of the few few to be on the BETA.
Thanks for your patience.
All right, i´ve sent you already an email last week for taking part in the BETA. I would help you willingly.
Hi,
I'm using ESXi 4.0, have a few virtual machines running, and trying to get the backup done. The thing is that I created all virtual machines with Thin disks. However, there are in all those VM's two vmdk's, one called <machinename>-flat.vmdk, and one called <machinename>.vmdk. When I do some filecopying and rename the <machinename>.vmdk to <machinename>.vmdk.old and the <machinename>-flat.vmdk to <machinename>.vmdk the backup seems to work, although I cannot find the backupfiles somewhere on my system. See the attached logs, can anybody help me out?
============================== 10-21-2009 15:44:02 -- ghettoVCBg2 LOG START ==============================
10-21-2009 15:44:02 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
10-21-2009 15:44:02 -- CONFIG - VM_BACKUP_DATASTORE = datastore1
10-21-2009 15:44:02 -- CONFIG - VM_BACKUP_DIRECTORY = backup
10-21-2009 15:44:02 -- CONFIG - DISK_BACKUP_FORMAT = thin
10-21-2009 15:44:02 -- CONFIG - ADAPTER_FORMAT = lsilogic
10-21-2009 15:44:02 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
10-21-2009 15:44:02 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
10-21-2009 15:44:02 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
10-21-2009 15:44:02 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-10-21
10-21-2009 15:44:07 -- Initiate backup for "TS3" found on 192.168.72.113!
10-21-2009 15:44:14 -- TS3 original powerState: poweredOn
10-21-2009 15:44:14 -- TS3 has 1 VMDK(s)
10-21-2009 15:44:14 -- Backing up "datastore1 TS3/TS3.vmdk" to "datastore1 backup/TS3/TS3-2009-10-21/TS3.vmdk"
10-21-2009 15:44:18 -- Backup completed for datastore1 TS3/TS3.vmdk
10-21-2009 15:44:18 -- WARNING: Snapshot "ghettoVCBg2-snapshot-2009-10-21" not found
10-21-2009 15:44:19 -- Unable to purge "datastore1 backup/TS3/GET https:192.168.72.113folderbackupTS3?dsName=datastore1 unsuccessful : 404 Not Found" due to rotation max
10-21-2009 15:44:19 -- Backup completed for "TS3"!
============================== 10-21-2009 15:44:19 -- ghettoVCBg2 LOG END ==============================
============================== 10-21-2009 16:00:29 -- ghettoVCBg2 LOG START ==============================
10-21-2009 16:00:29 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
10-21-2009 16:00:29 -- CONFIG - VM_BACKUP_DATASTORE = datastore1
10-21-2009 16:00:29 -- CONFIG - VM_BACKUP_DIRECTORY = backup
10-21-2009 16:00:29 -- CONFIG - DISK_BACKUP_FORMAT = thin
10-21-2009 16:00:29 -- CONFIG - ADAPTER_FORMAT = lsilogic
10-21-2009 16:00:29 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
10-21-2009 16:00:29 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
10-21-2009 16:00:29 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
10-21-2009 16:00:29 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-10-21
10-21-2009 16:00:35 -- Initiate backup for "TS3" found on 192.168.72.113!
10-21-2009 16:00:42 -- TS3 original powerState: poweredOff
10-21-2009 16:00:42 -- TS3 has 1 VMDK(s)
10-21-2009 16:00:42 -- Backing up "datastore1 TS3/TS3.vmdk" to "datastore1 backup/TS3/TS3-2009-10-21/TS3.vmdk"
10-21-2009 16:00:45 -- Backup completed for datastore1 TS3/TS3.vmdk
10-21-2009 16:00:47 -- Backup completed for "TS3"!
============================== 10-21-2009 16:00:47 -- ghettoVCBg2 LOG END ==============================
I'm not exactly sure what you're trying to do? Was the backup successful? Are you saying that you executed a backup of 1 VM (TS3) and after the backup, you manually renamed the files on the ESX(i) host? From the looks of the log, you should have your backup VM stored in /vmfs/volumes/backup/TS3/TS3-2009-10-21/ and note that if you browse your datastore using the vSphere Client that the *-flat.vmdk will not display, only the descriptor.
Hi,
First I tried to do a backup, just of the VM TS3. That resulted in the following:
============================== 10-21-2009 15:44:02 -- ghettoVCBg2 LOG START ==============================
10-21-2009 15:44:02 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
10-21-2009 15:44:02 -- CONFIG - VM_BACKUP_DATASTORE = datastore1
10-21-2009 15:44:02 -- CONFIG - VM_BACKUP_DIRECTORY = backup
10-21-2009 15:44:02 -- CONFIG - DISK_BACKUP_FORMAT = thin
10-21-2009 15:44:02 -- CONFIG - ADAPTER_FORMAT = lsilogic
10-21-2009 15:44:02 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
10-21-2009 15:44:02 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
10-21-2009 15:44:02 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
10-21-2009 15:44:02 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-10-21
10-21-2009 15:44:07 -- Initiate backup for "TS3" found on 192.168.72.113!
10-21-2009 15:44:14 -- TS3 original powerState: poweredOn
10-21-2009 15:44:14 -- TS3 has 1 VMDK(s)
10-21-2009 15:44:14 -- Backing up "datastore1 TS3/TS3.vmdk" to "datastore1 backup/TS3/TS3-2009-10-21/TS3.vmdk"
10-21-2009 15:44:18 -- Backup completed for datastore1 TS3/TS3.vmdk
10-21-2009 15:44:18 -- WARNING: Snapshot "ghettoVCBg2-snapshot-2009-10-21" not found
10-21-2009 15:44:19 -- Unable to purge "datastore1 backup/TS3/GET https:192.168.72.113folderbackupTS3?dsName=datastore1 unsuccessful : 404 Not Found" due to rotation max
10-21-2009 15:44:19 -- Backup completed for "TS3"!
============================== 10-21-2009 15:44:19 -- ghettoVCBg2 LOG END ==============================
The backup directory was still empty. So, i tried to get info via Google, and saw something about two VMDK-files. So, I thought probably I can rename the TS3-flat.vmdk to TS3.vmdk. I did (made a saveset first) and then the second run:
============================== 10-21-2009 16:00:29 -- ghettoVCBg2 LOG START ==============================
10-21-2009 16:00:29 -- CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
10-21-2009 16:00:29 -- CONFIG - VM_BACKUP_DATASTORE = datastore1
10-21-2009 16:00:29 -- CONFIG - VM_BACKUP_DIRECTORY = backup
10-21-2009 16:00:29 -- CONFIG - DISK_BACKUP_FORMAT = thin
10-21-2009 16:00:29 -- CONFIG - ADAPTER_FORMAT = lsilogic
10-21-2009 16:00:29 -- CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = NO
10-21-2009 16:00:29 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
10-21-2009 16:00:29 -- CONFIG - VM_SNAPSHOT_QUIESCE = NO
10-21-2009 16:00:29 -- CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2009-10-21
10-21-2009 16:00:35 -- Initiate backup for "TS3" found on 192.168.72.113!
10-21-2009 16:00:42 -- TS3 original powerState: poweredOff
10-21-2009 16:00:42 -- TS3 has 1 VMDK(s)
10-21-2009 16:00:42 -- Backing up "datastore1 TS3/TS3.vmdk" to "datastore1 backup/TS3/TS3-2009-10-21/TS3.vmdk"
10-21-2009 16:00:45 -- Backup completed for datastore1 TS3/TS3.vmdk
10-21-2009 16:00:47 -- Backup completed for "TS3"!
============================== 10-21-2009 16:00:47 -- ghettoVCBg2 LOG END ==============================
Still the backup directory was empty, but the log seems successfull. Can you point me in the right direction?
Regards,
Bas
BETA email invitations will be going out this weekend ... keep an eye out
I have installed this wonderfull script. Keep up the good work!
I am having trouble with crontab. My crontab (vi-admin) looks like:
vi-admin@vma ~$ crontab -l
0 0 * * * /home/vi-admin/ghettoVCBg2.pl --config_dir /home/vi-admin/backupConfigs --vmlist /home/vi-admin/virtual_machne_back_list_belangrijk
0 10 * * 7 /home/vi-admin/ghettoVCBg2.pl --config_dir /home/vi-admin/backupConfigs --vmlist /home/vi-admin/virtual_machne_back_list
0 5 * * 1-5 /home/vi-admin/ghettoVCBg2.pl --config_dir backupConfigs --vmlist /home/vi-admin/virtual_machne_back_list_branderweg
But cron doesn't run it at all. Did I missed something? When I use the lines at the shell the commands make great backups.
a tail of /var/log/cron gives:
vi-admin@vma ~$ sudo tail /var/log/cron
Password:
Oct 23 00:01:01 localhost crond14745: (root) CMD (run-parts /etc/cron.hourly)
Oct 23 01:01:01 localhost crond14987: (root) CMD (run-parts /etc/cron.hourly)
Oct 23 02:01:01 localhost crond15229: (root) CMD (run-parts /etc/cron.hourly)
Oct 23 03:01:01 localhost crond15471: (root) CMD (run-parts /etc/cron.hourly)
Oct 23 04:01:01 localhost crond15713: (root) CMD (run-parts /etc/cron.hourly)
Oct 23 05:01:01 localhost crond15955: (root) CMD (run-parts /etc/cron.hourly)
Oct 23 06:01:01 localhost crond16224: (root) CMD (run-parts /etc/cron.hourly)
Oct 23 07:01:01 localhost crond16466: (root) CMD (run-parts /etc/cron.hourly)
Oct 23 08:01:01 localhost crond16708: (root) CMD (run-parts /etc/cron.hourly)
Oct 23 08:26:49 localhost crond2074: (CRON) STARTUP (V5.0)
Why cron isn't running my backups?
I am trying to backup vms in an ESX4 host that has mostly SAN based storage to an ESXi server with local storage over the network to a remote location. It's not clear to me whether I need to mount an NFS store on the ESX4 host or if the store still needs to be visible to the ESX4 host or if the vMA should take care of this as long as it is listed as being managed by the vMA. Do I still need to mount the NFS store manually on each ESX4 host so that $VM_BACKUP_DATASTORE that I'm backing up to is visible to that individual ESX4 host?
I think I'm just confused on the syntax for the datastore or how the script works with vMA, I verified that both hosts are being managed by vMA with sudo vifp listservers and I have tried several different names for the $VM_BACKUP_DATASTORE value. Everything in the logs says the backup completes but on the ESX4 host it keeps saying invalid datastore specified so it is clear it doesn't know what datastore I am trying to backup to. I have also tried specifying the ESXi server that I am trying to backup to with the --server command option but doesn't seem to make a difference.
I’ve tried several different values and no luck.
my $VM_BACKUP_DATASTORE = "/vmfs/volumes/backups";
my $VM_BACKUP_DATASTORE = "https://172.16.x.x/folder?dcPath=ha-datacenter&dsName=backups";
my $VM_BACKUP_DATASTORE = "172.16.x.x/folder?dcPath=ha-datacenter&dsName=backups";
my $VM_BACKUP_DATASTORE = "172.16.x.x";
Thanks again for all your work any help is apprieciated!
The NFS datastore MUST be mounted on the ESX(i)host and must be visible to the host, vMA will instruct the various operations using the vSphere API to perform the backup to the NFS datastore or to any valid datastore for that matter.
Your syntax is for VM_BACKUP_DATASTORE is incorrect, you apparently did not go through the documentation throughly. The entry should just be the name of your datastore (e.g. datastore1)
If your NFS datastore is mounted on the ESX(i) host as backups then variable VM_BACKUP_DATASTORE should be set to backups
I would recommend going over the documentation and read through it carefully as much of your questions can be answered.
Thanks
Thank you that helps alot!
I have a VM with a virtual RDM. When I run the script, it immediately says 'WARN - RDM was found for (vmname), backup will not take place.' The comments in the code seem to indicate that this is normal, though the 'features list' above says they're supported. Any advice?