xen 4.5 kisokos

Virtualizáció

Sziasztok!

Korábban beleástam magamat Fedora 19 környékén a XEN-be.
Akkor XEN-t bootolva, indítottam egy xend-et, majd xm create valami.cfg és ennyi volt.
Ma meg XEN 4.5 van xend eltűnt, xm helyett tudom xl van, de még mindig hiányzik valami.
Google nem volt kellően barátságos.
Segítsetek ki, please.

Üdv,
DRobert

  • 14673 megtekintés

( neutrino v | 2015. 06. 19., p – 20:01 )

Xencenter?

Régen legalábbis volt, bár ez webes gui.
-------------------------
Dropbox refer - mert kell a hely: https://db.tt/V3RtXWLl
neut @ présház

( andrej_ v | 2015. 06. 19., p – 21:45 )

De mit szeretnél csinálni, mihez hiányzik?

Xenkernelt bootoltál?
Libvirt van telepítve? virsh list mit ír? látja a dom0-át?

A virtgéped.cfg fájl megvan még?
Ha igen javítsd/ellenőrizd benne az elérési útvonalakat pl. Hálózati interfész, kernel, voltékat ez, virtuális diszk, stb.
Ha nincs .cfg neten találsz, win7hez vb-n ctg kell, átírod és kész, mehet az xl create virtgéped.cfg
--------------------
http://grant-it.com/

Persze a hibaüzenet változatlan, miután javítottam a bridget:
brctl show

[root@localhost drobert]# brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.525400b3bbf0 yes virbr0-nic
xenbr0 8000.000000000000 no

xl create

[root@localhost images]# xl create win7.cfg
Parsing config from win7.cfg
libxl: error: libxl_dm.c:1499:device_model_spawn_outcome: domain 2 device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1319:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:1603:kill_device_model: Device Model already exited

Half way SOLVED

Tehát, xend mint olyan már nincs, helyette sincs semmi, meg nem is kell már.

Úgy néz ki, hogy a problémáért a

videoram = 128

volt felelős. Doksi szerint működnie kéne .. de 3 hete még a XEN maga összeomlott boololáskor a gcc5 miatt (bár korábbi gcc-vel jelentések szerint ment).
Működik most már, de azért egy sor hibát még dob:

libxl: error: libxl_qmp.c:287:qmp_handle_error_response: received an error message from QMP server: Could not set password

ennek ellenére bootol, és rá lehet VNC-zni.

/var/log/messages a témában nem tartalmaz bejegyzést.

A konfigurációs fájlodból hiányzik pár paraméter.

xen-hvm esetén nem elég a builder='hvm' paraméter (XEN 4.4-től). szükséges még a
kernel='/usr/lib/xen/boot/hvmloader' és
device_model = '/usr/bin/qemu-system-x86_64'

A hálókártya beállításnál is hiányzik a model paraméter, pl.
vif = ['bridge=xenbr0, mac=aa:00:00:12:34:56, model=rtl8139, type=ioemu']

VNC beállításnál jól jön a vncunused = 0 paraméter.

Elnézést, hogy bepofátlankodok egy kérdés erejére, de talán ez a legfrissebb xen topik és itt van egy mondat, amire szeretnék rákérdezni (tegnap kezdtem xen-ezni, így lehet, hogy egy kicsit buta kérdés lesz)
Fedora 22 a dom0,
Oprendszer nélküli gépre telepítettem. (xen cd-ről boot..)
Ekkor mi lesz a dom0?

Köszönöm a választ,
és azt, hogy gyorsabban reagáltál, mint ahogy időm engedi foglalkozni a xen-el :)
Még egy kérdésem lenne, minden leírás azzal kezdi, hogy 1. Configure xend-config.sxp , de a fenti esetben nincs ilyen fájl, helyette találtam egy /etc/xen/scripts/vif-setup fájlt, amiben ez volt: exec /etc/xen/scripts/vif-bridge $*. Akkor gondolom így rendben a bridge?!
Viszont itt írják, hogy a xenbr0 tartalmazza azt a címtartományt, amit a virtuális gépek is használnak, eth0 meg a külsőt (vagy amit a router ad).
Ha nyomok egy 'ifconfig -a'-t, akkor xenbr0 -n látom a külső címet, az et0-n meg semmit. Ez így akkor nem lesz jó, ugye?
(és még az /etc/network/interface se létezik, ha a hypervisor a domU)

