VM /ETC

Posts Tagged ‘script’

One of the advantages of running virtual machines (VMs) on shared storage is that if you need to rebuild your ESX host(s) you won’t lose your VMFS volumes or the VMs. But, what if you can’t VMotion evacuate the VMs to another host with extra capacity first? This scenario means the VMs will no longer be registered on an ESX host once you are finished. Importing VMs with the datastore browser is simple enough, but what if you have hundreds of VMs to import? Manually importing that many VMs will take hours.

Luckily, the built-in ESX console command vmware-cmd with the -s option allows you to mass import VMs via some simple scripting. Ed Haletky pointed this out to me via Twitter, and then Duncan Epping tweeted me a post of  his that contained the following batch script he used for mass VM imports in slightly different scenario :

for i in `find /vmfs/volumes/ -name "*.vmx" `
do
echo "Registering VM $i"
vmware-cmd -s register $i
done

To use the above code save it as a text file with a .sh extension. For example “importvms.sh”. Place the file on anywhere on your ESX host and then as root run

#./importvms.sh

updated 3.12.09 – My Softchoice colleague, Michael Cocat out of our Chicago office, modified the original script above to work when spaces exist in the VM (and .vmx) name. Michael also likes to run the script as a single line entry on the ESX Console. Here’s the updated command in single line format:

find /vmfs/volumes -name “*.vmx” | while read LINE; do echo “registering VM $LINE”; vmware-cmd -s register $LINE

updated 3.12.09 – I also want to point out that this script will not place the VMs back in Resource Pools or Folders. The VMs are imported into the root of the object tree because the resource pool and folder information is not stored in the .vmx file. Once you have the VMs back registered with the ESX server you can simply drag and drop them into resource pools and folders again. Thanks to Jason Boche for bringing this up, and pointing out it is not really a fully automated recovery process. It is still a much better alternative to manually importing each VM with the datastore browser which will prompt you for Resource Pool and VM folder placement.

To find out more about the vmware-cmd options and switches check out

http://www.vmware.com/support/esx21/doc/vmware-cmd.html

and

http://www.esxguide.com/esx/content/view/2/25/

health_check.sh script report .html

If you are looking for a free and quick method to document your ESX 3.0.X  and ESX 3.5 server configurations without installing a scripting environment then don’t forget about A. Mikkelsen’s ESX Healthcheck script. An oldie but still a goodie, this script is simply transferred to your ESX 3.5 Console and then just run manually or via a scheduled job. The end result is a .html report that is saved on your ESX host, or if you utilize the optional send_smtp.pl script the report can be mailed to you automatically.

I’m not providing any new information in this post. In fact I am way behind  as Duncan Epping has covered this script on his blog at Yellow-bricks.com. Duncan first posted about the esx healthcheck script in January 2008 and recently mentioned it again in his post about his tools he uses when conducting customer Healthcheck services. The comments thread on Duncan’s January post walk through a year’s worth of feature development and support.

Download your copy of the script at  SourceForge.net: ESX Healthcheck Script

Once downloaded, the .zip file contains several helpful text files along with the script. The rest of this post walks through the install and configure steps and then explains how to run the script when ready. Read the rest of this entry »

New in the latest version of ESX 3.5 is an experimental Service Console script called the VMDK Recovery Tool. Since it’s Console based, it’s not available in ESXi. The Update 3 Release Notes say the following about it:

Experimental Support for the VMDK Recovery Tool — This release adds support for the VMDK Recovery tool, a script intended to help customers to recover VMFS/vmdk data stores from accidental deletion of VMFS/vmdk data store or physical disk corruption. For more information, see VMDK Recovery Tool (ESX 3.5 Update 3) ( KB 1007243).

Use the VMDK Recovery Tool to:

Create a “block list” of your VMDK files. The block list file is a plain text file that keeps a record of all VMDKs of the virtual machines.

Recover VMDK files if they become deleted, or if the VMFS datastore gets deleted or corrupted.

Undelete VMDKs? Recover corrupted or deleted VMFS data stores? Reading KB 1007243 a little further reveals you can back up and restore VMs too – either specify which one you want to back up or pick all the registered VMs on the host. The script asks you to specify the directory path to use for saving backups and the destination path for restoring from backups.

Sounds to me like this script could become a “super VCB” without the extra server requirements? It seems much simpler anyways. It will be interesting to see how this script is developed and exactly how much disk space the block list and backup files consume.

