Probleme beim Abfragen der Hardware

[H3llGhost]

Hallo zusammen,

ich wollte heute den Converter ausprobieren und habe festgestellt, dass es scheinbar immer noch Probleme mit einem Software RAID unter Debian gibt.
Ich habe 5.5.1 ausprobiert und bekomme einen Fehler beim Abfragen der Hardware: SysinfoQueryNoBootDirFault

Hat jemand schon Erfahrungen in dem Bereich sammeln können?

[irix]

Vorher die Kernelmodule fuer die Hardware einbauen, 2 LIveCDs booten und dann DD/tarball. Anpassen vom Bootloader, fstab und je nach Distri gucken wo sich die Netzwerklarte versteckt.

Wenn es denn mal wieder bootet kann man sich an den Tools versuchen.

Gruss
Joerg

[H3llGhost]

Danke für deine schnelle Antwort! Klingt ja eigentlich ganz plausibel aber ich hätte vielleicht hinzufügen müssen, dass der Server für mich physikalisch nicht erreichbar ist, da er in einem Rechenzentrum steht.

[irix]

Ilo idrac

[H3llGhost]

Ilo idrac

Wie bitte?

[irix]

War von unterwegs... wenn die Kiste im RZ steht dann hast du doch bestimmt ein Remote Management wie ILO, iDRAC, iRMC usw. um ein ISO zumounten.

Gruss
Joerg

[H3llGhost]

Achso, jetzt verstehe ich. Ich habe Zugriff auf das IPMI.

Bezüglich der Schritte, welche ich durchführen muss:
Was für Kernelmodule meinst du?
Welche Live-CDs brauche ich?

[irix]

Der spaetere SCSI Kontroller waere nicht schlecht. Aber das kann man auch hinterher in einer chroot machen wenn man sich sein original nicht verhunzen moechten.

Du nimmst die LiveCD welche du magst. Letztendlich muss sich halt nur in einer VM laufen. SSH und DD bzw. chroot ist in jedem minimal Linux drin.

Wenn du hier im Forum suchst bzw. Tante Google fragst findest du bestimmt ein Howto welches Anschubhilfe gibt. Ich habe hier meine Linux Admins

Gruss
Joerg

[H3llGhost]

Hmm also gibt es noch keine native Unterstützung vom Converter für so ein Szenario?

Ja ich muss mal recherchieren wie ich das RAID auflösen kann ohne Daten zu verlieren.
Anschließend sollte ja auch der Prozess funktionieren

[~thc]

Du hast mehrere Möglichkeiten.

Laut der Fehlermeldung des Converters findet er das "/boot"-Verzeichnis nicht - ist das für diese Debian-Maschine korrekt? Du könntest in diesem Fall die Partition, die das "/boot"-Verzeichnis enthält (meist außerhalb des RAIDs) selbst manuell mounten.

Ist das Verzeichnis vorhanden, aber laut "mount" aus einer anderen Partition stammend eingehängt worden, so kann der Converter damit leider nicht umgehen.

Dann bleibt dir entweder das RAID vor der Konvertierung aufzulösen oder - wie irix schon sagte - mit "dd" ein Mitglied des RAID-Verbundes zu kopieren und das RAID nachher in der VM aufzulösen. Ich habe so etwas im letzten Dezember gemacht: http://vmware-forum.de/viewtopic.php?t=29345.

[H3llGhost]

Danke für eure Antworten.
Letztendlich sieht es aber so aus, als ob ich nicht den Converter für diese Operation ansich nehmen kann sondern auf andere Alternativmethoden ausweiche?

Laut der Fehlermeldung des Converters findet er das "/boot"-Verzeichnis nicht - ist das für diese Debian-Maschine korrekt? Du könntest in diesem Fall die Partition, die das "/boot"-Verzeichnis enthält (meist außerhalb des RAIDs) selbst manuell mounten.

Ist das Verzeichnis vorhanden, aber laut "mount" aus einer anderen Partition stammend eingehängt worden, so kann der Converter damit leider nicht umgehen.

Ich muss ehrlich gesagt gestehen, ich weiß nicht, wie ich das überprüfen soll.
Der Server besitzt eine SSD und zwei HDDs. Auf der SSD soll laut Template des Anbieters die boot Partition liegen.

[~thc]

Ich muss ehrlich gesagt gestehen, ich weiß nicht, wie ich das überprüfen soll.

Du loggst dich per SSH in den Debian-Host ein und schaust dir die Ausgabe der Kommandos