1) az fura, h nincsen xend-config.sxp file, ez a hypervisor konfigja lenne.
Ha a domU configjában bridge van, és beteszi a bridge-be (azt, hogy ezt hogyan tudod ellenőrizni, lentebb) akkor ez köszönhető a default beállításnak, vagy valahol mégis elbújt egy configfile :-)

IPcímet a bridge-nek illik adni, nem az interfésznek. Emlékeim szerint az interface onnantól kerül forward állapotba, hogy van neki IP címe (0.0.0.0-t szokták adni a bridge interfészeknek)

A Dom0 network configjában elég, ha a localhost-nak van IPcíme, amennyiben nem akarod távolról is elérni,
nyilván úgy logikus, ha 1db címe van (a "belső" hálózatban).

Nekem azonos gépen van külső (valós ip) és belső (192.168.x.y) IPcímmel bíró DomU is. A Dom0 csak belső IPcímmel rendelkezik. ehhez van két bridge (lehet svr_belso,svr_kulso vagy xenbr0 és xenbr1 is)

A legutolsó mondatod oximoron (vagy elírás):
"ha a hypervisor a domU"

A hypervisor a dom0.

Úgy helyes, hogy Dom0 -ban fut a hypervisor

Fordítva.

A Type-1 es hypervisor-ban (a Xen ilyen) fut a Dom0 (is).
Ő is csak egy VM, csak "kicsit" több hardver hozzáféréssel és management jogokkal.
A dom0 tulajdonképpen a management felülete a hypervisornak - azonban a hipervisor nem kötődik a dom0 ban futó oprendszerhez, de szüksége van rá, mert pl a diszket a hypervisor nem tudja kezelni, azt (is) a dom0 végzi. A hypervisor csak virtuális gépeket futtat.

Ezért lehet az, hogy Xen hypervisor használata esetén szinte bármilyen OS lehet a dom0 szerepében. A többi type-1 es hypervisor (VMware, Hyper-V), beépített 'dom0'-nak megfelelő management OS-sel rendelkezik, és mivel ezek zárt rendszerek, nem is cserélhető a management felületük

A domU ezzel szemben nem fér hozzá közvetlenül a hardverhez, ettől 'unprivileged', és ez a fajta (dom0 vs domU) szeparáciohoz van hardver támogatás is: VT-x, VT-d

A type-2 hypervisor esetében van az a felállás, hogy a 'dom0' (de ez a név csak a Xen esetében létezik) maga a hypervisor is egyben. Ilyen pl a VMware player, virtualbox, és a KVM is (bár ez utóbbi típusáról sokan vitatkoznak)

Forrás:
http://wiki.xenproject.org/wiki/Xen_Overview#What_is_Xen.3F
https://en.wikipedia.org/wiki/Hypervisor

--
zrubi.hu

( Honkydoo v | 2015. 11. 03., k – 10:46 )

Sziasztok!

Lazán kapcsolódik a témához ezért kérdezem itt:
Nem tudja véletlenül valaki, hogy ubuntu server 14.04-hez mikor jön ki a xen 4.5?
A drdb cluster nem igazán akar működni xen 4.4 alatt...

nos, az állítás igaznak tűnik (talán patch már van rá).
Ha simán drbd:resource -t adok meg, semmi (resource file not found)
ha drbd:/dev/drbd/by-resource/resource akkor grub bejön, de a kernelt már nem tölti be...

szerk: elvileg a secondary állapotban lévő kötetet automatán primary-ba kéne raknia, ez sem OK

Köszi!!

A 3. megoldást választottam.
Indítanám a virtuális gépet, de az alábbi hibával megáll: xenbus_probe_frontend: Waiting for devices to initialise

Van ahol azt olvastam, hogy az alábbi modul kell: xen-fbfront
Nem igazán találom se a gépen se a neten. Nem tudja valaki melyik csomagban van benne?

1. Csináltam egy telepítést a xen-tools-al (külön lvm kötetre került a disk és a swap)
2. beállítottam a drbd-t mind a két gépen
2.1 létrehoztam egy meta lemezt mind a két gépen
2.2 létrehoztam az lvm kötetet a 2. gépen is
2.3 indítottam a szinkront az első gépről a másodikra
3. beállítottam a xen-t a fentieknek megfelelően

Ajánlom a Ganeti-t.
drbd-t kezeli, a VM létrehozása során mindent megcsinál helyetted. Működés közben folyamatossan ellenőrzi a drbd disk integritást.

