• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Erfahrungen mit Oracle Virtualbox

ralli

BSD Fanboy
Themenstarter #1
Ich möchte heute meine Erfahrungen mit Virtualbox mit Euch teilen, und Euch bitten, Eure Erfahrungen auch zu posten. Danke!

Installiert habe ich unter FreeBSD 12 RC3 die folgenden Binary Pakete:

Code:
virtualbox-ose-5.2.18_1
virtualbox-ose-additions-5.2.18_1
virtualbox-ose-kmod-5.2.18_1
Dann habe ich in die /boot/loader.conf eingetragen:

Code:
vboxdrv_load="YES"
und in die /etc/rc.conf:

Code:
vboxnet_enable="YES"
vboxguest_enable="YES"
vboxservice_enable="YES"
Rechner neu gestartet und es kommt im Mate Desktop die Fehlermeldung:

Code:
the virtualbox kernel service is not running
VM Virtualbox startet aber und ich habe erfolgreich ein FreeBSD 11.2 mit dem Mate Desktop virtualisiert. Was mich wundert, das die Grafikauslösung nur 1024x768 beträgt. Gibt es für die Grafikleistung noch eine Lösung? Ich benutze eine AMD SAPPHIRE Radeon R5 230 2 GB (PCI Express).

Ein Q4OS Linux unter Virtualbox läuft sehr viel schneller und mit allen nativen Auflösungen bis zu FULL HD (1920x1080).

Videos mit Youtube und Sound sind schlecht, sehr schlecht.

Hab ich bei der Konfiguration noch Fehler gemacht, oder geht es noch besser?

In den nächsten Tagen werde ich auch noch alternative Virtuallösungen ausprobieren.
 
Gefällt mir: Vril

Andy_m4

Well-Known Member
#2
VM Virtualbox startet aber und ich habe erfolgreich ein FreeBSD 11.2 mit dem Mate Desktop virtualisiert. Was mich wundert, das die Grafikauslösung nur 1024x768 beträgt. Gibt es für die Grafikleistung noch eine Lösung?
Hast Du auch die Gasterweiterung auf dem Gastsystem installiert?

Hab ich bei der Konfiguration noch Fehler gemacht, oder geht es noch besser?
Ich nehme an, Du hast Dich an die Vorgaben des Handbuches gehalten?
https://www.freebsd.org/doc/de/books/handbook/virtualization.html

In den nächsten Tagen werde ich auch noch alternative Virtuallösungen ausprobieren.
Die native Virtualisierungslösung unter FreeBSD ist bhyve. Ebenfalls im Handbuch beschrieben:
https://www.freebsd.org/doc/de/books/handbook/virtualization-host-bhyve.html
 

ralli

BSD Fanboy
Themenstarter #4
Hast Du auch die Gasterweiterung auf dem Gastsystem installiert?
Ja, habe ich doch oben gepostet.;)

Ich nehme an, Du hast Dich an die Vorgaben des Handbuches gehalten?
Ja, das geht auch aus meinem Posting hervor.

Die native Virtualisierungslösung unter FreeBSD ist bhyve. Ebenfalls im Handbuch beschrieben:
Das werde ich mir jetzt vorknöpfen. Arbeitet hier jemand erfolgreich mit der Virtualisierungslösung bhyve?

Und zum Schluß,ja ich lese immer vorher das Handbuch, bevor ich mich ans Forum wende. Das sollte doch eine Selbstverständlichkeit sein. Aber wenn ich alles richtig gemacht habe und mich an das Handbuch gehalten habe, und diese Fehlermeldung kommt, dann bin ich auch ratlos.

Es wäre schön, wenn mir jemand aus unserer Community bestätigen würde, das bei der Auflösung 1024x768 definitiv Schluß ist. Dann weiß ich Bescheid. Ansonsten läuft FreeBSD mit dem Mate Desktop ganz passabel, bis eben das Videos ruckeln und dadurch auch der Sound nicht mitkommt. Das ist aber bei OpenBSD, das ich auch bereits virtualisert habe, ebenso, gar noch schlechter.
 

Andy_m4

Well-Known Member
#6
Ja, habe ich doch oben gepostet.;)
Nein. Hast Du nicht.
Gasterweiterungen gehören aufs Gastsystem.

