XCP-ng

Fórumok

Előzmények
Citrix XenServer 6 (2011-es topik)
Citrix XenServer 7 (2018-as topik)
mintájára problémák, tapasztalatok összegzése.

Kb 2011 óta használok XenServert, azóta megragadtam a 6.5-ös verziónál, mert alapvetően bevált, de hiányzik hozzá egy rendes webes gui, nem alulról tákolt backup/restore megoldás.

Többen említettétek a XCP-ng, mint ígéretes forkot.
Ki használja éles üzemben, milyen gyermek betegségei vannak, amire figyelni kell?
Illetve hogyan lehet beizzítani a web guit ingyenesen? A https://xen-orchestra.com erősen a fizetős irányba terelne.
Ha nem ez, milyen más web gui adott hozzá, akár fizetős is.

Hozzászólások

Szia!
Én csak kipróbáltam, de nem volt különösebb gondom a management programmal, jobban szeretem azt.
A felületét nem tudtam megszokni (lehet nem is akartam), nekem nem jött be az a design.
XCP-ng-vel használtam, de gondolom XenServer-rel is ugyanúgy fog működni. Ami hibát észrevettem: nálunk 2 Hypervisor van, egyik az éles, másik a backup. Minden nap készül backup mindegyik virtuális gépről, elmenti egy hálózati storage-ra, majd a backup törli a rajta lévőt és felhúzza az újat. Na az ilyen módon "duplikált" (ugye 1 példány éles, 1 meg off a backupon) gépek nekem elég furán jelentek meg a felületen.. Valamikor mindkettőt láttam, valamikor csak az egyiket, de akkor teljesen kuszán mutatta az adatait.. mondjuk ha csak az offline-ost mutatta és én ráböktem, hogy akkor induljon el, akkor jött a hibaüzenet, hogy már fut - mert a futót akarta elindítani. Nem foglalkoztam vele, mert amúgy is jobban tetszik a gyári management program.
Ingyenes verziót tudsz magadnak forgatni, de mindig piszkálni fog, hogy fizess elő, engem ez is zavart.

Szia!
Bocsánat, kicsit elkevertem a neveket (új még nekem), szóval az XCP-ng-re gondoltam alapból, mint XenServer forkra. (Át is neveztem a topikot erre.) A xen-orchestra kizárólag a felület, oké, ez most leesett :)

Én is felraktam tesztelni az XCP-ng-t és a hozzá adott "xencentert", ami kezeli az új XCP-ng teszt szervert és a meglévő 6.5-s XenServereket is. Mi készíti nálad minden nap a backupot? Mi duplikálja le? Én neten találtam anno egy scriptet, ami backupot készít sn_VMnév néven, így rögtön tudtom, hogy az sn_, mint snapshot a mentés és visszaállításkor (xe vm-import) is sn_VMnév névvel jön létre, igy nem keverem össze. Ez a script dolgozik évek óta és egy felcsatolt NFS-re tolja.

Ingyenes web gui verziót hogy tudsz magadnak forgatni?

Backupot script csinálja, nagy vonalakban így:
export
xe vm-snapshot vm=$VM_NAME new-name-label=$VM_NAME new-name-description='Generated @ `date +%Y-%m-%d_%T`'
xe template-param-set is-a-template=false uuid=$SNAPSHOT_ID
xe vm-export vm=$SNAPSHOT_ID filename=$DEST_PATH/$FILE_NAME-exported.xva
xe vm-uninstall uuid=$SNAPSHOT_ID force=true

import
xe vm-uninstall vm=$VM_NAME force=true
xe vm-import filename=$DEST_PATH/$FILE_NAME-exported.xva preserve=true

Ezeket csak kimásolgattam a scriptből, ez a lényegi része, többit hozzá tudod írni (kilépjen, ha hiba van; csak exportáljon; küldjön emailt; stb). Gondolom a tiéd is hasonló :)

Web gui: Szerintem hasonló módon csináltam én is, de már nem emlékszem pontosan: https://www.youtube.com/watch?v=lf_tNVomBcE

Mi nagyon sokáig használtunk XenServer-t és XCP-t is, elégedettek voltunk vele.
De szerintem nagyon eljárt felette az idő.
Maga XEN jó, stabil, megbízható, szerintem a teljesítménnyel sincsen gond, de a körités az már kevésbé.
A backup az egyenesen körülményes és erőforrás pazarló.

3+ éve átmigráltunk majdnem mindent Proxmox-ra, fényévekkel jobb a kezelhetősége.
Linux-oknak konténeres virtualizáció, ZFS adta backup lehetőséget, normális cluster működés, etc ....
KVM + windows VM-ek telepítésénél 1-2 dologra oda kell figyelni, de windows guest-ekkel sincsen gond.
Ha akarod veszel hozzá supportot is.
Jelenleg CEPH-el teszteljük komolyabb cluster reményében.

A migráció 1xű, export -> import (driverek)

Írom mindezeket úgy hogy van ügyfelünk akinél még 5.6-os XenServer fut! És pont upgrade-elni kell, mert 5.6-hoz nem lehet már Citrix-től licencet kérni. (5.6 még licenc köteles volt)

XenServer 5.6-tal kezdtem én is, az még kicsit bugos volt nálam.
Proxmox-szal illetve libvirtes KVM-en én is gondolkoztam, de még nem billentem át:)
A CEPH milyen peformanciád ad? Nyúztátok már rendesen? Mert amikor sok virtális gép terheli, félek kevés lesz.
Milyen admin felületet tudsz az ügyfelek kezébe adni?
Hogyan mentesz Proxmox alól? Ott is ugyanolyan erőforrás pazarló gondolom, mint XenServer alól. Le kell másolni a image-ket/LVM köteteket snapshot formájában a diszkről, ami idő és i/o.

