[libvirt] RFC: Qemu/SeaBIOS/VGA/PXE upgrades vs. longterm-snapshot/migration

Philipp Hahn hahn at univention.de
Mon Aug 29 06:57:28 UTC 2016


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 at univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876




More information about the libvir-list mailing list