Created attachment 892545 [details] emerge --info When I try to create a new virtual machine it gives me this error: Unable to complete install: 'internal error: process exited while connecting to monitor: 2024-05-08T22:05:01.652731Z qemu-system-x86_64: error: failed to set MSR 0x40000021 to 0x0 Assertion failed: ret == cpu->kvm_msr_buf->nmsrs (../target/i386/kvm/kvm.c: kvm_buf_set_msrs: 3210)' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/createvm.py", line 2008, in _do_async_install installer.start_install(guest, meter=meter) File "/usr/share/virt-manager/virtinst/install/installer.py", line 695, in start_install domain = self._create_guest( ^^^^^^^^^^^^^^^^^^^ File "/usr/share/virt-manager/virtinst/install/installer.py", line 637, in _create_guest domain = self.conn.createXML(initial_xml or final_xml, 0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/libvirt.py", line 4545, in createXML raise libvirtError('virDomainCreateXML() failed') libvirt.libvirtError: internal error: process exited while connecting to monitor: 2024-05-08T22:05:01.652731Z qemu-system-x86_64: error: failed to set MSR 0x40000021 to 0x0 Assertion failed: ret == cpu->kvm_msr_buf->nmsrs (../target/i386/kvm/kvm.c: kvm_buf_set_msrs: 3210) I can run already created virtual machine images just fine I just can't create any new ones. This error exists with the latest versions of qemu and libvirt on ~amd64.
A QEMU bug, I suppose.
Yeah, this smells like a QEMU bug. Though, maybe libvirt can stop tickling it. ~Tohka, can you please turn on debug logs for libvirt, reproduce and attach them here? This should be enough to turn debug logs on: https://libvirt.org/kbase/debuglogs.html#tl-dr-enable-debug-logs-for-most-common-scenario If you're running monolithic libvirtd instead of split deamon (virtqemud), then just s/virtqemud/libvirtd/ in the virt-admin commands.
(In reply to Michal Prívozník from comment #2) > Yeah, this smells like a QEMU bug. Though, maybe libvirt can stop tickling > it. ~Tohka, can you please turn on debug logs for libvirt, reproduce and > attach them here? > > This should be enough to turn debug logs on: > https://libvirt.org/kbase/debuglogs.html#tl-dr-enable-debug-logs-for-most- > common-scenario > > If you're running monolithic libvirtd instead of split deamon (virtqemud), > then just s/virtqemud/libvirtd/ in the virt-admin commands. I have tested this and it seems like the error only occurs when I am trying to create a windows 11 virtual machine. I have posted the libvirt log of what is happening.
Created attachment 892703 [details] win11-libvirt.log
I can however create a dummy linux virtual machine with no storage and once thats done I can replace the iso with a windows11 iso and everything seems to be fine but just directly I cant create a windows11 virtual machine.
Yeah, this is a QEMU bug (or maybe KVM even?) and it should be reported to QEMU. But, IIUC, you have: <clock> <timer name='hypervclock' present='yes'/> </clock> in your domain XML. Now, this timer causes libvirt to put -cpu hv-time=on onto the cmd line which in turn makes QEMU set the MSR and fail. Maybe the workaround is to delete the timer?
(In reply to Michal Prívozník from comment #6) > Yeah, this is a QEMU bug (or maybe KVM even?) and it should be reported to > QEMU. But, IIUC, you have: > > <clock> > <timer name='hypervclock' present='yes'/> > </clock> > > in your domain XML. Now, this timer causes libvirt to put -cpu hv-time=on > onto the cmd line which in turn makes QEMU set the MSR and fail. Maybe the > workaround is to delete the timer? It seems that anything hyperv related causes the vm to show that error so after removing <hyperv>...</hyperv> it works. However, maybe its also a kernel issue as I may not have support for it?
It seems like a similar issue has already been mentioned here https://forums.gentoo.org/viewtopic-p-8826149.html
It seems the issue was CONFIG_KVM_HYPERV needs to be enabled now for this to work and not cause any problems.
I wonder whether we should put CONFIG_KVM_HYPERV onto the list of kernel config checks. A check failing is not fatal but can warn users upfront.