hivatalos webes guiban lehet user letrehozni, ahhoz jogokat es vmhez rendelni. de van rest api, irhatsz hozza sajat guit ha akarsz.
backup block szinten megy, sajat progijuk van ami a spare blokkokat nem tarolja. ha ez nem jo megoldas, akkor fogod a kedvenc backup progidat, es az OS-bol mented amit akarsz.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

CEPH-re nincsenek még számok, egy 4 gépes dedikált CEPH clustert rakunk most össze első körben egy Nexus 3K-val.
Arra vagyunk kíváncsiak 4 gépnél mire elég a 10G, valószínűleg kevés lesz. Proxmox CEPH managment-re vagyunk még kiváncsiak.
A cél storage kiváltási lehetőségek tesztelése, egy 4(+) gépes CEPH clusterrel már ki lehet váltani egy storage-ot redundáns módon. (két switch-el)

Admin felületet sehol nem kellett még kiadnunk, így erről nem tudok nyilatkozni.
De proxmoxnak nagyon jó a CLI-je, mi az esetek 70%-ban azt használjuk, GUI-t inkább csak console-hoz használunk.

Ha ZFS storage-et használsz proxmox alatt, akkor block szinten tudsz backupolni, erre van több megoldás is. Tehát tudsz akár óránként is inkrementális mentést végezni a guest-től.
Természetesen ez rész backup megoldás, DC, SQL, etc .. mentésére nem alkalmas önállóan. De ha pl. le tudod az adott VM-et állítani éjjel, akkor is mehet egy sync, és máris van egy fullos offline backupod, ami VM oldalról nézve egy restart ideje alatt megvan. (VM leáll, snapshot, VM indít snapshot inkrementális sync).
Mivel a backupok ZFS-ből mountolhatóak, akkor és azt veszel elő amit csak akarsz.
pl.
500Gb-os Terminal Serverről az első mentés alkalmával megcsinálod a "sync"-et, majd adott időközönként (akár 2 óránként) megy ZFS-el az különbözeti sync, ez normál esetben 1-2 perc alatt megvan.
pve-zsync-et érdemes megnézni.

En tesztelgettem anno, igazabol nem volt vele gond, de eles hasznalatra en nem ajanlanam, foleg windows VM-eknek. Nincs normalis Guest tools, nekem is a Citrix xenserver guest tool-jat kellett kibanyaszni ISO-bol, azzal volt viszonylag normalis driver pack...

Managementhez a legegyszerubb sztm ez a docker image: https://hub.docker.com/r/ezka77/xen-orchestra-ce Nem kell forditgatni, etc...

vagy: https://github.com/xcp-ng/xenadmin/releases (bar ezzel pont a plusz feature-ok vesznek el)

Eles hasznalatra inkabb Proxmox sztm, vagy Ovirt (clusterhez, bar az ujabb Proxmox verziokkal mar a cluster kepesseg is szepen jon fol), Ha meg fizetos, akkor vmware, azzal van a legkevesebb gond :)

proxmox már clusterre is kb. tökéletes.
Ha van közös storage, akkor HV kiesés esetén, szépen indul is másik HV-n (ha van még szabad erőforrás).

De közös storage nélkül is, van lehetőség replikációra, ami pl. 5/10p-s replikációval simán indul ha gond van. Persze nem egy DC, vagy egy hajtott SQL esetén, de pl. egy webszerver simán elfog replikából indulni.

Szia,

> Managementhez a legegyszerubb sztm ez a docker image: https://hub.docker.com/r/ezka77/xen-orchestra-ce Nem kell forditgatni, etc...

gyors kérdésem lenne: ezt magán a hipervigyoron (vagy hoston) indítod el Docker-ben, vagy csinálsz neki egy dedikált linux VM-et? Esetleg kliensgépen futik? :) Az első két esetben mekkora erőforrásigénnyel (főleg RAM) kell számolni?

Köszi,

Sanyi

Sok éves tapasztalat szerint hypervisoron kb ssh meg a hypervisor fusson, vagy ami kell a managementhez fenti esetben xenapi. Semmi esetben se tennék rá egy docker-t, meg mást se :>

1x futtattam rajta NFS szerver-t, a rajta futó VPS-eknek legyen afféle backup, de rájöttem jobban járok, ha azt a disket amit NFS-re szántam odaadom egy VPS-nek, és az NFS-ezik.

Szóval a suszter maradjon a kaptafánál :D Szerintem.

Nekem a XOA mindig VPS-en fut 2G rammal, régebben voltak memória gondjai (leak), de már jó ideje elég stabil. Annak ellenére is, hogy a kezdetektől magamnak buildelem (szeretem ha minden funckió megy :D)

Fedora 38, Thinkpad x280

A xenserver-t 5.5 ota használok. A xen-orchestrát is az első publikus verzió óta használom, legjobb webes cucc :> A windowsos management program réges rég el van felejtve. Természetesen magamnak buildelem így megy minden feature. Éles szerveren még 7.2 es xenserver fut ugyanis ez az utolsó olyan amiben még jó pár feature ingyenes, tervezve van a XCP-ng-re váltás, de mindig van más fontosabb dolog :D

Természetesen futnak XCP-ng telepítések is nincsen azokkal se gond, talán annyi hogy a windows driver hiányzik belőle, de azt be lehet szerezni máshonnnan.

Fedora 29, Thinkpad x220

