[cap-talk] Moving running applications

David Hopwood david.hopwood at industrial-designers.co.uk
Mon Nov 26 19:24:57 EST 2007


Jed Donnelley wrote:
> On 11/21/2007 5:18 PM, Norman Hardy wrote:
>> I highly recommend the talk by Eric Traut of Microsoft that is online at
>> http://endeavour.acm.uiuc.edu/UIUC-ACM-RP07-Traut.wmv
> 
> I was also favorably impressed by this talk.  I can add my
> recommendation.  I took some notes at home that perhaps I'll
> share at some future time.  However, here I want to comment
> on:
> 
>> I.  Moving a running app to another platform is something that Keykos  
>> could perhaps not easily do; we had did not try to design such a scheme.
>> II.  VMware does this and MinWin claims they will too.
>> III.  The VM provides a natural cleavage point to do this.
> 
> I'm at least a little bit surprised by pretty much all
> of the above.  Let me address them one at a time:
> 
> I.  You say that Keykos (perhaps?) could not easily move an
> application from one 'platform' to another:
> 
> I believe that with a mechanism like the DCCS (which I
> believe KeyKOS could support?) or MarkM's "vat" mechanism
> there is a straight forward way to move a running application
> from one 'platform' to another.

KeyKOS was not, and CapROS is not, a distributed capability system.
They're local capability systems. In particular, they support shared
memory, in the sense that more than one domain can access the same
memory segment via direct memory operations, rather than via invocations.

It would be possible to implement distributed shared memory, but it's
not at all clear that this is actually what we want. (Do I need to
go into the arguments against full network transparency in shared
memory systems? I think I'd be mostly preaching to the converted on
this list.)

> II.  Regarding "VMware does this and MinWin
> claims they will too." where 'this' is to
> move running applications - I'm skeptical
> of this claim.  I have heard and can
> understand a more limited claim.  As
> long as a VM can be moved to another
> platform that can assume the same network
> address (or addresses), then I can accept
> that this can work (even then there may
> be some hazards).

One of the networking options that VMware supports is a NAT
(network address translator) mode that supports port forwarding.
So any given connection can be forwarded via the NAT when a VM
instance moves. Google "VMware NAT" for details.

> III.  Regarding "The VM provides a natural
> cleavage point to do this." - to me it
> doesn't, precisely because of these device/
> communication issues.  In an object/capability
> system requests are abstracted from any
> underlying device (e.g. network) infrastructure.

It isn't strictly necessary for a system to use a pure message
passing architecture, for it to provide sufficient abstraction from
underlying devices to support migration. The design will probably be
cleaner if it does use pure message passing, because otherwise special
case treatment of particular kinds of device may be required -- but
many VMM implementations seem to have managed to implement this anyway.

-- 
David Hopwood


More information about the cap-talk mailing list