Ja, das geht auch aus meinem Posting hervor.
Nein. geht es nicht.
Das fängt schon mal damit an, dass Du Deine Konfiguration nicht sauber getrennt nach Host und Gast gepostet hast. Das lässt den Schluss zu, dass Du eben alles nur auf dem Host (oder Gast) gemacht hast.

Im Handbuch werden die Sachen fein säuberlich nach Host und Gast getrennt aufgeführt.

Es wäre schön, wenn mir jemand aus unserer Community bestätigen würde, das bei der Auflösung 1024x768 definitiv Schluß ist.
Nein. Ist es nicht. Im Prinzip gibts keine größtmögliche Auflösung. Die Begrenzung liegt viel mehr darin, wie viel virtuellen Videospeicher man dem Gast zuweist. In der Standardeinstellung ist das aber i.d.R. mehr als üppig.
Wenn die Gasterweiterungen korrekt installiert sind, kannst Du auch das Fenster frei größer/kleiner ziehen.
 

Andy_m4

Well-Known Member
#7
Nachtrag:
Egal ob Du die Ports oder die Packages nimmst:
VirtualBox auf dem Host und virtualbox-ose-additions auf dem Gast sollten die gleiche Version haben.

VirtualBox aus den Ports kannst Du bedenkenlos nehmen. Ich hatte es dieser Tage mal getestet und es lief soweit gut.
 

Andy_m4

Well-Known Member
#8
Arbeitet hier jemand erfolgreich mit der Virtualisierungslösung bhyve?
Byhve performt gut. Die Videoausgabe könnte aber eine Schwachstelle sein. Das fängt schon damit an, dass die Ausgabe nicht wie bei VirtualBox direkt in ein Fenster passiert, sondern Du Dich via VNC mit der virtuellen Maschine verbinden musst.
Ich habs zwar noch nicht mit Videoausgaben etc. getestet, aber ich blicke aufgrund dessen nicht gerade positiv in diese Richtung.
 

medV2

Well-Known Member
#9
Vorweg, alle meine Erfahrungen mit VirtualBox beziehen sich auf Linux (Fedora/RedHat). Allerdings bezweifle ich stark, dass es auf FreeBSD besser läuft.

Vorweg der Desktopeinsatz: Zum virtualisieren eines Gastsystems auf dem Desktop tut es seine Sache. Später war mir KVM zwar immer lieber da performanter aber für ne Testmaschine oder ähnliches hats immer gelangt und es gab keine großen Ausfälle.

Server: Irgendwann wollte ich es leider mal ausprobieren.. Schlimm, schlimm, schlimm.
Ich hatte 5VMs von KVM auf VirtualBox gestellt, der rest lief normal unter KVM. Auf dem Server eine mitlere Last von 30-40%.
In den VMs hatte ich katastrophale IO Zeiten, unter Last (in den VMs) waren die VMs teilweise fast eine Minute nicht erreichbar. Auch eine Bevorzugung der VirtualBox VMs gegenüber KVM (mittels CGroups) brachte da keine Besserung. Alls in allem lief es sehr Instabil, sowohl was Netzwerk als auch was IO betraf. Alle VMs hatten Linux als Gastsystem.
Auch "kann" VBox nunmal sehr wenig im vergleich zu KVM, Bhyve ist leider auch noch nicht wirklich als Virtualisierungslösung im größeren Umfeld geeignet.

Der Fairness halber muss ich aber sagen, das ganze ist auch schon ca. 3 Jahre her.
 

Andy_m4

Well-Known Member
#10
In den VMs hatte ich katastrophale IO Zeiten, unter Last (in den VMs) waren die VMs teilweise fast eine Minute nicht erreichbar.
Ich würde spontan sagen, dass zwei zeitgleich eingesetzte Hypervisoren nicht die beste Idee sind. Das mag kein Hypervisor wirklich.

Auch "kann" VBox nunmal sehr wenig im vergleich zu KVM
Ohne zu sagen _was_genau_ damit gemeint ist, iist das eine ziemlich wertlose Aussage.

Bhyve ist leider auch noch nicht wirklich als Virtualisierungslösung im größeren Umfeld geeignet.
Weil ... ?
 

datasmurf

