Dotaz: XEN - monitorovací sofware

[warp]

Zdravím,

hledám nástroj, který by mi pomohl detekovat náhlé pády domU na 2.6.26-2-xen-amd64 pod XEN-3.2.1-amd64 (Debian Lenny), které nelze z dostupných logů vystopovat. Máte někdo zkušenosti s tímto? Díky za případně reakce.

Warp

Odpovědi

[Miška]

Nic takoveho neznam, ale ke Xenu se da pristupovat pomoci libvirtd, to by mozna mohlo pridat dalsi vhodny klicovy slovo k vyhledavani...

[VSi]

Pokud na dom0 používáš taky Debian jádro 2.6.26, vykašlal bych se na detekci pádů a zkusil použít jiné jádro. Často se lze dočíst, že stabilita toho 2.6.26 z Debianu jako dom0 je všelijaká.

Momentálně testuji systém v podobě:

- 64bit hypervizor z Debian lenny

- Dom0: Debian lenny 32bit systém + 2.6.27 32bit jádro z Xen Cloud Platform (resp. z Citrix XenServeru)

- DomU: Debian lenny 64bit, jádro 2.6.32 64bit z lenny-backports (obyčejný ne-xen kernel, využívá se pv_ops)

Udajně je kombinace 32bit dom0 + 32/64bit domU nejspolehlivější, něco na tom bude když Citrix to tak má v hlavním produktu - XenServeru.

Můžu poskytnout postup kompilace toho jádra do podoby Debian balíků. Mám to zatím jen pár týdnů v testovacím prostředí s malou zátěží, takže přesnější iformace o stabilitě nedodám. Nicméně stabilita samotného XenServeru je perfektní.

[Lubos Kopecky]

stabilita nejen dom0, ale i domU :( ja sem presel nejdrive na verze mnou kompilovane a nyni mam nasazeny jadra z testingu, kde je pripraveny jadro 2.6.32, a zda se to byt v pohode (zatukavam na drevo).

[kyytaM]

Pri DomU mohla byt urcita vyhoda v tom, ze islo pouzivat standardne vannila kernely napr. (pomocou PyGrubu ci PvGrubu), len tiez museli byt dostacone nove a ta funkionalita pvops vo vannila jadre nieje taka rozsiahla ako v "xenified" jadrach :/ (a tiez je to babracka navyse v mnohych pripadoch).

Je to skratka skoda, ze v Lenny je prave tento 2.6.26 nepodarok. :)

[VSi]

V mém testovacím prostředí používám na domU právě ta "vanilla" jádra (2.6.32 z lenny-backports), která na Xenu běží díky pv_ops. Nic navíc jsem řešit nemusel. Jaká funkcionalita tomu chybí oproti "xenified" domU? Vím jen o USB a PCI passthrough, což na serveru nemá moc využití.

Rozhodně není nutně potřeba nějaký PyGrub, pv_ops jádra jde normálně načítat z filesystemu dom0, stejně jako ta "xenified". PyGrub ale ušetří starosti při upgrade DomU jádra, to je pravda.

[kyytaM]

Ano, nacitat z Dom0 ide rovnako, len som mal osobnu skusenost, ze ked som sa babral s DomU kernelmi a initrd, tak sa mi to robilo prirodzenejsie z prostredia DomU. :)

Myslim, ze tam chyba aj plna podpora balonovania pamate (je len jednosmerne :)), ci PVSCSI.

PCI passtrhu je dobry ked sa virtualizuju napr Asterix riesenia, ci nejaky file/backup server (da sa mu cely scsi raid controller napriklad), pripadne sietovky... :) ), ale je fakt, ze az tak casto sa to nezvykne pouzivat (kedze zatial sa taketo virt. stroje nedaju live migrovat...). Respektive neviem ani ako je na tom SR-IOV funkcionalita vo vannila kerneloch v DomU.

[VSi]

Má PCI passtrhu skutečně tak malou režii a je tak stabilní, že je to OK použít pro RAID controller fileserveru? Máte s tím zkušenost?

Použití pro asterisk popř. nějaké HW klíče beru, to je jasné.

[kyytaM]

Osobnu nie, nezostal mi k dizpozicii HW s IOMMU na virtualizaciu (navali na vsetko nativne Win Ser 2008 a 8 jadra maju vytazenie okolo 0,5%...). Na PV DomU ide pci pass thru aj bez IOMMU, ale na produkciu je to otazne, kedze tymi nicim nekontrolovanymi DMA prenosmi sa da prepisovat hociaka cast pamate (skusal som len virtualny router/bez. branu s PCI pass thru sietovkami na starsom lacnom hw - tam bola limit PCI zbernica a 2 1gbit sietovky na nej, na ktory to narazalo aj bez pouzia pass thru).

