Manchmal dauert es einfach länger, bis man auf die Lösung kommt. Wer zu Testzwecken sein Xen mit auf Reisen nehmen möchte und dazu Vmware Workstation/Server verwendet, hat sich sicher schon gefragt, warum eine Bridge Konfiguration innerhalb von Vmware einfach nicht funktioniert. Es ist so logisch und die Lösung noch einfacher: Xen versetzt die Netzwerkkarte bekannterweise in den Promiscuous Mode, wenn nun aber Vmware als Benutzer gestartet wird, ist es ihm nicht gestattet das Gerät /dev/vmnet0 (meist die Bridge Netzwerkkarte von Vmware) in den entsprechenden Zustand zu versetzen.

Seit ich meine letzte Xen Anleitung veröffentlicht habe, erschien gerade Xen 3.1, wobei ich persönlich 3.0.4 bevorzugt habe. Nun, Monate später schaue ich erneut nach, und wir haben Xen 3.3 – wobei mir das Erscheinen selbst natürlich nicht entgangen ist, dank Heise, Golem und Co. Doch, wenn ich mir die Liste der Funktionen anschaue, komme ich aus dem Staunen kaum heraus. Vor allem soll ja nun die Live Migration von Windows sauber funktionieren, nicht dass es mir keine Freude bereitet hätte, Windows einfach verschwinden zu sehen, aber Kunden mögen zuweilen dieses Verhalten nicht.

Da tauscht man mit einer Freundin ein paar warme Worte, und sogleich lernt man ein neues Kommando. Heute: stat denny@miyazaki ~ $ stat firewall/ File: „firewall/“ Size: 4096 Blocks: 8 IO Block: 4096 Verzeichnis Device: fe07h/65031d Inode: 17825927 Links: 3 Access: (0755/drwxr-xr-x) Uid: ( 1000/ denny) Gid: ( 1000/ denny) Access: 2008-11-08 11:03:50.430417550 +0100 Modify: 2008-11-07 15:47:59.573138808 +0100 Change: 2008-11-07 15:47:59.573138808 +0100 denny@miyazaki ~ $ stat -c %a firewall/ 755 ``