Host friert ein bei Migration

[TapsTT]

Hallo,

ich habe 2 Nodes mit Proxmox 4.2(gleiche Hardware):

proxmox-ve: 4.2-64 (running kernel: 4.4.16-1-pve)
pve-manager: 4.2-18 (running version: 4.2-18/158720b9)
pve-kernel-4.4.6-1-pve: 4.4.6-48
pve-kernel-4.4.13-2-pve: 4.4.13-58
pve-kernel-4.4.16-1-pve: 4.4.16-64
lvm2: 2.02.116-pve3
corosync-pve: 2.4.0-1
libqb0: 1.0-1
pve-cluster: 4.0-44
qemu-server: 4.0-86
pve-firmware: 1.1-9
libpve-common-perl: 4.0-72
libpve-access-control: 4.0-19
libpve-storage-perl: 4.0-57
pve-libspice-server1: 0.12.8-1
vncterm: 1.2-1
pve-qemu-kvm: 2.6.1-2
pve-container: 1.0-73
pve-firewall: 2.0-29
pve-ha-manager: 1.0-33
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u2
lxc-pve: 2.0.4-1
lxcfs: 2.0.3-pve1
cgmanager: 0.39-pve1
criu: 1.6.0-1
novnc-pve: 0.5-8
zfsutils: 0.6.5.7-pve10~bpo80

Wenn ich nun einen virtuellen Host von einem Node auf den anderen Migriere(Online) friert der virtuelle Host nach der Migration ein, ist per Ping noch erreichbar aber mehr leider nicht mehr.
Host: Win 2012 R2, installiert nach Wiki mit allen Treibern und Agent (betrifft alle 2012 Server).
Es ist nicht mehr möglich den virtuellen Host herunter zu fahren(Fehler: VM quit/powerdown failed) oder zu reseten(Fehler: unexpected status), das einzige was hilft ist den kompletten Proxmox ausschalten und wieder einschalten.

Danke.

Gruß
Tobias

 

[wolfgang]

Hi,

Hat du im bios alle powersaving Optionen disabled?

 

[TapsTT]

Hallo,

ich habe das BIOS bereits mehrfach durchgeschaut und keinerlei Powersaving Optionen gefunden die ich deaktivieren könnte.

Board: Supermicro X11SSH-F
CPU: Xeon E3-1240 v5 3.50Ghz

Gruß
Tobias

 

[TapsTT]

Hallo,

habe nun in Zusammenarbeit dem dem Hersteller alle relevanten Energieoptionen deaktiviert:
Intel (R) SpeedStep (tm)
CPU C-States

Das Problem bleibt aber das selbe:
Die Migration wird erfolgreich abgeschlossen aber die VM friert ein.
Die VM ist per Ping noch erreichbar aber mehr nicht.

Das Problem tritt manchmal schon bei der ersten Migration auf kann aber sein das sich eine VM 1-2 mal Migrieren lässt und das Problem erst beim 3. mal auftritt.

Gruß
Tobias

 

[wolfgang]

Kannst du mir bitte mal die config der Vm schicken?

cmd
qm config <vmid>

P.S. ist es auch nicht möglich die VM mit stop zu stoppen, nicht shutdown?
qm stop <vmid>

 

[TapsTT]

agent: 1
balloon: 1024
bootdisk: virtio0
cores: 1
description: ***
ide0: none,media=cdrom
memory: 8192
name: ***
net0: virtio=EA:D4:9B:9E:68:73,bridge=vmbr0
numa: 1
ostype: win8
smbios1: uuid=432c3d71-7b07-449c-aaa9-0ae561c988ee
sockets: 1
virtio0: DS1-PVE:106/vm-106-disk-1.qcow2,cache=writeback,size=60

 

[wolfgang]

Bitte probieren Sie mal die graffik gegen eine Spice karte zu wechseln.

ist es auch nicht möglich die VM mit stop zu stoppen, nicht shutdown?
qm stop <vmid>

Muss immer der ganze Node neu gebooted werden?

 

[TapsTT]

