XEN : DomUs einrichten

[stephanbde19]

Hallo zusammen,

bei der Einrichtung der DomU's laufe ich zur Zeit in Probleme:

Zur Einrichtung nutze ich das unter openSuSe 10.3 verfügbare "Create Virtual Machine"-Programm.

Hier wird zunächst analog die Konfig der neuen Maschine abgefragt.
Unter dem Punkt "Operating System Installation" wird man aufgefordert eine Installation Source anzugeben. Hierzu wollte ich das lokal installierte ISO nutzen, das ich auch zur Installation von VMware-VMs nutze. Leider erhalte ich hier die Fehlermeldung: "installation source is unusable". Ebenso bei der CD, wenn ich das physische CD-ROM verlinke.

Wenn ich statt Paravirtualization Full Virtualization auswähle, erhalte ich keine Fehlermeldung. Zwar öffnet sich ein VNC-Fenster und zeigt, das ein Prozeß gestartet wird, jedoch bleibt dieses Fenster (bzw. der abgebildete Prozeß) beim Laden des ISOs hängen.

In YaST2 finde ich 3 "Programme" unter "Virtualization".

1.) Create Virtual Machines -> funktioniert wie oben beschrieben nicht.
2.) Install Hypervisor and Tools -> Meldet, das Hypervisor und Tools ordnungsgemäß installiert sind.
3.) Virtual Machine Manager -> Startet nicht, und wirft auf der Konsole die Fehlermeldung:
xend [ERROR] Config file does not exist: /etc/xen/xend-config.sxp

Das File existiert aber sehr wohl. Allerdings kann ich als normaler User nicht auf den Ordner /etc/xen zugreifen, und über sudo sagt mir die Konsole, daß das Kommando "cd" nicht gefunden wurde.
Nur über "su -" komme ich ins Filesystem und kann die Existenz der Datei prüfen.

Daneben fällt mir auf, das die Physik keinen NW-Link hat, wenn sie mit dem Xen-Kernel gestartet ist.
Unter "Network Settings" sieht man, daß das eigentliche Device nicht connected ist. Daneben gibt es ein Duplikat mit der MAC FE:FF:FF:FF:FF:FF, daß ich aber nicht konfigurieren kann.

Kann mir jemand sagen was ich falsch mache, bzw. was hier noch eingerichtet werden muss?

VG

Stephan

 

[stefan.becker]

Bei mir funktioniert der Suse Krempel genauso wie bei dir.

Versuchs mal hiermit: http://gnomefiles.org/app.php/ConVirt

 

[stephanbde19]

Hi,

das ist ja beruhigend. ;-) Das conVirt-Tool scheint nur eine GUI zu sein. In dem anderen Thread erwähntest Du, daß Du Dich selbst gerade durchwurschtelst. Wie hast Du den Xen-Kernel auf das System gebracht? Greifst Du auf das mitgelieferte Package zurück, oder installierst Du alles "zu Fuß"? Falls letzteres, kannst Du mir den Link der Anleitung schicken, mit dem die Installation auf openSuSE bei Dir funktioniert hat.

VG

Stephan

 

[stefan.becker]

http://www.linuxforen.de/forums/showthread.php?t=231541

Ist noch nicht fertig.

Der Teil Paravirtualisierung und Netzwerk fehlt noch komplett. Wird aber auch noch dauern. Ist halt ein Hobby, das Leben geht vor

 

[stephanbde19]

Hi,

sehr schöne, übersichtliche Anleitung. Dann werde ich mal das ConVirt-Tools ausprobieren - heute allerdings nicht mehr. Ich habe ja noch meine Zweifel, ob das die Probleme löst, aber Versuch macht kluch!
Werde dann berichten.

Vielen Dank schonmal!

VG

Stephan

 

[stephanbde19]

Hi,

bin direkt ins erste Problem gelaufen. ConVirt benötigt Paramiko. Habe das .tar heruntergeladen und entpackt, aber keine Ahnung, wie ich dies nun installieren soll.
Der Aufruf von ./setup.py wirft die Fehlermeldung

line20: longdesc: command not found

Wie hast Du das Programm installiert?

VG

Stephan

Btw.: Habe heute auch versucht, VMs "zu Fuß" ans laufen zu kriegen. Bis zum "create" klappts, aber danach geht nichts mehr....

 

[stefan.becker]

zypper install python-paramiko

Gibt es bei PackMan.

 

[pft]

Hi,

ich finde es interessant was es alles so an Tools gibt, auch wenn sie dann oft gar nicht funktionieren.

meine Erfahrung war aber, dass es - zumindest solange man Suse als Host und gast verwendet - auch ohne spezielle Tools gut geht.

Wenn ich mich recht erinnere bin ich weitgehend nach dieser Anleitung vorgegangen: http://en.opensuse.org/Installing_Xen3

In der c't gabs damals auch ein paar Tipps aber ich meine die brauchte man inzwischen nicht mehr. Der Support bei Suse ist ja mittlerweile ausrecichend.

Im Prinzip ist der Ablauf wie folgt:
0. Im Host den Xen-kernel und die xen-tools installieren
1. Image dateien für die Partitionen des Hostsystems anlegen
2. Suse in ein directory installieren (in die gemountete Imagedatei)
3. Configdateien erstellen
4. Gast starten
5. Bingo

Das ist natürlich nur ein Minimalsystem. Komplizierte Konfigurationen (Netzwerk, PCI-Karten etc.) kann man dann darauf aufsetzen

Edit: unter http://en.opensuse.org/HOWTOs findet sich im Kaptel XEN eine ganze Reihe von weiteren HowTo's - könnte einen Blick wert sein

 

[stephanbde19]

Hallo zusammen,

lieben Dank erstmal für Eure Infos!

zypper install python-paramiko

Gibt es bei PackMan.

ok, mit einigen Haken und Ösen hat das nun geklappt. Ich kann ConVirt starten.

Nun würde ich gerne eine VM mit openSuSE anlegen. Idealerweise kann ich hierfür später ein VMware-Image importieren, aber fürs Erste wäre ich schon begeistert, überhaupt eine Xen-VM ans Fliegen zu kriegen.

Ich gehe also in den "Provision VM"-Dialog. Dort kann ich zwischen CentOS-PV-install und Fedora_PV_install wählen. Ich möchte aber ja SuSE, also wähle ich Linux_CD. In dem Moment bin ich schon automatisch auf den HVMLoader festgelegt.

Ich würde zwecks Performance aber eigentlich lieber eine paravirtualisierte Maschine nutzen.

Ich versuche es trotzdem mal mit der HVM-Maschine, linke das physische CD-ROM, lege die CD ein und starte die VM.

In der Konsole sehe ich, daß die VM bootet, aber beim Laden der CD bleibt sie hängen.

Wäre es denkbar, daß ich gar nicht über eine HVM-fähige CPU verfüge?
Lt. "dmesg" habe ich eine
Intel® 2 Core(TM) Duo processor E6750

, was ich gem.
http://wiki.xensource.com/xenwiki/HVM_Compatible_Processors