Happy FreeBSD User
#11
Bisher habe ich gute Erfahrung mit sysutils/cbsd gemacht. Es ist wirklich einfach VM's oder Jails zu erstellen.

Code:
cbsd bconstruct-tui
2018-12-07-184122_623x660_scrot.png


Wie Du siehst ist es recht einfach, via Text UI ( dialog(1) ) eine VM zu erstellen. CBSD kann auch beim ersten Start der VM das benötigte ISO herunterladen. Spart man sich auch diesen Schritt.

Für mich eindeutig der Favorit, Platz 2. sysutils/vm-bhyve da ich mit CBSD keine nicht UEFI VM booten kann. Die Ünterstützung wurde mit Release 11.1.17 entfernt. Brauchte es aber da ich für Kunden Linux 2.6.32-3 / Distro: Ubunut 10.04.4 LTS für MySQL 4.1 Backend für Warenwirtschaftssoftware weiter betreiben muss. vm-bhyve ist schon ein wenig kniffliger im Vergleich zu CBSD.
 

medV2

Well-Known Member
#12
ad1: Weil..?

ad2:

Automatisierte Deployments, live Migration, Acounting, vielfalt bei den Storageinterfaces (iSCSI, SANs), Monitoring, vernünftige Backups zur Laufzeit (je nach Storagebackend), Performance an sich, insb. Netzwerk und Storage. Zu guterletzt spielt es automatisch gut mit Linuxfunktionen wie tuningd oder den cgroups zusammen. Einiges natürlich im Zusammenspiel mit libvirt, aber ich denke niemand der von "kvm" spricht meint nur das Kernelmodul sondern den ganzen Stack.

ad3: siehe 2
 

pit234a

Well-Known Member
#13
VirtualBox aus den Ports kannst Du bedenkenlos nehmen.
auf "latest" liegt die gleiche Version binär (5.2.22 r126257) und arbeitet bei mir problemlos. Passende Gasterweiterungen für meine wichtigsten Systeme gibt es dafür auch.

virtualbox-ose, früher virtualbox und von mir im weiteren Beitrag als VB abgekürzt, war die erste Virtualisierungs-SW, die ich benutzte und deshalb gibt es da natürlich einen gewissen Gewöhnungs-Effekt. Im Laufe der Zeit hatte ich unterschiedliche Einsatzzwecke probiert und inzwischen nutze ich das nur noch Ersatz für HW-PCs mit einigen bestimmten Systemen, die ich gelegentlich mal brauche und dann direkt aus meinem FreeBSD starten kann.
Meine virtuellen Gäste laufen also nicht dauernd, ja, sie laufen selten länger als einige Stunden.
Mein Host hat zwei Monitore und ich lege dann immer das virtuelle System auf einen Monitor fest und nutze dort die gesamte Auflösung. Viele wichtige Dinge erledige ich noch immer direkt auf dem Host und arbeite manchmal auch gleichzeitig mit Gast und Host am gleichen Problem, sprich, an den gleichen Dateien. Dazu benutze ich hauptsächlich meinen FreeBSD-NAS als Austauschsystem. Austauschordner auf dem dem Host sind mir nicht so wirklich sympathisch und Sticks sind langsam.
Die Gäste sind aber auf bidirektionalen Austausch mit dem Host eingestellt, wobei ich vor allem die Zwischenablage gerne nutze.

