[MEGOLDVA] CentOS 7 vmware -> xen

Fórumok

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).

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?

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.

'qemu-img' lesz a barátod, az rendesen átkonvertálja akár a VMware-es image-eket is...

--
zrubi.hu

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/

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

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 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 :-)