[virt-tools-list] Live migration of iscsi based targets

[Mark van Walraven]

On Wed, Oct 27, 2010 at 11:10:25AM +0200, Gildas Bayard wrote:
> My understanding is that blade A got it's iscsi disk cache up and  
> running and that when the VM comes back, blade A has no way to know that  
> the VM got its disk altered by its stay on blade B for a while. Hence  
> the corruption.

Another possible reason is caching by KVM.  Check in the <disk> element
of the domain definition for one like:

      <driver name='qemu' cache='none'/>

Without it, KVM defaults to 'writethrough' caching, which is not safe
for migration.

Regards,

Mark.