I am easily able to create Debian and a Linux Mint virtual machines.  However, when I try to create a Windows 10 64 bit virtual machine, it gets as far as the Windows 10 logo and just stalls.  I don't even get to the "busy" circling screen.  Furthermore, when I look at the processor activity on the Dashboard, all the processors I allocate to the VM are running at about 80%.  This is absolutely not the case for my other virtual machines.

 

I have redownloaded a new version of the Windows 10 iso from Microsoft.  I have redownloaded the VertIO drivers.  I have deleted all previous attempts at creating a Windows 10 VM.

 

Any thoughts or suggestions?

How many CPUs do you have assigned to the VM?  You should try with 1 cpu during installation (you can increase the number post installation).

I have 16 cores and 32 threads available.  I've assigned 16 threads several times, and 4 threads one one occasion.  There was no difference in the outcome.

Here's what the log says:

 

2017-02-11 23:04:44.203+0000: starting up libvirt version: 2.4.0, qemu version: 2.7.1, hostname: unRAID

LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/ QEMU_AUDIO_DRV=none /usr/local/sbin/qemu -name 'guest=Windows 10 Pro,debug-threads=on' -S -object 'secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-15-Windows 10 Pro/master-key.aes' -machine pc-i440fx-2.7,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=none -drive file=/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/etc/libvirt/qemu/nvram/3d85df40-7670-8b50-9f21-b1c6da09845c_VARS-pure-efi.fd,if=pflash,format=raw,unit=1 -m 4096 -realtime mlock=off -smp 2,sockets=1,cores=1,threads=2 -uuid 3d85df40-7670-8b50-9f21-b1c6da09845c -no-user-config -nodefaults -chardev 'socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-15-Windows 10 Pro/monitor.sock,server,nowait' -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-hpet -no-shutdown -boot strict=on -device ich9=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev 'socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-15-Windows 10 Pro/org.qemu.guest_agent.0,server,nowait' -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,websocket=5700 -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device vfio-pci,host=00:1b.0,id=hostdev0,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on

Domain id=15 is tainted: high-privileges

Domain id=15 is tainted: host-cpu

char device redirected to /dev/pts/0 (label charserial0)

2017-02-11T23:06:35.895176Z qemu-system-x86_64: terminating on signal 15 from pid 6473

2017-02-11 23:06:36.295+0000: shutting down, reason=destroyed

There have been reports that installing with 1 core/1 thread frequently works for the installation or update of Windows 10.  You should try that and see if it helps.

Holy cow!  That worked!  One core, one thread ...  Who could have guessed??

 

By the way, how does one mark a question as "Solved"?

Holy cow!  That worked!  One core, one thread ...  Who could have guessed??

One of the mysteries of Windows .  You may well find that the same applies when Windows tries to do a major update.

 

By the way, how does one mark a question as "Solved"?

edit the first post in the thread and alter the title.

Here's what the log says:

 

2017-02-11 23:04:44.203+0000: starting up libvirt version: 2.4.0, qemu version: 2.7.1, hostname: unRAID

LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/ QEMU_AUDIO_DRV=none /usr/local/sbin/qemu -name 'guest=Windows 10 Pro,debug-threads=on' -S -object 'secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-15-Windows 10 Pro/master-key.aes' -machine pc-i440fx-2.7,accel=kvm,usb=off,dump-guest-core=off,mem-merge=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=none -drive file=/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/etc/libvirt/qemu/nvram/3d85df40-7670-8b50-9f21-b1c6da09845c_VARS-pure-efi.fd,if=pflash,format=raw,unit=1 -m 4096 -realtime mlock=off -smp 2,sockets=1,cores=1,threads=2 -uuid 3d85df40-7670-8b50-9f21-b1c6da09845c -no-user-config -nodefaults -chardev 'socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-15-Windows 10 Pro/monitor.sock,server,nowait' -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-hpet -no-shutdown -boot strict=on -device ich9=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev 'socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-15-Windows 10 Pro/org.qemu.guest_agent.0,server,nowait' -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -vnc 0.0.0.0:0,websocket=5700 -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device vfio-pci,host=00:1b.0,id=hostdev0,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on

Domain id=15 is tainted: high-privileges

Domain id=15 is tainted: host-cpu

char device redirected to /dev/pts/0 (label charserial0)

2017-02-11T23:06:35.895176Z qemu-system-x86_64: terminating on signal 15 from pid 6473

2017-02-11 23:06:36.295+0000: shutting down, reason=destroyed

 

I had this same issue as well with the machine being i440fx-2.7. I switched to q35-2.5 and it started working, no other modifications needed.