Re: Xen aus Quellen - Update
Hi Dominique,
sorry für das Delay, aber ich musste noch n paar Brötchen verdienen
gehen ;)
Am Montag, den 17.03.2008, 09:43 +0100 schrieb Dominique H. Schramm:
> >>> Die Frage ist eher, warum du die Quellen bemühen magst?
> >> Um mir solche Fehler zu ersparen:
> >> .......
> >> BTW: es ist nur 1 einziger VM vorhanden ;) Dieser läuft nicht und es
> >> sind auch keine Dubletten vorhanden, ich habe das komplette System mit
> >> grep ^name umgewuselt um Dubletten zu finden. Da kompilier ich lieber
> >> selbst, denn so einen Fehler hatte ich bisher noch nicht :) und das
> >> ist nun meine 6te oder 7te Install bereits.
> >
> > Hehe - einer der tollen neuen Changes ist die xen-interne Datenbank :)
>
> Xen interne DB ? Ich war gerade auf der XEN Seite leider sind die Docs
> noch nicht oben :( Gib mir bitte nen kurzen Abriss zu dieser DB. Danke
Das läuft unter dem Begriff der "Managed Domains".
Diese XEN-interne DB ist der xenstore. Neu seit Xen Version 3.04 -
Das Kommando xm create wird durch ein neues Verfahren abgelöst, bei dem
die Konfigurationsdaten jedes Gastes in der Xen-Datenbank xenstore
gespeichert werden.
Um einen neuen Gast zu generieren und zu starten, geht man dann so vor:
xm new -f KONFIGURATIONSDATEI
Einen bereits in dieser Form konfigurierten Gast starten Sie dagegen mit
xm start GASTNAME
wobei GASTNAME dem in KONFIGURATIONSDATEI hinterlegten Namen für den
Gast entspricht.
Die neuen und „alten“ Kommandos werden ausführlich in Kapitel 7
behandelt.
ii xenstore-utils 3.2.0-3~bpo4+1
Xenstore utilities for Xen
ii libxenstore3.0 3.2.0-3~bpo4+1
Xenstore communications library for Xen
der in 3.2 nochmals weiter "aufgebohrt" wurde.
Schau mal, was du nun zB machen kannst:
xm create -f domu.cfg fügt dir ne cfg zur db hinzu
mit xm start domu kannst diese nun starten
wenn du diese mit xm shutdown domu stopst steht sie immer noch in xm
list
Vergleich)
1) xm list
Name ID Mem VCPUs State
Time(s)
Domain-0 0 735 1 r-----
2397.2
2) xm new -f pvm32.cfg
Using config file "/etc/xen/pvm32.cfg".
Debian-40-etch-64-minimal:~# xm list
Name ID Mem VCPUs State
Time(s)
Domain-0 0 735 1 r-----
2402.0
pvm32 128 1
0.0
3) xm shutdown pvm32
Debian-40-etch-64-minimal:~# xm list
Name ID Mem VCPUs State
Time(s)
Domain-0 0 735 1 r-----
2404.9
pvm32 128 1
5.6
Wie du siehst steht der gast nun immer in xm list. und in meinem falle
pvm32 kann ich lustig als template verwenden, dutzende mal starten
etc...
Praktisch bedeutet das für Sie, dass Sie – zumindest unter Xen 3.2 –
weiterhin mit den separaten Konfigurationsdateien arbeiten können. Die
darin enthaltenen Parameter und
Einstellungen werden beim Starten des Gastes automatisch in xenstore
übertragen, so dass eine Abwärtskompatibilität hergestellt ist.
>
> > Normalerweise hast ja deine domains mittels
> > xm create domU.cfg gestartet.
>
> richtig
>
> > Es geht mittlerweile aber auch mittels
> >
> > xm new -f domU.cfg und das hat dann reingarnichts mehr mit deinen cfg's
> > zu tun - die kannst auch ändern wie du magst - das ändert für xen rein
> > gar nicht ;)
>
> Den Satz verstehe ich nun wirklich nicht :(
Im Gegensatz zu früheren Versionen listet Xen aufgrund des „managed
domain“-Modells nicht nur die aktiv laufenden Domains auf, sondern alle,
welche in der internen Konfigurationsdatenbank
aufgelistet sind....
Ab Version 3.04 wurde ein neues Verfahren für die Verwaltung und
Generierung von Gästen
eingeführt: „managed domains“.Während das oben beschriebene xm create
aus Gründen der Abwärtskompatiblität bislang uneingeschränkt
funktioniert, gibt es parallel dazu neue
Kommandos, die eine etwas andere Vorgehensweise bedingen.
Mit
xm new -f /etc/xen/domu1
erzeugen Sie eine managed domain, welche nun von Xen verwaltet werden
kann.
Danach können Sie diesen Gast starten mit
xm start persistentGuest
wobei persistentGuest dem in /etc/xen/domu1 konfigurierten Namen
entsprechen muss.
Ein solchermaßen erzeugter Gast ist „persistent“, d.h. er ist bis auf
weiteres in der internen
Konfigurationsdatenbank gespeichert. Um ihn dort zu entfernen, müssen
Sie ihn explizit
löschen. Das Kommando
xm delete persistentGuest
entfernt Gast persistentGuest dauerhaft.
Ein recht einfacherWeg, einen vorhandenen „persistenten“ Gast
umzukonfigurieren, kann
wie folgt aussehen:
1. Konfigurationsdaten auslesen:
xm list -l persistentGuest > persistentGuest.sxp
2. Konfigurationsdaten in persistentGuest.sxp mit einem Editor
bearbeiten. Dabei den
Wert vonUUIDnicht ändern, damit die Konfigurationsdaten in xenstore
überschrieben
werden – sonst wird bei späteren Neueinlesen ein zusätzlicher Gast
angelegt.
3. Gast neu anlegen (bzw. überschreiben) mit
xm new -F persistentGuest.sxp
Beachten Sie den Schalter -F, der an dieser Stelle verwendet werden
muss, da die
Konfigurationsdatei im SXP-Format vorliegt. Bei Standard-Python-Format
lautet
der Schalter -f. Wenn Sie diesen Schalter weglassen, erwartet das
Kommando eine
XML-Datei als Eingabe.
> Nun backports bringt sicherlich einige vorteile allerdings als ich
> nicht einmal einen domU erzeugen konnte und gleich der Fehler kam
> stand ich doch etwas verlassen da...
jo - dir fehlte vermutlich der xen-store ;) der ist seit debian xen 3.1
aus backports unerlässlich und in keinerleit depends aufgeführt, wie
Paul Muster schon anmerkte. Die Backports laufen sonst echt rund - nutze
diese selber produktiv und da gibts rein gar nichts zu meckern.
> Grüße Dominique
Grüßle
Thomas,
der etwas faul war und ein paar Sätze aus dem Manuskript zitierte :)
Reply to: