|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration |
Date: | Tue, 07 Sep 2010 11:00:45 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |