If you’re like us, you purchased “workload” licenses from Platespin/Novell and deployed your Portability Suite server. This server housed your Migrate and Protect jobs. But with v9 you can no longer house Protect and Migrate on the same server:

NOTE: As of the current release, PlateSpin Migrate and PlateSpin Protect are separate products, no longer packaged as editions of PlateSpin Portability Suite, and cannot be collocated on the same host.

Well, that sucks. Now I need two servers to do the same thing that I’ve been doing with one. And licensing? Well, let’s just say that after some mild brain damage I’m engaging Novell to help me through how we’re going to split these things up. As for the upgrade you can supposedly just upgrade in place – run the installer and Platespin will utilize your existing database instance. But if you activated all your licenses first for both Protect and Migrate, you’ve now got them all tied up for one product or the other (assuming you’re using local SQL. I haven’t even checked into using an external database server for this as I didn’t even think to do so).

Once I’ve got this sorted out I hope to post up more about the latest version – in lab testing, it seems to be a small step forward for Windows, but a much larger leap for Linux migrations.

Good for you! You’ve successfully finished a clone of your server’s physical hard drive(s), and the conversion process is almost done. BUT: At anywhere between 94% and 99%, the VMWare Converter console shows a failed conversion at reconfiguring your target virtual machine. So you switch to your VM and try to just power it on: BSOD. What now?

So, here’s something to check:

• Is the boot.ini file for this server correct? Does it point to the correct boot partition for your server?

Yup, it probably does. If you’re cloning from your physical server to the same drive letters and partitions, you’re probably looking at a SCSI driver problem. Sometimes, more often with Windows 2000 conversions, Converter fails to inject the correct driver for Windows 2000 to recognize it’s hard drives on booting up as a virtual machine. So, how to fix it?

You’ve got a couple of options: mount the .vmdk file in another virtual machine and copy the driver by hand to the c:WINNT or c:WINDOWS folder of your problem VM’s disk. Or, as I’ve learned to enjoy using if you have to do this repeatedly, you build a boot CD that does a lot of the work for you.

Following this guide at RTFM Education, you can create a very useful boot CD using BartPE Boot-CD, the correct VMWare drivers you’ll need, and a couple of “Fix-VMSCI” tools. It’s fairly simple:

1. Create the boot CD – you’ll want this ISO to keep around. Make sure to include the Fix-VMSCI tools.
2. Boot your failed VM with this CD.
3. When the WinPE environment comes up, simply run through the tools on the Start menu – these will automatically do things like fix your boot.ini and assign the correct partition to boot to. But most importantly for you at this moment in time, it’ll allow you to inject the correct SCSI driver into the VM’s Windows directory.

If you’re reading this right now with a client breathing down your neck, waiting for that VM to be up – I feel for you. But take some time, get this boot CD built up, and keep it around for a long-term fix when you (inevitably) run into this issue again.

For a free product, I’ve got to say this is an amazing piece of software and pretty bombproof if some basic steps are taken to maximize the chances of success with using it.¬† I hope to outline some basic steps you can take in order to up those chances, focusing on Windows 2000 and 2003. I can tell you I wish I had known a lot of this info previously when having performed some other clones…

Tip 1: Perform Live Migrations

The best way to perform P2V is by installing Converter on the source machine itself, then running the conversion while the operating system is up and running. So, a general process for this would be:

1. Install VMWare Converter on your source machine.
2. Reboot if necessary (Windows 2000) and then shut down all non-essential services.
   Shut down database servers, antivirus, the print spooler, Network Neighborhood, scheduled tasks, and so on. The point here is to get this Windows machine to the basics: server process, network connectivity, and the VMWare Converter services.
3. Start Converter and point it at the target VM host.
   Feel free to change disk parameters on the fly – you’ll find that if you’ve got a partitioned disk, you might want to break out those partitions to separate .vmdk files for better performance.

Tip 2: Remove Hardware-Specific Software Once the Conversion is Done

If you’re doing this process on a server, chances are you’ve got utility programs on there that are designed to interface with hardware that’s not going to be available on the VM. Some examples are IBM Director, Intel ProSet, and HP iLO and RAID array management tools. Keep in mind that I work on Compaq, IBM, and HP devices for the most part – post up any tips for Dell hardware if you have ‘em.

• If you have access to IBM’s support site, they make a utility called “dirclean” that helps to remove IBM Director, which oftentimes fails to uninstall.
• Intel offers a ProSet Uninstaller utility to help with removing ProSet – another utility the oftentimes fails to uninstall.
• Uninstall all HP utilities, including HP networking utilities.
  Go to the properties of an Ethernet connection, highlight the HP Networking Utility, and choose “Uninstall.” Reboot to complete.
• Even if you’ve uninstalled everything HP, get rid of any HP system shutdown services – in Server 2003, you can simply run this from the command line:

  sc delete sysdown
  sc delete cpqasm2

  In Windows 2000, you’ll want to delete those services from the reigstry (careful!)
  (HKLMSystemCurrentControlSetServices)

• Uninstall VMWare Converter.

Tip 3: Remove Hardware That’s No Longer There

This one’s a no-brainer once you think of it: get rid of hardware that the operating system has drivers for but no longer exists. But the way to get rid of that hardware is a little more hidden, no pun intended (you’ll see why). You can start up Device Manager in Windows by running devmgmt.msc from the Run menu, but it won’t necessarily show you everything you need to get rid of. To show all of those components, do the following:

1. From a command prompt, run

   set devmgr_show_nonpresent_devices=1

2. Without exiting that command prompt, run

   devmgmt.msc

3. When the Device Manager comes up, click on View -> Show Hidden Devices. This should show you a whole slew of hardware that is slightly greyed out – it’s basically safe to remove anything that is greyed out, such as iLO Multifunction adapters, Intel Ethernet adapters, IBM RAID controllers, and so on.

Basically, these three major tips are what I follow whenever I P2V a server – and I’ve done roughly 50 of them over the last two months with a few hundred more to follow in the coming year. The failure rate, following these tips, should be pretty low.