[08:55] <jodh> smb: re bug 1208455, I've tried running with 'qemu -enable' on a 64-bit canonistack instance and this appears to consistently kill the canonistack instance :(
[08:55] <ubot2`> Launchpad bug 1208455 in linux (Ubuntu Saucy) "general protection fault running apt-get inside double nested kvm VM" [High,In progress] https://launchpad.net/bugs/1208455
[08:57] <smb> Only -enable? Or -enable-kvm? Anyway, err kills the whole instance? Maybe let me know the image number and I look myself
[08:57] <jodh> smb: 'qemu -enable-kvm'
[08:58] <jodh> smb: I've been trying with image ami-0000047d.
[08:58] <jodh> smb: the image boots, but running prepare-testbed runs using qemu kills the canonistack instance.
[08:59] <smb> jodh, Ok, let me start one and look into its environment
[09:00] <jodh> smb: thanks
[09:12] <smb> jodh, Bah, so at least thing I was wrong about is qemu always being the same as arch. Obviously (looking at canonistack and another machine) it is always i386/32bit. Not that this would explain the crash (or should). Just is not what my expectation was.
[09:13] <smb> In my local testing I was using qemu-system-i386 in all cases then, not as I thought both, depending on 1rst level guest.
[09:21] <smb> jodh, But beside of that, prepare-testbed has the 2nd level guest running...
[09:22] <smb> jodh, Are you still using the variant without byobu and with nographics?
[09:32] <jodh> smb: I've disabled byobu, but wasn't running with nographics. I'll re-add that...
[09:38] <smb> jodh, Very likely, as you are now on a 64bit instance, you would want at least use qemu-system-x86_64 again (sorry I should have verified that before)  as peeking inside the running instance of prepare-testbed shows the guest without VMX and I am not sure forcing core2duo and qemu-system-i386 go together well
[09:39] <smb> jodh, But give me a few minutes I am verifying this now on canonistack
[09:40] <jodh> smb: ack.
[10:34] <doko> apw`, ogasawara: do you run the trinity tests on the ubuntu kernels?
[10:59] <smb> jodh, Ok, sorry for the delay, at least prepare-testbed was running through successfully with qemu-system-x86_64 -enable-kvm on the 64bit instance and peeking inside the testbed VM it had VMX and kvm modules loaded
[10:59] <jodh> smb: using qemu-system-x86_64 for prepare-testbed+run-adt-test and then using just 'qemu' for the final vm seems to have killed the qemu-system-x86_64 vm.
[11:01] <smb> That final VM, that had graphics enabled (no -nographics)? It seemed to make a difference on the outer call
[11:02] <smb> Maybe something about iommu or lack of... (thinking alout)
[11:04] <jodh> smb: yes, it uses "-nographic" so I can log the output of the vm. I can try again withouth, but I'm at the point when I'm thinking maybe we should rethink the whole testing strategy to avoid nested kvm's altogether atm. Even if we can find the correct combination of architectures, qemu binaries and qemu options, it all feels very fragile to me.
[11:06] <smb> jodh, Yes, at least going through combinations of cpu bitsize and guest arch. :/
[11:10] <smb> jodh, From what I heard the sec-team was saying they use nested VMs, but probably a 64bit first level all the time and probably not deeper that a 2nd level
[11:11] <smb> It sounded yesterday that what you try to accomplish may be done without nesting but multiple VMs... So you could potentially avoid these issues
[12:35]  * henrix -> lunch
[12:38] <ogasawara> doko: nope, is that something you'd like to see ran?
[12:40] <doko> ogasawara, the debian kernel maintainer asked me to run this for x32, making it a prerequisite to enable the x32 syscalls in the debian kernel
[12:40] <doko> just wondering if it would make sense to run this for ubuntu kernel builds in general
[12:44] <ogasawara> doko: we'll take a look
[12:44] <doko> thanks
[14:46] <disposable> why is it that if I boot up 3.9 kernel with the 'gfxmode $linux_gfx_mode', i get black screen. It works fine without that line in grub. Before 3.9, that was never an issue even with kernels without ubuntu patches.
[17:14]  * rtg -> lunch
[20:01]  * rtg -> EOD