Disk migration

Disk migration

[Haydn Solomon]

[-- Attachment #1.1: Type: text/plain, Size: 377 bytes --]

I see that vmware just demonstrated migration of virtual disks. I know that
kvm is very young but I think has come a long way in a very short period. I
just wanted to get some feedback/discussion on how difficult this would be
to implement in kvm/qemu and if this would be anywhere in future plans for
development? Would this be less complicated than live migration of memory?

[-- Attachment #1.2: Type: text/html, Size: 383 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Disk migration

[Anthony Liguori]

Haydn Solomon wrote:
> I see that vmware just demonstrated migration of virtual disks. I know 
> that kvm is very young but I think has come a long way in a very short 
> period. I just wanted to get some feedback/discussion on how difficult 
> this would be to implement in kvm/qemu and if this would be anywhere 
> in future plans for development? Would this be less complicated than 
> live migration of memory?

Disk migration is super easy to implement in KVM.  There are two basic 
models you can follow to do disk migration.  In a push model, you would 
apply a similar algorithm to the memory migration algorithm whereas you 
pushed the whole disk over in chunks keeping track of what bits on disk 
have been dirtied.  You'd converge after a certain number of iterations 
and then perform the memory migration.

A pull model would immediately do the memory migration and allow QEMU to 
continue running on the source node acting as an IO server.  Any disk IO 
from the guest would either go directly to disk if the block was present 
or would be fetched from the QEMU instance on the source node.  The only 
trick here is that you'd want to continue transferring blocks even when 
the guest isn't accessing the disk.

The push model may require parallelization of the disk and memory 
convergence depending on how much disk activity the guest is doing.  
That's a pretty interesting problem but it shouldn't be too hard to solve.

The push model has the advantage of having the smallest performance 
impact over time.  The pull model has an advantage of immediately 
reducing CPU usage on the source node at the expense of a potentially 
severe degradation in performance of the guest.  Both models probably 
require roughly the same amount of time for migration completion.

Very good thing for someone looking for a fun task in KVM :-)

Regards,

Anthony Liguori



> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Disk migration

[Dong, Eddie]

>
>The push model may require parallelization of the disk and memory 
>convergence depending on how much disk activity the guest is doing.  
>That's a pretty interesting problem but it shouldn't be too 
>hard to solve.
>
Embed this kind of cache like disk ops (write and read hit always 
goes to local disk, while read miss goes to remote source before
convergence)
feature into IDE device model would be great which will benefit both KVM
& Qemu 
and thus easier to push into Qemu tree. 

thx, eddie

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Disk migration

[Anthony Liguori]

Dong, Eddie wrote:
>> The push model may require parallelization of the disk and memory 
>> convergence depending on how much disk activity the guest is doing.  
>> That's a pretty interesting problem but it shouldn't be too 
>> hard to solve.
>>
>>     
> Embed this kind of cache like disk ops (write and read hit always 
> goes to local disk, while read miss goes to remote source before
> convergence)
> feature into IDE device model would be great which will benefit both KVM
> & Qemu 
> and thus easier to push into Qemu tree. 
>   

I was actually thinking it ought to be another BlockDriver.  There's no 
need to make it part of the device emulation.

Regards,

Anthony Liguori

> thx, eddie
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/