Kategorie: Virtualisierung

Arbeiten mit physischen Festplatten

diabolusUmarov

Ich habe es schon unter VirtualBox am laufen und im Artikel “Ein echtes OS unter VirtualBox?” beschrieben. Mich hat es aber genervt, dass es unter qemu nicht funktionieren wollte. Also habe ich angefangen zu lesen und zu testen und siehe da, es bewegt sich doch! Tja, sogar teilweise viel einfacher, als unter VirtualBox, aber drauf kommen muss man da erst einmal!

Inhalt:

Ich habe mit Absicht einen anderen Titel als in dem VirtualBox Artikel gewählt, da ich hier einfach noch ganz anderes Potential sehe! Aber dazu gleich mehr.

Nutzen

Ja, die Frage hinter so ziemlich allem. Warum soll man das eigentlich machen?

Ganz einfach. Wie schon in dem verlinkten Artikel geschrieben, ging es mir in erster Linie um das auf einer extern installierten Festplatte Windows 10. Ich benutze es ausschliesslich zum spielen und von daher, wenn ich da ein Spiel installiere, oder alleine Windows mal wieder ein Update machen will, musste ich erst Windows booten und dann war mein Rechner für das, was ich normalerweise so mache, blockiert. Das gefiel mit nicht!

Deshalb der Gedanke, warum denn nicht ein nativ installiertes OS in einer virtuellen Umgebung booten? Spielen funktioniert da zwar nicht so toll, aber die Updates und Installationen kann man doch machen, ohne den ganzen Rechner durch ein ansonsten für mich nutzloses OS zu blockieren!

Leider fand ich ja zuerst nur Informationen, wie man eine physische Festplatte unter VirtualBox betriebsbereit machen kann. Ich benutze aber in der Regel qemu, um etwas zu virtualisieren. Von daher wollte ich natürlich auch eine Lösung für qemu.

Gut, die habe ich ja nun gefunden und ich muss sagen, ich sehe da recht grosses Potential drin! Zum Beispiel kann man theoretisch (ich habe es noch nicht versucht!) eine leere Festplatte einbinden, ein OS drauf installieren und die Platte dann in einen anderen Rechner bauen. Das hätte den Vorteil, man könnte beispielsweise ein Gentoo, was ja ewig zum installieren braucht, da alles compiliert wird, auf einem schnellen Rechner installieren und dann in einen anderen Rechner einbauen. Klar, da müssten dann noch ein paar Anpassungen vorgenommen werden, aber wahrscheinlich geht es dennoch schneller.

Man kann es aber auch benutzen, um ein OS zu prüfen, würde ich mal sagen. Obwohl da die Frage ist, ob der Einsatz eines Live-OS nicht effizienter wäre. Eine Möglichkeit wäre es dennoch.

Aber alleine schon, dass man beide OS gleichzeitig benutzen kann, halte ich persönlich für einen grossen Vorteil!

Die richtigen Parameter

Wie immer bei qemu, kommt es schlussendlich nur auf die Wahl der richtigen Startparameter an. Ich nehme einfach meine Konfiguration als Beispiel. Da ist Windows auf einer externen Festplatte, welche bei mir unter

/dev/sdf

zu finden ist.

Nach einigen Experimenten habe ich die Lösung, wie man ein solches Laufwerk einbindet, quasi durch Zufall gefunden. Denn, unter Linux ist ja alles eine Datei, inklusive einer physischen Festplatte! Also, warum denn für -hda nicht /dev/sdf4 angeben?

Na, weil es nicht funktioniert! Ich dachte, als -hda gebe ich einfach sdf4 an, weil dort alles notwendige zum booten drauf ist und als -hdb dann sdf2, da dort Windows installiert ist und alles ist toll. Na, falsch gedacht! Korrekt ist tatsächlich so:

-hda /dev/sdf

Der Rest kriegt dann qemu geregelt.

Hier jetzt meine Konfiguration! Virtualisiert wird ein 64-Bit Rechner mit 4 Prozessoren, 4 GB Arbeitsspeicher und einer hda Soundkarte. Ich benutze immer VNC zum anzeigen, da ich dann auch von anderen Rechnern aus darauf zugreifen kann! 

qemu-system-x86_64 -m 4096 -enable-kvm -smp 4 -net nic -net user,hostname=realwin10 -vga std -hda /dev/sdf -device virtio-serial -display vnc=:10 -usb -device usb-tablet -soundhw hda

So. Was passiert denn nun, wenn ich es starte? Da ich ein Skript dafür verwende, starte ich es so:

./startwin10.sh

Es passiert folgendes:

Ja, was ist denn da passiert? Ganz einfach! Der normale Benutzer des Systems darf nicht mal eben auf die Laufwerke zugreifen! Wäre ja noch schöner. Ergo:

sudo ./startwin10.sh

Dann sieht das so aus:

Ach ja, UEFI. Ich habe es nie gebraucht, aber jetzt ist es da und irgendwie will Windows nichts mehr anderes! Unter VirtualBox war das ja noch leicht zu regeln, da muss man einfach nur ein Hacken setzen. Bei qemu ist es ein wenig komplizierter!

OVMF

Man muss, wenn man es nicht schon getan hat, OVMF installieren. Wie das für die jeweilige Distribution geht weiss ich nicht, da müsst ihr euch belesen. Sollte ja aber nicht zu schwierig sein.

Nach der Installation besitzt man folgende Datei:

/usr/share/ovmf/x64/OVMF.fd

oder auch

/usr/share/ovmf/OVMF.fd

Das ist ein BIOS, mit der qemu auch UEFI laden kann. In einigen Foren habe ich zwar gelesen, man müsse nur 

-boot uefi

beim starten mit angeben, funktioniert hat es bei mir aber nicht. Nur mit OVMF!

Der richtige Parameter für qemu lautet:

-bios /usr/share/ovmf/x64/OVMF.fd

qemu mit UEFI

So. Nachdem das soweit geklärt ist, kann man ja mal alles zusammenbauen und dann erneut testen!

qemu-system-x86_64 -m 4096 -enable-kvm -smp 4 -net nic -net user,hostname=realwin10 -vga std -bios /usr/share/ovmf/x64/OVMF.fd -hda /dev/sdf -device virtio-serial -display vnc=:10 -usb -device usb-tablet -soundhw hda

Ja! Von der Theorie her könnt ihr das so kopieren, in einem Terminal einfügen, sudo davor schreiben und das Laufwerk anpassen und schon läuft die Kiste. Wenn denn der Pfad zu OVMF passt!


Tada! Läuft!

Es fällt aber direkt etwas auf, besonders wenn man es vergleicht!

Links Windows unter qemu, Rechts unter VirtualBox. Die Auflösung ist unter qemu niedriger! Gerade einmal 800×600!

Es lässt sich aber auch nicht ändern! Unter VirtualBox übrigens auch nicht!

Gut, die Auflösung reicht, um Updates zu machen, oder ein Spiel zu installieren. Trotzdem wäre es doch schön, wenn man es grösser machen könnte, oder?

Grund dafür dürfte wohl dieser Treiber sein, den Windows in qemu automatisch lädt. Nebenbei, boote ich Windows, wird automatisch der Nvidia-Treiber geladen. Also der von Nvidia, nicht der den Windows mitbringt!

So. Warum akzeptiert Windows 10, wenn man es direkt unter qemu installiert, eine höhere Auflösung? Das werde ich mir mal anschauen und testen. Wenn ich mehr weiss, dann gibt es einen neuen Artikel!

Fazit

Ich meine, Windows läuft unter qemu etwas weicher, als unter VirtualBox. Das mag an den Einstellungen liegen, oder weil Windows unter qemu nur eine Auflösung von 800×600 hat, oder vielleicht ist es rein subjektiv.

Für mich ist es auf jeden Fall ein Erfolg, da ich nach wie vor qemu bevorzuge! Davon aber abgesehen ist es wohl ziemlich egal, welches Tool man benutzt. Sie funktionieren beide!

Ein echtes OS unter VirtualBox?

diabolusUmarov

Um das direkt zu klären, natürlich ist ein OS, welches man in einer virtuellen Umgebung installiert, ebenfalls ein echtes OS. Hier soll es aber darum gehen, ein OS, welches nativ auf einem Computer installiert wurde, in einer virtuellen Umgebung auszuführen. Deshalb sage ich “echtes OS”.

Inhalt:

Warum sollte man?

Warum sollte man ein “echtes OS” in einer virtuellen Umgebung starten wollen? Eine gute Frage, denn wenn es ja auf einem richtigen Computer installiert wurde, kann man es doch auch dort benutzen, oder?

Ja, im Prinzip ist das richtig. Dennoch gibt es da Gründe, warum man gerne ein echtes OS in eine virtuelle Umgebung zwingen möchte. Ich habe zumindest für mich einen solchen Grund gefunden.

Auslöser daran ist Epic mit ihren gratis Spielen jede Woche. Zum Beispiel ARK, oder Civilisation VI. Da konnte ich einfach nicht widerstehen. Gut, ARK spiele ich eigentlich mit Steam unter Linux, doch Civilisation wollte einfach nicht unter Linux laufen. Keine Chance, egal was ich versucht habe. Was also tun?

Nun, ich habe aus meinem NetBook einst die Festplatte gegen eine SSD getauscht. Die alte Platte lag von da an auf dem Regal. Die habe ich jetzt einfach in ein externes Gehäuse gesteckt und unter Windows 10 (zweites OS auf meinem Laptop) Windows 10 Pro als “Windows to go” installiert. Ergo, ich habe jetzt auch ein natives Windows, mit dem ich zum Beispiel Civilisation spielen kann.

Problem an der Sache, natürlich wollte Windows Updates und was weiss ich. Ergo, in der Zeit war ich nicht in der Lage, mit meinem Linux etwas zu arbeiten. Eine echt bescheidene Situation, wie ich finde. Da kam für mich die Frage auf, kann ich denn nicht das installierte Windows virtualisieren?

Und es startet doch!

Ich bin ja bekannt dafür ein Noob zu sein, was Suchmaschinen angeht. Von daher ist es vielleicht für einige unverständlich, warum ich mich bei der Suche nach einer Lösung so schwer getan habe.

Die Quintessenz von dem, was ich da so auf Anhieb gefunden habe war einfach. Es funktioniert nicht, da sowohl qemu wie auch VirtualBox keine physischen Festplatten verwenden können. Damit wollte ich mich aber nicht abfinden!

Ich habe gesucht und leider muss ich sagen, Ergebnisse habe ich nur für VirtualBox gefunden, dabei laufen die meisten meiner virtuellen Maschinen doch unter qemu. Aber egal, VirtualBox benutze ich schliesslich auch.

Also hab ich angefangen zu experimentieren. So habe ich herausgefunden, dass man einen physikalischen USB-Stick tatsächlich als Laufwerk in VirtualBox einbinden kann und siehe da, so habe ich schlussendlich auch die Kiste ins Rollen gebracht.

Eine nicht physische physische Festplatte

Ein Knackpunkt an der Geschichte war, wie kriegt man eine physische Festplatte so gebogen, dass VirtualBox sie benutzen kann? Nun, eigentlich ist das gar nicht so schwer.

Aber! VirtualBox steht ja im Ruf vorwiegend von denen benutzt zu werden, die lieber mit der Mouse arbeiten, also nicht so gerne tippen. Das wird hier aber nicht funktionieren. Hier muss man in den Terminal.

Schritt 1: Hinsetzen

Das ist eine kleine Anspielung auf den Film “Die tollkühnen Männer in ihren fliegenden kisten”.

Schritt 2: Die ID der Festplatte herausfinden

Das ist bei mir ziemlich einfach. Ich habe zwar einige Platten eingebaut, aber nur eine sitzt am USB.

ls -l /dev/disk/by-id/ | grep usb

Die ID der kompletten Platte ist wichtig, nicht einzelner Partitionen! Also das, was ich rot umrahmt habe.

Wer jedoch keine USB-Platte verwendet, sondern eine fest installierte, der muss

| grep usb

weglassen. Das “|” ist übrigens kein i, oder l, sondern das Zeichen welches man mit “STRG + <” bekommt!

Die ID haben wir jetzt also, jetzt müssen wir daraus etwas basteln, was VirtualBox auch versteht.

Schritt 3: Physische Platte für VirtualBox verwendbar machen

Achtung! Hierfür braucht man Administrator-Rechte!

Zuerst wechsel ich mal in das Verzeichnis, wo die Datei später auch sein soll. Das erspart mir die Eingabe eines Pfades. Wo man die Datei schliesslich speichert, ist völlig egal.

Jetzt brauchen wir das Programm “vboxmanage”, welche bei der Installation von VirtualBox dabei ist. Der Befehl sieht dann so aus:

sudo vboxmanage internalcommands createrawvmdk -filename usbdisk.vmdk -rawdisk /dev/disk/by-id/usb-SAMSUNG_HM160HC_5812271602C2-0\:0

Für jene, die nicht so gerne tippen, hier eine Variante, die ihr kopieren und einfügen könnt. Ihr müsst lediglich die ID, die ihr bei Schritt 2 kopieren könnt, einfügen.

sudo vboxmanage internalcommands createrawvmdk -filename usbdisk.vmdk -rawdisk

Wichtig, ihr müsst auch das Leerzeichen am Ende mitkopieren, oder nach dem Einfügen selbst einsetzen!

Hat alles geklappt, dann sieht das so aus. Wir haben also aus der physischen Festplatte eine VMDK Datei gemacht. Die wird aber wirklich nur dafür gebraucht, um für VirtualBox eine Datei bereitzustellen. Gearbeitet wird definitiv direkt auf dem physischen Laufwerk!

Schritt 4: VirtualBox einrichten

Zuerst startet man VirtualBox. Aber ich denke, soweit ist wohl jeder schon selbst gekommen. Aber, man muss VirtualBox mit Administrator-Rechte öffnen, da man ansonsten nicht auf die Festplatte zugreifen kann.

sudo VirtualBox

Hat man das, klickt man oben auf “Neu”

Ich nenne die virtuelle Maschine einfach RealWin10. Der Name ist aber völlig egal, da kann jeder so kreativ sein wie er will.

Speicher kriegt das gute Ding 4GB, sollte ja für mein Anliegen reichen.

Jetzt wird es ein bisschen kniffliger. Aber nicht viel. Wir müssen hier jetzt die erstellte VMDK einfügen. Also erst wählen wir aus, dass eine bestehende Platte genutzt werden soll und dann hinten auf den kleinen Ordner klicken. Beides von mir rot umrahmt.

Hier dann auf “Hinzufügen” klicken, da die Datei wohl kaum schon einmal eingefügt worden ist.

Hier muss man dann die VMDK Datei auswählen, die wir erstellt haben. Wer sich nun wundert, dass auf einmal die zuvor gesehenen Platten weg sind, den kann ich beruhigen. Die Bilder bis hier her habe ich gemacht und selbst vergessen VirtualBox mit Root-Rechten zu starten. Also keine Sorge, wenn ihr hier eine VMDK Datei einfügt, verschwindet nicht automatisch alles andere!

Soweit so gut. Bis hier hin hat dann ja alles geklappt, aber ein paar Dinge sind noch einzustellen.

Windows 10 wird ja immer so installiert, dass es UEFI zum booten benutzt. Also muss auch VirtualBox das berücksichtigen. Einfach ein Haken bei “EFI sktiveren (nur spezielle Gäste)”.

Ausserdem scheint es doch von Vorteil zu sein, mindestens 2 CPUs einzustellen.

So. Hat jetzt alles geklappt? Dann sollte man die Kiste ja starten können, oder?

Geil, oder? Warum da jetzt aber VirtualBox steht und nicht Windows, ist mir ein Rätsal. Auch die komischen Meldungen oben kann man eigentlich getrost ignorieren. Aber man baucht doch etwas Geduld.

Yeah! Hat geklappt! Jetzt noch schnell einloggen!

Geil, oder? Auch wenn das Fenster hier recht klein ist und die Icons links am Rand, wenn ich Windows dann wieder direkt boote ist die alte Auflösung wieder da und die Icons dort, wo ich sie haben will.

Toll! Und jetzt?

Also, spielen würde ich damit nicht. Ich habe es spasseshalber mal versucht, Civilisation startet auch, aber schön ist anders.

Was man aber durchaus problemlos machen kann sind zum Beispiel Updates. Oder irgendwas installieren. Eben all so zeug, wo selbstständig abläuft. Das kann man nun bequem virtualisiert erledigen, ohne damit den Rechner zu blockieren. Finde ich persönlich echt praktisch!

Ich kann mir auch gut vorstellen, dass wenn man beruflich zum Beispiel Programme nutzen muss, die unter Linux einfach nicht laufen wollen, man selbst aber eigentlich Linux bevorzugt, man so mit den Programmen auch arbeiten kann, während man eigentlich unter Linux unterwegs ist.

Generell denke ich aber, die Möglichkeiten, die sich hier bieten, sind gross!

Android mit VirtualBox

diabolusUmarov

Meine Schritt für Schritt Anleitung zu Android mit Qemu erfreut sich ja angenehmer Beliebtheit. Es gibt jedoch immer wieder ein paar Fragen nach VirtualBox und wie man Android dort installiert. Offensichtlich ist tatsächlich die Benutzeroberfläche ausschlaggebend, ob jemand Qemu oder VirtualBox benutzen möchte. Aber gut, jeder wie er will.

Inhalt:

Hier folgt nun die Schritt für Schritt Anleitung, wie man Android unter VirtualBox zum laufen bringt. Ich weise aber gleich darauf hin, in einigen Punkten werde ich auf die bestehende Anleitung verweisen, da es exakt das Gleiche ist.

Vorbereitung

Viel vorzubereiten gibt es bei der Geschichte nicht. VirtualBox muss installiert sein und man braucht eine ISO, von welcher aus man Android installieren kann.

Wie man VirtualBox installiert beschreibe ich nicht. Es gibt so viele Wege bei den verschiedenen Betriebssystemen, dass es schon ein kleines Buch werden würde, alles zu beschreiben. Ausserdem glaube ich, wer sich an Virtualisierung versucht, der weiss auch wie man so ein Programm installiert!

Dann braucht man eben noch die entsprechende ISO. Für dieses Beispiel verwende ich die ISO

android-x86_64-9.0-r2.iso

Diese habe ich hier heruntergeladen. Es sollte aber auch mit späteren Versionen genauso funktionieren, zumindest nehme ich das mal stark an!

Maschine in VirtualBox einrichten

Bei mir fängt das so an. Noch keine Maschine eingerichtet, VirtualBox ist quasi noch Jungfrau. Genau das werde ich aber jetzt ändern! Dafür einfach oben auf Neu klicken.

Hier müssen jetzt ein paar Einstellungen getroffen werden. Oben geht es los! Dabei ist der Name absolut irrelevant. Da kann alles stehen, es geht nur um einen für VirtualBox verwendeten Namen.

Den Ordner kann man auf den Standardwerten lassen. Ich ändere das gerne, da ich meine eigenen Verzeichnisse für die verschiedenen OS habe.

Als Typ muss man Linux angeben und bei Version Linux 2.6 / 3.x / 4.x (64-bit). Das kann man aber auch später noch ändern. Aber, auf diese Weise funktioniert es.

Dann “Weiter >“.

Nun gibt man an, wie viel Speicher Android haben soll. Ich spendiere ihm 4GB, also 4096MB. Das kann aber jeder nach den Ressourcen seines Rechners selbst entscheiden. Zu wenig sollte es nicht sein, sonst funktioniert es unter Umständen nicht.

Die liebe Festplatte. Keine zu nutzen wäre ein bisschen bescheuert finde ich und da noch keine vorhanden ist, zumindest für dieses Beispiel, muss ich eben eine erzeugen.

Welcher Typ soll es sein? Ich bleibe da bei VDI, denn da weiss ich, dass ich sie auch mit Qemu nutzen kann.

Art der Speicherung. Es ist natürlich schön, wenn man wirklich nur den Festplattenspeicher verliert, den man in der virtuellen Maschine auch wirklich nutzt. Da aber nur neuer Speicher hinzugefügt und keiner mehr freigegeben wird und man der Platte ohnehin eine Grösse geben muss, benutze ich die feste Größe.

Das Verzeichnis für die VDI Datei wird automatisch vergeben. Das kann man ändern, muss man aber nicht. Ich tue es nicht.

Als Grösse bleibe ich bei meinen 10GB. Das hat für Android bislang immer gereicht.

So. Die Kiste ist einsatzbereit und wartet darauf gestartet zu werden. Also, ein kleiner Druck oben auf Start und es geht los!

Die virtuelle Festplatte ist unbenutzt, es liegt keine ISO zum starten bereit, kein Wunder, dass da nachgefragt wird, von wo aus gebootet werden soll. Dort wählt man die entsprechende ISO aus und startet.

Geht doch! Bevor das aber nun installiert wird, schaue ich mal nach, ob es auch funktioniert und starte Android ohne Installation.

Ach du Schreck! Da stimmt wohl was nicht! Nur was?

Erst einmal die virtuelle Maschine ausschalten (Einfach das Fenster schliessen) und in die Einstellungen der Maschine.

Bei den Einstellungen unter Anzeige findet sich der Grafik-Controller. Diesen muss man umstellen auf VBoxVGA.

Dann der nächste Versuch!

Schon klappt der Mist! Warum auch immer man das auf VGA umstellen muss weiss ich zwar nicht, aber es funktioniert und das reicht mir!

Einwandfrei! Nun also die Kiste wieder ausschalten, neu starten und die Installation auswählen! Diese ist die Gleiche wie in der Anleitung für Qemu, die ich oben verlinkt habe. Das spare ich mir also hier.

Nach dem Befolgen der Qemu Anleitung

So. Jetzt könnte man auf Reboot gehen und OK anwählen um dann zu merken, der bootet wieder von der ISO. Das wollen wir aber nicht!

Leider konnte ich kein Bild davon machen, deshalb muss ich es so erklären. Oben im Menü geht es los.

Geräte -> Optische Laufwerke

Dort ist die ISO aufgeführt, die man zum installieren benutzt hat mit einem Haken davor. Der muss weg und fertig.

Nun kann man die Installation neu booten.

Geschafft! Jetzt noch alles einrichten und Spass haben! Ich hoffe, euch damit ein bisschen geholfen zu haben und da ich jetzt VirtualBox eh installiert habe, werde ich wohl hier und da noch ein paar kleine Anleitungen zu bringen.

Bis dahin viel Spass mit Android!

qemu mit snapshot

diabolusUmarov

VMs werden gerne dazu verwendet, irgendetwas auszuprobieren. In der Regel verwenden einige diese Technik, um sich mit einem anderen Betriebssystem vertraut zu machen. Aber, die Experimentierfreudigen benutzen eine VM vielleicht auch dazu, Software zu teste. Vielleicht selbst geschriebene? Vielleicht will man testen, ob nach einem make install auch wirklich alles dorthin kommt, wo es hingehört?

Wie dem auch sei. Wäre es nicht sehr angenehm, etwas testen zu können, ohne ein System wirklich zu verändern? Dafür gibt es natürlich verschiedene Möglichkeiten. Man könnte das OS, welches man einsetzen möchte, einfach in einer VM installieren und bevor man testet, kopiert man erst das Image und startet damit. Man kann alles kaputt machen, vielleicht auch mal unter Linux testen, was  »rm -rf /« bewirkt, löscht hinterher das Image und es ist nichts verloren.

Was aber, wenn man etwas testen will, was andere Software voraussetzt, um die Kompatibilität zu prüfen, oder ob sich die Programme in die Quere kommen? Nun, auch da kann man nach dem selben Prinzip vorgehen. Dagegen ist nichts zu sagen. Ausser, hat man ein grosses Image, dann kann das kopieren eine Zeit dauern.

Was aber, wenn es sich nicht um ein Test-System handelt, sondern über eine VM, die im Einsatz ist, mit der auch regelmässig gearbeitet wird? Klar, hier kann man ebenfalls mit einem Backup arbeiten. Es geht aber auch einfacher!

snapshot

Hier kommt jetzt der Parameter -snapshot ins Spiel. Startet man sein Gast-System mit diesem Parameter, so passiert alles, was man so anstellt, nicht wirklich im Image, sondern temporär. Das heisst, man kann sich voll auslassen, unter Umständen auch das System zerlegen und dennoch passiert eigentlich nichts! Neustarten und alles bleibt beim Alten.

Das kann eine Menge Zeit sparen! Angenommen, man hat ein System nach dem Vorbild von »qemu mit VNC in der Familie« aufgebaut. Die Images sind vielleicht 500 GB gross, will man davon echt jedes Mal erst eine Arbeitskopie anlegen? Das erfordert Platz und dauert ja schliesslich seine Zeit. Zeit, die man vielleicht zum testen gar nicht brauchen würde und hinterher hat man eigentlich noch gar nichts gemacht!

Der Parameter snapshot umgeht diesen Umstand einfach. Man startet die VM mit diesem Parameter, installiert, oder testet und wenn alles funktioniert, dann drückt man Strg + Alt + S und alles wird ins Image übernommen. Klappt es nicht, neustarten und alles ist wie vorher!

qemu mit VNC in der Familie

diabolusUmarov

Es gibt einen durchaus praktischen Nutzen von qemu mit VNC. Sagen wir mal, man hat eine vierköpfige Familie. Mutter, Vater und zwei Teenager. In der heutigen Zeit kann man Technik gar nicht schnell genug kaufen, um mit der rasanten Entwicklung Schritt zuhalten. Ausserdem ist es heute so, dass gerade auch die Kinder immer mehr im Internet recherchieren sollen. Mindestens ein Gerät mit Internet sollte also vorhanden sein.

