On Wed, Apr 20, 2011 at 2:10 AM, Asias He <asias.hejun@xxxxxxxxx> wrote:
>>> This came up during our testing.
>>>
>>> Ingo suggested a large delay so we could easily see the results of
>>> threading. The problem we encountered was that having a delay right from
>>> the beginning will make the guest kernel take a rather long time to boot
>>> and would make actually testing the threading impossible.
>>>
>>> I've added a delay before the activation of the I/O request completion
>>> delay to give the tester/debugger enough time to boot into the guest and
>>> prepare anything needed for the test.
>>>
>>> Making it a constant is also rather hard because different kernels can
>>> take a very different amount of I/O requests to boot. Take the simple
>>> example of a whether fsck was running during the boot or not.
>>
>> I suspect we'll eventually want to have some sort of 'kvm set' subcommand that
>> can modify attributes of running instances? Setting the debug delay would be
>> one of the options:
>>
>> kvm set MyInstance-1 --debug-io-delay-ms 10000
>>
>> That way the delay can be activated in a suitable moment - and disabled again
>> after testing:
>>
>> kvm set MyInstance-1 --debug-io-delay-ms 0
>>
>
> It's a very good idea.
>
> Do we need:
>
> kvm get MyInstance-1
>
> which reports all the attributes, or
>
> kvm get MyInstance-1 --debug-io-delay-ms
>
> which only reports the interested attribute.
Sorry for the bikeshedding but wouldn't it be better to follow Git's
lead and have something like
kvm config MyInstance-1 --set debug.io.delay.ms 100
and
kvm config MyInstance-1 --list
Pekka
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
