Hello, If my understanding of migration/snapshots is correct, the target/loading VM must be a clone of the source/saving VM, that is have the same devices, RAM/PCI layout, etc. In the past I have had several issues with Qemu, when the distribution (Debian) updates their packaging of SeaBIOS/iPXE/VgaROM, which changes the the next/previous power-of-2 size and thus changes the PCI layout, preventing me from loading old snapshots. As the BIOS file is provided externally, it is prone to such (accidental) updates. As (AFAIK) libvirt does not track the Qemu version, BIOS files inside its XML data, there's always the danger of making snapshots invalid by updating Qemu and the BIOS files. Some questions: 1. Does Qemu use ROM shadowing, that is copying the ROM to RAM? This makes sense on real HW as ROMs are a low slower than RAM. In that case the content of the "ROM" would already be contained inside the VM-State and it would be enough to provide an "empty ROM file of the right size". 2. If Qemu does no ROM shadowing, what happens if I suspend a VM while executing ROM or SMM code and then doing an SeaBIOS update? (my DOS-assembler knowledge is quiet old nowadays) 3. How do others handle long-term snapshots? Just say "good-bye" to your old snapshots when upgrading to a newer Qemu version or keeping the old, probably unmaintained and vulnerable Qemu/BIOS binaries until the end-of-time? Thanks in advance Philipp -- Philipp Hahn Open Source Software Engineer Univention GmbH be open. Mary-Somerville-Str. 1 D-28359 Bremen Tel.: +49 421 22232-0 Fax : +49 421 22232-99 hahn(a)univention.de http://www.univention.de/ Geschäftsführer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876