Inhalt:

Hardware
Warum qemu als VNC-Server?
Software
Einschränkungen
Was noch?

Man könnte nun hingehen, ein guten Computer anschaffen und diesen in der Familie teilen. Der Streit ist vorprogrammiert! Dauernd werden Ansprüche an dem Computer geltend gemacht und jeder wird seine Gründe anführen und als besonders wichtig einstufen. Es mag Familien geben, wo das kein grosses Problem darstellt, doch in den meisten Fällen kommt es zum Krieg.

Wie könnte das Problem nun gelöst werden? Da hat man drei Optionen:

  1. Man spricht ein Machtwort, erstellt einen Nutzungsplan und jeder steht unter Zeitdruck. Nicht schön, aber könnte funktionieren.
  2. Anstelle eines wirklich guten Rechners, beschafft man vier Geräte aus dem mittleren Sektor. Funktioniert auch und ist, mit ein paar Abstrichen, auch durchaus akzeptabel. Wäre da nicht die Sache, dass die Technik einfach Gas gibt und die Hardware schon bald zu schwach werden könnte.
  3. Man besorgt doch einen starken Rechner, der für eine Zeit up to date bleibt und dazu noch vier Terminals. Die können schwach sein, solange ein Linux darauf läuft, spielt das keine wirkliche Rolle!

Wir wollen Option 3 näher unter die Lupe nehmen!

Hardware

Eine wirkliche Investition stellt eigentlich nur der Server dar. Der sollte Power haben! Dicker CPU, viel schneller Arbeitsspeicher und ausreichend Speicherplatz. Da muss der Geldbeutel entscheiden, wie viel möglich ist. Je mehr, je besser!

Die Terminals können kostengünstig sein. Vielleicht gebrauchte Laptops, irgendwelche Angebote vom Discounter, spielt alles keine wirkliche Rolle. Er sollte eine ausreichende Auflösung bieten und dazu in der Lage sein, einen VNC-Viewer unter Linux laufen zu lassen. Mehr wird davon nicht verlangt!

Bei mir sieht das so aus:

Mein Rechner, der auch als Server fungiert, hat folgende Hardware:

CPU: Intel® Core™ i3-2100 CPU @ 3.10GHz × 4
RAM: 6GB DDR3
HDD: runde 2 TB
Grafik: Nvidia GeForce GTX 1050ti

Die Terminals sind verschiedene Geräte. Ein älterer HP Laptop, ein Asus EeePC NetBook und selbst ein Sony Vario mit einem Intel Pentium M ist dabei.

Keine Luxusausstattung, aber es läuft! Mit etwas mehr Geld, kann man das natürlich deutlich besser aufstellen. Zumindest den Server, denn wie gesagt, bei den Terminals ist es relativ egal, was die unter der Haube haben.

Nun setze ich nicht qemu ein, um den Terminals einen VNC zu bieten, sondern starte die VNC-Server direkt unter meinem Linux. Aber auch nur, weil meine Kinder selbst im System nichts machen wollen. Die wollen ein bisschen Spielen, mal was recherchieren und mehr interessiert die nicht. Da man aber nicht darauf bauen kann, dass es in allen Fällen so ist, ist der Einsatz von qemu als VNC-Server durchaus vorteilhaft!

Warum qemu als VNC-Server?

Die Frage ist einfach zu beantworten. Nicht immer will jeder das gleiche System und nicht immer ist es gewünscht, den “Administrator” zu rufen, wenn man etwas installieren möchte.  Oder, es wird für die Schule, Berufsschule, oder warum auch immer Software vorausgesetzt, die nur unter einem bestimmten System lauffähig ist. Der eine braucht also Windows, wieder ein anderer ist da flexibel, vielleicht wird MacOS benötigt, oder einer will AROS, oder etwas ähnliches. Vielleicht will auch einer den Computer nutzen, als wäre er ein Handy und möchte lieber Android?

Hier kommt jetzt qemu ins Spiel!

Software

Der Server kann vollständig minimalistisch aufgesetzt werden. Er muss nur qemu starten können, mehr braucht er nicht zu machen! Mehr soll er auch gar nicht machen, denn je weniger er arbeiten muss, desto mehr Leistung steht für die VNC-Server zurecht.

Man startet nun vier Gast-Systeme und lässt sie einen VNC-Server starten. Die Systeme können skaliert und den Bedürfnissen der jeweiligen Benutzer angepasst werden. Die Frau will vielleicht nur surfen, man selbst braucht Leistung für Grafik, 3D-Anwendungen und ähnliches, eines der Kids guckt nur YouTube und will ein bisschen zocken, während das andere Kind definitiv ein Windows braucht, mit Office und allem was dazugehört.

Angenommen, man hat einen richtig starken Server, dann könnte man sich selbst 4 – 8 Kerne spendieren, 8GB Arbeitsspeicher und viel Festplattenplatz. Der Frau reichen 2 Kerne mit 2 – 4 GB Arbeitsspeicher und nur etwas Platz, um vielleicht etwas herunterzuladen, für das erste Kind kommt eine ähnliche Konfiguration zum tragen und das letzte Kind bekommt auch 4 – 8 Kerne und entsprechend Arbeitsspeicher.

Die Festplatten werden als Images angelegt und können bei Bedarf auch vergrössert werden. Hier kommt dann noch ein gewaltiger Vorteil zum Vorschein. Ein Backup ist unglaublich einfach zu erstellen! Einfach das Image kopieren und man ist fertig! Das kann man auch beispielsweise dafür nutzen, nur einmal ein System aufzusetzen und es sowohl der Frau, wie auch dem einen Kind zugänglich zu machen. Einmal installiert, Image kopiert und schon hat man zwei fertige Systeme, die sofort gestartet werden können!

Noch angenehm ist, man muss nicht an die Terminals, um sie zu installieren. Das macht man einfach alles an einem Platz, von dem aus man auf den Server zugreifen kann und muss nicht dauernd hin und her rennen.

Sich selbst installiert man vielleicht Gentoo, Frau und einem Kind Mint und Kind Nummer 2 bekommt sein Windows. Zur Sicherheit kann man davon direkt ein Backup machen und falls man sein System zerlegt, hat man hinterher ein Neues am Start. Einfach und effizient!

So. Nachdem alles installiert und die Gast-Systeme gestartet wurden, greifen die Terminals nun auf ihren Server zu. Im Vollbildmodus und dem heimischen Netzwerk merkt man gar nicht, dass man nicht lokal arbeitet!

Man kann aber auch, was ich ebenfalls als grossen Vorteil ansehe, von ausserhalb auf sein System zugreifen! Wo auch immer ein VNC-Viewer bereitsteht und man mit dem Internet verbinden ist, kann man sich in seinen Server einloggen! Man selbst arbeitet vielleicht in einem Büro und kann die Mittagspause, oder einen Leerlauf dazu nutzen, zuhause etwas zu arbeiten. Kind Nummer 2 kann vielleicht einem Freund von dessen Rechner aus zeigen, was er bei sich zuhause gemacht hat und ähnliches. Viele, viele Vorteile. In dem Fall aber bitte darauf achten, dass man nicht ohne gutes Passwort auf das System zugreifen kann. Sonst drohen entsprechende Konsequenzen!

Nun kann die Spielerei losgehen! Frau und Kind können surfen, in YouTube Filme schauen, recherchieren, Texte schreiben, Tabellen erstellen, oder was auch immer. Kind Nummer 2 kann seine Software herunterladen und installieren und man selbst wird auch wissen, was man machen will.

Neben der Installation verschiedener Betriebssysteme, der einfachen Backup-Möglichkeit und der Möglichkeit, ein System für mehrere Gäste aufzusetzen, gibt es aber noch einen Vorteil!

Es spielt keine Rolle, ob ein System sich verabschiedet, irgendwelche Viren eingeschleppt, oder das System aus einem sonstigen Grund nicht mehr benutzbar geworden ist! Das betrifft dann nur dieses eine System und den Schuldigen! Im Unterschied zu meiner Variante, wo eine Beschädigung des Systems gleich alle betreffen würde, fällt mit der Gast-Lösung nur ein System aus. Macht man regelmässige Backups, ist das auch kein Problem! Kaputtes Image löschen, Backup kopieren, entsprechend benennen und die Kiste läuft wieder!

Einschränkungen

Leider ist auch diese Variante nicht die eierlegende Wollmilchsau! Es gibt Abstriche, die man machen muss! So scheint die Hardwarebeschleunigung dabei nicht gerade die Beste zu sein. Da fehlt mir leider die Erfahrung, aber daran arbeite ich gerade. Es kann also sein, dass Spiele mit hoher Grafikanforderung nicht, nicht gut, oder nur unspielbar betrieben werden können!

Man hat keinen Zugriff auf die Hardware. Sprich, man kann nicht einfach einen USB-Stick anstecken und davon etwas installieren, oder etwas darauf speichern. Gleiches gilt natürlich für CD/DVD/Blueray. Während man sich wegen einer Installation weniger Sorgen machen muss, schliesslich findet man eigentlich alles im Netz, oder installiert es über den Paketmanager, will man doch mal Bilder, Videos, oder ähnliches auf einem Stick, oder einer Karte speichern. Das fällt flach! Dafür gibt es zwar Möglichkeiten, aber die habe ich noch nicht getestet. Sobald ich jedoch weiss, wie man das bewerkstelligen kann, werde ich einen entsprechenden Beitrag bringen!

Dann wäre da noch eine Sache mit dem Netzwerk. Qemu startet mit dem Parameter -net nic -net user immer ein eigenes Netzwerk. Das sieht man auch, wenn man die IP des Rechners abruft. Das heisst, die Rechner können sich untereinander nicht sehen und finden auch keine Netzwerkdrucker, oder andere Netzwerkgeräte im heimischen Netzwerk. Das kann man jedoch mit VPN, oder einer Netzwerkbrücke umgehen. Auch dazu werde ich noch einen eigenen Beitrag bringen.

Was noch?

Es gibt noch einiges, was man auf diese Weise realisieren kann. Beispielsweise will man vielleicht ein eigenes System haben, in welchem man geschäftliche Aktivitäten abwickelt. Wo das Passwort für Online-Banking gespeichert ist, sonstige sensible Daten zu finden sind und ähnliches. Mit qemu bastelt man sich dann einfach ein entsprechendes System zusammen, macht dort nur sensible Sachen und benutzt ansonsten ein anderes System, wo es keine Rolle spielt, wer davor sitzt.

Oder, man bekommt öfter Besuch und will nicht, dass die irgendetwas durchsuchen, aber dennoch Zugriff auf den Rechner haben dürfen. Man kann ihnen ein System einrichten, wo sie sich voll austoben können.

Es gibt so viel, was man auf diese Weise realisieren kann. Der Fantasie sind fast keine Grenzen gesetzt. Ein eigenes System nur für Spiele, eins nur für Bürokram, ein anderes rein zum surfen. Alles kein Problem und in wenigen Minuten realisiert! 

qemu und VNC

diabolusUmarov

VNC ist schon eine geniale Sache. Man kann bequem von einem entfernten Rechner auf den Desktop zuhause zugreifen, seine Arbeit erledigen, Mails checken, oder was auch immer. Zugegeben, vieles davon geht auch von jedem Handy aus, aber es gibt dennoch Fälle, wo so ein VNC durchaus nützlich ist!

Ich zum Beispiel nutze TigerVNC und quäle damit meine Rechner. Eigentlich nutze ich bevorzugt ssh, um Programme anderer Rechner auf meinem eigenen anzeigen zu lassen, aber gerade wenn man unterwegs ist und das mobile Netz nicht so recht mitspielen will, stösst ssh leider gerne an seine Grenzen. Deshalb eben VNC.

Hier soll es aber nicht um meine Spielereien gehen, sondern um qemu! Qemu hat die nette Eigenschaft, anstelle eines Fensters einen VNC-Server zu starten. Anschliessend kann man dann bequem darauf zugreifen und das gestartete System benutzen. Sowohl von dem lokalen Rechner, als auch von einem Rechner aus dem Netzwerk. Welchen Vorteil das hat, kommt in einem anderen Beitrag.

qemu mit VNC-Unterstützung starten

Wie man sich eine qemu-Umgebung aufbaut, habe ich bereits in meinem Beitrag »Schnell ans Ziel mit qemu« beschrieben. Ich gehe also davon aus, dass es kein Problem sein sollte, eine solche Umgebung zum laufen zu bringen.

Will man nun, anstatt eines Fenster, einen VNC-Server starten, fügt man einfach folgenden Parameter in das Start-Skript ein, oder tippte es in den Terminal.

-vnc :1

Damit sagt man qemu, dass man gerne einen VNC-Server gestartet hätte. Dahinter steht noch ein :1. Damit kann man angeben, über welchen Port man den Server erreichen möchte. Standardmässig benutzt VNC 5900 als Port. Mit diesem Parameter würden wir den Server also mit 5901 erreichen. Mit :2 wäre es 5902 und so weiter. Im Regelfall ist aber gar nicht die Angabe des ganzen Ports notwendig und man muss ebenfalls nur :1, :2 und so weiter angeben.

Gut. Nachdem der Parameter eingefügt und qemu gestartet wurde, passiert nichts. Logisch, wir wollen ja kein Fenster bekommen, sondern einen VNC-Server. Den erreichen wir (das kann sich je nach verwendeter Software unterscheiden!) so:

vncviewer :1

In dem Fall wollen wir einen VNC-Server auf dem lokalen Rechner erreichen, mit dem Port 5901. Wenn alles passt, öffnet sich ein Fenster und darin sieht man die virtuelle Umgebung. Läuft also prima!

Warum sind da jetzt zwei Mousepointer?

Es passiert tatsächlich nicht immer, dass man neben dem lokalen Mouse-Pointer auch noch den des Gastes sieht. Wenn es aber passiert, was leider häufiger der Fall ist, ist es ziemlich nervig! Denn dummerweise reagieren die Pointer nicht synchron! Soll heissen, in den meisten Fällen ist der des Gast-Systems langsamer, als der vom Host. Es ist stellenweise super mühsam, so im Gast etwas zu erreichen! Aber, es gibt einen Trick, um dem Abhilfe zu schaffen.

Kleine Anmerkung: Sollte es einen besseren Weg geben, dass Problem mit dem Pointer zu lösen, ich bin für Informationen dankbar!

Ich behelfe mir in diesem Fall damit, dass ich qemu erkläre, dass es ein Tablet emulieren soll. Das funktioniert ganz einfach mit dem Parameter:

-usb -device usb-tablet

Mit -usb aktivieren wir den USB-Treiber, der standardmässig nicht eingeschaltet ist. Danach folgt der Parameter -device usb-tablet.

Starten wir jetzt den Gast, so können wir uns mittels VNC damit verbinden und haben nur noch einen Pointer, was das Arbeiten viel, viel angenehmer macht!

Schnell ans Ziel mit qemu

diabolusUmarov

Ich möchte gleich zu Beginn betonen, auch ich habe noch viel zu lernen, was qemu angeht und es liegt im Bereich des Möglichen, dass nicht alle meine Angaben korrekt, oder vollständig sind!

Mir geht es mit dieser kleinen Anleitung eher darum, einem Interessenten qemu etwas näher zubringen und ihn zu einem Erfolgserlebnis zu verhelfen. Es gibt sehr viele Anleitung zu qemu im Netz, die mit Sicherheit deutlich detailreicher und ausreifter sind, als dass was ich abliefere. Ich möchte auch nicht noch eine Anleitung schreiben, weil es noch nicht genug gibt, doch seit ich meine Anleitung für Android mit qemu Schritt für Schritt geschrieben habe, wurde ich schon einige Male gefragt, ob es nicht auch eine Erklärung zu qemu für Noobs gibt.

Genau das soll diese Anleitung erreichen. Am Ende soll der Interessierte eine qemu Umgebung laufen haben, die er mit den von ihm gewünschten ISOs füttern kann, ohne grosses Wissen mitzubringen.

Nur eins setze ich voraus. Man muss qemu installiert haben! Da ich mit Gentoo-Linux arbeite und da die Installation etwas anders verläuft, bin ich nicht ganz firm, wie man qemu zum Beispiel unter Mint, Ubuntu und Co installiert.

qemu zum testen anderer Distributionen nutzen

Anfangen wollen wir ganz simpel. Es soll ein x86_64 Prozessor virtualisiert werden. Voraussetzung dafür ist natürlich, dass man mit einem solchen Prozessor arbeitet!

Kurz noch schnell den Unterschied zwischen virtualisieren und emulieren erklären. Das mag technisch nicht ganz korrekt sein, sollte aber das Verständnis verbessern.

Emulieren heisst, man bildet eine bestimmte Hardware komplett nach. Also Prozessor, Speicher, Peripherie usw. Nichts ist real, alles wird dem verwendeten Betriebssystem vorgegaukelt.

Virtualisieren ist so ein bisschen eine Mischform. Was an echter Hardware genutzt werden kann, wird auch genutzt. Alles andere wird wieder emuliert. Das ist auch der Grund, warum Software in einer virtuellen Hardware meist schneller läuft, als in einer emulierten.

