Sziasztok!
Egy áramkimaradás miatti szerverleállás után gondom lett egy Xen Windows Server 2012 guesttel. Elindulása után egy idő múlva leáll. A logban ezt találtam:
Domain 27 needs to be cleaned up: destroying the domain
Neten keresgélve találtam utalást arra, hogy hálózati adapter módosulása okozhatja a dolgot. Az tény, hogy a DomU sem indult rendesen, kézzel kellett feléleszteni a xenbr0-t, ami
ifup -a
-ból állt.
Kérdés, hogy tényleg hálózati adapter beállítás módosulása okozza-e a problémát, és ha igen, mit tehetek ellene? Milyen egyéb oka lehet a hibajelenségnek?
Xen 4.4-en jelentkezik, Debian Jessie-n.
- 1127 megtekintés
Hozzászólások
Beidézem a teljes üzenetet, mert amit idéztem, nem az első lépés:
Waiting for domain srv9 (domid 38) to die [pid 26757]
Domain 38 has shut down, reason code 3 0x3
Action for shutdown reason code 3 is destroy
Domain 38 needs to be cleaned up: destroying the domain
Done. Exiting now
Kipróbáltam, hogy elindítom eth adapter nélkül, és így elindul a rendszer.
Visszaengedélyeztem az adaptert, és újra nem indult el (vagyis boot közben dobta ki a guestet).
A teljes guest cfg:
builder='hvm'
memory = 4400
vcpus = '1'
cpus = '2'
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
shadow_memory = 15
name = "srv9"
vif = [ 'mac=AA:AA:AA:AA:AA:AA,bridge=xenbr0' ]
acpi = 1
apic = 1
disk = [ 'phy:/dev/xygroup/srv9sys,hda,w',
'phy:/dev/xygroup/srv9data,hdb,w', 'file:/mnt/data/Windows_Server_2012_R2_Magyar_x64.iso,hdc:cdrom,r' ]
device_model_version = "qemu-xen"
#-----------------------------------------------------------------------------
# boot on floppy (a), hard disk (c) or CD-ROM (d)
# default: hard disk, cd-rom, floppy
boot="dc"
sdl=0
vnc=1
vncconsole=1
vncpasswd=''
vnclisten='192.168.11.12'
serial='pty'
usbdevice='tablet'
- A hozzászóláshoz be kell jelentkezni
Win7 esetén tapasztaltam hasonlót. Megette az össze ramot, erre az xen kilőtte.
Neten találsz megoldást, az usbdevice='tablet' okozta a problémát.
- A hozzászóláshoz be kell jelentkezni
Én eddig sajnos nem találtam megoldást. Próbáltam debuggolni, de a guest_loglvl='debug' nem segített semmit (nem találtam logot, ami részletesebb lett ettől).
Nálam biztos a hálózat okozza, mert egyértelmű, hogy amikor vif opció nélkül indítom a DomU-t, akkor nem lövi ki.
- A hozzászóláshoz be kell jelentkezni
A VPS konzolon ilyenkor mi van? Nem lehet, hogy egyszeruen elcrashel a guest kekkepernyovel, majd ezutan a xen 5-10-20-30 masodperccel kesobb egyszeruen shutdownolja a haltolt guestet?
---
Apple iMac 27"
áéíóöőúüű
- A hozzászóláshoz be kell jelentkezni
Khm... de. Próbálkoztam egy tiszta telepítéssel. Ebben így nincsenek PV driverek. Eszközmeghajtót telepítene, és elszáll.
Próbáltam feltenni a 8.2.2-es drivereket, de 'install failed'-del az sem sikerül.
- A hozzászóláshoz be kell jelentkezni
Sikeresen telepítettem a 8.1.0-s drivereket, viszont továbbra is elszáll bootoláskor engedélyezett vif-fel.
- A hozzászóláshoz be kell jelentkezni
Tuti van elég ram ? Ahogy az előttem szóló is mondta, én crashelni így VM-et csak akkor láttam, mikor a dom0 kifogyott a ramból, és a domU nak kellett még volna adnia.
Fedora 29, Thinkpad x220
- A hozzászóláshoz be kell jelentkezni
Visszaellenőriztem, de van.
- A hozzászóláshoz be kell jelentkezni
Indulás közben (is) nézd ezt:
brctl show
van-e xenbr0,
milyen interfacek vannak benne,
akar-e másik xenbr-et létrehozni,
létrejön-e vif és milyen névvel (van, hogy -emu névvel jön létre a vif)
van, hogy a vif= -hez kell írnod a vifname-et
stb. stb.
Egyébként meg log és log olvasás. Ezek a vif scriptek nem a legstabilabbak.
- A hozzászóláshoz be kell jelentkezni
Indítás előtt:
bridge name bridge id STP enabled interfaces
xenbr0 8000.a0b3cce7f76d no eth1
vif2.0
Van egy linuxos guest is, az fut.
Win guest indításakor:
bridge name bridge id STP enabled interfaces
xenbr0 8000.a0b3cce7f76d no eth1
vif2.0
vif63.0
vif63.0-emu
Ez kitart mindaddig, míg elszáll a Win.
- A hozzászóláshoz be kell jelentkezni