On 12/30/2017 5:13 PM, Mike Larkin wrote:
On Wed, Dec 27, 2017 at 01:10:13PM -0500, Brian Rak wrote:I have a server with an Intel Platinum CPU: https://ark.intel.com/products/120505/Intel-Xeon-Platinum-8176M-Processor-38_5M-Cache-2_10-GHz It's running Fedora 27 Server, kernel version 4.14.8-300.fc27.x86_64, qemu-system-x86-core-2.10.1-2.fc27.x86_64 I'm starting qemu like this: /usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=test,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-6-test/master-key.aes -machine pc-i440fx-2.10,accel=kvm,usb=off,dump-guest-core=off -cpu Skylake-Client,hypervisor=on -m 32768 -realtime mlock=off -smp 16,sockets=2,cores=8,threads=1 -uuid 6427e485-5aee-4fb6-b5e5-a80c1dc0f4af -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-6-test/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/tmp/cd62.iso,format=raw,if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=32 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=56:00:00:27:d6:3f,bus=pci.0,addr=0x3,rombar=0,bootindex=3 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 127.0.0.1:4788,websocket=40688 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 -msg timestamp=onCould you try a simpler config? There's a lot in there that's not needed for OpenBSD, and I'm wondering if there is some option you've chosen that's causing problems. For what it's worth, there have been a number of reports of OpenBSD guests recently failing when run on KVM (mainly clock related issues but other things as well). You are using a very new CPU on a very new host OS, I'm not surprised some things are behaving a bit strangely. -ml
The simplest command line I can come up with is:/usr/bin/qemu-system-x86_64 -machine accel=kvm -name guest=test -machine pc-i440fx-2.10 -cpu Skylake-Client -m 32768 -drive file=/var/tmp/cd62.iso,format=raw,if=none,id=drive-ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x3 -vnc 127.0.0.1:4788
I still see the same hang. Even using more ancient virtual CPUs (-cpu pentium3) doesn't seem to help.
Switching to '-machine pc-q35-2.10' doesn't appear to help either.If I disable KVM, the instance appears to boot normally. However, I'm not sure if this points to a KVM issue or if it's just masking a timing issue (because it runs so much slower emulated)
In this case, we went with Fedora 27 to rule out a problem that would be fixed by upgrading some part of the host OS. This isn't an OS we normally use, and we've seen issues with older versions of qemu.
I do not have a functional OpenBSD install here, this happens even when I try to boot off the ISO. OpenBSD hangs after printing: pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility There is a flashing "_" cursor, but I'm unable to interact with it in any way. I tried setting this to use an older CPU type, which changed the -cpu flag to be "-cpu Nehalem,vme=off,x2apic=off,hypervisor=off", but this did not seem to have any effect. If I boot the VM with 'boot -c', then 'disable pciide*', I can actually get to the 'Welcome to the OpenBSD/amd64 6.2 installation program' prompt, but then the machine hangs whenever I type 'A'. If I choose another option ('I'), I can get partially through the install before it hangs. The hangs at that point seem to be random. I've attached a screenshot of where it's hanging during the initial boot. So far we've been able to reproduce this on all of our Intel Scalable processors, which includes a few other Gold CPUs. This does work ok on our older E5 CPUs