Valamint nem csak drbd-t lehet használni storage-nak.

Persze, több más, jó funkciója van Ganeti-nek. Olvass utána egy kicsit.

Én ahogy láttam a Ganeti NEM GUI, hanem egy keretrendszer, ami több hypervisort kezel (pl KVM,Xen)
és script-en keresztül biztosítja a VM-ek létrehozását, módosítását, törlését, migrálását a pool-on belül.

Azaz ha összeraktad a Ganeti Cluster-t, akkor abban egy új VM előállítása kb ennyi:
gnt-create-vm vm_name cluster_member1,cluster_member2

Ehhez képest uez Ganeti nélkül:
mindkét gépen megcsinálod a(z LVM) partíciót
erre létrehozod a DRBD resource-t
összekapcsolod a két gépen a resource-t
létrehozod a Xen configot az egyik gépen
átmásolod a másikra

Előbbinek uaz a hátránya, mint az előnye: egyszerű
kevésbé van lehetőséged finomhangolni

> Előbbinek uaz a hátránya, mint az előnye: egyszerű
> kevésbé van lehetőséged finomhangolni

Ezzel nem feltetlenul ertek egyet. Egyszeru a VM-ek kezelese; start,stop, migrate, reinstall, stb.
viszont rengeteg dolgot lehet finomhangolni, namcsak Cluster szinten, hanem Node, Group, Network, VM szinten.

a hangolas utan az uzemeltetes mar tenyleg egyszeru.

a VM telepitesekhez hasznalt hook-okkal az elkeszult gep teljesen az igenyekhez szabhato. az ujratelepites, klonozas, egyszeru.

GUI-nak egy webgui-t javaslok; ganetimgr.
ezzel a felhasznalo kezeles, HVM eseten webconsole (noVNC), statisztikak, VM karbantartas, stb. tovabb segiti az uzemltetest.

probaltam a ganeti-web-managert, de az nem jott be.

3. pontot próbáltam Debian Jessie-n Xen4.4

Elindulni elindul, de a live-migrate nem megy:
xc: progress: Reloading memory pages: 249856/262144 95%
xc: progress: Reloading memory pages: 262157/262144 100%
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block-drbd add [-1] exited with error status 1
libxl: error: libxl_device.c:1085:device_hotplug_child_death_cb: script: /etc/xen/scripts/block-drbd failed; error detected.
libxl: error: libxl_create.c:1054:domcreate_launch_dm: unable to add disk devices
migration target: Domain creation failed (code -3).
libxl: error: libxl_utils.c:396:libxl_read_exactly: file/stream truncated reading ready message from migration receiver stream
libxl: info: libxl_exec.c:118:libxl_report_child_exitstatus: migration target process [6454] exited with error status 3
Migration failed, resuming at sender.

Ami nekem fura (bár nem olvastam el a Xen changes-t), hogy
1) Xen config nincs(? vagy máshol van?)
2) SSH-n keresztül megy a migrate

Sziasztok!
Bocs, ha off vagyok. DomU clone témában keresek topikot.
Image fájlban futó PV hostot szeretnék klónozni, de elég nagyra sikeredet a létrehozáskor az image fájl. Kb. 20%-át használja a host. Szóval valahogy a lényegi részéről szeretnék másolatot készíteni.

Elég zöldfülü vagyok a témában. A migrate valójában mit is jelent? Host költöztetése egyik vasról a másikra vagy mentésre is használható?

ha klónozod, az vélhetően az egész image-t menti, az üres részt is.
Ha csak a "hasznos" rész kell, szerintem leállítod, mount localban, "cp -a" egy másik image file-ba, ami csak kicsivel nagyobb mint a ténylegesen szükséges terület.

a migrate-t jól érted: egyik futó vasról mozgatás másik (azonos CPU-val bíró) vasra.

( render_elek v | 2016. 02. 23., k – 15:07 )

Sziasztok,
hogyan lehet xen (és nem a citrixes) esetében ctrl+alt+del küldeni?

Oylat olvastam, hogy 3 x ctrl aztán alt+del, de nem megy.
Ha debiánon v.hogy letiltanám ezt a billentyűtriót, akkor az jó lenne, vagy vakvágány és máshogy kell?

