Kashyap, just to be sure - it happens to you during the v2v conversion? on L2? While L1 and L0 works fine afterwords, right? Thanks On Fri, Jan 17, 2014 at 4:45 PM, Kashyap Chamarthy <kchamart@redhat.com> wrote:
On 01/17/2014 03:38 PM, Richard W.M. Jones wrote:
On Fri, Jan 17, 2014 at 04:14:03PM +0200, Rom Freiman wrote:
How do you know that the problem is with KVM/QEMU and not with libguestfs?
The guestfsd daemon is simply running the regular 'mount' command. The mount command causes the kernel to panic. There should be no circumstances where running an ordinary command like that, albeit as root, should cause the kernel to panic. Unless the kernel (or in this case, something underneath the kernel) is broken.
mount -o ro /dev/sdb /sysroot/ [ 12.645305] PANIC: double fault, error_code: 0x0 [ 12.645305] CPU: 0 PID: 141 Comm: mount Not tainted 3.11.8-200.strato0002.fc19.strato.c3850ae03e9d.x86_64 #1 [ 12.645305] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 12.645305] task: ffff88001cc816e0 ti: ffff88001cde6000 task.ti: ffff88001cde6000 [ 12.645305] RIP: 0033:[<00007fa602c5b99b>] [<00007fa602c5b99b>] 0x7fa602c5b99a [ 12.645305] RSP: 002b:00007fff4f5884a0 EFLAGS: 00010216 [ 12.645305] RAX: 00007fa602008ff8 RBX: 00007fa601ff0000 RCX: 00007fa601ff0000 [ 12.645305] RDX: 00000000003b7068 RSI: 00007fff4f588560 RDI: 00007fa601ff3d18 [ 12.645305] RBP: 00007fff4f5885d0 R08: 00007fa60200f310 R09: 0000000000000000 [ 12.645305] R10: 0000000000000022 R11: 00007fa60200f310 R12: 00007fa60200e9b0 [ 12.645305] R13: 0000000000000000 R14: 0000000000000000 R15: 00007fa602e6e990 [ 12.645305] FS: 00007fa602e69880(0000) GS:ffff88001f000000(0000) knlGS:0000000000000000 [ 12.645305] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 12.645305] CR2: 0000000000000000 CR3: 000000001d7fb000 CR4: 00000000000006f0 [ 12.645305] [ 12.645305] Kernel panic - not syncing: Machine halted. [ 12.645305] CPU: 0 PID: 141 Comm: mount Not tainted 3.11.8-200.strato0002.fc19.strato.c3850ae03e9d.x86_64 #1 [ 12.645305] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 12.645305] ffff88001f005f58 ffff88001f005e90 ffffffff8164024b ffffffff819e89dc [ 12.645305] ffff88001f005f08 ffffffff8163c272 0000000000000008 ffff88001f005f18 [ 12.645305] ffff88001f005eb8 ffffffff8163c8e5 0000000000000046 00000000000000b1 [ 12.645305] Call Trace: [ 12.645305] <#DF> [<ffffffff8164024b>] dump_stack+0x45/0x56 [ 12.645305] [<ffffffff8163c272>] panic+0xc8/0x1d7 [ 12.645305] [<ffffffff8163c8e5>] ? printk+0x67/0x69 [ 12.645305] [<ffffffff81048ae1>] df_debug+0x31/0x40 [ 12.645305] [<ffffffff810132ed>] do_double_fault+0x5d/0x80 [ 12.645305] [<ffffffff81650b88>] double_fault+0x28/0x30 [ 12.645305] <<EOE>>
Correct.
I encountered this same double_fault panic a week ago:
http://kashyapc.fedorapeople.org/temp/double-fault-panic-nested-kvm-environm...
With these versions:
$ uname -r ; rpm -q libvirt qemu-system-x86 3.11.10-301.fc20.x86_64 libvirt-1.1.3.1-2.fc20.x86_64 qemu-system-x86-1.6.1-2.fc20.x86_64
When I briefly discussed this double fault panic with Paolo Bonzini (KVM maintainer), he mentioned it is probably a host hypervisor bug. But this needs more investigation (ftrace for nested guest, x86info in L1 and L2 - if possible).
Answering Rom's earlier question ("Kashyap, can you please share your experience?"): Yes, ested virtualization with KVM and Intel is not *really* the most stable, but there's on going work upstream to improve this and fix bbugs.
Refer these recent bugs I filed while in a nested KVM environment:
https://bugzilla.kernel.org/show_bug.cgi?id=67761 https://bugzilla.kernel.org/show_bug.cgi?id=68051 https://bugzilla.kernel.org/show_bug.cgi?id=67751
-- /kashyap