Debian + Xen = 1 CPU

Virtualizáció

Sziasztok!

Belefutottam egy igen erős problémába amivel már hetek óta szívok hogy megoldjam, de már tippem nincs.
Van egy IBM System X 3550 M4 server két darab Xeon(R) CPU E5-2620 procival.
A problémám az hogy a xen-t felhúzva egyetlen cpu-t lát.
Már sokmindent kipróbáltam, "játszottam" az acpi-vel, mind grub-ba mind bios-ba, számszerint megadtam a dom0 processzorainak a számát a xend-configba, stb, de eddig semmi.
Érdekesség hogy ha xen nélkül indítom a debian-t akkor lát mindent (CPU(s): 24 )

Sajnos ráadásnak óvatosan kell eljárnom mert két éles server (PV) már fut rajta így ha ellövöm akkor baj van.
Van rajta egy HVM is, mellyel alapvetően nincs baj (jelenleg is fut), csak ha azt elkezdjük majd igazán használni (nem csak elfutkorász) akkor ott nagy processor terhelésre számítunk, és ezekkel az adatokkal ezt nem merem még bevállalni)

[ 0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 45
Stepping: 7
CPU MHz: 2000.048
BogoMIPS: 4000.09
Hypervisor vendor: Xen
Virtualization type: none
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 15360K
NUMA node0 CPU(s): 0

Nézelődök egy ideje, de eddig amit talátam az rám nem vonatkozó megoldás volt (acpi=off, stb) És valahol kifejezetten olvastam olyat hogy a System X serianál ilyen előfordulhat, csak nem látom a megoldást.
Találtam egy ilyet is: http://lists.xen.org/archives/html/xen-devel/2012-12/msg01206.html
De őszintén szólva ez nekem kínai (és nem nyelvtanilag, hanem be kell vallanom hogy nem tudom hogy eszik vagy isszák a xen.efi -t azon kívül hogy ott van a /boot/-ba egy ilyen.

Plussz infó a rendszerről:

Linux xyz 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
(Debian Wheezy)

Xen:
release : 3.2.0-4-amd64
version : #1 SMP Debian 3.2.54-2
machine : x86_64
nr_cpus : 1
nr_nodes : 1
cores_per_socket : 1
threads_per_core : 1
cpu_mhz : 2000
hw_caps : bfebfbff:2c100800:00000000:00003f40:13bee3ff:00000000:00000001:00000000
virt_caps : hvm
total_memory : 32740
free_memory : 31874
free_cpus : 0
xen_major : 4
xen_minor : 1
xen_extra : .4
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : unavailable
xen_commandline : placeholder acpi=off dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin (<-ezt nem rég szabályoztam le az itt láthatóra)
cc_compiler : gcc version 4.7.2 (Debian 4.7.2-5)
cc_compile_by : carnil
cc_compile_domain : debian.org
cc_compile_date : Sun May 5 14:44:49 UTC 2013
xend_config_format : 4

Van esetleg valami ötletetek?
Köszi.

  • 6319 megtekintés

( wpeople v | 2014. 03. 14., p – 07:27 )

Nem lehet, h csak a dom0 van 1 cpu-ra limitalva?

( _ventura_ v | 2014. 03. 14., p – 08:14 )

Esetleg a https://wiki.debian.org/Xen

Itt azt írja hogy dom0_max_vcpus=4 a /etc/defaul/grub ba, majd update-grub

Amúgy miért gond ha a dom0 1 cpu-t lát csak? Ott kb egy ssh-nak kell esetleg snmp pár lap cucc.

Fedora 20, Thinkpad x61s

Nem ismerem a xent, de annyi rémlik, hogy a dom0 az a "host".
Rosszul tudom? (Ok., nem teljesen azonos mondjuk a virtualbox hosttal, de közelítőleg hasonló a funkciója)
Ha ezt jól tudom, akkor szerintem elég nagy baj, ha épp ő nem lát minden hardver elemet.
Így hogy tudja elosztani a processzor(mag)okat a domU-k között?
Lehet, hogy alaposabban utána kellene néznem a működésének?

Nem a xen teljesen más architechtúra. A dom0 is hasonló VPS mint a többi, csak rendelkezik pár plusz feladattal mint a mangement + driverek. Attól ő látja a többi CPU-t is. Igaz jó pár éve xenservert használok, ott a dom0 4 cpu-t kap. Egy xl/xm top ban látszania kell az összesnek pl:

Mem: 201255384k total, 148778848k used, 52476536k free CPUs: 24 @ 2926MHz

Fedora 20, Thinkpad x61s

( powermate | 2014. 03. 14., p – 08:40 )

Jelenleg valóban limitálva van, de limit nélkül se látja.

Igazából nem lenne gond, csak valószínűnek tartom hogy ha mindent látnia kéne és ezt mutatja akkor használni se tudja őket szerintem (csak egy processornak egy magját), így a Guest-ek se szerintem. Ugyan beállítottam például a hvm-nek hogy 6 cpu-ja van és annyit is mutat, de erős a gyanúm, hogy a fizikainak csak azt az egy magját használja hozzá (néhol el-el tűnik egy-két pingem is, randomra a dom0-on és a guest-eken egyaránt, de nem egy időben, és ez nekem szintén erre utal, pláne mivel nincs icmp_redirect-em, a hosting pedig jó így mást nem tudok ami okozhatja.

Nekem is kernel szintűnek tűnik a probléma, ezért vagyok tanácstalan. A fenti linken azt olvastam hogy a grub-ot kéne kiejtenem esetleg a "buliból", de egyrészt ezt nem tudom hogy tegyem, másrészt mivel fut ratja két aktív serverem így elég bátortalan is vagyok, mondván hogy egy szép napos reggelre riadva elszúrom a boot-ot és nem fog elindulni és kezdhetek kapálózni.

UPDATE:
érdekes, éjjel egyébként lekorlátoztam a dom0 cpu-ját és memoriáját, valamint hasraütés alapon nyomtam egy apt-get upgrade-et ahol is egy-két xen-es dolgot is frissített mással együtt, azóta nem látok elveszett pinget, így ezt a kijelentést az imént lehet visszavonnám.

( powermate | 2014. 03. 14., p – 08:52 )

xm top

NAME STATE CPU(sec) CPU(%) MEM:* MEM(%) MAXMEM:* MAXMEM(%) VCPUS NETS NETTX:* NETRX:* VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID
Domain-0 -----r 671 2.8 15194120 45.3 no limit n/a 1 3 406878 44438 0 0 0 0 0 0 0
Server1 --b--- 937 1.7 1048576 3.1 1048576 3.1 1 0 0 0 2 0 8217 26762 243362 468432 0
Server2 u --b--- 777 2.1 16781268 50.1 16781312 50.1 6 0 0 0 2 0 0 0 0 0 0
...

Egy egy héttel korábbi dmesg-em (csak mert már kicsit szétberheltem a boot-ot azóta, de nem sokkal másabb):

[ 0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs
[ 0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 28 pages/cpu @ffff8807dfc00000 s82944 r8192 d23552 u2097152
[ 4.448523] installing Xen timer for CPU 0
[ 4.469258] CPU: Physical Processor ID: 0
[ 4.469259] CPU: Processor Core ID: 0
[ 4.481367] Performance Events: unsupported p6 CPU model 45 no PMU driver, software events only.
[ 4.481513] Brought up 1 CPUs

nekem egy olyan gépen ahol a Dom0 CPU korlázozva van:
xm dmesg:
(XEN) Processor #0 7:10 APIC version 21
(XEN) Processor #4 7:10 APIC version 21
(XEN) Processor #2 7:10 APIC version 21
(XEN) Processor #6 7:10 APIC version 21
(XEN) Processor #1 7:10 APIC version 21
(XEN) Processor #5 7:10 APIC version 21
(XEN) Processor #3 7:10 APIC version 21
(XEN) Processor #7 7:10 APIC version 21

dmesg|grep CPU:
[ 0.000000] SMP: Allowing 1 CPUs, 0 hotplug CPUs
[ 0.000000] NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:1 nr_node_ids:1
[ 0.000000] PERCPU: Embedded 30 pages/cpu @ffff8800035b5000 s90328 r8192 d24360 u122880
[ 2.383065] Initializing CPU#0
[ 2.410032] SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 2.419858] installing Xen timer for CPU 0
[ 2.420555] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 2.420558] CPU: L2 cache: 256K
[ 2.420559] CPU: L3 cache: 8192K
[ 2.420563] CPU 0/0x0 -> Node 0
[ 2.420565] CPU: Unsupported number of siblings 16
[ 2.420569] mce: CPU supports 9 MCE banks
[ 2.420591] Performance Events: unsupported p6 CPU model 26 no PMU driver, software events only.
[ 2.448006] Brought up 1 CPUs
[ 2.448018] CPU0 attaching NULL sched-domain.

IMHO a magok megvannak, csak a DomU-k részére "félretéve".

( uid_2716 | 2014. 03. 14., p – 09:22 )

A levlistán található info azt jelenti, hogy a UEFI setup-ba belépve, vagy az efibootmgr-t használva, be kell állítanod egy olyan UEFI boot option-t (és később majd azt kell boot-olnod), amely a grub2 UEFI alkalmazás helyett a "xen.efi" nevezetű alkalmazást indítja el. Lényegében meg kell változtatnod a boot loader-edet.

Erre jó eséllyel azért van szükséged, mert a UEFI boot firmware-ed valami olyan jellegű információval rendelkezik a rendszered többprocesszoros mivoltáról, amelyet a grub2 UEFI alkalmazás elér(hetne) ugyan, de nem továbbít a Xen hypervisor-nak. A "xen.efi" ezt az információt bizonyára lekérdezi, és továbbadja a Xen-nek.

Arról, hogy a xen.efi-t hogyan kell konfigurálni (vagyis hol fogja megtalálni a Xen hypervisor binárist), természetesen fogalmam sincs. A grub2-nek ugye van saját konfig file-ja (az EFI system partition-ön), vannak saját filesystem driver-ei (amelyekkel a Xen ill. kernel image-et, illetve az initrd-t be tudja húzni pl. ext4-ről).

Nem elképzelhetetlen, hogy a xen.efi már maga a hypervisor image, UEFI alkalmazássá fordítva, amely maga hívja meg az ExitBootServices()-t (a kernel EFI stub-jához hasonlóan, ha olyat fordítasz).

Hm, itt található egy leírás a xen.efi használatáról: http://xenbits.xen.org/docs/unstable/misc/efi.html

Tehát összefoglalva:

  • efibootmgr-rel vagy a géped gyári UEFI setup-jával ("bios setup" lényegében) felveszed a xen.efi-t első helyre a UEFI boot opciók közé,
  • A xen.efi-t bekonfigolod a fenti linken található leírás alapján (xen.cfg-t a xen.efi bináris mellé, ugyanabba a könyvtárba). A megadott kernelnek és initrd-nek nagyon valószínű, hogy szintén az EFI system partition-ön kell lennie; a xen.efi jó eséllyel nem rendelkezik saját filesystem driver-ekkel és csak a UEFI service-eket tudja használni a file-ok betöltéséhez.

Nagyon köszönöm a leírást. Segített jobban megértenem a boot cserét. Sajnos ezt a megoldást jelenleg nem áll módomban kipróbálni, mind a témakört érintő tapasztalat hiánya, mind a server éles mivolta miatt. Teszt környezet sajnos nem áll rendelkezésemre amit nyugodtan hazavághatok, miközbe kipróbálom.

Egy szakmabeli kedves ismerősöm igazából annyit fűzött a jelenséghez hogy: "Megnézném, hogy a guest milyen teljesítményre képes függetlenül attól hogy mit tud magáról (mondjuk 1 és 6 vcpu esetén)".

Ezen fellelkesedve elkezdtem gyilkolni rajta az egyik 6 VCPU-s HVM-et (elég nagy sql műveletekkel) látszólag meg se kottyant neki (míg egy másik hasonló hvm egy másik serveren ennél a műveletnél már visit), ám más rajta futó szolgáltatásba eközbe érződött némi minőség romlás. Majd ezután jött a feketeleves:
Aida CPU test.

Na ez volt az a pillanat mikor is a Zabbix elkezdett nyeríteni, a teljes dom0-on megugrottak a pingek (átlagosan csak 4 ms-el kivéve az érintett hvm ott 30-40). És itt már nem volt más belátható időn belül ható megoldás, csak az xm destroy.

Sajnos ez az a pont ahol már nem tudom hogy mit gondoljak.

( powermate | 2014. 09. 29., h – 21:50 )

Rég jártam erre pedig azóta van fejlemény, ami ugyan nem derítette ki a problémát, de megoldotta.

Nem megyek bele mennyi mindennel próbálkoztam, legyen elég annyi hogy ami csak a létező xen-es fórumokon vagy bárhol fellelhető mindent kipróbáltunk.
A grub-ot átparamétereztem, a xend configokat átírtam, a különböző frissebb debian alapú disztribúciókat sorra kipróbáltam.
Míg nem, eszembe nem jutott hogy nézzük meg hogyan viselkedik egy Squeezy-vel (a rajta kipróbált rendszerek mind Debian 7.x illetve ubuntu 12.04 < )

A squeezy és a hozzá tartozó xen telepítése után jött a csattanó, hoppá lscpu: CPU(s) = 24
Na ekkor jött az hogy nézzünk rá egy dist-upgrade -et.
Az upgrade megtörtént, a végeredmény: Debian 7.6 kernel 3.2 Xen 4.1 = 24 cpu
Az ok nem teljesen tiszta, feltételezhetően a másik korábbi grub oldotta meg (mivel különösebb paramétert nem kapott, a rendszer pedig végül ugyanúgy a legfrissebb lett.