VMware Communities : Document List - vSphere Management Assistant (vMA)

Folks,

The intention of this document is to list third party agents / scripts that work with vSphere Management Assistant.

If you are a third party software vendor, or anyone with an interesting script that you have tested on vSphere Management Assitant, please add to the list below. The benefit is that the community will be able to determine and quickly see if your agent runs on vMA. This is very much a community effort and look for your help in maintaining this list.

Product Name	Owner	Link	vMA Compatible Version
VMware Health Check Report v0.9.4	William Lam	VMware Health Check Report v0.9.4	VIMA 1.0
VMware vSphere Health Check Report v1.2	William Lam	VMware vSphere Health Check Report v1.2	vMA 4.0
ghettoShutdown.pl/upsVIShutdown.pl	William Lam	ESX/ESXi APC/APCUPSD Host Shutdown VI Perl Toolkit Script (ghettoShutdown.pl/upsVIShutdown.pl)	VIMA 1.0
ghettoVCBg2	William Lam	ghettoVCBg2 - Free alternative for backing up VMs in ESX(i) 3.5 and 4.x (no SSH console required!)	vMA 4.0

takeVMScreenshot.pl using vMA 4.0

Wed, 12 Aug 2009 05:30:33 GMT

Ever run into issues with your VMs where you have some debugging information logged to the console and you want to take a screenshot of it using vSphere API?

Requirement
ESX(i) 4.0 (must execute against individual ESX(i) host and not vCenter)
vMA 4.0

Sample Execution:

[vi-admin@scofield ~]$ ./takeVMScreenshot.pl --server himalaya.primp-industries.com --username root --vmname William-XP
Enter password:

Initiating screenshot of William-XP ...
Successfully capture screenshot from William-XP!
Downloading "William-XP-screenshot-0.png" to "vm_screenshots/William-XP-screenshot-0.png"
Removing screenshot "William-XP-screenshot-0.png" from ESX(i) host ...

Here is what William-XP-screenshot-0.png looks like:

Hot add memory to vMA or other supported Linux guestOSes using vSphere ESX(i) 4.0

Sun, 09 Aug 2009 18:47:36 GMT

Summary

This document will demonstrate how to hot add memory to a live running vMA (RHEL5) VM using vSphere ESX(i) 4.0, this feature is only supported on certain guestOSes, check vSphere documentation for more information.

Resources

http://adaptivethinking.wordpress.com/2009/07/27/vsphere-esx4-hot-add-memory-for-linux-guests/

Requirements

ESX(i) 4.0
vMA 4.0 or other supported Linux guestOSes

Instructions

1. Hot add memory requires a VM to be running hardware version 7 and since vMA 4.0 by default is distributed as HW4, you'll need to first right click on the VM and upgrade to hardware 7 before powering on the VM. You will also need to enable hot add memory which is a new configuration item once you've upgraded to HW7 under OPTIONS->Memory/CPU Hotplug and just select 'enable'

2. Power on vMA

3. Let's verify the default memory available within vMA (this can be done using free,/proc/meminfo,top,etc)

[vi-admin@vMa-resize ~]$ free -m
             total       used       free     shared    buffers     cached
Mem:           498        178        320          0          6         98
-/+ buffers/cache:         73        425
Swap:         1023          0       1023

[vi-admin@vMa-resize ~]$ cat /proc/meminfo m
MemTotal:       510668 kB
MemFree:        327696 kB
Buffers:          6740 kB
Cached:         101200 kB
SwapCached:          0 kB
Active:         110392 kB
Inactive:        43864 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       510668 kB
LowFree:        327696 kB
SwapTotal:     1048568 kB
SwapFree:      1048568 kB
Dirty:              24 kB
Writeback:           0 kB
AnonPages:       46340 kB
Mapped:          43704 kB
Slab:            12584 kB
PageTables:       2408 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   1303900 kB
Committed_AS:   222648 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    263328 kB
VmallocChunk: 34359474423 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

