Bug #3323
open
VirtIO V1 not supported (was: virtio (if_vtnet...) not detected on Hetzner cloud (AMD system))
0%
Description
`pciconf -lv` lists a "Virtio network device"
But it does not show up under `ifconfig`. Also the virtio SCSI harddisk is not detected.
Just curious if I am doing anything wrong.
Files
Updated by mneumann about 3 years ago
`pciconf -lv` on the "Intel" system looks like.
The difference here is that on the Intel system, virtio has `rev=0`, while on the AMD system it has `rev=1`. Is this a different version of VirtIO?
Updated by daftaupe almost 3 years ago
Could it be linked to the fact that one can choose to use either i440FX or Q35 as the chipset for KVM ?
I had some issues with the latter and had to use i440FX to have working (reckognized) vtnet at least (also AMD-based)
Looks like FreeBSD had to work on some drivers to make Q35-based vms to work properly too : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922
Updated by mneumann almost 3 years ago
daftaupe wrote in #note-2:
Could it be linked to the fact that one can choose to use either i440FX or Q35 as the chipset for KVM ?
I had some issues with the latter and had to use i440FX to have working (reckognized) vtnet at least (also AMD-based)Looks like FreeBSD had to work on some drivers to make Q35-based vms to work properly too : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922
See "comment 8" https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922#c8:
The device IDs you are seeing are for the VirtIO V1 spec. FreeBSD only supports the pre-V1 (aka legacy) VirtIO spec. I suppose there was a QEMU change to use V1 with Q35 chipset.
So the real problem is that we do not support the newer VirtIO specification.
Updated by liweitianux 2 days ago
From a later comment in the FreeBSD bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922#c77
Just wanted to confirm that changing all model strings from "virtio" (or "virtio-scsi") to "virtio-transitional" is a sufficient workaround for booting FreeBSD 12.3 on a Q35 VM on libvirt+QEMU.
Updated by liweitianux 2 days ago
- Subject changed from virtio (if_vtnet...) not detected on Hetzner cloud (AMD system) to VirtIO V1 not supported (was: virtio (if_vtnet...) not detected on Hetzner cloud (AMD system))
Updated by liweitianux 2 days ago
- Related to Bug #3299: DragonFlyBSD reports utterly wrong uptime (most of the time, right after booting in) added
Updated by daftaupe 2 days ago
From my test today, it's possible to have a Q35 chipset and "virtio-transitional" devices. I was able to install and boot the system using
<devices>
<...>
<disk type='file' device='disk' model='virtio-transitional'>
<driver name='qemu' type='qcow2' discard='unmap'/>
<source file='/var/lib/libvirt/images/dragonflybsd.qcow2'/>
<backingStore/>
<target dev='vda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>
<...>
<interface type='bridge'>
<mac address='52:54:00:4f:cc:ff'/>
<source bridge='virbr0'/>
<model type='virtio-transitional'/>
<address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/>
</interface>
<...>
</devices>
They appear as
virtio_pci0@pci0:2:1:0: class=0x020000 card=0x00011af4 chip=0x10001af4 rev=0x00 hdr=0x00
vendor = 'Red Hat, Inc.'
device = 'Virtio network device'
class = network
subclass = ethernet
virtio_pci1@pci0:4:0:0: class=0x010000 card=0x00021af4 chip=0x10011af4 rev=0x00 hdr=0x00
vendor = 'Red Hat, Inc.'
device = 'Virtio block device'
class = mass storage
subclass = SCSI
The qemu command line contains -machine pc-q35-10.0
I'll try to upstream these requirements in https://gitlab.com/libosinfo as it's being used by virt-manager at least and it's the one I'm using.