Am 12.11.2011 11:25, schrieb Avi Kivity: > On 11/11/2011 12:15 PM, Kevin Wolf wrote: >> Am 10.11.2011 22:30, schrieb Anthony Liguori: >>> Live migration with qcow2 or any other image format is just not going to >>> work >>> right now even with proper clustered storage. I think doing a block level >>> flush >>> cache interface and letting block devices decide how to do it is the best >>> approach. >> >> I would really prefer reusing the existing open/close code. It means >> less (duplicated) code, is existing code that is well tested and doesn't >> make migration much of a special case. >> >> If you want to avoid reopening the file on the OS level, we can reopen >> only the topmost layer (i.e. the format, but not the protocol) for now >> and in 1.1 we can use bdrv_reopen(). > > Intuitively I dislike _reopen style interfaces. If the second open > yields different results from the first, does it invalidate any > computations in between?
Not sure what results and what computation you mean, but let me clarify a bit about bdrv_reopen: The main purpose of bdrv_reopen() is to change flags, for example toggle O_SYNC during runtime in order to allow the guest to toggle WCE. This doesn't necessarily mean a close()/open() sequence if there are other means to change the flags, like fcntl() (or even using other protocols than files). The idea here was to extend this to invalidate all caches if some specific flag is set. As you don't change any other flag, this will usually not be a reopen on a lower level. If we need to use open() though, and it fails (this is really the only "different" result that comes to mind) then bdrv_reopen() would fail and the old fd would stay in use. Migration would have to fail, but I don't think this case is ever needed for reopening after migration. > What's wrong with just delaying the open? Nothing, except that with today's code it's harder to do. Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