Default installation of vMA 4.0 is 512mb of memory, we'll increase this to 1gb

4. You will now use the vSphere Client and edit the vMA's memory and change it from 512mb to 1gb

5. Download and copy online_hotplug_memory.sh to vMA

[root@vMa-resize ~]# chmod +x online_hotplug_memory.sh

6. Execute the script which will find any new memory allocated to vMA and online the memory

[root@vMa-resize ~]# sudo ./online_hotplug_memory.sh
Found sparsemem: "/sys/devices/system/memory/memory0" ...
        memory0 already online
Found sparsemem: "/sys/devices/system/memory/memory1" ...
        memory1 already online
Found sparsemem: "/sys/devices/system/memory/memory2" ...
        memory2 already online
Found sparsemem: "/sys/devices/system/memory/memory3" ...
        memory3 already online
Found sparsemem: "/sys/devices/system/memory/memory4" ...
        memory4 is new memory, onlining memory ...
Found sparsemem: "/sys/devices/system/memory/memory5" ...
        memory5 is new memory, onlining memory ...
Found sparsemem: "/sys/devices/system/memory/memory7" ...
        memory7 is new memory, onlining memory ...

As you can see from the script output memory0-3 was already allocated and split up but memory4-7 was the newly added memory which needed to be brought online before the OS can use it.

7. Let's verify the new memory that has been allocated while the VM was running

[root@vMa-resize ~]# free -m
             total       used       free     shared    buffers     cached
Mem:           882        188        694          0          7        100
-/+ buffers/cache:         80        802
Swap:         1023          0       1023

[root@vMa-resize ~]# cat /proc/meminfo
MemTotal:       903884 kB
MemFree:        711128 kB
Buffers:          7644 kB
Cached:         102612 kB
SwapCached:          0 kB
Active:         111996 kB
Inactive:        45060 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       903884 kB
LowFree:        711128 kB
SwapTotal:     1048568 kB
SwapFree:      1048568 kB
Dirty:              36 kB
Writeback:           0 kB
AnonPages:       46836 kB
Mapped:          43708 kB
Slab:            12748 kB
PageTables:       2460 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:   1500508 kB
Committed_AS:   224736 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    263628 kB
VmallocChunk: 34359474423 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

How to increase/resize vMA Disks

Sat, 08 Aug 2009 22:46:54 GMT

Summary:

If you're extensively using vMA's vi-logger functionality or storing lots of content on the default 5gb VMDK, you can easily fill up the disks. This document will provide the steps in resizing and increasing the disk sizes using LVM.

Environment:

vMA 4.0 or VIMA 1.0 (not testing on VIMA 1.0, but steps should be exactly the same)
SSH and/or vSphere Client console access

Operation:

Increase /var/log from 500MB to 10GB

Steps:

1. Here is a default vanilla installation of vMA

Last login: Sat Aug  8 15:00:31 2009 from 172.30.0.225

Welcome to vMA
run 'vma-help' or see http://www.vmware.com/go/vma4 for more details.

[vi-admin@vMa-resize ~]$ cat /etc/vima-release | head -1
vMA 4.0.0 BUILD-161992