Tesztelem az XCP-ng-t 2 hoston. Egyelőre pozitív a tapasztalat. A referenciám XenServer 6.5.
Újdonságnak látom, hogy hostok között tudok másolni/áthelyezni leállított VM-et, így végre az export->import közé nem kell egy köztes tároló. Ja igen, local diszkekkel dolgozok, nincsen közös storage.
A live migration itt is jól működik 2 host localdiszkjei között.
Ami még újdonság, van live-migration force, ami akkor is végigmegy, ha eltérő a host verziója, CPU-ja a célhoston butább.
Tolja, a végén az eredeti hoston pause, célhoston off. Kicsit erős így, az fsck lefut, ha elindítom az átrakott VM-et, de legalább átmegy. Ha a hostok CPU-ja egy családból való, megy nyugisan a live vagy off állapotban a move.
A 2 teszt hostot most egy poolba szerveztem, de közös storage nélkül nem látok új menüpontot.
Származik bármi előnyöm a poolba szervezésből, ha nincs közös storage?

Talán már a 7.0 xenserverben is ment a live migració is közös storage nélkül is.

Ha használsz vlanokat akkor elég a pool-ra felvenni pl. Így hirtelen ennyi értelmét tudom, ha nincsen közös storage.

Most upgradelek egy pool-t 7.5 ről 7.6 ra sima yum update-el remélem jó lesz :D

Fedora 29, Thinkpad x220

A live migration közös storage nélkül már 6.5-ben is ment szépen. Előszeretettel használtam :)
A VLAN-ok tényleg átjöttek poolon belüli hostokra, apróság, de kényelmes 8 VLAN legalább van.
A yum update-t én is olvastam. Ha jól fog működni, szépen megvalósítja a rolling updatet.

Lezajlott gond nélkül, igaz 7.5 ről toltam 7.6 ra. Most legalább tesztelem, hogy megy-e a Nested Virtualization. Mert eddig csak dom0 reboot ot kaptam, valszeg most lesz másképp :/ Egy próbát megér.

Hát öö a 7.6 eddig elég szar :/

1-2 hoston magában futott a 7.6, de volt olyan mikor a xapi valahol elvesztette a fonalat. Viszont most még egy live migráció se biztos hogy lefut, berag stb. Viszont így nem tudok visszamenni 7.5-re, mert a yum update nem csinált backupot :/ Nahh remélem a 8asban javítják ezeket a bugokat.

Fedora 29, Thinkpad x220

CD-ről telepítve a 7.6 problémamentes 1 hónapja.
Most cd-ről telepítettem a 8.0 -t mivel főverziókat nem lehet yum segítségével frissíteni. Ez 1 napos.
Ami szívás: A 8.0-s XCP-ng-t csak a 8.0 által szállított xencenterből tudod használni.
Viszont a 7-es előtti XCP-ng-ket és a régi citrix xenservereket nem tudod ebből kezelni. Nekem még átmenet van citrix és XCP-ng között, szóval 2 helyről fogom addig kezelni.

Verziófüggetlenül: a live migration sebessége beáll kb 50-60Mbyte/s -re 1Gbit/s-es hálón. Ha 2 VM-et mozgatok egyszerre, akkor kikoppantja a 1Gbit/s-t. Nem értem miért korlátoz kb sávszélesség felére, ha 1VM-t mozgatok. Direkt közvetlen kábellel kötöttem össze a 2 gépet, hogy ne az éles hálózatot terheljem.

downgrade: én mentem a dom0-t is rsync-kel, így ha máshogy nem oldható meg egy elfuserált upgrade visszaállítása, akkor idracból felcsatolnék livecd és visszamásolnám a rendszerájlokat. Hála égnek eddig nem kellett.

Szerkesztve: 2019. 11. 06., sze – 11:52

Arról ki mit tud, hogy NUMA-t mikor fog tudni?

Tehát amikor van egy több fizikai processzoros host, azoknak van hozzájuk tartozó memória (modul), akkor ha a VM az 1-es CPU-n fut, akkor ne a 2-es CPU-hoz tartozó memóriába pakolja magát.

Nézem a 2 fizikai processzoros, 48 logikai magos szerveren a xl vcpu-list paranccsal, hogy hol fut az adott VM és bizony 0-47 között mindenhol előfordul legalább másodperces vándoroltatással.

Értem, hogy szét akarja kenni a terhelést, de így baromságnak látszik.

Aztán lehet bindelni adott VM virtuális CPU-ját adott logikai maghoz, de ha van 100 VM 48 logikai magra, akkor 1 magrara 2 VM tuti kerül. Ha épp egyszerre akarnak dolgozni, szívás.

Megadhatod, hogy először 0-23 logikai magot adja oda az 50 VM-nek, a maradék 50 VM-nek meg 24-47-ig, és így szét tudja kenni a terhelést, de ekkor is az a felhasználói visszajelzés, hogy esik a tempó. Nem az igazi. És úgy tűnik, minél nagyobb a logikai max szám, annál rosszabb performanciád ad ez az egész. 

VMware környezetben azt mondták nem vándoroltatja ennyire a vCPU<-->logikai CPU összerendeléseket, csak ha egyik izzad, másik tétlenkedik, akkor odébb "bindeli" automatikusan, amúgy marad ott, a memóriához közelebbi RAM-nál és állandó CPU-n.

Ilyesmire igen. Ezt a poolozást nem láttam még, megvizsgálom, de azt hiszem kevés lesz.

A klasszikus NUMA úgy működik máshol (KVM, VMware), hogy VM indításkor rákattan egy logikai magra és egy közeli memória területre és ha nem muszáj, nem ereszti.

A binding a fentinek a kikényszerítése adott magra. Ezt a kikényszerítést tudja a XenServer/XCP-ng, az automatikusat nem tudja. Így tapasztalom én is, és a neten is ezt olvastam, hogy sajnos ez a feature nem érhető el xenen.

Nahh de ez miért is jó ?

Úgyértem ha van mondjuk 12 logikai szálad viszont te kiosztasz 40vCPU-t akkor úgyis jobb ha a hypervisor dönti el ki mikor hova kerül. Legalábbis bízom benne, hogy jól el tudja dönteni :D

