[vwnc] Live Migration

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Steffen Märcker
> Sent: Monday, July 28, 2008 10:10 AM
> To: [hidden email]
> Subject: [vwnc] Live Migration
>
> Hi there!
>
> I wonder whether it is possible to migrate an running image from one
> virtual machine to another (similar to live migration in Xen and other
> virtualization systems). An image contains all state and data an
> application has. Instead of dumping it to a disk it should be possible to
> transfer it directly to another virtual machine (over a network
> connection) in order to seamlessly migrate between heterogeneous systems.
> Has anybody worked on such a project or can point me to an already
> existing?
>
> Thanks,
> Steffen
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> In the "simplest thing that could work that I can think of" category  
> what about this; run an open-talk agent on the remote machine. When the  
> local machine wants to migrate it saves itself to disk, sends the  
> resulting file to the remote agent and terminates itself. The remote  
> agent starts the image it just received.
>
> Of course there are many nuances but I don't think the important ones  
> will be in avoiding the creation of a file.
>
> Joerg
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On  
>> Behalf
>> Of Steffen Märcker
>> Sent: Monday, July 28, 2008 10:10 AM
>> To: [hidden email]
>> Subject: [vwnc] Live Migration
>>
>> Hi there!
>>
>> I wonder whether it is possible to migrate an running image from one
>> virtual machine to another (similar to live migration in Xen and other
>> virtualization systems). An image contains all state and data an
>> application has. Instead of dumping it to a disk it should be possible  
>> to
>> transfer it directly to another virtual machine (over a network
>> connection) in order to seamlessly migrate between heterogeneous  
>> systems.
>> Has anybody worked on such a project or can point me to an already
>> existing?
>>
>> Thanks,
>> Steffen
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> Hi Steffen!
>
> Steffen Märcker wrote:
>> For me the most important point is "seamlessly": Imagine an
>> application consuming lots of memory, e.g. 1GB. Saving it to disk,
>> tranfering to the remote machinge (perhaps 1GigaBit connection) and
>> starting it again would need more than 8 seconds.
>> What's needed is something like
>> 1. start a remote image and keep it in sync
>
> That sounds like hot-backup. I know of no system / software that
> does hot backup by replicating state of objects in memory.
> Usually both systems perform the same operation on the start
> objects.
>
> Keeping objects in sync across different machines sounds like
> database synchronization, where you have the advantage of
> fully described transactions and atomic state snapshots on
> commit.
>
>> 2. stop the running process and transfer the stack to the
>>    remote machine
>
> see above. Only transfering the stack would mean to sync the
> heap. Even if you want to avoid the one-shot transfer of the
> image you would still need a live connection transporting your
> gigabyte of heap to the other machine plus all the changes
> during the course of your processing (which would mean a
> severe extra network load plus the wait cycles to ensure that
> the target machine received a correct heap fragment). And
> ensuring a consistent state you would end up with some kind
> of transaction handling, which basically boils down to a
> database.
>
>> 3. quit the old image and resume execution in the new one
>> ...not considering other issues like file handles and so.
>
> Which brings all kind of detection problems, like
>   - is the source machine really up/down?
>   - is the target reachable and what means that dropped
>     ack package?
>   - is it save to assume that the source machine will not
>     suddenly be available/restarted again and start
>     working on the same "stack" as I would right now?
>
> For me the problem sounds like it is solved by databases.
>
> Just my two cents
>   Jan

>
>
>
>
>> Hi Steffen!
>>
>> Steffen Märcker wrote:
>>> For me the most important point is "seamlessly": Imagine an
>>> application consuming lots of memory, e.g. 1GB. Saving it to disk,
>>> tranfering to the remote machinge (perhaps 1GigaBit connection) and
>>> starting it again would need more than 8 seconds.
>>> What's needed is something like
>>> 1. start a remote image and keep it in sync
>> That sounds like hot-backup. I know of no system / software that
>> does hot backup by replicating state of objects in memory.
>> Usually both systems perform the same operation on the start
>> objects.
>>
>> Keeping objects in sync across different machines sounds like
>> database synchronization, where you have the advantage of
>> fully described transactions and atomic state snapshots on
>> commit.
>>
>>> 2. stop the running process and transfer the stack to the
>>>    remote machine
>> see above. Only transfering the stack would mean to sync the
>> heap. Even if you want to avoid the one-shot transfer of the
>> image you would still need a live connection transporting your
>> gigabyte of heap to the other machine plus all the changes
>> during the course of your processing (which would mean a
>> severe extra network load plus the wait cycles to ensure that
>> the target machine received a correct heap fragment). And
>> ensuring a consistent state you would end up with some kind
>> of transaction handling, which basically boils down to a
>> database.
>>
>>> 3. quit the old image and resume execution in the new one
>>> ...not considering other issues like file handles and so.
>> Which brings all kind of detection problems, like
>>   - is the source machine really up/down?
>>   - is the target reachable and what means that dropped
>>     ack package?
>>   - is it save to assume that the source machine will not
>>     suddenly be available/restarted again and start
>>     working on the same "stack" as I would right now?
>>
>> For me the problem sounds like it is solved by databases.
>>
>> Just my two cents
>>   Jan