gelten lassen würde. Sollte also nicht das Problem sein. Das Verhalten entspricht aber dem SuSE-eigenen Create Virtual Machine Wizard, der ebenfalls für HVM-Maschinen im Boot des Linux hängen bleibt.


Nun habe ich einfach spaßeshalber mal eine CentOS-VM mit Default-Einstellungen angelegt. Beim Startversuch erhalten ich die Fehlermeldung, daß der

guest type xen-3.0x86_32p not supported by xen kernel

ist.

Bin ich hier irgendwie auf dem Holzweg?? Ich möchte doch nur einen openSuSE-Gast auf einem openSuSE-Host....

meine Erfahrung war aber, dass es - zumindest solange man Suse als Host und gast verwendet - auch ohne spezielle Tools gut geht.

Wenn ich mich recht erinnere bin ich weitgehend nach dieser Anleitung vorgegangen: http://en.opensuse.org/Installing_Xen3

Ok, den Xen-Server habe ich direkt bei der Installation hinzugefügt. Ich würde allerdings ungern ein eigenes Filesystem für die DomU anlegen, sondern viel lieber ein Diskfile analog zu VMware nutzen.

In der c't gabs damals auch ein paar Tipps aber ich meine die brauchte man inzwischen nicht mehr. Der Support bei Suse ist ja mittlerweile ausreichend.

Habe einen recht aktuellen c't_Artikel studiert. Leider ohne Erfolg, da die DomUs immer noch nicht sauber starten, bzw. per Konsolenbefehl keine Verbindung zulassen.
Und welchen Support bei SuSE meinst Du? Habe seit 1 Woche eine Anfrage in beiden Mailing-Lists gestartet - ohne Erfolg. Gibt es noch andere Supportkanäle?

Im Prinzip ist der Ablauf wie folgt:
0. Im Host den Xen-kernel und die xen-tools installieren
1. Image dateien für die Partitionen des Hostsystems anlegen
2. Suse in ein directory installieren (in die gemountete Imagedatei)
3. Configdateien erstellen
4. Gast starten
5. Bingo

Das ist natürlich nur ein Minimalsystem. Komplizierte Konfigurationen (Netzwerk, PCI-Karten etc.) kann man dann darauf aufsetzen

Welche Image-Dateien für die Partitionen des Hostsytems meinst Du unter 2.)? Meinst Du eine Image-Platte für die DomUs? Das habe ich getan. Leider klappt Schritt 3 nicht, bzw. ich habe keine Ahnung, wie ich das anstellen soll.....

Edit: unter http://en.opensuse.org/HOWTOs findet sich im Kaptel XEN eine ganze Reihe von weiteren HowTo's - könnte einen Blick wert sein.

Habe ich schon gesichtet, leider setzen die funktionierende Tool wie den Virtual Machine Manager voraus - was ja bei mir nicht gegeben ist...

VG

Stephan

 

[pft]

Ich würde allerdings ungern ein eigenes Filesystem für die DomU anlegen, sondern viel lieber ein Diskfile analog zu VMware nutzen.

Du brauchst defintiv für jedes Linuxsystem ein eigens Filesystem. Ob das nun virtuell ist oder nicht. Für VMware gilt das genauso.
Der Punkt ist nur, dass Du bei virtuellen Systemen typischerweise keine realen Platten und Partitionen einsetzt sondern diese als Datei im Filesystem des Host anlegst.
Vorteil von xen ist, dass du auch reale Partitionen nutzen kannst. In anderen Virtualisierern geht das nicht oder nur bedingt.
Um es nochmal deutlich zu machen: Du brauchst definitiv für jede domU eine eigenen Installation.

Welche Image-Dateien für die Partitionen des Hostsytems meinst Du unter 2.)? Meinst Du eine Image-Platte für die DomUs? Das habe ich getan. Leider klappt Schritt 3 nicht, bzw. ich habe keine Ahnung, wie ich das anstellen soll.....

der erste Punkt ist mit obiger Erklärung wohl klar, oder?. Die Configdateien kannst Du doch einfach aus dem HowTo abtippen (bzw. copy-paste). Dabei bitte das Hirn eingeschaltet lassen und reale Parameter DEINER Umgebung einsetzen (IP-Adr., Dateinanemen etc.) (ist nicht persönlich gemeint - ich hatte da nur dieser Tage so einen Fall). Das ist aber recht schön erklärt.

Habe ich schon gesichtet, leider setzen die funktionierende Tool wie den Virtual Machine Manager voraus - was ja bei mir nicht gegeben ist...

Was geht denn da nicht? Wenn das xm tool nicht läuft, dann helfen dir womöglich auch keine anderen Tools, weil die Probleme wahrscheinlich tiefer liegen. Im übrigen muss das xm tool Fehler ausspucken, wenn deine config noch nicht steht.

Hast Du Zugriff auf alte c'ts? Dann würde ich Dir den besagten Artikel noch mal raussuchen - so ich ihn finde.

 

[stephanbde19]

Ich würde allerdings ungern ein eigenes Filesystem für die DomU anlegen, sondern viel lieber ein Diskfile analog zu VMware nutzen.

Du brauchst defintiv für jedes Linuxsystem ein eigens Filesystem. Ob das nun virtuell ist oder nicht. Für VMware gilt das genauso.
Der Punkt ist nur, dass Du bei virtuellen Systemen typischerweise keine realen Platten und Partitionen einsetzt sondern diese als Datei im Filesystem des Host anlegst.
Vorteil von xen ist, dass du auch reale Partitionen nutzen kannst. In anderen Virtualisierern geht das nicht oder nur bedingt.
Um es nochmal deutlich zu machen: Du brauchst definitiv für jede domU eine eigenen Installation.

Ich glaube, ich habe mich da ein wenig mißverständlich ausgedrückt. Ich will ja eigentlich explizit eine eigene Installation. Das Lesen diverser Tutorials hat mich inzwischen allerdings fast so weit verwirrt, daß ich dachte, daß auf Kernel-Ressourcen des Hosts zurückgegriffen wird. Im Bsp. im von Dir genannten Link wird ja im Konfig-File der VM auch auf den Kernel des Hosts verwiesen:

# kernel und initrd:
kernel = "/boot/vmlinuz-xen"
ramdisk = "/boot/initrd-xen"

Von daher wird doch auf den Kernel des Hosts zugegriffen, und die VM verfügt nicht über eine vollständige Installation, oder?

Was ich meinte, war daß ich kein eigenes Volume anlegen möchte, wie in der Anleitung beschrieben:

lvcreate -L 8g -n root xenvg

mkfs -t reiserfs /dev/xenvg/root
mkdir /var/tmp/dirinstall
mount -t reiserfs /dev/xenvg/root /var/tmp/dirinstall

sondern gerne ein File à la .vmdk hätte. D.h.

1. Maschine anlegen
2. Plattenfile anhängen
3. CD am liebsten als ISO ins virt. CD-ROM hängen.
4. VM starten
5. Konsole öffnen und installieren wie auf einer Physik.

So kenn ich es von VMware (auf Windows und Linux), aber irgendwie läuft das für Xen bei mir nicht...

