Anthony Liguori wrote:
On 12/21/2009 12:24 PM, Sebastian Herbszt wrote:
As stated before i don't like the idea of automagically upgrading the
firmware
on reset, e.g. after a live migration to a newer qemu version. You
have explained
that qemu-kvm needs this in order to work with live migration and
changed hw
support because of bug fixes. Is this only needed in the kvm case?
It's not "needed", it's desired. The same case can be made for real
hardware (automated firmware updates).
Tho on real hardware those updates are initiated by someone and not
automagic.
Does any OS (Windows?) depend on the tables the bios creates (e.g.
smbios)
for licensing? It would be ugly if Windows wants you to re-activate
after a reboot
following a migration to newer qemu version and therefore possibly
changed tables
due to newer bios.
Yes, and this is a good point. ACPI table changes can absolutely cause
re-activation. If we migrate from 0.12 -> 0.13 and make major changes
to the ACPI tables in 0.13, then it's very likely that will result in
problems for Windows guests.
Another problem could be on guest resume from S3 after migration if the
bios or acpi tables change.
I really think that we need to snapshot the FW and store it with the
guest state. If we switch all FW to be allocated with qemu_ram_alloc()
and we use an id mechanism, then this will Just Work for savevm based
snapshots and live migration. However, for it to work with -M pc-0.11
started from a cold boot, we need an nvram file. We probably want to
make available versioned nvram files from each release too.
So the idea is to store the bios/option roms in the guest state and read them
from there on reset or power cycle?
- Sebastian
