In der Praxis…
…kann der SQL-Server schon bei 3,6Gb Datenbankgröße den Dienst verweigern

In der Theorie…
…sollte die Anwendersoftware vorher eine Warnung ausgeben

In der Praxis…
…liegt der Schwellenwert für die Warnung bei 3,8Gb

In der Theorie…
…sollte die Fehlermeldung lauten: “Die Datenbank ist zu groß”

In der Praxis…
…lautet sie: “Die Datenbank ist defekt, spielen Sie eine Sicherung ein”

In der Theorie…
…Kann man sich an die Hotline wenden und das Problem in 10min beheben

In der Praxis…
…hat es zwei Stunden gedauert

In der Theorie…
…sollte der Einsatz nur 15 Minuten dauern

In der Praxis…
…waren es 3 Stunden

In der Theorie…
…liegen Theorie und Praxis weit auseinander

In der Praxis…
…kann ich das nur bestätigen.

Wucherzins

gesehen auf http://www.wohnlicht.com

[UPDATE1]
Weitere, von dem Problem betroffene Applikationen:

• Microsoft SQL Server
• Symantec pcAnywhere
• Symantec Antivirus
• Adobe Acrobat Reader

Die msvcp71.dll ist auch auf der VMWare Tools CD (Windows.iso, wird gemountet wenn man die Tools installiert) unter folgendem Pfad zu finden:

<cdrom drive>\program files\VMware\VMware Tools\

[/UPDATE1]

[UPDATE2]

Laut http://communities.vmware.com/message/1363520#1363520 gibt es eine Möglichkeit dieses Problem zu umgehen. Ich muss gestehen, diese Möglichkeit ist nicht schön, aber vielleicht nützlich:

chjones behauptet u.a. die msvcp71.dll wurde nicht angefasst wenn man folgendes beachtet:

• die automatische Aktualisierung der Tools aktivieren
• VMs NICHT mit VMotion auf einen vSphere 4 Host migrieren
• VMs herunterfahren und auf einem vSphere 4 Host neu booten

BTW, VMWare hat diesen Bug erkannt. Er soll in vSphere 4 Update 1 behoben werden. U1 erscheint voraussichtlich erst im November 09. Anscheinend sollte man genau wie bei M$ bis zum ersten ServicePack warten

[/UPDATE2]

Yes, we gähn

Ein Kommentar zum TV-Duell 2009. Gefunden auf tagesschau.de

Das Problem kann behoben werden, indem man die zusätzlichen Festplatten im Diskmanager wieder ‘online’ schaltet und die VM neu startet. Der Bug wurde mir gerade von VMWare bestätigt – es wird an einer Lösung gearbeitet!

Die Ursache ist anscheinend der Austausch des virtuellen Festplattencontrollers. Windows sieht diese Festplatten als “neu” an und bindet sie nicht automatisch wieder ins System ein.

Um USB-Geräte in VM’s zu nutzen, die auf einem ESX oder ESXi laufen, muss man ein wenig in die Trickkiste greifen und diese über das Netzwerk freigeben. Dazu kann man entweder recht teure Hardware (AnywhereUSB) oder recht günstige Stoftware (KernelPro USB-Over-Ethernet) nutzen. Beides ist getestet und läuft erstaunlich stabil und robust, nur diesmal nicht.

Und zwar kommen USBoE und das Yosemite Backup, das Dell als OEM liefert nicht miteinander klar. Sobald der Yosemite-Backup Agent auf dem besagten Rechner läuft, kann USBoE nicht mehr auf den USB-Bus zugreifen und die freigegebenen USB-Geräte sind in den VM’s nicht mehr ansprechbar. Beide Programme nutzen unterschiedliche Netzwerkports und haben eigentlich nichts miteinander zu tun. Wie kann das sein?!

Der Hintergrund alle Systeme zuerst in virtuellen Maschinen abzubilden ist hauptsächlich die Möglichkeit, in wenigen Sekunden Snapshots anzufertigen und bei Bedarf wiederherzustellen. Man friert sozusagen das Komplettsystem – alte Server und neue Server – vor jeder Daten- und Programmmigration ein und kann, falls etwas schief geht, einen konsistenten Zustand wiederherstellen.

Ein Hot-Convert mit dem VMWare Converter eines Windows 2000 Domain Controllers birgt jedoch laut VMWare einige Risiken, wie zum Beispiel diese hier. Obwohl es in den meißten Fällen gut geht, haben wir uns für die Cold-Convert Boot CD entschieden. Diese Boot-CD ist Teil des VMware vCenter Converter Enterprise, der im vCenter Server integriert ist und leider nicht kostenlos zum Download verfügbar ist. Die Boot-CD startet eine Windows PE Umgebung in welcehr der normale P2V-Converter, alle im Rechner verfügbaren Festplatten konviertiert.

Die Migration selber dauerte ca. 80 Minuten für 90GB an Daten. Dank aller Vorsichtsmaßnahmen (Cold Convert usw.) startete der alte Server in der VM tadellos. Alle Programme und Datenbanken funktionierten… bis wir einen Client-PC eingeschaltet haben.

Sie konnten nicht angemeldet werden.
Überprüfen Sie Benutzernamen und Domain und geben Sie das Kennwort ein….

Kein einziger Client-PC konnte sich an der Domäne anmelden – das Eventlog am Server meldete das Computerkonto HOSTNAME$ versuche sich mit einem abgelaufenen Computerkennwort anzumelden. WTF?! Um mittlerweile 21Uhr haben wir den Entschluss gefasst, das trotz diverser Rettungsmaßnahmen die VM unbrauchbar war und wir die alte, physikalische Kiste wieder angeschmissen haben.

Es drängte sich die Frage auf, was schief gegangen ist. Nach näherer Analyse des Servers, musste ich feststellen, dass im Server zwei RAID1 – Laufwerke vorhanden waren. BEIDE Laufwerke hatten jeweils eine aktive Partition mit einem Windows Ordner… Warum?

Es stellte sich heraus, dass die Festplattenkapazität in dem Server vor einigen Jahren zur Neige ging und größere Platten eingebaut wurden. Alle Partitionen wurden dem alten, kleinen RAID1 auf ein neues, größeres RAID1 geklont und das neue RAID1 wurde im BIOS als erstes Boot-Device eingetragen. Das alte RAID wurde jedoch nie aufgelößt und dümpelte in dem Server vor sich hin. Und genau das wurde uns bei der P2V-Migration zum Verhängnis. Da keiner daran gedacht hatte, dass mehrere bootbare Partitionen vorliegen, habe ich bei der P2V-Migration den Punkt “Alle Festplatten konvertieren und Größen beibehalten” gewählt. Gesagt, getan. Der Converter fand zwei aktive Partitionen vor und stand wahrscheinlich vor der Entscheidung welche er als Systempartition bevorzugt. Er bediente sich der erst-besten: Das alte, kleine RAID hatte die LUN0:0 und das neue, Produktivsystem die LUN0:1. Fälschlicher Weise wurde nun ide LUN0:0 als Systempartition erkannt, für die VM mit Treibern vorbereitet und gestartet.

Plötzlich wurde uns klar, das wir nach der ersten Konvertierung mehrere Stunden an einem ca. 2 Jahre alten System herumgedoktort haben und uns wunderten warum die Clients sich nicht anmelden. Keinem war aufgefallen, dass es garnicht das aktuelle System war. *FAILED* Das Resultat waren über fünf Stunden verlorene Arbeit, eine steile Lernkurve und am nächsten Tag eine erneute Spätschicht

Also vorsicht bei der der P2V-Migration von Multi-Boot-Systemen, deren Boot-Reihenfolge im BIOS eingestellt wird. Die Cold-Convert CD bereitet lediglich die niedrigste LUN mit einem Systemverzeichnis für die virtuelle Maschine vor. Die Bootreihenfolge lässt sich, analog zum echten BIOS, auch im virtuellen BIOS einstellen, jedoch fehlen in den anderen Partitionen die notwendigen Treiber für die VM (zumindest bei Win2k).

Wäre die Erde eine Bank, dann hätten wir sie schon längst gerettet

Kürzlich aufgeschnappt…

Niko Kampen's Webblog

Der Webblog von Niko Kampen, einem befreundeten Künstler aus Dortmund, erstraht seit gestern in neuem Glanz. Nach langem hin-und-her konnten wir uns auf ein Theme und Design einigen und haben es zusammen umgesetzt – Niko den grafischen und ich den technischen Teil. Als Grundlage diente das Wordpress-Theme ‘Trendy‘ von Benedikt RB. Mit wenigen Modifikationen am CSS  und am Hintergrund war das Theme an das größere Logo angepasst und die Seite ist nund endlich fertig. Ich hoffe nur Niko hält sich an sein Versprechen und möchte nicht wieder etwas ändern

Weitere Informationen zum Funktionsumfang oder technischen Details gab es auch von der Hotline leider nicht, Zitat:

Wir können keine näheren Angaben machen, weil wir die Software noch nicht vorliegen haben