Re: Migration filesystem coherency?

[John Byrne <john.l.byrne@hp.com>]

Ian Pratt wrote:
>> I thought I had a workaround for live migration crashing 
>> (I've been looking at the SLES 3.0.2 9742c code.), but I 
>> found that I was getting filesystem errors. I'm wondering if 
>> the problem is races in data being written to the backing storage.
>>
>> When migrating a domain, before the domain is started on the 
>> new host, you have to guarantee that all the domU vbd data is 
>> out of the block cache and written to the backing device. (In 
>> the case of a loopback device, whether this is sufficient 
>> depends on the cross-host coherency guarantees of the backing 
>> filesystem.) I cannot see that this takes place synchronously 
>> with the migration process. To me it looks like that the 
>> teardown/flush of the backing device depends on the action of 
>> the xenbus and the hotplug scripts and looks asynchronous to 
>> the migration process.
>>
>> So, am I right that there is a really a problem here or is 
>> there some other way the vbd data is getting flushed during migrate?
> 
> The loop device doesn't do direct IO, so using it for migration is
> fundamentally unsafe. See Andrew/Julians's blktap patches for a way to
> do safe file-backed VMs. 
> 
> Ian 
> 

Ian,

At the moment, I'm trying a shared physical disk. Should that work? If 
so, what code is guaranteeing the data is written to disk before the 
domain starts executing on the new host?

As to loopback, regardless of what kind of I/O it does, when the 
loopback device is torn down, all I/O should be committed to, at least, 
the VFS layer of the backing filesystem. If the backing filesystem makes 
the proper coherency guarantees, then this should be sufficient. My 
understanding is that both GFS and OCFS2 make these guarantees. So with 
these filesystems as the backing store, as long as Xen can guarantee the 
tear down before the domain starts executing on the new node, things 
should work, shouldn't they?

Thanks,

John Byrne