[vi-admin@vMa-resize ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                      3.3G  1.5G  1.7G  48% /
/dev/mapper/VolGroup00-var
                      496M   19M  452M   4% /var/log
/dev/sda1              99M   16M   79M  17% /boot
tmpfs                 250M     0  250M   0% /dev/shm

2. Notice /var/log has total of 452MB free and I will attempt to fill it up to 98%

[vi-admin@vMa-resize ~]$ sudo dd if=/dev/zero of=/var/log/big_ass_file bs=1M count=440
440+0 records in
440+0 records out
461373440 bytes (461 MB) copied, 9.64461 seconds, 47.8 MB/s

[vi-admin@vMa-resize ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                      3.3G  1.5G  1.7G  48% /
/dev/mapper/VolGroup00-var
                      496M  461M  9.9M  98% /var/log
/dev/sda1              99M   16M   79M  17% /boot
tmpfs                 250M     0  250M   0% /dev/shm

OH NO! /var/log is full, what to do! Let's increase the size of /var/log to 10GB, that should be plenty for logs.

3. Shutdown the vMA and edit the VM configurations and change the disk from 5gb to 15GB (increase of 10GB)

[vi-admin@vMa-resize ~]$ sudo shutdown -h now

4. Power back on vMA

5. As you can see we've grown the virtual disk from 5gb to 16gb

[vi-admin@vMa-resize ~]$ sudo fdisk -l
Password:

Disk /dev/sda: 16.1 GB, 16106127360 bytes
255 heads, 63 sectors/track, 1958 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14         652     5132767+  8e  Linux LVM

6. Next we'll be creating a new partition with the new space

[vi-admin@vMa-resize ~]$ sudo fdisk /dev/sda

The number of cylinders for this disk is set to 1958.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 3
First cylinder (653-1958, default 653):
Using default value 653
Last cylinder or +size or +sizeM or +sizeK (653-1958, default 1958):
Using default value 1958

Command (m for help): t
Partition number (1-4): 3
Hex code (type L to list codes): 8e
Changed system type of partition 3 to 8e (Linux LVM)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Note: The options were: n,p,3,<enter>,t,3,8e,w

7. We now verify the new partition has been created:

[vi-admin@vMa-resize ~]$ sudo fdisk -l

Disk /dev/sda: 16.1 GB, 16106127360 bytes
255 heads, 63 sectors/track, 1958 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14         652     5132767+  8e  Linux LVM
/dev/sda3             653        1958    10490445   8e  Linux LVM

/dev/sda3 is our new partition which has been formatted with LVM, we now need to reboot vMA before continuing.

vi-admin@vMa-resize ~]$ sudo reboot

8. We need to add a physical volume before LVM can access the partition

[vi-admin@vMa-resize ~]$ sudo pvcreate /dev/sda3
  Physical volume "/dev/sda3" successfully created

9. Now we need to extend the existing volume group to the physical volume which was found by doing (df -h)

[vi-admin@vMa-resize ~]$ sudo vgextend VolGroup00 /dev/sda3
  /dev/hda: open failed: No medium found
  Volume group "VolGroup00" successfully extended

10. Now we'll want to extend the logical volume into the new space, but we want to make sure how much the system will give us in terms of free space

[vi-admin@vMa-resize ~]$ sudo vgdisplay | grep -i free
  Free  PE / Size       320 / 10.00 GB

As you can see, that is the additional 10GB we've added on top of the already existing 5GB

11. Now we extend the LV to /var and not to another mount point and we'll increase that to 10GB

[vi-admin@vMa-resize ~]$ sudo lvextend -L+10G /dev/VolGroup00/var
  Extending logical volume var to 10.50 GB
  Logical volume var successfully resized

12. Last step is to make this space available to the OS, on general RHEL systems you have access to ext2online but since vMA is a stripped down version of RHEL, that is not available. We'll make uses of resize2fs to accomplish the same task

[vi-admin@vMa-resize ~]$ sudo resize2fs -p /dev/VolGroup00/var
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/VolGroup00/var is mounted on /var/log; on-line resizing required
Performing an on-line resize of /dev/VolGroup00/var to 11010048 (1k) blocks.
The filesystem on /dev/VolGroup00/var is now 11010048 blocks long.

Note: This task can take a few minutes depending on the disk size increase

13. Now we verify the new disk increase for /var/log for 10GB

[vi-admin@vMa-resize ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-root
                      3.3G  1.5G  1.7G  48% /
/dev/mapper/VolGroup00-var
                       11G  462M  9.2G   5% /var/log
/dev/sda1              99M   16M   79M  17% /boot
tmpfs                 250M     0  250M   0% /dev/shm

voilà! you've just increased the disk space on the default installation of vMA.

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

Thu, 23 Apr 2009 04:36:49 GMT

Description:

This tool is the follow up release of the ghettoVCB backup utility which allows users to perform backups of virtual machines residing on ESX(i) 3.5+/4.0+ servers using methodology similar to VMware's VCB tool. By incorporating highly constructive feedback from the VMware community and utilizing the existing VI API, ghettoVCB’s framework was completely rewritten to be harder, better, faster, stronger.

The primary motivation for ghettoVCBg2 was to provide ESXi users with access to the utility without relying on unlocking and utilizing the unsupported console. To satisfy this requirement, the rebuilt framework takes advantage of the VI Perl Toolkit/vSphere SDK for Perl which is present in the VIMA/vMA virtual appliance provided by VMware. As a result, ghettoVCBg2 provides a more proper backup solution that administrators can utilize in their virtual infrastructure.

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

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

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

Features

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

Requirements:

VMs running on ESX(i) 3.5u2+ or ESX(i) 4.x+
VMware VIMA 1.0 or VMware vMA 4.0

ESX/ESXi Version Support Table

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

Setup:

1) Download ghettoVCBg2.pl to your VIMA 1.0/vMA 4.0 system

2) Change the permissions on the script to ensure it can be executed:

[vi-admin@scofield ~]$ chmod +x ghettoVCBg2.pl

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

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

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

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

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

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

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

Configurations

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

Defining the datastore in which the backups are stored:

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

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

my $VM_BACKUP_DIRECTORY = "WILLIAM_BACKUPS";

Defining the backup rotation per VM:

my $VM_BACKUP_ROTATION_COUNT = "3";

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

my $DISK_BACKUP_FORMAT = "zeroedthick";

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

my $ADAPTER_FORMAT = "buslogic";

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

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

my $POWER_VM_DOWN_BEFORE_BACKUP = "0";

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

Note: By default both are disabled

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

Defining the detail of logging (verbose or normal):

my $LOG_LEVEL = "normal";

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

VM_VMDK_FILES="myvmdk.vmdk"

Experimental Support Configs:

Note: Port 25 by default

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

Ensure that you do not edit past this section:

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

Usage:

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

Synopsis: ./ghettoVCBg2.pl OPTIONS


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

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

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

--dryrun

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

--output

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

--config_dir

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

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

Provided is a sample of what the file should contain:

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

Sample Execution

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

Backup VMs located in a list

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

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

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

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

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

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

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

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

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

VIMA

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

vMA-2

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

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

[vi-admin@scofield ~]$ mkdir backup_config

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

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

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

Listing of VM backup policy within backup configuration directory

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

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

(e.g.)
--config_dir backupConfigs

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

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

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

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

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

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

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

Execution of backup

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

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

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

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

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

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

Dry run Mode (no backup will take place)

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

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

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

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

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

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

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

FAQ

1Q: 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…
1A Ensure the ESX/ESXi host is being managed by VMware VIMA/vMA ( sudo vifp listservers to verify)

2Q: 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?
2A: Please provide the entire output of a manual execution (debug & dry run mode) or if you're logging the output withing \{code\} tags, a short description of your environment and the type of VM(s) you're trying to backup—I will try to provide some assistance.

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)

6Q: 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?
6A: 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.

7Q: I’m pissed; the backup is taking too long. My datastore is of type X?
7A: YMMV, take a look at your storage configuration and make sure it is optimized.

8Q: I noticed that the backup rotation is occurring after a backup. I don't have enough local storage space, can the process be changed?
8A: 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.

9Q: What is the best storage configuration for datastore type X?
9A: Search the VMTN forums; there are various configurations for the different type of storage/etc.

10Q: I want to setup NFS Server to run my backups. Which is the best and should it be virtual or physical?
10A: 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.

11Q: When I try to use the script I get an error stating: "restricted version". What the heck is this?
11A: Please take a look at the ESX/ESXi Version Support Table in this document. The reason is explained here.

