Re: [Qemu-devel] [RFC][PATCH 0/2] Allow cache settings for block devices to be changed at runtime.

[Kevin Wolf <kwolf@redhat.com>]

Am 01.03.2011 10:55, schrieb Stefan Hajnoczi:
> On Mon, Feb 28, 2011 at 3:48 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 28.02.2011 16:35, schrieb Stefan Hajnoczi:
>>> On Mon, Feb 28, 2011 at 3:12 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>>>> Am 28.02.2011 12:49, schrieb Prerna Saxena:
>>>>> The following patchset introduces monitor commands:
>>>>>
>>>>> 1. set_cache DEVICE CACHE-SETTING
>>>>> Change cache settings for block device, DEVICE, through the monitor.
>>>>> (Available options : 'none', 'writeback', 'writethrough')
>>>>> Eg,
>>>>> (qemu)set_cache ide0-hd0 none
>>>>> -> Changes cache setting for ide0-hd0 to 'none'
>>>>
>>>> Not sure if adding this interface is a good idea. I see that you only
>>>> add it for HMP, and we may consider that, but it's definitely not
>>>> suitable for QMP.
>>>>
>>>> One reason is that none/writethrough/writeback/unsafe isn't really what
>>>> we want to use long term. We want to separate advertising a write cache
>>>> (which is guest visible) from things like whether to use O_DIRECT or not.
>>>>
>>>> In the past, Christoph mentioned that he had patches to make these
>>>> separate and even let the guest change the "write cache enabled" flag,
>>>> which would probably solve most of the use cases of this patch.
>>>
>>> Toggling host page cache at runtime is useful too because it saves
>>> having to restart VMs.
>>
>> Not sure why I wanted to change that during runtime, but agreed,
>> allowing to change parameters using the monitor is generally a good thing.
>>
>> However, I'm not sure if a command for changing the cache mode is the
>> right solution, or if it should be something like a command to change
>> block device options. (For example, what about toggling read-only or
>> snapshot mode?)
> 
> Yes, I think you're right.  We should aim for a general interface
> rather than having to add many more specific interfaces in the future.
> 
> CQ: Do you see a relation to the "update" interface you added to
> adjust drive options at runtime for FVD?

On one hand it's a different set of options today. IIUC, qemu-img update
refers to persistent per-image options like backing file, encryption,
etc. This monitor command refers to temporary command line options like
cache, snapshot mode etc.

On the other hand, we've had discussions before about storing a
copy-on-read flag in images which makes sense as a command line option
as well. The same may apply to things like the read-only flags.

So maybe these two sets of flags aren't that distinct from each other.

Kevin