Was mir von Anfang gut gefiel, war die GUI, die es für VB gibt. Es gibt mehrere, aber die direkt ausgelieferte fand ich immer sehr ansprechend und intuitiv. Das ist wichtig für mich, weil ich dann bei den sehr seltenen Fällen, wo ich einen neuen Gast aufsetzen will, nicht erst die Dokumentation lesen muss.
Inzwischen kann VB auch eine Menge an virtuellen Medien. Ich kann quasi meine VB-VHD kopieren und jemandem mitgeben, der sie dann in seinem Virtualisierungssystem benutzen kann, aber wichtiger: ich kann dies und die komplette Maschine kopieren und jemandem mitgeben, der sie dann in seinem eigenen VB benutzen kann und das für unterschiedliche Systeme!
Ich selbst nutze das und habe (teilweise unterschiedliche Versionen) von VB auf GNU/Linux und OS-X installiert, auf denen ich jeweils gleiche Maschinen laufen habe (manche Systeme sind kritisch, wenn sie auf veränderter HW laufen sollen) und gelegentlich synce ich dann die benutzten VHDs. Somit habe ich an unterschiedlichen Orten und auf unterschiedlichen Systemen sehr einfachen Zugang zu meinen Gästen.
In der GUI ist es auch realisiert, am Host angeschlossene Geräte zum Gast durch zu reichen. Das ist ebenfalls sehr intuitiv gemacht. Ein Bekannter braucht das etwa, um einen Scanner aus seinem GNU/Linux zu benutzen, der nur von einem Windows unterstützt wird. Er startet also sein VB mit dem veralteten Windows als Gast, das er früher tatsächlich als System auf seinem PC benutzt hatte, reicht den Scanner am USB-Port in den Gast durch und kann dort scannen und die Ergebnisse ansehen und auf einem Austauschordner speichern. Das geht sehr bequem, also bequem genug, dass man nicht unbedingt neue HW kaufen muss und einfach in einem Fenster des Hosts.
Auch die Einrichtung neuer Maschinen gelingt sehr einfach über diese GUI. So kann ch schnell mal eine anlegen, um etwa ein ISO eines Live-Systems laufen zu lassen, ich kann schnell mal ein System zur Probe installieren (auch ohne Gasterweiterungen) mal ansehen oder ich kann sehr einfachund schnell die Bootreihenfolge bei einem bestehenden Gast verändern und habe so vielfältige Möglichkeiten zur Manipulation, etwa, zum Erstellen eines Images, das ich dann auf echter HW restaurieren könnte.
Ohne erst Dokumentation zu lesen konnte sehr schnell einige Maschinen etwa mit einem FreeBSD bestücken und dann Datenaustausch unter diesen beobachten. Alles in ein Netz gepackt, tcpdump auf einer laufen und dann mal Daten über diverse Programm hin und her gesendet. Wenn ich etwa einen Mailserver aufsetzen müsste, würde ich mir das in der Art erst mal ansehen und kann mich dann ganz auf mein eigentliches Problem konzentrieren, wie die Administration der Gäste so gut wie selbsterklärend ist.

Also, wegen der Verfügbarkeit für viele Systeme und wegen der einfachen Bedienung über die GUI, bin ich nach wie vor bei VB und damit nicht unglücklich.

Immer wieder gibt es natürlich wirklich böse Überraschungen und gerade, weil es meist so gut geht, machte ich mir definitiv zu wenig Gedanken, über die Absicherung meiner Gäste. Das habe ich nun geändert, nachdem vor kurzem der Update auf eine VB-Version dazu führte, dass alle meine Gäste erst mal zerstört waren und ich sehr sehr lange brauchte, um die wichtigsten wieder zu beleben.
Schuld war nicht nur der Update und eine unpassende Gast-Erweiterung, sondern auch mein fahrlässiges Verhalten.
Ein System auf einem PC braucht einfache Aufmerksamkeit hinsichtlich Backup-Strategien, ein System in VB braucht doppelte Aufmerksamkeit, denn es geht um den Gast und um VB selbst.

Seit einiger Zeit gibt es im Reiter "Massenspeicher" zu einer Maschine den Punkt "Host I/O-cache verwenden" und zumindest bei SATA und SD auf dem Host kann ich das nur empfehlen!
 

ralli

BSD Fanboy
Themenstarter #14
Nein. Hast Du nicht.
Gasterweiterungen gehören aufs Gastsystem.
Danke Andy, da habe ich tatsächlich Mist gebaut und was durcheinander gebracht. Hab es bereits korrigiert.:)

Jetzt habe ich auch Auflösungen bis 2560x1600 bezw. 2560x1440. Es läuft alles wunderbar, aber Videos ruckeln immer noch ... Gut, das ist jetzt nicht so wichtig. Aber um mal schnell was auszuprobieren ist es durchaus praktikabel.
 

ralli

BSD Fanboy
Themenstarter #16
Byhve performt gut. Die Videoausgabe könnte aber eine Schwachstelle sein. Das fängt schon damit an, dass die Ausgabe nicht wie bei VirtualBox direkt in ein Fenster passiert, sondern Du Dich via VNC mit der virtuellen Maschine verbinden musst.
Ich habs zwar noch nicht mit Videoausgaben etc. getestet, aber ich blicke aufgrund dessen nicht gerade positiv in diese Richtung.
Das werde ich unbedingt auch noch antesten und dann vergleichen.
 

