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. 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