ezt vncviewerje válogatja, általában menüből tudod küldeni a spéci karaktereket.
keress rá neten a te verziójú vncvieweredre, hogy annál hogy kell, pár tipp ami működni szokott: F8-ra előugró menü, jobb klikk a viewer szélére(tslán jobb felső sarok)
vagy próbálj másik guis vncviewert, realvnc,tgihtvnc,ultravnc, stb.

--------------------
http://grant-it.com/

( render_elek v | 2016. 02. 29., h – 16:15 )

Sziasztok,

2 hálókártyát szeretnék beállítani úgy, hogy a domu-k lássák egymást, és kifelé is.
Jelenleg 2 domu van, egy ubi és egy w2k12, a dom0 egy debian.

Befelé minden rendben van. A dom0-val tudom pingelni a domu-k mindkét lábát, a domu-kal is tudom pingelni a dom0-nak és egymásnak mindkét lábát.

Kifelé viszont baj van: win-nel tudok pingelni publikus címek felé, de ubival nem "Network is unreachable.".
Amig csak az egyik bridge volt belőve az ubi is ment kifelé.

Nem látom a hibát.
A rendszer csak egy tesztrendszer, így a "külső" láb 192.168.1.x, a belső 172.16.0.x és sw tűzfal sincs.

A configok:
*********************************dom0 interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto xenbr0
iface xenbr0 inet static
bridge_ports eth0
address 192.168.1.1
broadcast 192.168.1.255
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 195.199.255.4 195.199.255.57

auto eth1
iface eth1 inet manual

auto xenbr1
iface xenbr1 inet static
bridge_ports eth1
address 172.16.0.1
broadcast 172.16.0.255
netmask 255.255.255.0

*********************************xen2.ubuntu.cfg

bootloader='pygrub'
builder='hvm'

memory = 4096
vcpus = 3

name = "ubuntu"

vif = [ 'type=ioemu, bridge=xenbr0','type=ioemu, bridge=xenbr1' ]

# disk = ['file:/home/xenvm/xen2.ubuntu.img,xvda,w', 'file:/home/xenimage/ubuntu-15.10-desktop-amd64.iso,xvdc:cdrom,r']
disk = ['file:/home/xenvm/xen2.ubuntu.img,xvda,w']

boot="dc"
sdl=0
vnc=1
vnclisten="127.0.0.1"
vnconsole=1
vncpasswd='qwert'
stdvga=0
serial='pty'
usbdevice='tablet'

on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

*********************************ubuntu interfaces

# interfaces(5) file used by iBfup(8) and ifdown(8)
auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
address 192.168.1.99
netmask 255.255.255.0
getaway 192.168.1.254
dns-nameservers 192.168.1.254
dns-search workgroup

allow-hotplug eth1
iface eth1 inet static
address 172.16.0.99
netmask 255.255.255.0

**********************************xen3.windows.cfg

bootloader='pygrub'
builder='hvm'

memory = 8192
vcpus = 4

name = "windows"

vif = [ 'type=ioemu, bridge=xenbr0', 'type=ioemu, bridge=xenbr1' ]

disk = ['file:/home/xenvm/xen3.windows.img,xvda,w', 'file:/home/xenimage/win2012r2.iso,xvdc:cdrom,r']
# disk = ['file:/home/xenvm/xen3.windows.img,xvda,w']

boot="dc"
sdl=0
vnc=1
vnclisten="127.0.0.1"
vnconsole=1
vncpasswd='qwert'
stdvga=0
serial='pty'
usbdevice='tablet'

on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'

1) tényleg addig frissítgetet a post-ot amíg valaki nem olvassa el helyetted a manualt?
2) én először is megnézném domU alatt a "brctl show" kimenetét, h a megfelelő helyeken látszanak-e a megfelelő MAC címek
3) én arra tippelek, hogy MAC címet is meg kéne adni a vif résznél, de lehet, h anélkül autoconfig van, fene tudja

0, eloszor is szeretnem megkoszonni a valaszt
1, tenyleg frissitgetem, de nem azert, hanem hogy valaszoljon ra valaki :)
amugy tul voltam mar a manual tanulmanyozasan, be is raktam a mac-et, de ugy meg a pingeles sem ment, igy kivettem, mielott publikaltam a konfigokat.

