Why iSCSI ?
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.
P2V and iSCSI
Consider you need to P2V a physical system into a virtual
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.
iSCSI and MOA
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
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
The network environment
We need direct access between source and target - in this case I assigned
10.0.0.5 for the MOA system that is booted on the source
10.0.0.7 for the MOA system that is booted on the target
Diskmanagement of 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:
Diskmanagement of the source
The source machine is booted into a typical MOA 3
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
iSCSI-setup on the target
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.
iSCSI-setup on the source
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.
The Clone or Copy process ...
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 ...