BaSyx / Documentation / ThreadMigration

The goal is to develop a device virtualization and migration service mechanism to secure partitions with Industry 4.0 applications. Snapshot and migration services are important building blocks for convertible Industry 4.0 hypervisor-based field devices. The "snapshots," which are the state of the split, including the management information in the operating system core and registers, can be stored locally or transferred over a network connection and started to another device with identical partition configuration [1-3].

Requirements and Definitions

A container needs to fulfill a process migration concept [4-6] regardless if it is used to stop and saved to resume its action later or if it is transferred from one PikeOS-System to another PikeOS-System.

A migration-able task executes actions on user-level and optional on kernel-level. A migration-able task will be called MigTask. A MigTask will be transferred from one target (source) to another target (sink). The target representing the migration-source will be called MigSource and the target representing the migration-sink will be called MigSink.

Note: A Middleware may manage the transfer or just export the task to restore it later. In this case the Middle takes the role of MigSink out of the targets view. In case of restoring the task it will take the role of MigSource out of the targets view.

User-Level

User-level actions shall be done by a thread included in the MigTask. The thread that manages the migration procedure within a MigTask will be called MigThread. The threads that will be transferred during the migration process or in other words the threads that travel from MigSource to MigSink are called MigTraveler. MigTask will have exactly one MigThread and 1..n MigTraveler.

User-level actions shall be done by a thread included in the MigTask. The thread that manages the migration procedure within a MigTask will be called MigThread. The threads that will be transferred during the migration process or in other words the threads that travel from MigSource to MigSink are called MigTraveler. MigTask will have exactly one MigThread and 1..n MigTraveler.

On this command channel it shall accept commands to:

(i) initialize threads (first boot up)

(ii) receive a container and restore the transferred MigTravelers

(iii) return information about the systems word-size, byte-order, current role/state and support of memory compression

If MigTask is in state MigSink, then it shall accept commands to:

(i) stop and transfer the MigTravelers

(ii) return information about the systems word-size, byte-order, current role/state and support of memory compression

If MigTask is in state MigSource:

(i) MigThread shall change MigTasks state to MigSource if threads where initialized (first boot up) or if it has restored MigTravelers.

(ii) MigThread shall change MigTasks state to MigSink if MigTravelers have been transferred.

PikeOS-Target

All PikeOS systems representing MigSink and MigSource shall run on identical hardware. All PikeOS systems shall offer a partition for migration that is able to run MigTask. A partition that runs MigTask is called MigPartition. MigPartion shall have identical settings including memory mapping on all systems. (It is required to migrate MigTask with identical physical and virtual memory mapping e.g., when DMA is used). MigPartion shall provide access to gate providers and file providers with similar names and rights on all systems.

Note: MigTravler accessing providers have to expect that the applicable file handle will be closed during runtime. Action on this handle might have to re-open the handle.

References:

[1] Fred Douglis and John Ousterhout. 1991. Transparent process migration: design alternatives and the sprite implementation. Softw. Pract. Exper. 21, 8 (Aug. 1991), 757–785. DOI:https://doi.org/10.1002/spe.4380210802

[2] Michael Litzkow and Marvin Solomon: Supporting Checkpointing and Process Migration Outside the UNIX Kernel. In Usenix Conference Proceedings, San Francisco, CA, January 1992, pages 283--290.

[3] Dejan S. Milojicic and Wolfgang Zint and Andreas Dangel, "Task Migration on top of the Mach Microkernel - Design and Implementation", 1992.

[4] Suspend on Linux: https://lwn.net/Articles/243404/.

[5] https://www.kernel.org/doc/Documentation/power/freezing-of-tasks.txt.

[6] Ho, S. L, “Process Migration in Distributed Systems.” (2003)