Welche Image-Dateien für die Partitionen des Hostsytems meinst Du unter 2.)? Meinst Du eine Image-Platte für die DomUs? Das habe ich getan. Leider klappt Schritt 3 nicht, bzw. ich habe keine Ahnung, wie ich das anstellen soll.....

der erste Punkt ist mit obiger Erklärung wohl klar, oder?. Die Configdateien kannst Du doch einfach aus dem HowTo abtippen (bzw. copy-paste). Dabei bitte das Hirn eingeschaltet lassen und reale Parameter DEINER Umgebung einsetzen (IP-Adr., Dateinanemen etc.) (ist nicht persönlich gemeint - ich hatte da nur dieser Tage so einen Fall). Das ist aber recht schön erklärt.

Nein, kann da vollkommen mit umgehen, wenn mir einer sagt, daß ich ein Brett vor dem Kopf habe - dann merke ich das wenigstens auch ;-)

Ich glaube, IP-Adressen sind mein geringstes Problem. Die Maschinen laufen ja kaum sauber an, sodaß es gar nicht erst zu Konflikten kommen kann.

Unter Schritt 2 gehe ich davon aus, daß meine Suggestion, daß die Festplattendatei der DomU gemeint ist, richtig ist. Die Konfig unter Schritt 3 habe ich ja schon per copy & paste übernommen und per xm create eingebunden. Unter xm list taucht die neue Maschine auch auf. Allerdings bewirken die Befehle xm console und xm shell nichts - ich komme einfach nicht auf die Maschine.

Den gleichen Effekt habe ich unter Verwendung des von Stefan empfohlenen ConVirt. Ich kann eine Maschine anlegen (xm create), aber nicht vernünftig verwenden....

Habe ich schon gesichtet, leider setzen die funktionierende Tool wie den Virtual Machine Manager voraus - was ja bei mir nicht gegeben ist...

Was geht denn da nicht? Wenn das xm tool nicht läuft, dann helfen dir womöglich auch keine anderen Tools, weil die Probleme wahrscheinlich tiefer liegen. Im übrigen muss das xm tool Fehler ausspucken, wenn deine config noch nicht steht.

Habe ich ja oben schon teilweise beantwortet. Ich habe ein blankes openSuSE vom Scratch installiert und dabei direkt den XenServer mitinstalliert. Create Virtual Machine liefert ähnliche Probleme wie ConVirt (wobei ich bei paravirtualisierten Maschinen noch nicht sicher bin, ob ich vielleicht zu blöd bin, die geforderten Eingaben zu machen). Der Virtual Machine Manager startet gar nicht. xm Befehle funktionieren prinzipiell, aber auch da kriege ich keine Konsole...

Ich glaube ja auch fast, daß die Probleme tiefer liegen aber

a) kann ich die Installation nicht verwurstet haben, sodaß mir eine Neuinstallation nichts hilft.
b) habe ich keine Ahnung, wie ich das Problem analysieren kann, was ja auch meine eigentliche Ausgangsfrage war. Beruhigend war für mich, daß Stefan prinzipiell die Probleme kannte, und ich nicht alleine damit stehe...

Hast Du Zugriff auf alte c'ts? Dann würde ich Dir den besagten Artikel noch mal raussuchen - so ich ihn finde.

Ja, ich habe alle Artikel bis 13/07 auf CD. Ein Artikel der mir ein gewisses Grundverständnis gebracht hat (auch mit Bsp. und mir die xm-Befehle erklärt hat), ist "Leichte LinuXen von Peter Siering in ct 08/07, S. 184 ff.


Sorry, daß ich Euch so auf die Nerven gehe! Vielleicht liegts nur an meiner "VMware-Blindheit", aber der zündende Funke will nicht überspringen.....


VG

Stephan

 

[pft]

Von daher wird doch auf den Kernel des Hosts zugegriffen, und die VM verfügt nicht über eine vollständige Installation, oder?

Mitnichten! wenn du die Stelle in der config für die VM meinst dann zeigt die ja auf "/" bzw. "/boot" des Dateisystems der VM und nit des Host. Watchout: beide haben eine Wurzel ("/")!

sondern gerne ein File à la .vmdk hätte. D.h.

Tja, das geht auch so. Ich glaube das war die Vereinfachung aus dem c't Artikel. LVM ist ja nett aber nicht notwendig. So ganz grob aus dem Kopp rekapituliert kannst DU auch einfach ein touch auf eine neue Datei machen und dann darin ein Filesystem anlegen mit mkfs. Details müsstest Du nochmal recherchieren - oder mir etwas Zeit geben huete abend zum suchen.

BTW, das opensuse howto wurde auch seit meinen Versuchen überarbeitet (-> history)

Nein, kann da vollkommen mit umgehen, wenn mir einer sagt, daß ich ein Brett vor dem Kopf habe - dann merke ich das wenigstens auch

Ich hatte die Tage eine Kollegen der hat aus einem hilfreichen Link Sachen wie "www.example.com" und "test.cfg" buchstabengetreu abgetippt.

Ich glaube, IP-Adressen sind mein geringstes Problem. Die Maschinen laufen ja kaum sauber an, sodaß es gar nicht erst zu Konflikten kommen kann.

War nur ein Beispiel. Aber werd' doch mal konkret. Solche Meldungen lieben wir hier gar nicht. Wir stehen mehr auf copy paste von Bildschrimausgaben inkl. der verusrsachenden Eingabe

Allerdings bewirken die Befehle xm console und xm shell nichts - ich komme einfach nicht auf die Maschine.

Hab ich nie benutzt - gibt es die überhaupt?
"shell" zumindest nicht - laut meiner man page.
Und bei "console" heisst es da:

This uses the back end xenconsole service which currently only works for para-virtual domains.

Wenn die VM laut "xm list" laufen ist das doch schon mal gut.
Wenn nicht hilft ein "xm -c create ..." um direkt in die Konsole der VM zu wechseln.
Ansonsten würde ich mit ssh auf die vm zugreifen, meinetwegen auch mit telnet, wenns dennsein muss.
Aber Du kannst ja erstmal mit so einfachen Sachen wie "ping" anfangen.

Sorry, daß ich Euch so auf die Nerven gehe! Vielleicht liegts nur an meiner "VMware-Blindheit", aber der zündende Funke will nicht überspringen.....

Mal nicht so ungeduldig, ich habe den Eindruck es brennt schon ganz nett, Du hast es nur noch nicht gemerkt

 

[pft]

Zitat:
Von daher wird doch auf den Kernel des Hosts zugegriffen, und die VM verfügt nicht über eine vollständige Installation, oder?

Mitnichten! wenn du die Stelle in der config für die VM meinst dann zeigt die ja auf "/" bzw. "/boot" des Dateisystems der VM und nit des Host. Watchout: beide haben eine Wurzel ("/")!

Muss mich da korrigieren - ist schon etwas her dass ich damit gespielt habe.
Das bezieht sich wirklich auf das Hostdateisystem - du hattest recht.
Die Anleitung behandelt steng genommen einen Sonderfall, nämlich dass Host und Guest den gleichen Kernel verwenden.

