Verteilen von VMDKs einer VM auf mehrere Datastores

[pirx]

Hallo,

wir legen unsere Windows VMs mit 3 VMDKs/Laufwerken an, diese liegen bisher alle im gleichen Ordner auf dem gleichen Datastore. Eine VMDK von jeder VM (immer das gleiche Laufwerk, 200 VMDKs, rund 15 TB) soll nun auf einem anderen Storage abgelegt werden. Ich weiß das ich bei einer svMotion auch nur eine VMDK auswählen und verschieben kann.

- wie funktioniert das, wenn die 2 anderen VMDKs in einem sDRS Cluster liegen der bei Bedarf die VM auf ein anderes DS verschiebt, wie kann ich sicherstellen, dass die eine VMDK immer auf dem anderen Storage (ggf. anderer sDRS Cluster) bleibt.?

- wie kann ich sicherstellen, dass wenn ein Mitarbeiter manuell eine svMotion Aktion für eine VM startet, die eine VMDK nicht mit verschoben wird? Ich dachte zuerst an Storage Profiles, aber das scheint dafür nicht geeignet zu sein.

- wie kann ich automatisiert die 200 bereits bestehenden VMDKs, die immer das gleiche Windows LW sind, an den neuen Ort verschieben. Es ist aber leider nicht immer die gleiche Disk in der VM Konfiguration (also SCSI Bus). Um die Last gering zu halten soll immer nur eine VMDK verschoben werden, das aber rund um die Uhr.


Mir ist noch nicht klar, welche Fallstricke dabei im täglichen Betrieb lauern.

[irix]

Mir ist keine Moeglichkeit bekannt welche ein manuelle svMotion unterbindet.

Wenn du 2(bei euch dann mehr) Storage Cluster hast dann mach ein sDRS dies ja nicht Cluster uebergreifend und somit muesste man ein automatischen verschieben schon mal unterbunden haben. Ich selbst hatte noch garkeine VM welche in mehrere Clustern liegt.. geht das ueberhaupt?

Fuer den Compliance Check gibts dann die Storage Profiles wobei man nachgucken muesste ob man ueber die API dran kommt.

Gruss
Joerg

[pirx]

Ich habe einige Test gemacht, ich kann einer VM vDisks in mehreren sDRS Clustern geben. Das funktioniert auch mit der Standard Affinity Rule "Keep VMDKs together". Wenn ich danach die VM, bzw. vDisks über sDRS manuell verschiebe, muss ich das mit den Advanced Options machen, die passende vDisks raussuchen und davor die "Keep VMDKs together" Rule deaktivieren.

So richtig gefällt mir das nicht, zum einen würde ich die VMDKs der VMs grundsätzlich schon gerne zusammenhalten, nur diese eine soll auf einem anderen Datastore liegen. Wenn ich die Affinity Rule aber deaktiviere, werden natürlich alle VMDKs dann bunt verteilt.

Irgendwie ist es ja schon sehr däm"§$%"§ das es bei den sDRS Clustern nur Affinitiy und AntiAffinity Rules gibt.

[bla!zilla]

Die Migration kannst du per PowerCLI automatisieren. Das sollte mit ein wenig Skripting problemlos zu machen sein.

Ich fasse deine Anforderungen mal zusammen (soweit ich sie verstanden habe):

- VMs haben mehrere VMDKs
- VMs liegen in mehreren SDRS Clustern
- ein VMDK von allen VMs soll in einem bestimmten SDRS Cluster/ Datastore liegen
- die restlichen VMs sollten am ursprünglichen Ort verbleiben
- Sobald eine VM verschoben wird, muss die getrennt abgelegte VMDK an ihrem Ort verbleiben, die anderen VMDKs sollen zusammengehalten werden

Soweit korrekt?

Du suchst offenbar eine Mischung aus Affinitv- und Anti-Affinitv Rule. Du willst einen Teil der VMs zusammenhalten, eine VMDK aber getrennt ablegen. So ad hoc fällt mir da nichts ein. Der Automatismus von SDRS wird die da einen Strich durch die Rechnung machen. Bei traditionellen Datastores wäre es nur einmaliger Aufwand, ohne die Benefits von SDRS.

[pirx]

Der Automatismus von sDRS macht mir momentan weniger Sorgen als das manuelle Ausführen von svMotion. Wenn man (aus welchen Gründen auch immer) die VM auf ein anderes DS verschieben möchte - bis auf die eine vDisk - und dort nicht in die Advanced Options geht und für die eine vDisk das Datastore belässt, werden alle vDisks wieder in einem DS/Verzeichnis konsolidiert. Ich kann das zwar mit Storage Profiles überwachen, dann muss ich die betroffene vDisk aber wieder verschieben.

Wobei mir das Storage Profile immer ein Noncompliant für "vm home", also die VM Konfigfiles, anzeigt. Obwohl diese alle auf dem Storage liegen das ich mit dem Profil verbunden habe. Für die VMDKs passt es.

Edit: das könnte wunderbar funktionieren, hätte VMware bei svMotion die Storage Profiles besser eingebunden. Man bekommt zwar in der Basic Anzeige von svMotion den Punkt "VM Storage Profile" angezeigt, kann dort aber nur ein Profile auswählen. In meinem Fall haben die VMs aber 2 Profile, eins für die eine vDIsk ein anderes für die Restlichen vDisks. Würde das an der Stelle sauber beachtet, wäre alles prima.


Edit 2: in 5.5 heißen die Storage Profile jetzt Storage Policies und dort kann man mit Tags arbeiten. Damit wird mir bei einer svMotion Aktion zumindest angezeigt, wenn ein DS ausgewählt wird das nicht zum Profil passt. Das geht aber wiederum nur im Web Client. Im klassischen Client (ebenfalls 5.5) heißt es immer noch Profiles. Die Profiles die man mit dem klassischen Client in 5.5 angelegt hat, sieht man nicht im Web Client und umgekehrt. Recht herzlichen Dank VMware...

[Dayworker]

Das VMware bei einem eigentlich bereits abgekündigten Produkt, der C#-Client sollte ursprünglich bei 5.5 schon nicht mehr dabei sein, nicht mehr viel bzw gar keine Pflege mehr investiert, verwundert dich jetzt aber nicht wirklich. Wenn VMware die Performance des Web-Clienten besser in Griff gehabt und sich vorher auch noch ein paar mehr Gedanken über den kostenfreien "vSphere Hypervisor" gemacht hätte, würdest wir heute dieses Chaos überhaupt nicht mehr haben...