12Q: 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?
12A: 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.

13Q: 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?
13A: 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.

14Q: I would like to restore from backup, what is the best method?
14A: 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).

15Q: 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?
15A: 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.

16Q: In vMA 4.0, vCenter target will be supported, can I just add vCenter target and assume this will work?
16A: 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).

17Q: When I try to run the script I get: "-bash: ./ghettoVCBg2.pl: Permission denied", what is wrong?
17A: You need to change the permission on the script to be executable, chmod +x ghettoVCBg2.pl

18Q: Where can I download the latest version of the script?
18A: The latest version is available on this page at the bottom. To get the version of the script run ./ghettoVCBg2.pl --version

Change Log

11/18/09 - New variable "EMAIL_DOMAIN" was added for email log functionality as email domain must be defined or left as default "localhost.localdomain". Thanks to adrian888 for finding this bug

my $EMAIL_DOMAIN = "localhost.localdomain";

11/17/09 - The following enhancements and fixes have been implemented in this release of ghettoVCBg2. Special thanks goes out to Gerhard Ostermann for assisting with some of the logic in the ghettoVCBg2 script and the rest of the ghettoVCBg2 BETA testers. Thanks for everyones time and comments to make this script better!

Enhancements:

Email log support
Include/exclude specific VMDK(s)
Additional logging + dry run mode

Fixes:

Independent disk aware
Large VMDK backups

VI Remote CLI 3.5 Update 2

Tue, 21 Apr 2009 18:45:25 GMT

Remote CLI commands allow you to perform many of the operations you might currently perform using the ESX 3 service console. You can use Remote CLI commands in scripts that run on ESXi 3.5 and ESX 3.5 hosts. Remote CLI commands are especially useful for an ESXi host because ESXi does not include a service console.

Links for VMware Infrastructure Remote Command‐Line Interface (Remote CLI) version 3.5 Update 2:

ESX/ESXi APC/APCUPSD Host Shutdown VI Perl Toolkit Script (ghettoShutdown.pl/upsVIShutdown.pl)

Mon, 16 Feb 2009 08:51:14 GMT

Description

Many parties have looked for the possibility of monitoring power continuity and subsequently reacting to power outages with information supplied by a UPS agent installed in a virtual machine running on a free version of ESXi. Currently, one free solution How to configure ESXi to shutdown using an APC SmartUPS created by Joseph Holland facilitates shutdown/suspend procedures for online virtual machines in the event of a power outage given that there is some type of physical UPS system in place to provide backup power to the ESXi server. Joseph’s solution utilizes VMware VIMA and the open source utility apcupsd however, one needs to enable the unsupported SSH console in ESXi and setup paired SSH keys between VIMA and host to utilize it. Enabling the unsupported SSH console may not be the preferred method for some end users with respect to their support contracts held with VMware.

The following solution outlined in this document is similar to Joseph’s work although it will not necessitate enabling the unsupported SSH console on the ESXi hosts. This is made possible by utilizing the VI Perl Toolkit to communicate with the ESXi hosts. The only possible drawback however is that next revision of ESXi may disallow write operations and require that the user purchase ESXi license(s) to make full use of the VI API (read/write).

It must be pointed out that this implementation is built on top of initial findings made by Joseph Holland (APC VIOPS documentation) and Andrew Sullivan (VMware VIMA VI Fastpass disection). Please do visit Andrew’s blog at get-admin. Thanks to Duncan Epping for nudging the challenge via Twitter ...

Note: Please ensure proper testing has been performed in a staging or development environment prior to implementing this solution in a production environment.

Requirements

ESX/ESXi 3.5+
VMware VIMA
VI Perl Toolkit (included in VIMA)
APC SmartUPS or other "smart" UPS (may require another monitoring utility)
apcupsd-3.14.5-1.el5.x86_64.rpm (VMware VIMA is 64bit RHEL VM)

