i have a problem with virtmanager kvm/qemu since the last update.
my ordinary images of 64-bit operating systems still work but i need to run a
32-bit image of linux (in this case debian) for a special application. this was running without complains in the past but after the latest december-update (i’m on stable) the 32-bit debian breaks at the boot with error:
“virtio: device uses modern interface but does not have VIRTIO_F_VERSION1”
did i miss something like an additional package of virtio that i have to install ?
any idea ?
i’m thankful for a solution cause i need this 32-bit debian in a vm.
That could be - but I don’t know - which debian image is you vm based on ?
it’s debian 11 / bullseye but it was running without complains before the last updates.
all 64-bit iso-images are still running, only the 32-bit iso causes the error.
I cannot say what your issue may be - but I’d check the vm settings prior to launching it.
It could be GPU related in some way - I think most issues with virtual machines stem from GPU configuration - so there is that.
Perhaps remove the vm - not deleting the image - then recreate the vm and attach the existing qcow image.
yes there must be the problem, but i have no idea where to start fixing the issue.
i used the ordinary preset of the vm-gpu, no passthrough, nothing specific. just the default and i did not expect such an failure out of nowhere.
is there any package missing that has been deleted with the new update. it wouldn’t surprise me if manjaro has shrinked the packaging another time causing such fails.
this system was working all the time and i need this old 32-bit vm for specific reasons. meanwhile i’m already thinking to throw manjaro from disk and install a different distro. it’s getting worse and more worse with manjaro with every new update.
digging the i-net for
brings up some problems from 2016 and now in 2023 it’s groundhog-day again.
there must be some missing package for kvm/qemu that is missing but what ? how to search for the package ?
It is not the host OS which is at fault here - because I can install debian 11 using libvirt.
Longer time ago Arch changed qemu packaging but if you say it worked before - say December 1. then there is nothing which has changed.
You could run
sudo pacman -Syu qemu-full
the full package was installed, redoing and refreshing didn’t solve the problem.
My tests using a 32bit Debian image shows no issues with creating and running.
nix@debian:~$ inxi -SM
System:
Host: debian Kernel: 5.10.0-26-686-pae i686 bits: 32
Desktop: LXQt 0.16.1 Distro: Debian GNU/Linux 11 (bullseye)
Machine:
Type: Kvm System: QEMU product: Standard PC (Q35 + ICH9, 2009)
v: pc-q35-8.1 serial: <superuser required>
Mobo: N/A model: N/A serial: N/A BIOS: SeaBIOS
v: Arch Linux 1.16.3-1-1 date: 04/01/2014
As I suggested yesterday.
- Open your virtual machine manager
- Rightclick you vm and select Delete
- When queried remove the checkbox in remove storage so you keep you virtual machine disk
Then recreate your vm and attach the existing virtual machine disk
Below is the xml file for the vm I created - it is a default - except from the location - perhaps you can deduct something from it
<domain type="kvm">
<name>debian11</name>
<uuid>59783a19-2d4b-46bb-acc0-bb6bc4fe6be6</uuid>
<metadata>
<libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
<libosinfo:os id="http://debian.org/debian/11"/>
</libosinfo:libosinfo>
</metadata>
<memory unit="KiB">2097152</memory>
<currentMemory unit="KiB">2097152</currentMemory>
<vcpu placement="static">2</vcpu>
<os>
<type arch="x86_64" machine="pc-q35-8.1">hvm</type>
<boot dev="hd"/>
</os>
<features>
<acpi/>
<apic/>
<vmport state="off"/>
</features>
<cpu mode="host-passthrough" check="none" migratable="on"/>
<clock offset="utc">
<timer name="rtc" tickpolicy="catchup"/>
<timer name="pit" tickpolicy="delay"/>
<timer name="hpet" present="no"/>
</clock>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<pm>
<suspend-to-mem enabled="no"/>
<suspend-to-disk enabled="no"/>
</pm>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type="file" device="disk">
<driver name="qemu" type="qcow2" discard="unmap"/>
<source file="/a/virtualbox/libvirt/debian11.qcow2"/>
<target dev="vda" bus="virtio"/>
<address type="pci" domain="0x0000" bus="0x04" slot="0x00" function="0x0"/>
</disk>
<disk type="file" device="cdrom">
<driver name="qemu" type="raw"/>
<target dev="sda" bus="sata"/>
<readonly/>
<address type="drive" controller="0" bus="0" target="0" unit="0"/>
</disk>
<controller type="usb" index="0" model="qemu-xhci" ports="15">
<address type="pci" domain="0x0000" bus="0x02" slot="0x00" function="0x0"/>
</controller>
<controller type="pci" index="0" model="pcie-root"/>
<controller type="pci" index="1" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="1" port="0x10"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0" multifunction="on"/>
</controller>
<controller type="pci" index="2" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="2" port="0x11"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x1"/>
</controller>
<controller type="pci" index="3" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="3" port="0x12"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x2"/>
</controller>
<controller type="pci" index="4" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="4" port="0x13"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x3"/>
</controller>
<controller type="pci" index="5" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="5" port="0x14"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x4"/>
</controller>
<controller type="pci" index="6" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="6" port="0x15"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x5"/>
</controller>
<controller type="pci" index="7" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="7" port="0x16"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x6"/>
</controller>
<controller type="pci" index="8" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="8" port="0x17"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x7"/>
</controller>
<controller type="pci" index="9" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="9" port="0x18"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x0" multifunction="on"/>
</controller>
<controller type="pci" index="10" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="10" port="0x19"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x1"/>
</controller>
<controller type="pci" index="11" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="11" port="0x1a"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x2"/>
</controller>
<controller type="pci" index="12" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="12" port="0x1b"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x3"/>
</controller>
<controller type="pci" index="13" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="13" port="0x1c"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x4"/>
</controller>
<controller type="pci" index="14" model="pcie-root-port">
<model name="pcie-root-port"/>
<target chassis="14" port="0x1d"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x03" function="0x5"/>
</controller>
<controller type="sata" index="0">
<address type="pci" domain="0x0000" bus="0x00" slot="0x1f" function="0x2"/>
</controller>
<controller type="virtio-serial" index="0">
<address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/>
</controller>
<interface type="network">
<mac address="52:54:00:fd:e9:fa"/>
<source network="default"/>
<model type="virtio"/>
<address type="pci" domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</interface>
<serial type="pty">
<target type="isa-serial" port="0">
<model name="isa-serial"/>
</target>
</serial>
<console type="pty">
<target type="serial" port="0"/>
</console>
<channel type="unix">
<target type="virtio" name="org.qemu.guest_agent.0"/>
<address type="virtio-serial" controller="0" bus="0" port="1"/>
</channel>
<channel type="spicevmc">
<target type="virtio" name="com.redhat.spice.0"/>
<address type="virtio-serial" controller="0" bus="0" port="2"/>
</channel>
<input type="tablet" bus="usb">
<address type="usb" bus="0" port="1"/>
</input>
<input type="mouse" bus="ps2"/>
<input type="keyboard" bus="ps2"/>
<graphics type="spice" autoport="yes">
<listen type="address"/>
<image compression="off"/>
</graphics>
<sound model="ich9">
<address type="pci" domain="0x0000" bus="0x00" slot="0x1b" function="0x0"/>
</sound>
<audio id="1" type="spice"/>
<video>
<model type="virtio" heads="1" primary="yes"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="2"/>
</redirdev>
<redirdev bus="usb" type="spicevmc">
<address type="usb" bus="0" port="3"/>
</redirdev>
<watchdog model="itco" action="reset"/>
<memballoon model="virtio">
<address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
</memballoon>
<rng model="virtio">
<backend model="random">/dev/urandom</backend>
<address type="pci" domain="0x0000" bus="0x06" slot="0x00" function="0x0"/>
</rng>
</devices>
</domain>
i must not, there’s an registered application running and i had to pay for a new registration if i wanna install the app again. i cloned the image once but both do not work with this manjaro. i’ll try to move the images to a different computer with qemu/kvm installed. it sucks, i have no idea what this last update did and where to find the issue. it’s really disappointing. this error happened in 2016, it was fixed and this update cause that it is back. but why ? and how to solve it ?
removing the vm can be done without harming what ever you have installed in the vm as long as you don’t delete the storage connected to the vm.
what you paid for is inside the vm’s virtual disk - not on your host system.
you could copy the qcow file to a backup media - it that makes you feel more safe …
look in the default location /var/lib/libvirt/images
i know, and i already stated i’ll move the image to a different computer with a real-running linux-distro that does not harm in such a way.
meanwhile the problems with manjaro get worse and worse and more worse and i’m pretty sure that it is because this !"§$%& packaging that breaks constant.
why on earth does this happen ?
why on earth this systematic groundhog-days with manjaro ? i believe this is the only distro where the maintainer do not have any quality-management. it became a simple weird take it or leave it and in this case i leave it.
case closed
I beg your pardon - what you have marked as a solution is not the solution.
there is no problems other than those one is creating for themselves 
You know that the vast majority of packages comes directly from Arch?
What? You are saying that Arch packages has no quality management?
Have a nice day.
If you do this - and it works there
as would be expected
then you have the opportunity to compare the .xml files which contain the VM definition - the now defunct one and the then likely working one.
They should be different and the differences point to what was the cause.
You’ll never actually know otherwise and can just keep assuming that
is constantly breaking.
but, on a side note:
years ago, I was hesitant of using Arch - so I went for Manjaro
But the little differences and the fact that Manjaro stable always lags a little behind was constantly causing me trouble.
Nothing unsolvable - but work and time had to go into it too often.
So eventually I went for Arch and used it quite some time - then some time later I went for EOS (rather: it’s predecessor - I don’t even remember the name now - and then it itself).
ATM I’m trying to live with Mint … not an easy switch when one is used to Arch 
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.