Ajanlasodra megis ujra probaltam a mac bedrotozasat.
Erdekes, hogy a brctl show szerint a ...:1c vegu mac tartozik a xenbr0-hoz es a eht0-hoz, es a ...:1e vegu pedig a xenbr1 - eth1. Ha viszont igy drotozom be az ubuntu.cfg fajlomba, akkor a belso halo is elszall.
Kulfoldi forumokon olvastam, hogy ilyenkor fizikailag kell atdugdosni a kabeleket, de en inkabb a xen2.ubuntu.cfg-ben adtam a ..:1c vegut a eth1-hez es a ...:1e vegut a eth0-ba.

Na, igy visszatertem az eredeti problemahoz, hogy belso halo volt, kulso nem :D

Szoval nem ez volt a megoldas, hanem az ubuntu interfaces fajljaban irtam gateway helyett getaway-t :D

..ahogy Bjarne Stroustup irta, "azok a buta kis hibak.."

ui.: elnezest az ekezettelensegert, de ezt "azon" az ubuntun gepelem es itt nincs magyar bill.

( lohner | 2016. 07. 27., sze – 11:11 )

Sziasztok!

Bocs, ha triviális a kérdés.
A XEN kernel indítása esetén leállításkor nem kapcsol ki a gép.
Elég kellemetlen, mert miután a szünetmentes leállítja a gépet és visszajön az áram, nem indul el automatikusan, mivel még le sem állt. Ki kell mennem a helyszínre, "kinyomni", majd elindítani. Több különböző hardverű XEN szerveremnél is ez a helyzet. A dmesg alapján az ACPI S5 támogatott és normál kernel indításkor működik a leállítás.
Fórumokon az acpi=off opciót javasolják egymásnak, de nem szeretném az egész ACPI alrendszert kikapcsolni.
Érdemes ebben tovább keresgélnem? Működik valakinek ez a funkció?

Nekem működik a leállás, semmit nem csináltam hozzá, alapból ment.

grub.cfg ban menüpont:


menuentry 'XEN Gentoo' {
root=hd1,1
search --fs-uuid --no-floppy --set 123123123123123
multiboot /xen.gz dom0_mem=1200M,max:12G dom0_max_vcpus=4
module /vmlinuz root=/dev/dom0/root panic=5 net.ifnames=0 consoleblank=0 rd.auto
module /initramfs
}

A probléma talán a dom0 linux kernelben van, esetleg valamilyen power management beállítást nem engedélyeztél. Próbáld meg xen nélkül a dom0 t bootolni, hogy úgy leáll-e, esetleg nem a xennel kapcsolatos a probléma.

( mauser1 v | 2016. 08. 01., h – 18:00 )

Tudna vki segiteni, hogy tudnám UEFI -avl a xen 4.5.1 elinditani ? (kernel 3-16, debian )
Mivel a szerver csak UEFI alatt támogatja a hardwares RAIDET.

( Honkydoo v | 2016. 08. 02., k – 11:11 )

Nekem az lenne a kérdésem, hogy centos 7 alatt, hogy lehet kiváltani a xen-tools csomagot?

Igen, de a kiváltást én úgy értettem, hogy centos-on a xen-tools nem elérhető és mi van helyette.
Hmm akkor a szó amit keresek: helyettesíteni
Lehet többet kellene foglalkoznom a szép Magyar nyelvünkkel, hogy érthetően fogalmazzak. /o\

( mauser1 v | 2016. 08. 08., h – 19:46 )

Megkérdezem csak azért is !!!

Például van 2 db 4 magos processzor a gépben meg 16GB RAM.
Megadom a grubba hogy a Domain-0 min 2024MB. confban a Domain nulla vcpu = 0
Innen okés a dolog, a ha nem engedélyezem a ballont, akkor marad 12Gb Ramom amit feloszthatók a domU köszt igaz ?

De ami a kérdésem a 8 cpu-val is igy kell gazdálkodni , vagy a 8 cput megkaphatja az osszes domU azaz
-egyesdomU 8 vcpu 4GB Ram
-kettesdomU 8 vcpu 4GB Ram
-harmasdomU 8 vcpu 2GB Ram

A processzoridő ütemezőnek, ez nem lehet gond igaz?

Nálam nincsenek üzleti szempontok , hogy 1 cpu 2GBram 100 FT 8cpu 16GBram 1200FT (ezek csak példák)

A legjobb teljesitmény kéne.

először is 14G marad, ha 16-2, szerintem :-)
nem csak azt adhatod meg, h melyik domU mennyi vcpu-t használhat, hanem azt is, h melyiket.
pl a 8 magból 1-et használ domU, marad 7.
a 7ből 2-t dedikálva adsz az egyik VM-nek, marad 5.
Az 5-t pedig kiadod 3 VM-nek, ahol mindegyik 2-t használhat. Nyilván lesz egy minimális verseny, ha mindenki használna akarja a magokat, de 5/6 overbooking az minimális.