Gut, genug davon. Was genau wollen wir erreichen? Die virtuelle Umgebung soll einen x86_64 Prozessor mit 1 Kern haben, 2 GB Arbeitsspeicher und netzwerkfähig sein!

Fangen wir an!

Für diese Anleitung verwende ich die Live-CD »linuxmint-18.1-mate-64bit.iso«. Das hat keinen besonderen Grund, die hatte ich einfach noch auf der Platte und so muss ich mir keine neue ziehen. Es sollte schlussendlich aber keine Rolle spielen, welches ISO man mit qemu starten will, solang es zum Prozessor passt! Also nicht versuchen, ein 64-Bit Linux mit einem 32-Bit qemu zu starten, oder ein PowerPC-OS auf einem x86-qemu. Es geht zwar nichts kaputt, wird aber nicht funktionieren!

Vorne fangen wir an! Das heisst, Terminal öffnen und zuerst entscheiden wir uns dafür, welchen qemu wir benutzen. Das wird nicht in den Parametern eingestellt, sondern man startet eine bestimmte Variante von qemu. In unserem Fall wäre das:

qemu-system-x86_64

Als Nächstes wollen wir uns um den Speicher kümmern. 2GB wollen wir haben und das erreichen wir mit folgendem Parameter:

-m 2048

Wie man sich denken kann, sind die 2048 die Megabyte, die wir haben wollen. Will man nur 1GB Arbeitsspeicher, dann setzt man hier natürlich 1024 ein. Analog dazu sind 3GB dann 3072 usw. Sollte sich selbst erklären!

Dann soll das System virtualisiert und nicht emuliert werden. Dafür brauchen wir:

-enable-kvm

Damit sagen wir qemu, dass wir volle Virtualisierung wollen!

Weiter gehts mit den Kernen. Einen Kern wollen wir haben und das erklären wir qemu mit dem Parameter:

-smp 1

Jetzt wollen wir auch noch Netzwerkfähigkeit. Das erreichen wir mit dem Parameter:

-net nic -net user

Ausgezeichnet! Da haben wir ja schon einen kleinen Rechner zusammengebaut! Im Ganzen sieht das dann so aus:

qemu-system-x86_64 -m 2048 -enable-kvm -smp 1 -net nic -net user

Ist ein wenig Tipparbeit, aber man kann es überleben!

Damit haben wir das Problem aber noch nicht gelöst, denn im Moment haben wir nur einen Rechner, ohne Laufwerke! Man könnte es so starten, doch passieren würde nichts, bis nicht viel!

Bauen wir also noch schnell unser CD-ROM Laufwerk ein. Überraschenderweise funktioniert das mit dem Parameter:

-cdrom

Äusserst schockierend, ich weiss! Aber gut, CD-ROM erfolgreich installiert, nun muss da eine CD, bzw. ein Image rein. Dazu geht man einfach in das Verzeichnis, wo man das ISO gespeichert hat. Ich nehme an, den Umgang mit cd sollte jedem bekannt sein, ansonsten seit ihr hier falsch und müsst weiter vorne anfangen!

Ich für meinen Teil baue mir für jedes OS einen eigenen, kleinen Verzeichnisbaum auf. Das Hauptverzeichnis trägt in diesem Fall den Namen mint. Darin kommt das Verzeichnis images. Warum? Weil ich in der Regel auch mindestens eine Festplatte verwende und je nachdem, was ich mit dem OS anfange, tauchen auch noch weitere Images auf. Beispielsweise weitere CDs, oder im Falle von Windows for Workgroups, tatsächlich betreibe ich so eine Maschine, auch Disketten. Das kommt alles bei images rein und ich habe Ordnung!

Der Einfachheit halber, liegt das ISO in dem Verzeichnis, aus welchem heraus ich auch qemu starte. Dann sieht der Parameter so aus:

-cdrom linuxmint-18.1-mate-64bit.iso

Zum Schluss erklären wir qemu noch, welches Medium gebootet werden soll. Manchmal funktioniert es komischerweise ohne den Parameter, manchmal auch wieder nicht. Um sicherzugehen, bauen wir es einfach ein, tut ja keinem weh!

-boot d
  • a = Floppy
  • c = Festplatte
  • d = CD-ROM
  • n = Netzwerk

Wie bereits gesagt, es funktioniert in manchen Fällen auch ohne diesen Parameter. Netterweise, hat man zum Beispiel nur eine Festplatte eingebaut und dennoch den Parameter -boot d gesetzt, bootet die Kiste trotzdem von der Platte. Ich vermute mal, es geht einzig um das Vorhandensein des Parameters.

Also, komplett sieht das dann so aus:

qemu-system-x86_64 -m 2048 -enable-kvm -smp 1 -net nic -net user -cdrom linuxmint-18.1-mate-64bit.iso -boot d

Ihr könnt diese Zeile einfach kopieren und in den Terminal einfügen. Wenn ihr das gleiche Image habt, sollte es funktionieren!

Na da schau einer an, das Boot-Bild von Mint haben wir ja schon einmal geschafft! Geht es auch weiter?

Tatsache! Linux Mint 18 in einem Fenster unter Gentoo-Linux! Genial, oder? Funktioniert wunderbar und nun kann man mit Mint rumspielen, ohne Gefahr zu laufen, dass eigene System zu beschädigen, oder zu blockieren!

Für die Schreibfaulen!

Gerade bei Umsteigern von Windows habe ich oft gemerkt, diese User sind bequem geworden. Tippen, nur wenn es sein muss! Um denen die Tipp-Arbeit zu verkürzen, hier etwas zum kopieren und einfügen!

echo "qemu-system-x86_64 -m 2048 -enable-kvm -smp 1 -net nic -net user -cdrom linuxmint-18.1-mate-64bit.iso -boot d" >> startMint.sh && chmod 0740 startMint.sh

Geht im Terminal einfach in das Verzeichnis, in dem das ISO liegt, kopiert den Krempel hier, fügt ihn in den Terminal ein und führt es aus. Hinterher hat man ein kleines Skript im Verzeichnis, welches man mittels:

./startMint.sh

starten kann!

Aber bitte dran denken, es geht NUR dann, wenn ihr auch das exakt gleiche Image habt! Wenn nicht, müsst ihr linuxmint-18.1-mate-64bit.iso durch den Namen eures Images ersetzen! Ich empfehle, dass Skript erstellen zu lassen und dann mit einem Editor zu verändern. Das ist bequemer, wie ich finde!

Das Skript kann man natürlich auch öffnen, Parameter verändern und so ein bisschen Erfahrung sammeln. Das kann nichts schaden, denn je besser man sich damit vertraut macht, desto leichter fällt es hinterher, eine für sich nutzbringende, virtuelle Umgebung zu schaffen!

Und was jetzt?

Wie gesagt, nun kann man Mint, oder welches OS man sich ausgesucht hat, testen, nach Lust und Laune. Will man jedoch mehr damit machen, so wünscht man sich natürlich die Installation auf einer Festplatte.

Wie man diese erstellt, einbindet und das alles, gibt es dann im nächsten Beitrag!

Dateiübertragung zwischen Android und Linux

diabolusUmarov

Dieser Beitrag richtet sich nicht nur an Android in einer virtuellen Umgebung, sondern kann auch mit jedem Handy/Tablet verwendet werden. Es gibt auch jede Menge andere Varianten, wie man Daten zwischen Android und Linux hin und her sieben kann, ich bevorzuge allerdings diese.

Linux

Auf dem Rechner, auf welchem Linux läuft, gibt es nur wenig vorzubereiten und viele werden alles notwendige sowieso schon installiert haben.

Man benötigt sshfs unter Linux. Es muss gestartet und einsatzbereit sein. Da gibt es eigentlich nicht besonders viel zu erledigen, in den meisten Fällen muss man es nur installieren und aktivieren und schon ist man fertig.

Da sshfs bereits sehr gut dokumentiert ist, gehe ich nicht weiter darauf ein. Ich denke, jeder, der lesen kann und keine Angst vor dem Terminal hat, wird das hinbekommen. Dafür muss man kein Raketenwissenschaftler sein!

Was man auf jeden Fall wissen muss, ist der Name, oder die IP vom Linux-Rechner. Ich selbst verwende immer den Namen, den ich dem Rechner in meiner FritzBox gegeben habe, die IP funktioniert logischerweise auch und das in aller Regel auch zuverlässiger.

Zwar gehe ich davon aus, wer sshfs installieren und starten konnte, der weiss auch, wie man die IP im lokalen Netzwerk herausfinden kann, doch sollte dem nicht der Fall sein, so geht es!

Terminal öffnen und dort

ifconfig

eingeben. Dann erscheint in etwa folgendes:

diabolus@horst ~ $ ifconfig
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.xx  netmask 255.255.255.0  broadcast 192.168.0.255
.
.
.

Wichtig ist die Adresse hinter inet, was ein wenig verwirrend ist, denn das ist NICHT die Adresse, über die der Computer vom Internet aus erreichbar ist! In meinem Fall also

192.168.0.xx

Wo hier jetzt xx steht, steht natürlich auch eine Zahl. In einigen Fällen steht auch statt der 0 eine 2, dass spielt aber keine wirkliche Rolle. Wichtig ist, diese Adresse braucht man später in Android!

Android

Es gibt einige Varianten, wie man von Android aus auf Linux zugreifen kann. Der einfachste und funktionalste Weg, den ich bislang gefunden habe, bietet der ES Datei Explorer

Er kann recht nervig sein, da er ganz gerne mal Werbung macht, hier und da auch Funktionen aktiviert, die man eigentlich nicht haben wollte, aber ist er für den eigenen Geschmack entsprechend konfiguriert, dann läuft er einwandfrei und bietet einen wirklich tollen Funktionsumfang!

So sieht der Knecht in etwa nach der Installation aus. Mehr muss man eigentlich nicht machen, kann man aber, wenn man will. Es gibt einige Einstellmöglichkeiten, dass Thema kann man ändern und was weiss ich noch alles. Ich benutze ihn in der Regel so, wie er gekommen ist.

Scrollt man in der linken Auswahl etwas nach unten, so findet sich der Menüpunkt Netzwerk. Klickt man den an, klappt er sich auf und was wir dort brauchen ist FTP.

Normalerweise wird sich darin kein Eintrag befinden, da ich jedoch mit dem Ding arbeite, habe ich natürlich auch meinen Rechner bereits gespeichert.

Um einen neuen Server anzulegen, drückt man auf Neu. Entweder unten in der Liste, oder oben, wo ich den Pfeil hingezeichnet habe.

In der Auswahl wählen wir sftp aus, da wir ja auf einen solchen Server zugreifen wollen.

Hier muss man nun ein paar Dinge eintragen. Bei Server trägt man die IP-Adresse ein, die man vorher mit ifconfig ausgelesen hat. Ich sage es noch einmal, da gehört eigentlich KEIN xx rein, sondern die Zahl, die ifconfig ausgegeben hat!

Bei Port steht automatisch eine 22. Sollte man bei Linux für sshfs einen anderen Port verwenden, muss man das entsprechend abändern.

Der Benutzername ist jener, mit dem man sich bei Linux anmeldet.

Ebenso das Kennwort! 

Bei Anzeigen als kann man angeben, wie der Server in ES Datei Explorer angezeigt werden soll. Das kann man frei wählen.

OK drücken und fertig!

Hat alles geklappt, ist man wieder hier und sieht den eben eingetragenen Server. Einfaches daraufklicken und man wird verbunden.

Das sieht dann in etwa so aus. Man ist im Wurzelverzeichnis (also /) von Linux. Aber keine Sorge, die Berechtigungen sind alle erhalten geblieben. Man kann nur auf das zugreifen, wofür der Benutzer auch berechtigt ist.

Will man in seinen persönlichen Ordner, dann geht man erst zu home und dann zu seinem Benutzernamen.

Will man nun etwas kopieren, drückt man einen Moment auf das entsprechende Objekt, bis an jedem Eintrag diese kleinen Kreise erscheinen. Bei dem Objekt, auf welches man gedrückt hat, erscheint ein kleiner Haken und der Kreis wird grün. Man kann nun noch weitere Objekte auswählen, wenn man will und drückt dann anschliessend unten auf Kopieren, Ausschneiden, oder was auch immer man damit machen will. Das, oder die Objekte wandern in die Zwischenablage. Nun müssen wir ein Ziel dafür finden.

Links in der Auswahl geht man zu Lokal und wählt dort seinen Zielort aus. Ich selbst benutze immer Heruntergeladen, aber man kann natürlich auch Interner Speicher auswählen, oder wo man die Objekte eben haben will. Vielleicht muss man ein bisschen suchen, aber wirklich viel falsch machen kann man eigentlich nicht.

Hat man sein Ziel erreicht, drückt man unten auf Einfügen, wodurch die Übertragung gestartet wird.

Schon sind wir fertig! Die Datei wurde übertragen und kann nun auf dem Gerät voll genutzt werden. Bilder werden dabei auch sofort in der Galerie, oder anderen Apps angezeigt und können verwendet werden.

War doch gar nicht so schwer, oder?

Wer Anmerkungen dazu hat, der kann gerne die Kommentare benutzen! Ich würde mich freuen!

Android mit qemu Schritt für Schritt

diabolusUmarov

Zuerst sei gesagt, diese Anleitung bezieht sich auf Linux! Da ich selbst kein anderes Betriebssystem nutze, kann ich dazu auch keine Angaben machen!

Desweiteren verwende ich Gentoo-Linux und setze voraus, dass der geneigte Leser dazu in der Lage ist, qemu auf seinem System zu installieren. Wichtig hierbei ist, es muss

qemu-system-x86_64

oder

qemu-system-i386

ausführbar sein!

Schritt 1: Android downloaden

Hierzu geht man auf die Seite http://www.android-x86.org/download und läd sich dort das passende Image herunter. In meinem Fall, so wie es hier in der Anleitung beschrieben wird, ist es die Datei

android-x86_64-8.1-rc2.iso

Mein OS ist 64-Bit, ich verwende qemu-system-x86_64, wodurch natürlich Android x86_64 logisch für mich ist. 8.1-rc2 ist die Versionsnummer von Android. Ihr solltet die Datei an einen Ort speichern, den ihr später von der Konsole auch gut erreichen könnt. Ich lege mir für meine virtuellen Systeme immer einen extra Ordner an. In dem Fall eben android. Dort kommt wieder ein Ordner hinein, welchen ich images nenne. Das schafft für mich mehr Übersichtlichkeit. Das gespeicherte ISO kommt dann natürlich in images, was klar sein sollte.

Schritt 2: Virtuelle Festplatte für qemu erstellen

Das ist denkbar einfach. Wir gehen also im Terminal in das Verzeichnis für die Images und dort wird folgender Befehl eingegeben:

qemu-img create -f qcow2 android.img 10G

Natürlich kann man auch eine andere Grösse als 10G angeben, doch diese hat sich bei mir als ausreichend erwiesen. Das sollte jedoch jeder für sich entscheiden. Aber bitte daran denken, 4GB ist das Minimum, 8GB werden empfohlen. Je nachdem, was man mit Android machen will, sollte man darauf achten, dass noch genug freier Speicher verfügbar ist, auch im Hinblick auf mögliche Updates. 

Schritt 3: Startskript anlegen

Dieser Schritt ist nicht zwingend erforderlich, aber in meinen Augen hilfreich. Natürlich kann man stattdessen auch immer den kompletten Befehl eintippen, sich eine GUI dafür bauen (obwohl die, die das können, wohl kaum diese Anleitung lesen müssen), oder einen Starter in einem DM anlegen. Das ist jedem selbst überlassen. Ich verwende ein Skript, da ich sowieso gerne im Terminal arbeite.

Das Skript ist einfach und besteht auch nur aus einer einzigen Zeile:

qemu-system-x86_64 -m 2048 -boot d -enable-kvm -smp 3 -net nic -net user -cdrom images/android-x86_64-8.1-rc2.iso -hda images/android.img

Gespeichert wird das Skript ins android Verzeichnis, in meinem Fall habe ich es startAndroid.sh genannt und man muss ihm noch die Rechte geben, um auch gestartet werden zu können.

chmod 0760 startAndroid.sh

Nun sollte mittels

./startAndroid.sh

qemu starten, was dann in etwa so aussehen sollte

Schritt 3.1 (optional): Android testen

Ich selbst mache mir nur ungerne unnütze Arbeit. Bevor ich also mit der Installation und allem beginne, will ich auch wissen, ob die ganze Nummer auch funktioniert. Android kommt einem da entgegen und bietet eine Option an, Android auszuführen, ohne es zu installieren.

Man wählt einfach

Live CD - Run Android-x86 without installation

aus und wartet ab was passiert. Wenn alles passt, dann sollte, nachdem einige Zeit ein android im Fenster zu sehen war, so etwas auftauchen

Als Test sollte das ausreichend sein. Also weiter!

Schritt 4: Installation