Az meg hogy 12 logikai szálból csak 10 et osztok ki, akkor szerintem a xenen se rohangál ide-oda, de majd letesztelem :>

Fedora 38, Thinkpad x280

>megadhatod, hogy először 0-23 logikai magot adja oda az 50 VM-nek, a maradék 50 VM-nek meg 24-47-ig, 

Ez azert nem jo, mert a magok (illetve a thread-ek) nem ugy oszlanak el, hogy 0-23-ig node-0, 24-47-ig meg node-1.

Pl az egyik szerveremen:

root@vmsrv02:~# numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 12 13 14 15 16 17
node 0 size: 32050 MB
node 0 free: 488 MB
node 1 cpus: 6 7 8 9 10 11 18 19 20 21 22 23
node 1 size: 32232 MB
node 1 free: 538 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

XCP-ng alatt nincs ilyen parancsom, neten ezt találtam ano egy ilyesmi kimutatásra:

[code]# xenpm get-cpu-topology
CPU    core    socket    node
CPU0     0     0     0
CPU1     0     0     0
CPU2     1     0     0
CPU3     1     0     0
CPU4     2     0     0
CPU5     2     0     0
CPU6     3     0     0
CPU7     3     0     0
CPU8     4     0     0
CPU9     4     0     0
CPU10     5     0     0
CPU11     5     0     0
CPU12     8     0     0
CPU13     8     0     0
CPU14     9     0     0
CPU15     9     0     0
CPU16     10     0     0
CPU17     10     0     0
CPU18     11     0     0
CPU19     11     0     0
CPU20     12     0     0
CPU21     12     0     0
CPU22     13     0     0
CPU23     13     0     0
CPU24     0     1     1
CPU25     0     1     1
CPU26     1     1     1
CPU27     1     1     1
CPU28     2     1     1
CPU29     2     1     1
CPU30     3     1     1
CPU31     3     1     1
CPU32     4     1     1
CPU33     4     1     1
CPU34     5     1     1
CPU35     5     1     1
CPU36     8     1     1
CPU37     8     1     1
CPU38     9     1     1
CPU39     9     1     1
CPU40     10     1     1
CPU41     10     1     1
CPU42     11     1     1
CPU43     11     1     1
CPU44     12     1     1
CPU45     12     1     1
CPU46     13     1     1
CPU47     13     1     1
[/code]

Szerkesztve: 2019. 11. 27., sze – 09:16

Néhány üzemeltetési tapasztalat:

1.
XenServer 6.5->XCP-ng 7.6 váltás (+ elérő host CPU) közös XCP-ng -s xencenterből megoldható, live-migrationnal is. Hatás: pár óra-2nap után a VM csontra fagy. Force reboot segít.
XCP-ng 7.6->XCP-ng 8.0 ugyanazon típusú host cpu-val a 2 node-on, live migration esetén szintén előfordult.
Mindkettőre a megoldás: live-migraton után VM reboot.

2.
XCP-ng 8 alatt ősidők (XenServer 5.6) óta problémamentes futó monitoring VM csontra fagy. Force reboot után nem tudja használni a virtuális diszket. Backupból történő visszaimportttal megoldottam. A problémás vm diszket mai napig nem tudom törölni, fogja a rendszer: "Control domain on host .."
Semmiféle vbd és hasonló parancsokkal nem megy az unplug, destroy, delete. Azóta már host újraindítás is volt, beragadt.

3.
XCP-ng 8-on a szokásos xenserveren is használt backup script nem tudott lefutni: snapshot készítés, vm-be konvertálás, vm export, vm diszkek törlése, vm törlése és ezzel átmegy a teljes hoston.
Nem tudott snapshtotot készíteni. nem tudtam lekérdezni az sr-listtel a local storage-ben lévő vm diszkeket. Timeoutra futott. Ha leállítottam egy VM-et, nem tudtam elindítani, mert nem tudott hozzáférni a local storage lvm-hez rendesen. A meglévő VM-ek gond nélkül mentek.
Host reboot után minden rendben.

4.
XCP-ng 8 alatt az egyik nagyforgalmú VM csontra fagyott. A 10GB-s renszer diszkje reboot után nem látható. Beraktam egy "service VM" alá, ahol már van indíuló rendszer diszk, xvdb-nek próbálta volna felismerni, de eldobta, hogy nem tudja olvasni. Az a VM diszk úgy tűnt kuka, holott a többi 150GB-s vm diszkje meg jó volt. Választás: több száz GB-s VM import backupból, system diszk felhasználása vagy teljes host restart. Hátha alapon. És a host restart megoldotta. Mintha mi sem történt volna, a problémás VM bebootolt, az FS nem volt corrupt. Na ez a baz+ kategória nálam. Utánakerestem, és XenServer 7-ből hozták ezt az 3-4 bugot. Reportolom az XCP-ng felé, de ha hozott anyagból dolgoznak, akkor szerintem ez ennyi.

Nálam pedig az utolsó 2 nagyon csúnya, váló ok gyanús.
Az  mondjuk még érdekes lehet, hogy shared storage-nél is jelentkezik vagy csak local storage-nél, mert én az utóbbit használom. Ámbár XenServer 5.6 óta használom ezt a technológiát, soha nem volt ilyen gondom.

hibaüzenetek:

XCP-ng hoston dmesg: Buffer I/O error on dev dm-44, logical block 2628577, async page read

"service VM" -en dmesg, ahol attacholtam a problémás diszket:
kernel: [    5.825837] Buffer I/O error on dev xvdb, logical block 0, async page read
kernel: [    5.825869] Dev xvdb: unable to read RDB block 0
kernel: [    5.825920] print_req_error: I/O error, dev xvdb, sector 0

