Alexander Graf wrote:
Peter Lieven wrote:
Alexander Graf wrote:
Peter Lieven wrote:
we are running on intel xeons here:
That might be the reason. Does it break when passing -no-kvm?
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU L5530 @ 2.40GHz
stepping : 5
cpu MHz : 2394.403
cache size : 8192 KB
physical id : 1
siblings : 4
core id : 0
cpu cores : 4
apicid : 16
initial apicid : 16
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
xtopology tsc_reliable nonstop_tsc pni dtes64 monitor ds_cpl vmx est
tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm tpr_shadow
vnmi flexpriority ept vpid
bogomips : 4788.80
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
kvm-kmod is 2.6.32.7
...
which commandline parameters do you supply to qemu-kvm?
None :)
It seems to stop working if i supply -no-kvm-irqchip. Can you try to
reproduce this?
We introduced that parameter because we encountered some problems with
the e1000 kernel driver stopped to work in some
guests after live migration with a "nobody cared about interupt" (i
don't know the exact error anymore). supplying
-no-kvm-irqchip made live migration of these guests possible...
Sounds that familiar to someone?
So it works with the in-kernel irqchip? That's the normally supported
configuration anyways. If migration fails with that, that's a different
thing and definitely needs to be addressed.
Yes, it seems, I got the machine booting ~10 times without any problems.
I will try to reproduce the error condition after migration and come back
to the list.
Thanks for your help,
Peter
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
