Live Migrating VFIO, vhost-user, and vfio-user Devices
summary
QEMU today migrates devices by serializing runtime state and launching a full destination VM; vhost-user takeover stops the out‑of‑process device, QEMU copies vring state and restarts it but cannot migrate internal state. VFIO reads/writes a vfio migration region so the device controls its opaque binary state; proposal adds device model/version strings exposed via mdev sysfs and vfio-user CLI so compatibility can be prechecked and migrations between implementations succeed if versions match, at the cost of baking creation parameters into versions.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 0:46How are migration
- 1:24Device state
- 2:46Why isnt everything part of device state
- 3:35Challenges
- 5:51vhostuser migration
- 8:27busvmstate
- 9:27VFIO
- 12:06Migration Compatibility
- 14:29Migration Challenges
- 15:48VFIO User Migration
- 19:03Upgrading Versions
- 20:29How does this work
- 21:18Advantages and disadvantages
- 22:24Future directions
related talks
40mVirtual Topology for Virtual Machines: Friend or Foe?
28mExploring an Architecture-neutral KVM MMU
15mvBOIDs: Taming Chaos via Coarse-Grained Scheduling Abstraction for Containers
19mKVM/ARM at Scale: Improvements to the MMU in the Face of Hardware Growing Pains
44mUserspace Assisted Scheduling via Sc...
27mInsights on the Re-Architecting to a Single Codebase, Running on Different Hardware...
41mFuture of Zephyr Device Model
15mLeveling Up Kubevirt-Manager: New Features, Better UX, and Real-World Usability