Home     Documentation       VM-Sickbay        MOA        News        About   


MOA Tips and tricks: Coldclone via ISCSI

related Link: guide to P2V Windows 2008 R2

please post questions and comments here

Another way to mount remote virtual disks ? ... so what ....
Well - mounting a disk via iSCSI has one major advantage compared to other procedures like using mount-tools ...
A disk mounted via iSCSI appears in diskmanagement - that means it can be handled by partitioning tools.
This is not possible wihen we mount a virtual disk with the Virtual Disk Development Kit for example.



Consider you need to P2V a physical system into a virtual machine on a ESX farm.
The physical system is a large fileserver and you want to clone the data disk with the fileshares directly
into a RDM or LUN on the SAN of the farm. This is a killer scenario for Coldclone via iSCSI running MOA.
In other scenarions doing coldclones via iSCSI may not come as natural ... but it is worth to consider it.

All recent versions of MOA support installation on the fly of Starwind 4 and Starport.
MOA 64 also has buildin iSCSI support. You just have to configure the service in Debian.
For MOA 2.4 have a look at the LODR packages for Starwind and Starport which simplify the setup.

MOA can be used as the iSCSI-Target and as the iSCSI-Initiator.
In the following MOA-usage example both roles are used so it is a nice example to practice iSCSI with your MOA-system.


With my limited hardware resources I used the following scenario: one physical host is used as P2V-source.
It is a multiboot machine with Windows 2003 and 2008 R2 and one data-partition.

On a second physical host VMware Workstation or ESX is running.
For the further discussion it makes absolutely no difference wether we use Workstation or ESXi or HyperV or whatever ...
As a target for this coldclone via iSCSI we create a new virtual machine with a new virtual disk.

In the following example we will boot both the source and the target system onto MOA

We need direct access between source and target - in this case I assigned for the MOA system that is booted on the source for the MOA system that is booted on the target

The target system is a virtual machine.
It has one brand new 80 Gb unpartitioned virtual disk.
It was booted into a MOA 2.4 LiveCD - see diskmanagement:

The source machine is booted into a typical MOA 3 USB-disk.
After boot the USB disk appears as disk 0 in diskmanagement.
The original system disk is disk 1.
The source disk carries a multiboot setup.
First partition: 2003 system and boot-files
Sec. Partition: a 2008 R2 system
Third Partition : just data

In the Starwind GUI connect to localhost

once connected add a new iSCSI-target - we want the Disk Bridge Device

In the next step we assign the virtual disk. Note the VMware in the vendor name.

Assign a name to the iSCSI-target

After the wizard finished the log-screen should look like this.
On the target all work is done for now - we can leave it alone.



In the Starport GUI we need to mount a "remote iSCSI-device"

click "add Device"

enter the IP of the MOA system running inside the VM

enter the target name ...

and finish the wizard.


Now that the target is mounted we need to partition it. Open MOA diskmanagement.
A new blank disk has appeared in the list. This is the one connected via iSCSI.
This disk is actually a vmdk file on the ESX or Workstation ...

With the diskmanagement tools I created
a small partition - which will later be used to boot the 2008 system -
and a larger one - which will be used for the 2008 system.
Both are created as primary partitions.

Note the red arrows ... they show the two different copy/clone actions to be done.
In this example the original Windows 2003 boot-option is no longer required.
So we can just create a small boot-partition ...
The Windows 2008 R2 system which lives in the second partition of the source disk
will be cloned into the second partition of the virtual disk.

Now that we have one system which has both target and source disks mounted
we can use all types of tools to do the actual copies.

Good old ghost32 is just one example ... robocopy may be the first choice in other scenarios ...

to be continued ... work in progress ...