On 09/07/2010 10:39 AM, Kevin Wolf wrote:
Am 07.09.2010 17:30, schrieb Anthony Liguori:
On 09/07/2010 10:20 AM, Kevin Wolf wrote:
Am 07.09.2010 17:11, schrieb Anthony Liguori:
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.
But as a web site owner, it's extremely useful for me to associate
copy-on-read with an image because it significantly reduces my bandwidth.
I have a hard time believing this isn't a valuable use-case and not one
that's actually pretty common.
As a web site user, I don't necessarily want you to control the
behaviour of my qemu. :-)
That's why I understand your argument about -blockdev and making sure
all compat features can be overridden. I'm happy with that as a
requirement.Okay, the only place I'm disagreeing slightly is that I
think an image
format should be able to request copy_on_read such that the default
behavior if an explicit flag isn't specified is to do what the image
suggests we do.
Maybe we can agree on that. I'm not completely decided yet if allowing
the image to contain such a hint is a good or a bad thing.
It's a tough space. We don't want to include crazy amounts of metadata
(and basically become OVF) but there's metadata that we would like to have.
backing_format is a good example. It's a suggestion and it's something
you really want to let a user override.
Regards,
Anthony Liguori
Kevin
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list