> Steffen Märcker wrote:
>
>> Basically I am thinking of the way Xen and VMWare implement live  
>> migration. I think virtual machines (at the level of smalltalk an java  
>> vm)  could extend migration to heterogeneous System like x86 Windows  
>> and power  pc linux. The question is, how can this be achieved in  
>> Smalltalk?
>
> One of possibilities would be to tie Smalltalk VM to VMware memory  
> management, so that VMware would actually do a migration, not Smalltalk  
> VM. What virtualization engine is usually doing is saving parts of  
> memory to disk in advance so that when you do a snapshot, just  a small  
> amount of memory still needs to be saved and this is quick.
>
> Something like that needs therefore to be achieved with VM too. VM  
> standalone or with help of underlying virtualization engine, as I said.
>
> JAnko
>
>
>>
>>> Hi Steffen!
>>>
>>> Steffen Märcker wrote:
>>>> For me the most important point is "seamlessly": Imagine an
>>>> application consuming lots of memory, e.g. 1GB. Saving it to disk,
>>>> tranfering to the remote machinge (perhaps 1GigaBit connection) and
>>>> starting it again would need more than 8 seconds.
>>>> What's needed is something like
>>>> 1. start a remote image and keep it in sync
>>> That sounds like hot-backup. I know of no system / software that
>>> does hot backup by replicating state of objects in memory.
>>> Usually both systems perform the same operation on the start
>>> objects.
>>>
>>> Keeping objects in sync across different machines sounds like
>>> database synchronization, where you have the advantage of
>>> fully described transactions and atomic state snapshots on
>>> commit.
>>>
>>>> 2. stop the running process and transfer the stack to the
>>>>    remote machine
>>> see above. Only transfering the stack would mean to sync the
>>> heap. Even if you want to avoid the one-shot transfer of the
>>> image you would still need a live connection transporting your
>>> gigabyte of heap to the other machine plus all the changes
>>> during the course of your processing (which would mean a
>>> severe extra network load plus the wait cycles to ensure that
>>> the target machine received a correct heap fragment). And
>>> ensuring a consistent state you would end up with some kind
>>> of transaction handling, which basically boils down to a
>>> database.
>>>
>>>> 3. quit the old image and resume execution in the new one
>>>> ...not considering other issues like file handles and so.
>>> Which brings all kind of detection problems, like
>>>   - is the source machine really up/down?
>>>   - is the target reachable and what means that dropped
>>>     ack package?
>>>   - is it save to assume that the source machine will not
>>>     suddenly be available/restarted again and start
>>>     working on the same "stack" as I would right now?
>>>
>>> For me the problem sounds like it is solved by databases.
>>>
>>> Just my two cents
>>>   Jan
>
>

> In the Java camp is an intersting framework, namely "Mobile Jikes RVM"
> enabling applications to transfer their execution stack to another
> virtual machine and resume computation:
> http://mars.ing.unimo.it/wiki/index.php/Mobile_JikesRVM
>
> Steffen
>
>
> Am 30.07.2008, 22:08 Uhr, schrieb Janko Mivšek <[hidden email]>:
>
>> Steffen Märcker wrote:
>>
>>> Basically I am thinking of the way Xen and VMWare implement live  
>>> migration. I think virtual machines (at the level of smalltalk an
>>> java vm)  could extend migration to heterogeneous System like x86
>>> Windows and power  pc linux. The question is, how can this be
>>> achieved in Smalltalk?
>>
>> One of possibilities would be to tie Smalltalk VM to VMware memory
>> management, so that VMware would actually do a migration, not
>> Smalltalk VM. What virtualization engine is usually doing is saving
>> parts of memory to disk in advance so that when you do a snapshot,
>> just  a small amount of memory still needs to be saved and this is quick.
>>
>> Something like that needs therefore to be achieved with VM too. VM
>> standalone or with help of underlying virtualization engine, as I said.
>>
>> JAnko
>>
>>
>>>
>>>> Hi Steffen!
>>>>
>>>> Steffen Märcker wrote:
>>>>> For me the most important point is "seamlessly": Imagine an
>>>>> application consuming lots of memory, e.g. 1GB. Saving it to disk,
>>>>> tranfering to the remote machinge (perhaps 1GigaBit connection) and
>>>>> starting it again would need more than 8 seconds.
>>>>> What's needed is something like
>>>>> 1. start a remote image and keep it in sync
>>>> That sounds like hot-backup. I know of no system / software that
>>>> does hot backup by replicating state of objects in memory.
>>>> Usually both systems perform the same operation on the start
>>>> objects.
>>>>
>>>> Keeping objects in sync across different machines sounds like
>>>> database synchronization, where you have the advantage of
>>>> fully described transactions and atomic state snapshots on
>>>> commit.
>>>>
>>>>> 2. stop the running process and transfer the stack to the
>>>>>    remote machine
>>>> see above. Only transfering the stack would mean to sync the
>>>> heap. Even if you want to avoid the one-shot transfer of the
>>>> image you would still need a live connection transporting your
>>>> gigabyte of heap to the other machine plus all the changes
>>>> during the course of your processing (which would mean a
>>>> severe extra network load plus the wait cycles to ensure that
>>>> the target machine received a correct heap fragment). And
>>>> ensuring a consistent state you would end up with some kind
>>>> of transaction handling, which basically boils down to a
>>>> database.
>>>>
>>>>> 3. quit the old image and resume execution in the new one
>>>>> ...not considering other issues like file handles and so.
>>>> Which brings all kind of detection problems, like
>>>>   - is the source machine really up/down?
>>>>   - is the target reachable and what means that dropped
>>>>     ack package?
>>>>   - is it save to assume that the source machine will not
>>>>     suddenly be available/restarted again and start
>>>>     working on the same "stack" as I would right now?
>>>>
>>>> For me the problem sounds like it is solved by databases.
>>>>
>>>> Just my two cents
>>>>   Jan
>>
>>
>
>