PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenSuSE migrieren Xen -> VMWare Fusion



fork
15.11.17, 19:16
Hi,

ich habe gerade folgendes in der Mache:

Situation

Installation einer OpenSuSE(Leap 42.3) Linux-Distribution unter Xen(Citrix XenServer)
und exportieren des ganzen als ova - Exportdatei und importieren dieser Datei auf
einem Mac in VMWare Fusion(Virtualisierungssoftware für den Desktop). Den Import
nimmt ein anderer als ich vor und ich kann per Teamviewer unterstützen.

Mein Problem ist dass die SuSE dort nicht hochfährt.

Ich sehe einen systemd-Dienst abgekürzt "dev-disk" der startet,
aber ohne Limit ist und nicht zum Ende kommt.

Vermutung

Das System sucht eine oder mehrere Partitionen, die so auf dem neuen System anders benannt sind.

Was ich bisher getan habe


von der Kernel command-line das resume=/dev/xvda2 weggenommen. Keine Wirkung
/etc/fstab geprüft. Dort sind überall nur UUIDs eingetragen, und die müssten identisch geblieben sein
im Grub mit vmlinuz ... init=/bin/bash gestartet. Die Rescue-Shell kommt nicht, nur wieder der systemd-dienst dev-disk der nicht beendet werden kann
im Grub das System mit dem Kernel-Parameter systemd.debug-shell=1 gestartet. Ich komme nicht mit Ctrl+Alt+F9 auf die Debug shell. Möglicherweise ist Teamviewer oder der Mac das Problem, der die Kombination nicht weitergeben kann
Boot per GRML(grml-small 64+32 bit) versucht. Hat nicht geklappt. Trotz CD-Image einhängen und Startgerät auf CD setzen hat VMware Fusion nicht davon gebootet.
Das /etc und /boot Verzeichnis nach xvda abgesucht, dem Namen des Blockdevices so wie es in Xen heisst. Da war aber nicht viel. Nur mtab, welche ja dynamisch ist und grub.cfg. Dort habe ich überall das resume=xvda2 entfernt(Brauche kein suspend2disk). Ansonsten war noch in /etc irgendwo das template für grub mit dem resume=/dev/xvda2, was ich auch dort entfernt habe.


Ich erstelle jetzt nochmal ein Image vom System und hoffe das es klappt. Aber eigentlich vermute ich, dass ich den Fehler noch nicht gefunden habe.

Habt Ihr noch eine Idee?

fork();

Newbie314
16.11.17, 09:56
Ich habe das so noch nie gemacht, also meinen Vorschlag bitte mit Vorsicht genießen, aber wenn ich mich recht erinnere kann man in Virtualbox eine VM auch mit einer live distri booten. Von da aus könntest du dich evtl auf der Platte der nichtstartenden VM umsehen. Vielleicht geht das bei VMWARE...

fork
16.11.17, 10:31
Hi Newbie,

ja danke. Das hatte ich oben schon mal versucht. Sollte gehen. Hat aber leider nicht. Vielleicht probiere ich nochmal eine andere Live-Distri.

---

Ich habe jetzt selbst auch nochmal die erzeugte OVA - Datei entpackt(Sind genau 2 Dateien drin: 1 x OVF und 1 x VHD) und wollte Sie in Virtualbox importieren um da nochmal zu testen.

Als erstes hat VirtualBox gemeckert, dass in der Datei drin steht, dass es UTF16 in der Datei drin steht, aber die Datei per UTF8 kodiert ist.

Als zweites hatte sich VirtualBox dann beschwert dass die OVF-Datei(XML) eine falsch Struktur hätte. Scheint also nicht kompatibel zu sein, was XenServer 6.5 da erzeugt(6.5 ist auch nicht mehr ganz die aktuelle Version).

Als ich dann manuell eine VM erzeugt habe und als Festplattendatei(.VHD) dazu vorher importiert habe, ist die SuSi bei mir dann sauber gestartet.

Newbie314
16.11.17, 10:45
Sorry, hatte ich überlesen.

MarroniJohny
29.11.17, 22:52
Hi

Ich glaube, das liegt am virtuellen Storage Controller. Versuche mal nicht exportieren, sondern eine neue VM ohne Festplatte erstellen, und dann die VHD einzuhängen. Beim Einhängen auf den gewünschten Festplattencontroller achten. SATA geht glaub ich erst ab vm Version 10. Ansonsten SCSI parallel und seriell testen.