Endpoint del cluster OpenShift con i seguenti operatori installati:

NetApp Trident CSI configurato con backend e classi di storage appropriati

NodeNetworkConfigurationPolicy e NetworkAttachmentDefinitions (NAD) configurati con le VLAN appropriate

Il cluster OpenShift è raggiungibile dalla rete con le voci del file host correnti

Privilegi di livello amministratore sul cluster

File Kubeconfig scaricato

I file VMDK possono essere configurati in diversi modi: tutti i file VMDK possono risiedere su un singolo volume NFSv3 (eliminando la necessità di Storage vMotion), ciascun file VMDK può essere posizionato su un volume individuale oppure più file VMDK possono essere organizzati all'interno di un qtree in un volume.

Il Shift Toolkit rileva automaticamente il layout e seleziona il metodo di clonazione e i driver di storage NAS appropriati.

Quando i file VMDK vengono inseriti all'interno di un qtree, Shift Toolkit utilizza il driver ONTAP-NAS-economy.

Gli strumenti VMware sono in esecuzione sulle VM guest

Le VM da migrare sono in stato RUNNING per la preparazione

Le VM devono essere spente prima di attivare la migrazione

La rimozione degli strumenti VMware avviene sull'hypervisor di destinazione una volta accese le VM

ONTAP-NAS: I VMDK possono risiedere tutti su un singolo volume oppure ciascun VMDK può trovarsi su un volume individuale. La selezione delle VM può essere fatta a livello di datastore o a livello di singola VM.

ONTAP-NAS-Economy: I file VMDK devono risiedere su un singolo volume e il nome del volume deve rispettare la seguente convenzione di naming: trident_qtree_pool_<storage-prefix>_<10 random characters>. La selezione delle VM all'interno di un gruppo di risorse avviene solo a livello di datastore.

Per ONTAP-NAS-Economy, il volume con la convenzione di naming specificata sopra deve preesistere e deve essere utilizzato come datastore su VMware vCenter. Questo significa che la VM deve essere Storage vMotioned su questo specifico datastore, oppure un datastore esistente deve essere rinominato per corrispondere alla convenzione di naming: trident_qtree_pool_<storage-prefix>_<10 random characters>.

Per ONTAP-NAS-Economy, la configurazione del backend Trident (TBC) dovrebbe avere il parametro Deny New Volume Pools impostato su true. Anche la storage class utilizzata dovrebbe limitare i storagePools a tbc name: <aggr name where the trident_qtree_pool_<storage-prefix>_<10 random characters> resides>.

apiVersion: v1
kind: Secret
metadata:
	name: nas-eco-data-1172-secret
	namespace: trident
type: Opaque
stringData:
	username: <svm-admin-username>
	password: <svm-admin-password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
	name: nas-eco-data-1172
	namespace: trident
spec:
	backendName: nas-eco-data-1172
	credentials:
		name: nas-eco-data-1172-secret
	dataLIF: "192.168.1.100"
	denyNewVolumePools: "False"
	managementLIF: "192.168.1.50"
	storageDriverName: ontap-nas-economy
	svm: data_1172
	version: 1

Il parametro denyNewVolumePools deve essere impostato su true subito dopo che trident_qtree_pool_<storage-prefix>_<10 random characters> viene creato come parte della creazione iniziale del PVC. Impostando questo valore su true garantisci che Trident utilizzi il pool qtree esistente per posizionare i PVC basati su qtree.

oc patch tbc nas-eco-data-1172 -n trident --type=merge -p '{"spec":{"denyNewVolumePools":"true"}}'

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
	name: nas-eco-data-1172
	annotations:
		storageclass.kubernetes.io/is-default-class: "true"
provisioner: csi.trident.netapp.io
parameters:
	backendType: ontap-nas-economy
	fsType: nfs
	storagePools: "nas-eco-data-1172:NSOL_NetApp_C800_T18U13_02_SSD_CAP_1"
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate

ONTAP-SAN: I VMDK devono essere posizionati su volumi individuali (simulando la struttura VMDK su PVC/PV) utilizzando Storage vMotion. La selezione della VM avviene a livello di VM.

