Difference between revisions of "P.Haul"
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | P.Haul is an extension to CRIU that makes [[live migration]] with CRIU possible. The effort first appeared as [[Py-P.Haul|python script(s)]], but due to high complexity of python code integration, it was switched into Go. Right now the sources are in [https://github.com/ | + | P.Haul is an extension to CRIU that makes [[live migration]] with CRIU possible. The effort first appeared as [[Py-P.Haul|python script(s)]], but due to high complexity of python code integration, it was switched into Go. Right now the sources are in [https://github.com/checkpoint-restore/go-criu go-criu] repository. |
== Description == | == Description == | ||
Line 43: | Line 43: | ||
* Add API for FS migration (if necessary) | * Add API for FS migration (if necessary) | ||
* Fix [[Py-P.Haul]] to use this library as a core | * Fix [[Py-P.Haul]] to use this library as a core | ||
+ | |||
+ | == Git == | ||
+ | https://github.com/checkpoint-restore/go-criu | ||
[[Category: Live migration]] | [[Category: Live migration]] | ||
− | [[Category: | + | [[Category: New features]] |
Latest revision as of 18:51, 4 November 2018
P.Haul is an extension to CRIU that makes live migration with CRIU possible. The effort first appeared as python script(s), but due to high complexity of python code integration, it was switched into Go. Right now the sources are in go-criu repository.
Description[edit]
P.Haul library is the pair of Go classes, one to be launched on the source node, the other one on the destination. Users are to import the source into their projects and call function directly. No CLI provided (yet).
Configuration[edit]
Both source and destination should create a PhaulConfig
object that configures client and server. The fields are
Pid
-- the pid of the process subtree to live migrateMemfd
-- file descriptor via which CRIU will send processes' memory contentsWdir
-- path where CRIU can put intermediate files (images, logs, etc.)
Destination[edit]
Destination process is to call phaul.MakePhaulServer
routine, that returns back a handler (and go error). Argument is the PhaulConfig
object described above.
Source[edit]
Source is to call phaul.MakePhaulClient
routine, it also returns a handler (and go error). Arguments are more complex.
The first is PhaulLocal
interface. This one has the single method called DumpCopyRestore
. Once p.haul client and server agree, that all preparations (pre-dumps) are done and it's time to call full dump, copy images and call full restore, this method is called. It's up to go-phaul caller to implement this method, as dumping processes is very engine-specific. E.g. OpenVZ, Docker, LXC all have different ways of invoking the criu dump
operation. In turn, the method accepts
criu.Criu
-- a handler to Criu object from go wrappers using which client may invoke the dump actionPhaulConfig
objectlast_client_images_path
string denoting where the last dump-s are. Needed to configure the incremental dumps for this final step
Next goes the PhaulRemote
interface with a set of methods, that client wants to be called on the server object. It's up to the caller to provide the RPC method for this. E.g. in phaul test the server handler is passed as is as this argument.
The last one is known PhaulConfig
object.
After these preparations, the client.Migrate()
is to be called.
Further development plans[edit]
Right now phaul is an implementation of iterative migration -- it calls pre-dumps several times, then informs the caller to do final dump-copy-restore steps. It's important to note, that it's up to the caller to copy the generated by last criu call images to the destination node.
To improve the above we want to
- Add lazy migration support
- Add automatic images transfer
- Add API for FS migration (if necessary)
- Fix Py-P.Haul to use this library as a core