ich würd mal den rat von euch experten benötigen:
folgende situation:
server (mail, dns, web, ...) auf debian testing mit softraid, lvm, ...
vdr (www.vdr-wiki.de) auf debian unstable mit einer DVB-C karte
vdr ist ein alter P3 (zum videos transcodieren etwas lahm) und der server
eher stromfressend, mehr als 100 W idle, eine alte AMD kiste.
nun würde ich für beide rechner gerne _einen_ neuen ordern, hauptsächlich
aufgrund des hohen stromverbrauches (in summe irgendwo über 200 W). den vdr
will ich aber nicht auf testing laufen lassen und den server nicht auf
unstable.
ich dachte zuerst an eine vm realisiert mit KVM oder VirtualBox (eher was
für den desktop?!). sprich, der vdr soll in der vm laufen. aber da kann ich
ja keine PCI devices durchreichen. oder gäbs da doch eine möglichkeit? und
den server will ich nicht in der vm laufen haben, weil dann müßte das
gastgeber-system ja unstable sein.
andererseits würde sich eine chroot-umgebung mit hilfe von debootstrap wie
es zb in http://capricorn.woot.net/~jdrew/debian-chroot.html erklärt ist
anbieten.
die chroot-umgebung hätte auch noch den vorteil, daß ich keine CPU mit
vanderpool oder ähnlichem benötigen würde.
was halten die experten von meinen lösungsvorschlägen? any other hints?
gre3tings, Klaus
> ich dachte zuerst an eine vm realisiert mit KVM oder VirtualBox (eher was
> für den desktop?!). sprich, der vdr soll in der vm laufen. aber da kann ich
> ja keine PCI devices durchreichen. oder gäbs da doch eine möglichkeit? und
> den server will ich nicht in der vm laufen haben, weil dann müßte das
> gastgeber-system ja unstable sein.
www.openvz.org, www.linux-vserver.org, läuft stabil und ist sehr flexibel
> andererseits würde sich eine chroot-umgebung mit hilfe von debootstrap wie
> es zb in http://capricorn.woot.net/~jdrew/debian-chroot.html erklärt ist
> anbieten.
geht auch
> die chroot-umgebung hätte auch noch den vorteil, daß ich keine CPU mit
> vanderpool oder ähnlichem benötigen würde.
brauchst Du auch so nicht unbedingt.
cheers
>> ich dachte zuerst an eine vm realisiert mit KVM oder VirtualBox (eher was
> www.openvz.org, www.linux-vserver.org, läuft stabil und ist sehr flexibel
zumindest auf den ersten blick wird das nicht von debian "supported".
ich stehs mir leider auf in-the-box dingen. :-)
>> die chroot-umgebung hätte auch noch den vorteil, daß ich keine CPU mit
>> vanderpool oder ähnlichem benötigen würde.
> brauchst Du auch so nicht unbedingt.
stimmt. wobei mir mittlerweile xen gefallen würde, vor allem haben sich
da schon ein paar leute in zusammenhang mit vdr gedanken gemacht:
http://www.vdr-wiki.de/wiki/index.php/LinVDR_-_Xen ich hab das leider
mit google nicht gleich auf anhieb gefunden ...
gre3tings, Klaus
>> was halten die experten von meinen lösungsvorschlägen? any other hints?
> Was spricht aus deiner Sicht gegen Xen?
ein 2.6.18er.
der ist relativ alt und deshalb bin ich von xen mittlerweile auch nicht mehr
so begeistert.
> IIRC kann man da PCI-Devices in
> die Gast-Domain durchreichen.
ja, kann man. Dom0 und DomU müssen aber den selben kernel haben, den
2.6.18er.
kvm soll angeblich auch pci devices durchreichen könne, ich hab nur leider
noch keine anleitung gefunden.
gre3tings, Klaus
> Burkhard Ott wrote:
>
>>> ich dachte zuerst an eine vm realisiert mit KVM oder VirtualBox (eher was
>> www.openvz.org, www.linux-vserver.org, läuft stabil und ist sehr flexibel
> zumindest auf den ersten blick wird das nicht von debian "supported".
> ich stehs mir leider auf in-the-box dingen. :-)
OpenVZ :
kernel-patch-openvz - server virtualization solution - kernel patch
vzctl - server virtualization solution - control tools
vzquota - server virtualization solution - quota tools
Da Du den Kernel ohnehin patchen musst kannst Du auch den Sourcepatch von
deren Seite nehmen. Ich habe das in Produktivumgebungen laufen und noch
nie negative Erfahrungen gemacht. In der chroot hast Du den Nachteil das
Du sobald Du ein Update im System hast diese auch in die chroot bringen
musst.
Chroot setze ich nur bei Apache etc. ein und habe mir dafür Packete gebaut
die ich dann innerhalb von 1 Minute neu generieren kann und die chroot
damit updaten kann.
Ich sehe gerade vserver ist auch im Debian Repo drinn:
linux-image-2.6.18-4-vserver-*
Xen ist auch eine gute Alternative allerdings sehe ich das dann doch eher
auf Systemen etwas größerer Bauart die einfach mehr Gäste haben sollen.
Ausserdem musst Du da ein Device anlegen, was mit dd nun auch nicht
wirklich hinderlich ist, bei OpenVZ kannst Du z.Bsp. die zu benutzende HD
Größe während der Laufzeit anpassen.
> stimmt. wobei mir mittlerweile xen gefallen würde, vor allem haben sich
> da schon ein paar leute in zusammenhang mit vdr gedanken gemacht:
> http://www.vdr-wiki.de/wiki/index.php/LinVDR_-_Xen ich hab das leider
> mit google nicht gleich auf anhieb gefunden ...
cheers
> was halten die experten von meinen lösungsvorschlägen? any other hints?
Ich weiss nicht, ob ich ein Experte bin, hier nur meine Gedanken
dazu:
Eine VM wie xen/kvm/vmware bietet einen sehr hohen Trennungsgrad
zwischen beiden System, fuehrt aber eine recht heftige Schicht
dazwischen ein. Die Performance ist mit heutigen CPUs fuers erste
meist kein Thema mehr, wenns aber so Sachen kommen wie Energie
sparen, macht das meistens noch 1-2 Probleme (die Belastung des
Systems messen und ggf. die CPU runtertakten muesste der Hypervisor
machen, xen kann das AFAIK z.B. nicht).
Ausserdem ist xen ein bisschen ekelhaft, wenn 2 Gaeste auf der
gleichen Maschine miteinander kommunizieren wollen/muessen,
zumindest auf Maschinen mit nur 1 CPU - das erfordert viele
Kontextwechsel, bei manchen Protokollen drueckt das _sehr_ auf die
Performance.
linux-vserver und openvz sind im wesentlichen aufgebohrte chroots,
und als solche zur Laufzeit um einiges schlanker, weil nur mehr 1
Kernel beteiligt ist (gegenüber 1 Hypervisor + n Kernel). chroot
virtualisiert nur das Fiesystem, linux-vserver/etc. gehen halt noch
weiter, und virtualisieren die Netzwerkschnitten, Prozess-
Namensraeume usw.
Meine Meinung: xen wuerde ich nur nehmen, wenn ich fuer die Gaeste
einen anderen Kernel brauche, linux-vserver/openvz nur, wenn die
Gaeste abgetrennte Bereiche brauchen (d.h. es soll im Gast einen
root geben, der z.B. keine Prozesse aus dem Host-System beeinflussen
koennen soll). Sonst - chroot, macht am wenigsten Aerger.
Fuer die Aufgabenstellung mit vdr wuerd ich das eug einfach in ein
chroot stecken, soweit ich Dich verstanden habe, gehts nur darum,
dem vdr ein wenig aktuellere Software zuzuschieben.
Adalbert
> Meine Meinung: xen wuerde ich nur nehmen, wenn ich fuer die Gaeste
> einen anderen Kernel brauche, linux-vserver/openvz nur, wenn die
> Gaeste abgetrennte Bereiche brauchen (d.h. es soll im Gast einen
> root geben, der z.B. keine Prozesse aus dem Host-System beeinflussen
> koennen soll). Sonst - chroot, macht am wenigsten Aerger.
In der chroot kannst Du aber keine Speicherbereiche trennen, bzw. cpu
verteilen, das macht sich besonders beim testen neuerer Software ziehmlich
gut.
cheers
Die Speicherbereiche zu trennen ueberlasse ich ganz gern meinem
Kernel, der macht das ganz automatisch; abgesehen davon schrub ich
in dem von Dir zitierten, dass ich linux-vserver nehme, wenn ich
abgetrennte Bereiche fuer die Gaeste brauche.
Das Zeug (xen, vserver - egal) nervt aber zeitweise hinreichend, um
es nicht als Allheilmittel fuer alles empfehlen zu koennen. Ein
chroot ist zwar altmodisch, aber genuegt oft voellig. Und dann gibts
auch noch ulimit.
Adalbert
> Das Zeug (xen, vserver - egal) nervt aber zeitweise hinreichend, um
> es nicht als Allheilmittel fuer alles empfehlen zu koennen. Ein
> chroot ist zwar altmodisch, aber genuegt oft voellig. Und dann gibts
> auch noch ulimit.
Ja stimmt auch wieder, Allheilmittel dürfte es ohnehin nicht geben.
cheers
Außerdem braucht sie keine neue "Technologie", Tools, Patches u.ä. Probleme.
> was halten die experten von meinen lösungsvorschlägen? any other hints?
Wenn Security (zwischen den beiden virtuellen Rechnern) kein wirkliches
Thema ist, nimmm "chroot".
Bernd
--
Bernd Petrovitsch Email : be...@bofh.at
"For I was talking aloud to myself. A habit of the old: they choose
the wisest person present to speak to; the long explanations needed
by the young are wearying." --- Gandalf, the White
> ich dachte zuerst an eine vm realisiert mit KVM oder VirtualBox (eher was
der tipp mit OpenVZ war goldes wert. vielen dank!
mein VDR läuft schon problemlos darin, mußte nur die entsprechenden devices
durchreichen und im mount script die permissions anpassen.
das ganze auf debian testing/lenny mit 2.6.26er kernel (mit OpenVZ
standardmäßig aus testing).
lediglich beim bridging mit dem veth device (will einen DHCPd laufen haben)
schmiert mir die ganze kiste ab. aber da soll es angeblich besserung mit
2.6.27 geben.
wenn das dann alles läuft darf ich noch im detail erzählen, wie ich das mit
dem VDR erledigt habe.
gre3tings, Klaus