.: Michael Korp :.

Rund um die Windows Plattform, Systems Management und Virtualisierung

October, 2007

The best way to predict the future is to invent it.
(Alan Kay)
Artikel
  • Verteilen von Windows Betriebssystemen - auch für Server...

    Der eine oder andere erinnert sich bestimmt daran, dass ich im Umfeld der Fertigstellung von Windows Vista den einen oder anderen Vortrag zu den Bordmitteln von Vista (Windows AIK / Automated Installation Kit) und den BDD 2007 gehalten habe.

    Das WIndows AIK stellt hierbei die verwendete Technologie zur Verfügung und BDD Prozessdokumentation und eine Workbench um den gesamten Prozess zu automatisieren und vor allem außer dem Betriebsystem auch Anwendungen und Treiber in den Prozess zu integrieren. -- Einschränkung: BDD steht für "Business Desktop Deployment". Wer seine Server ebenfalls damit installieren wollte, konnte zwar vieles direkt verwenden, hatte aber auch diverse weiße Flecken zu adressieren.

    Jetzt steht die nächste Version des BDD fast vor der Tür, mit der integrierten Fähigkeit der Serverinstallation & Konfiguration. Deswegen wurde auch der Name in "Microsoft Deployment" (Codename: "Deployment4") geändert.

    Infos dazu gibt es hier - inklusive dem Link zum RC1 Download auf connect.microsoft.com

    Update: Mittlerweile ist die fertige Version verfügbar, wie ich hier geschrieben habe...

  • Windows Server 2008 Hypervisor API

    Wie alle sonstigen Windows Komponenten, wird auch die Virtualisierung ein Programmierinterface (API) haben - die "Hypercall API". Details dazu stehen auf dem Windows Virtualization Team Blog in einem eigenen Artikel.

    Die Hypercall API steht dabei unter der"Open Specification Promise". Der Download der Spezifikation findet sich hier.

    Die Frage ist natürlich, wofür man diese Informationen eigentlich braucht. Eigentlich ist das gar nicht so schwer, andererseits braucht der "durschnittliche" Anwender diese Informationen aber auch nicht. Wer allerdings die Schnittstelle zwischen der Virtualisierung und der Außenwelt verstehen will, oder aber Lösungen erstellen will, die kompatibel sind, der benötigt diese API Beschreibung sehr wohl.

  • Netzwerkkarten und Virtualisierung

    Eine Frage, die ich mittlerweile schon häufiger bekommen habe und daher wohl mal "öffentlich" beantworten sollte: "Mein Server hat eine Gigabit Netzwerkkarte, in der virtuellen Maschine kann ich aber nur eine 100MBit Karte konfigurieren. Jetzt muss ich ja doch anstatt Virtual Server etwas anderes nehmen, damit ich eine schnellere Netzwerkanbindung in der VM bekomme..."

    Klingt logisch, ist aber trotzdem falsch.

    Bei einer physischen Netzwerkkarte gilt dieses ja schon, da der Hardware Chip auf der Karte ein bestimmtes Protokoll für das Kabel implementiert und eine eingebaute Funktionalität hat, die weitestgehend durch Silizium festgelegt wird. In der virtuellen Welt wird aber auch die Hardware virtualisiert. Hierbei muss man zwischen zwei Modi der Virtualisierung unterscheiden: Die Hardware, die virtualisiert wird, aber in der VM genauso erscheint wie im Host (z.B. der Prozessor - die VM sieht immer die CPU, die im Host steckt) und die Hardware, die emuliert wird. Emuliert wird ja der Chipsatz (Intel 440BX), die Grafikkarte (S3 Trio) und auch die Netzwerkkarte (Intel 21140, ehemals DEC 21140). Emuliert bedeutet, dass dort keine Hardware genutzt wird, sondern das Gerät vollständig in Software existiert. Das wiederum bedeutet, dass die Geschwindigkeit des Gerätes nur von der Geschwindigkeit der Emulation und der darunter liegenden Hardware abhängt.
    Im Beispiel der Netzwerkkarte bedeutet das, dass nur die CPU Ressourcen und die Netzwerkkarte des Host die Geschwindigkeit der Netzwerkkommunikation in der VM beeinflussen. Auf der anderen Seite ist natürlich auch die Hardware des Host eine gemeinsam genutzte Ressource, deren Leistungsfähigkeit sich der Host und alle dort laufenden VMs teilen müssen.

    Das beschriebene Verhalten hat aber noch ein paar weitere Konsequenzen, die z.T. nur die Anwender mit mobilen Geräten merken.

    1. Beispiel: Die "Offload" Funktionalitäten aktueller Netzwerkkarten. Im Kontext der Virtualisierung macht die wenig Sinn und stört teilweise sogar, da ja das Hardware Modell in der VM ein anderes ist, als die reale Netzwerkkarte des Host. Damit es dort nicht zu ungewollten Beeinträchtigungen kommt, ist es häufig ratsam, die Offload Funktionen zu deaktivieren.

    2. Beispiel: Drahtlos Netzwerke - die Virtualisierung muss Netzwerkpakete mit der MAC Adresse der VM abschicken, die sich natürlich von der MAC Adresse der realen (WLAN) Karte unterscheidet. Das wiederum mögen die üblichen Access Points nicht... (Ausnahme: Virtual PC im NAT Modus)

  • Operations Manager 2007 - neue Management Packs

    Nachdem der Operations Manager 2007 ja seit Juli allgemein verfügbar ist, füllt sich zunehmend auch der Katalog mit den Management Packs. Ein weiteres wichtiges wurde jetzt gestern veröffentlicht: Exchange 2007. Gleichzeitig wurde auch das "MOM 2005 Backwards Compatibility MP" aktualisiert.

    In diesem Fall müssen beide importiert werden, da das Exchange MP das aktualisierte Compatibility MP erfordert - mit ein Grund, warum die Veröffentlichung etwas länger gedauert hat...

  • Ende eines Anachronismus (genannt Bug...)

    Irgendwann hat bekannterweise ja jemand einen "Treffer" gelandet - dazu meinen Glückwunsch! Wie man mittlerweile weiß, gibt (bzw. gab) es einen Bug in Excel, der dafür sorgte, dass bestimmte Ergebnisse falsch angezeigt wurden.

    OK, Bugs gibt es leider ja immer wieder, aber dieser war neu für Excel 2007 und nicht in den vorherigen Versionen enthalten.

    Außerdem - was sicherlich den meisten, die die veröffentlichte einfache Berechnung nachvollzogen haben, nicht aufgefallen war, bezog sich dies nur auf die Darstellung, nicht aber auf das Ergebnis. Excel hat also weiterhin richtig gerechnet, aber das Ergebnis falsch angezeigt. Auch nicht besser, aber zumindest wusste man jetzt, dass die gesamte Kalkulation in sich stimmig war. Auch andere Darstellungen, wie z.B. Charts, waren von dem Fehler nicht betroffen. Wer die Details nachlesen will, hier ein informativer Artikel: Excel Bug

    Warum mein Glückwunsch an den Entdecker? Ganz einfach: Es gibt genau zwei mal sechs Möglichkeiten diesen Bug zu triggern - wenn man bedenkt, dass die Gleitkommazahlen als 64-Bit Zahl vorliegen, heist das "12 aus 2 hoch 64". Sechs Richtige im Lotto gibt es da viel häufiger (wenn mich meine Erinnerung an Statistik in der Schule nicht täuscht).

    Aber es ist gut, dass es immer wieder solche Treffer gibt!

    Das hat jetzt wieder ein Ende, da es den Fix dafür gibt: KB943075.

    Warum wurde der Bug nicht vorher gefunden? Auch das ist eine interessante Frage und zumindest die Antwort wirft eine weitere Frage auf - nämlich wie sich so etwas verhindern lässt.
    Ziel bei der Entwicklung eines Produktes ist es eine möglichst große Abdeckung der Codebasis durch Tests zu erreichen (Coverage). Jetzt jemanden hinzusetzen, der alle Funktionen mit diversen Parametern testet, ist nicht praktikabel, da der Mensch nicht schnell und zuverlässig genug ist. Also werden diese Tests weitestgehend automatisiert. In diesem Fall war das Problem aber die Darstellung und nicht das Ergebnis, also der Inhalt der Zelle. Automatische Tests haben also nur finden können, dass alles OK ist. Nur die visuelle Beurteilung hätte hier Alarm geschlagen. Hier hilft dann meistens nur der Zufall, oder aber eine Vielzahl von Anwendern, die irgendwann (warum auch immer) genau den Fehlerzustand produzieren. Ein Grund, warum es breite Beta Programme gibt...