Category Archives: VMWare

Solutions and work I have done with VMWare products.

Poor Man’s Virtual Machine Backup with PowerCLI (Updated)

This post is based on this wonderful script I found by Hugo Peeters of the Netherlands. His original script available here fit exactly what I was looking for. I already had “in-guest” VM-Backups. We did have a solution that would do virtual machines but it caused us nothing but grief.

I thought if I could just find a way to copy the  .vmx files, I could do a restore at our DR site from backup. I searched online and finally found Peeters’ script.

I tried it out but I ran into errors. I’m not sure what version of PowerCli his script was based on but it no longer worked with the latest one available.

New-PSDrive : Cannot bind parameter ‘Datastore’ to the target. Exception setting “Datastore”: “Invalid location type. Location accepts only VIDatastore objects.”

This failing command was stored as a function in a powercli in one of it’s library files.
New-DatastoreDrive was the function that was failing. It was calling New-PSDrive. Something about how it was being called it no longer liked. I found a working version.

Note: Prep work

As noted in the script, you can store your .vmx files in a subfolder. You have to use the same subfolder name in Windows and on your datastore. The one on your datastore will have to be manually created (for now.)


I actually run this as a scheduled task through a .bat file via task scheduler.
Here is what I put in my batch file:

C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe -PSConsoleFile “C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1″ ” &  “C:\Scripts\Backup-VMXFileRemote\Backup-VMXFilesRemote.ps1”


The restore process is a bit interesting (at either your main site or your backup site.)

  1. Create a new folder on your datastore with the name of your vm
  2. Copy your VM’s .vmx file into that folder
  3. Right-click and add .vmx to Inventory
  4. Update your nic to match the VM network if its not the same
  5. I have no .vmdk’s when I do this. I have to delete the hardrive’s from the config.
  6. Open the vmconfig.csv file that is stored with the .vmx copies. This will give you the size of HD(s) you will need.
  7. Create new hardrives in order of what is listed in the vmconfig.csv file
  8. Boot your vm with your restore media.

Download the updated script here (and rename it to .ps1): Backup-VMXFilesRemote

The virtualization of a working SCO Unix box.

(Note: This is from a doc I created years ago from my hospital job. It was a fun challenge and I’m glad my persistence paid off.)

I have already converted a working Mandrake Linux box to a VM so doing the conversion of a SCO Unix box seemed to be a breeze. Not quite.

Some of my techniques did work and that is where I started. I booted the system with a Ghost boot disk. I have access to a Ghost server so I used that to create a ghost image file.  If you have Ghost, so you should be fine to convert to a file on a separate hardrive.

I created a VM with a drive as big as the one that physical box had. Whether you allocate the space now is up to you and how much performance you require.  Now the task is to apply that ghost image to the drive. I keep a Windows based “Helper VM” around for just such purposes. I have tried using a ghost boot disk with mixed success. For that reason, I prefer to use Ghost32 in Windows. I have had imaging freeze up using DOS based boot disks.

Before booting up my helper system, I attach the vmdk file from the VM I created earlier. I don’t move the file.  I browse to the new VM folder and use it from there. Once I boot up the Helper VM, I use Ghost32 to apply the .gho image of the Linux box to the second drive. Once the imaging is done, shutdown the Helper VM. To avoid error messages later, remove the second drive from the Helper system.

Of course with the VM system you are trying to create, you want to make sure you add any non-standard devices you need such as COM ports and Parallel ports.  Also, I tried to keep the memory size the same. When booting up the Mandrake system, it seemed more like my curious cat in a new house. I thought it wouldn’t work because it’s on new hardware. Instead, it just keep noticing new devices and prompting to install them. With Mandrake, the only real task I had to do was to configure the former systems’ TCPIP settings on the new AMD Pcnet family NIC it now had. I rebooted and the machine was pingable and our apache based page worked just fine from my windows system.

SCO Unix was a different story. I did the same method for the SCO box but with quite different results. The system started booting and stopped at a Boot: prompt. I pressed enter and the system started up displaying some memory errors. Things got worse, as the system stopped dead with a Kernel Panic and a second Double Panic message.

I searched around and found a page with some SCO notes. I found out about this command for the memory problems:


I entered it at the Boot: prompt and the memory errors went away. The kernel panics didn’t. 

Research on the error message didn’t give me any concrete leads.  I thought perhaps the differences between the hardware was the biggest factor.  I thought I could borrow a Windows trick and try installing SCO Unix over the existing VM. This wouldn’t work as none of the old settings stuck.

Looking deeper into what was out there, the “repair” method really involves a fresh install and restoring from a backup. I didn’t have much viable options. The old system had a tape drive but that wasn’t much of an option as I cant use that with a VM. The graphic interface’s backup program offered either a 3.5″ floppy disk or a 5 ¼” floppy disk. Not very attractive option with a 6.4 gig drive! There were options to remote to a backup system. I got to learn about setting up rlogin to login as root on a remote system sans password. This was needed for the remote backup to work. This remote option would either work with the floppies or any tape drives.  If someone tries it, the tape option might work but I never had the chance. The tape drive was defective. I had hoped to back up locally to the physical boxes tape drive and remotely restore from it on the VM. Back to the drawing board as the cliché goes.

I thought if I could at least recreate the kernel panic on the physical box, I would be much farther ahead. The physical system had a scsi card for the tape drive. I tried removing the scsi card and I got the same panic.  Great! I put the card back in. Now to see how to make the physical box forget about the scsi card. I learned about a command called hwconfig (.scsi_cdrom) and used that to remove the only scsi device listed which was a cd-rom drive (it didn’t have one). I removed it anyway thinking maybe it treated the tape drive as such. I booted again with the tape drive disconnected and no panic. I doubt the CDROM part mattered. I did find information online about removing devices. I mostly had to know the name of the device.

When SCO Unix starts, you see the device name as it starts each one. I simply checked what came after the point that the VM crashed. The device name I saw was ALAD. In the example I got, the main trick was to navigate to where the startup device files are.  I had to use Vi to change the Yes column in this file (required) to a No. Now after a lengthy shutdown process, I tried booting again without the SCSI card. Success! No errors at all.

This meant I had to recreate my Ghost image and my virtual disk. The VM booted without a problem this time.

Like with Mandrake, I need to configure the new nic.