Mondjuk azért 6.5 ről egyből 7.6 ra upgradelni elég meredek :D

Egyelőre nekem semmi gondom egyik telepítéssel se, pedig van még 7.2-es xenserver, 7.6 és 8.0 XCP-ng is. Akár shared, akár local storage megvalósításban. Ráadásul a héten üzemeltem be egy újabb 8.0 pool-t 3 hosttal + shared storage, és jópár VM-et migráltam át ide mindenféle más xenserveres hostoból live módban. Egyikkel sincsen azóta se gond. Reboot se kellett a VM-eken.  Ilyenkor ugye a VM még a régi CPU-t látja ahonnan migrálva lett, de mivel újabban fut így ez nem gond.

Megjegyzem itt minden gép CPU intel xeon sorozat, X56xx szériától a E5 xeonon át a mostnai Silver Xeonokig. Ha shared storage az iSCSI SAN-on van 10GbE intel vagy cisco hálózati kártyákkal. Ahol meg local storage van ott SSD vagy NVMe-n futnak a VPS-sek.

Legbugosabb időszakom talán 7.0 es xenserverrel volt. Ott voltak disk beragadások, de olyan sose, hogy nem lehetett vele mit kezdeni.

Minden VPS en ott van  a guest-tools, legyen az linux, vagy windows. Jahh és az a guest tools amit a xenserverhez adnak. Ugyanis volt ubuntu szerver ami valami saját repoból telepített valamit xe- szart, attól állandóan fagyott a VPS, főleg live migrációnál, megoldás az volt hogy le kellett szedni az ubuntu szarját, és feltenni a rendes guest-tools, azóta is megy szépen. Mondjuk a CentOS epel repoban is megjelent az xe-guest utilities, viszont ha azt felrakom akkor a régebbi 7.2 xenserver hostokon futó VPS-eknek nem látszanak az adatai.

Fedora 38, Thinkpad x280

A XenServer 7.x-ről többszöri próbálkozásra is lepattantam, mert bugos volt, a legutolsó stabil a 6.5 volt nálam.

Tőlem függetlenül munkatársak is próbálkoztak XenServer 7.x verziókkal DELL R720 szerveren, hasonlóan negatív tapasztalattal gazdagodtak.

A node-ok:
2x DELL T610 X5650 CPU-val
2x DELL R730 Xeon E5-2690 v3 CPU-val, Intel szerver SSD-vel local.

Nagyjából 50VM fut egy hoston. Nem nagy kaland, régen kisebb hoston 100-150 VM is futott, megakadás nélkül (XenServer vagy akár opensource xen alatt is 2010 körül)

A VM-ek 99%-a debian, a problémás VM-ek 100%-a debian linux, benne a xcp-ng iso-ban lévő xentools.
A vasak nem gagyik, az alkalmazott kiegészítők sem, erre próbálok figyelni. A xentools mindenhol van, linux mindenhol, általában friss vagy 1 verzióval visszább (perpill debian 9, 10). Nem idegbajos VM-ek vannak rajta. 5-10%-a terhel jobban, az össz terhelés bőven 50% alatt van. Van bőven RAM (256GB-s host) nincs dinamikus RAM használva. Szóval úgy gondolom ennek jól illene működnie.

Ahogy mondod, kezeim alatt megy is szépen vagy 150 VM. Evek ota semmi gond velük, pedig mostanság igencsak voltak ide-oda rángatva. Van köztük még 12.04 es ubuntu, vagy 5.0 debian :D

Évek alatt mindig felmerült, hogy kéne váltani de annyira stabil jól működik, feature gazdag, hogy nincsen értelme.

Fedora 38, Thinkpad x280

Nem tudom nálam miért makacskodik. Nekem az XS 6.5 volt ilyen beton stabil, mint amiről te írsz, de haladni kellett a korral, jól támogasson új OS verziókat. Azóta csak szívok :)

Erősen elgondolkoztam a váltáson, jobb híján Proxmox irányban nézelődtem. A tesztek alapján elég jó. A diszkek szabad mozgatása adott VM alá nekem is hiányzik. Bár megoldható, csak nyűgösebben, kézzel kell configot módosítani vagy LVM-et átnevezni.

 Bár megoldható, csak nyűgösebben, kézzel kell configot módosítani vagy LVM-et átnevezni.

Hát ilyenektől azért fáznék, otthon játszósnak jó, de másra nem használnám. Nekem a proxmox/kvm el 1 gondom van/volt, hogy nem hypervisor (type-1). Meg mivel 2006 ota tolom a xen-t semmi olyan okot nem láttam, hogy KVM-re kellett volna váltani. 

Fedora 38, Thinkpad x280

"Hát ilyenektől azért fáznék"

Igen, te is elkényelmesedtél, mint én :)

A type-1,type-2 engem nem zavar annyia. Pár helyen ~10 éve van libvirtes KVM, pár VM/host, több hoston. Stabilan teszik a dolgukat.

Nem rég VMware vSphere oktatáson voltam (Install, Configure, Manage v6.7 + Optimize and Scale v6.7), ahol többek között szépen átvettük a VMware funkcióit (van több száz apró kapcsoló, paraméter :O ) és folyamatosan húztam a párhuzamot az elmútl 10 év xen, xenserver, kvm, proxmox tapasztalatokkal illetve utána kerestem melyik mit tud, mit nem, ami a VMware-ben tetszett és előtte nem hallottam róla.

A tévedés jogát fenttartom, de úgy láttam, hogy
- a kvm (és a vmware) tud NUMA-t, a xenserver nem,
- a kvm tud hot plug cpu, ram-t, a xenserver nem, Oké, lehet élni nélküle, de jó cloud feature.
- a kvm (és a vmware) tud balloon-t, a xenserver nem. Néha jól jön, persze állandóra nem egészséges.

