The error says: “Cannot continue restore as a virtual machine ‘VM-NAME’ not on host ‘DESTINATION-HOST’ already exists in the root folder for the datacenter.“. This, for me, makes no sense, as I could do a scheduled restore of a VM to another host. This would enable me to quickly start this in case, the sourcehost encounters an error. Especially for Citrix-Servers this would be a perfect setup, as they usually do not contain any user data.

However, I found a workaround:
- on the source machine, right click the VM and select “Remove from Inventory”
- do your restore
- open a SSH-connection on the sourcehost and reregister the VM

This makes the whole thing work, althought it´s quite inconvenient to automate the whole process. The only drawback seems to be that already created backup jobs aren´t able to find the VM anymore (ID-mismatch). I already have a service request regarding this topic. Let´s see what vizioncore has to say about this.

Strangely enough, this problem only seemed to affect VI client installations; we were able to connect without any problems from the VirtualCenter server itself.

Hmm… I gave it a try and realized, it was no problem to connect from my VC Server to any machine´s console. That leads me to the point where I realized, it´s a compatibility issue. I´m running VMware Infrastructure Client v2.5.0 Build 204931 on my computer, and VMware Infrastructure Client v2.5.0 Build 227637 on my server. Both connect to VMware Virtual Center v2.5.0 Build 227637.

To make a long story short: avoid differences in Buildnumber can avoid strange behaviour/malfunction. Easy solution for a major problem, but it took me a while to figure it out.

Jedoch gibt es bei den Snapshots auch einiges zu wissen/beachten:
- Beim mergen von großen Snapshots gilt es, vor allem den Timeout des Virtual Centers zu beachten. Nach 15 Minuten wird der Task als abgebrochen angezeigt, er läuft im Hintergrund allerdings weiter. Es sollte tunlichst vermieden werden, einen weiteren Merge zu starten!

- Snapshots sollten mit Bedacht verwendet werden, und vor allem nur für kurze Zeit. Snapshots, die länger laufen (z.b. >2 Tage) beeinflußen die Systemperformance stark. Außerdem braucht es äußerst lange, bis die Snapshots wieder gemergt sind (lt. VMWare Support bis zu 8h, abhängig von der Auslastung der Virtuellen Maschine, der verwendeten Hardware, der Größe des Snapshots, uvm.). Seit ESX3.x dauert das mergen noch länger als in den Vorgängerversionen, da der verwendete Algorithmus geändert wurde.

- Virtual Center kennt noch keine Überwachung des verbleibenden Festplattenplatzes. Der/die Snapshots wachsen kontinuierlich an, bis die Partition/das LUN voll ist (es verbleiben nur wenige Mb. Meistens 11MB oder 4MB – zumindest in meiner Umgebung). Aus diesem Grund emfpielt es sich, eine Dummy-Datei im root des Storages zu erstellen, die man im Ernstfall schnell löschen kann. Diese kann mit dem Befehl: “dd if=/dev/zero of=./4000megs.zero bs=1M count=4000” erstellt werden. So werden aus dem Zero-Device 4000 Stücke mit jeweils 1 Megabyte in die Datei 4000megs.zero geschrieben. Dies sollte dann im Verzeichnis /vmfs/volumes/SID-DES-VOLUMES/ passieren, da dies die vmfs-Partition wiederspiegelt. Das ganze könnte dann so ausschauen:

4GB Dummyfile mit dd erstellen

Im Ernstfall, wenn also das Kind schon in den Brunnen gefallen ist und “nichts mehr geht”, kann diese Datei gefahrlos via SSH oder dem Storagebrowser gelöscht werden. Diese 4GB können dann vom ESX-Server genutzt werden, um die Delta-Files mit der VMDK zu mergen.

Es gibt noch ein Tool, welches die Snapshots und den Plattenplatz überwacht, und ggf. eine Warnung per E-Mail versendet. Snaphunter von xtravirt wird in vielen Foren als Lösung genannt, bis VMware in der nächsten Version diese Überprüfung selbst einbaut (info vom VMware Support). Ich habe das Tool allerdings noch nicht getestet, werde das aber demnächst nachholen und hier darüber berichten.

