Nous disposons de l'infrastructure suivante: WUDSS 2003 R2 fournit des cibles iSCSI qui sont consommées par un cluster Server 2008 R2 et transmises en tant que disques relais aux invités Hyper-V. Nous n'utilisons pas de disques durs virtuels pour Hyper-V et, jusqu'à récemment, nous n'utilisions pas MPIO pour iSCSI. Pour le déploiement du système d'exploitation, nous avons choisi le scénario suivant: Nous avons pré-configuré des invités "maîtres" avec un système d'exploitation et un logiciel installés. Nous avons copié des disques virtuels (chez WUDSS) correspondant à l'un de ces invités «maîtres» chaque fois que nous avions besoin de déployer un nouveau système invité. Comme un nouveau disque est copié, nous l'avons importé dans WinTarget, créé une nouvelle cible iSCSI pour la nouvelle machine virtuelle. Enfin, nous avons créé une nouvelle machine invité avec la nouvelle cible et sysprep-ed la nouvelle machine invité. Jusqu'ici, cela a fonctionné de manière merveilleuse: la mise à disposition d'une nouvelle machine invité ne prenait que quelques minutes. Nous avons maintenant installé MPIO pour l'équilibrage du trafic iSCSI et un problème de déploiement est apparu. Maintenant, avec MPIO activé, lorsque deux ou plus de ces images "clonées" sont connectées via l'initiateur iSCSI, l'initiateur iSCSI les affecte à un seul lecteur physique (par exemple \. \ PhysicalDrive5). Chaque cible connectée a son propre LUN, mais les chemins MPIO sont connectés à la cible connectée en premier et il n'y a qu'un seul disque visible par l'hôte Hyper-V.Les disques iSCSI/MPIO collent ensemble après le déploiement xcopy des cibles
Il est clair que iSCSI/MPIO stocke certaines informations sur le disque, et notre pensée originale était que c'est l'ID du disque. Cependant, nous avons essayé de changer l'identifiant de disque à l'aide de l'outil diskpart et l'identifiant de disque ne semble pas jouer de rôle.
Actuellement, nous devions passer au déploiement basé sur WIM/ImageX, mais cela prend plus de temps et nous voulons savoir s'il existe un moyen d'empêcher le comportement «ensemble» décrit ci-dessus et de déployer de nouveaux iSCSI cibles/invités VM utilisant l'approche xcopy.