Von Daniel Baumann am Di, 6. Februar 2007 um 15:13 #
Ob das neue kqemu in Etch kommt, ist noch haengig[0]. Falls es nicht rein kommt, werde ich einen Backport fuer Etch auf backports.org hochladen, sobald dass da die etch-backports suite eingerichtet wurde.
In der Zwischenzeit kannst du das regulaere Paket[1] verwenden, es laeuft ohne Aenderung auch auf Sid und Etch.
Ubuntu musst du selber schauen, das interessiert mich nicht[2].
Vielen Dank für die Info. Hoffentlich schafft es das Paket noch in etch, wenn nicht, dann werde ich das reguläre Paket verwenden, danke für den Tipp + die Links.
Von Daniel Baumann am Di, 6. Februar 2007 um 15:49 #
Ohne kqemu ist qemu Groessenordnung 1/10 so schnell wie das Hostsystem. Mit kqemu ist qemu in den meisten Situationen fast gleichschnell oder nur minimal langsamer als das Hostsystem.
Gilt das auch beim Emulieren fremder CPUs (bspw. PowerPC-Emu auf x86-Host-System)? (Abgesehen davon, dass es da generell schwierig werden dürfte, einen 100%-Indexwert festzulegen, vermute ich.)
bezieht sich das i386 bzw. amd64 eigentlich auf den prozessor oder das OS?
wenn ich eine amd64 cpu habe, dann kann ich darauf ja auch ein 32bit OS verwenden. ist es dann aber möglich auf einem 32bit host (welches auf einer 64bit cpu läuft) auch ein 64bit gast OS zu verwenden? wie sieht es umgekehrt aus, also kann ich auf einem 64bit host einen 32bit gast laufen lassen?
Von Daniel Baumann am Di, 6. Februar 2007 um 18:36 #
bezieht sich das i386 bzw. amd64 eigentlich auf den prozessor oder das OS?
auf die Debian Plattform.
Wenn du qemu als amd64 Binary auf amd64 Debian ausfuehrst, gehen 64bit und 32bit Betriebssysteme. Wenn du qemu als i386 Binary auf amd64 Debian oder i386 Debian ausfuehrst, gehen nur 32bit Betriebssysteme.
Damit zusaetzlich auch kqemu geht, muss Host und Guest Plattform aber identisch sein.
Von Crazy Pinguin am Di, 6. Februar 2007 um 17:07 #
Na ja, gleich schnell ist ein wenig übertrieben, nur reine CPU Benchmarks sind schnell, alles andere hinkt nativ hinterher. Netzwerk oder Festplatten Zugriffe sind z.B. um ein vielfaches langsamer als nativ insgesamt fühlen sich virtuelle Maschinen (Linux, Windows) 2 bis 3 mal langsamer an als nativ. Ein gecracktes OSX für VMware das ebenfalls in Qemu startet (tiger-flat-x86.img aka deadmoo Image) lief bei mir sogar 5 mal langsamer als nativ (gemessen mit Xbench). Empfehlen würde Kqemu & Kemu trotzdem, VMware oder Parallels sind auch nicht viel schneller.
Von Anonyme Maus am Di, 6. Februar 2007 um 14:14 #
Möglicherweise ein Grund für diesen Schritt. Jedenfalls erscheint einige, auch Open Source, Software die kqemu zu nichts mehr besonderen macht.
Z.B. auch die Kernel-Based-Virtual-Machine (KVM) die ja in 2.6.20 ist und auch eine angepasste QEmu Version nutzt. Sicher eine, vermutlich noch leistungsfähigere, Alternativlösung zu kqemu. Mehr dazu auch da:
> Jedenfalls erscheint einige, auch Open Source, Software die kqemu zu nichts mehr besonderen macht. Qemu hat allerdings etwas das andere Emulatoren/Virtualisierer nicht haben: Es emuliert ganze Systeme.
So kann ich auf einem x86er ausprobieren wie ein Programm auf einem Sparc, Arm oder PowerPC System funktioniert.
Damit ist es jetzt vielleicht nicht so interessant für jemanden, der produktiv irgendeine Software drauf laufen lassen möchte, aber dafür für jemanden der sich für systemnahe Programmierung dieser Architekturen interessiert bzw. sich da einarbeiten möchte ohne gleich Hardware kaufen zu müssen.
Von Stefan Becker am Mi, 7. Februar 2007 um 07:55 #
Ergänzung zu KVM: Man braucht einen recht aktuellen Prozessor mit Virtualisierungserweiterung (VT, Pacifica).
Weil Qemu basierend, kann man vorhandene Qemu Images, Kommandozeilen (bis auf (KQEMU-Parameter) und Netzwerkeinrichtungen 1:1 weiterverwenden.
Wenn man so einen Prozessor hat, ist es wirklich eine nette Lösung. Die GUI bzw. der Gast fühlt sich noch etwas flüssiger an. Aktuelle wird wohl eine Netzwerkemulation für KVM im Gigabitbereich entwickelt, so dass auch das Problem mit dem langsamen Netzwerk wegfallen würde.
Gibt es eigentlich schon ein gutes grafisches Konfigurationsprogramm zum Konfigurieren der QEMU Umgebung?
So etwas suche ich nämlich zur Zeit, ich bin nämlich zu Faul geworden, dauernd die Dokumentation zu lesen, nur um zu sagen, daß ich nen PC mit VGA Grafikkarte emulieren will und wo sich die Image Datei mit dem zu ladenden Festplattenimage befindet.
Läuft wunderbar. Kann man sogar ganz bequem per Java Webstart installieren, nur leider ist es dort nur die ältere Version. Ich habe es also manuel installiert, um die neuste Version mit einigen wichtigen Features mehr zu haben.
Wann kann man in QEMU einfache Verzeichnisse des Wirstsystem einer Festplatte zuweisen und in der Emulationsumgebung nutzen?
BSP: Ich habe ein OS als image datei. Z.b. linux.image Von diesem wird gebootet, in dem man es der Festplatte hda zuweist und qemu startet. Nun möchte ich noch das Verzeichnis /temp der Festplatte hdb zuweisen, so daß ich im Gastsystem auf dieses Verzeichnis mit schreib und leserechten zugreifen kann. Wann bzw. wie geht das in qem?
Von Crazy Pinguin am Di, 6. Februar 2007 um 17:18 #
Qemu kann eine virtuelle FAT Festplatte für das Guest OS erstellen aus einem Ordner in deinem Host OS, ich glaube das ist was du suchst: http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC24
QEMU hat angeblich so eine Art SMB-Server eingebaut (habe ich aber bei meinem letzten Versuch vor einiger Zeit nicht zum Laufen bringen können).
Alternativ (falls man auf die Dateien im Image nur zugreifen muss, wenn QEMU nicht läuft), kann man ein HDD-Image auch unter Linux als Loopback-Device mounten:
mount -o loop,offset=32256 hdc.img /tmp/hdc/
(Der Offset sorgt dafür, dass im Festplatten-Komplettimage "hdc.img" die erste Partition gemountet wird.)
Vor dem Starten von QEMU ist u.a. wegen Problemen mit Write-Caching (durch Linux und/oder QEMU) das unmounten der Image-Partition zu empfehlen.
Kann man eigentlich mit Qemu von mit raread.exe oder dd erstellte Bootdiskettenimagedateien mit beliebiger Partitionierung booten, oder werden nur reine, mit FAT formatierte, Disketten unterstützt?
Bei mir scheint das nämlich irgendwie nicht zu funktionieren. Ich habe von einem alten Spiel auf 5.25" Disketten, in welches man direkt reinbooten muß (es ist also kein DOS Spiel) eine RAW Image Datei erstellt, aber qemu kann davon nicht booten. Muß man da irgendeinen extra Parameter angeben?
Und ist es egal mit welchem Progamm die RAW Image Datei erstellt worden ist?
Von Crazy Pinguin am Di, 6. Februar 2007 um 17:14 #
Normalerweise geht das problemlos, wenn ich ein Floppy Image mache: dd if=/dev/fd0 of=/tmp/floppy.img dann sollte das Image auch in Qemu booten: qemu -fda /tmp/floppy.img -localtime -boot a Ich kenn mich mit alten Games und deren Kopierschutz nicht aus, das könnte evtl. eine mögliche Fehlerquelle sein.
Von Crazy Pinguin am Di, 6. Februar 2007 um 19:26 #
Bei mir funzt es, ich habs probiert mit Qemu 0.9.0. Ich hab das fertige FreeDos Festplatten Image von der Qemu Download Seite als OS benutzt und nach /tmp entpackt. -Eine leere Floppy erstellt mit: dd if=/dev/zero of=/tmp/floppy.img bs=1024 count=1400 - Qemu gestartet mit: /qemu -hda /tmp/freedos.img -fda /tmp/floppy.img -localtime -boot c Danach format a: eingegeben und es funzt sofort. Der Beweis: http://img253.imageshack.us/img253/5510/bildschirmfotoqemuts6.png
Jetzt funktioniert es und ich habe auch gleich einen Bug in qemu gefunden.
Und zwar habe ich vorher die floppy nach fdb gemountet, weil die FreeDOS CD sich ein eigenes Laufwerk auf A: anlegt, daher dachte ich, ich müßte für das Disk Image B: also fdb nehmen.
Jetzt habe ich fdb nach fda geändert und darauf die image Datei gemountet. Aber wenn ich dann qemu mit freedos starte, dann legt freedos sein zeug wieder auf A: an und verschiebt die Image Diskette nach B:
Die liegt also in B: obwohl nach fda gemountet wurde. Und hier funktioniert das formatieren dann.
Schöner Mist. Und das DOS programm mit dem ich die die Imaga Floppy beschreiben will erwartet die Daten wieder auf A: und weigert sich B: zu nehmen.
Ich denke ich werde freedos auf ein hd image installieren müssen um es dann noch einmal zu probieren. Und wenn es dann auch nicht geht, dann muß ich wohl bochs verwenden, vielleicht ist das ausgereifter als qemu.
Von Crazy Pinguin am Di, 6. Februar 2007 um 20:32 #
Nimm doch einfach das fertige freeDOS Image, das ist einfacher, oder installier es dir selbst auf eine virtuelle Platte (bei FreeDos geht das flott). Die CD die du benutzt ist warscheinlich ein Floppy image auf CD gebrannt (ging mit MSDOS auch) und meldet sich als A: an. Das bringt Qemu warscheinlich total durcheinander. Wenn ich bei DOS eine ide0 master Festplatte einhänge die nicht formatiert ist und eine formatierte ide0 slave einhänge, dann ist die ide0 slave automatisch C: solange bis ich ide0 master formatiere und reboote. Erst dann stimmt die Laufwerksbezeichnung.
Ne, ich bin beim CD Image geblieben und habe es jetzt installiert. Habe einfach das Verzeichnis für die Instalation nicht eingebunden, dann war das HD image auf C: wo es hingehört.
Spielt aber jetzt eh alles keine Rolle mehr. Ich habe versucht von der HD aus das Image Formatiert zurückschreibprogramm zu verwenden und dieses konnte wieder nicht auf die Image Floppy schreiben. Sieht wohl so aus, als wäre qemu beim emulieren noch nicht so weit, denn dieses Programm geht ziemlich tief ins System um auch 1:1 Sicherungskopien von kopiergeschützen Disketten erstellen zu können. Wer hd-copy für DOS kennt, der weiß was ich meine.
Auf jedenfall versagt qemu mit diesem Programm. Ich werde es mal mit Bochs oder FreeDOS ausprobieren, hauptsache die Image datei ist auf die floppy image datei wieder zurückgeschrieben danach kann ich ja dann wieder mit qemu testen, aber dazu habe ich heute keine Zeit mehr.
Es ist wichtig daß ich die RAW Image datei vom Gastsystem aus formatieren kann, da dazu ein spezielles progamm notwendig ist um meine Image Datei zurückzuschreiben.
Also bitte keine Vorschläge wie man die Image Datei in Linux formatiert.
Und wie sieht es mit einem Backport für Debian 4.0 (Etch) aus?
In der Zwischenzeit kannst du das regulaere Paket[1] verwenden, es laeuft ohne Aenderung auch auf Sid und Etch.
Ubuntu musst du selber schauen, das interessiert mich nicht[2].
[0] http://lists.debian.org/debian-release/2007/02/msg00220.html
http://lists.debian.org/debian-release/2007/02/msg00227.html
[1] http://blog.daniel-baumann.ch/2007/02/06#20070206_re_kqemu-is-free
[2] http://people.debian.org/~daniel/documents/ubuntu.html
Hoffentlich schafft es das Paket noch in etch, wenn nicht, dann werde ich das reguläre Paket verwenden,
danke für den Tipp + die Links.
wenn ich eine amd64 cpu habe, dann kann ich darauf ja auch ein 32bit OS verwenden. ist es dann aber möglich auf einem 32bit host (welches auf einer 64bit cpu läuft) auch ein 64bit gast OS zu verwenden? wie sieht es umgekehrt aus, also kann ich auf einem 64bit host einen 32bit gast laufen lassen?
auf die Debian Plattform.
Wenn du qemu als amd64 Binary auf amd64 Debian ausfuehrst, gehen 64bit und 32bit Betriebssysteme. Wenn du qemu als i386 Binary auf amd64 Debian oder i386 Debian ausfuehrst, gehen nur 32bit Betriebssysteme.
Damit zusaetzlich auch kqemu geht, muss Host und Guest Plattform aber identisch sein.
Empfehlen würde Kqemu & Kemu trotzdem, VMware oder Parallels sind auch nicht viel schneller.
Benchmarks.
Bin mal gespannt, welches dann besser läuft
Z.B. auch die Kernel-Based-Virtual-Machine (KVM) die ja in 2.6.20 ist und auch eine angepasste QEmu Version nutzt. Sicher eine, vermutlich noch leistungsfähigere, Alternativlösung zu kqemu. Mehr dazu auch da:
http://www.golem.de/showhigh2.php?file=/0702/50328.html&wort[]=linux
Qemu hat allerdings etwas das andere Emulatoren/Virtualisierer nicht haben: Es emuliert ganze Systeme.
So kann ich auf einem x86er ausprobieren wie ein Programm auf einem Sparc, Arm oder PowerPC System funktioniert.
Damit ist es jetzt vielleicht nicht so interessant für jemanden, der produktiv irgendeine Software drauf laufen lassen möchte, aber dafür für jemanden der sich für systemnahe Programmierung dieser Architekturen interessiert bzw. sich da einarbeiten möchte ohne gleich Hardware kaufen zu müssen.
Weil Qemu basierend, kann man vorhandene Qemu Images, Kommandozeilen (bis auf (KQEMU-Parameter) und Netzwerkeinrichtungen 1:1 weiterverwenden.
Wenn man so einen Prozessor hat, ist es wirklich eine nette Lösung. Die GUI bzw. der Gast fühlt sich noch etwas flüssiger an. Aktuelle wird wohl eine Netzwerkemulation für KVM im Gigabitbereich entwickelt, so dass auch das Problem mit dem langsamen Netzwerk wegfallen würde.
So etwas suche ich nämlich zur Zeit, ich bin nämlich zu Faul geworden, dauernd die Dokumentation zu lesen,
nur um zu sagen, daß ich nen PC mit VGA Grafikkarte emulieren will und wo sich die Image Datei mit dem zu ladenden Festplattenimage befindet.
Für Bochs suche ich übrigens genau das gleiche.
So richtig schön aus einer Packung
Läuft wunderbar.
Kann man sogar ganz bequem per Java Webstart installieren, nur leider ist es dort
nur die ältere Version.
Ich habe es also manuel installiert, um die neuste Version mit einigen wichtigen Features mehr zu haben.
Eine Suche bei freshmeat nach "qemu" hätte Dir natürlich auch geholfen.
Auf jeden Fall läuft darauf AROS http://www.aros.org
Ich werde es mir mal anschauen.
Habe es gerade getestet.
Es läuft sogar mit qemu 8.0 ohne Probleme.
und in der Emulationsumgebung nutzen?
BSP:
Ich habe ein OS als image datei.
Z.b. linux.image
Von diesem wird gebootet, in dem man es der Festplatte hda zuweist und qemu startet.
Nun möchte ich noch das Verzeichnis /temp der Festplatte hdb zuweisen, so
daß ich im Gastsystem auf dieses Verzeichnis mit schreib und leserechten zugreifen kann.
Wann bzw. wie geht das in qem?
http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC24
QEMU hat angeblich so eine Art SMB-Server eingebaut (habe ich aber bei meinem letzten Versuch vor einiger Zeit nicht zum Laufen bringen können).
Alternativ (falls man auf die Dateien im Image nur zugreifen muss, wenn QEMU nicht läuft), kann man ein HDD-Image auch unter Linux als Loopback-Device mounten:
mount -o loop,offset=32256 hdc.img /tmp/hdc/
(Der Offset sorgt dafür, dass im Festplatten-Komplettimage "hdc.img" die erste Partition gemountet wird.)
Vor dem Starten von QEMU ist u.a. wegen Problemen mit Write-Caching (durch Linux und/oder QEMU) das unmounten der Image-Partition zu empfehlen.
Bei mir scheint das nämlich irgendwie nicht zu funktionieren.
Ich habe von einem alten Spiel auf 5.25" Disketten, in welches man direkt reinbooten muß (es ist also kein DOS Spiel) eine RAW Image Datei erstellt, aber qemu kann davon nicht booten.
Muß man da irgendeinen extra Parameter angeben?
Und ist es egal mit welchem Progamm die RAW Image Datei erstellt worden ist?
dd if=/dev/fd0 of=/tmp/floppy.img
dann sollte das Image auch in Qemu booten:
qemu -fda /tmp/floppy.img -localtime -boot a
Ich kenn mich mit alten Games und deren Kopierschutz nicht aus, das könnte evtl. eine mögliche Fehlerquelle sein.
Wenn ich in RAW Image nach fda, also B: in QEMU einbinde
und im Gastsystem ein
Format B:
mache, dann erhalte ich folgenden Fehler:
Invalid Drive! Aborting
[Error 61]
So wie es aussieht liest qemu die disk images nur lesend ein.
Wie kann ich als die DISK Images beschreibbar mounten?
fdb ist B:
Disk images sind r/w in Qemu eingebunden.
> Disk images sind r/w in Qemu eingebunden.
Und warum kann ich sie dann nicht formatieren?
Ich hab das fertige FreeDos Festplatten Image von der Qemu Download Seite als OS benutzt und nach /tmp entpackt.
-Eine leere Floppy erstellt mit:
dd if=/dev/zero of=/tmp/floppy.img bs=1024 count=1400
- Qemu gestartet mit:
/qemu -hda /tmp/freedos.img -fda /tmp/floppy.img -localtime -boot c
Danach format a: eingegeben und es funzt sofort. Der Beweis:
http://img253.imageshack.us/img253/5510/bildschirmfotoqemuts6.png
qemu -hda /tmp/freedos.img -fda /tmp/floppy.img -localtime -boot c
Ich benutze aber auch Bochs 0.8.0 von Ubuntu Dapper Drake
und die ISO Live+Install CD von FreeDOS 1.0.
Vielleicht liegt es daran.
Und zwar habe ich vorher die floppy nach fdb gemountet, weil die FreeDOS CD sich ein eigenes Laufwerk auf A: anlegt, daher dachte ich, ich müßte für das Disk Image B: also fdb nehmen.
Jetzt habe ich fdb nach fda geändert und darauf die image Datei gemountet.
Aber wenn ich dann qemu mit freedos starte, dann legt freedos sein zeug wieder auf A: an und verschiebt die Image Diskette nach B:
Die liegt also in B: obwohl nach fda gemountet wurde.
Und hier funktioniert das formatieren dann.
Und das DOS programm mit dem ich die die Imaga Floppy beschreiben will erwartet die Daten wieder auf A: und weigert sich B: zu nehmen.
Ich denke ich werde freedos auf ein hd image installieren müssen um es dann noch einmal zu probieren.
Und wenn es dann auch nicht geht, dann muß ich wohl bochs verwenden, vielleicht ist das ausgereifter als qemu.
jetzt habe ich ein Verzeichnis nach hdb und ein hd.img nach hdc eingebunden.
da das hd.img aber unformatiert ist, liegt das verzeichnis von hdb jetzt auf C: anstatt auf D:
Wenn ich bei DOS eine ide0 master Festplatte einhänge die nicht formatiert ist und eine formatierte ide0 slave einhänge, dann ist die ide0 slave automatisch C: solange bis ich ide0 master formatiere und reboote. Erst dann stimmt die Laufwerksbezeichnung.
Habe einfach das Verzeichnis für die Instalation nicht eingebunden, dann war das HD image auf C: wo es hingehört.
Spielt aber jetzt eh alles keine Rolle mehr.
Ich habe versucht von der HD aus das Image Formatiert zurückschreibprogramm zu verwenden und dieses konnte wieder nicht auf die Image Floppy schreiben.
Sieht wohl so aus, als wäre qemu beim emulieren noch nicht so weit, denn dieses Programm geht ziemlich tief ins System um auch 1:1 Sicherungskopien von kopiergeschützen Disketten erstellen zu können.
Wer hd-copy für DOS kennt, der weiß was ich meine.
Auf jedenfall versagt qemu mit diesem Programm.
Ich werde es mal mit Bochs oder FreeDOS ausprobieren, hauptsache die Image datei ist auf die floppy image datei wieder zurückgeschrieben danach kann ich ja dann wieder mit qemu testen, aber dazu habe ich heute keine Zeit mehr.
Es ist wichtig daß ich die RAW Image datei vom Gastsystem aus formatieren kann,
da dazu ein spezielles progamm notwendig ist um meine Image Datei zurückzuschreiben.
Also bitte keine Vorschläge wie man die Image Datei in Linux formatiert.