kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dor Laor <dlaor@redhat.com>
To: Lucas Meneghel Rodrigues <lmr@redhat.com>
Cc: Feng Yang <fyang@redhat.com>,
	autotest@test.kernel.org, kvm@vger.kernel.org
Subject: Re: [Autotest][PATCH V2] KVM Test: Add ioquit test case
Date: Sun, 23 May 2010 11:56:34 +0300	[thread overview]
Message-ID: <4BF8EDC2.4080507@redhat.com> (raw)
In-Reply-To: <1274138836.8388.135.camel@freedom>

On 05/18/2010 02:27 AM, Lucas Meneghel Rodrigues wrote:
> On Fri, 2010-05-14 at 17:43 +0800, Feng Yang wrote:
>> Emulate the powercut under IO workload(dd so far) using kill -9.
>> Then check image in post command.
>> This case want to make sure powercut under IO workload will not
>> break qcow2 image.
>
> The big question that came to my mind here is: Are we really expected to
> keep the hard disk image consistency even if the power is cut down? I am
> not sure about that. Dor, what is the expected behavior on this
> situation?

Consistency is expected, hope will meet it too.

>
>> Now it only work on linux.
>
> I have a couple of minor comments on this one:
>
>> Signed-off-by: Feng Yang<fyang@redhat.com>
>> ---
>>   client/tests/kvm/tests/ioquit.py       |   39 ++++++++++++++++++++++++++++++++
>>   client/tests/kvm/tests_base.cfg.sample |   10 +++++++-
>>   2 files changed, 48 insertions(+), 1 deletions(-)
>>   create mode 100644 client/tests/kvm/tests/ioquit.py
>>
>> diff --git a/client/tests/kvm/tests/ioquit.py b/client/tests/kvm/tests/ioquit.py
>> new file mode 100644
>> index 0000000..a202297
>> --- /dev/null
>> +++ b/client/tests/kvm/tests/ioquit.py
>> @@ -0,0 +1,39 @@
>> +import logging, time, random
>> +from autotest_lib.client.common_lib import error
>> +import kvm_test_utils
>> +
>> +
>> +def run_ioquit(test, params, env):
>> +    """
>> +    Emulate the poweroff under IO workload(dd so far) using kill -9.
>> +
>> +    @param test: Kvm test object
>> +    @param params: Dictionary with the test parameters.
>> +    @param env: Dictionary with test environment.
>> +    """
>> +
>> +    vm = kvm_test_utils.get_living_vm(env, params.get("main_vm"))
>> +    session = kvm_test_utils.wait_for_login(vm,
>> +                  timeout=int(params.get("login_timeout", 360)))
>> +    session2 = kvm_test_utils.wait_for_login(vm,
>> +                  timeout=int(params.get("login_timeout", 360)))
>> +    try:
>> +        bg_cmd = params.get("background_cmd")
>> +        logging.info("Add IO workload for guest OS.")
>> +        (s, o) = session.get_command_status_output(bg_cmd, timeout=60)
>> +        check_cmd = params.get("check_cmd")
>> +        (s, o) = session2.get_command_status_output(check_cmd, timeout=60)
>> +        if int(o)<= 0:
>> +            raise error.TestError("Fail to add IO workload for Guest OS")
>> +
>> +        logging.info("Sleep for a while")
>> +        time.sleep(random.randrange(30,100))
>> +        (s, o) = session2.get_command_status_output(check_cmd, timeout=300)
>> +        if int(o)<= 0:
>> +            logging.info("Background command finish before kill VM")
>
> ^ "IO workload finished before the VM was killed"
>
>> +        logging.info("Kill the virtual machine")
>> +        vm.process.close()
>> +    finally:
>> +        session.close()
>> +        session2.close()
>> diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample
>> index bb3646c..4387a36 100644
>> --- a/client/tests/kvm/tests_base.cfg.sample
>> +++ b/client/tests/kvm/tests_base.cfg.sample
>> @@ -389,7 +389,11 @@ variants:
>>                   rebase_mode = unsafe
>>                   image_name_snapshot1 = sn1
>>                   image_name_snapshot2 = sn2
>> -
>> +    - ioquit:
>> +        type = ioquit
>> +        background_cmd = "for i in 1 2 3 4; do (nohup dd if=/dev/urandom of=/tmp/file bs=102400 count=10000000&) done"
>> +        check_cmd = ps -a |grep dd |wc -l
>
> ^ Here we can add login_timeout explicitly so people can tune this
> timeout.
>
>> +
>>       # system_powerdown, system_reset and shutdown *must* be the last ones
>>       # defined (in this order), since the effect of such tests can leave
>>       # the VM on a bad state.
>> @@ -1347,6 +1351,10 @@ variants:
>>           pre_command += " scripts/hugepage.py /mnt/kvm_hugepage;"
>>           extra_params += " -mem-path /mnt/kvm_hugepage"
>>
>> +ioquit:
>> +    post_command_noncritical = no
>> +    only qcow2
>> +    only Linux
>>
>>   variants:
>>       - @no_pci_assignable:
>
>


      reply	other threads:[~2010-05-23  8:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-14  9:43 [Autotest][PATCH V2] KVM Test: Add ioquit test case Feng Yang
2010-05-17 23:27 ` [PATCH " Lucas Meneghel Rodrigues
2010-05-23  8:56   ` Dor Laor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF8EDC2.4080507@redhat.com \
    --to=dlaor@redhat.com \
    --cc=autotest@test.kernel.org \
    --cc=fyang@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lmr@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).