JDPFu.com 2024

Why Batch Program?

A batch program lets 1-click control complex tasks. Batch is easier to understand for many people, me included, than an XML settings file. Batch cmds don’t need to run and eat RAM/CPU when the specific task isn’t needed. When you want something to happen once a day, like backups, then you probably want a batch program instead of running a GUI tool continuously.

MS-Schedule – Why Not?

The interface to MS-Schedule is ugly and FireDaemon Pro is just US$50, easy to use and highly capable with pre/post task setups. I’m the last person who wants to waste money when it isn’t necessary, but in these days of $1000 tools, it doesn’t make much sense to deal with a bad interface when a good one is just $50.

Fire Daemon

Installed for all users on the system. The license is shared across the system. After I failed to get things working under MS-Schedule, it was an easy decision to spend the $50 for Fire Daemon Pro. When that failed to work, we contacted the support team and they responded saying that nothing in the log file appeared to be at issue.

Trilead VM Explorer Tips

I like VM/Explorer, also known as vmx.exe or VMX. It is significantly more cost effective than the other options. Backups run quickly too (70MB/s). There is much to like in this tool, but even after getting it working, tying in the controlling batch program to run specific backups on specific days was not trivial due to a simple mistake made without much consideration on the first day. We never got it working through MS-Schedule, but when it did not work, we quickly purchased FireDaemon and moved forward. On to the tips.

1. Use IP addresses for connectivity. In an MS-Windows shop, DNS may not be configured in a way that is friendly for VMware or other UNIX-like operating systems to be able to resolve easily. That was the case here too. Much of the configuration worked, until it was time to run a backup. The backup appeared to start and connect, but then failed. Connectivity issues should be all or none, otherwise the end users will believe that connectivity is working perfectly. We had to contact Trilead support about this after setting the /etc/hosts files to be identical on VMS1, VMS2 and the backup Windows Server that ran VMX. Support said – use IP addresses, not DNS names. Fortunately, the tool configuration required just a change in 1 place for each VMWare ESX server and it was just an edit to the prior settings. Nice.
2. Use a Service Account since the VMX license key seems to be tied to a user, not the system. This required a few days to figure out. We had been using a personal account to setup and test the VM Explorer software. In our testing, we always fully specified the path to either VMX.exe or to the batch program. The batch program did not need to run from any specific director to work. The batch called the command line interface for VMX and always performed the way we wanted when double clicked.
3. Export the VMX configuration XML file and back it up when you think everything is working. A nice backup of this file can be imported later to bring a new user or different backup machine up and configured quickly. When the configuration is restored, it will attempt to connect to the VMware ESX systems and validate the VMs there. If they do not exist, be careful since you may lose that data.
4. Install the Trilead license Key File, configure and test while logged in as the specific userid who will be running the backup job from the scheduling tool (Fire Daemon in our case). This is critical for scheduled backups to work.

Just to clarify, the command line use of VM Explorer only works in the paid or 30 day trial version, not the free version. Scheduling does not work in the free version either, but we aren’t using that feature at all.

What I’d Change about VM Explorer

For the price, this is a very good tool, but there are a few things that I’d like to see changed.

1. License installation should be per-server, not per-user. This burned my team for a few days. The lack of a valid license for the specific userid was not displayed in an error log or any of the requested log files.
2. When the tool is run with command line options, no GUI should be displayed. There should be an option for no GUI to be displayed. This is very important for all server-based enterprise tools, like a backup tool.
3. More cmd line examples of how to run the program should be included in both the FAQ and User Manual from Trilead. Concrete examples would save a few hours of trial and error for new users.
4. Import of the XML configuration file should have an option to completely replace the config or to simply add all the settings to the existing configuration. Having a complete replacement, which is the current default, really is nice, however.
5. Compression should be enabled for both transfers and backup storage by default, not as an option buried on the 4th tab of the 3rd-level window.
6. Complete control the any VM backup from the command line without any setup is needed. Sometimes the tool is for a single purpose even when the tool has many, many other features. I would have preferred to not have any settings inside VM Explorer at all. I’d like to control everything from the command line interface, including all the connection settings for each VM-Server and where the backups are placed. I do not plan to ever use the built-in scheduler due to the limitations that it has. A few limitations:
   1. The configuration for each VM to be backed up must be created inside VMX, manually. There is no batch method to perform this.
   2. For a scheduled task controlled by VMX to run, VMX must be running, always. Effectively, this means the tool must run 24/7/365 even if only 1 event every 24 hours is desired.
