<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p dir="ltr"><br>
Den 15 feb. 2017 9:06 em skrev Peter Hudec &lt;phudec@cnc.sk&gt;:<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; so theproblem is little bit different. When I wait for a long time, the<br>
&gt; VM boots ;(</p>
<p dir="ltr">Does the VM have VirtIO serial console activated? I had the same problem and removing that fixed it.</p>
<p dir="ltr">/K</p>
<p dir="ltr">&gt;<br>
&gt; But ... /see the log/. I'm invetigating the reason.<br>
&gt; The difference between the dipovirt0{1,2} and the dipovirt03 isthe<br>
&gt; installation time. The first 2 was migrated last week, the last one<br>
&gt; yesterday. There some newer packages, but nothing related to KVM.<br>
&gt;<br>
&gt; [&nbsp; 292.429622] INFO: rcu_sched self-detected stall on CPU { 0}&nbsp; (t=72280<br>
&gt; jiffies g=393 c=392 q=35)<br>
&gt; [&nbsp; 292.430294] sending NMI to all CPUs:<br>
&gt; [&nbsp; 292.430305] NMI backtrace for cpu 0<br>
&gt; [&nbsp; 292.430309] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.16.0-4-amd64<br>
&gt; #1 Debian 3.16.39-1<br>
&gt; [&nbsp; 292.430311] Hardware name: oVirt oVirt Node, BIOS 0.5.1 01/01/2011<br>
&gt; [&nbsp; 292.430313] task: ffffffff8181a460 ti: ffffffff81800000 task.ti:<br>
&gt; ffffffff81800000<br>
&gt; [&nbsp; 292.430315] RIP: 0010:[&lt;ffffffff81052ae6&gt;]&nbsp; [&lt;ffffffff81052ae6&gt;]<br>
&gt; native_write_msr_safe&#43;0x6/0x10<br>
&gt; [&nbsp; 292.430323] RSP: 0018:ffff88001fc03e08&nbsp; EFLAGS: 00000046<br>
&gt; [&nbsp; 292.430325] RAX: 0000000000000400 RBX: 0000000000000000 RCX:<br>
&gt; 0000000000000830<br>
&gt; [&nbsp; 292.430326] RDX: 0000000000000000 RSI: 0000000000000400 RDI:<br>
&gt; 0000000000000830<br>
&gt; [&nbsp; 292.430327] RBP: ffffffff818e2a80 R08: ffffffff818e2a80 R09:<br>
&gt; 00000000000001e8<br>
&gt; [&nbsp; 292.430329] R10: 0000000000000000 R11: ffff88001fc03b96 R12:<br>
&gt; 0000000000000000<br>
&gt; [&nbsp; 292.430330] R13: 000000000000a0ea R14: 0000000000000002 R15:<br>
&gt; 0000000000080000<br>
&gt; [&nbsp; 292.430335] FS:&nbsp; 0000000000000000(0000) GS:ffff88001fc00000(0000)<br>
&gt; knlGS:0000000000000000<br>
&gt; [&nbsp; 292.430337] CS:&nbsp; 0010 DS: 0000 ES: 0000 CR0: 000000008005003b<br>
&gt; [&nbsp; 292.430339] CR2: 0000000001801000 CR3: 000000001c6de000 CR4:<br>
&gt; 00000000000006f0<br>
&gt; [&nbsp; 292.430343] Stack:<br>
&gt; [&nbsp; 292.430344]&nbsp; ffffffff8104b30d 0000000000000002 0000000000000082<br>
&gt; ffff88001fc0d6a0<br>
&gt; [&nbsp; 292.430347]&nbsp; ffffffff81853800 0000000000000000 ffffffff818e2fe0<br>
&gt; 0000000000000023<br>
&gt; [&nbsp; 292.430349]&nbsp; ffffffff81853800 ffffffff81047d63 ffff88001fc0d6a0<br>
&gt; ffffffff810c73fa<br>
&gt; [&nbsp; 292.430352] Call Trace:<br>
&gt; [&nbsp; 292.430354]&nbsp; &lt;IRQ&gt;<br>
&gt;<br>
&gt; [&nbsp; 292.430360]&nbsp; [&lt;ffffffff8104b30d&gt;] ? __x2apic_send_IPI_mask&#43;0xad/0xe0<br>
&gt; [&nbsp; 292.430365]&nbsp; [&lt;ffffffff81047d63&gt;] ?<br>
&gt; arch_trigger_all_cpu_backtrace&#43;0xc3/0x140<br>
&gt; [&nbsp; 292.430369]&nbsp; [&lt;ffffffff810c73fa&gt;] ? rcu_check_callbacks&#43;0x42a/0x670<br>
&gt; [&nbsp; 292.430373]&nbsp; [&lt;ffffffff8109bb1e&gt;] ? account_process_tick&#43;0xde/0x180<br>
&gt; [&nbsp; 292.430376]&nbsp; [&lt;ffffffff810d1e00&gt;] ? tick_sched_handle.isra.16&#43;0x60/0x60<br>
&gt; [&nbsp; 292.430381]&nbsp; [&lt;ffffffff81075fc0&gt;] ? update_process_times&#43;0x40/0x70<br>
&gt; [&nbsp; 292.430404]&nbsp; [&lt;ffffffff810d1dc0&gt;] ? tick_sched_handle.isra.16&#43;0x20/0x60<br>
&gt; [&nbsp; 292.430407]&nbsp; [&lt;ffffffff810d1e3c&gt;] ? tick_sched_timer&#43;0x3c/0x60<br>
&gt; [&nbsp; 292.430410]&nbsp; [&lt;ffffffff8108c6a7&gt;] ? __run_hrtimer&#43;0x67/0x210<br>
&gt; [&nbsp; 292.430412]&nbsp; [&lt;ffffffff8108caa9&gt;] ? hrtimer_interrupt&#43;0xe9/0x220<br>
&gt; [&nbsp; 292.430416]&nbsp; [&lt;ffffffff8151dcab&gt;] ? smp_apic_timer_interrupt&#43;0x3b/0x50<br>
&gt; [&nbsp; 292.430420]&nbsp; [&lt;ffffffff8151bd3d&gt;] ? apic_timer_interrupt&#43;0x6d/0x80<br>
&gt; [&nbsp; 292.430422]&nbsp; &lt;EOI&gt;<br>
&gt;<br>
&gt; [&nbsp; 292.430425]&nbsp; [&lt;ffffffff8109b2e5&gt;] ? sched_clock_local&#43;0x15/0x80<br>
&gt; [&nbsp; 292.430428]&nbsp; [&lt;ffffffff8101da50&gt;] ? mwait_idle&#43;0xa0/0xa0<br>
&gt; [&nbsp; 292.430431]&nbsp; [&lt;ffffffff81052c22&gt;] ? native_safe_halt&#43;0x2/0x10<br>
&gt; [&nbsp; 292.430434]&nbsp; [&lt;ffffffff8101da69&gt;] ? default_idle&#43;0x19/0xd0<br>
&gt; [&nbsp; 292.430437]&nbsp; [&lt;ffffffff810a9b74&gt;] ? cpu_startup_entry&#43;0x374/0x470<br>
&gt; [&nbsp; 292.430440]&nbsp; [&lt;ffffffff81903076&gt;] ? start_kernel&#43;0x497/0x4a2<br>
&gt; [&nbsp; 292.430442]&nbsp; [&lt;ffffffff81902a04&gt;] ? set_init_arg&#43;0x4e/0x4e<br>
&gt; [&nbsp; 292.430445]&nbsp; [&lt;ffffffff81902120&gt;] ? early_idt_handler_array&#43;0x120/0x120<br>
&gt; [&nbsp; 292.430447]&nbsp; [&lt;ffffffff8190271f&gt;] ? x86_64_start_kernel&#43;0x14d/0x15c<br>
&gt; [&nbsp; 292.430448] Code: c2 48 89 d0 c3 89 f9 0f 32 31 c9 48 c1 e2 20 89 c0<br>
&gt; 89 0e 48 09 c2 48 89 d0 c3 66 66 2e 0f 1f 84 00 00 00 00 00 89 f0 89 f9<br>
&gt; 0f 30 &lt;31&gt; c0 c3 0f 1f 80 00 00 00 00 89 f9 0f 33 48 c1 e2 20 89 c0 48<br>
&gt; [&nbsp; 292.430579] Clocksource tsc unstable (delta = -289118137838 ns)<br>
&gt;<br>
&gt;<br>
&gt; On 15/02/2017 20:39, Peter Hudec wrote:<br>
&gt; &gt; Hi,<br>
&gt; &gt; <br>
&gt; &gt; I did already, but not find any suspicious, see attached logs and the<br>
&gt; &gt; spice screenshot.<br>
&gt; &gt; <br>
&gt; &gt; Actually the VM is booting, but is stacked in some&nbsp; bad state.<br>
&gt; &gt; When migrating, the migration is sucessfull, but the vm is not acessible<br>
&gt; &gt; /even on network/<br>
&gt; &gt; <br>
&gt; &gt; Right now I found one VM, which is working well.<br>
&gt; &gt; <br>
&gt; &gt; In logs look for diplci01 at 2017-02-15 20:23:00,420, the VM ID is<br>
&gt; &gt; 7ddf349b-fb9a-44f4-9e88-73e84625a44e<br>
&gt; &gt; <br>
&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; thanks<br>
&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Peter<br>
&gt; &gt; <br>
&gt; &gt; On 15/02/2017 19:40, Nir Soffer wrote:<br>
&gt; &gt;&gt; On Wed, Feb 15, 2017 at 8:11 PM, Peter Hudec &lt;phudec@cnc.sk&gt; wrote:<br>
&gt; &gt;&gt;&gt; Hi,<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; I'm preparing to migrate from 3.5 to 3.6<br>
&gt; &gt;&gt;&gt; The first step is the CentOS6 -&gt; CentOS7 for hosts.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; setup:<br>
&gt; &gt;&gt;&gt;&nbsp;&nbsp; - 3x hosts /dipovitrt01, dipovirt02, dipovirt03/<br>
&gt; &gt;&gt;&gt;&nbsp;&nbsp; - 1x hosted engine /on all 3 hosts/<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; The upgrade of the first 2 hosts was OK, all VM are running OK.<br>
&gt; &gt;&gt;&gt; When I upgraded the 3rd host /dipovirt03/, some&nbsp; VMs are not able to run<br>
&gt; &gt;&gt;&gt; on the or boot on this host. I tried&nbsp; to full reinstall the host, but<br>
&gt; &gt;&gt;&gt; wth the same result.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; In case of migration the VMm will stop running in a while.<br>
&gt; &gt;&gt;&gt; In case of booting the VM will not boot, I see the 'Loading kernel ...'<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Almost all VMS are Debian 8 with guest tools, some Centos 6/7<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; The hosts were OK with CentOS6.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Where should I start to investigate ?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Sharing vdsm logs showing the failed attempts to run or migrate<br>
&gt; &gt;&gt; a vm would be a good start.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; best regards<br>
&gt; &gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Peter<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; --<br>
&gt; &gt;&gt;&gt; *Peter Hudec*<br>
&gt; &gt;&gt;&gt; Infraštruktúrny architekt<br>
&gt; &gt;&gt;&gt; phudec@cnc.sk &lt;mailto:phudec@cnc.sk&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; *CNC, a.s.*<br>
&gt; &gt;&gt;&gt; Borská 6, 841 04 Bratislava<br>
&gt; &gt;&gt;&gt; Recepcia: &#43;421 2 35 000 100<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Mobil:&#43;421 905 997 203<br>
&gt; &gt;&gt;&gt; *www.cnc.sk* &lt;http:///www.cnc.sk&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; _______________________________________________<br>
&gt; &gt;&gt;&gt; Users mailing list<br>
&gt; &gt;&gt;&gt; Users@ovirt.org<br>
&gt; &gt;&gt;&gt; http://lists.ovirt.org/mailman/listinfo/users<br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt;<br>
&gt;<br>
&gt; -- <br>
&gt; *Peter Hudec*<br>
&gt; Infraštruktúrny architekt<br>
&gt; phudec@cnc.sk &lt;mailto:phudec@cnc.sk&gt;<br>
&gt;<br>
&gt; *CNC, a.s.*<br>
&gt; Borská 6, 841 04 Bratislava<br>
&gt; Recepcia: &#43;421 2&nbsp; 35 000 100<br>
&gt;<br>
&gt; Mobil:&#43;421 905 997 203<br>
&gt; *www.cnc.sk* &lt;http:///www.cnc.sk&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Users mailing list<br>
&gt; Users@ovirt.org<br>
&gt; http://lists.ovirt.org/mailman/listinfo/users<br>
</p>
</body>
</html>