Error on creating a VM with virtManager

English Virtualization
1

Hello,
i just tried to create a VM in yast, it gave the following error:

Installation could not be completed: «Interner Fehler: process exited while connecting to monitor»

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createvm.py", line 2081, in _do_async_install
    installer.start_install(guest, meter=meter)
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 731, in start_install
    domain = self._create_guest(
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 679, in _create_guest
    domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib64/python3.8/site-packages/libvirt.py", line 4366, in createXML
    raise libvirtError('virDomainCreateXML() failed')
libvirt.libvirtError: Interner Fehler: process exited while connecting to monitor

Does anyone have any idea what I did wrong?

2

Hi
I see a few updates to virtual-manager in snapshot 20210106, perhaps zypper dup to this and test again.

3

I have upgraded, but I still have the same error. :frowning:

4

Hi
OK, so when you say YaST, is this in the initial kvm setup? Normally ensure libvirtd services is running, and run virt-manager…

5

I was just about to make a thread about this same error. I get the error in the Virt Manager GUI application. It is 100% reproducible with the NixOS 20.09 ISO.

I have taken the following setup steps:

  1. zypper install bridge-utils libvirt virt-manager qemu-kvm
  2. Selected KVM and LXC options in the YaST Virtualization module
  3. Added my user to the libvirtd and kvm groups
  4. Created a bridge network device with NetworkManager called “br0”
  5. Rebooted my machine

In Virt Manager, I can reproduce the error reliably with the following:

  1. Select File -> “New virtual machine”
  2. Select “Local install media”
  3. Select the NixOS 20.09 ISO linked above
  4. Uncheck “automatically detect” and set the operating system to “nixos-unknown”
  5. Keep the default memory and CPU settings (3072 MB and 1 vCPU)
  6. Create a 20 GiB disk image
  7. Set the name to “nixos-gnome_20.9”
  8. Set the network to “Bridge device…” and set the device name to “br0”

I then get a popup window with the following error output:


Unable to complete install: 'internal error: qemu unexpectedly closed the monitor'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createvm.py", line 2081, in _do_async_install
    installer.start_install(guest, meter=meter)
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 731, in start_install
    domain = self._create_guest(
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 679, in _create_guest
    domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib64/python3.8/site-packages/libvirt.py", line 4366, in createXML
    raise libvirtError('virDomainCreateXML() failed')
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor

Here are the contents of /var/log/libvirt/nixos_20.9-gnome.log:I was just about to make a thread about this same error. I get the error in the Virt Manager GUI application. It is 100% reproducible with the NixOS 20.09 ISO.

I have taken the following setup steps:

  1. zypper install bridge-utils libvirt virt-manager qemu-kvm
  2. Selected KVM and LXC options in the YaST Virtualization module
  3. Added my user to the libvirtd and kvm groups
  4. Created a bridge network device with NetworkManager called “br0”
  5. Rebooted my machine

In Virt Manager, I can reproduce the error reliably with the following:

  1. Select File → “New virtual machine”
  2. Select “Local install media”
  3. Select the NixOS 20.09 ISO linked above
  4. Uncheck “automatically detect” and set the operating system to “nixos-unknown”
  5. Keep the default memory and CPU settings (3072 MB and 1 vCPU)
  6. Create a 20 GiB disk image
  7. Set the name to “nixos-gnome_20.9”
  8. Set the network to “Bridge device…” and set the device name to “br0”

I then get a popup window with the following error output:


Unable to complete install: 'internal error: qemu unexpectedly closed the monitor'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createvm.py", line 2081, in _do_async_install
    installer.start_install(guest, meter=meter)
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 731, in start_install
    domain = self._create_guest(
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 679, in _create_guest
    domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib64/python3.8/site-packages/libvirt.py", line 4366, in createXML
    raise libvirtError('virDomainCreateXML() failed')
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor

Here are the contents of /var/log/libvirt/nixos_20.9-gnome.log: https://paste.opensuse.org/42337860 (also reproduced below)
](https://paste.opensuse.org/42337860)


2021-01-10 14:34:37.751+0000: shutting down, reason=failed
2021-01-10 14:35:11.450+0000: starting up libvirt version: 6.10.0, qemu version: 5.2.0openSUSE Tumbleweed, kernel: 5.10.4-1-default, hostname: freedombox.flesh.space
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
HOME=/var/lib/libvirt/qemu/domain-13-nixos-gnome_20.9 \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-13-nixos-gnome_20.9/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-13-nixos-gnome_20.9/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-13-nixos-gnome_20.9/.config \
QEMU_AUDIO_DRV=spice \
/usr/bin/qemu-system-x86_64 \
-name guest=nixos-gnome_20.9,debug-threads=on \
-S \
-object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-13-nixos-gnome_20.9/master-key.aes \
-machine pc-q35-5.2,accel=kvm,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram \
-cpu Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hle=off,rtm=off \
-m 3072 \
-object memory-backend-ram,id=pc.ram,size=3221225472 \
-overcommit mem-lock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid 62845df6-c8b1-432f-bbbc-39ba05123a8b \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=30,server,nowait \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-reboot \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot strict=on \
-device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/nixos-gnome_20.9.qcow2","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":false,"no-flush":true},"driver":"qcow2","file":"libvirt-2-storage","backing":null}' \
-device virtio-blk-pci,bus=pci.4,addr=0x0,drive=libvirt-2-format,id=virtio-disk0,bootindex=2,write-cache=on \
-blockdev '{"driver":"file","filename":"/home/mg/misc/iso/nixos-gnome-20.09.2497.4a75ca4a4e7-x86_64-linux.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}' \
-device ide-cd,bus=ide.0,drive=libvirt-1-format,id=sata0-0-0,bootindex=1 \
-netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fe:e6:12,bus=pci.1,addr=0x0 \
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=35,server,nowait \
-device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \
-chardev spicevmc,id=charchannel1,name=vdagent \
-device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 \
-device usb-tablet,id=input0,bus=usb.0,port=1 \
-spice port=5900,addr=127.0.0.1,disable-ticketing,image-compression=off,seamless-migration=on \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1 \
-device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 \
-chardev spicevmc,id=charredir1,name=usbredir \
-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \
-object rng-random,id=objrng0,filename=/dev/urandom \
-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 \
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
char device redirected to /dev/pts/2 (label charserial0)
2021-01-10 14:35:11.598+0000: shutting down, reason=failed
6

I should add to this that I also made sure to start the libvirtd service in systemctl.

7

I fought for many days with qemu / kvm. There were two things I had to do

  1. switching the screen graphically squash -> vnc

  2. check / change state network with commands

virsh net-list --all


virsh net-start default


virsh net-autostart default

I hope these tips help :slight_smile:

8

Sorry, I write the first tip wong. It should be like picture below

URL: SUSE Paste

9

Your error is related to setting up your Shared Directory and is unrelated to creating a new VM.

TSU

10

When an error like this describes “process exited while connecting to monitor” that usually in reference to connecting to a remote display.
I’ve usually found these type of errors beyond the capability of a typical User and should be submitted to https://bugzilla.opensuse.org.

TSU

11

You should submit a bug to https://bugzilla.opensuse.org.
A couple of notable things in your post…

  1. You created your br0 manually using bridge-utils. This is fine but suggests that you didn’t install your virtualization using the YaST virtualization module so might be set up with a custom configuration and not the standard configuration set up by YaST. Also, although use of bridge-utils is acceptable (like many other methods), it’s deprecated because tools are now built into the kernel’s ip module.
  2. you’re implementing the spice protocol connecting to the graphical console display which is fine although unless something has changed I’m not aware of, is not the default.

TSU

12

You are not right.
I got this error when I tried to create new VM. In other words when creating guest. And this is fresh installation (first time before I reinstalled Tumbleweed)

Asennus ei onnistu: ”internal error: process exited while connecting to monitor: audio-legacy: Unknown audio driver `spice'”

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createvm.py", line 2081, in _do_async_install
    installer.start_install(guest, meter=meter)
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 731, in start_install
    domain = self._create_guest(
  File "/usr/share/virt-manager/virtinst/install/installer.py", line 679, in _create_guest
    domain = self.conn.createXML(install_xml or final_xml, 0)
  File "/usr/lib64/python3.8/site-packages/libvirt.py", line 4366, in createXML
    raise libvirtError('virDomainCreateXML() failed')
libvirt.libvirtError: internal error: process exited while connecting to monitor: audio-legacy: Unknown audio driver `spice'
13 
And this is fresh installation (first time before I reinstalled Tumbleweed)

And this is fresh installation (first time after I reinstalled Tumbleweed)

14

Is this process documented somewhere? I was unable to use YaST to do any network configuration because my system came with NetworkManager by default. Should I uninstall bridge-utils, delete br0, and redo the process with NetworkManager, so that it uses the kernel and not bridge-utils?

I don’t know anything abou Spice, honestly. I am using all of the defaults in Virt Manager.

Maybe I should make a separate thread? Or just go ahead and submit a bug?

15

I don’t know what you mean by “Process” but the advice to install using the YaST virtualization module has been repeated many times in this Virtualization forum and is described in the openSUSE documentation.

Using Network Manager is possible but not recommended. If you set your Network Manager to connect on boot, it can work otherwise networking is not available when the various virtualization services supporting vms don’t start up in time. If this is an issue (often on personal machines and laptops), I wouldn’t recommend this for a beginner, should install Virtuallbox or VMware Player instead which are apps configured by default not to start up on boot.

As for using bridge-utils, that’s OK. As I described, there are many ways to create bridge objects and bridge-utils is the way to use the older, deprecated brctl commands. The linux kernel today has a set of IP commands which do the same thing so people don’t have to install bridge-utils, both create the same thing that just works…

Spice is an alternative protocol that can be implemented instead of the VNC protocol which unless something has changed should be default. People can use the Spice protocol just fine but may need to be configured. The Spice protocol also has other features and uses not usually needed by libvirt displaying graphical consoles.

Whether you should start over and re-install virtualization the recommended way can only be answered by you.
Beginners either without libvirt experience and especially without any virtualization experience should probably start over so that you can start with a known, working configuration.
If you don’t start over, then you’ll have to spend time reviewing what you did to understand what you have. Without insight knowing what you’re looking at, it’s hard to say how difficult it will be to figure out what you have.

This is the openSUSE 15.2 virtualization guide should also work with Tumbleweed.
I rarely recommend it because the guide naively tries to use the same terminology describing installing and managing Xen and KVM, but for whatever odd reason there are a number of scenarios where the terminology is reversed. Since the documentation seems to be written and maintained by a person whose primary expertise is Xen, it means plenty of KVM terminology mistakes that will have to be unlearned, but aside from that the described steps to accomplish things are usually solid.

https://doc.opensuse.org/documentation/leap/virtualization/html/book-virt/index.html

TSU

16

BTW -
I’ll repeat another recommendation frequently mentioned…

Tumbleweed is a rolling release which based only on the number of changes that constantly happen has a much higher risk level of breakage although hopefully any breakage is quickly reported and noticed, usually fixed fairly quickly. Most breakage are fixed very quickly within a few days or if already reported before you encountered almost immediately. But you never know… there’s always a chance breakage can be substantial in which case you should be very familiar how to recover and possibly roll back changes.

For most normal User apps, the consequences of any breakage are hopefully limited to a specific application for a short period of time.
But, consider that if breakage is the HostOS virtualization, it will affect all the Guests that run on that machine.

If this can be an issue,
Users are strongly recommended to install on a LEAP system instead of Tumbleweed.

TSU

17

Again, AFAIK the spice driver is not default although that may be the case today (things always change without me knowing, and then I have to catch up).

As long as the error is saying that your system is set up to use the spice driver, this is where I’d start… The Spice user manual.
It does have instructions how to configure which likely fix this specific problem

https://www.spice-space.org/spice-user-manual.html

BTW - Your error is not the same as the @OP.
Do not hijack another thread in the future… Create a new thread.

TSU

18

If a “zypper dup” doesn’t solve your problem, pls submit a bug to https:./bugzilla.opensuse.org.

TSU

19

I just gave a hint to thorned how I myself got ahead in creating guest. I don’t try hijack another thread. I wanted just help.
I tried to create guest with defaults, but it didn’t work (in Tumbleweed and in 15.2 Leap). See pic below.
https://paste.opensuse.org/81890415

20

On my system, NetworkManager starts up on boot as a system-level service in Systemd. Either this was the default, or I enabled it in the installer. I don’t recall ever manually installing or enabling NetworkManager.

I did use the YaST virtualization module to install everything KVM related, just to be 100% sure that I had not missed anything with Zypper. But because my system came with NetworkManager enabled by default, YaST failed to configure the bridge networking. That is why I used NetworkManager to create the bridge network.

What virtualization services are required to support VMs? I have libvirtd and libvirtd.ro configured in Systemd to start on socket activation.

I didn’t explicitly use bridge-utils. I created the bridge using NetworkManager. I don’t know if NetworkManager internally uses bridge-utils, or if it’s smart enough to use the kernel-level features.

Again, I am using the default settings provided by the packaged Virt Manager program.

I would not say that I am an experienced libvirt user, but I have had no trouble doing this on Debian with more or less the same setup. I suspect that this is just a matter of misaligned configuration files due to the rolling nature of Tumbleweed, but I don’t know enough to make that determination.

I followed instructions from that document, specifically https://doc.opensuse.org/documentation/leap/virtualization/html/book-virt/cha-vt-installation.html#sec-vt-installation-kvm and here: https://doc.opensuse.org/documentation/leap/virtualization/html/book-virt/cha-kvm-inst.html#sec-libvirt-inst-vmm. The problem I am reporting (and the problem that I believe the OP also had, which is why I posted in the same thread) is that the Virtual Machine Manager GUI fails to install after step 7 with the error I reported.