1 files changed, 72 insertions, 0 deletions
diff --git a/results/classifier/118/none/1691109 b/results/classifier/118/none/1691109
new file mode 100644
index 00000000..bc145528
--- /dev/null
+++ b/results/classifier/118/none/1691109
@@ -0,0 +1,72 @@
+device: 0.795
+user-level: 0.753
+boot: 0.742
+KVM: 0.735
+PID: 0.735
+vnc: 0.727
+virtual: 0.709
+socket: 0.697
+hypervisor: 0.697
+register: 0.661
+risc-v: 0.654
+ppc: 0.649
+architecture: 0.635
+kernel: 0.631
+permissions: 0.612
+x86: 0.607
+debug: 0.604
+arm: 0.594
+VMM: 0.573
+performance: 0.553
+assembly: 0.551
+files: 0.544
+semantic: 0.542
+mistranslation: 0.532
+TCG: 0.522
+peripherals: 0.519
+network: 0.452
+i386: 0.385
+graphic: 0.378
+
+qemu-kvm not working as nested inside ESX 6.0
+
+ESX 6.0 (virt bits exposed) - Ubuntu 16.04 + qemu-kvm 1:2.8+dfsg-3ubuntu2~cloud0 - CirrOS launched by OpenStack (devstack master)
+
+
+VM will start with -machine = 'pc-i440fx-zesty' and will stuck in "booting from hard disk"
+
+to fix it you can manually change -machine to 'pc-i440fx-2.3'
+
+also, ISOs boots well, so I think it`s something about block devices configuration introduced in new machine type.
+
+p.s.
+also confirmed with RHEL instead of Ubuntu as KVM host - new machine type don`t work
+
+It appears that the recent qemu packages released for 16.04 set the machine type to "pc-i440fx-zesty" instead of "pc-i440fx-xenial".  If you override this and make it use "pc-i440fx-xenial" instances boot again.
+
+FYI, if you are using OpenStack, this can be done by editing nova.conf, [libvirt] section, and add hw_machine_type = x86_64=pc-i440fx-xenial
+
+Thanks Thomas for redirecting this to us.
+
+@fxpester - qemu uses the latest default machine type.
+Since you run on 16.04 but have -zesty types that means you run very likely with the Ubuntu Cloud Archive.
+
+That is what makes more recent virtualization stacks around openstack available on LTS releases.
+As Michael already pointed out in c#1 you can set the type as needed.
+
+I'll add a task for the openstack team who maintains the cloud archive so they can see this as well. I have no ESX around to retry atm, but OTOH haven't seen any such issue on Bare metal nor on nested KVM<->KVM. I'm not sure about the severity yet, as nesting is always a bit less supported.
+
+@Openstack Team do you have VMware testbeds?
+
+Status changed to 'Confirmed' because the bug affects multiple users.
+
+@paelzer
+
+No we don't - sorry.
+
+I marked it as "Incomplete" since the bug reported is quite old and it's not clear what should be done at this point.
+
+Please feel free to mark it back to "New" with further details if necessary.
+
+Thanks,
+