Das muss aber nicht so sein. Allgemein würde man die Kernels für die VMs separat ablegen, z.B. in /boot/vm1, /boot/vm2 ...
Trotzdem müssen sie für den Host zugänglich sein. Sonsts könnte der sie ja nicht starten. Genauso wie der Kernel des Host für grub zugänglich sein muss.

 

[stephanbde19]

Von daher wird doch auf den Kernel des Hosts zugegriffen, und die VM verfügt nicht über eine vollständige Installation, oder?

Mitnichten! wenn du die Stelle in der config für die VM meinst dann zeigt die ja auf "/" bzw. "/boot" des Dateisystems der VM und nit des Host. Watchout: beide haben eine Wurzel ("/")!

Hm, das ist ja schonmal beruhigend. Aber auf was in der virtuellen Festplatte verweist der Eintrag denn dann, wenn diese noch leer ist? Aus der VMware-Welt habe ich die Vorstellung mitgenommen, daß eine VM erstmal wie ein Rechner aus dem Laden ohne Dateisystem auf der Platte ist. Das FS kommt dann bei der Installation drauf. Denke ich da falsch?

sondern gerne ein File à la .vmdk hätte. D.h.

Tja, das geht auch so. Ich glaube das war die Vereinfachung aus dem c't Artikel. LVM ist ja nett aber nicht notwendig. So ganz grob aus dem Kopp rekapituliert kannst DU auch einfach ein touch auf eine neue Datei machen und dann darin ein Filesystem anlegen mit mkfs. Details müsstest Du nochmal recherchieren - oder mir etwas Zeit geben huete abend zum suchen.

Also die Datei habe ich schon. Die legt mir der Wizard beim Versuch, eine HVM-VM anzulegen an. Die habe ich nun einfach für die Versuche zu Fuß kopiert (sollte ja leer sein)

BTW, das opensuse howto wurde auch seit meinen Versuchen überarbeitet (-> history)

ok, schade!

Nein, kann da vollkommen mit umgehen, wenn mir einer sagt, daß ich ein Brett vor dem Kopf habe - dann merke ich das wenigstens auch

Ich hatte die Tage eine Kollegen der hat aus einem hilfreichen Link Sachen wie "www.example.com" und "test.cfg" buchstabengetreu abgetippt.

Ok, ich bin nicht Informatik-blöd, sondern nur Linux- und Xen-blöd. ;-)

Ich glaube, IP-Adressen sind mein geringstes Problem. Die Maschinen laufen ja kaum sauber an, sodaß es gar nicht erst zu Konflikten kommen kann.

War nur ein Beispiel. Aber werd' doch mal konkret. Solche Meldungen lieben wir hier gar nicht. Wir stehen mehr auf copy paste von Bildschrimausgaben inkl. der verusrsachenden Eingabe

Liefere ich nach, wenn ich daheim bin.

Allerdings bewirken die Befehle xm console und xm shell nichts - ich komme einfach nicht auf die Maschine.

Hab ich nie benutzt - gibt es die überhaupt?
"shell" zumindest nicht - laut meiner man page.
Und bei "console" heisst es da:

This uses the back end xenconsole service which currently only works for para-virtual domains.

Wenn die VM laut "xm list" laufen ist das doch schon mal gut.
Wenn nicht hilft ein "xm -c create ..." um direkt in die Konsole der VM zu wechseln.
Ansonsten würde ich mit ssh auf die vm zugreifen, meinetwegen auch mit telnet, wenns dennsein muss.
Aber Du kannst ja erstmal mit so einfachen Sachen wie "ping" anfangen.

Ja, die Befehle habe ich kennengelernt, als ich nur "xm" eingegeben habe - dann werden Sie in der Liste neben "create" etc. aufgeführt.

Mit ssh und ping hast Du mich aber ein wenig abgehangen... Ich möchte die Systeme doch eigentlich erstmal installieren. Wie können Sie da im Netz hängen?? (das muß jetzt fürchterlich dumm nennen, aber die Verzweiflung ist schon lange größer als jede Scham...)

Sorry, daß ich Euch so auf die Nerven gehe! Vielleicht liegts nur an meiner "VMware-Blindheit", aber der zündende Funke will nicht überspringen.....

Mal nicht so ungeduldig, ich habe den Eindruck es brennt schon ganz nett, Du hast es nur noch nicht gemerkt

Diese Hoffnung habe ich auch noch, jetzt warte ich noch auf den, der mich erleuchten kann. Ich schlage mich seit gut 2 Monaten nicht mit meiner eigentlichen Aufgabe, sondern nur mit dem Weg dorthin herum....

VG

Stephan

 

[pft]

Mit ssh und ping hast Du mich aber ein wenig abgehangen... Ich möchte die Systeme doch eigentlich erstmal installieren. Wie können Sie da im Netz hängen?? (das muß jetzt fürchterlich dumm nennen, aber die Verzweiflung ist schon lange größer als jede Scham...)

Nach deiner Schlderung hatte ich den Eindruck die VM läuft, du kommst nur nicht ran. Und ein Linux ohne Netzanbindung ist wie ein kastrierter Kater, will sagen Netzanbindung ist für Linux völlig normal. Und für eine VM gilt das dreimal, denn für was anderes ist sie mangels graf. Oberfläche kaum zu brauchen.
Als Nichtinformatik-Blöder weißt Du ja das ohne input und oihne output Informationsverarbeitung relativ wenig Sinn macht ;-)

BTW, hab gerade noch 'nen alten Zettel gefunden. Dort steht wie man zu Fuß die image Datei erzeugt (die leere wohlgemerkt):

dd if=/dev/zero of=disk.img bs=1k seek=2048k count=1
mkfs -t ext3 disk.img

Befüllen kann man es auch durch kopieren vom Host, wenn man ohnehin das gleiche System einsetzt.
Nur fstab, hostname und so ein par Geschichten muss man dann noch anpassen.[/code]

 

[stephanbde19]

Muss mich da korrigieren - ist schon etwas her dass ich damit gespielt habe.
Das bezieht sich wirklich auf das Hostdateisystem - du hattest recht.
Die Anleitung behandelt steng genommen einen Sonderfall, nämlich dass Host und Guest den gleichen Kernel verwenden.

Das muss aber nicht so sein. Allgemein würde man die Kernels für die VMs separat ablegen, z.B. in /boot/vm1, /boot/vm2 ...
Trotzdem müssen sie für den Host zugänglich sein. Sonsts könnte der sie ja nicht starten. Genauso wie der Kernel des Host für grub zugänglich sein muss.

Hm, daß der Kernel für den Host in irgendeiner Form zum Boot zugreifbar sein muß, ist mir klar. Ist ja bei VMware letztlich auch nicht anders. Aber da kann ich auch eine leere Platte ohen Kernel booten (freilich ohne tieferen Sinn).

Nach deiner Schlderung hatte ich den Eindruck die VM läuft, du kommst nur nicht ran. Und ein Linux ohne Netzanbindung ist wie ein kastrierter Kater, will sagen Netzanbindung ist für Linux völlig normal. Und für eine VM gilt das dreimal, denn für was anderes ist sie mangels graf. Oberfläche kaum zu brauchen.
Als Nichtinformatik-Blöder weißt Du ja das ohne input und oihne output Informationsverarbeitung relativ wenig Sinn macht

