Sziasztok!
Kaptam néhány VMDK és VMX fájlt, amelyek vmware alatt futtathato CentOS rendszereket tartalmaznak. A feladatom az, hogy Xen alatt futtassam őket. Feltettem a gépemre egy VMWare playert, amin hiba nélkül fut egy ilyen virtuális gép.
A disk image típusa RAW, ezért könnyedén blokkeszközzé alakítottam a loop driver segítségével, majd a kpartx paranccsal elérhetővé tettem a rajta levő partíciókat, végül aktiváltam a rajta levő LVM köteteket, és fel is tudtam mountolni őket, hogy körülnézhessek a rendszeren. Chroottal indítottam egy shellt a rendszeren, és megpróbáltam új initrd-t létrehozni, amely tartalmazza az ata_piix, valamint a xen hálózati és block drivert. Ezután mindent lemountoltam, megpróbáltam bebootolni Xen alatt.
Úgy tűnik, nem jártam sikerrel az említett driverek initrd-be integrálásával, mert mind HVM üzemmódban indítva (ehhez kellett az ata_piix driver), mint PV üzemmódban indítva bebootolt ugyan a kernel, és elindult az initrd-ben levő rendszer, de nem találta a harddisket, tehát a root fájlrendszer mountolása előtt elakadt a boot folyamat.
A kérdésem az, hogy egyáltalán milyen kernelre van szükségem a CentOS 7 Xen domU-ban történő futtatásához? Megfelel a VMWare környezetben használt 3.10.0-229.7.2.el7.x86_64, vagy le kell cserélnem egy kifejezetten Xen domU rendszerhez való kernelre. Ha igen, hogyan? Ha nem, hogy tudom beintegrálni a megfelelő Xen specifikus drivereket (kernel modulokat) a kernelbe. (Sajnos nem vagyok jártas a dracut és a grub2 világában.)
############# SZERK. 2015.09.11.:
Az elejétől fogva jól gondoltam, hogy a problémát az okozza, hogy pár xen domU specifikus driver hiányzik az initramfs-ből. A megoldás:
A RAW image-et blokkeszközzé alakítottam a loop driver segítségével, majd a kpartx paranccsal elérhetővé tettem a rajta levő partíciókat, végül aktiváltam a rajta levő LVM köteteket, és felmountoltam őket, valamint --bind mounttal a /proc
, a /sys
és a /dev
könyvtárakat is aktiváltam a vendég rendszeren. Ezek után chroottal indítottam egy /bin/bash
shellt az összeállított rendszerben, és újrageneráltam az initramfs-t, hogy benne legyenek a szükséges driverek. Ezt úgy értem el, hogy a /etc/dracut.conf
fájlba felvettem a add_drivers+="xen_blkfront xen_netfront"
opciót, majd a dracut paranccsal újrageneráltam az initramfs-t. Ezután a /etc/dracut.conf
fájlon eszközölt módosításokat már vissza lehet vonni, mert a Xen-en futó rendszer már külön utasítás nélkül is rájön majd, hogy szüksége van ezekre a driverekre.
Az initramfs újragenerálása után kiléptem a chroot shellből, lemountoltam a vendég fájlrendszereket, lebontottam a RAW image-re épülő LVM blokkeszköz-fát, kpartx-szel eltávolítottam a partíciókat, majd magát a loop eszközt is, hogy semmilyen virtuális blokkeszköz ne használja az image fájlt. Ezek után létrehoztam egy PVHVM típusú virtuális gépet az image-hez. Ez azonnal teljesen működőképes volt, leszámítva a soros konzol (xm console
) hiányát. Ezt úgy oldottam meg, hogy a virtuális framebufferen futó virtuális konzolba belépve kiadtam az alábbi parancsot:
systemctl enable serial-getty@ttyS0.service
Ezzel elértem, hogy a következő bootoláskor a Xen által biztosított virtuális /dev/ttyS0
soros porton is hallgatózzon egy getty. Ugyanez a rendszer egyébként teljesen paravirtualizál módban (PV) is elindul, amikor mindenféle trükközés nélkül azonnal működik az xm console
típusú hozzáférés a /dev/hvc0
paravirtualizált porton keresztül, azonban a CentOS kernele nem támogatja a paravirtualizált framebuffert, tehát nem lesz VGA konzolunk, viszont minden más tökéletesen működik (leszámítva, hogy a PV üzemmód rosszabb teljesítményt ad, mint a PVHVM).
- 1867 megtekintés
Hozzászólások
"nem találta a harddisket, tehát a root fájlrendszer mountolása előtt elakadt a boot folyamat."
Nem lehet csak annyi a problema, hogy maskent nevezi el a diszkeket (sda vda xvda stb.) es ezt kellene modositani az ujra?
- A hozzászóláshoz be kell jelentkezni
Az initrd-ből elindul egy kis rescue rendszer-szerűség, abban megnéztem, hogy létrejött-e a /dev könyvtárban sda*, hda* vagy xvda* nevű blokkeszköz, de nem. És ennek a kis rendszernek a /lib/modules könyvtárába is benéztem, és sajnos nem voltak benne azok a driverek, amiket a dracut --add-driver paranccsal be akartam tenni. Pedig maga a parancs lefutott a VMWare-en, és az initrd-t is újragenerálta egyébként.
- A hozzászóláshoz be kell jelentkezni
'qemu-img' lesz a barátod, az rendesen átkonvertálja akár a VMware-es image-eket is...
--
zrubi.hu
- A hozzászóláshoz be kell jelentkezni
Az image formátuma jó. A benne levő kernelt és initrd-t kellene "konvertálni".
- A hozzászóláshoz be kell jelentkezni
Sztem nem kell itt konvertálni ha tényleg raw. Max átnevezni .vmdk-ról .img-ra
VMware playerbe nézd meg a vm / partíciójának a blockeszközét, annak tipusát(sda,hda,vda,xvda,stb.)
Tegyük fel, hogy hda, akkor csinálsz egy standard hvm konfigfájlt a xennek és beleteszed így:
disk = [ ‘file:/vms/vm1/vm1.img,hda,w’ ]
http://wiki.xenproject.org/wiki/Migration_from_VMware
--------------------
http://grant-it.com/
- A hozzászóláshoz be kell jelentkezni
Ez megvan, be is indul Xen alatt a boot folyamat, csak a kernel és az initrd "nem teljesen" kompatibilis a Xen környezettel.
- A hozzászóláshoz be kell jelentkezni
Egyébként már korábban megnéztem, és a qemu-img megerősítette, hogy a file formátuma RAW.
- A hozzászóláshoz be kell jelentkezni
Ha van köztetek valaki, aki CentOS 7-et futtat paravirtualizált Xen domU-ban, meg tudná írni, hogy milyen kimenetet ad a szóban forgó rendszeren a következő parancs:
uname -r
- A hozzászóláshoz be kell jelentkezni
Ha már bebootol a kernel, az már biztos, hogy jó. Már nagyon rég óta nincs külön DomU kernel, szinte biztos, hogy nem ott van a baj.
Ezt futtattad?
dracut --add-driver ata_piix --force
Biztos az a kernel/initrd bootolt a xen alatt, amelyiknek újrageneráltad az initrdjét?
- A hozzászóláshoz be kell jelentkezni
OK, jó úton jártam, és sikerült további eredményeket elérnem: Ha nem parancssorban adom ki a dracut-nak, hogy milyen kernel modulokat rakjon az initrd-be, hanem beírom a /etc/dracut.conf-ba, az hatásos. Már sikerült is bebootolni paravirtualizált domU módban, viszont sajnos nem minden Xen specifikus eszközt talál meg :-( A framebuffer pl. nem működik, úgyhogy soros konzolról kell menedzselnem. Azt viszont kapásból lekezelte a CentOS.
- A hozzászóláshoz be kell jelentkezni
Soros konzol úgyis csak addig kell, amíg az ssh-t beállítod :D
- A hozzászóláshoz be kell jelentkezni
A soros konzol (`xm console` vagy `xl console`) működik PV módban, de akkor nincs framebuffer, HVM módban viszont van framebuffer, de nincs soros konzol. Illetve van, de nem /dev/hvc0-n, hanem /dev/ttyS0-n. Viszont amint látom a Xen tudásom felett elszállt az idő, és már nem a PV, hanem a PVHVM mód a nyerő (http://wiki.xen.org/wiki/Virtualization_Spectrum), amihez a HVM móddal majdnem megegyező konfigurációt kell készíteni: http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers
Tulajdonképpen nincs más teendő egy RAW image VMWare-ről Xen-re migrálásánál, mint biztosítani a xen_blkfront és a xen_netfront driverek betöltődését, és engedélyezni egy getty-t a /dev/ttyS0 porton, majd PVHVM üzemmódban elindítani a rendszert, ami így még gyorsabb is lesz, mint egy hagyományos PV domU :-)
- A hozzászóláshoz be kell jelentkezni
Problem solved :-)
- A hozzászóláshoz be kell jelentkezni