Re: vkernel migration
: A great example is already in DragonFly - process checkpointing. I : don't even know how it works as well as it does. : :Has this been coupled with the new vkernel mods yet? In other words, :could I build a checkpointable kernel and then pause it, put it away :for a month, and come back to it? ( Pardon me if I'm sounding naive :here. :) ) :-- :Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] : The opinions expressed above are entirely my own It won't work, but it would not be hard to save and restore the state: * The checkpointing code doesn't understand VPAGETABLE mappings. Offset and page directory settings would have to be saved and restored. * Network (TAP) interface code would have to reopen the interface and re-set its parameters. * Console driver would have to restore the console mode via termios. * Kernel core would have to re-create the VM spaces for the various processes on checkpoint restore (but otherwise would not have to do anything fancy, since the VM spaces are controlled entirely by VPAGETABLE mappings). -Matt Matthew Dillon [EMAIL PROTECTED]
Re: vkernel migration
Nigel Weeks 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...) Nige. Hmm... there is a sort of 'left-handed' precedent.. Before Microslog got its 'one way' licensing mits on Connectix' Virtual PC.. one could close a VPC session in 'save state' - which preserved even the (virtual) program-counter of the (virtal) PC (not to mention registers, stack, memory) in the 'container file' along with everything else. That container file could be-emailed half way 'round the globe, loaded on another VPC-equipped box, and fired up - with the cursor in the same spreadsheet cell as when saved. Or whatever. Whether minutes - or months - earlier. And it fired-up fast. MS later prevented a container created on box A from running on box B. Or even logged-in user A and logged-in user B on the same box. So long as the registers, caches, RAM, stack, and program counter are preserved, it is as portable as the (virtualized?) hardware supports. The IP stack, OTOH, *should* get hairy - but they handle that anyway - as when a network cable is swapped over to a different link and IP. Bill
Re: vkernel migration
Dmitri Nikulin [EMAIL PROTECTED] writes: What? Opening this e-mail is acceptance of the terms specified in this e-mail? Not exactly, according to what I read. Nevertheless it's pretty unenforcable, for the same reasons you can't stop spam. A great example is already in DragonFly - process checkpointing. I don't even know how it works as well as it does. Has this been coupled with the new vkernel mods yet? In other words, could I build a checkpointable kernel and then pause it, put it away for a month, and come back to it? ( Pardon me if I'm sounding naive here. :) ) -- Dave Hayes - Consultant - Altadena CA, USA - [EMAIL PROTECTED] The opinions expressed above are entirely my own We have just enough religion to make us hate, but not enough to make us love one another. --Jonathan Swift
vkernel migration
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...) Nige. Nigel Weeks Tech Support Systems Developer Rural Press Tasmania The Examiner Newspaper 71-75 Paterson St Launceston Tas 7250 Ph. 03 6336 7234 Mob. 0408 133 738 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.
Re: vkernel migration
On 2/1/07, Nigel Weeks [EMAIL PROTECTED] 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
RE: vkernel migration
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? Yep - standard footer for the enterprise. If you open it, and it goes boom, it's not our fault...;-) N.
