Cloning procedure + destination system support question

Moderator: continuum

Cloning procedure + destination system support question

Postby Nethfel » Sat Jan 22, 2011 5:24 pm

Hi all,

After getting MOA going and a boot disk successfully made, I'm ready to try a cold clone. Now, I need to mention - in the past all I've done were hot clones (except when using VMWare converter 4.3 to migrate some VMs from VMWare server 1.x to ESXi 4.0). In searching through the old and new of this site, I have a few questions that I was having some trouble locating information on (I'm sure it's here, but I'm not sure where to look)

1) When I cold clone a machine - say a Windows 2k3 server - I had read procedures for other versions where you have to clone first then patch (SCSI drivers if I recall correctly, but the docs I read were more with regard to Win 7 and 2008, this machine I want to attempt to clone is running on an older poweredge that I'm pretty sure has a boot drive that is SCSI (I don't have it in front of me atm)); I'm not sure of what exactly the procedure is I need to follow in order to do this; and I want to make sure I understand what I'm doing before I try.

2) When I cold clone, I have several options in terms of where to target - will the VMWare Converter 3.0.3 that is used work with ESXi 4.0? (on vmwares site they only reference working with ESXi 3.x) or is there a way to clone to a set of files on an external drive, then later run converter 4.3 to migrate the new vm to ESXi 4?

Basically, I'm a cold cloning noob and I want to make sure I understand what I need to do (any/all steps needed) prior to doing it - I'm sure there are docs here somewhere covering this, but I am having some trouble locating them.
Posts: 6
Joined: Thu Jan 20, 2011 11:02 pm

Re: Cloning procedure + destination system support question

Postby continuum » Sun Jan 23, 2011 6:20 pm

when I saw your post I decided to create something like an introduction into Coldclones.

Looks like this takes longer as expected ... lots of stuff ...

so let me answer your questions quickly - more details coming soon

First of all please eat this - you must understand this part

A Coldclone task - and a Hotclone by the way - is split into 3 separate 3 steps.

1. create new virtual machine
2. clone the bootdisks of the source machine into vmdk-files
3. mount the new vmdk-files and adjust registry and inject driverfiles if necessary

This 3 steps are completely independant from each other.
For the final result it does not matter at all which tool was used to do the imaging part of the job.

The most reliable procedure to P2V a source system running Windows7 64 to a ESX target for example does not use Converter at all.
here you would use a Knoppix and create the diskimage with dd and store it on a local USB-disk.
The resulting file is already ESX-compatible if used as *-flat.vmdk and can be uploaded to the ESX with a reliable tool like WinSCP or FastSCP at any time later.
The necessary adjusting of the drivers then can be done by booting the new VM into a Windows 7 recovery CD

When you ask where you would store the newly created VM of the Coldclone wizard the answer is simple.

it does not matter at all.

if you have a fast and reliable network connection to the ESX or ESXi server the most covenient option is of course to directly store the new VM on the ESX olr ESXi.

If the connection feels unstable or you get strange errors due to some firewall issues or bugs in Converter the safer approach is to store the new VM on a local disk.

So you may have to decide: do I risk a direct clone to ESX with the danger that it may abort after 10 hours with an unusable result - or do I play it safe and create a local image first and upload it later.

Now what is better: trying a risky 12 hours direct clone - or better plan with 4 hours for the clone to USB plus 10 hours for the upload to ESX later.

If you are lucky the direct clone is more convenient and faster
if you have no luck the direct clone fails after 11 hours with zero results.

the two steps approach will always take 14 hours but both single steps are reliable and so you can
predict when the job will be done.

When I have to decide I often start a direct clone and if it feels fast and snappy I let it finish.
If I have a reason to suspect problems I take the slower but safer approach and abort the direct clone.
As already mentioned a successful P2V operation = create new VM + clone + patch
For any of the 3 steps Converter is just a very convenuient tool but not necessary the fastest, most stable or most reliable.

The imaging part also can be done with Acronis or Ghost CD - both of them may be faster then the Converter.
Patching can be done with Converter, a liveCD that has the DriverInjectionGUI like MOA, a Windows Recovery CD ...

Again Converter is the most convenient but not necessary the best tool for the job.

The Converter "create Coldclone" wizard that can be started from MOA is designed to not ask unnecessary questions.
This is nice for occasional users - but for folks that do Coldclones more regularly it is a pain.

Many failures of the wizard like "can not find the system drive" could be avoided if that stupid wizard would simply ask in such a case.
If the wizard does not finds the Windows directory in the expected path it aborts and gives up.

If the wizard would ask at this point you could specify a directory and go on with the process ....

Selecting poor defaults for the open options is another bad habbit of Converter.
For example the new version 4.3 usually misconfigures the Controller used for booting the system.
per default it seems to pick IDE - exactly that option that will most probably fail :lol:

Short rant summary: all Converter versions are over-simplified tools - designed to look easy - not to acchieve best results in all cases.

Knowing that I now use the following approach when I have a P2V task planned.

I boot the source machine with a MOA-standard CD using Big-driverpackage and at the same time I plugin a USB-disk.
I try a direct clone directly to ESX
If the progress meter does not make the jump from 2% to 3% inside the first lets say 15 minutes I abort the procedure.
If I get a SSL problem or a Firewall related problem I abort.
If I get unspecified errors I abort.

When ever one of those mentioned cases appears I usually do not waste any time with troubleshooting the problem.

Instead I switch to plan B = store new VM on USB
If that also fails I switch to plan C and create the diskimage with dd, ghost or whatever

Why do I still use Converter at all you may ask ?

Converter has one killer feature buildin: it can image a source disks and directly store it as a thin provisioned vmdk on ESX.
This is very convenient and safes one step.

Only other tool that I am aware of that can do this in one step is vmware-vdiskmanager.exe - a tool included in Workstation
Do you know that you can VMware Workstation do your MOA-CD ?
UIf you plan to a lot of P2V I highly recommend to add it - vmware-vdiskmanager really can safe the day ....

Oh dear - I got a litttle bit carried away.

Hope this answers your most pressing questions for now ...


check occasionally.
the guide I am writing right now will appear there in the P2V section
Posts: 57
Joined: Tue Sep 28, 2010 8:39 pm

Re: Cloning procedure + destination system support question

Postby Nethfel » Sun Jan 23, 2011 8:06 pm

Hmm, interesting. I understand the 3 steps, and I understand that I've been kind of oblivious to them while using the VMWare converter ;)

I did not know that a DD'd image was already compatible with esx! The closest I had seen about using dd was when cloning a linux installation by booting both the source and target with a live cd and using dd over the network to image the source into a VM.

Now, I won't be cloning Windows 7 machines - I would instead be cloning either Server 2k3 or server 2k machines. Would I still use a win 7 recovery cd to adjust the drivers or another process? I guess I myself would need a tutorial of injecting the drivers post clone as that is something I have never done.
Posts: 6
Joined: Thu Jan 20, 2011 11:02 pm

Re: Cloning procedure + destination system support question

Postby continuum » Sun Jan 23, 2011 11:04 pm

The suggested procedure for Coldcloning 2003 and XP is different then for Windows 7.

In fact Converter 3.0.3 usually does a pretty good job when Coldcloning 2003 , XP and 2000.
Manually patching is only required in very rare cases.
MOA also comers with the tool DriverInjectionGUI - see some screenshots






see discussion

I assume you have seen a F6 driver-floppy for 2000 or XP or 2003 ?
Typically this floppies have a content like this :

some inf-files
some sys-files

if you want to use DriverInjectionGUI to install a driver to an offline system - you start the GUI and point it to the txtsetup.oem file.
Then the tool checks if it makes sense to install this driver on this system.
If yes - you can proceede and click through the next questions.

This more or less does something similar to the action with the Windows 7 recovery CD I use to p2v Windows 7.
Actually it does a bit more then just set one registry setting.

P2V of Windows 7 is way easier then P2V of 2003 or earlier.

You asked about the dd ...

A dd image is an uncompressed raw diskimage without any special headers. I assume you create the dd image like this

dd if=/dev/sda of=/mounted-usb-disk/p2v-import.dd

/dev/sda = bootdisk of the source physical machine
/mounted-usb-disk = path where the USB-disk is mounted in knoppix
p2v-import.dd = output-image - file maybe very large !

The output of dd is very similar to the one-piece-preallocated vmdk - type.

This is great as it means that we can directly use the dd-file as the *-flat datachunk for theVMware VMDK-types monolithicFlat or VMFS

Only one little step is necessary to persuade VMware to like our dd-image.
Rename p2v-import.dd to p2v-import-flat.vmdk and create a descriptorfile named p2v-import-flat.vmdk

the result then looks similar to
Code: Select all
# Disk DescriptorFile

# Extent description
RW 16777216 VMFS "p2v-import-flat.vmdk"

# The Disk Data Base

ddb.virtualHWVersion = "7"
ddb.geometry.cylinders = "1044"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"

To use that selfmade vmdk in a VM we need the two files


along with a vmx-file that references the vmdk like this

Code: Select all
scsi0.present = "true"     
scsi0.virtualDev = "lsilogic"
scsi0:0.fileName = "p2v-import.vmdk"
scsi0:0.present = "true"

The vmx-file + the vmdk file then can be directly used in Workstation AND in ESX.

No further conversions are necessary.
Posts: 57
Joined: Tue Sep 28, 2010 8:39 pm

Return to MOA - based on BartPE

Who is online

Users browsing this forum: No registered users and 0 guests