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.