I recently installed the latest version (3.1.0) of QEMU, and I have been having trouble getting virt-manager to work correctly, presumably because it isn't connected to the right dependencies. Some of my other troubles are described in this thread.
I run the following command:
~$ virt-install \
> --name myWINVM \
> --boot uefi \
> --ram 32768 \
> --graphics vnc,listen=0.0.0.0 \
> --machine pc \
> --features kvm_hidden=on \
> --hostdev 9:00.0,address.type=pci,address.multifunction=on \
> --hostdev 9:00.1,address.type=pci \
> --hostdev 0a:00.0,address.type=pci,address.multifunction=on \
> --machine pc \
> --vcpus 4 \
> --os-type windows \
> --os-variant win10 \
> --network bridge=virbr0 \
> --console pty,target_type=serial \
> --disk /home/boss/Downloads/Win10_1809Oct_English_x64.iso,device=cdrom \
> --disk /home/boss/Downloads/virtio-win-0.1.164.iso,device=cdrom \
> --disk path=/home/boss/testVM/WINVM.img,bus=virtio,size=120
and my output is this:
Starting install...
Allocating 'WINVM.img' | 120 GB 00:04
ERROR internal error: process exited while connecting to monitor: 2019-02-21T01:58:56.827372Z qemu-system-x86_64: -enable-kvm: unsupported machine type 'pc-i440fx-3.1'
Use -machine help to list supported machines
Removing disk 'WINVM.img' | 0 B 00:00
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start myWINVM
otherwise, please restart your installation.
In addition to trying the git version of qemu, I also tried building the current SPICE server from the SPICE website:
Note: if I specify q35, I get the exact same error:
~$ virt-install \
> --name myWINVM \
> --boot uefi \
> --ram 32768 \
> --graphics vnc,listen=0.0.0.0 \
> --machine q35 \
> --features kvm_hidden=on \
> --hostdev 9:00.0,address.type=pci,address.multifunction=on \
> --hostdev 9:00.1,address.type=pci \
> --hostdev 0a:00.0,address.type=pci,address.multifunction=on \
> --machine pc \
> --vcpus 4 \
> --os-type windows \
> --os-variant win10 \
> --network bridge=virbr0 \
> --console pty,target_type=serial \
> --disk /home/boss/Downloads/Win10_1809Oct_English_x64.iso,device=cdrom \
> --disk /home/boss/Downloads/virtio-win-0.1.164.iso,device=cdrom \
> --disk path=/home/boss/testVM/WINVM.img,bus=virtio,size=120
Starting install...
Allocating 'WINVM.img' | 120 GB 00:04
ERROR internal error: process exited while connecting to monitor: 2019-02-21T04:08:50.597025Z qemu-system-x86_64: -enable-kvm: unsupported machine type 'pc-i440fx-3.1'
Use -machine help to list supported machines
Removing disk 'WINVM.img' | 0 B 00:00
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start myWINVM
otherwise, please restart your installation.
Edit: I think the issue must be with virt-manager, because I was able to create a qemu system and view it with VNC using the following:
sudo qemu-system-x86_64 \
> -name WINVM,process=WINVM \
> -machine type=q35,accel=kvm \
> -smp 4,sockets=1,cores=2,threads=2 \
> -m 16G \
> -rtc clock=host,base=localtime \
> -serial none \
> -vga qxl \
> -parallel none \
> -boot order=dc \
> -drive file=/home/boss/Downloads/virtio-win-0.1.164.iso,index=1,media=cdrom \
> -drive file=/home/boss/Downloads/virtio-win-0.1.164.iso,index=2,media=cdrom
qemu-system-x86_64: This family of AMD CPU doesn't support hyperthreading(2). Please configure -smp options properly or try enabling topoext feature.
VNC server running on ::1:5900
Edit: My next step will to be to start from scratch from a new host system, and manually build and install all the latest software components before.
So that would be QEMU, libvirt, virt-manager, and spice-server.. Am I forgetting anything? Is there anything I should do to make sure the packages I am building find each other?
Anyway, if that fails I'll probably admit defeat and go back to the repository version, even if it has some issues.
Update: I was not able to get the manually compiled qemu, libvirtd, and virt-manager to all work together, and decided to admit defeat (for the moment). If the reset bug that started this whole thing gets too annoying, maybe I will throw caution to the wind and try Arch.
Best Answer
Given the command line that you illustrate there should be no way to get the error you are reporting. You have requested a unversioned "pc" machine type, which will cause libvirt to query QEMU to ask what the most recent versioned variant is. QEMU appears to have told libvirt to use "pc-i440fx-3.1" which makes sense given your claim to have upgraded to 3.1.0. Given that libvirt gets this info from QEMU itself though, it makes no sense at all that QEMU would then refuse to run complaining that this doesn't exist. This should be an impossible situation to hit. I would check the "virsh capabilities" output to see what machine types its detecting for QEMU.
The reason why you get the same problem when you pass "q35" is because your virt-install args have passed the "--machine pc" option twice. You changed the first one to say "q35" but the second still says "pc" which overrides the first.