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!
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.
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:
Man spricht ein Machtwort, erstellt einen Nutzungsplan und jeder steht unter Zeitdruck. Nicht schön, aber könnte funktionieren.
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.
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:
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!
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!
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!
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!
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!
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!
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!
In Version 0.2 erfasst der Arduino Nano mittels zwei DS18B20 die Innen- und Aussentemperatur und speichert die Daten auf die SD-Karte. Da noch keine RTC verbaut ist, erscheint bei Uhrzeit und Datum natürlich immer der selbe Wert, was ohne eine entsprechende RTC kaum zu ändern ist.
Der Arduino wartet auf Eingabe über die serielle Schnittstelle. Ausgegeben können die Informationen der SD-Karte inklusive deren Grösse und wie viel Speicherplatz noch frei ist, die aktuellen Daten und alle gespeicherten Daten. Ausserdem kann der Arduino auf Kommando auch die Speicherkarte wieder löschen, was in der Backup-Funktion zum Einsatz kommen soll.
Kommunikation zwischen Arduino und Raspberry übernimmt die Server-Software der Wetterstation, welche rein über die Kommandozeile läuft. Geschrieben wird der Server in C/C++ mit Visual-Studio-Code unter Verwendung von cmake. Der Einfachheit halber bekommen alle Komponenten immer die gleiche Versionsnummer.
Der Server baut dabei einen Socket auf und wartet auf Anfragen. Diese können von verschiedenen Anwendungen kommen und spezifisch auf verschiedene Gebiete ausgelegt sein. Beispielsweise dem Erzeugen eines Widgets, wobei kein GUI notwendig ist und nur die aktuellen Daten abgefragt werden.
Die vollständige Client-Software kann sämtliche Informationen der Wetterstation abrufen. Von der SD-Karte, die aktuelle Werte, wie auch alle gespeicherten Werte. Es wird angezeigt, wie viel Speicherplatz noch auf der Karte ist, die Karte kann gelöscht und es kann ein Backup erstellt werden. Beim Backup werden alle Daten von der Wetterstation auf den Computer übertragen und in einer Datei gespeichert. Ist die Datei bereits vorhanden, so werden die neuen Daten angehängt, um ein vollständiges Bild seit Beginn der Aufzeichnung zu bekommen. Im Anschluss wird die Speicherkarte gelöscht, um die Zeit der Übertragung zu verkürzen.
Auch der Client wird in C/C++ mit Visual-Studio-Code geschrieben und verwendet zum Erzeugen des GUI die Bibliothek Nana.
Aktueller Stand (03.12.2018):
Schaltung aufgebaut und getestet
Die Firmware des Arduino verfügt über alle geforderten Funktionen
Der Server kann alle Daten der SD-Karte auslesen und übertragen
Der Server kann die Temperaturen abrufen und übertragen
Der Server speichert die Temperaturen mit falscher Uhrzeit und Datum
Der Server kann alle Daten der SD-Karte übertragen
Der Server kann die Speicherkarte löschen
Die GUI des Client ist fertiggestellt.
Der Client kann die Informationen der Speicherkarte abrufen und anzeigen.
ToDo:
Abrufen und anzeigen aller gespeicherten Daten
Aktualisierung der SD-Karten-Informationen
Löschen der SD-Karte
Backup
Bekannte Bugs:
Gelegentliche Abstürze beim Start, die auch den Server zum Absturz bringen
Beim Abrufen der aktuellen Daten besteht die erste Übermittlung immer in der Ausgabe der SD-Karten-Informationen
Auch heute haben wir wieder Wetter, Wetter, Wetter! Wir haben unglaublich viel Grad. Da 30, dort 60 und da drüber 90 Grad. Ach nein, dass waren ja Winkel!
Spass beiseite! Irgendwie, wenn es um Arduino und Co geht, dann ist da immer irgendwo eine Wetterstation dabei. Dem will ich mich natürlich nicht entziehen! Allerdings will ich es dabei auch ein bisschen übertreibe!
Zielsetzung:
Erfassen der Aussentemperatur
Erfassen der Innentemperatur
Erfassen der Luftfeuchtigkeit
Erfassen der Witterung (Regen, oder kein Regen)
Speichern aller Daten auf eine 2GB SD-Karte (die sollte eine Zeit halten)
Kommunikation zwischen Arduino und einem Raspberry Pi mittels des USB-Port
Bereitstellung eines Servers auf dem Raspberry Pi
Client-Software zum Abrufen der Daten. Aktuelle Daten, alle gespeicherten Daten, Backup, SD-Karten-Informationen
Ausgabe der aktuellen Wetterinformationen auf einem OLED Display
Warum gleich so viel? Nun, warum nicht? Wenn, dann richtig, oder?
Im Prinzip soll die Wetterstation dazu dienen, die Wetterdaten zu sammeln. Der Arduino soll autonom laufen, also nicht auf den Strom vom Raspberry angewiesen sein, damit der Raspberry auch neugestartet und daran gearbeitet werden kann. Der Raspberry dient dabei als Ausgabe und Server gleichzeitig. Dadurch soll bewerkstelligt werden, dass an anderen Computern im Netzwerk die aktuellen Wetterdaten abgerufen und ausgewertet werden können. Beispielsweise ist auf diese Weise ein Widget mit echten Daten vor Ort denkbar.
