Hi Kirill,
if the disks have really the same disk signature this is definitly your root
cause.
you can change the disk signature with diskpart -> "DETAIL DISK" to view
signature and "UNIQUEID DISK ID=newsignature" for setting a new one.
Troubleshooting Disk Management
http://technet.microsoft.com/en-us/l...81(WS.10).aspx
Regards
Ramazan
"Kirill Kovalenko" <> wrote in message
news:206882f6-1802-426a-9156-...
> Hello Ramazan,
>
> Disks did have the same id as we deployed them by xcopying them from
> the 'master'. However, that hadn't been an issue before we switched to
> using MPIO.
>
> We tried MCS but didn't managed to have it working.
>
> Using 10Gb on the initiator side is not an option for us for the
> reasons of price and redundancy.
>
> Judging from the behavior we observe there must some signature or id
> that MPIO layer writes to disk. We basically looking for Microsoft
> engineers to confirm it and to get to know a way of changing it.
>
>
> On Feb 23, 11:13 pm, "RCan" <noos...@arcor.de> wrote:
>> Hi Kirill,
>>
>> as you say you did change the disk signatures, do the disks had the same
>> signature before ? Also did you tried to use MCS (multiple connection per
>> server) instead of MPIO ?
>>
>> Finally driving with a single path and switch to 10GBit on
>> Target+Client -
>> if possible ;-) But then, you will loose the redundancy :-(
>>
>> Regards
>> Ramazan
>>
>> "Kirill" <kirill.kovale...@gmail.com> wrote in message
>>
>> news:aa652702-5ee5-4858-bc92-...
>>
>> > We have the following infrastructure: WUDSS 2003 R2 provides iSCSI
>> > targets which are consumed by a Server 2008 R2 cluster and forwarded
>> > as pass-through disks to Hyper-V guests. We do not use VHDs for
>> > Hyper-V and, until recently, we have used no MPIO for iSCSI.
>>
>> > For OS deployment, we have chosen the following scenario: We have pre-
>> > configured "master" guests with an OS and software installed. We
>> > copied virtual disks (at WUDSS) corresponding to one of those master
>> > guests every time we needed to deploy a new guest system. As a new
>> > disk is copied we imported it into WinTarget, created a new iSCSI
>> > target for new virtual machine. Finally we created a new guest
>> > machine with the new target and sysprep-ed the new guest machine.
>>
>> > So far it worked wonderful: the provision of time for a new guest
>> > machine was just few minutes. Now we have installed MPIO for iSCSI
>> > traffic balancing and a deployment problem appeared.
>>
>> > Now, with MPIO enabled, when two or more such "cloned" images are
>> > connected via iSCSI Initiator, the iSCSI initiator assigns them to a
>> > single physical drive (e.g. \\.\PhysicalDrive5 ) . Each connected
>> > target has its own LUN, but MPIO paths are connected to the target
>> > connected first and there is only one disk is visible to the Hyper-V
>> > host.
>>
>> > It s clear that iSCSI/MPIO stores some information on disk, and our
>> > original thought was that it s disk id. However, we tried changing
>> > disk id with help of diskpart tool and disk id doesn t seem to play a
>> > role.
>>
>> > Currently we had to switch to WIM/ImageX based deployment, but it
>> > takes more time and we want to know if there is any way to prevent the
>> > stick together behavior described above and to have a possibility to
>> > deploy new iSCSI targets/VM guests using xcopy approach.
>
Linear Mode
