#
8d60280e |
| 17-Jun-2024 |
Fabiano Rosas <farosas@suse.de> |
migration: Add documentation for fdset with multifd + file
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 th
migration: Add documentation for fdset with multifd + file
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 <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
show more ...
|
#
4ed49feb |
| 29-Feb-2024 |
Fabiano Rosas <farosas@suse.de> |
migration/ram: Introduce 'mapped-ram' migration capability
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 res
migration/ram: Introduce 'mapped-ram' migration capability
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 <armbru@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240229153017.2221-8-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
show more ...
|