<div dir="ltr"><div dir="ltr">This might be of interest to you: <a href="https://www.criu.org">https://www.criu.org</a></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 4, 2018 at 8:23 PM <<a href="mailto:valdis.kletnieks@vt.edu">valdis.kletnieks@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 04 Oct 2018 21:44:14 +0300, Boian Karatotev said:<br>
<br>
> I am a Computer Science student and for my last year I need to make and<br>
> present a 'diploma project' at the end of June. So far I want to make a<br>
> kernel module, whose description is in the following paragraph. I feel<br>
> comfortable with C and my OS knowledge is maybe slightly better than my OS<br>
> course. My question is: Would it possible to pull this off? I have no<br>
> experience with the kernel and I want to get into kernel development, so<br>
> this would be a perfect opportunity for that. My only issue is that this<br>
> may be too complex for my experience.<br>
<br>
> My idea: Something along the lines of checkpoint-restart as a kernel<br>
> module. I want to ultimately be able to migrate a running process to a<br>
> different machine (assuming same at least some basic similarity). I know of<br>
> BLCR <<a href="http://crd.lbl.gov/departments/computer-science/CLaSS/research/BLCR/" rel="noreferrer" target="_blank">http://crd.lbl.gov/departments/computer-science/CLaSS/research/BLCR/</a>><br>
> and I am planning on using it as a guide, although I am unsure about<br>
> working on it directly. As far as I know, the grading process does not<br>
> require this to be 100% complete, so I am aiming at transferring at least<br>
> all the memory, restoring file descriptors and maybe child<br>
> processes/threads.<br>
<br>
You mean you want to re-invent the current checkpoint-restart code that's been<br>
in the kernel since v3.10 back in June 2013? (see kernel/kcmp.c for the gory<br>
details).<br>
<br>
Note that migrating a running process to a different machine is a *lot*<br>
trickier, especially if it has things like open files or network connections.<br>
"Assume at least some basic similarity" isn't anywhere *near* good enough - if<br>
the process has /home/fred/wombats/my_terabyte_database open, you're going to<br>
need to have it at the same place in the filesystem and data synced across to<br>
the new target (particularly fun if the process scribbles some more on the file<br>
while you're busy migrating it, or if it hasn't done an fsync). Similarly, if<br>
it has a TCP connection open to someplace else, you're going to have to figure<br>
out what to do with the IP 4-tuple and sequence numbers to avoid breaking the<br>
connection. And if it's HPC software using MPI configured to do RDMA over<br>
Infiniband, that's even uglier....<br>
<br>
In fact, migrating an entire virtual machine is easier than migrating one<br>
process, because you don't have to worry about recovering the process state,<br>
that's all in kernel memory that you migrate with the VM.  Move the VM, take<br>
down the IP on the old hypervisor, set up the IP on the new one, toss out a<br>
gratuitous ARP packet so other machines on the subnet notice, and you're ready<br>
to go...<br>
<br>
There's a *reason* why VMWare gets away with charging lots of money for their<br>
enterprise-class software that supports migrating a live VM across hypervisors.<br>
It's a lot harder to do than you think.<br>
<br>
_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" rel="noreferrer" target="_blank">https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</blockquote></div>