ralli

BSD Fanboy
Themenstarter #17
Also, wegen der Verfügbarkeit für viele Systeme und wegen der einfachen Bedienung über die GUI, bin ich nach wie vor bei VB und damit nicht unglücklich.
So sehe ich das auch. Dennoch werde ich auch mal Alternativen ausprobieren, um mir ein Gesammtbild zu machen. Das erweitert doch den Erfahrungshorizont.:)
 

Andy_m4

Well-Known Member
#18
Im Prinzip aus dem gleichen Grund, warum man keine zwei Kernel parallel betreiben kann, weil die sich halt gegenseitig behindern. Sie greifen auf die gleichen Ressourcen zu.

aber ich denke niemand der von "kvm" spricht meint nur das Kernelmodul sondern den ganzen Stack.
Und wenn das so ist, warum vergleichst Du dann diesen ganzen Stack mit bhyve?

Bisher habe ich gute Erfahrung mit sysutils/cbsd gemacht.
Guter Tipp.

von mir im weiteren Beitrag als VB abgekürzt
*lol*
Aber gut zu wissen. :-)

Inzwischen kann VB auch eine Menge an virtuellen Medien. Ich kann quasi meine VB-VHD kopieren und jemandem mitgeben, der sie dann in seinem Virtualisierungssystem benutzen kann, aber wichtiger: ich kann dies und die komplette Maschine kopieren und jemandem mitgeben, der sie dann in seinem eigenen VB benutzen kann und das für unterschiedliche Systeme!
Ergänzend kann man noch sagen, dass es auch eine offizielle Export/Import Funktion gibt.

Seit einiger Zeit gibt es im Reiter "Massenspeicher" zu einer Maschine den Punkt "Host I/O-cache verwenden" und zumindest bei SATA und SD auf dem Host kann ich das nur empfehlen!
Ja. Das bringt spürbar Geschwindigkeit.
 

ralli

BSD Fanboy
Themenstarter #19
Seit einiger Zeit gibt es im Reiter "Massenspeicher" zu einer Maschine den Punkt "Host I/O-cache verwenden" und zumindest bei SATA und SD auf dem Host kann ich das nur empfehlen!
Und ich möchte noch ergänzend hinzufügen, das das nicht extra aktiviert werden mußte bei mir, sondern automatisch richtig eingestellt war.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#20
Ich muss dann wohl doch noch was zu Bhyve sagen:

Erstmal muss man den Anspruch des Projekts sehen. Bhyve hatte nie als Ziel eine Full-Stack Virtualisierungslösung zu werden. Denn als Bhyve begonnen wurde, waren VMware ESX, Hyper-V, KVM und XenServer schon viele Jahre auf dem Markt. Dort nennenswerte Marktanteile zu gewinnen war realistisch gesehen absolut aussichtslos und das nicht nur aus technischen Gründen. Dazu kam das Manpower-Problem, Virtualisierung ist ein komplexes Thema und um auch nur in die Nähe der Möglichkeiten etablierter Lösungen zu kommen hätte es zehntausende Mannstunden gebraucht. Wo hätten die herkommen sollen?

Bhyve war zu Beginn als eine schlanke Lösung, die dem Unix-Prinzip folgend gerade genug bereit stellte, um FreeBSD selbst zu virtualisieren, konzipiert. Darauf baute man dann auf, erst andere unixoide Systeme wie OpenBSD und natürlich Linux, später dann schon unter deutlichem Entwicklungsaufwand auch Windows. Es kam die Möglichkeit per UEFI zu booten, es kam die Integration in libvirt und schließlich, allerdings mehr als Spielzeug zu betrachten, sogar in OpenStack.

