Re: vkernel migration

["Dmitri Nikulin" <dnikulin@xxxxxxxxx>]

On 2/1/07, Nigel Weeks <nweeks@examiner.com.au> wrote:
> Just an idea for thought over your next coffee...
>
> I'm if it would be to conceivably possible to move a vkernel process(and any
> sub-processes it had) to another host? It'd have to stop temporarily, or at
> least, slow down immensely while pumping all the userland data inside the
> vkernel to the other host.
>
> It might just be easier to have a vkernel powered by multiple physical
> kernels (on different machines), giving the appearance of an SMP machine
> inside the vkernel.
>
> (Insert 40,000 lines of code here...)

The considerations are mostly the same for real kernels - you have to
ensure the resident image of the process will still reference the
right host entities like file descriptors, etc. The virtual kernel can
help by insulating its processes from the specifics of the host
kernel, but the virtual kernel itself uses those specifics a lot too.
Basically, the system has to be practically identical for migration to
work.

A great example is already in DragonFly - process checkpointing. I
don't even know how it works as well as it does. It can't magically
switch CPU architectures or compensate for changes in kernel
structures, but it can do a lot more than I thought practical.

As an aside, a few months ago I was thinking about distributed
processing, and that in increasingly heterogeneous networks it's
harder to just migrate processes directly.

The SMP thing you described is a nature of many SSI systems already,
but again, it requires deploying precisely the same environment in so
far as the user processes should not have any sudden changes that
can't be explained in terms of hotplugging. E.g. changing available
RAM is fine because virtual memory makes up for that, but suddenly
removing MMX support really isn't, since the process could have been
in the middle of an MMX instruction set when it was frozen - and
voluntary preemption in this is fraught with problems. Then you have
to "bind" some processes to their hosts because they directly mmap a
device, for instance.

> IMPORTANT NOTICE - The contents of this e-mail may be confidential and is
> intended only for the individual(s) or entity(s) named herein. Any
> unauthorised use of the contents is expressly prohibited. If you have
> received the e-mail in error, please contact the sender by telephone
> immediately and then delete the e-mail. We cannot guarantee that this
> e-mail, attachments or Internet links are free of computer viruses that may
> damage or interfere with data, hardware or software or contains material
> that may contravene local, national or International laws. Opening of this
> e-mail is acceptance on the part of the recipient(s) that he or she accepts
> full responsibility for protecting their computer and associated software
> and systems from any such viruses and materials and absolves Rural Press
> Ltd.

What? "Opening this e-mail is acceptance of the terms specified in this e-mail"?

---
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia