Weitere Probleme mit vProxy FLR bei VMs

Über die letzten Wochen sind mir noch diverse weitere Probleme aufgefallen, denen man über den Weg laufen kann, wenn man es mit Windows-VMs zu tun hat.
Diverse Probleme habe ich bereits in einem vorherigen Beitrag beschrieben.
Allerings sind nun weitere Probleme aufgetreten, sodass man leider sehr vorsichtig sein muss, ob man FLR überhaupt über die NMC durchführt oder diese nur zum Mounten der Platten an die Ziel-VM nutzt und den eigentlichen ‚Restore‘ dann über den Windows-Explorer (oder auf er Linux Kommandozeile) durchführt.

1) Die Platten einer VM werden von einem (virtuellen) SCSI Controller verwaltet.
Beim FLR werden bis zu 9 Platten an solch einen SCSI-Controller gehangen. Hat die VM mehr Platten, wird ein weiterer Controller temporär erstellt und die weiteren Platten an diesen gehangen. Soweit so gut. Wenn die VM aber bereits einen zweiten SCSI Controller hat, welcher jedoch einen anderen Typ (z.B. Controller 1 LSI LOGIC SAS & Controller 2 LSI LOGIC PARALLEL) als der erste hat, wird nicht etwa ein neuer Controller mit dem korrekten Typ erstellt, sondern es wird versucht, die Platten an den zweiten Controller zu hängen.
Das schlägt dann jedoch im Normalfall fehl und man erhält die Meldung „Unable to mount: SCSI ID 1/0/0/0 does not have a corresponding PhysicalDrive“. In solch einem Fall ist ein FLR NICHT direkt möglich, außer man entfernt den 2. Controller vorher. Die VM mit Instant Access bereitstellen und dann die Platten manuell mounten funktioniert natürlich.
Bei Dell EMC gibt es zu dem Thema den Bug 34824. Leider kenne ich den Status der Behebung nicht.
2) Das Thema „automount“ unter Windows ist auch leider wieder aktuell… Mittels der automount Funktion werden neugefundenen Laufwerken automatisch Laufwerksbuchstaben zugewiesen. Eigentlich eine gute Sache. Jedoch sieht sich der FLR-Agent in dem Fall nicht in der Lage, die betroffenen Platten unter C:\Program Files (x86)\EMC\vProxy FLR Agent\flr\mountpoints zu mounten. Im Disk Management sieht man die Platten natürlich trotzdem. Wenn NetWorker die Platten aber nicht in seinem Verzeichnis gemountet bekommt, werden sie auch nicht in der NMC angezeigt. D.h. hier muss für den ‚Restore‘ dann wieder der Windows-Explorer herhalten. Oder man schaltet das Automount-Feature aus.
Je nach Windows Version gibt es hier zwei Möglichkeiten:
a) Man öffnet die Kommandozeile mit Administrator-Berechtigungen und tippt folgendes ein:

diskpart
automount disable
exit

b) Der Befehl: mountvol /n
Zu dem Thema habe ich bei Dell EMC einen RFE geöffnet, aber wie bei RFEs so üblich, kann es lange dauern bis er implementiert wird…
Die Nummer lautet: NW-I-1327
3) Und nochmal einer für Windows:
Das leidige Thema UAC/UAM (User Access Control / User Account Management). Wenn man dies zu restriktiv einstellt, kann es passieren, das man die zu restorenden Dateien auswählen kann, aber dann der nächste Schritt, bei dem man das Zielverzeichnis auswählt, versagt.
Die Fehlermeldung sieht so ähnlich aus: „vProxy FLR Error: Error while browsing: 200: Error received from vProxy: Could not get directory contents: Unable to retrieve file list from ‚target VM name‘ – C:\Windows\System32\wbem\WMIC.exe – exit code 44210“
In diesem Fall kam das allbekannte Pop-Up, bei dem NetWorker hätte auf Ja klicken müssen, was er aber nicht kann.
Lösung: UAC/UAM weniger restriktiv einstellen.
Wenn dieser Fehler auftritt, hat man aber ein größeres Problem. Denn selbst wenn man den Restore jetzt beendet, indem man in der NMC auf Close klickt, räumt NetWorker NICHT auf. D.h. der NFS-Datastore auf der Data Domain wird nicht gelöscht, die VM wird nicht für weitere vProxy Operationen freigegeben, usw. Ich werde in Kürze einen weiteren Beitrag schreiben, wie man von Hand aufräumt.