Grafikkarte hab ich getauscht und Treiber installiert.
Konnte die VM ca. 3 mal Migrieren, beim 4. wieder eingefroren.

qm stop <vm> - hat funktioniert.

 

[pixelpeter]

Hallo,

Ich hänge mich mal hier an.
Ich hatte ja vor einiger Zeit hier die selben Probleme gepostet.
Ich war dann erfolgreich als ich Tight VNC nicht mehr benutzte.
Ich konnte die VM's zig mal migrieren ohne Probleme.
Vorher die selben Problem wie TapsTT.
Alerdings musste ich jetzt nach einigen Wochen den Knoten leerräumen und was soll ich sagen, die VM's hängen einige.
Teilweise ging auch kein Ping mehr.
Poweroptionen sind nach meiner Meinung alle aus.
Gibt es eventuell eine Übersicht was bei einem HP Blade HP BL460 C Gen9 zwingend aus sein muss.

Peter

 

[wolfgang]

Es gib einen Bug der anscheinend Hardware abhängig ist.
probier mal bitte folgendes.
Trag in die <VMID>.config der Windows VM's folgendes ein

args: -rtc clock=vm,base=localtime,driftfix=slew

 

[TapsTT]

Das sieht gut aus.
Hab jetzt ca. 1h nichts anderes gemacht als VMs zu migrieren und keine Probleme gehabt.

Werde das beobachten und nächste Woche nochmal einen Status abgeben.

Danke.

Gruß
Tobias

 

[pixelpeter]

2008'er Server starten sauber und die Migration geht auch.
2003'er werfen diesen fehler beim Start:

TASK ERROR: start failed: command '/usr/bin/kvm -id 156 -chardev 'socket,id=qmp,path=/var/run/qemu-server/156.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -pidfile /var/run/qemu-server/156.pid -daemonize -smbios 'type=1,uuid=0b9a0544-cc59-4b26-a2e9-c7f868f0be45' -name server2003 -smp '2,sockets=1,cores=2,maxcpus=2' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000' -vga std -vnc unix:/var/run/qemu-server/156.vnc,x509,password -cpu kvm64,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 4096 -object 'memory-backend-ram,id=ram-node0,size=4096M' -numa 'node,nodeid=0,cpus=0-1,memdev=ram-node0' -k de -rtc 'clock=vm,base=localtime,driftfix=slew' -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -chardev 'socket,path=/var/run/qemu-server/156.qga,server,nowait,id=qga0' -device 'virtio-serial,id=qga0,bus=pci.0,addr=0x8' -device 'virtserialport,chardev=qga0,name=org.qemu.guest_agent.0' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:27cf9ca13154' -drive 'if=none,id=drive-ide1,media=cdrom,aio=threads' -device 'ide-cd,bus=ide.0,unit=1,drive=drive-ide1,id=ide1,bootindex=200' -drive 'file=/mnt/pve/nfs_nosnap/images/156/vm-156-disk-1.raw,if=none,id=drive-virtio1,cache=unsafe,format=raw,aio=threads,detect-zeroes=on' -device 'virtio-blk-pci,drive=drive-virtio1,id=virtio1,bus=pci.0,addr=0xb,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap156i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=DE:84:12:FF:C8:58,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300' -rtc 'driftfix=slew,base=localtime'' failed: got timeout

 

[dcsapak]

offenbar hängt qemu wenn man 2x

-rtc driftfix=slew

als parameter übergibt

da das bei den 2003er schon gemacht wird, sollte ein
-rtc clock=vm
reichen

 

[pixelpeter]

Ja, das passt.
Werde berichten.
Danke.

Peter

 

[dcsapak]

korrektur:

bitte
-rtc base=localtime,clock=vm
verwenden sonst ist die uhr utc

 

[wolfgang]

fix wird in der Version pve-qemu-kvm 2.6.1-6 und danach drin sein.
Dann werden diese Flags nicht mehr gebraucht.
Ist aber auch nicht schlimm wenn man sie aktive lässt.

 

[fireon]

Danke für den Fix. Hab mir den Thread mal in Lesezeichen abgespeichert.