On Wed, Nov 5, 2025 at 4:49 PM Jinpu Wang <[email protected]> wrote:
>
> Hello QEMU developers,
>
> I’m encountering a migration failure when trying to live-migrate a VM
> from a newer host (kernel 6.12 + QEMU 9.2.4) to an older one (kernel
> 6.1 + QEMU 8.2.10).
> Migration in the forward direction (old → new) works fine, but after
> rebooting the guest on the new host, migration back to the old host
> fails.
>
> ________________________________
>
> Issue summary
>
> Source host: kernel 6.12, QEMU 9.2.4
>
> Destination host: kernel 6.1, QEMU 8.2.10
>
> VM type: pc-q35-8.2, using virtio-net-pci with vhost backend
>
> Symptom: Migration from 9.2.4 → 8.2.10 fails with virtio-net load error.
>
> Error log (destination):
>
> 2025-09-23T07:06:14.915708Z qemu-8.2: Features 0x1c0010130afffa7
> unsupported. Allowed features: 0x179bfffe7
> 2025-09-23T07:06:14.915843Z qemu-8.2: Failed to load virtio-net:virtio
> 2025-09-23T07:06:14.915851Z qemu-8.2: error while loading state for
> instance 0x0 of device '0000:00:02.0:06.0/virtio-net'
> 2025-09-23T07:06:14.917894Z qemu-8.2: load of migration failed:
> Operation not permitted
>
> ________________________________
>
> Analysis
>
> It appears that virtio-net feature bits differ between the two versions.
> On QEMU 9.2.4, virtio-net reports additional features:
>
> VIRTIO_F_RING_RESET
>
> VIRTIO_NET_F_HOST_USO
>
> VIRTIO_NET_F_GUEST_USO4
>
> VIRTIO_NET_F_GUEST_USO6
>
> These are not present (or not supported) on QEMU 8.2.10, which causes
> the migration state load to fail.

Interesting, we've already done the compat work:

GlobalProperty hw_compat_8_1[] = {
    { TYPE_PCI_BRIDGE, "x-pci-express-writeable-slt-bug", "true" },
    { "ramfb", "x-migrate", "off" },
    { "vfio-pci-nohotplug", "x-ramfb-migrate", "off" },
    { "igb", "x-pcie-flr-init", "off" },
    { TYPE_VIRTIO_NET, "host_uso", "off"},
    { TYPE_VIRTIO_NET, "guest_uso4", "off"},
    { TYPE_VIRTIO_NET, "guest_uso6", "off"},
};
const size_t hw_compat_8_1_len = G_N_ELEMENTS(hw_compat_8_1);

>
> The issue seems related to the introduction of these features and how
> they are handled during incoming migration when the target QEMU does
> not recognize them.
>
> ________________________________
>
> Reproduction steps
>
> Start VM on host with QEMU 8.2.10 (kernel 6.1).
>
> Migrate to host with QEMU 9.2.4 (kernel 6.12).
> → Migration succeeds.
>
> Reboot the guest on the 9.2.4 host.
>
> Attempt to migrate back to QEMU 8.2.10 host.
> → Migration fails with virtio-net load error (see log above).
>
> ________________________________
>
> Expected behavior
>
> Migration from newer QEMU to older version should either:
>
> gracefully ignore unsupported virtio-net features, or
>
> fail with a clear compatibility message before starting migration.
>
> Currently, migration starts and fails during device state load.
>
> ________________________________
>
> Related patch
>
> I found this commit that looks relevant but is already included in
> both 8.2.10 and 9.2.4:
>
> https://lore.kernel.org/qemu-devel/[email protected]/
>
> ________________________________
>
> VM configuration
>
> -uuid dbaf0b1f-4dc5-4462-86b1-d82107b58599
> -name Serverwittchendbaf0b1f-4dc5-4462-86b1-d82107b58599
> -M pc-q35-8.2

Could you double check if this is used in both source and destination?

> -accel kvm,kernel-irqchip=split
> -cpu SierraForest-v2
> -smp 7,sockets=128,cores=1,maxcpus=128,threads=1
> -m 4096,slots=252,maxmem=256G
> -bios /usr/share/ovmf/OVMF.fd
> -device 
> virtio-net-pci,netdev=hostnet6,id=net6,mac=02:01:17:9b:9a:35,bus=pci.0,addr=0x6
> -netdev tap,ifname=n0201179b9a35,id=hostnet6,script=no,downscript=no
>
> ________________________________
>
> Question
>
> Is this expected behavior (i.e. migration incompatibility due to newer
> virtio-net feature bits)?

No.

Could you check if

1) those features were enabled or not via "info qtree" when using pc-q35-8.2.
2) whether the migration with if you disabled those features explicitly in 9.2.4

> Or should QEMU handle such feature mismatches more gracefully (e.g.,
> automatically disable unsupported virtio features during migration)?

This would break guests as it could be noticed by guests.

>
> Any guidance on how to make migration between these versions work
> would be appreciated.
>
> ________________________________
>
> Thanks,
> Jinpu Wang @ IONOS Cloud
>

Thanks


Reply via email to