qemu/docs/devel/migration, branch master

docs: Fix some typos (found by typos) and grammar issues

2024-08-16T13:12:59Z

Fix the misspellings of "overriden" also in code comments. Signed-off-by: Stefan Weil Reviewed-by: Peter Maydell Message-Id: <20240813125638.395461-1-sw@weilnetz.de> Reviewed-by: Peter Xu Reviewed-by: Eric Auger Signed-off-by: Alex Bennée Message-Id: <20240813202329.1237572-20-alex.bennee@linaro.org>

migration/docs: Update postcopy recover session for SETUP phase

2024-06-21T12:47:59Z

Firstly, the "Paused" state was added in the wrong place before. The state machine section was describing PostcopyState, rather than MigrationStatus. Drop the Paused state descriptions. Then in the postcopy recover session, add more information on the state machine for MigrationStatus in the lines. Add the new RECOVER_SETUP phase. Reviewed-by: Fabiano Rosas Signed-off-by: Peter Xu [fix typo s/reconnects/reconnect] Signed-off-by: Fabiano Rosas

migration: Add documentation for fdset with multifd + file

2024-06-21T12:47:22Z

With the last few changes to the fdset infrastructure, we now allow multifd to use an fdset when migrating to a file. This is useful for the scenario where the management layer wants to have control over the migration file. By receiving the file descriptors directly, QEMU can delegate some high level operating system operations to the management layer (such as mandatory access control). The management layer might also want to add its own headers before the migration stream. Document the "file:/dev/fdset/#" syntax for the multifd migration with mapped-ram. The requirements for the fdset mechanism are: - the fdset must contain two fds that are not duplicates between themselves; - if direct-io is to be used, exactly one of the fds must have the O_DIRECT flag set; - the file must be opened with WRONLY on the migration source side; - the file must be opened with RDONLY on the migration destination side. Reviewed-by: Peter Xu Signed-off-by: Fabiano Rosas

docs/migration: add uadk compression feature

2024-06-14T17:01:29Z

Document UADK(User Space Accelerator Development Kit) library details and how to use that for migration. Signed-off-by: Shameer Kolothum Reviewed-by: Zhangfei Gao [s/Qemu/QEMU in docs] Signed-off-by: Fabiano Rosas

docs/migration: add qpl compression feature

2024-06-14T17:01:28Z

add Intel Query Processing Library (QPL) compression method introduction Signed-off-by: Yuan Liu Reviewed-by: Nanhai Zou Reviewed-by: Fabiano Rosas Acked-by: Peter Xu Signed-off-by: Fabiano Rosas

migration: Remove block migration

2024-05-08T12:20:58Z

The block migration has been considered obsolete since QEMU 8.2 in favor of the more flexible storage migration provided by the blockdev-mirror driver. Two releases have passed so now it's time to remove it. Deprecation commit 66db46ca83 ("migration: Deprecate block migration"). Reviewed-by: Markus Armbruster Reviewed-by: Peter Xu Signed-off-by: Fabiano Rosas

migration: cpr-reboot documentation

2024-03-13T14:59:25Z

Signed-off-by: Steve Sistare Reviewed-by: Cédric Le Goater Reviewed-by: Fabiano Rosas Link: https://lore.kernel.org/r/1710338119-330923-1-git-send-email-steven.sistare@oracle.com Signed-off-by: Peter Xu

migration/multifd: Don't fsync when closing QIOChannelFile

2024-03-11T18:41:40Z

Commit bc38feddeb ("io: fsync before closing a file channel") added a fsync/fdatasync at the closing point of the QIOChannelFile to ensure integrity of the migration stream in case of QEMU crash. The decision to do the sync at qio_channel_close() was not the best since that function runs in the main thread and the fsync can cause QEMU to hang for several minutes, depending on the migration size and disk speed. To fix the hang, remove the fsync from qio_channel_file_close(). At this moment, the migration code is the only user of the fsync and we're taking the tradeoff of not having a sync at all, leaving the responsibility to the upper layers. Fixes: bc38feddeb ("io: fsync before closing a file channel") Reviewed-by: "Daniel P. Berrangé" Signed-off-by: Fabiano Rosas Link: https://lore.kernel.org/r/20240305195629.9922-1-farosas@suse.de Link: https://lore.kernel.org/r/20240305174332.2553-1-farosas@suse.de [peterx: add more comment to the qio_channel_close()] Signed-off-by: Peter Xu

migration/ram: Introduce 'mapped-ram' migration capability

2024-03-01T07:42:04Z

Add a new migration capability 'mapped-ram'. The core of the feature is to ensure that RAM pages are mapped directly to offsets in the resulting migration file instead of being streamed at arbitrary points. The reasons why we'd want such behavior are: - The resulting file will have a bounded size, since pages which are dirtied multiple times will always go to a fixed location in the file, rather than constantly being added to a sequential stream. This eliminates cases where a VM with, say, 1G of RAM can result in a migration file that's 10s of GBs, provided that the workload constantly redirties memory. - It paves the way to implement O_DIRECT-enabled save/restore of the migration stream as the pages are ensured to be written at aligned offsets. - It allows the usage of multifd so we can write RAM pages to the migration file in parallel. For now, enabling the capability has no effect. The next couple of patches implement the core functionality. Acked-by: Markus Armbruster Reviewed-by: Peter Xu Signed-off-by: Fabiano Rosas Link: https://lore.kernel.org/r/20240229153017.2221-8-farosas@suse.de Signed-off-by: Peter Xu

docs/devel/migration.rst: Document the file transport

2024-02-28T03:31:28Z

When adding the support for file migration with the file: transport, we missed adding documentation for it. Signed-off-by: Fabiano Rosas Reviewed-by: Peter Xu Link: https://lore.kernel.org/r/20240220224138.24759-2-farosas@suse.de Signed-off-by: Peter Xu