0

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.

2

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.

  • Good catch of me using -machine twice, thanks. I did a fresh install and am building the latest version everything, so I won't be able to replicate the exact situation as before. – Stonecraft Feb 21 at 9:54
-1

Don't use --machine pc anymore. It emulates a 1995-era motherboard, and is wholly inappropriate for running modern operating systems.

Replace it with --machine q35, its only other option, which emulates a more modern and UEFI-capable motherboard.

  • I that with the same results (the message still cites i44fx-3.1!). My understanding was that PC was the most basic and therefore the most likely to work. I will update my question to reflect this. – Stonecraft Feb 21 at 4:10
  • pc will certainly fail with Windows 10, and many other guests. But it looks like you aren't using the qemu version that came with your system. It's not clear why you've done this. You probably should revert. Looks like you also used vnc graphics when you should have used spice. – Michael Hampton Feb 21 at 4:17
  • I heard that a newer version of QEMU helps with the reset bug in AMD Radeon GPUs. Since I am using fairly new hardware (AMD Threadripper), I figured that hardware support would in general be better for newer versions. – Stonecraft Feb 21 at 4:25
  • Also, using spice I get the error about QXL missing (discussed in the thread linked to at the beginning of my post) – Stonecraft Feb 21 at 4:27
  • 1
    The key functional difference between pc & q35 is that the latter provides a PCI-X topology, while the former is PCI. This doesn't really matter, as essentially any modern OS, including Windows 10, will work with both. QEMU's UEFI support is provided by OVMF and works with both pc & q35 machine types. The only thing that becomes q35 specific is UEFI SecureBoot support, which has not been implemented for pc. – DanielB Feb 21 at 10:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.