A proxmox kvm roadmapben benne van az encrypt vm, ahogy a vmware alapból tudja. A többiről nem hallottam, hogy tervben van. Van, amikor hasznos.

A proxmox kinézete egyébként hajaz a VMware vCenter kinézetre, persze ahhoz képest full fapad (de a xenserver is). Kicsit úgy tűnik, mintha a VMware után menne. Múltkor teszteltem a proxmoxban a clustert, HA-t, osztott és local storage live migrálást. Tette jól a dolgát, persze proxmox-szal nincs nagy üzemeltetési tapasztalat. Utoljára 2010 körül teszteltem, bugos volt még. 25VM felett elkeverte a vm konzolokat, más VM konzolját nyitotta meg. 9 év alatt azért sokat fejlődött a  gui. Látok benne potenciált, főleg, hogy a kvm-et a redhat tolja, debian alapból támogatja. Van némi előnye, hogy egy teljesértékű debian linuxod van, nem kell összevadászni adott csomagot a xenserveres centosre, ha pl. monitoring klienst akarsz rá tenni vagy csak egy megacli-t. Főleg egy régebbi xenserver verzió esetén nekem kellemetlen volt adott outdated centos alá rpm-et betákolni, mert akkor merült fel, hogy kellene egy csomag bele. A külső repot nem támogatják (nem szeretik). Joggal, nehogy a saját függőségeiket összekavard.

Hogyne tudna hotplug cpu-t a xenserver :D Simán használom, csak van egy static-max ami főlé nem megy. Szóval ha megadod neki, hogy max 32 de a vm-start cpu 8 akkor 8 al indult fut stb de bármikor belőhető 16-ra is és vissza 4-re :D

ballon is simán megy, mert belefutottam, hogy a xen-orchestra hülyen manageli a ramot, és volt mikor a VPS túlfutott a host fizikai ramján én meg csak lestem hogy mi van, akkor állítottam static-ra az összeset.

A numa-t azt mutattam a multkor, nem tudom az az-e amire gondoltál.

Az meg, hogy nem teljes értékű linux pont, hogy jó, mert csak azzal foglalkozik amivel kell. A virtualizációval, nem akarok rá webszervert lófasz szervert stb. Persze megoldható. A szerverekre feltettem a megacli-t is, meg nagios klienst, de mostanság ráálltam arra, hogy majd a szerver IPMI-je küld egy snmp trapet ha gond van. Így nem a hypervisornak kell figyelni, hogy a raid él-e még, megjegyzem nem is a hypervisor dolga :P

Persze nem hasonlítható a vmware egy xenserverhez, de nem is kerül annyiba :D

Fedora 38, Thinkpad x280

Amit múltkor mutattál, az manuális bindolás, pinning, ki hogy hívja és a vcpu-t adott logikai cpu-hoz rögzítem. A NUMA ettől több.
NUMA: a memóriához közel lévő processzorhoz igyekszik kiosztani a feladatot. Több socketes rendszernél érdekes. 1-es CPU-n futó feladat ne 2-es CPU-hoz közeli RAM-ban legyen.

VMware balloon saját jegyzetemből: "a vmtools-on keresztül benyul és a ballon drivert felébreszti. Egy app elindul a guesten belül és ramot ad neki az OS, többet és még többet kér az OS-től, ehhez lebontja az OS a felesleges cachet, lebontja az álló folyamatokat. Ezt felismeri a vmware és visszanyeri host szinten, ki tudja osztani másnak.

Ballooning: felfúj egy lufit, max 65%-ig lehet, a free listből és az idle ramből próbálja kirakatni a VM-mel swapre.
az igy felszabadult RAM-ból ad a többi VM-nek a share értéknek megadott érték szerint. Ki mennyire férhet hozzá a húsosfazékhoz."

Szerintem a xenserver nem játszik ilyennel. A balloon nem csak dinamikus ram-ot fogalja magában, hanem aztt a folyamatot, ami segít visszanyerni a sok feleslegesen RAM-ban tárolt inaktív adatot (oké van a swap, de tételezzük fel, hogy attól agresszívebben kell most nekünk RAM és a felesleg eltakarítására kényszerítjük a guest OS-t).

Érdekesség, a vmware több lépcsően nyer ramot, ha fogytán az hostban:
TPS (Transparent Page Sharing), balloon, dedup,compress, swap

Valami hasonló van a xen-ben is elég régóta:

https://wiki.xenproject.org/wiki/Archive/XCP_FAQ_Dynamic_Memory_Control

Viszont én ebben nem merültem el, mivel szeretem kézben tartani a dolgokat. Nekem annyira nem tiszta, hogy mikor mi alapján dönt úgy egy algoritmus, hogy ettől elveszem ennek odaadom stb. 

Ha mindenki fixet kap, azzal gond nem lehet, és nem is volt még :>

Fedora 38, Thinkpad x280

Ahha, ez hasznos tűnik, köszi:

What technologies does DMC rely on?
DMC relies on two key technologies:
Memory balloon drivers running within each guest.
Memory populate-on-demand logic within the hypervisor.

Akkor csak van valami mágia ott is :)
Egyébként igen, én is a fix híve vagyok, de hozhat olyat a sors, hogy kell a cipőkanál :)

Szerkesztve: 2019. 12. 13., p – 20:13

Atmigraltunk ma egy Windows VM-et meg egy tuzfalat 7.5-rol 8.0 -ra (Xcp-ng full reinstall, elotte exportaltuk a VM-eket XVA-ba )

 

A 7.5 os felallas (local storage):

 

RAID5 ben HDD-k, ezen volt a VM-ek system es data HDD-je is.

 

8.0 felallas (local storage):

 

ket 512Gb-os SSD, Raid1-ben, a regi HDD-k raid tombje ment a levesbe es cserelve RAID10-re.

 