Hier wird es etwas fummelig und ich habe ein paar Anläufe gebraucht, bis es schlussendlich zum Ergebnis geführt hat. Es geht um die Vorbereitung der Festplatte, des Boorloaders usw. Dinge, die man bei Android so eigentlich nicht kennt. Aber gut, da muss man eben durch und das schöne ist, man muss es nur einmal!

Wir starten also wieder Android und wählen dieses Mal die Option

Installation - Install Android_x86 to Harddisk

Schon sieht es mehr nach Linux, als nach Android aus. Aber keine Panik, nach der Installation erlebt man so etwas, ausser beim Bootvorgang nicht mehr!

Da die virtuelle Festplatte zur Zeit noch leer ist, müssen wir sie vorbereiten und wählen dazu

Create/Modify partitions

aus. Es erscheint folgendes

Ich habe es erfolglos mit No versucht, deshalb wählen wir Yes und bekommen folgendes gezeigt

Klingt dramatisch, ist aber total harmlos. Irgendeine Taste drücken und schnell wieder vergessen.

Ignoriert bitte, dass bei Size in dem Bild 5.0 GiB angezeigt wird. Aus Platzgründen konnte ich für diese Anleitung keine 10GB Platte erstellen. Wer eine 10GB Platte erstellt hat, der bekommt hier natürlich die korrekte Grösse angezeigt!

Wir müssen nun die virtuelle Platte für Android vorbereiten. Die Platte ist ausgewählt und auch New wird netterweise bereits markiert. Wir müssen also nur noch Enter drücken.

Das tun wir auch gleich 5x. Es ist ausreichend, wenn man alle Werte, nach denen gefragt wird, auf dem Standard belässt. Also einfach Enter drücken und fertig.

Hat alles korrekt funktioniert, erscheint folgendes

Die Partition ist erfolgreich eingerichtet und es kann weitergehen. Mit den Pfeiltasten geht man nun weg von New hin zu Write. Das ist wichtig, denn alles, was wir bisher getan haben, dient nur der Vorbereitung. Erst wenn wir die Änderungen auch wirklich geschrieben, also Write ausgewählt haben, werden die Änderungen auch wirklich auf der Platte vorgenommen!

Natürlich wird man noch gefragt, ob man die Änderungen wirklich vornehmen will

Are you sure you want to write the partition table to disk? (yes or no):

Um ganz sicher zu gehen, dass man die Änderungen auch wirklich übernehmen will, muss man nun tatsächlich yes eintippen. Ein einfaches Enter, oder nur ein y ist unzureichend!

Wenn soweit alles in Ordnung ist, werden wir nach dem Installationsort für Android gefragt. Viel Auswahl ist nicht, also einfach Enter drücken.

Die Wahl des Filesystem steht auf dem Plan. Wir wählen ext4 aus und drücken Enter.

Natürlich bezweifelt man die Ernsthaftigkeit unseres Vorhabens und fragt sicherheitshalber noch einmal nach, ob wir uns da auch ganz sicher sind. Da wir es sind, alles andere würde schliesslich keinen Sinn ergeben, wählen wir Yes und drücken Enter.

Die Formatierung wurde erfolgreich abgeschlossen, was in aller Regel sehr schnell geht, nun werden wir nach dem Bootloader gefragt. In einer virtuellen Umgebung eigentlich Blödsinn, da ohne Grub überhaupt nichts passieren würde, aber Fragen kostet ja nichts. Höflich wählen wir Yes aus und drücken Enter.

Hier kommt nun eine interessante Geschichte. Grub kann nicht in GPT installiert werden. Interessant deswegen, wenn man weiter oben nicht GPT auswählt, läuft Android nach der Installation nicht. Zumindest war es bei mir in zwei Versuchen so. Offensichtlich muss man tatsächlich erst GPT auswählen und es dann in MBR konvertieren. Warum das so ist, da habe ich keine Ahnung. aber, es funktioniert, die Warnung ignorieren wir, wählen Yes und drücken Enter.

Der Scheideweg. Was will man haben? Will man /system auch beschreiben können, oder reicht das lesen? Prinzipiell soll das jeder für sich entscheiden. Wer ohnehin keine Ahnung hat, was er mit /system anfangen soll, der wählt einfach No. Wer es hingegen weiss, der stellt sich die Frage erst gar nicht.

Ich für meinen Teil wähle immer Yes.

Jetzt gehts rund! Rief der Papagei und flog in den Ventilator!

Android wird installiert. Das kann ein bisschen dauern, erfordert aber kein weiteres Eingreifen.

Sie haben ihr Ziel erreicht!

Wenn man es bis hierhin geschafft hat, ist man tatsächlich am Ziel. Man kann nun wählen, ob man einen Reboot durchführen möchte, aber bei der aktuellen Konfiguration würde man damit wieder in die Live-CD kommen und das wollen wir ja nicht. Also wählen wir Run Android-x86, was sowieso schon angewählt ist und drücken Enter.

Das sieht doch gut aus! Wir bekommen angezeigt, dass Android startet. Kennt man wahrscheinlich vom Handy, oder Tablet, auch wenn dort zumeist andere Boot-Animationen angezeigt werden.

Anmerkung: Es kann sein, dass vor dem Android Zeichen erst noch etwas von der Konsole angezeigt wird. Eine Eingabeaufforderung zum Beispiel. Einfach ignorieren. Das ist kein Fehler und tritt anscheinend immer auf!

Erfolg auf ganzer Linie! Nachdem man Android eingerichtet hat, was jeder, der ein Android-Handy, oder Tablet sein Eigen nennt und auch Leute, die noch nie etwas mit Android zu tun hatten schaffen sollten, kommt man zu dieser Ansicht. Android ist gestartet, der Launcher ist bereit und man kann loslegen, was auch immer man mit Android machen will. Den Hintergrund halte ich dabei für grenz-wertig, aber zum Glück kann man den ja ändern!

Mission erfüllt!

Schritt 5: Nachbearbeitung

Damit sind wir jedoch noch nicht ganz durch. Zwar kann man ab jetzt sein Android starten, mit dem aktuellen Skript bedeutet das jedoch einen Umweg. Mit dem Skript wird immer zuerst die Live-CD gestartet. Im Menü kann man dann zwar dafür sorgen, dass von der Platte gestartet wird, aber der Umweg ist unsinnig. Deshalb ändern wir das Skript etwas ab.

qemu-system-x86_64 -m 2048 -boot d -enable-kvm -smp 3 -net nic -net user -hda images/android.img

Wer die beiden Befehlszeilen vergleicht stellt fest, lediglich der -cdrom Parameter ist rausgeflogen. Den braucht man jetzt nicht mehr. Von nun an startet Android direkt von der Platte und man hat seine Ruhe. Zuerst erscheint dabei übrigens Grub, also der Bootloader. Einfach Enter drücken, oder die Zeit ablaufen lassen. Mehr muss man da nicht machen.

Alternativ kann man das Skript auch einfach kopieren und dieses editieren. So könnte man ein installAndroid.sh und ein startAndroid.sh anlegen. Falls man wieder Android installieren möchte, oder wie auch immer. Der Fantasie sind nur wenige Grenzen gesetzt!

Empfehlenswert ist es in meinen Augen auch, eine Kopie von android.img anzulegen. Möglichst direkt nach dem Einrichten. Auf diese Weise spart man sich neue Installationen! Auch kann man so mehrere Androids parallel betreiben, man muss lediglich das Skript dafür etwas anpassen. Je nachdem, was man damit anstellen will.

Zum Schluss

Während des schreiben dieser Anleitung bin gefragt worden, warum man überhaupt Android in einer virtuellen Umgebung laufen haben will. Man hätte es ja schliesslich Nativ auf dem Handy. 

Die Frage ist gut! Warum man nun ein Android auf dem Computer haben will, sollte jeder für sich entscheiden können. Ich bin auf die Idee gekommen, da Instagram ein wenig zu stur ist. Zwar kann man seinen Account über den Browser erreichen, auch Kommentare schreiben und ähnliches, doch selbst das Posten eines neuen Beitrags ist einem dort untersagt. Einen neuen Post über das Handy erstellen kann aber ein Geduldsspiel sein, da die Bildschirmtastatur ganz gerne mal ein Eigenleben entwickelt und man sich gerne vertippt. Um das zu umgehen habe ich Android jetzt mit qemu laufen, dort Instagram installiert und poste jetzt auf diese Weise, was für mich deutlich angenehmer ist, als vom Handy aus.

Es gibt sicherlich aber noch viele Gründe, warum man gerne ein Android auf dem Rechner hätte. So gehe ich davon aus, wer diese Anleitung hier liest, wird schon einen gefunden haben!

Bis dahin wünsche ich gutes Gelingen und viel Spass mit Android in qemu. Wer ein Kommentar übrig hat, ich nehme es gerne!