About
You arrived at the weblog of Geert Baeke. I am a technology consultant for a company called Xylos (Belgium). I mostly work with Microsoft technologies such as Windows, Active Directory, Exchange, Sharepoint, MSCS, and more. I am also actively busy with VMware's products, focussing on VMware ESX.

Search





Sections
Networking
View Geert Baeke's profile on LinkedIn

Services

RSS Newsfeeds
baeke.info Main RSS Feed Main Page RSS
Virtual Machines RSS Feed Virtual Machines RSS
XBOX 360
View Article  Create new VMWare virtual machines with a batch file

When I need to create new virtual machines (for a test lab for instance), I do not want to spend a lot of time on deployment. For customers who use VMWare GSX without VirtualCenter, I use a simple batch file to roll out virtual machines automatically.

Before you can use the batch file, you need a sysprepped virtual machine. This article presumes that you know how sysprep works. On the virtual machine's disk, c:\sysprep\sysprep.inf will be the answer file that provides all answers to the mini-setup wizard. The mini-setup is run when you deploy the virtual machine and start it for the first time. You should make mini-setup fully unattended.

Of course, I want to provide the computername automatically during deployment. In the sysprep.inf file, do not fill in a computername behind Computername=. So the  [UserData] section should be like:

[Userdata]
...
Computername=
...

When the machine has been sysprepped and is shutdown, you have a template to create other machines from. In the template directory, you should modify the vmx file as required. You should remove the displayName entry because we will set the display name during deployment. You should also remove uuid settings so VMWare can create a new uuid for your new virtual machines automatically without asking questions.

So suppose you have a template directory e:\vm\W2003Template. The directory has two files: w2003.vmdk and w2003.vmx.

To create a new virtual machine based on this template, I use the batch file with one parameter: the name of the new virtual machine. For instance:

deploy.cmd w2003srv

The batch file contains some variables that point to the template directory, the directory where new virtual machines should be created and so on...

The batch file then does the following things:

  • A new folder called w2003srv is created under a directory you specify in the batch file.
  • The w2003.vmx file from the template is copied to the new folder (e:\vm\w2003srv) as w2003srv.vmx.
  • The displayName is set inside w2003srv.vmx to w2003srv.
  • The w2003.vmdk file is copied from the template directory to the new folder.
  • w2003.vmdk is mounted on V: and v:\sysprep\sysprep.inf is modified. Computername= is replaced with Computername=w2003srv.

To replace Computername= with something else, I used munge.exe from one of the Windows resource kits. Munge requires a munge script. That is just a file with one line that contains the value to search and replace. The munge script is created by the batch file.

To mount a vmdk on a drive letter, I used vmware-mount.exe. This is a download from the VMWare site.

That's it. You now have a new virtual machine based on a specific template. The computername of this virtual machine is automatically set in sysprep.inf. When you start the new vm and mini-setup is fully automated, the new machine will be up and running without having to provide answers to the setup process.

This is a very simple solution and was created out of need. It could be further enhanced by using VMWare APIs to automatically add this virtual machine to the inventory, maybe start the virtual machine automatically after creation, and so on. Maybe next time!

UPDATE: well, what about providing the information to register and start the virtual machine now? It is really easy, thanks to the sample vmware-cmd script that VMWare provides. That script can be found in c:\Program Files\VMware\VMware VmPerl Scripting API. Check the attached reg-start.cmd for a sample script that registers and starts a vm automagically.

2 Attachments
View Article  GUI VMX/VMDK builder

Check out this site for a GUI front-end to create vmx and vmdk files for VMWare. This is ideal when combined with the free VMWare player!

The cool thing about it is that it allows you to create a vmdk file (disk) as well. There is no need to use other tools to do that (qemu for instance). Or no need to download pre-made disk files from the web. Great stuff.

View Article  Testing Invirtus

A few days ago, I blogged about a tool called VM Optimizer from Invirtus (http://www.invirtus.com). Today, I downloaded an eval version to check how it works.

I must say that it works very well. I did not have older and bigger VMWare images available because my external USB disk has crashed. And of course, I did not have a backup.

I did have a newly created VM with a disk file that was about 4,5 GB in size. After running VM Optimizer, the size came down to 1,4 GB. After compression, I had a zip of around 700 MB. This makes VMs so much more portable for distribution to colleages. It may also solve my storage problems because I have many VMs to play with.

This tool is really a great way to optimize the size of your virtual disks. To me, it works way better than the native shrink tools provided by VMWare and Microsoft. Highly recommended!!!

View Article  Short evaluation periods: use VMWare to fix that

You know how it goes. You download a piece of software that you would like to evaluate but after you install it you don't have the time to actually do the evaluation. 15 or 30 days later, you can start from scratch.

In some cases, eval software comes with a license that always ends at a certain date. Sure, you can ask for another license from the vendor, but that's annoying.

Well, when you test time-bombed software in VMWare, there is something you can do: always start a VM at a certain time and prevent time synchronization with the VMWare tools.

Just add these settings to your vmx file:

tools.syncTime = "FALSE"
tools.synchronize.continue=FALSE
tools.synchronize.restore=FALSE
tools.synchronize.resume.disk=FALSE
tools.synchronize.shrink=FALSE
rtc.startTime=1131148800

The key parameter here is rtc.startTime. That parameters sets the virtual CMOS TOD (time of day). The number you see in this example sets the CMOS TOD to November 5, 2005. The number 1131148800 is an amount of seconds since January 1, 1970. When you start up the virtual machine, the clock is set to the time specified. Each time you restart the machine, the time will be set to the time specified.

Of course, don't leave your virtual machine running for the duration time of the evaluation.

Obviously, this won't work for all types of evaluations. It also might pose problems if you need multiple virtual machines like a member server and a domain controller.

 

Login
User name:
Password:
Remember me 
This Month
December 2005
Sun Mon Tue Wed Thu Fri Sat
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Powered by BlogHarbor
Powered by BlogHarbor
StatCounter