[pve-devel] livemigration with qcow2 writeback, potential cache coherency problem

Alexandre DERUMIER aderumier at odiso.com
Wed Feb 20 15:35:03 CET 2013


Hi, I have just found on qemu-mailing list that live migration of qcow2 with writeback,
can cause problems.
Maybe also for other network storage.


So maybe is better to keep cache=none as default for all storages ? 


----- Mail transféré ----- 

De: "Kevin Wolf" <kwolf at redhat.com> 
À: "Tiziano Müller" <tiziano.mueller at stepping-stone.ch> 
Cc: "Anthony Liguori" <aliguori at us.ibm.com>, qemu-devel at nongnu.org 
Envoyé: Mercredi 20 Février 2013 14:46:03 
Objet: Re: [Qemu-devel] Live migration using qcow2 

On Wed, Feb 20, 2013 at 02:14:47PM +0100, Tiziano Müller wrote: 
> Am Mittwoch, den 20.02.2013, 12:20 +0100 schrieb Kevin Wolf: 
> > On Wed, Feb 20, 2013 at 11:47:56AM +0100, Tiziano Müller wrote: 
> > > Hi everyone 
> > > 
> > > According to http://wiki.qemu.org/Migration/Storage section "Image 
> > > Formats" qemu can't do live migration without data corruption when using 
> > > qcow2 or qed due to the metadata caches. 
> > > Wasn't that fixed by commit 06d9260 ? 
> > 
> > Yes, it is fixed. Depending on your backend, you still need 
> > cache=none/directsync, of course. 
> 
> Thanks for the fast reply. Can you please elaborate on that (or post a 
> link to an explanation): What exactly does the backend have to provide 
> that for example cache=writeback can be used? Is there a way to test for 
> it? 

The problem is about cache coherency. Local files work just fine with 
cache=writeback, but if you migrate to a different host, you get the 
problem that the destination kernel may cache some parts of the image 
while the source is still writing to it. When you do the actual switch 
to the destination host and the backend doesn't take care of 
invalidating that cache, you might (partially) read outdated data. 

Kevin 



More information about the pve-devel mailing list