- Läuft schon ein Merge, kann man sich über den Status mit dem CLI-Tool “vimsh” informieren (detaillierte Informationen über “vimsh” gibt es hier). Dazu connected man sich auf den ESX-Host, auf dem der Merge läuft, und startet in der Shell “vimsh“.

VMware vimsh vimsvc/task_list

Dann kann man sich eine Liste der Tasks via “vimsvc/task_list” anzeigen lassen, mit “vimsvc/task_info NAME_DES_TASKS” wird eine detaillierte Info ausgegeben:

VMware vimsvc/task_info

Dort ist ersichtlich, ob der Task schon abgeschlossen ist oder nicht.

————————-

Da es jetzt 2.17 ist, werde ich diesen Beitrag morgen weiter schreiben….

Fehler bei der Installation von VMWare Server 2.0

Dies wird durch ein zu großes MSI-Paket verursacht. Es muss der Patch KB925336 installiert werden. Nach einem Neustart sollte die Installation funktionieren.

Alternativ sollte auch überprüft werden, ob auch wirklich keine Software Restriction Policy eingerichtet ist. Dies kann unter Start – Programs – Administrative Tools – Local Security Policy – Software Restriction Policy (oder auf Deutsch: Start – Programme – Verwaltung – Lokale Sicherheitsrichtlinie – Richtlinie für Softwareeinschränkungen):

Local Security Policy - Software Restrictions

oder unter Windows Vista:

Lokale Sicherheitsrichtlinie - Richtlinien für Softwareeinschränkungen

Nachdem dies getan wurde, lassen sich auch die Lizenzen importieren (Fehlermeldung: Es sind nicht genügend Lizenzen verfügbar, um den Vorgang abzuschließen.)

Zwischen den Tags <config> und </config> müssen, falls noch nicht vorhanden, folgende Einträge hinzugefügt werden:

<hostdWarnMemInMB>175</hostdWarnMemInMB>
<hostdStopMemInMB>250</hostdStopMemInMB>

Um die Änderungen zu übernehmen ist in der Shell (z.b.: SSH über PuTTY) folgendes kommando abzusetzen:

‘service mgmt-vmware restart‘ (<- klick mich für mehr Informationen diesbezüglich)

Unter ESX 3.x geht das unter:
Configuration – Memory. Dort den Speicher von standardmäßig 272MB auf 800MB erhöhen:

ESX 3.x - Raising the memory usage for the Service Console

Die Einstellungen werden erst nach einem Reboot des entsprechenden ESX-Servers übernommen:

Changing the maximum RAM-Size will take place after reboot.

Ergänzend sei noch dieser Artikel der VMWare Knowledge Base zu nennen, der beschreibt, wie man einen ESX-Host neu startet.
In den Maintenance Mode schalten und rebooten sollte aber kein all zu großes Problem sein

Erklären lässt sich das damit, dass die Lizenzen an die MAC-Adresse des Servers gebunden sind, auf dem die Managementsoftware installiert wird.

Ein Anruf bei der HP-Hotline brachte zum Vorschein, dass eine E-Mail an codeword_europe@hp.com mit folgendem Inhalt:
Contact Person:
Company Name:
Licensenumber:
Ordernumber:
Old MAC:
New MAC:
schon genügt, um einen neuen Schlüssel zu bekommen. Die Antwort auf mein E-Mail ist auch wirklich flott gekommen: 14 Minuten nachdem ich meine Anfrage abgesetzt hatte, war die  funktionierende Antwort schon da!

Wenn auch nicht diese Woche, wie ich es mir eigentlich gedacht habe. Aber irgendwann fix.

Btw: es ist ein Proliant DL380G4; lt. diversen ergoogelten Quellen gibt es Probleme mit den Broadcomkarten in verbindung mit dem ESX. Leider hat es auch nichts gebracht, die im BIOS zu deaktivieren und den virtuellen Switch neu zu verkabeln…