From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53182) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHu8d-00067M-C4 for qemu-devel@nongnu.org; Tue, 19 Mar 2013 06:51:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UHu8Y-0002rc-Ja for qemu-devel@nongnu.org; Tue, 19 Mar 2013 06:51:27 -0400 Received: from smtp.citrix.com ([66.165.176.89]:55092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UHu8Y-0002rT-Er for qemu-devel@nongnu.org; Tue, 19 Mar 2013 06:51:22 -0400 Message-ID: <51484328.4030301@eu.citrix.com> Date: Tue, 19 Mar 2013 10:51:20 +0000 From: George Dunlap MIME-Version: 1.0 References: <1363609123-20748-1-git-send-email-alex@alex.org.uk> <51471767.8030604@redhat.com> <7AC8953FE45335FB794B6DFE@Ximines.local> <51471F14.7030209@redhat.com> <6D0F4ACDA3B7FCF1A50F8B52@Ximines.local> <5147298C.8080900@redhat.com> <51473E82.1020806@redhat.com> <861AFE1A9C44444FD8BAEE16@Ximines.local> <5147512E.5050501@eu.citrix.com> <5147562E.1090203@redhat.com> <5148414C.7060303@redhat.com> In-Reply-To: <5148414C.7060303@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Xen-devel] [PATCHv3] QEMU(upstream): Disable xen's use of O_DIRECT by default as it results in crashes. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Ian Campbell , Stefano Stabellini , Ian Jackson , "qemu-devel@nongnu.org" , xen-devel , Alex Bligh , Anthony Liguori On 03/19/2013 10:43 AM, Paolo Bonzini wrote: >>> Even for successful migration, it would also be bad for downtime (QEMU >>> isn't exactly lightning-fast to start). And even if failure weren't >>> catastrophic, it would be a pity to transfer a few gigs of memory and >>> then find out that QEMU isn't present in the destination. :) >> >> Well, if qemu isn't present at the destination, that's definitely user >> error. :-) In any case, I know that he migrate can resume if it >> fails, so I suspect that the qemu is just paused on the sending side >> until the migration is known to complete. As long as the last write >> was flushed to the NFS server before the receiver opens the file, we >> should be safe. > > Note that the close really must happen before the next open. Otherwise > the file metadata might not be up-to-date on the destination, too. By "file metadata" I assume you mean "metadata about the virtual disk within the file", not "metadata about the file within the filesystem", right? That's good to know, I'll keep that in mind. Even if it's true that at the moment qemu doesn't write the file metadata until it closes the file, that just means we'd have to add a hook to the callback to save qemu state, to sync the metadata at that point, right? (This may in fact already be done; I'm more or less completely unfamiliar with the qemu side of save/restore.) -George