qemu und virtualbox gleichzeitig betreiben?

[jutta]

weiss jemand, ob es moeglich ist, qemu und virtualbox gleichzeitig zu betreiben? oder zumindest gleichzeitig installiert zu haben und dann nur eins davon einzuschalten? der gleichzeitige betrieb von virtualbox und vmware ist meiner erfahrung nach unmoeglich und beim abwechselnden betrieb kommts sehr auf die reihenfolge des ein- und ausschaltens an, sonst kriegt man fehlermeldungen en masse.

zum zusammenhang:

ich brauch fuer die reparatur eines kranken nas einen powerpc. nach ein bissl googeln habe ich herausgefunden, dass qemu die powerpc architektur emulieren kann. andere tipps zu dem thema werden gerne entgegen genommen. es geht darum, die 4 festplatten auszubauen und das raid5 zu mounten. (ist ein "normales" linux mdadm raid)

[lordpeng]

ohne es jemals getestet zu haben bzw. dies testen zu wollen, würd ich behaupten, dass da durchaus probleme geben kann, da wesentliche teile von virtualisierungslösungen meist sehr hardwarenah programmiert sein dürften, wodurch konflikte sicherlich nicht auszuschliessen sind ... aber da es sich ja um opensource software handelt, wärs das einfachste mal ein mail an die entwickler zu schicken oder in einer entwickler-mailinglist der jeweiligen applikation nachzufragen, was die denn meinen ... ich denk dort wirst die kompetenteste antwort bekommen

[gendelider]

Wenn "nur" installiert hast, sollst du berücksichtigen, dass virtualbox von /etc/init.d sein driver startet - man muss es verhindern. Übrigens virtualbox ist selber auch qemu.

[fredl99]

es geht darum, die 4 festplatten auszubauen und das raid5 zu mounten. (ist ein "normales" linux mdadm raid)

Wofür genau braucht man dazu einen PowerPC?
Oder hab ich da etwas falsch verstanden?

[jutta]

man braucht deshalb einen powerpc, weil die diese terastation einen ppc-processor hat http://buffalo.nas-central.org/wiki/HardwarePro und die auf der terastation installierte mdadm-version endian-sensitiv ist. siehe http://buffalo.nas-central.org/wiki/Ter ... a_Recovery

und ein update zu meinem op: die "unmoeglichkeit" besteht offenbar nur zwischen virtualbox und vmware server. virtualbox und vmware player auf meinem (debian squeeze) laptop haben anstandslos funktioniert, kurzfristig sogar gleichzeitig eingeschaltet (wobei ich nicht probiert habe, was passiert, wenn ich dann noch versuche, usb-anschluesse durchzureichen oder aehnliches)

[fredl99]

weil die diese terastation einen ppc-processor hat http://buffalo.nas-central.org/wiki/HardwarePro und die auf der terastation installierte mdadm-version endian-sensitiv ist

Also was für eine CPU die hat, ist meines Erachtens erstmal egal.
Im Bezug auf mdadm sagt die man-page (auszugsweise):

--metadata=
Declare the style of RAID metadata (superblock) to be used. The default is 1.2 for --create, and to guess for other operations. The default can be overridden by setting the metadata value for the CREATE keyword in mdadm.conf.
Options are:

0, 0.90
Use the original 0.90 format superblock. This format limits arrays to 28 component devices and limits component devices of levels 1 and greater to 2 terabytes. It is also possible for there to be confusion about whether the superblock applies to a whole device or just the last partition, if that partition starts on a 64K boundary.

1, 1.0, 1.1, 1.2 default
Use the new version-1 format superblock. This has fewer restrictions. It can easily be moved between hosts with different endian-ness, and a recovery operation can be checkpointed and restarted. The different sub-versions store the superblock at different locations on the device, either at the end (for 1.0), at the start (for 1.1) or 4K from the start (for 1.2). "1" is equivalent to "1.0". "default" is equivalent to "1.2".

und:

-U, --update=
Update the superblock on each device while assembling the array. The argument given to this flag can be one of sparc2.2, summaries, uuid, name, homehost, resync, byteorder, devicesize, no-bitmap, or super-minor.
[...]
The byteorder option allows arrays to be moved between machines with different byte-order. When assembling such an array for the first time after a move, giving --update=byteorder will cause mdadm to expect superblocks to have their byteorder reversed, and will correct that order before assembling the array. This is only valid with original (Version 0.90) superblocks.

Also, wenn es nur um endian-awareness geht, sollte das auch so gehen, ebenso mit der byte-order. Allerdings scheinen sich die Optionen gegenseitig auszuschließen. Einen Versuch wäre es aber wert, bevor die Krämpfe in einer VM anfangen.

Das Problem zwischen QUEMU und VBox wurde übrigens neulich hier aufgedeckt. Es scheint sich besonders dann drastisch zu manifestieren, wenn man QUEMU wieder deinstalliert.

[jutta]

wenn die festplatten an eine linux-maschine angeschlossen werden, kann mdadm das raid5 nicht zusammen bauen. das haben schon andere versucht. daher gibt es folgende moeglichkeiten:

a) eine zweite baugleiche terastation (dazu raet aus naheliegenden gruenden der buffalo-support) heute ist es allerdings schon schwierig, da dieses modell laengst eol ist. (und vor ein paar jahren hat diese loesung ueber 700 euro gekostet, wenns kein garantiefall war)
b) einen anderen rechner auf ppc-basis, auf deutsch: einen alten mac
c) einen emulator, unter dem man linux fuer ppc installieren kann
d) ufs explorer

wobei d) die einfachste loesung ist. funktioniert wirklich idiotensicher. man muss halt entscheiden, ob einem das 65 bis 200 euro wert ist.

das zitat mit -update ist allerdings interessant. das ist mir bisher entgangen und *koennte* funktionieren. wobei es ein bissl riskant ist, die mdadm version eines dings zu erraten, auf dessen systempartition nicht zugegriffen werden kann.

die daten hab ich eh schon laengst in sicherheit - eben mit dem ufs-explorer. die uebrigen optionen sind also nur mehr theoretische ueberlegungen und vielleicht probier ich das eine oder andere noch in der praxis aus. (ich habe ja images der festplatten - genauer: von 3 der 4 festplatten, die 4. ist defekt und das image daher voellig unbrauchbar)

[jutta]

> Das Problem zwischen QUEMU und VBox wurde übrigens neulich hier aufgedeckt. Es scheint sich besonders dann drastisch zu manifestieren, wenn man QUEMU wieder deinstalliert.

ich hab mir den thread jetzt durchgelesen und denke, dass es auf den tipp rauslaeuft, den genderlider schon weiter oben gegeben hat: dafuer sorgen, dass die treiber nicht automatisch geladen werden.