[Dark Lam0r]

Nochmal vielen Dank für die vielen Antworten.
Ich habe es übrigens innerhalb November geschafft, zumindest den wichtigen Datenteil zu retten und die Kiste neu mit Proxmox zu installieren. Generell würde ich jedem davon abraten xen noch zu benutzen, da proxmox ohnehin besser zu verwalten ist und deutlich sinnvoller arbeitet.

XEN: standardmäßig VDI-Images, sehr schlecht zu handlen außerhalb von xen
Proxmox: RAW Images, können einfach ausserhalb eingebunden werden
LVM benutzen zwar beide, aber aufgrund der imageformate lässt es sich bei Proxmox (vermutlich) deutlich besser retten, da man sich untenstehende Umwandlung sparen kann und vermutlich on-the-fly alles einbinden bzw. per loopback bereitstellen kann. alle tipps zur einbindung von VDI z.B. mit "losetup -o *offset*" waren nicht möglich

Das größte Problem bei meiner Rettung war, dass die formate sich aufgrund der installation verschachtelt haben:
LVM{VDI[LVM(Part0,Part1)],VDI[LVM(Part0,Part1)]}
Falls jemand mal vor einem ähnlich Problem steht:

1. Externe Festplatte anschließen lassen oder eine Festplatte mit weniger wichtigen Daten löschen
2. LVM im vKVM mounten
3. VirtualBox installieren, da ein Tool daraus benötigt wird
4. VDI-Image mit "VBoxManage clonehd --format RAW /pfad/zum/lvm_volume /leere_platte/raw_volume.img" auf die freie Platte ins RAW-Format umwandeln
5. Das RAW-Image mit "losetup /dev/loop0 /leere_platte/raw_volume.img" einbinden
6. Das eingebundene Loopback-Laufwerk mit LVM mounten und Daten sichern

Da ich mir nicht alles aufgeschrieben habe, was ich versucht habe und ich jetzt mehr durch Zufall nach der Zeit nochmal über das Thema gestolpert bin, ist die Beschreibung etwas ungenau, hilft aber sicherlich zur Orientierung weiter, falls jemand je vor einem ähnlichen Problem steht.

[Dark Lam0r]

Hallo an alle,
auf meinem Server der Serie SYS-IP-1 läuft Citrix XenServer 6.5 (64bits). Bei dem habe ich am Montag die offiziellen Quellen in der /etc/yum.repos.d/CentOS-Base.repo aktiviert und ein "yum update" ausgeführt, wie ich es vorher hier auf einem lokalen Server auch getan habe. Nach einem "shutdown -r now" wollte dieser Server allerdings nicht mehr hochfahren. Ich habe dann lange gegooglet, was ich denn noch machen kann und hab mir nach dieser Anleitung ein vKVM installiert und mal nachgesehen, was los ist.
Offensichtlich hängt der Server in einer Bootschleife, mit der Meldung "IO-APIC + timer doesn't work", wenn ich dann allerdings, wie mir die Meldung empfiehlt, mit der "noapic" option den kernel aufrufe, bekomme ich gesagt, dass diese Option mit Xen nicht kompatibel ist.
Auch der Versuch mit einem Original-Image über vKVM hochzufahren scheitert am gleichen Fehler.
Es scheint wohl, dass der Kernel in der Grundinstallation von OVH angepasst wurde. Leider ist es mir bisher nicht möglich gewesen, irgendeine Quelle zu finden, von der ich entweder Installationsdateien/-medien oder ein Image beziehen kann, mit dem der Server zu retten ist, ohne die Dateisysteme der VMs zu verlieren. OVH selbst bietet leider auch keine Neuinstallation in die vorhandene Partitionierung an, denn dadurch wäre es möglich, die VMs einfach wiederzubeleben, ohne sie komplett neu aufzusetzen, nachdem alle Inhalte wegpartitioniert wurden.

Wenn jemand gerade eine neu aufgesetzte SYS-IP-1 Xen6.5 Kiste hat, wäre ich superglücklich, wenn ich ein Image davon bekommen könnte, möglicherweise reicht auch einfach nur die Kernel-Dateien zu bekommen (da ist es dann auch egal, ob die frisch aufgesetzt ist oder schon Jahre läuft)... man weiß es nicht genau...
Ich verstehe leider auch nicht, warum die Original-Images auf allem, was ich bisher getestet haben laufen, nur nicht auf der OVH-Kiste. Selbst auf einem Rechner, bei dem die CPU keine Virtualisierung unterstützt lief das.

Für jede Hilfe schonmal Vielen Dank