Windows 7 in vm ohne Aktivierung

Thursday, May 19. 2011

Die c't hat in Heft 2011/11 S.121 einen Tip, wie man eine windows 7 - Installation in einer virtuellen Maschine "aktivierungssicher" hinbekommt. Der sei hier kurz notiert:

win7 läuft ja 30 Tage ohne Aktivierung. Diese Karenzzeit kann man auch noch drei mal verlängern. Dazu öffnet man ein cmd-Fenster mit Admin-Rechten und gibt dort
slmgr -rearm 
ein. Dann nuddelt die Kiste etwas, bis sich ein Fenster öffnet mit dem Hinweis, der Befehl sei erfolgreich abgeschlossen und man müsse nun den Rechner neu starten. Aber genau das tut man jetzt nicht!
Tatsächlich ist nämlich nur die Umsetzung des Befehls als Task im Zuge des nächsten Boot eingetragen worden. Anschliessend wird das System 30 Tage wie aktiviert laufen.

Und jetzt macht man keinen Neustart, sondern fährt die vm stattdessen einfach runter. Anschliessend legt man einen Snapshot an (oder kopiert den aktuellen Stand der vm). Wenn man später auf diesen snapshot zurückgeht und bootet, wird mit dem boot die Zeitverlängerung ausgeführt und nach dem Bo0t hat man ein windows, dass für die nächsten 30 Tage frisch bleibt. 

Wenn die Zeit abgelaufen ist, geht man auf den Snapshot zurück und die Uhr läuft von vorn. Im Prinzip kann man das beliebig oft wiederholen, ohne dabei die drei Rearms aufzubrauchen.  Für eine vm, die nur mit Abständen, als Testsystem, angeworfen wird, ist das ein ausgesprochen praktisches Setup. (Gerade bei solchen Testsystemen verstreicht die zeitweise Aktivierung oft ungenutzt, während das System ruht, und wenn man sie dann zum Leben erweckt und das Datum lange abgelaufen ist, schwärzt sie sich ein, ehe man den nächsten Rearm vornehmen konnte.)

Dabei verliert man freilich jedesmal alle Updates und veränderten Einstellungen, man sollte also, ehe man den Snapshot anlegt, das System sorgfältig so konfigurieren, wie man es später immer wieder vorfinden möchte. Eine Möglichkeit, manche Daten und Einstellungen persistent zu halten, ist, mehr als ein einziges HD-Image in die vm einzubinden. 

Wieviele Rearm-Versuche noch übrig sind, verrät der Befehl:
slmgr -dlv 

und an welchem Datum die zeitweilige Aktivierung ausläuft, zeigt:
slmgr -xpr

Kleiner Nachtrag:

Die Festplatte  einer anderen vm war etwas klein gewaehlt und es stellte sich die Frage, wie ich sie vergroessern koennte. Ich bin dieser Anleitung gefolgt, die device names der Platten waren etwas anders aber ansonsten ging's prima.

update 25.05.2013:
den obigen Link bis ans Ende lesen! :
vboxmanage modifyhd
Diskussion dazu  und mehr

Snapper und SnapUtil

Tuesday, April 12. 2011

An earlier post described my TimeMachine-inspired SnapShot backup based on rsync and hard links downloadable there. It has been very useful for me already. You know how things can happen, I was working on a script which should empty a certain directory before writing new files there and at some point substituted the hard-coded path to that directory with a parameter, and then tested the thing forgetting to enter the path-parameter.
Thus, 
rm -rf $DEST_BASE/*  effectivly turned into 
rm -rf /*

I was so glad my last snapShot was but 70 min old.

Then I had to detail the steps and times of working on a certain project a posteriori, which files had been edited over what times on which days? A series of snapShots is basically a very good source for this kind of research, but in praxis it turned out to be uncomfortabel to always walk the pathes up and down between the parallel snapShot directories.

Typically the folders I wanted to compare always share a common relative path, like
snapShots/snap1/some/longish/and/winded/path 
snapShots/snap2/some/longish/and/winded/path 
snapShots/snap3/some/longish/and/winded/path 
and I soon started to wish I had symlinks to the destinations in a special folder. And while in some cases I want to see all the files, in other cases I'd rather only have the files that got changed between one snapShot and the next.

So I ended up creating a tool to build just this.

At the core this is a bash shell script which gets the pathes to the snapShot base, the relative path to link, the destination dir to place the symlinks in and then walks the file tree. It is supported by a gui front end that makes picking the pathes and setting the parameters so much easier.  

Together they form SnapUtil, based on Bash, Python_2.6 and wxPython. This is an early alpha version, GPL 2,  download .

(Page 1 of 1, totaling 2 entries)