7. Even with the configuration set to retain only 1 backup older backups created with different storage details were not removed when they were in the same storage tree. For example,
   VM-Server:DatastoreXX/{VMNAME}/{DATESTAMP} is the normal setup for backups placed within VMWare ESX Datastores, but that can be overridden to a slightly shorter path by removing the {DATESTAMP} portion. Clean up of older backups should automatically remove any old backups under the {VMNAME} too.
8. Logging would be better and more clearly state when an error happens and the possible causes for the error.
9. The VMX FAQ should cover more common issues so support interaction isn’t needed.
10. The VMX User Manual is a little thin and it should cover more example uses and specific known issues so support interaction isn’t required. The tool does have 2 specific common issues solved in the Help menu, unfortunately, neither of them helped with the 3 issues we experienced.

Many of my ideas come from my UNIX background and expectations. For a server application, I have an expectation that it can be run without a GUI. That is clearly not the background of the VMX developers.

Some Example VM Explorer Commands

I figured I could help some others jump start their learning on using vmx.exe from the command line. Here’s a trivial example in a batch program – bak-cm-server.cmd is the filename and it doesn’t matter what the CWD or start in setting is for this to work.

SET VMX_CMD="C:\Program Files (x86)\Trilead\Trilead VMX\VMX.exe"
SET LOG_DIR="D:\backups\log"

SET VM_MACHINE=CM-Server
%VMX_CMD%  /runtask:%VM_MACHINE% /logfile:"%LOG_DIR%\%VM_MACHINE%.xml"
@echo ===INFO: Logfile: %LOG_DIR%\%VM_MACHINE%.xml

Inside VMX, CM-Server has to be setup as a scheduled backup task, but it should remain as paused unless you intend to use the scheduler, not the batch program to control backups for this VM. (Paused) should appear next to CM-Server in the Scheduled Tasks list. Each VM will need to be configured individually.

The ideas here are applicable to vSphere 4.x deployments too.

What Was Setup For This Client

I installed and configured 2 commercial tools to backup VMware ESX virtual machines without taking the VM down.

• Zero downtime was important to this client.
• Data used by the 15+ different VMs was already stored in storage locations that were backed up using Veritas Netbackup to tape, so the purpose of my engagement was to backup with virtual machines, applications, and settings with minimal or zero downtime.
• A weekly backup was deemed to be sufficient for each VM. The client determined which VMs needed to be backed up on which days.
• Nominal testing showed between 10 and 20 minutes was needed for each VM and performing disk-to-disk backups was desired.
• Netbackup would then take the disk backup and spool that off to tape using daily, weekly and monthly tape rotation schedules.
• Daily emailed backup reports are requested by the batch program after all the backups for the day have completed.
• A backup all VMs batch program was also provided to the client. It was based on the more complex daily backup, but simplified.

Here’s the call tree for how the different pieces are invoked. FireDaemon → Batch.cmd → VMX.exe

• FireDaemon calls a specific batch program once every 24 hours – every day. Nothing is complex, just 1 program called daily. Simple. We like simple.
• The batch program acts as the VM backup controller and calls VMX with specific options based on the day of the week. Inside the batch program, different VMs are backed up on different days. Due to current tape backup schedule concerns, less than 30 minutes per day, except on Sunday, are available for VM disk-to-disk backups to be performed. The batch program is called once and then calls VMX with options for each VM to be backed up that day. See the sample call above, but be aware that the real batch program is slightly more complex, while still being easily modified by the end client to tweak or add additional VMs to be backed up. The client will not need me to maintain this. It is simple.
• VMX has the backup configuration for each VM. This config is specified on the command line when the program is called from the Batch.cmd.
• Validation of the backup was performed. Backing things up are 10% of the work. Restoring everything is the remaining 90%. A backup is worthless without being able to restore it. Simple.