ONTAP-SAN-Economy: I file VMDK devono risiedere su un singolo volume NFSv3 e il nome del volume deve rispettare la seguente convenzione di naming: trident_lun_. La selezione delle VM all'interno di un gruppo di risorse avviene solo a livello di datastore.

Per ONTAP-SAN-Economy, il volume con la convenzione di naming trident_lun_ deve preesistere e deve essere utilizzato come datastore su VMware vCenter. Questo significa che la VM deve essere Storage vMotioned su questo specifico datastore, oppure un datastore esistente deve essere rinominato per corrispondere alla convenzione di naming trident_lun_.

apiVersion: v1
kind: Secret
metadata:
	name: ontap-san800-eco-secret
	namespace: trident
type: Opaque
stringData:
	username: <svm-admin-username>
	password: <svm-admin-password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
	name: ontap-san800-eco
	namespace: trident
spec:
	backendName: ontap-san800-eco
	aggregate: NSOL_NetApp_C800_T18U13_01_SSD_CAP_1
	credentials:
		name: ontap-san800-eco-secret
	dataLIF: "192.168.1.110"
	defaults:
		protocol: iSCSI
		snapshotPolicy: none
		spaceAllocate: "true"
		spaceReserve: none
		tieringPolicy: none
	managementLIF: "192.168.1.60"
	storage:
		- labels:
			backend: san800-eco
	storageDriverName: ontap-san-economy
	svm: data_1172
	version: 1

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
	name: sc-ontap-san-eco
provisioner: csi.trident.netapp.io
parameters:
	backendType: ontap-san-economy
	selector: "backend=san800-eco"
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate

Per ONTAP-SAN e ONTAP-SAN-Economy, le VM devono essere vMotioned da qualsiasi datastore basato su blocchi a volumi ONTAP NFSv3 prima di tutto. Shift Toolkit convertirà quindi i VMDK in LUN e li importerà come PVC nel rispettivo namespace.

Per le VM Windows: utilizzare le credenziali di amministratore locale

Per le VM Linux: utilizzare un utente con autorizzazioni per eseguire comandi sudo senza richiesta di password

Per le VM Windows: montare l'ISO VirtIO sulla VM (scaricare da"Qui" )

Lo script di preparazione utilizza il pacchetto .msi per installare i driver e qemu-guest-agents.

Inietta script per aggiornare i driver VirtIO, installare qemu-agent, rimuovere gli strumenti VMware, eseguire il backup dei dettagli IP e aggiornare fstab

Utilizza PowerCLI per connettersi alle VM guest (Linux o Windows) e aggiornare i driver VirtIO

Per le VM Windows: memorizza gli script in C:\NetApp

Per le VM Linux: memorizza gli script in /NetApp E /opt

Pulisce i volumi per avere solo il file disk.img

Importa i volumi come PVC utilizzando l'importazione Trident

Crea VM utilizzando file yaml specifici per VM

Accende le VM sulla destinazione

Registra le reti su ogni VM

Rimuove gli strumenti VMware e assegna indirizzi IP utilizzando cron job

Cluster OpenShift con operatore OpenShift Virtualization e driver NetApp Trident CSI installati

MTV 2.9.4 (che include la modalità di conversione)

"Kit di strumenti per il cambio"installato

Poiché viene utilizzata solo l'API di Shift Toolkit, non è necessario configurare gruppi di risorse o progetti di Shift Toolkit.

Privilegi di livello amministratore sul cluster OpenShift

Un'istanza Linux con lo strumento da riga di comando OC installato

Requisiti della macchina virtuale per MTV: i VMDK possono essere organizzati in diversi modi: possono essere tutti inseriti in un singolo volume (evitando la necessità di Storage vMotion), assegnati singolarmente a volumi separati o raggruppati all'interno di un qtree in un volume NFS. Lo script rileva automaticamente la struttura e seleziona il metodo di clonazione e i driver di storage NAS appropriati in base all'UUID TBC.