A win system HDD-je ment a RAID1 SSD tombre, a data pedig az uj RAID10-re.

 

A windows questen (Citrixbol kibanyaszott) guest tools felrakva (a legfrissebb)

 

A gondunk, hogy nem vagyunk elajulva a sebessegtol... (boot ido pl) kb nem valtozott semmi sem. Szerintetek hol csuszhat el a dolog? 

 

A VM amiket futtat jelenleg egy win-server2019 (8Gb ram, 1 socket 4 core) meg egy OPNsense(ezzel nincs gond).

 

A host:

16 Gb RAM (DDR4-2133P)

Xeon e5-1620 v3

+ a fent emlitett HDD (4xWD Blue)+SSD-k (2xCrucial MX500)

Szerkesztve: 2020. 02. 13., cs – 15:42

Az archivum kedvéért.

Ha frissítesz magasabb verzióra és valami gáz van, nem tudsz visszamenekülni egy régebbi verzióval futtatott hostra, mert nem engedi.

Ilyenkor segítség, hogy lehetőség van csak diszket exportálni, importálni.

XCP-ng 7.6 host:

$ xe vdi-list name-label=XXXX
$ xe vdi-export uuid=XXX-YYY-ZZZ filename=/migralas/VM.raw format=raw  --progress

RAW helyett lehet VHD-t is használni.
Másik hoston kézzel a datastore-ban létrehozok egy ugyanakkor méretű üres diszket, elnevezem egyedi névvel és a venti vdi-list paranccsal lekérdezem.

XenServer 6.5 host:

$ xe vdi-import uuid=XXX2-YYY2-ZZZ2 filename=VM.raw format=raw --progress

Készítek egy új VM-et, ha ad hozzá diszket, létrehozás után törlöm és attach ez az importált diszk.
Start és jó esetben bejön minden. Linuxnál van  az rsync diszk tartalma c. menekülés, de windowsnál egy kicsit fájdalmasabb. Nekem most az utóbbihoz kellett.
xcp-ng 7.6->8.1 -> xenserver 6.5 illetve 1 esetben kvm proxmox lett és felnyalta gond nélkül a raw fájlt. Az xcp-ng win drivert próbáltam visszacserélni xenserverre, attól kékhalált kapott, így nem erőltettem. Elfut addig, amíg kell, nincs rajta nagy terhelés.

Hogy érted, hogy nem tudsz visszamenekülni ? Annó ezt leteszteltem simán működött, felupgradeltem, majd downgrade. Igaz az még nem xcp-ng időszak volt. Viszont a telepítő a mai napig detektálja az előző verziót és fel is ajánlja, hogy visszatérhetsz rá.

Viszont azt tény, hogy nem szerencsés mikor újabb xenserver/xcp-ng alatt exportált XVA-t nem tudok régebbi xenserver/xcp-ng re importálni :/

Fedora 38, Thinkpad x280

Van A és B hostom és mindegyik VM-et átmigrálom az A hostra (xcp-ng 7.6), B-t frissítem 7.6->8.0-ra.

Miután lezajlott a frissítés B-n, A-ról visszamigrálom a VM-eket. Elhasal egy windows VM kék halállal vagy maga a host instabillá válik az új verzióval, akkor nem tudom ismét visszamigrálni a VM-eket B-ről A-ra. (Hacsak nem volt egy másolatom belőle A hoston vagy egy korábbi backupom)

Ha live migrálást vagy offline migrálást csinálok B->A irányba, a xencenter kiírja: Older than current server és inaktív.
Vagy: You attempted to migrate a VM to a destination host which is older than the source host.

Mondjuk nem rögtön vettem észre, hogy instabil B host, lefutott azóta pár backup, eltelt pár hét, de látom, hogy xar. A fenti módszer nem játszik, próbáljuk meg friss (már B-n készült) backupból visszatolni A hostra a VM-eket. Nem engedi.

Azt nem tudom, hogy mi van akkor, ha VM-ekkel teli hostot frissítek, ilyet sosem mertem bevállalni.

Nem tudom számít-e, de nálam local disken vannak a VM-ek. Tudtommal a VM-re vonatkozó metadata-t külső storage-n lévő VM fájlba is kiírja, tehát elvileg ez nem ront/nem használ.

Na erre a szívásra megoldás, hogy lehetőség van metadata nélküli diszket exportálni, importálni.

Azt nem tudom, hogy mi van akkor, ha VM-ekkel teli hostot frissítek, ilyet sosem mertem bevállalni.

Én világ életemben így csináltam. Ahol csak single host van akkor ott addig áll minden, azt a fél órát kibírják, ha már nem akartak shared stoarge meg több hostot. Sose volt gondom ebből. Elolvastam a doksit, és ha az azt mondta 6.5 ről mehet az upgrade 7.2 re akkor csináltam és nem is volt gond. 

Sőt 7.x környékén változott a particiós stratégia is. 7.0 ig vagy 7.1 ig a xenserver a local disk ből 4G -t levágott magának és oda pakolta magát. 7.x után már clean installnál 16G -t meg külön log particiót csinál stb. Viszont ezzel se volt még gondom, van XCP-ng -m mai napig a régi 4G-s felállásban. Francnak van kedve sok 100G-t exportálgatni importálgatni :D

Szóval elég furán adod elő a dolgokat, nem csoda ha gubanc lesz benne. Újabbról régire nem lehet migrálni, még ha közös a pool akkor sem. Ezért írják, hogyha a pool-t frissítel akkor mindig a masterrel kezd. A pool nélküli live migrálás érdekes dolog néha én is használom, főleg mikor egyik pool ból a másikra kell költöztetni valamit. Ott is él az újról a régire nem nagyon lehet. 

Fedora 38, Thinkpad x280

Szerkesztve: 2020. 02. 14., p – 09:14

Szóval elég furán adod elő a dolgokat, nem csoda ha gubanc lesz benne.

 

Nem értem itt mire gondosz, mi a fura? Miért nem csoda a gubanc? Vannak single hostok, amiket olykor frissítek. Hogy ne legyen kiesés (meg esetleg frissítéskor nem várt törlés), ezeket a live migration funkcióval local diskről local diskre átmigrálom külső hostra. Frissítem a a régi hostot. Eddig teljesen official útnak tűnik nekem.

Tudtommal nem lennék bentebb, ha poolba szervezném őket és a fenti hozzászólásod ez meg is erősített ebben. Ha az új verzió jó, nincs is teendő.

Ha jól értem, egy bugos verziótól való visszamenekülést az adná, ha a hostot downgradelném Vm-ekkel együtt és így remélve a VM-ek ugyanúgy elindulnak majd. Ezt így még valóban nem próbáltam.

Ilyenekre gondoltam: 

 xencenter kiírja: Older than current server és inaktív.

Mivel ahogy írtam is újról régire nem fogsz tudni visszaállni. Amúgy én olyan bugos verzióval nem találkoztam még, ami miatt downgradelni kellett volna. Pedig 5.x óta használom a xenservert. Voltak/vannak kisebb nagyobb bugok, de inkább elvagyok velük mintsem downgradeljek emiatt. 

ui: bár most nem esküdnék meg rá, de mintha xen-orchestrában ment olyan migráció is amit a xencenter nem engedett volna.

Fedora 38, Thinkpad x280

Tudom, te nagyon mákos vagy. Én csak voltam a XS 6.5-ig. Felette verziókkal sorra jönnek elő bugok és a környezetemben lévő kollégák is panaszkodtak. A neten több xcp-ng->valami más (pl. proxmox) topikba futottam bele az elmúlt hónapokban.

Nem tudom az okát, de kellemetlen és nem tudom kivárni míg javitják.

xcp-ng 8: korábbi panaszaimat ismered, most a kworker/u32:0rpciod pörög 100%-on és az NFS mount, ahova a backupot tolom be van fagyva. Csak a teljes host restart segít és a következő backup (sima vm snapshot, vm export) pár órás futtatása után a ~20. VM-nél ugyanezt teszi.

xcp-ng 7.6: most vettem észre, a xentop olyan vm-et mutatott létezni és futni, ami a hoston már nincs is ott és a xencenter sem mutatja. Reboot megoldotta. Ott nincs gond a backuppal szerencsére.

Úgyhogy egyelőre az irány nekem proxmox, ami valamiért nem hozható át driver, kék halál gond miatt, az legalább XS 6.5-n menjen. Az xcp-ng -t pedig egyelőre hanyagolom, nekem valamiért nem vált be ez a váltás az XS-ről. Remélem nálad kitart a siker :)

Nekem ha van shared storage az iSCSI mindenhol. NFS-ben sose biztam ilyen szinten, ugyanis a fenti hibát nekem nem csak xenserver alatt kepes produlkalni. Az NFS eleg erzekeny a halozatra, es ha az NFS szerver megakad load stb miatt akkor az kihat a host-ra. NFS-t kb csak backupra használok (nem a host csinálja a backupot), meg az nfs-iso-ra :>

xcp-ng ben van egy hiba ami érinti a coalesce folyamatot, azaz snapshot után mikor rendezi a sorait. Mivel LVM-et használok kb mindenhol így különösen fontos volt hogy a snapshot után a foglalt hely felszabaduljon. ehhez /opt/xensource/sm/cleanup.py fájlban kellett kicsit átírni egy változót és megy is szépen. A 7.6 hoz hasonló dolgokat én is tapasztaltam, de ekkor is reboot helyett egy xe-toolstack-restart helyrehozta a galibát. 

Szóval egyelőre a nem elég ismeret hiánya inkább a bajok forrása mint az xcp/xenserver bugjai ;> 

Csak kitart a siker vagy 1x hoston fut xcp-ng 8.0, a fenti cleanup bugot leszamitva teszi a dolgát. sok sok VM-el. Úgyhogy nincsen miért proxmoxra váltani, főleg hogy jó pár feature hiányozna (xenmotion, vagy a live migráció közös storage nélkül) , bár lehet ezek ott is megvannak csak nem tudok róla.

Fedora 38, Thinkpad x280

"xenmotion, vagy a live migráció közös storage nélkül"

Működik mindkettő, sőt menet közben local disk és ugyanazon gép local diskje között is. Pl. HDD->SSD.

Sajnos a 8.0 olyat csinál, ami nálam válóok: többször előfordult, hogy egy VM 3-ból egyik virtuális diszkje nem volt olvasható. Feladva másik VM-nek sem tudtam olvasni, elszállt róla az FS?

Egyik esetben VM backup restore lett a megoldást. Másik esetben, amikor nagy volt a virtuális diszk visszaállítási ideje, bevállaltam egy teljes host restartot, hátha alapon. És láss csodát: a virtuális diszk tökéletesen olvasható volt. A VM azóta is fut és nem okozott hibát.

Ezt még 2x megjátszotta másik VM-mel, de pár hónapja most nyugi van. Én viszont nem alszok tőle nyugodtan, időzített bomba, ha igy megfogja nekem a VM-et valami hülyeség miatt. A VM diszkjei local vannak. Más VM-eket nem érintett, tehát nem hiszem, hogy a diszk alrendszerrel lett volna gond.
Ezt csak 8.0 alatt tapasztaltam és előtte soha, pedig 2010-11 óta használom én is, max 10 hoston kevesebb, mint 200 VM-mel.

Az NFS vs. iSCSI tippet köszi, észben tartom.