OpenShift Cluster-Endpunkt mit folgenden installierten Operatoren:

NetApp Trident CSI ist mit den entsprechenden Backends und Speicherklassen konfiguriert.

NodeNetworkConfigurationPolicy und NetworkAttachmentDefinitions (NAD) sind mit den entsprechenden VLANs konfiguriert.

Der OpenShift-Cluster ist über das Netzwerk mit den aktuellen Hostdateieinträgen erreichbar.

Administratorrechte auf dem Cluster

Kubeconfig-Datei heruntergeladen

VMDKs können auf verschiedene Arten konfiguriert werden: Alle VMDKs können sich auf einem einzigen NFSv3-Volume befinden (wodurch die Notwendigkeit für Storage vMotion entfällt), jede VMDK kann auf einem eigenen Volume platziert werden oder mehrere VMDKs können in einem qtree innerhalb eines Volumes organisiert werden.

Das Shift Toolkit erkennt automatisch das Layout und wählt die passende Klonmethode und die entsprechenden NAS-Speichertreiber aus.

Wenn VMDKs in einem qtree platziert werden, verwendet Shift Toolkit den ONTAP-NAS-economy-Treiber.

VMware-Tools laufen auf den Gast-VMs.

Die zu migrierenden VMs befinden sich zur Vorbereitung im Status „Wird ausgeführt“.

Die VMs müssen vor dem Auslösen der Migration ausgeschaltet werden.

Die Entfernung der VMware Tools erfolgt auf dem Zielhypervisor, sobald die VMs eingeschaltet sind.

ONTAP-NAS: VMDKs können entweder alle auf einem einzigen Volume liegen oder jede VMDK kann auf einem eigenen Volume gespeichert sein. Die VM-Auswahl kann auf Datenspeicherebene oder auf VM-Ebene erfolgen.

ONTAP-NAS-Economy: VMDKs müssen sich auf einem einzelnen Volume befinden, und der Volume-Name muss der folgenden Namenskonvention trident_qtree_pool_<storage-prefix>_<10 random characters> entsprechen. Die VM-Auswahl innerhalb einer Ressourcengruppe erfolgt ausschließlich auf Datenspeicherebene.

Für ONTAP-NAS-Economy muss das Volume mit der oben angegebenen Namenskonvention bereits vorhanden sein und als Datenspeicher auf VMware vCenter verwendet werden. Das bedeutet, dass die VM mittels Storage vMotioned auf diesen spezifischen Datenspeicher verschoben werden sollte oder ein vorhandener Datenspeicher entsprechend der Namenskonvention umbenannt werden sollte: trident_qtree_pool_<storage-prefix>_<10 random characters>.

Für ONTAP-NAS-Economy sollte die Trident Backend-Konfiguration (TBC) den Parameter Deny New Volume Pools auf true setzen. Die verwendete Storage Class sollte ebenfalls die storagePools auf tbc name: <aggr name where the trident_qtree_pool_<storage-prefix>_<10 random characters> resides> beschränken.

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

Der Parameter denyNewVolumePools sollte auf true direkt nach der Erstellung von trident_qtree_pool_<storage-prefix>_<10 random characters> im Rahmen der initialen PVC-Erstellung gesetzt werden. Das Setzen dieses Werts auf true stellt sicher, dass Trident den vorhandenen qtree Pool für die Platzierung von qtree-basierten PVCs verwendet.

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: VMDKs sollten auf einzelnen Volumes platziert werden (wodurch eine VMDK-zu-PVC/PV-Konstruktion nachgebildet wird) mithilfe von Storage vMotion. Die VM-Auswahl erfolgt auf VM-Ebene.

ONTAP SAN Economy: VMDKs müssen sich auf einem einzelnen NFSv3-Volume befinden, und der Volume-Name muss der folgenden Namenskonvention entsprechen trident_lun_. Die Auswahl der VMs innerhalb einer Ressourcengruppe erfolgt ausschließlich auf Datenspeicherebene.

Für ONTAP-SAN-Economy muss das Volume mit der Namenskonvention trident_lun_ bereits vorhanden sein und als Datenspeicher auf VMware vCenter verwendet werden. Das bedeutet, dass die VM auf diesen spezifischen Datenspeicher Storage vMotioned werden sollte oder ein vorhandener Datenspeicher entsprechend der Namenskonvention trident_lun_ umbenannt werden sollte.

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

Für ONTAP-SAN und ONTAP-SAN-Economy sollten VMs zunächst per Storage vMotioned von beliebigen blockbasierten Datenspeichern auf ONTAP NFSv3 Volumes verschoben werden. Das Shift Toolkit konvertiert die VMDKs anschließend in LUNs und importiert sie als PVCs in den jeweiligen Namespace.

Für Windows-VMs: Verwenden Sie lokale Administratorrechte.

Für Linux-VMs: Verwenden Sie einen Benutzer mit Berechtigungen zur Ausführung von sudo-Befehlen ohne Passwortabfrage.

Für Windows-VMs: Binden Sie die VirtIO-ISO-Datei in die VM ein (Download von"hier," )

Das Vorbereitungsskript verwendet das .msi-Paket, um Treiber und qemu-Gastagenten zu installieren.

Fügt Skripte ein, um VirtIO-Treiber zu aktualisieren, den qemu-Agenten zu installieren, VMware Tools zu entfernen, IP-Details zu sichern und die fstab-Datei zu aktualisieren.

Verwendet PowerCLI, um eine Verbindung zu Gast-VMs (Linux oder Windows) herzustellen und VirtIO-Treiber zu aktualisieren.

Für Windows-VMs: Speichert Skripte in C:\NetApp

Für Linux-VMs: Speichert Skripte in /NetApp Und /opt

Bereinigt die Volumes, sodass nur noch die Datei disk.img vorhanden ist.

Importiert die Volumes als PVCs mit Trident Import

Erstellt VMs mithilfe von VM-spezifischen YAML-Dateien

Schaltet VMs am Zielsystem ein

Registriert Netzwerke auf jeder VM

Entfernt VMware Tools und weist IP-Adressen mithilfe von Cronjobs zu.

OpenShift-Cluster mit installiertem OpenShift Virtualization-Operator und NetApp Trident CSI-Treiber

MTV 2.9.4 (einschließlich Konvertierungsmodus)

"Shift-Toolkit"installiert

Da ausschließlich die Shift Toolkit API verwendet wird, ist es nicht erforderlich, Shift Toolkit Ressourcengruppen oder Blueprints zu konfigurieren.

Administratorrechte auf dem OpenShift-Cluster

Eine Linux-Instanz mit installiertem OC-Befehlszeilentool

Anforderungen an virtuelle Maschinen für MTV: VMDKs können auf verschiedene Weise organisiert sein: Sie können alle in einem einzigen Volume abgelegt werden (wodurch die Notwendigkeit für Storage vMotion entfällt), einzeln separaten Volumes zugewiesen oder in einem qtree innerhalb eines NFS-Volumes gruppiert werden. Das Skript erkennt das Layout automatisch und wählt anhand der TBC UUID die passende Klonmethode und die NAS-Speichertreiber aus.