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

  • 14660 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?

Fedora 22 a dom0, és van ugye korábbról win7 disk image, ami futott még xen 4.2.25 alatt. (Tehát fileba feltelepített win7).
Ezen kívül mindenféle live Linux dvd és cd próbálgatására is van konfigom.
Ezeket szeretném újra / tovább használni.

virt-managerrel megpróbálok xen kapcsolatot létesíteni és (1) hibaüzenetet adja.
Szerintem régebben erre volt a xen service (xend), ami helyett most nem tudom mi van.

szerk:
[root@localhost images]# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 5700 8 r----- 76.3

(1):
Unable to connect to libvirt.

no connection driver available for xen:///

Verify that:
- A Xen host kernel was booted
- The Xen service has been started

ÉS:

Unable to connect to libvirt.

no connection driver available for xen:///

Verify that:
- A Xen host kernel was booted
- The Xen service has been started

Libvirt URI is: xen:///

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 862, in _do_open
self._backend.open(self._do_creds_password)
File "/usr/share/virt-manager/virtinst/connection.py", line 161, in open
open_flags)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 105, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: no connection driver available for xen:///

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/

Biztosan Xen-t bootoltam:

[root@localhost images]# xl create win7.cfg
Parsing config from win7.cfg
libxl: error: libxl_dm.c:1499:device_model_spawn_outcome: domain 1 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

Ezen a ponton egy pillanatra látszik, hogy

[root@localhost drobert]# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 5700 8 r----- 358.3
(null) 1 587 1 --p--- 0.0

xl list

root@localhost drobert]# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 7863 8 r----- 78.5

virsh list

[root@localhost images]# virsh list
Id Name State
----------------------------------------------------

config

cfg:
[root@localhost images]# cat win7.cfg
builder='hvm'
memory = 2048
videoram = 128
vcpus = 2
name = "win7"
vif = [ 'bridge=xenbr0,mac=00:16:3e:00:00:01' ]
netmask = '255.255.255.0'
gateway = "192.168.1.220"
disk = [ 'file:/home/drobert/images/win7.img,hda,w' ]
acpi = 1
usb=1
usbdevice = 'tablet'
boot="c"
sdl=0
audio=1
soundhw='sb16'
serial='pty'
vnc=1
vnclisten="127.0.0.1"
vncpasswd=""

brctl show

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

libvirt

[root@localhost images]# rpm -qa | grep libvirt
libvirt-daemon-driver-interface-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-secret-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-lxc-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-network-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-xen-1.2.13.1-2.fc22.x86_64
libvirt-client-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-nwfilter-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-uml-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-qemu-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-libxl-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-storage-1.2.13.1-2.fc22.x86_64
libvirt-daemon-config-network-1.2.13.1-2.fc22.x86_64
libvirt-glib-0.2.0-1.fc22.x86_64
libvirt-daemon-1.2.13.1-2.fc22.x86_64
libvirt-daemon-driver-nodedev-1.2.13.1-2.fc22.x86_64
libvirt-1.2.13.1-2.fc22.x86_64
libvirt-daemon-kvm-1.2.13.1-2.fc22.x86_64
libvirt-gobject-0.2.0-1.fc22.x86_64
libvirt-daemon-driver-vbox-1.2.13.1-2.fc22.x86_64
libvirt-daemon-config-nwfilter-1.2.13.1-2.fc22.x86_64
libvirt-python-1.2.13-1.fc22.x86_64
libvirt-gconfig-0.2.0-1.fc22.x86_64

xl dmesg

