Ki használja a 6-os verziót?
Az 5.6-os verzió eddig XEN 3.4.2-t használt, 6-os verzióban pedig már XEN 4.1.1 van.
Szép, jó, de van egy kis gond win alatt a xen-tools progival.
5.6 alatt xenservice.exe futott 2-4 MB mérettel, senkit nem zavart. Felmászott mindenre.
6 alatt már XenGuestAgent.exe fut 20-70 (!) MB mérettel. Ez a méret elég problémás egy 256 MB-s VPS esetén, ahol alapból elég lenne a vps mérete, mert max 1-2 apró win progi miatt kell, de a xen agent jól befalja a ramot.
Ráadásként nem települ mindenre. Kéri a .NET 4-et + XP sp3 alattiakra nem mászik fel.
Megtehetem, hogy letíltom a szolgáltatások között. A cpu, memória, net sebesség adatokat így is jelzi a XenCenter, azonban kintről már nem lehet újraindítani. Amint visszakapcsolom az agentet, az újraindulás megtörténik. Szóval nem létszükség, de erősen javallott a futtatása.
Mi indokolta a frissítést?
Az 5.6 több anomáliát is művelt.
Az egyik kiszolgálón 2 egymást követő hónapban is egy kernel bugos hibaüzit maga mögött hagyva megszakított minden vps kapcsolatott, a vps-eket nem tudtam leállítani,de XenCenter kapcsolat volt.
A xe-toolstack-restart sem segített. A xapit már nem tudta beindítani.
Először oké, de 2x már gázos.
Ami viszont nagyon problémás volt, az egy olyan eset, amikor az egyik VPS-t screenjén egy másik VPS jelent meg.
A dolog hamar kiderült, mert linuxos helyett egy windowst tolt az arcomba.
Leállítani sem tudta.
Ilyen szinten kellett kilőni: /opt/xensource/debug/destroy_domain -domid 62
A screen csere szerencsére csak 1x fordult elő. A leállíthatatlanság sajnos már 3-4x.
Bízva, hogy a 6-os nem csinál ilyet, frissítettem.
A xen agent memória fogyasztása viszont problémás.
A Rooling Pool Update-t nem mertem bevállalni. Az automatikus netes forrást kért, gyanítom egy ISO kevés neki a manuális újraindította a gépet benne a telepítővel, de nem ajánlotta fel az upgrade-t vagy én voltam lassú.
Tekintve, hogy a rendszer sw raid1 alatt van amit őkelme nem nagyon támogat (bár a 6-os legalább nem fagy tőle, mint az 5.6 fp1), így újraraktam tisztán 6-tal.
Előtte kiexportáltam mindent, max import.
Az 5.6-ban feltett Xen-tools nem működik windowsok esetén, így meg kell kérni a népeket, hogy tegyék fel a cd meghajtóban lévő progit.
A felrakás során lecseréli a hálókártya driverét is amitől megszakad a kedves ügyfél távoli asztala. A háttérben persze felmászik és ha jelzi ezt feléd, elég egy reboot a XenCenterből. Már az új xen-tools & driverei fognak betöltődni.
Szóval kicsit nyűgös a téma. Ha nem lettek volna gondok ezzel a géppel szerintem én is vártam volna.
Van több 5.6-os gép, ott nem voltak kernel bugos fagyások csak 1-1 vps fagyott be nagy ritkán. Azt még el lehet viselni, de a globális kernel bugos fagyás nem bevállalható :)
Kiderül a 6 mit produkál 1 hónap múlva:)
Továbbra is csak teszt környezetben van tapasztalat, élesben nincs.
A megnövekedett memória igény feltűnt nekem is. Amivel engem szivat, az a XenServer Tools. 3 próbálkozásból 1x sikerül telepíteni - vicces. További storage (ikszedik HDD) hozzáadása kicsit körülményesnek tűnt számomra. Eddig ennyi, tudom nem túl sok, de többre még nem volt időm sajnos azóta sem :(
Xenserver 6-os verziónál már több mindent igényel a xen-tools install előtt.
Ilyen pl. a .net 4 és a windows image component. Win2003-ban az utóbbi nincs benne, így azt kézzel kell feltenni.
Azt hiszem .net 4 is csak teljes win update után lesz 2003-ban. Szóval kicsit melósabb a dolog :)
Akkor nyilatkozz kérlek :)
Update: komolyan érdekel, hogy miket olvastál. Kérlek oszd meg velünk.
Néhány érdekességet én is olvastam, de az alapvetően nem a citrix hibája hanem az új Intel C-state-re vezethető vissza. Citrix 5.5 felett ezért adódhatnak random fagyások, újraindulások. Megoldás: BIOS-ban minden ilyen opció OFF.
Látom nem nagyon nyilatkozik senki, csak a sejtelmes kijelentés ment, hogy vannak gondok, de konkrétum aztán semmi.
Hogy más ne szívjon el vele n+1 órát, néhány okosság:
1.
3.x kernel felett fstabban barrier=0, különben ilyen hibaüzenet fogad boot során:
blkfront write barrier empty xvda op failed
Ebből akár FS hiba is lehet.
2.
Nagy hálózati forgalom esetén az openswitchd terhel, és 1-2 ügyes parancsal a legkisebb vps is meg tudja fektetni a teljes kiszolgálót.
Elvileg kijött egy patch erre, de a szomorú tapasztalat szerint nem javult tőle. Xenbridge-vel viszont teljesen jó Gbit forgalom esetén is.
3.
BIOS C-state és minden ilyen jellű state, * spektrum offolva legyen, különben random fagyás, reboot lesz a jutatlom.
Első körben ezek a kritikus dolgok. Ezek után abszolút stabilan megy.
Érdemes váltani, mert 5.6-nál voltak hülyeségei amit szerencsére kinőtt a 6-os verzió.
Top-ban nézted a switchd processzt? Több gépen is előjött a gond. Ha gondolod privátban küldök egy parancsot, amit kiadva a guest vm-en tesztelheted mennyire stabil így a host gép.
most hogy mondod, meglestem 25-30%, viszont mint mondtam megy az sflow-d amivel monitorozom az egész infrastruktúrát. Gondolom az is jobban hajtja. Pont 40 VPS fut rajta. Jelenleg 44 napos uptime.
Parancssorból hogyan tudom lekérdezni a futó VM-ek futásidejét (uptime) ?
Az xl uptime parancs csak akkor működik, ha xl create paranccsal vannak indítva.
Pool esetén érdemes a node-okat a /etc/hosts-ba kézzel is felvenni. Jártunk úgy, hogy a belső dns szerver is a pool-on volt és 4 blade emiatt nem volt hajlandó elindulni, csak hosszas bütykölés után.
5.6fp1-ben ezen felül volt egy bug, ami miatt nem szabadította fel a snapshot területeket, így hiába volt még elvileg 1.5TB helyünk az adott LUN-on, az nem volt használható mert foglalta egy halom fantom VDI. Ezt az újban megoldották.
Illetve nem emlékszem, hogy az 5.6 tudott-e stdout-ra exportálni és stdin-ről importálni, ez is nagyon hasznos, ha két pool között mozgatok VM-et csak ssh-n vagy ha ftp/http-ről importálok.
Tanulási fázisban járunk a témával kapcsolatban. XenServer 6.0.2-vel futunk. Van-e arra lehetőség, hogy olyan felhasználókat hozzunk létre, akik korlátozott jogokkal tudják a VM-ket kezelni? Ahogy nézegettük, 'vm-operator' jogosultság nagyszerű lenne, csak ahhoz egy AD-t kellene beüzemelni hozzá. E téren még nincs jártasságunk, ezért szeretnénk tudni, hogy nincs-e valami egyszerűbb megoldás ilyen típusú felhasználó létrehozására?
Hozzászólások
Sziasztok
Ki használja a 6-os verziót?
Az 5.6-os verzió eddig XEN 3.4.2-t használt, 6-os verzióban pedig már XEN 4.1.1 van.
Szép, jó, de van egy kis gond win alatt a xen-tools progival.
5.6 alatt xenservice.exe futott 2-4 MB mérettel, senkit nem zavart. Felmászott mindenre.
6 alatt már XenGuestAgent.exe fut 20-70 (!) MB mérettel. Ez a méret elég problémás egy 256 MB-s VPS esetén, ahol alapból elég lenne a vps mérete, mert max 1-2 apró win progi miatt kell, de a xen agent jól befalja a ramot.
Ráadásként nem települ mindenre. Kéri a .NET 4-et + XP sp3 alattiakra nem mászik fel.
Megtehetem, hogy letíltom a szolgáltatások között. A cpu, memória, net sebesség adatokat így is jelzi a XenCenter, azonban kintről már nem lehet újraindítani. Amint visszakapcsolom az agentet, az újraindulás megtörténik. Szóval nem létszükség, de erősen javallott a futtatása.
Mi indokolta a frissítést?
Az 5.6 több anomáliát is művelt.
Az egyik kiszolgálón 2 egymást követő hónapban is egy kernel bugos hibaüzit maga mögött hagyva megszakított minden vps kapcsolatott, a vps-eket nem tudtam leállítani,de XenCenter kapcsolat volt.
A xe-toolstack-restart sem segített. A xapit már nem tudta beindítani.
Először oké, de 2x már gázos.
Ami viszont nagyon problémás volt, az egy olyan eset, amikor az egyik VPS-t screenjén egy másik VPS jelent meg.
A dolog hamar kiderült, mert linuxos helyett egy windowst tolt az arcomba.
Leállítani sem tudta.
Ilyen szinten kellett kilőni: /opt/xensource/debug/destroy_domain -domid 62
A screen csere szerencsére csak 1x fordult elő. A leállíthatatlanság sajnos már 3-4x.
Bízva, hogy a 6-os nem csinál ilyet, frissítettem.
A xen agent memória fogyasztása viszont problémás.
Ötletek? Hasonló tapasztalatok?
frissítés, rendben zajlott?
van egy 2 szerveres pool 5.6 ossal kéne frissíteni majd 6.0, csak még nem vágtam bele :D
Ubuntu 10.04, Thinkpad x61s
A Rooling Pool Update-t nem mertem bevállalni. Az automatikus netes forrást kért, gyanítom egy ISO kevés neki a manuális újraindította a gépet benne a telepítővel, de nem ajánlotta fel az upgrade-t vagy én voltam lassú.
Tekintve, hogy a rendszer sw raid1 alatt van amit őkelme nem nagyon támogat (bár a 6-os legalább nem fagy tőle, mint az 5.6 fp1), így újraraktam tisztán 6-tal.
Előtte kiexportáltam mindent, max import.
Az 5.6-ban feltett Xen-tools nem működik windowsok esetén, így meg kell kérni a népeket, hogy tegyék fel a cd meghajtóban lévő progit.
A felrakás során lecseréli a hálókártya driverét is amitől megszakad a kedves ügyfél távoli asztala. A háttérben persze felmászik és ha jelzi ezt feléd, elég egy reboot a XenCenterből. Már az új xen-tools & driverei fognak betöltődni.
Szóval kicsit nyűgös a téma. Ha nem lettek volna gondok ezzel a géppel szerintem én is vártam volna.
Van több 5.6-os gép, ott nem voltak kernel bugos fagyások csak 1-1 vps fagyott be nagy ritkán. Azt még el lehet viselni, de a globális kernel bugos fagyás nem bevállalható :)
Kiderül a 6 mit produkál 1 hónap múlva:)
Továbbra is csak teszt környezetben van tapasztalat, élesben nincs.
A megnövekedett memória igény feltűnt nekem is. Amivel engem szivat, az a XenServer Tools. 3 próbálkozásból 1x sikerül telepíteni - vicces. További storage (ikszedik HDD) hozzáadása kicsit körülményesnek tűnt számomra. Eddig ennyi, tudom nem túl sok, de többre még nem volt időm sajnos azóta sem :(
Xenserver 6-os verziónál már több mindent igényel a xen-tools install előtt.
Ilyen pl. a .net 4 és a windows image component. Win2003-ban az utóbbi nincs benne, így azt kézzel kell feltenni.
Azt hiszem .net 4 is csak teljes win update után lesz 2003-ban. Szóval kicsit melósabb a dolog :)
subscribe
+1
GPLPV?
--
Bátor emberek vagytok. :) Itt még 5.5u2-nél tartunk, mert az 5.6-nál is olvastam, hm, érdekes jelenségekről. :)
--
Java apps are nothing more than sophisticated XML-to-exception converters.
Akkor nyilatkozz kérlek :)
Update: komolyan érdekel, hogy miket olvastál. Kérlek oszd meg velünk.
Néhány érdekességet én is olvastam, de az alapvetően nem a citrix hibája hanem az új Intel C-state-re vezethető vissza. Citrix 5.5 felett ezért adódhatnak random fagyások, újraindulások. Megoldás: BIOS-ban minden ilyen opció OFF.
Látom nem nagyon nyilatkozik senki, csak a sejtelmes kijelentés ment, hogy vannak gondok, de konkrétum aztán semmi.
Hogy más ne szívjon el vele n+1 órát, néhány okosság:
1.
3.x kernel felett fstabban barrier=0, különben ilyen hibaüzenet fogad boot során:
blkfront write barrier empty xvda op failed
Ebből akár FS hiba is lehet.
2.
Nagy hálózati forgalom esetén az openswitchd terhel, és 1-2 ügyes parancsal a legkisebb vps is meg tudja fektetni a teljes kiszolgálót.
Vissza kell állítani a korábban is használt xen bridge-t a "xe-switch-network-backend bridge" paranccsal.
Releváns link: http://blogs.citrix.com/2011/12/23/how-to-change-xenserver-network-back…
Elvileg kijött egy patch erre, de a szomorú tapasztalat szerint nem javult tőle. Xenbridge-vel viszont teljesen jó Gbit forgalom esetén is.
3.
BIOS C-state és minden ilyen jellű state, * spektrum offolva legyen, különben random fagyás, reboot lesz a jutatlom.
Első körben ezek a kritikus dolgok. Ezek után abszolút stabilan megy.
Érdemes váltani, mert 5.6-nál voltak hülyeségei amit szerencsére kinőtt a 6-os verzió.
nekünk megy 1 gép xenserver 6 al, rajta majd 40 VPS egyelőre semmi gond, pedig sflow-t is belőttem a vswitch-hez .
Fedora 16, Thinkpad x61s
Top-ban nézted a switchd processzt? Több gépen is előjött a gond. Ha gondolod privátban küldök egy parancsot, amit kiadva a guest vm-en tesztelheted mennyire stabil így a host gép.
most hogy mondod, meglestem 25-30%, viszont mint mondtam megy az sflow-d amivel monitorozom az egész infrastruktúrát. Gondolom az is jobban hajtja. Pont 40 VPS fut rajta. Jelenleg 44 napos uptime.
Fedora 16, Thinkpad x61s
köszi, jól jött az info, pont most gondolkodtam rajta, hogy új vasra merjek -e már 6-ost rakni.
Ezek szerint kap egy esélyt.
Sziasztok
Parancssorból hogyan tudom lekérdezni a futó VM-ek futásidejét (uptime) ?
Az xl uptime parancs csak akkor működik, ha xl create paranccsal vannak indítva.
Előre is köszönöm.
xe vm-param-list uuid= | grep start-time
Pool esetén érdemes a node-okat a /etc/hosts-ba kézzel is felvenni. Jártunk úgy, hogy a belső dns szerver is a pool-on volt és 4 blade emiatt nem volt hajlandó elindulni, csak hosszas bütykölés után.
5.6fp1-ben ezen felül volt egy bug, ami miatt nem szabadította fel a snapshot területeket, így hiába volt még elvileg 1.5TB helyünk az adott LUN-on, az nem volt használható mert foglalta egy halom fantom VDI. Ezt az újban megoldották.
Illetve nem emlékszem, hogy az 5.6 tudott-e stdout-ra exportálni és stdin-ről importálni, ez is nagyon hasznos, ha két pool között mozgatok VM-et csak ssh-n vagy ha ftp/http-ről importálok.
Sziasztok!
Tanulási fázisban járunk a témával kapcsolatban. XenServer 6.0.2-vel futunk. Van-e arra lehetőség, hogy olyan felhasználókat hozzunk létre, akik korlátozott jogokkal tudják a VM-ket kezelni? Ahogy nézegettük, 'vm-operator' jogosultság nagyszerű lenne, csak ahhoz egy AD-t kellene beüzemelni hozzá. E téren még nincs jártasságunk, ezért szeretnénk tudni, hogy nincs-e valami egyszerűbb megoldás ilyen típusú felhasználó létrehozására?
Üdv, Cözi
https://xen-orchestra.com
Igaz, kézzel kell buildelned és akkor minden feature él.
Fedora 23, Thinkpad x220