Hi Maurice. Danke für deine ausführliche Antwort. Einige Dinge sind geklärt ... ich antworte dennoch ebenfalls nochmal ausführlich:
Vorab noch ein Hinweis für alle Mitleser: Die Einbindung der vorgefertigten VMs unter Xen klappt wirklich gut und ist einfach. Es sind wie gesagt ein paar "Folgeprobleme", die man vermutlich vor allem dann hat, wenn man von einem anderen System kommt und Xen (bisher) nicht kennt. Es sollte also durch diesen Thread niemand abgeschreckt werden, sich selbst von Xen zu überzeugen....! > Dies ist ein Typ-1 Hypervisor, da hat ein Midnight Commander ebenso wenig was > zu suchen wie andere Pakete aus irgendwelchen Repos. > Dies hat einen guten Grund und mir würde nicht ein Grund einfallen warum dieser benötigt wird. Alles nötige bringt XenServer mit. Na ja -- ich sehe das so: Ich kann mich per ssh am XenServer anmelden und dort also auch Daten hin- und herschieben oder editieren. Dazu benutze ich häufig den mc -- daher verstehe ich das Argument nicht ganz, warum der da nix zu suchen hat. Genauso verhält es sich mit "ncdu" -- das ist einfach super praktisch und wesentlich schneller als per GUI. Ist Geschackssache und natürlich spielen bei Servern auch immer Sicherheitsüberlegungen mit hinein .... doch dieses "Risiko" halte ich für vertretbar. > Warum nicht einfach über XenCenter > New SR > ISO Libary? Auf der Konsole ist > natürlich auch alles möglich. (xe) Hat mittlerweile geklappt. >> (vor allem die Sache mit der 4 GB Grenze kommt mir seltsam vor -- warum >> nicht gleich beliebig groß anlegen?) > Diese gibt es nicht. Wo hast du das gesehen? Doch -- wenn man nach der zuletzt genannten Anleitung vorgeht, landet das Storage offenbar auf root / und dort ist der Platz begrenzt. Man sollte es also tatsächlich lieber via XenCenter -> Wizard einbinden. > Doch, wenn die XenTools installiert sind oder unsere Vorgefertigten VMs > verwendet werden. Ist bei VirtualBox/VMware etc. ja auch nicht anders. > Generell würde ich aber diese Konsole nur als fall back sehen und immer via > SSH usw. arbeiten. Ja -- ssh ist auch mein Favorit. Damit komme ich aber wieder nur ins grüne Netz. Der Zugriff auf rot erledigt sich aber mit dem u.g. wahrscheinlich! Letztlich wird es vermutlich so sein, dass man sich per ssh (fast) nie auf dem XenServer selbst "aufhält" sondern alles, was es zu regeln gibt, via XenCenter/XOA macht und ansonsten die VMs selbst anspricht. Dagegen spricht ja auch nichts, doch bis es soweit ist, musste (zumindest ich) bisher häufiger mal auf den XenServer selbst -- auch, um mich zurecht zu finden. >> * Zur Performance bzw einem Leistungsvergleich mit Proxmox > Da kann man wirklich Proxmox (Typ-2 Hypervisor) nicht mit Xen (Typ-1 > Hypervisor) oder ESXi (Typ-1 Hypervisor) vergleichen. >Ein Ubuntu mit VirtualBox drauf bootet bestimmt noch schneller ;) Am Ende zählt ja die Performance der VMs. Dazu habe ich etwas nachgelesen und das hier gefunden: http://www.datacenter-insider.de/typ-1-versus-typ-2-kvms-und-andere-hypervisoren-a-318394/ (vor allem auf der 2. Seite) >htop noch mit iftop, ncdu ... >> und allen weiteren Tools, die ich "must-have" nennen würde. Hat jemand eine >> Lösung parat? > Die Anforderungen hatte ich bislang nicht gesehen, wo genau benötigst du > diese Tools? Detailliert Berichte der Performance bietet das XenCenter. > Welche Infos sucht du hier? Ja. Das habe ich mittlerweile eingesehen: Man macht offenbar einfach ALLES via XenCenter. Ich war es von Proxmox bisher gewohnt, dass ich vieles _auch_ per Konsole mache(n kann). Daher waren die Tools htop,ncdu,iftop usw wichtige/notwendige Helfer, um beispielsweise RIESEN-Dateien bei Plattenplatzproblemen schnell finden zu können ... (mit xe muss ich mich ohne Zweifel noch auseinandersetzen!) > Der Xenserver wird über ein Interface administriert. Das ist natürlich > beliebig umstellbar. Es ist auch möglich dem Server auf mehreren > Schnittstellen IPs zu geben (für Storage Dienste). > Natürlich sollte hier eher der Testaufbau überdacht werden. Ich würde nicht > über ROT den Hypervisor erreichen wollen... Kann man ja auch nur temporär so einstellen und später wieder zurück auf GRÜN ändern ... wie gesagt habe ich im Moment keine Chance, von zu Hause auf Xen zu gelangen, was aber notwendig wäre, um auch von hier aus weiterarbeiten zu können. Ich habe schon überlegt, ob mir mir eine TeamViewer-Verbindung zu dem Laptop einrichte, auf dem XenCenter läuft. Dann ginge es immerhin weiter... >> Und siehe da: Das Passwort vom IPFire wird wieder abgefragt -- ich komme >> NICHT mehr passwortlos auf die FW! Bug?? > Das ist ein bekannter Bug und hat nichts mit Xen oder den VMs zu tuen. War auch nicht so gemeint. Ich werde den "linuxmuster-ipfire"-Befehl morgen ausprobieren -- damit dürfte das Problem behoben sein. >> Fehlermeldungen hoch -- so z.B. bei dropbear/ssh (kann's im Moment nicht >> genauer wiedergeben) > Kann ich nicht nachvollziehen. Kannst du das nochmal genauer Protokollieren? > Ggf. kann ich das nachstellen. Ja, wenn ich wieder Zugriff habe, kann ich das nochmal genauer protokollieren. Es gab hier jedenfalls einige Meldungen beim Start. SSH auf 10.16.1.1 funktionierte jedoch anschließend -- vielleicht war es also auch nur ein Warnung. >> * Ich habe eine Migration auf dem Produktivsystem angeworfen und wollte es >> unter Xen zurückholen. Aus Geschwindigkeitsgründen habe ich dazu eine virt. >> HDD reingehängt, die ich anschließend nach XEN kopiert habe. > Ein mögliches vorgehen wurde in dem Thread "Re: [lmn] XEN Start" behandelt. Wenn ich das richtig sehe, wird dort aber "nur" der Fall behandelt, dass die Daten der Migration bereits zugänglich sind. Das ist ja bei mir (noch) nicht der Fall. Ich wollte dem lml-Server eine zusätzliche HDD spendieren, auf dem die Migrationsdaten bereits enthalten sind. Das geht offenbar nicht sooo einfach? Es scheint so zu sein, dass man dem Server nicht einfach eine selbst benannte .vhd "unterjubeln" kann, richtig? >Bitte vergesst nicht wie das Ganze für "Externe" aussieht.. die denken bei linuxmuster geht Garnichts - so viel Probleme wie da behandelt werden. Das kann ich gerne nochmal entkräften: Es läuft alles gut zusammen. Die vorgefertigten VMs unter XenServer sind wirklich SEHR flott aufgesetzt und man kann sich auf die Anleitung verlassen! Zudem greift hier wieder der oft zitierte Vergleich mit dem Wartezimmer eines Arztes: Dort sieht man nur die Kranken und weiß nichts über die Gesunden... > Es sollte hier klarer erkennbar sein ob es Probleme mit dem "vorgesehenen > Weg" gibt oder ob es um erweiterte Anpassungen und Sonderfälle geht. > Aber das ist ein anderes Thema und sicher kein Vorwurf an dich :-) Ja, auch hier nochmal zur Klärung: Wer umsteigt, muss sich daruf einstellen, dass unter Xen einiges anders läuft als z.B. unter Proxmox. Von "schlechter/besser" als vorher reden wir jetzt mal nicht -- aber "anders" kann man definitiv sagen. > Dafür liefern wir eben die XOA aus und werden auch mal noch das XenCenter für > Linux nachziehen. Wie wollt ihr das realiseren? Als wine-Application oder wirklich nativ unter Linux? Ist der Code für XenCenter etwa OSS? >> Ich teste XEN aber gerne noch ein paar weitere Tage. Die Migration sollte >> dazu allerdings einwandfrei funktionieren, denn sonst macht es wenig Sinn. > Dazu kann ich dir nochmals den Beitrag "Re: [lmn] XEN Start" empfehlen. Oder > du holst dir professionelle Hilfe dazu, dies ist sicher keine typische > Aufgabe für ein Netzwerkbetreuer. Eine Migration habe ich schon öfter angeworfen (auch von bare metal --> VM) ... ein "Problem" dabei ist, dass die Daten komplett rüberkopiert werden, wenn man als Quelle ein NFS-Share angibt (Schalter -t). Ich fürchte, dass es dann "etwas" eng auf dem Server wird ... kann es aber auch auf diesem Weg nochmal versuchen. >> Übrigens: Eine Win10-Installation in einer VM unter XEN mit LINBO lief heute >> sauber durch. Es gibt also auch positives zu berichten. > Das ist schön, warum verwendest du Linbo in einer VM? Reines Interesse. Ich wollte zunächst Linbo + Win10 testen (vor allem, ob das Klonen funktioniert). Danach soll ein Win10-Client als Vorlage dienen (als VM!), um dort benötigte Software nachinstallern zu können und es anschließend z.B. auf Notebookwagen auszurollen. Das ist also das gleiche Vorgehen wie wir es seit Jahren mit den Ubuntu-Clients praktizieren. Eine VM ist die Vorlage, über die alle anderen dann versorgt werden. Also dann -- die restlichen Dinge klären sich sicher. Bis später, Michael _______________________________________________ linuxmuster-user mailing list [email protected] https://mail.lehrerpost.de/mailman/listinfo/linuxmuster-user