Na xen-users mailing liste to viaceri tak pouzivali (casto s openfilerom) - nam konretne vo firme by sa to aj zislo, filserver zbytocne zerie cele zelezo a ma hw problemy - zaroven nie je nevyhnute aby mal 24/7/365 dostupnost - dat na nom nie je az tak vela, zalohuju sa inde a nemaju tie data enormnu hodnotu v tom zmysle, ze by to firma nejako silenjsie pocitila, keby o nejaku cast nahodou z nich prisla (cize v nasom pripade by stacilo pridat lacnejsi radic do uz existujceho virtualizacneho hw a presunut nan disky z existujuceho fileserveru).

Mission critical file server asi takto bastlit nebude optimalne, to uz asi radsej formou klasickej PV DomU s celym raid block deviceom. :)

[VSi]

Příloha:

• i386.mk (3651 bytů)

Jeden člověk mě požádal o postup kompilace Xen Cloud Platform jádra pro Debian. Tady je, zkoušel jsem to jen sám, takže neručím za úplnost/správnost.

Dlaší věc je, že jde o 32bit jádro, takže pokud máte 64bit dom0, použít přímo nepůjde. Přirozeně funguje jen s 32bit dom0. Hypervizor může být 64bit, pak fungují i 64bit domU. Asi by bylo dobré použít i novější domU jádro. Třeba to 2.6.32 z lenny-backports (vychází z testingu).

Kompiloval jsem 32bit jádro na 64bit systému. Ničemu to nevadilo, možná bude třeba použít export ARCH=x86.

Celý postup jsem dělal pod rootem. Vím, že to není správné, ale na testovacím stroji je mi to jedno a neměl jsem čas řešit další problémy, kterých už tak bylo dost (rozbité kpkg skripty).

1) Stáhneme [Source ISO Xen-Kernel (md5): Xen/Dom0 Kernel], bohužel má cca 1 GB, protože je tam všechno možné:

  wget http://www.xen.org/files/XenCloud/Software/latest/sources/source-1.iso

2) Instalace potřebných debian balíků:

  apt-get install rpm kernel-package

3) Upravíme /etc/kernel-pkg.conf - Lze nastavit Maintainer info, popř. další věci

  mcedit /etc/kernel-pkg.conf

4) Připojíme source-1.iso na /mnt/iso, rozbalíme source rpm:

  mkdir /mnt/iso
  mount -o loop source-1.iso /mnt/iso/
  mkdir /root/xcpkernel
  cd /root/xcpkernel
  rpm2cpio /mnt/iso/kernel-dom0/kernel-2.6.27.42-0.1.1.xs0.1.1.737.1065.src.rpm | cpio -idmv
  umount /mnt/iso

5) Rozbalíme zdrojový tarball jádra:

  cd /usr/src

  tar xf /root/xcpkernel/linux-2.6.27.42-0.1.1.xs0.1.1.737.1065.tar.bz2

  ln -s /usr/src/linux-2.6.27.42-0.1.1.xs0.1.1.737.1065/ linux

  cd linux

  cp /root/xcpkernel/kernel-2.6.27.42-0.1.1.xs0.1.1.737.1065-i686-xen.config .config

Upravíme config - je dobré vypnout CONFIG_DEBUG_KERNEL, jinak mají moduly cca 5× větší objem; 'local version append' nenastavovat. Nezapomeneme na konci na uložení do souboru .config.

  make menuconfig ARCH=x86

Pak je tu jeden problém, Debian balík make-kpkg obsahuje kompilační skripty, které nejsou úplně kompatibilní s různými xen jádry (jde přeci jen o patche mimo hlavní řadu). Je třeba upravit soubor /usr/share/kernel-package/ruleset/arches/i386.mk do podoby přiložené k tomuto příspěvku.

Zkompilujeme rovnou do podoby .deb:

  CONCURRENCY_LEVEL=5 make-kpkg --arch i386 --append-to-version .xs0.1.1.737.1065-vsis-generic --initrd --revision 1 kernel_image modules_image kernel_headers

Balíky máme připravené v /usr/src, nainstalujeme je na dom0. Pozor na to, aby se správně vygeneroval initrd. Záznam v grubu může vypadat asi takhle:

title           Xen 3.2-1-amd64 / Debian GNU/Linux, kernel 2.6.27.42-0.1.1.xs0.1.1.737.1065-vsis-generic
root            (hd0,0)
kernel          /xen-3.2-1-amd64.gz dom0_mem=360M
module          /vmlinuz-2.6.27.42-0.1.1.xs0.1.1.737.1065-vsis-generic root=/dev/mapper/vgdeb0-root ro console=tty0
module          /initrd.img-2.6.27.42-0.1.1.xs0.1.1.737.1065-vsis-generic