Usage

[vi-admin@vima-ups-dev ~]$ ./ghettoShutdown.pl
Required command option 'ups_vm' not specified.

Synopsis: ./ghettoShutdown.pl OPTIONS


Command-specific options:
   --sleep
      The amount of time (secs) to wait after a guestOS shutdown (default 15 secs)
   --ups_vm (required)
      The name of VM that is monitoring your UPS

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

Overview of the scripts:

ghettoShutdown.pl - This script initiates the shutdown of all VM(s) within an ESX/ESXi host excluding the virtual machine that's monitoring the UPS device and then shutdowns the host. It accepts two commandline parameters: --sleep the duration in seconds to wait after a VM has initiated the shutdown before moving onto the next VM (shutdownVM() is non-blocking function) and --ups_vm the name of the displayName of your VM that is monotiring the UPS device [more details to come later].

upsVIShutdown.pl - This script is a wrapper which will hold the configurations of the order of hosts to shutdown. It may be used inconjunction with other UPS monitoring utility, though with our example, it'll be placed in the apccontrol script to execute upon a power interuption.

Scenario

2 ESXi 3.5u3 (free unlicensed edition):

superion.primp-industries.com
SQL-PROD-01	Powered On
Quentin	Powered Off
air_raid	Powered On
skydive	Suspended
fireflight	Powered Off
slingshot	Powered On

devastator.primp-industries.com
VIMA-UPS-DEV	Powered On
bonecrusher	Powered Off
master_mix	Suspended
quickMigrate-X	Powered Off
scavenger	Suspended
hook	Powered On
long_haul	Powered On

Simulate a power interuption and initiate shutdown of superion and it's VM(s) then devastator and its VM(s) using VMware VIMA: VIMA-UPS-DEV. (note, due to the lack of our UPS being configured, this will be a simulation of the UPS utility initiate the shutdown)

Since the script is written using the VI Perl Toolkit, this potentially could function on a Windows VM installed with the VI Perl Toolkit but you will not able to use VI Fastpass for authentication and credentials will need to be passed to ghettoShutdown.pl via the execution.

Setup

1. Ensure your ESX/ESXi host(s) are being managed by VMware VIMA

2. Download ghettoShutdown.pl and save to /home/vi-admin and make sure it has executable permissions set (chmod +x ghettoShutdown.pl)

3. Download upsVIShutdown.pl and save to /home/vi-admin and make sure it has executable permissions set (chmod +x upsVIShutdown.pl)

4. Edit the following sections in upsVIShutdown.pl:

A) Insert your ESX/ESXi host(s), use the hostname that you used to add to VIMA managment interface, if you're unsure run sudo vifp listservers

Remember to make sure the host that is running your VIMA VM is listed as the last entry.

my @hosts = ("superion.primp-industries.com","devastator.primp-industries.com");B) Modify the logoutput of the shutdown process if you like, default will go to /tmp/upsShutdown.log

my $log_output = "/tmp/upsShutdown.log";C) Insert the displayName of VIMA or VM that is monitoring your UPS device (case sensitive)

Very important step else you could end up shutting down the VM that is executing this script, we wouldn't want that

my $ups_vm_name = "VIMA-UPS-DEV";D) Insert the number of seconds to delay after a guestOS has initiated to be shutdown, this will vary depending on the type of applications the VM(s) may be running, tweak this value as needed.

Note, the shutdownVM() is a non-blocking function, if you set the delay to be too short the host could be powered down before the VM(s) have completed powering off (default 15 secs)

my $sec_to_sleep = 15;Next, you'll want to install the apcupsd client on your VMware VIMA host with the following command:

sudo rpm -ivh apcupsd-3.14.5-1.el5.x86_64.rpm

You'll then need to configure your apcupsd.conf and you use the following document

Next, instead of setting up a SSH paired keys and inserting the ssh command in /etc/apcupsd/apccontrol, you'll be appending the following:

doshutdown)
	echo "UPS ${2} initiated Shutdown Sequence" | ${WALL}
	/home/vi-admin/upsVIShutdown.pl 
	${SHUTDOWN} -h now "apcupsd UPS ${2} initiated shutdown"
;;

I don't think the 3rd line is really ncessary since the VM will be on the same host that'll be shutting down.

Sample output

1. We'll now manually initate the upsVIShutdown.pl script as if a power interuption was detected by apcupsd client.

[vi-admin@vima-ups-dev ~]$ ./upsVIShutdown.pl

2. As you can see from above...nothing too fancy, though the process has been kicked off and both host(s) and their VM(s) have been powered down in the order of our configuration file. To verify the output, we will power on our hosts, log into VIMA-UPS-DEV (the VM that initiated the shutdown process) and inspect the logs containing the shutdown process at /tmp/upsShutdown.log.

[vi-admin@vima-ups-dev ~]$ cat /tmp/upsShutdown.log
04-25-2008 11:17:52 -- Found ESX/ESXi host: superion.primp-industries.com!
        04-25-2008 11:17:52 -- Begin shutdown process ...
        04-25-2008 11:18:07 -- VM: slingshot shutdown succssfully.
        04-25-2008 11:18:22 -- VM: air_raid shutdown succssfully.
        04-25-2008 11:18:37 -- VM: silverbolt shutdown succssfully.
        04-25-2008 11:18:37 -- VM: skydive is already suspended.
        04-25-2008 11:18:37 -- VM: fireflight is already off.
        04-25-2008 11:18:44 -- VM: SQL-PROD-01 hard poweroff succssful (No VMware Tools, bad admin).
        04-25-2008 11:18:44 -- VM: Quentin is already off.
        04-25-2008 11:18:44 -- HOST: superion.primp-industries.com is shutting down!

04-25-2008 11:18:49 -- Found ESX/ESXi host: devastator.primp-industries.com!
        04-25-2008 11:18:49 -- Begin shutdown process ...
        04-25-2008 11:18:49 -- VM: scavenger is already suspended.
        04-25-2008 11:18:49 -- VM: bonecrusher is already off.
        04-25-2008 11:18:49 -- VM: master_mix is already suspended.
        04-25-2008 11:18:56 -- VM: scrapper hard poweroff succssful (No VMware Tools, bad admin).
        04-25-2008 11:19:04 -- VM: long_haul hard poweroff succssful (No VMware Tools, bad admin).
        04-25-2008 11:19:11 -- VM: hook hard poweroff succssful (No VMware Tools, bad admin).
        04-25-2008 11:19:11 -- VM: quickMigrate-X is already off.
        04-25-2008 11:19:12 -- Shutting down final host: devastator.primp-industries.com and UPS VM: VIMA-UPS-DEV!
==============================================================================================

VMware Communities : Document List - vSphere Management Assistant (vMA)

Getting Started with the vMA (tips/tricks)

Getting started with Documentation:

Examples

Scripts and Tools

Tweaks

vMA Compatible Agent/Scripts(Third Party) Community List

takeVMScreenshot.pl using vMA 4.0

Hot add memory to vMA or other supported Linux guestOSes using vSphere ESX(i) 4.0

Summary

Resources

Requirements

Instructions

How to increase/resize vMA Disks

Summary:

Environment:

Operation:

Steps:

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

Table of Contents:

Description:

Features

Requirements:

ESX/ESXi Version Support Table

Setup:

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

Configurations

Usage:

Sample Execution

Backup VMs located in a list

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

Dry run Mode (no backup will take place)

FAQ

Change Log

VI Remote CLI 3.5 Update 2

ESX/ESXi APC/APCUPSD Host Shutdown VI Perl Toolkit Script (ghettoShutdown.pl/upsVIShutdown.pl)

Description

Requirements

Usage

Overview of the scripts:

Scenario

Setup

Sample output