Schon richtig, aber wieso sollte ich keine normale Konsole haben?? Eine VMware-VM liefert mir ja auch eine wunderbare Konsole, über die ich dann ein OS installieren und die VM ins Netz bringen kann.

BTW, hab gerade noch 'nen alten Zettel gefunden. Dort steht wie man zu Fuß die image Datei erzeugt (die leere wohlgemerkt):
Code:
dd if=/dev/zero of=disk.img bs=1k seek=2048k count=1
mkfs -t ext3 disk.img

Befüllen kann man es auch durch kopieren vom Host, wenn man ohnehin das gleiche System einsetzt.
Nur fstab, hostname und so ein par Geschichten muss man dann noch anpassen.

An der Stelle wird es mir endgültig zu obskur....mir ist schleierhaft, wieso ich ein FS auf einer leeren Platte anlegen muß, und womit ich das VM-FS befüllen soll. (nicht schlagen, bin Linux-doof). Das klingt mir nicht mehr nach einer VM, sondern mehr nach einem VPS `a la Virtuozzo o.ä.

Ich muß mich erstmal entschuldigen, daß ich so lange mit Rückmeldung gebraucht habe, aber ich habe gestern einen Quantensprung vollzogen und eine erste DomU ans Laufen gebracht, Deswegen wollte ich auch nicht mit Zwischenfehlern nerven.

Casus cnactus war scheinbar, daß ich die VM mit der CD booten wollte. Die enthält aber wohl keinen paravirtualisierungsfähigen Kernel. Mit der DVD funktioniert es einwandfrei. Warum die HVM nicht laufen - keine Ahnung!

Jedenfalls habe ich meine ersten DomUs ganz klassisch wie unter VMware installiert (also keinerlei Befüllungen aus dem Wirts-OS o.ä., weswegen mir das auch wie Hexenwerk erscheint). Da der Virtual Machine Manager nicht läuft und auch ConVirt nicht immer das gewünschte Ergebnis lieferte, bedurfte es einiger Haken und Ösen - aber ich habe nun 2 VMs, die einen wunderschönen Cluster bilden.
Insofern bin ich völlig bei Dir: Sobald ich die Dinger im Netz hatte wars wundervoll.

2 Probleme konnte ich allerdings nicht lösen:

1. Die Gast-OS in den DomUs verwenden ein merkwürdiges Keyboard-Layout. 'y' und 'z' sind vertauscht, aber es ist auch kein englisches oder amerikanisches Layout. In der Systemsteuerung ist auch ein deutsches Layout eingestellt. Kennt jmd. den Effekt und was kann man tun? Die DomUs sind so nur über PuTTY zu gebrauchen....

2. Ich habe 2 baugleiche physische Maschinen, die für die Clustertests dienen. Ich teste hierbei zunächst beide VMs auf einem Eisen und dann auf physisch getrennten Maschinen. Bei den VMware VMs habe ich hierfür einfach eine der beiden VMs auf die andere Physik kopiert, gestartet, fertig.
Das müßte ja mit Xen-DomUs auch möglich sein. Wenn ich die Maschine aber herüberkopiert habe, d.h. Diskfile und folgendes Konfigfile:

name="test2"
ostype="opensuse"
uuid="e8fa2bfb-54c9-440a-43fa-a58b361ce80e"
memory=512
vcpus=1
on_crash="destroy"
on_poweroff="destroy"
on_reboot="restart"
localtime=0
builder="linux"
bootloader="/usr/lib/xen/boot/domUloader.py"
bootargs="--entry=xvda2:/boot/vmlinuz-xen,/boot/initrd-xen"
extra=" "
disk=[ 'file:/var/lib/xen/images/mpichxentest2/disk0,xvda,w', ]
vif=[ 'mac=00:16:3e:00:00:02', ]
vfb=['type=vnc,vncunused=1']

kann ich die DomU auf der anderen Maschine nicht starten.

Sowohl ConVirt als auch die Konsole liefern die Fehlermeldung:

mpiphysicaltest2:~ # /usr/sbin/xm create /etc/xen/vm/test2 -c
Using config file "/etc/xen/vm/test2".
Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n')

Das verstehe ich nicht: gleiche HW, gleiches OS, gleicher Xen-Kernel....
Was muß man beim Herüberkopieren beachten???


Danke und VG

Stephan

 

[pft]

Hst Du evtl. unterschiedliche kernel auf den Hosts?
Was sagt den jeweils "uname -a".

Was mich irritiert ist, dass Du weder kernerl noch ramdisk in der KOnfig angegeben hast. Dafür ein unter "bootloader" Pythonskript, das ich nicht kenne. Kannst Du das mal posten? Oder ist das normale 10.3 Ausstattung?= Ich arbeite nämlich derzeit noch mit 10.2.

Zu deinen anderen Fragen, soweit es nicht zu weit führt:
Aber da kann ich auch eine leere Platte ohne Kernel booten (freilich ohne tieferen Sinn).

Das ist nicht nur sinnlos sondern auch unmöglich. Du kannst bestenfalls mit dem vmware player einen leere PC booten, aber weit kommst Du damit nicht. Das ist halt der Unterschied zwischen den Konzepten. vmware player virtualisiert einen ganzen PC - xen nicht.

Schon richtig, aber wieso sollte ich keine normale Konsole haben?? Eine VMware-VM liefert mir ja auch eine wunderbare Konsole, über die ich dann ein OS installieren und die VM ins Netz bringen kann.

WMware verfolgt ein anders Konzept - siehe oben. Da aber xen keinen ganzen PC, also auch keine Grafikkarte emuliert ists damit Essig - außer mit xm console bei paravirtualisierten System. Da ist man dank Einbindung von Teilen von qemu wieder auf dem vmware level.

An der Stelle wird es mir endgültig zu obskur....mir ist schleierhaft, wieso ich ein FS auf einer leeren Platte anlegen muß, und womit ich das VM-FS befüllen soll.

Jetzt stehst Du ein bisserl auf der Leitung
Du kannst jedem virtualisierten System, ob vmware oder xen entweder eine echte Platte bzw Partition oder eine virtuelle, also eine Datei als Speicher geben. Aussehen tun sie alle gleich: sie enthalten ein Filesystem.
Also entweder legst Du eine Partition an und darin ein filesystem oder eine Datei und darin ein Filesystem - erkennst Du die Parallele?
Das eine bindest Du in die VM mit "disk = ['phy:..." ein, das andere mit "disk = ['file:..."
Leer sind sie alle solange Du sie nicht füllst

Casus cnactus war scheinbar, daß ich die VM mit der CD booten wollte. Die enthält aber wohl keinen paravirtualisierungsfähigen Kernel. Mit der DVD funktioniert es einwandfrei. Warum die HVM nicht laufen - keine Ahnung!

Ich auch nicht. Habe noch nie gehört, dass man eine Xen VM on CD/DVD booten kann. Würde mich interessieren.

 

[stephanbde19]

Hst Du evtl. unterschiedliche kernel auf den Hosts?
Was sagt den jeweils "uname -a".

stephan@mpiphysicaltest1:~> uname -a
Linux mpiphysicaltest1 2.6.22.17-0.1-xen #1 SMP 2008/02/10 20:01:04 UTC i686 i686 i386

GNU/Linux
stephan@mpiphysicaltest1:~> uname -r
2.6.22.17-0.1-xen

stephan@mpiphysicaltest2:/usr/lib/xen/boot> uname -a
Linux mpiphysicaltest2 2.6.22.17-0.1-xenpae #1 SMP 2008/02/10 20:01:04 UTC i686 i686 i386

GNU/Linux
stephan@mpiphysicaltest2:/usr/lib/xen/boot> uname -r
2.6.22.17-0.1-xenpae

Mich irritiert, daß der 2. die PAE-Extension hat. Wie gesagt, die Maschinen sind baugleich

und extra vom Scratch installiert. Also keine verwursteten Altinstallationen. Könnte das

"PAE" die Portierbarkeit einschränken?

Was mich irritiert ist, dass Du weder kernerl noch ramdisk in der KOnfig

angegeben hast. Dafür ein unter "bootloader" Pythonskript, das ich nicht kenne. Kannst Du

das mal posten? Oder ist das normale 10.3 Ausstattung?= Ich arbeite nämlich derzeit noch mit

10.2.

Tjoar, also mich kann das nicht irritieren, da ich das Konzept scheinbar noch nicht ganz

geblickt habe. Es ist aber eine normale Installation von der 10.3er-CD - wobei ich nicht

beurteilen kann, was normale 10.3 Ausstattung ist.

Hier das Skript:

#!/usr/bin/env python
# domUloader.py
"""Loader for kernel and (optional) ramdisk from domU filesystem

Given a physical disk (or disk image) for a domU and the path of a kernel and
optional ramdisk, copies the kernel and ramdisk from the domU disk to a
temporary location in dom0.

The --entry parameter specifies the location of the kernel (and optional
ramdisk) within the domU filesystem. dev is the disk as seen by domU.
Filenames are relative to that filesystem.

The disk is passed as the last parameter. It must be a block device or raw
disk image. More complex disk images (QCOW, VMDK, etc) must already be
configured via blktap and presented as a block device.

The script writes an sxpr specifying the locations of the copied kernel and
ramdisk into the file specified by --output (default is stdout).

Limitations:
- It is assumed both kernel and ramdisk are on the same filesystem.
- domUs might use LVM; the script currently does not have support for setting
up LVM mappings for domUs; it's not trivial and we might risk namespace
conflicts. If you want to use LVM inside domUs, set up a small non-LVM boot
partition and specify it in bootentry.

The script uses kpartx (multipath-tools) to create mappings for devices that
are exported as whole disk devices that are partitioned.

(c) 01/2006 Novell Inc
License: GNU GPL
Author: Kurt Garloff <garloff@suse.de>
"""

import os, sys, getopt
from stat import *
from xen.xend import sxp
import tempfile
import time

# Global options
quiet = False
verbose = False
dryrun = False
tmpdir = '/var/lib/xen/tmp'
in_args = ''
# kpartx, left to its own devices, does not consistently pick the
# same partition separator. Explicitly specify it.
kpartx_args = '-p -part'

# Helper functions

def error(s):
print >> sys.stderr, "domUloader error: %s" % s

def verbose_print(s):
if verbose:
print >> sys.stderr, "domUloader: %s" % s

def traildigits(strg):
"""Return the trailing digits, used to split the partition number off"""
idx = len(strg)-1
while strg[idx].isdigit():
if len == 0:
return strg
idx -= 1
return strg[idx+1:]

def getWholedisk(part):
while len(part) and part[len(part)-1].isdigit():
part = part[:-1]
return part

#def isWholedisk(domUname):
# """Determines whether dev is a wholedisk dev"""
# return not domUname[-1:].isdigit()

class Wholedisk:
"Class representing a whole disk that may have partitions"
def __init__(self, vdev, pdev):
"c'tor: set up"
# Initialize object; will not raise:
self.ldev = None
self.vdev = vdev
self.pdev = pdev
self.mapped = 0
self.partitions = []
self.pcount = 0
# Finish initialization; may raise:
self.is_blk = (S_ISBLK(os.stat(pdev)[ST_MODE]))
self.pcount = self.scanpartitions()

def physdev(self):
"""Gets the physical device used to access the device from dom0"""
if self.ldev:
return self.ldev
return self.pdev

def findPart(self, vdev):
"Find device dev in list of partitions"
if len(vdev) > 5 and vdev[:5] == "/dev/":
vdev = vdev[5:]
for part in self.partitions:
if vdev == part.vdev:
return part
return None

def loopsetup(self):
"""Sets up the loop mapping for a disk image.

Will raise if no loopbacks are available.
"""
if not self.is_blk and not self.ldev:
# Loops through all loopback devices, attempting to
# find a free one to set up. Don't scan for free and
# then try to set it up as a separate step - too racy!
i = 0
while True:
ldev = '/dev/loop%i' % (i)
if not os.path.exists(ldev):
break
i += 1
fd = os.popen("losetup %s '%s' 2> /dev/null" % (ldev, self.pdev))
if not fd.close():
verbose_print("losetup %s '%s'" % (ldev, self.pdev))
self.ldev = ldev
break
if not self.ldev:
raise RuntimeError("No free loop device found")

def loopclean(self):
"""Delete the loop mapping.

Will never raise.
"""
if self.ldev:
verbose_print("losetup -d %s" % self.ldev)
# Even seemingly innocent queries like "losetup /dev/loop0"
# can temporarily block the loopback and cause transient
# failures deleting the loopback, hence the retry logic.
retries = 10
while retries:
fd = os.popen("losetup -d %s" % self.ldev)
if not fd.close():
self.ldev = None
break
else:
time.sleep(0.1)
retries -= 1

def scanpartitions(self):
"""Scan device for partitions (kpartx -l) and set up data structures,
Returns number of partitions found."""
self.loopsetup()
# TODO: We could use fdisk -l instead and look at the type of
# partitions; this way we could also detect LVM and support it.
fd = os.popen("kpartx %s -l '%s'" % (kpartx_args, self.physdev()))
pcount = 0
for line in fd.readlines():
line = line.strip()
verbose_print("kpartx -l: %s" % (line,))
(pname, params) = line.split(':')
pname = pname.strip()
pno = int(traildigits(pname))
#if pname.rfind('/') != -1:
# pname = pname[pname.rfind('/')+1:]
#pname = self.pdev[:self.pdev.rfind('/')] + '/' + pname
pname = "/dev/mapper/" + pname
verbose_print("Found partition: vdev %s, pdev %s" % ('%s%i' % (self.vdev, pno),

pname))
self.partitions.append(Partition(self, '%s%i' % (self.vdev, pno), pname))
pcount += 1
fd.close()
if not pcount:
if self.ldev:
ref = self
else:
ref = None
self.partitions.append(Partition(ref, self.vdev, self.pdev))
return pcount

def activatepartitions(self):
"Set up loop mapping and device-mapper mappings"
if not self.mapped:
self.loopsetup()
if self.pcount:
verbose_print("kpartx %s -a '%s'" % (kpartx_args, self.physdev()))
fd = os.popen("kpartx %s -a '%s'" % (kpartx_args, self.physdev()))
fd.close()
self.mapped += 1

def deactivatepartitions(self):
"""Remove device-mapper mappings and loop mapping.

Will never raise.
"""
if not self.mapped:
return
self.mapped -= 1
if not self.mapped:
if self.pcount:
verbose_print("kpartx %s -d '%s'" % (kpartx_args, self.physdev()))
fd = os.popen("kpartx %s -d '%s'" % (kpartx_args, self.physdev()))
fd.close()
self.loopclean()

def __del__(self):
"d'tor: clean up"
self.deactivatepartitions()
self.loopclean()

def __repr__(self):
"string representation for debugging"
strg = "[" + self.vdev + "," + self.pdev + ","
if self.ldev:
strg += self.ldev
strg += "," + str(self.pcount) + ",mapped %ix]" % self.mapped
return strg

class Partition:
"""Class representing a domU filesystem (partition) that can be
mounted in dom0"""
def __init__(self, whole = None, vdev = None, pdev = None):
"c'tor: setup"
self.wholedisk = whole
self.vdev = vdev
self.pdev = pdev
self.mountpoint = None

def __del__(self):
"d'tor: cleanup"
if self.mountpoint:
self.umount()
# Not needed: Refcounting will take care of it.
#if self.wholedisk:
# self.wholedisk.deactivatepartitions()

def __repr__(self):
"string representation for debugging"
strg = "[" + self.vdev + "," + self.pdev + ","
if self.mountpoint:
strg += "mounted on " + self.mountpoint + ","
else:
strg += "not mounted,"
if self.wholedisk:
return strg + self.wholedisk.__repr__() + "]"
else:
return strg + "]"

def mount(self, fstype = None, options = "ro"):
"mount filesystem, sets self.mountpoint"
if self.mountpoint:
return
if self.wholedisk:
self.wholedisk.activatepartitions()
mtpt = tempfile.mkdtemp(prefix = "%s." % self.vdev, dir = tmpdir)
mopts = ""
if fstype:
mopts += " -t %s" % fstype
if options:
mopts += " -o %s" % options
verbose_print("mount %s '%s' %s" % (mopts, self.pdev, mtpt))
fd = os.popen("mount %s '%s' %s" % (mopts, self.pdev, mtpt))
err = fd.close()
if err:
try:
os.rmdir(mtpt)
except:
pass
raise RuntimeError("Error %i from mount %s '%s' on %s" % \
(err, mopts, self.pdev, mtpt))
self.mountpoint = mtpt

def umount(self):
"""umount filesystem at self.mountpoint"""
if not self.mountpoint:
return
verbose_print("umount %s" % self.mountpoint)
fd = os.popen("umount %s" % self.mountpoint)
err = fd.close()
try:
os.rmdir(self.mountpoint)
except:
pass
if err:
error("Error %i from umount %s" % (err, self.mountpoint))
else:
self.mountpoint = None
if self.wholedisk:
self.wholedisk.deactivatepartitions()

def parseEntry(entry):
"disects bootentry and returns vdev, kernel, ramdisk"
def bad():
raise RuntimeError, "Malformed --entry"
fsspl = entry.split(':')
if len(fsspl) != 2:
bad()
vdev = fsspl[0]
entry = fsspl[1]
enspl = entry.split(',')
if len(enspl) not in (1, 2):
bad()
# Prepend '/' if missing
kernel = enspl[0]
if kernel == '':
bad()
if kernel[0] != '/':
kernel = '/' + kernel
ramdisk = None
if len(enspl) > 1:
ramdisk = enspl[1]
if ramdisk != '' and ramdisk[0] != '/':
ramdisk = '/' + ramdisk
return vdev, kernel, ramdisk

def copyFile(src, dst):
"Wrapper for shutil.filecopy"
import shutil
verbose_print("cp %s %s" % (src, dst))
stat = os.stat(src)
if stat.st_size > 16*1024*1024:
raise RuntimeError("Too large file %s (%s larger than 16MB)" \
% (src, stat.st_size))
try:
shutil.copyfile(src, dst)
except:
os.unlink(dst)
raise()

def copyKernelAndRamdisk(disk, vdev, kernel, ramdisk):
"""Finds vdev in list of partitions, mounts the partition, copies
kernel [and ramdisk] off to dom0 files, umounts the parition again,
and returns sxpr pointing to these copies."""
verbose_print("copyKernelAndRamdisk(%s, %s, %s, %s)" % (disk, vdev, kernel, ramdisk))
if dryrun:
return "linux (kernel kernel.dummy) (ramdisk ramdisk.dummy)"
part = disk.findPart(vdev)
if not part:
raise RuntimeError("Partition '%s' does not exist" % vdev)
part.mount()
try:
(fd, knm) = tempfile.mkstemp(prefix = "kernel.", dir = tmpdir)
os.close(fd)
copyFile(part.mountpoint + kernel, knm)
except:
os.unlink(knm)
part.umount()
raise
if not quiet:
print "Copy kernel %s from %s to %s for booting" % (kernel, vdev, knm)
sxpr = "linux (kernel %s)" % knm
if ramdisk:
try:
(fd, inm) = tempfile.mkstemp(prefix = "ramdisk.", dir = tmpdir)
os.close(fd)
copyFile(part.mountpoint + ramdisk, inm)
except:
os.unlink(knm)
os.unlink(inm)
part.umount()
raise
sxpr += "(ramdisk %s)" % inm
part.umount()
return sxpr

def main(argv):
"Main routine: Parses options etc."
global quiet, dryrun, verbose, tmpdir, in_args
def usage():
"Help output (usage info)"
global verbose, quiet, dryrun
print >> sys.stderr, "domUloader usage: domUloader [--output=fd] [--quiet]

[--dryrun] [--ver
bose]\n" +\
"[--args] [--help] --entry=dev:kernel[,ramdisk] physdisk

[virtdisk]\n"
print >> sys.stderr, __doc__

try:
(optlist, args) = getopt.gnu_getopt(argv, 'qvh', \
('entry=', 'output=', 'tmpdir=', 'args=', 'help', 'quiet', 'dryrun', 'verbose'))
except:
usage()
sys.exit(1)

entry = None
output = None
pdisk = None
vdisk = None

for (opt, oarg) in optlist:
if opt in ('-h', '--help'):
usage()
sys.exit(1)
elif opt in ('-q', '--quiet'):
quiet = True
elif opt in ('-n', '--dryrun'):
dryrun = True
elif opt in ('-v', '--verbose'):
verbose = True
elif opt == '--output':
output = oarg
elif opt == '--entry':
entry = oarg
elif opt == '--tmpdir':
tmpdir = oarg
elif opt == '--args':
in_args = oarg

verbose_print(str(argv))

if args:
if len(args) == 2:
pdisk = args[1]
elif len(args) == 3:
pdisk = args[1]
vdisk = args[2]

if not entry or not pdisk:
usage()
sys.exit(1)

if output is None or output == "-":
fd = sys.stdout.fileno()
else:
fd = os.open(output, os.O_WRONLY)

if not os.access(tmpdir, os.X_OK):
os.mkdir(tmpdir)
os.chmod(tmpdir, 0750)

vdev, kernel, ramdisk = parseEntry(entry)
if not vdisk:
vdisk = getWholedisk(vdev)
verbose_print("vdisk not specified; guessing '%s' based on '%s'" % (vdisk, vdev))
if not vdev.startswith(vdisk):
error("Virtual disk '%s' does not match entry '%s'" % (vdisk, entry))
sys.exit(1)
disk = Wholedisk(vdisk, pdisk)

r = 0
try:
sxpr = copyKernelAndRamdisk(disk, vdev, kernel, ramdisk)
if in_args:
sxpr += "(args '%s')" % in_args
os.write(fd, sxpr)
except Exception, e:
error(str(e))
r = 1


for part in disk.partitions:
part.wholedisk = None
del disk

return r

# Call main if called (and not imported)
if __name__ == "__main__":
r = 1
try:
r = main(sys.argv)
except Exception, e:
error(str(e))
sys.exit(r)

Zu deinen anderen Fragen, soweit es nicht zu weit führt:
Aber da kann ich auch eine leere Platte ohne Kernel booten (freilich ohne tieferen

Sinn).

Das ist nicht nur sinnlos sondern auch unmöglich. Du kannst bestenfalls mit dem vmware

player einen leere PC booten, aber weit kommst Du damit nicht. Das ist halt der Unterschied

zwischen den Konzepten. vmware player virtualisiert einen ganzen PC - xen nicht.

Ok, das gilt aber auch für die anderen VMware-Produkte.

Schon richtig, aber wieso sollte ich keine normale Konsole haben?? Eine

VMware-VM liefert mir ja auch eine wunderbare Konsole, über die ich dann ein OS installieren

und die VM ins Netz bringen kann.

WMware verfolgt ein anders Konzept - siehe oben. Da aber xen keinen ganzen PC, also auch

keine Grafikkarte emuliert ists damit Essig - außer mit xm console bei paravirtualisierten

System. Da ist man dank Einbindung von Teilen von qemu wieder auf dem vmware level.

Ok.

An der Stelle wird es mir endgültig zu obskur....mir ist schleierhaft,

wieso ich ein FS auf einer leeren Platte anlegen muß, und womit ich das VM-FS befüllen

soll.

Jetzt stehst Du ein bisserl auf der Leitung
Du kannst jedem virtualisierten System, ob vmware oder xen entweder eine echte Platte bzw

Partition oder eine virtuelle, also eine Datei als Speicher geben. Aussehen tun sie alle

gleich: sie enthalten ein Filesystem.
Also entweder legst Du eine Partition an und darin ein filesystem oder eine Datei und darin

ein Filesystem - erkennst Du die Parallele?
Das eine bindest Du in die VM mit "disk = ['phy:..." ein, das andere mit "disk =

['file:..."
Leer sind sie alle solange Du sie nicht füllst

Ja, der Unterschied zwischen Platte, Partition und Datei als virtuelle Festplatte war mir

schon klar. Die Diskussion und das erneute Studium des c't-Artikels und des Links
http://en.opensuse.org/Installing_Xen3
bringen ein wenig Licht ins Dunkle. Wenn ich nochmal aufgreifen darf:

Im Prinzip ist der Ablauf wie folgt:
0. Im Host den Xen-kernel und die xen-tools installieren
1. Image dateien für die Partitionen des Hostsystems anlegen
2. Suse in ein directory installieren (in die gemountete Imagedatei)
3. Configdateien erstellen
4. Gast starten
5. Bingo

Wenn ich das jetzt richtig verstanden habe, installiere ich das OS, BEVOR die VM (d.h. das

Konfigfile) überhaupt existiert?? Gebootet wird - bei identischem OS - jeweils mit dem gleichen Kernel und der gleichen RamDisk, mit der auch der Wirt schon gebootet ist?? Und wenn man andere OSe einsetzen will, muß man mehrere Kernel zentral ablegen:

Das muss aber nicht so sein. Allgemein würde man die Kernels für die VMs separat ablegen, z.B. in /boot/vm1, /boot/vm2 ...

??

Hats geklingelt oder liege ich schon wieder daneben?

Casus cnactus war scheinbar, daß ich die VM mit der CD booten wollte.

Die enthält aber wohl keinen paravirtualisierungsfähigen Kernel. Mit der DVD funktioniert es

einwandfrei. Warum die HVM nicht laufen - keine Ahnung!

Ich auch nicht. Habe noch nie gehört, dass man eine Xen VM on CD/DVD booten kann. Würde mich

interessieren.

Tja, was kann ich Dir erzählen? Ich habe einfach den Wizard ausgefüllt - und fertig!
In dem Link wird das Thema aber auch geschildert:

http://en.opensuse.org/How_to_Install_a_VM%27s_OS_from_ISO

Wenn meine obige Annahme richtig ist, sehe ich kein Problem darin, wenn die VM von einem IM Diskfile liegenden Kernel und einer RamDisk bootet, oder? Das war ja das, was ich in Kenntnis der VMware-Konzepte und in Unkenntnis des obigen Konzepts immer versucht habe.

VG

Stephan

 

[pft]

Könnte das "PAE" die Portierbarkeit einschränken?

Yup, meines Wissen schon - aber das heißt in diesem Fall nicht viel.

Gebootet wird - bei identischem OS - jeweils mit dem gleichen Kernel und der gleichen RamDisk, mit der auch der Wirt schon gebootet ist??

Im Prinzip ja. Spricht ja auch nix dagegen eine Datei zweimal zu öffnen - wird ja nur gelesen.

Allerdings habe ich mir mal das Python Skript angesehen. Das löst ein altes Problem - wusste gar nicht dass es das gibt.
Hier wird das Problem der Zugänglichkeit den Guest-kernel vom Host aus gelöst obwohl der im guest filesystem steckt. Das ist deswegen sehr gut, weil man dann den Guest problemlos updaten kann. Liegt der Kernel im host-filesystem geht das in die Hose. Das hat mich mal ein poaar Nächte gekostet.

Tja, was kann ich Dir erzählen? Ich habe einfach den Wizard ausgefüllt - und fertig!
In dem Link wird das Thema aber auch geschildert:

Muss ich mir mal reinziehen. klingt interessant.

Wenn meine obige Annahme richtig ist, sehe ich kein Problem darin, wenn die VM von einem IM Diskfile liegenden Kernel und einer RamDisk bootet, oder? Das war ja das, was ich in Kenntnis der VMware-Konzepte und in Unkenntnis des obigen Konzepts immer versucht habe.

Nein, ist sogar besser. Siehe oben.

 

[pft]

Kurzer Blick in die von Dir genannte Seite lässt mich vermuten, dass da mehr oder weniger eine normale "Installation in ein Verzeichnis" ist.
Den Punkt findest Du auch in yast, nur dass hier nicht das installierte Hostsystem installiert wird sondern ein anderes von CD.
Definitiv wird aber nicht eine VM von der CD gebootet. Das geht m.M. nach wirklich nicht bei Xen.