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).
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.
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.
Regards,
Anthony Liguori
- Sebastian
