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
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.
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.
Example Environment
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
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
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
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 ...