49 lines
1.5 KiB
ReStructuredText
49 lines
1.5 KiB
ReStructuredText
|
==============
|
||
|
|
Best practices
|
||
|
|
==============
|
||
|
|
|
||
|
|
Debugging
|
||
|
|
=========
|
||
|
|
|
||
|
|
The migration stream can be analyzed thanks to ``scripts/analyze-migration.py``.
|
||
|
|
|
||
|
|
Example usage:
|
||
|
|
|
||
|
|
.. code-block:: shell
|
||
|
|
|
||
|
|
$ qemu-system-x86_64 -display none -monitor stdio
|
||
|
|
(qemu) migrate "exec:cat > mig"
|
||
|
|
(qemu) q
|
||
|
|
$ ./scripts/analyze-migration.py -f mig
|
||
|
|
{
|
||
|
|
"ram (3)": {
|
||
|
|
"section sizes": {
|
||
|
|
"pc.ram": "0x0000000008000000",
|
||
|
|
...
|
||
|
|
|
||
|
|
See also ``analyze-migration.py -h`` help for more options.
|
||
|
|
|
||
|
|
Firmware
|
||
|
|
========
|
||
|
|
|
||
|
|
Migration migrates the copies of RAM and ROM, and thus when running
|
||
|
|
on the destination it includes the firmware from the source. Even after
|
||
|
|
resetting a VM, the old firmware is used. Only once QEMU has been restarted
|
||
|
|
is the new firmware in use.
|
||
|
|
|
||
|
|
- Changes in firmware size can cause changes in the required RAMBlock size
|
||
|
|
to hold the firmware and thus migration can fail. In practice it's best
|
||
|
|
to pad firmware images to convenient powers of 2 with plenty of space
|
||
|
|
for growth.
|
||
|
|
|
||
|
|
- Care should be taken with device emulation code so that newer
|
||
|
|
emulation code can work with older firmware to allow forward migration.
|
||
|
|
|
||
|
|
- Care should be taken with newer firmware so that backward migration
|
||
|
|
to older systems with older device emulation code will work.
|
||
|
|
|
||
|
|
In some cases it may be best to tie specific firmware versions to specific
|
||
|
|
versioned machine types to cut down on the combinations that will need
|
||
|
|
support. This is also useful when newer versions of firmware outgrow
|
||
|
|
the padding.
|