If you run the free VMware Server on a Linux host then VMTN Communities user phxrider has created a couple of scripts that can make your life a little easier. Phxrider’s clone and rename scripts automate the process of two administrative tasks that are frankly a burden to do manually. Both VMware Server 1.x or 2.0 do not offer any template or cloning abilities from their respective GUI interfaces, so these scripts are an essential tool to have if you want to duplicate VMs or change the VM’s files to match a renamed directory.

Check out either http://communities.vmware.com/docs/DOC-8050 or the VMTN Forum thread at http://communities.vmware.com/thread/168266 to download the scripts. Here’s some brief info from these links:

“The clone script does a straight clone of a VM. It copies the directory, renames the files and tweaks all the text inside the files by using sed to replace the old name with the new one, then sets all the permissions to what they would be if you created a new VM.

The rename script basically does all but copy it. This is handy for if you tried to rename a directory manually or attempted a manual copy and then found it still shows up under the old name in the web console. Remember this one assumes you have already renamed the directory to the new name and it MUST be the same as what you intend for the new name to be.

Both work the same way… scriptname <old name> <new name>”

I am not aware of equivalent scripts for VMware Server hosted on Windows, but if they exist please leave a comment with a link for VM /ETC readers.

The rest of this post is my example of using the clone_vm.sh script to make a template for future VMware Server 2.0 VM cloning. Read the rest of this entry »

I missed Mike DiPetrillo’s Deploying VMware in a Microsoft Shop session at VMworld 2008, but Mike apparently provided a PowerShell example of automating the migration of an Ubuntu VM between ESX hosts without using VMotion. This script would be a great alternative to a cold migration for VI Foundation customers. Mike has now posted his script and a video of a demo on his blog.

From the VMware Field: Mike D’s Virtualization Blog: Quick Migration for VMware – The Power of PowerShell shows off the script and flirts with comparing this ability to the Microsoft Hyper-V Quick Migration feature.

“One of the things that was also brought up over and over again in the debate was the fact that Quick Migration was free and came with Hyper-V since it was based on Microsoft Clustering whereas VMware VMotion was only available in the most expensive Enterprise SKU of VMware Infrastructure. So there it was – I need to create Quick Migration for the lower priced and free VMware solutions. I went off, built my little script, and showed it off at VMworld. There was a GREAT response to it so I’m posting it here for others to use or improve upon however you see fit.

The script works just like Microsoft Quick Migration – the virtual disk is stored on shared storage, the VM is suspended to disk, and the VM is then resumed on the destination.”

Mike provides the various requirements and the links later in his post.

To set this up in your environment you’ll need a few things:

Read the rest of this entry »

Last week I had a customer ask me for help with a repetitive administrative task that is extra aggravating for shops with a lot of Linux virtual machines (VMs). The customer was frustrated with the manual process of upgrading VMware Tools after kernel upgrades in their VMs. It’s a problem unique to Linux since the Windows operating system kernel does not change very frequently, but the development cycle of several Linux distributions can mean multiple kernel versions each year. After each upgrade and subsequent VM reboot the VMware tools must be re-installed so the tools are compiled correctly with the new kernel. Not exactly fun to do when you have a lot of Linux VMs.

I suggested 2 alternatives for the customer. The first is a scripted solution configured inside each Linux VM and the second is a built in feature of VirtualCenter and ESX for versions 2.0.1 and 3.0.1 or greater. I have not tested either of these solutions. My reason for writing this post is partly to explain the options, but also to get some feedback from the community. Let me know if you use or have tried either of these solutions or anything similar. If there is a better way please comment on this post! If you try one of these for your Linux virtual guests let me know what works and what doesn’t.

The following methods require that VMware tools are already installed in the Linux guests. For instructions for installing the tools check out the current VMware .pdf guide titled Basic System Administration Update 2 Release for ESX 3.5, ESXi version 3.5, VirtualCenter 2.5. if you are wondering if you should even install VMware tools in Linux guests than check out my post “Why do I need to install VMware Tools?”. Read the rest of this entry »

If you are running VMware Server on a Linux host and need to automate and schedule a process for backing up your guests then check out Two Bald Geeks’ bash script documented in the post at vmware-server VM backups. In short, the vmsbackup script systematically cycles through all VMs in a designated folder and accomplishes a full guest backup for each. To do this the script suspends the VM, copies it to another location, tars the copied file, removes any existing tars older then a specified time period, and then resumes the source VM again. Creating a Cron job for the script enables the process to be repeated on a scheduled basis.

Here’s some more information taken from the linked post on the strategy behind the script. Read the rest of this entry »