[root@localhost images]# xl dmesg
Xen 4.5.0-10.fc22
(XEN) Xen version 4.5.0 (mockbuild@[unknown]) (gcc (GCC) 5.1.1 20150422 (Red Hat 5.1.1-1)) debug=n Tue Jun 2 19:14:22 UTC 2015
(XEN) Latest ChangeSet:
(XEN) Bootloader: GRUB 2.02~beta2
(XEN) Command line: placeholder no-real-mode edd=off
(XEN) Video information:
(XEN) VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN) Found 0 MBR signatures
(XEN) Found 0 EDD information structures
(XEN) Multiboot-e820 RAM map:
(XEN) 0000000000000000 - 000000000009f000 (usable)
(XEN) 000000000009f000 - 00000000000a0000 (reserved)
(XEN) 0000000000100000 - 0000000020000000 (usable)
(XEN) 0000000020000000 - 0000000020200000 (reserved)
(XEN) 0000000020200000 - 0000000040004000 (usable)
(XEN) 0000000040004000 - 0000000040005000 (reserved)
(XEN) 0000000040005000 - 00000000c9f97000 (usable)
(XEN) 00000000c9f97000 - 00000000ca269000 (reserved)
(XEN) 00000000ca269000 - 00000000ca276000 (ACPI data)
(XEN) 00000000ca276000 - 00000000ca427000 (reserved)
(XEN) 00000000ca427000 - 00000000ca42f000 (ACPI data)
(XEN) 00000000ca42f000 - 00000000ca4bd000 (usable)
(XEN) 00000000ca4bd000 - 00000000ca583000 (ACPI NVS)
(XEN) 00000000ca583000 - 00000000ca909000 (reserved)
(XEN) 00000000ca909000 - 00000000ca982000 type 20
(XEN) 00000000ca982000 - 00000000ca983000 (usable)
(XEN) 00000000ca983000 - 00000000ca9c6000 (ACPI NVS)
(XEN) 00000000ca9c6000 - 00000000cadcc000 (usable)
(XEN) 00000000cadcc000 - 00000000caff4000 (reserved)
(XEN) 00000000caff4000 - 00000000cb000000 (usable)
(XEN) 00000000cb800000 - 00000000cfa00000 (reserved)
(XEN) 00000000f8000000 - 00000000fc000000 (reserved)
(XEN) 00000000fec00000 - 00000000fec01000 (reserved)
(XEN) 00000000fed00000 - 00000000fed04000 (reserved)
(XEN) 00000000fed1c000 - 00000000fed20000 (reserved)
(XEN) 00000000fee00000 - 00000000fee01000 (reserved)
(XEN) 00000000ff000000 - 0000000100000000 (reserved)
(XEN) 0000000100000000 - 000000022f600000 (usable)
(XEN) ACPI: RSDP 000FDF00, 0024 (r2 SECCSD)
(XEN) ACPI: XSDT CA269080, 0084 (r1 SECCSD LH43STAR 1072009 AMI 10013)
(XEN) ACPI: FACP CA271998, 010C (r5 SECCSD LH43STAR 1072009 AMI 10013)
(XEN) ACPI: DSDT CA269198, 8800 (r2 SECCSD LH43STAR 18 INTL 20051117)
(XEN) ACPI: FACS CA581F80, 0040
(XEN) ACPI: APIC CA271AA8, 0092 (r3 SECCSD LH43STAR 1072009 AMI 10013)
(XEN) ACPI: FPDT CA271B40, 0044 (r1 SECCSD LH43STAR 1072009 AMI 10013)
(XEN) ACPI: MCFG CA271B88, 003C (r1 SECCSD LH43STAR 1072009 MSFT 97)
(XEN) ACPI: HPET CA271BC8, 0038 (r1 SECCSD LH43STAR 1072009 AMI. 5)
(XEN) ACPI: SSDT CA271C00, 036D (r1 SataRe SataTabl 1000 INTL 20091112)
(XEN) ACPI: SLIC CA271F70, 0176 (r1 SECCSD LH43STAR 1072009 AMI 10013)
(XEN) ACPI: SSDT CA2720E8, 08FC (r1 PmRef Cpu0Ist 3000 INTL 20051117)
(XEN) ACPI: SSDT CA2729E8, 0A7E (r1 PmRef CpuPm 3000 INTL 20051117)
(XEN) ACPI: BGRT CA273468, 0038 (r0 SECCSD LH43STAR 1072009 AMI 10013)
(XEN) ACPI: SSDT CA2734A0, 07CA (r1 SgRef SgTabl 1000 INTL 20051117)
(XEN) ACPI: SSDT CA273C70, 1533 (r1 OptRef OptTabl 1000 INTL 20051117)
(XEN) System RAM: 8087MB (8281944kB)
(XEN) Domain heap initialised
(XEN) ACPI: 32/64X FACS address mismatch in FADT - ca581f80/0000000000000000, using 32
(XEN) Processor #0 7:10 APIC version 21
(XEN) Processor #2 7:10 APIC version 21
(XEN) Processor #4 7:10 APIC version 21
(XEN) Processor #6 7:10 APIC version 21
(XEN) Processor #1 7:10 APIC version 21
(XEN) Processor #3 7:10 APIC version 21
(XEN) Processor #5 7:10 APIC version 21
(XEN) Processor #7 7:10 APIC version 21
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
(XEN) Enabling APIC mode: Flat. Using 1 I/O APICs
(XEN) Not enabling x2APIC: depends on iommu_supports_eim.
(XEN) XSM Framework v1.0.0 initialized
(XEN) Flask: Initializing.
(XEN) AVC INITIALIZED
(XEN) Flask: Starting in permissive mode.
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2294.842 MHz processor.
(XEN) Initing memory sharing.
(XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7
(XEN) I/O virtualisation disabled
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs
(XEN) -> Using old ACK method
(XEN) Platform timer is 14.318MHz HPET
(XEN) Allocated console ring of 16 KiB.
(XEN) VMX: Supported advanced features:
(XEN) - APIC MMIO access virtualisation
(XEN) - APIC TPR shadow
(XEN) - Extended Page Tables (EPT)
(XEN) - Virtual-Processor Identifiers (VPID)
(XEN) - Virtual NMI
(XEN) - MSR direct-access bitmap
(XEN) - Unrestricted Guest
(XEN) HVM: ASIDs enabled.
(XEN) HVM: VMX enabled
(XEN) HVM: Hardware Assisted Paging (HAP) detected
(XEN) HVM: HAP page sizes: 4kB, 2MB
(XEN) Brought up 8 CPUs
(XEN) Dom0 has maximum 792 PIRQs
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Xen kernel: 64-bit, lsb, compat32
(XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x2044000
(XEN) PHYSICAL MEMORY ARRANGEMENT:
(XEN) Dom0 alloc.: 0000000220000000->0000000224000000 (1992350 pages to be allocated)
(XEN) Init. ramdisk: 000000022e4b7000->000000022f5ff1c8
(XEN) VIRTUAL MEMORY ARRANGEMENT:
(XEN) Loaded kernel: ffffffff81000000->ffffffff82044000
(XEN) Init. ramdisk: 0000000000000000->0000000000000000
(XEN) Phys-Mach map: ffffffff82044000->ffffffff82f9ff38
(XEN) Start info: ffffffff82fa0000->ffffffff82fa04b4
(XEN) Page tables: ffffffff82fa1000->ffffffff82fbe000
(XEN) Boot stack: ffffffff82fbe000->ffffffff82fbf000
(XEN) TOTAL: ffffffff80000000->ffffffff83400000
(XEN) ENTRY ADDRESS: ffffffff81d381f0
(XEN) Dom0 has maximum 8 VCPUs
(XEN) Scrubbing Free RAM on 1 nodes using 4 CPUs
(XEN) ..................done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) Xen is relinquishing VGA console.
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
(XEN) Freed 288kB init memory.
(XEN) traps.c:2579:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000.
(XEN) traps.c:2579:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802db000 to 0xffffffff817896d0.
(XEN) traps.c:2579:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802db080 to 0xffffffff8178bb00.
(XEN) traps.c:2579:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010.
(XEN) traps.c:2579:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802dffc0 to 0x0000000000000000.
(XEN) traps.c:2579:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d080237370 to 0xffffffff8178be10.
(XEN) traps.c:2579:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802db080 to 0xffffffff8178c050.
(XEN) traps.c:2579:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700.
(XEN) traps.c:2579:d0v1 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000.
(XEN) traps.c:2579:d0v1 Domain attempted WRMSR 00000000c0000082 from 0xffff830226ffb000 to 0xffffffff817896d0.

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

Több "megoldás" létezik:

1. elindítod a drbd-t dual primary-ban, majd valamilyen cluster programmal felügyeled a xen-t.
2. elindítod a drbd-t dual primary-ban, xen configban phy: eszközként hivatkozol rá. Vigyázol az adataidra.
3. csak linux esetén: drbd normál módon fut, xen configban drbd: erőforrásként állítod be.
A telepített rendszer kernelét kimásolod a dom0-ba. Majd a virtuális gép configban hivatkozol rá.
Pl.:
disk = [
'drbd:HA_disk/1,xvda1,w',
'drbd:HA_disk/2,xvda2,w',
]
#bootloader = '/usr/lib/xen-4.4/bin/pygrub'
kernel = "/var/lib/xen/images/vmlinuz"
ramdisk = "/var/lib/xen/images/initrd.img"

Ezzel a xen állítja a primary/secondary módot a drbd-nél, viszont körülményes a rendszer frissítés után figyelni a kernel verziókra.

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