Mit Windows Virtual PC Snapshots emulieren


    Tags: ,

    Microsoft Windows Virtual PCAls frei erhältliche Dreingabe ist Microsoft Windows Virtual PC mit einer nicht gerade üppigen Snapshot-Funktion ausgestattet. Für professionelle Testumgebungen, in denen es zur Routine gehört, auf einen alten Stand des Systems zurückzukehren, scheint das Produkt damit nicht zu taugen, zumal der Betrieb mit aktivierten Rückgängig-Datenträgern auch noch quälend langsam ist. Dem ist jedoch nicht so: Mit ein paar Tricks und guter Organisation kann man auch mit Windows Virtual PC eine Snapshot-Infrastruktur erstellen und verwalten, die der etwa von VMware Workstation nicht nachsteht.

    XP-Modus: Schreibgeschützte Master-VHD und differenzierende Kinder-VHDs

    Die Idee ist zugegebenerweise gestohlen – von der Implementation des XP-Modus unter Windows 7 Professional, Enterprise und Ultimate. Dessen Installation beinhaltet eine Basis-VHD unter %ProgramFiles%\Windows XP Mode\Windows XP Mode base.vhd, die schreibgeschützt ist. Die einzelnen Benutzer des Systems arbeiten mit einer differenzierenden VHD, so dass jeder Benutzer seinen eigenen XP-Modus verwalten kann.

    Dieses Szenario lässt sich auch manuell konfigurieren: Man erklärt seine virtuelle Windows-Installation zum aktuellen „Snapshot“ und erstellt davon ausgehend weitere VMs, die seinen Stand übernehmen. Den Snapshot rührt man anschließend nicht mehr an, außer dazu, darauf basierend weitere VMs zu erstellen.

    So erstellt man eine manuelle Snapshot-Struktur

    Zuerst erstellt man den Master für ein Betriebssystem. Er wird nach der Installation nicht konfiguriertJe nachdem, welche Systeme man zu testen hat, installiert man von jeder Windows-Version einen Master nach Standard-Prozedur. Diese Master-Version macht man durch den Namen kenntlich: Da Windows Virtual PC keine Kommentare oder ähnliches zu den einzelnen VMs kennt, hinterlegt man diese am besten in dem Namen der VM selbst sowie in deren Netzwerknamen.

    Die Master-VM für ein Betriebssystem konfiguriert man im Prinzip gar nicht – sie sollte weder Integrationskomponenten noch die aktuellen Windows-Updates oder einen Virenschutz erhalten – außer man weiß zu 100%, dass man nie das Verhalten von Systemen ohne diese Komponenten testen muss. Nur mit einem gültigen Produktschlüssel sollte man sie versehen und aktivieren – sonst kommen später erstellte Kind-VMs auf die Idee zu monieren, dass sie schon zu lange ohne Aktivierung laufen. Danach fährt man die VM herunter. Um zu vermeiden, dass dabei automatisch Updates installiert werden, startet man eine Eingabeaufforderung (am besten über cmd in das Suchfeld des Startmenüs) und verwendet darin den Befehl shutdown -s -f.

    Die VHD der übergeordneten VM wird schreibgeschütztIn der Bibliothek Virtuelle Computer löscht man nun das Symbol für die VM. Im Ordner %LocalAppdata%\Microsoft\Windows Virtual PC\Virtual Machines – wenn man keinen anderen Ort für die Virtual-PC-Daten konfiguriert hat – klickt man anschließend mit der rechten Maustaste auf die VHD-Datei der Master-VM, wählt aus dem Kontextmenü den Punkt Eigenschaften und aktiviert auf der Registerkarte Allgemein das Attribut Schreibgeschützt. Eine VM mit schreibgeschützter virtueller Festplatte kann man auch versehentlich nicht mehr starten.

    Für die abgeleiteten VMs verwendet man benutzerdefinierte VHDsIn der Bibliothek Virtuelle Computer erstellt man anschließend einen neuen virtuellen Computer über die Aufgabenleiste. Wenn der Assistent an die Stelle kommt, an der man eine virtuelle Festplatte hinzufügen soll, wählt man die Option Eine virtuelle Festplatte mithilfe erweiterter Optionen verwenden, anschließend für den Typ der VHD Differenzierend. Als übergeordnete virtuelle Festplatte gibt man die eben schreibgeschützte Festplatte des Betriebssystem-Masters an.

    Damit hat man das Äquivalent zum Kind eines Snapshots erstellt und kann dieses nun konfigurieren und verwenden. Von dem „Snapshot“ ausgehend kann man dies beliebig oft tun, die einzige Grenze sind der Plattenplatz und die Anzahl der verbrauchten Windows-Lizenzen.

    Snapshot-Hierarchien erstellen

    Abgeleitete VMs müssen jeweils ihren eigenen Netzwerknamen erhaltenEs wäre nicht sonderlich effektiv, alle weiteren VMs von einem Master zu erstellen. Denkbar ist etwa, von ihm ausgehend verschiedene abgeleitete Konfigurationen zu erstellen, die seinerseits schreibgeschützt und als übergeordnete Festplatten für weitere Ebenen dienen können.

    So könnte man etwa unter dem Master Schablonen erstellen für Konfigurationen mit Service Packs oder ohne, mit bestimmter Browser-, Firewall- oder Virenschutzkonfiguration oder in verschiedenen Sprachen. Wie viele Ebenen man am Ende benutzt, hängt von den konkreten Testerfordernissen ab.

    Welche Konfigurationsvarianten die untergeordneten Schablonen-VMs beinhalten, sollte man in Ermangelung einer Kommentarfunktion am besten direkt in den Namen der VMs hinterlegen. Das Erstellen einer VM und das Löschen nicht mehr benötigter VMs (also das Äquivalent zur Rücknahme von Änderungen) kosten insgesamt weniger Zeit als die Verwendung von Rückgängig-Datenträgern. Voraussetzung ist, die Infrastruktur der insgesamt benötigten Konfigurationen gut zu durchdenken – sonst geht Zeit beim Konfigurieren jeweils abgeleiteter VMs verloren, weil deren Schablonen zu weit entfrernt von den Erfordernissen sind oder man gar Aufwand hat, ungünstige Einstellungen der Schablonen in den davon abgeleiteten VMs immer wieder zurücknehmen zu müssen.

    Wichtig sind immer die 2 folgenden Regeln:

    • In einer neu erstellten untergeordnete VM, sei sie nun für den konkreten Testgebrauch oder als weitere Schablone bestimmt, muss man als erste Maßnahme ihren Netzwerknamen ändern, damit es zu keinen Kollisionen kommt.
    • Eine VM, die anderen als Master dient, darf nie wieder gestartet werden. Versehentlich ist dies durch das Schreibschutz-Attribut an ihrer VHD nicht möglich; tut man es absichtlich, gehen alle untergeordneten VMs verloren und können nur noch gelöscht werden.

    Keine Kommentare