Re: [libvirt] [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration

Am 07.09.2010 17:11, schrieb Anthony Liguori: > On 09/07/2010 10:02 AM, Kevin Wolf wrote: > >> Am 07.09.2010 16:49, schrieb Anthony Liguori: >> >> >>>> Shouldn't it be a runtime option? You can use the very same image with >>>> copy-on-read or copy-on-write and it will behave the same (execpt for >>>> performance), so it's not an inherent feature of the image file. >>>> >>>> >>>> >>> The way it's implemented in QED is that it's a compatible feature. This >>> means that implementations are allowed to ignore it if they want to. >>> It's really a suggestion. >>> >>> >> Well, the point is that I see no reason why an image should contain this >> suggestion. There's really nothing about an image that could reasonably >> indicate "use this better with copy-on-read than with copy-on-write". >> >> It's a decision you make when using the image. >> >> > Copy-on-read is, in many cases, a property of the backing file because > it suggests that the backing file is either very slow or potentially > volatile. > The simple copy-on-read without actively streaming the rest of the image is not enough anyway for volatile backing files.

> IOW, let's say I'm an image distributor and I want to provide my images > in a QED format that actually streams the image from an http server. I > could provide a QED file without a copy-on-read bit set but I'd really > like to convey this information as part of the image. > > You can argue that I should provide a config file too that contained the > copy-on-read flag set but you could make the same argument about backing > files too. > No. The image is perfectly readable when using COW instead of COR. On the other hand, it's completely meaningless without its backing file.

>>> So yes, you could have a run time switch that overrides the feature bit >>> on disk and either forces copy-on-read on or off. >>> >>> Do we have a way to pass block drivers run time options? >>> >>> >> We'll get them with -blockdev. Today we're using colons for format >> specific and separate -drive options for generic things. >> >> > That's right. I think I'd rather wait for -blockdev. > Well, then I consider -blockdev a dependency of QED (the copy-on-read part at least) and we can't merge it before we have -blockdev.

> You really can't do as good of a job in the block layer because you have > very little info about the characteristics of the disk image. > I'm not saying that the generic block layer should implement copy-on-read. I just think that it should pass a run-time option to the driver - maybe just a BDRV_O_COPY_ON_READ flag - instead of having the information in the image file. From a user perspective it should look the same for qed, qcow2 and whatever else (like copy-on-write today)

Kevin