A lényeg, hogy nem kötelező. Nem kell maghoz / cpuhoz kötni a domu-t, adhatsz minden virt gépnek minden procit egyszerre, és osztják a súlyozás alapján, default egyenlően (úgy tudom)

így tudod állítani a súlyozást, ami a proci terhelésnél számít:

xl sched-credit -d Domain-0 -w 512

Ok erről már olvastam, http://wiki.xenproject.org/wiki/Cpupools_Howto
de ha az osszes domU az osszes processzor felett rendelkezik, a logikám szerint ez azt jelentené,hogy az összes gép nagy teljesitményű lenne és nem igazán versenyeznének egymással mert több maggal gyorsabban elvégzik a feladatukat.

De

Idézet Xen a gyakorlat-ból:
"A xen hiperfelügyelőben található VCPU-ütemező azt dönti el, hogy melyik vendég melyik virtuális processzora melyik igazi processzoron futthat."

És ebből adódik a fentebb feltett kérdésem:

Hogy akkor még is csak kell a processzorokat finomhangolni épp úgy ahogy te írod.

Akkor egy helyes config:
--domO 1,2 procc 4GBRam
--egyesdomU 3,4,8 procc 4GBRam
--kettesdomU 5,6 procc 4GBRam
--harmasdomU 7 procc 2GBRam

es akkor nem lesz se cpu se Ram vita ?

Ebben az esetben az ütemező egyépként mit csinál, ha az összes domun megvan határozva cpu?

Ilyenkor mind a 3 domu egy időben használhatja cput nem ?

én nem vagyok nagyon milyen sem a kódolásban sem az ütemezésben, de:
"de ha az osszes domU az osszes processzor felett rendelkezik, a logikám szerint ez azt jelentené,hogy az összes gép nagy teljesitményű lenne és nem igazán versenyeznének egymással mert több maggal gyorsabban elvégzik a feladatukat."

Szerintem a scheduler megpróbál a domU-k között igazságosan osztani. Ennek az lesz a következménye, h minden domU kb azonos időrést kap a CPUkon (természetesen figyelembe véve az esetleges súlyozást). Csakhogy se a CPU-nak nem mindegy, h a kérdéses utasítás-sorozat milyen sorrendbe kerül végrehajtásra (értsd 10 időrés kb így: 11223312) ez nem nagyon optimális a cache-nek, pláne, ha 100 utasítás 3 külön magon kerül végrehajtásra egy helyett.
Nyilván, ilyen esetben előfordulhat, hogy hatékonyabb lesz, ha minden domU-nak adsz inkább dedikált magot.
A scheduler-nek (szerintem) még azt is beállíthatod, hogy a domU-nak van 4 vcpu-ja, de Te összesen 2 fizikai magot engedsz használni.

Még vedd figyelembe ha NUMA felépítésű a gép (Intel Nehalem óta mind) akkor nem az adott CPU-hoz tartozó memória elérése teljesítmény csökkenéssel jár.
http://wiki.xen.org/wiki/Xen_on_NUMA_Machines
Ja és CPU esetén sem mindegy.
http://wiki.xen.org/wiki/Cpupools_Howto#Using_cpupool-numa-split

De pontosan ha az OS támogatja NUMA architektúrát, akkor látja a 32G+32G memóriát és a hozzá tartozó CPU magokat, és ennek megfelelően képes futtatni programokat, hogy NUMA node határon belül maradjanak. Virtualizáció esetén is fontos szempont ez XEN, vmware esetén sem mindegy.

( mauser1 v | 2016. 08. 31., sze – 13:32 )

Melyik a magasabb verzió szám ?komolyan nem egyértelmű számomra

A xen 4.5.1-rc1 vagy a xen 4.5.0-rc2 ???

Az előbbit használjuk, de az utonbbira szeretnénk áttérni (no known issue)

A 4.5.1 a magasabb, de 4.5-ből már bőven valami 4.5.2/3 lesz, miért RC-ztek egy elég régóta stable branchből? Ráadásul egy maintenance releaseről áttérni a következőre az update igazából, nem egy veszedelem.

Itt a branchek listája: http://xenbits.xen.org/gitweb/?p=xen.git;a=summary