Two things are infinite..

Chociaż opisana w tym wpisie metoda będzie działać w przypadku systemu (open)SUSE zainstalowanego na fizycznych dyskach, to w moim przypadku potrzeba migracji pojawiła się dla dysków wirtualnych w maszynie skonfigurowanej pod Vmware. Osoby które nie są zainteresowane VMware mogą pominąć tę część opisu.

Organizacja wirtualnych dysków VMware
Dysk wirtualny w VMware zapisany jest w plikach VMDK.  Zawsze jest to jeden plik opisujący geometrię dysku, oraz jeden lub kilka plików z przestrzenią dyskową. Plik z opisem geometrii możemy otworzyć w dowolnym edytorze tekstowym (na przykład gedit w GNOME). Oto przykładowy fragment opisu dysku:

# Disk DescriptorFile
version=1
CID=f7c7de36
parentCID=ffffffff
createType="twoGbMaxExtentSparse"

# Extent description
RW 4192256 SPARSE "ext3-s001.vmdk"
RW 4192256 SPARSE "ext3-s002.vmdk"
RW 4192256 SPARSE "ext3-s003.vmdk"
....

Już po tym fragmencie można się zorientować, że dysk jest podzielony na wiele plików (ext3-s001.vmdk…itd.). Taki podział jest praktyczny jeżeli chcemy przetrzymywać wirtualny dysk na partycji, która nie obsługuje dużych plików. O tym, czy mamy dysk dzielony czy nie, decydujemy na etapie tworzenia dysku. Możemy to później zmienić (pisałem o tym w jednym z poprzednich wpisów).
Dodatkowo, tworząc dysk wybieramy, czy ma być to dysk IDE czy SCSI. I tutaj dochodzimy do sedna problemu jaki ostatnio miałem.

Jak przenieść system SUSE z dysku IDE na SCSI

Nie pamiętam już dlaczego w jednej z instalacji SLES 9 wybrałem IDE zamiast zalecanego przez Vmware SCSI. Kiedy przy pracy z systemem pojawiły się pewne problemy z wydajnością, zacząłem się zastanawiać co mogłoby być przyczyną. Wydawało mi się, że dyski są bardzo wolne i że ich wydajność jest niska. System był przeciążony podczas pracy bazy danych, która intensywnie korzystała z dysku. Będąc zalogowany na wirtualnej maszynie z zainstalowanym SLES 9 sprawdziłem wydajność dla dwóch dysków: jeden był dyskiem SCSI, a drugi IDE. Sprawdziłem to komendą tego typu:

hdparm -t /dev/hda2

(oczywiście dla dysku SCSI było to /dev/sd2).

Choć z informacji do których dotarłem wynika, że nie powinno być różnic szybkości pomiędzy IDE (EIDE) i SCSI, to jednak z jakichś powodów Vmware zalecało wybór SCSI. Tak czy inaczej postanowiłem spróbować sklonować system z dysku IDE na dysk SCSI. Po pierwsze aby sprawdzić czy wpłynie to na wydajność systemu, a po drugie aby przećwiczyć samą migrację.

Oto kroki, dzięki którym wykonałem przeniesienie systemu. Chociaż dotyczyły one wirtualnej maszyny, to wyglądają tak samo dla zwykłych dysków twardych. Podobnie też z dystrybucją. Mój test dotyczył SLES 9 SP4. Opisana procedura przywracania loadera GRUB może się komuś przydać.

Krok 1
Klonujemy dysk jednym z programów które mamy pod ręką (kiedyś rozwinę ten temat, w tym przykładzie wybór programu nie ma znaczenia).

Krok 2
Uruchamiamy system z dysku instalacyjnego (CD lub DVD) i wybieramy tryb „Rescue„.

Uruchomienie systemu z dysku twardego nie zadziała. W opisywanym przypadku z dwóch powodów:
- dyski SCSI są wykrywane jako /dev/sdX a dyski IDE jako /dev/hdX (W miejscu X mamy kolejne litery: a, b…itd.). Wszystkie wpisy w plikach konfiguracyjnych odnoszą się do /dev/hda , a po zmianie dysku na SCSI powinno być /dev/sda.
- jeśli klonowaliśmy partycję systemową, to nie mamy sektora MBR. Można co prawda klonować cały dysk, ale i tak MBR lepiej zaktualizować.

Krok 3
W trybie Rescue musimy przełączyć się na system, który mamy na dysku twardym. Logujemy sie jako root i kolejno wykonujemy następujące komendy:

mount /dev/sda2 /mnt
mount –bind /sys /mnt/sys
mount –bind /proc /mnt/proc
mount –bind /dev /mnt/dev
chroot /mnt

(oczywiście w tej, jak i każdej dalszej komendzie wartości typu /dev/sda2 zastępujemy odpowiednimi dla naszej konfiguracji wartościami. Przed wykonaniem czegokolwiek warto sprawdzić dyski wykonując „fdisk -l„)

Krok 4
Po przelogowaniu (komenda chroot) musimy przywrócić GRUB. Najpierw próbujemy komendą:

grub-install –no-floppy –force-lba –recheck /dev/sda2

Kiedy jej nie wykonałem (z opcją ‘recheck‘), to komenda w grub „find /boot/grub/stage1” zwracała błąd.

Następnie startujemy komendę ‘grub’ i po uruchomieniu GRUBa wykonujemy:

grub> find /boot/grub/stage1

Wykonanie tej komendy powinno zwrócić wartość typu (hd0,1). Musimy ją zapamiętać i wykorzystać w kolejnych komendach. Oto dalsze komendy przy założeniu, że poprzednia  (find) zwróciła hd(0,1).

grub> root (hd0,1)
grub> setup (hd0)
grub> quit

Załączony poniżej zrzut ekranu pokazuje przykładowe wykonania komendy.

Krok 5
Musimy wyedytować plik /boot/grub/menu.lst w taki sposób, aby wpisy odpowiadały nowej konfiguracji dysku (np. hda2 musi być zastąpione przez /dev/sda2)

Krok 6
Musimy wyedytować plik /etc/fstab w taki sposób, aby odpowiadał konfiguracji dysku. Podobnie jak w poprzednim kroku zmiany najczęściej dotyczą zamiany „hd” (IDE) na „sd” (SCSI).

Krok 7
W tym kroku może okazać się konieczne dopasowanie modułów w pliku /etc/sysconfig/kernel.

Jest to opisane na stronie VMware . Należy wykonać komendę:

modprobe mptscsih

aby sprawdzić czy odpowiedni sterownik jest w systemie. Problem dotyczył starszych dystrybucji, więc nie będę go rozwijał (najlepiej zajrzeć na stronę VMware).

Wykonanie tych wszystkich kroków pozwoliło mi uruchomić SLES 9 na innym dysku bez ponownej reinstalacji systemu. Może się komuś przyda ten opis. Szczególnie w przypadku gdy spędziliśmy wiele czasu aby dostosować system i działające na nim aplikacje i szkoda nam czasu na reinstalację całości.

Tags: vmware