Inzwischen ist Bhyve die mit Abstand beste Lösung, wen man unter FreeBSD ein paar virtuelle Maschinen ausführen will. Es integriert sehr gut ins Hostsystem, alleine das Zusammenspiel mit ZFS ist jedes Mal wieder eine große Freunde. Aber auch in die Bereiche, die man nicht so sieht. Virtuelle Speicherverwaltung, Scheduler, etc. Ich hab hier in meiner Produktion inzwischen eine ganze Reihe Bhyve-VMs laufen, von FreeBSD, über verschiedene Linuxe bis hin zu Windows. Und es funktioniert absolut einwandfrei, besser als VirtualBox es jemals tat. Bhyve ist aber ungeeignet, wenn es darum geht eine komplette virtuelle Infrastruktur aufzuziehen. da gibt es einfach bessere Möglichkeit und die sollte man dann auch nehmen. Die Sache mit dem richtigen Werkzeug für den Job.

Der große Schwachpunkt von Bhyve ist I/O. Es ist meiner Erfahrung nach schneller als unter VirtualBox, aber deutlich langsamer als unter den meisten Konkurrenten. Auf der Speichermedienseite hat sich mit 12.0 nun einiges getan, ich hatte aber noch keine Zeit es zu testen. virtio-scsi wird nun unterstützt, damit kann man unter anderem jedes CAM-Device (auch iSCSI) durchreichen. Dazu gibt es eine NVMe-Emulation. In 13-CURRENT wird gerade an der Netmap-Integration gearbeitet, die das Netzwerk beschleunigen sollte. Da gibt es also zumindest Fortschritte.

Es arbeitet auch schon seit längerer Zeit jemand an Live-Migration. Darauf, dass die Arbeit zeitnah oder vielleicht überhaupt jemals seinen Weg in FreeBSD findet, würde ich aber nicht hoffen. Das Thema ist sehr komplex, zu komplex für einen einzigen Freizeitentwickler und tatsächlich scheint das Interesse der Community da auch eher gering zu sein. Es gibt auch Patches für Intel HDA Emulation, die weitgehend fertig sind und vielleicht sogar demnächst eingehen könnten.
 

ralli

BSD Fanboy
Themenstarter #23
Ich bin gerade dabei, bhyve auszuprobieren. Jetzt sollte ich, wie in unserem Handbuch beschrieben, ein tap Gerät erzeugen. Dort ist ja nur ein Beispiel beschrieben. Wie finde ich heraus, was ich für eine physikalische Schnittstelle benötige?
 

Andy_m4

Well-Known Member
#24
Mit ifconfig kannst Du Dir alle physikalischen Schnittstellen ausgeben lassen.

Dann spendier Ihm doch mal ein Gefällt mir ..... unten rechts, das ist auch ein Zeichen von Wertschätzung.:)
Damit komme ich irgendwie nicht zurecht.
Erst mal weil nicht differenziert wird, wie gut man ein Posting findet. Und zweitens weil man nicht deutlich machen kann auf welchen Abschnitt sich das bezieht. Nicht immer stimmt man ja mit dem gesamten Posting überein.
 

Vril

Well-Known Member
#25
Ich bin gerade dabei, bhyve auszuprobieren. Jetzt sollte ich, wie in unserem Handbuch beschrieben, ein tap Gerät erzeugen. Dort ist ja nur ein Beispiel beschrieben. Wie finde ich heraus, was ich für eine physikalische Schnittstelle benötige?
wie Andy_m4 schon schrieb, Du schaust zuerst wie mit ifconfig wie Deine Netzwerkschnittstelle heisst.
Dann .. wie im Handbuch (Zitat aus FreeBSD Manual):

"...
Erstellen Sie ein tap-Gerät, um dieses mit der Netzwerk-Schnittstelle der virtuellen Maschine zu verbinden. Damit sich die Schnittstelle mit dem Netzwerk verbinden kann, müssen Sie zusätzlich eine Bridge-Schnittstelle erzeugen, bestehend aus dem tap-Gerät und der physikalischen Schnittstelle. In diesem Beispiel wird die physikalische Schnittstelle igb0 verwendet:

# ifconfig tap0 create
# sysctl net.link.tap.up_on_open=1
net.link.tap.up_on_open: 0 -> 1
# ifconfig bridge0 create
# ifconfig bridge0 addm igb0 addm tap0
# ifconfig bridge0 up
..."
Und Du tippst es genauso wie hier ... und ersetzt einfach igb0 mit Deiner eth0 ..oder wie auch immer die heisst.

Im Prinzip erstellst Du hier nur eine virtuelle "Netzwerkkarte" und via bridging verbindest Du die mit Deiner physischen Karte