Code: Alles auswählen

ls -la /

und

Code: Alles auswählen

mount

an.

[irix]

df -h bzw. cat /etc/fstab mit einem fdisk -l bringen auch Licht in das Dunkel.

Gruss
Joerg

[H3llGhost]

Danke für eure schnellen Antworten. Hier die benötigten Informationen:

ls

Code: Alles auswählen

total 945
drwxr-xr-x  22 root root   4096 Apr 23  2012 .
drwxr-xr-x  22 root root   4096 Apr 23  2012 ..
drwxr-xr-x   2 root root   4096 Apr 23  2012 bin
drwxr-xr-x   4 root root   1024 May 10  2012 boot
drwxr-xr-x  16 root root   3620 Apr 23  2012 dev
drwxr-xr-x 108 root root  12288 Apr 29 23:47 etc
drwxr-xr-x  12 root root   4096 Dec 18 23:58 home
lrwxrwxrwx   1 root root     30 Apr 23  2012 initrd.img -> boot/initrd.img-2.6.32-5-amd64
lrwxrwxrwx   1 root root     30 Feb 24  2011 initrd.img.old -> boot/initrd.img-2.6.26-2-amd64
drwxr-xr-x  10 root root  12288 Sep  7  2013 lib
drwxr-xr-x   4 root root  12288 Sep  7  2013 lib32
lrwxrwxrwx   1 root root      4 Feb 24  2011 lib64 -> /lib
drwx------   2 root root  16384 Feb 24  2011 lost+found
drwxr-xr-x   3 root root   4096 Mar  9  2011 media
drwxr-xr-x   2 root root   4096 Jan 16  2011 mnt
drwxr-xr-x   2 root root   4096 Feb 24  2011 opt
dr-xr-xr-x 217 root root      0 Jan 14  2012 proc
drwxr-xr-x  32 root root   4096 Dec 18 23:33 root
drwxr-xr-x   2 root root   4096 Sep  7  2013 sbin
drwxr-xr-x   2 root root   4096 Sep 16  2008 selinux
drwxr-xr-x   2 root root   4096 Feb 24  2011 srv
drwxr-xr-x  11 root root      0 Jan 14  2012 sys
drwxrwxrwx  11 root root 856064 Apr 30 20:09 tmp
drwxr-xr-x  11 root root   4096 Apr 23  2012 usr
drwxr-xr-x  17 root root   4096 Jun 22  2011 var
lrwxrwxrwx   1 root root     27 Apr 23  2012 vmlinuz -> boot/vmlinuz-2.6.32-5-amd64
lrwxrwxrwx   1 root root     27 Feb 24  2011 vmlinuz.old -> boot/vmlinuz-2.6.26-2-amd64


mount

Code: Alles auswählen

/dev/md1 on / type ext3 (rw)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/md0 on /boot type ext2 (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)


df

Code: Alles auswählen

Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              881G  315G  522G  38% /
tmpfs                 4.0G     0  4.0G   0% /lib/init/rw
udev                   10M  736K  9.3M   8% /dev
tmpfs                 4.0G  4.0K  4.0G   1% /dev/shm
/dev/md0               93M   37M   52M  42% /boot


fdisk

Code: Alles auswählen

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0008f156

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          13       97656   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2              13         137     1000000   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3             137      115968   930415039   fd  Linux raid autodetect

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000908ea

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          13       97656   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2              13         137     1000000   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sdb3             137      115968   930415039   fd  Linux raid autodetect

Disk /dev/sdc: 60.0 GB, 60022480896 bytes
255 heads, 63 sectors/track, 7297 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00091dca

   Device Boot      Start         End      Blocks   Id  System

Disk /dev/md0: 99 MB, 99876864 bytes
2 heads, 4 sectors/track, 24384 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

Disk /dev/md1: 952.7 GB, 952744869888 bytes
2 heads, 4 sectors/track, 232603728 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table


Wenn ich mir so die Ausgabe anschaue, scheint es so, als ob die SSD garnicht wirklich genutzt wird.
Hat natürlich jetzt auch für mich Vorteile, weil ich dann doch die Bootpartition umziehen lassen kann und somit der Converter diese Partition nicht im Software-RAID suchen muss oder vertue ich mich jetzt da?

[~thc]

Ja, die SSD ist ungenutzt. Das Software-RAID wird aus zwei MD-Devices aufgebaut. Das kleine enthält nur "/boot" - das große "/" (den Rest). Der Converter erwartet scheinbar, dass "/boot" nativ auf der gleichen Partition bzw. dem gleichen Device liegt wie "/".

[JustMe]

Hmmm, wenn ich mir die Groessen so anschaue, dann wuerde ich meinen, dass / und /boot schon auf den gleichen Devices liegen, naemlich als Spiegel auf sda1/sdb1 (/boot) und sda3/sdb3 (/)...
Andererseits bin ich ganz bestimmt nicht der geborene Linuxer unter dem Herrn...

Wenn aber schon fdisk nix mehr mit der Konfiguration/dem Dateisystem auf den beiden eingerichteten Spiegeln md0 und md1 anfangen kann, dann ist's nicht mehr unwahrscheinlich, dass auch der VMware Converter hier scheitert. Meines Wissens hat auch noch nie jemand behauptet, dass alle und jede beliebige Konfiguration unter allen Umstaenden damit fehlerfrei virtualisiert werden koenne )

Letztlich bleibt, um hier mal voranzukommen, nur wie schon eingangs eindringlich angeraten, die Daten von Hand in eine neu angelegte VM zu uebertragen, und deren Bootkonfiguration dann passend einzustellen. Das sollte mit etwas Entdeckergeist in der bevorzugten Findemaschine (und einem verlaesslichen Backup) auch kein Hexenwerk sein.

Wie ansonsten ~thc schon schrieb, wird die 60GB SSD offenbar zumindest nicht fuer /boot verwendet. Trotzdem kann sich darauf noch der MBR und weiterer BootCode befinden. Insofern koennte die Information "des Anbieters" zumindest teilweise richtig sein, und man hat beim Verwenden des "Templates" einfach einen Fehler gemacht. Vielleicht ist ja auch ein ganz schlauer Treiber installiert, der die SSD als Cache verwendet wie bei IRST...

[H3llGhost]

Ja, die SSD ist ungenutzt. Das Software-RAID wird aus zwei MD-Devices aufgebaut. Das kleine enthält nur "/boot" - das große "/" (den Rest). Der Converter erwartet scheinbar, dass "/boot" nativ auf der gleichen Partition bzw. dem gleichen Device liegt wie "/".

Entschuldigt meine späte Antwort.
Kann man in dem Fall nicht einfacher die Bootpartition "umlegen" für den Converter und danach es wieder rückgängig machen?

Da der Server dem Tode geweiht sein wird, ist es möglich das RAID auch jetzt schon aufzulösen?
Weil ich würde so lange ungerne den Server vom "Netz" nehmen.

[Dayworker]

Code: Alles auswählen

/dev/sda1               1          13       97656   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2              13         137     1000000   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sda3             137      115968   930415039   fd  Linux raid autodetect
...
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          13       97656   fd  Linux raid autodetect
Partition 1 does not end on cylinder boundary.
/dev/sdb2              13         137     1000000   82  Linux swap / Solaris
Partition 2 does not end on cylinder boundary.
/dev/sdb3             137      115968   930415039   fd  Linux raid autodetect


Ausgehend von dieser Partitionstabelle würde ich dieses OS nicht einfach in eine VM konvertieren, da die Partitionen nicht korrekt ausgerichtet (missaligned) sind. Das kann man zwar nachträglich über mein HowTo HowTo - Nachträgliches Alignment auf Sektor 2048 wieder geradebiegen, aber ich glaube es wäre einfacher weil schneller, wenn man die Partitionen gleich korrekt ausgerichtet in VMware anlegt und dann die weitere Vorgehensweise, wie von "irix" bereits im April beschrieben, abarbeitet. Allerdings würde ich hier den "tarball" nutzen, da bei DD ja wieder falsch ausgerichtete Partitionen rauskommen würden. Um das Anpassen von Bootloader, fstab etc kommst du sowieso nicht herum, da die VM ja ohne Raid laufen wird.

Wegen dem "tarball" sieh dir mal exemplarisch http://de.opensuse.org/SDB:SuSE_Linux_umkopieren an.

[H3llGhost]

Danke für deine Antwort.
Wenn ich tarball nutzen möchte, könnte ich es auch sicherlich pipen, um letztendlich es via ssh auf eine andere Maschine zu befördern ala:

Code: Alles auswählen

tar -cSp --numeric-owner --atime-preserve -f - . | gzip -c | ssh root@esxiserverip "gzip -c -d > /vmfs/volumes/datastore2/server/server.tar"


[irix]

Wir klammern fuer den Tarball noch jede Menge Verzeichnisse aus wie div. Temp/log/udev usw.

Gruss
Joerg

[H3llGhost]

Macht wahrscheinlich in gewisser Hinsicht Sinn. Die Logs würde ich schon mitnehmen wollen (wenn du /var/log meinst).

Code: Alles auswählen

tar -cSp --numeric-owner --atime-preserve --exclude /tmp --exclude /dev --exclude /proc -f - .


Das /dev müsste ich aber mitnehmen, wenn ich den RAID Verbund auflösen möchte oder?

[Dayworker]

Den Tarball direkt auf das VMFS des ESXi zu beamen, macht für mich keinen Sinn, da dieser nur eine 1:1-Kopie des Dateisystems aber keine Partitionen enthält. Von daher würde ich auf dem ESXi einfach einen neuen Linux-Gast aufsetzen, diesen von einer Live-CD booten und dann die Daten direkt in die VM beamen.
Das Raid vor dem Beamen noch aufzulösen, dürfte dir einige Arbeit ersparen.

[H3llGhost]

Die Geschwindigkeit scheint generell ziemlich langsam zu sein.
dd hat um die 50 MB/s erreicht und tar schafft maximal 20 MB/s.

Kann ich die einzelnen Prozesse noch beschleunigen?

[~thc]

Du kannst dd auch durch gzip pipen, aber das bringt nach meiner Erfahrung nur spürbar etwas bei Partitionen, deren unbenutzte Bereiche mit Nullen überschrieben worden sind.

[Dayworker]

Welche CPU läuft im zu virtualisierenden Rechner?
Dann könnte man die 20MB/s des Tarballs besser einordnen.

DD per gzip zu pipen ist möglich und bringt, wie von "~thc" angemerkt, nur etwas bei ausgenullten Bereichen. Wenn du allerdings mit DD arbeiten willst, warum beamst du dann nicht gleich in eine VM?
Beide "Rechner" (PC und VM) per Live-CD starten, der VM beispielsweise die IP 192.168.0.1 verpassen und "netcat" starten:

Code: Alles auswählen

netcat -l -p 9000 | dd of=/dev/sda

Das Pendant in der VM würde dann lauten:

Code: Alles auswählen

dd if=/dev/sda | netcat 192.168.0.1 9000

Sobald die VM den PC auf Port 9000 anspricht, läuft DD los.

Code: Alles auswählen

Filesystem            Size  Used Avail Use% Mounted on
/dev/md1              881G  315G  522G  38% /
tmpfs                 4.0G     0  4.0G   0% /lib/init/rw
udev                   10M  736K  9.3M   8% /dev
tmpfs                 4.0G  4.0K  4.0G   1% /dev/shm
/dev/md0               93M   37M   52M  42% /boot

Mir ist allerdings schleierhaft, weshalb du, abgesehen vom bereits festgestellten Missalignment deiner Partitionen, bei diesen Vorraussetzungen unbedingt DD nehmen willst. DD würde dir hier doch völlig sinnlose 522GB an unbelegtem Plattenplatz kopieren. Die 315GB als Tarball wären bei 20MB/s nach ~4.5h fertig, während du per DD diese Menge zwar in ~2h fertig hättest und dazu dann aber noch die eigentlich unnötigen 522GB mit weiteren 3h dazukommen würden.

Zeittechnisch ist das jetzt nicht der grosse Unterschied, aber den Bootloader, fstab etc mußt du doch sowieso auf die neuen Verhältnisse anpassen. Es ist auch fraglich, ob du mit einer VM von 1TB Plattengrösse gut beraten bist, wenn davon nicht mal die Hälfte belegt ist. Du solltest in der VMware-Welt immer im Hinterkopf haben, daß du jederzeit und problemlos eine vDISK vergrössern, aber nicht auf demselben Wege eine vDISK wieder verkleinern kannst. Schon aus diesem Grunde würde ich von DD komplett absehen.


Zur Frage der Geschwindigkeitsoptimierung bei DD kannst du "bs=xx" nutzen. Je nach Distribution nutzt DD dann bei fehlender bs-Angabe eine bestimmte Voreinstellung. Da die meisten OS in 4KB-Blöcken anfragen, würde ich auch damit oder einem Vielfachen davon wie 32MB arbeiten. Bei GZIP dürfte sich auch einiges herausholen lassen, wenn man den Kompressionsgrad zwischen 1-9 (bei Voreinstellung von 6) variiert, wobei 1 dann maximale Geschwindigkeit mit geringfügigster Kompression entspricht.