public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Uri Lublin <uril@qumranet.com>
Cc: kvm@vger.kernel.org, Dror Russo <dror@qalogic.com>
Subject: Re: [ANNOUNCE] kvm-autotest
Date: Wed, 9 Jul 2008 12:43:57 -0300	[thread overview]
Message-ID: <20080709154357.GA6217@dmt.cnet> (raw)
In-Reply-To: <48709B6D.6030300@qumranet.com>

On Sun, Jul 06, 2008 at 01:16:13PM +0300, Uri Lublin wrote:
> Hello,
>
>     We are happy to announce the availability of kvm-autotest, a test 
> framework for KVM based on autotest. Naturally, the purpose is to make 
> KVM stable, find/fix bugs faster and prevent regressions. It is to serve 
> developers, to test if their new code breaks anything, as well as users, 
> to verify that the KVM they are using is stable in their own environment.
>
>     There are many things to improve. Currently supported are only a few tests
> (mainly reboot/migration) and a single guest (Fedora 8 i386). This will 
> change soon as we add tests and guests to the test matrix.
>
>     We've tried to be very flexible with configuration of tests, so there are
> quite a few options to choose from (check the documentation). For example
> one may choose to download and install the latest (or a specific) KVM release,
> the latest (or a specific) daily snapshot, use git, or use other source.
> Almost all configuration is located in kvm.cfg (under client directory).
>
>     By default kvm-autotest creates a machine-local subnet with a
> local dhcp server. The dhcp server is configured to ignore unknown clients and
> only serves KVM guests. One may disable it by changing kvm.cfg (See documentation)
>
>     The test framework is based on autotest ( http://test.kernel.org/autotest ).
> Currently we only using client tests, later we may want to use server tests
> for more complicated tests.

This is looking great. Easy to use and fast. A few comments:

- As you mention, it should reuse the server/client model for running
  tests inside guests. I hacked up a "kvm_autotest" test that
  basically does:

tests = ["linus_stress", "bash_shared_mapping", "rmaptest", "tsc",
"scrashme", "isic", "sleeptest", "libhugetlbfs", "..."]

vm.ssh.scp_to_remote(autotest_tarball, '/root')
(s,o) = vm.ssh.ssh('tar zvxf kvm-autotest.tar.gz')
for i in range(0, len(tests)):
    (s,o) = vm.ssh.ssh('kvm-autotest/client/bin/autotest ' +
                       'kvm-autotest/client/tests/' + tests[i] +
                       '/control')
    print(o)

Which poorly replicates what the client/server infrastructure already
provides. IMO its a waste of time to write specialized client
tests (other than virt specific ones).

- On top of the client tests, we want to be able to force "special
stress conditions", such as:
    - host memory pressure (to test mmu shrink and mmu notifiers)
    - CPU starvation (lower the priority of the guest process with 
     higher prio CPU hungry tasks running on the host).
    - synthetic cpu migration stress. ChrisW wrote this script sometime
      ago to test clock stability:

     PID=$1
     while :
     do
        for x in 0x01 0x02 0x04 0x08 0x10 0x20 0x40 0x80
        do
            taskset -p $x $PID > /dev/null 2>&1
            usleep 5
        done
     done
    - migration (as it stands now there is no transparent way to schedule 
      client tests to run _while_ migration is in progress, one needs to
      manually change the migration test for that).

- Currently its difficult to debug client test failure inside guests,
  since the VM and its image are destroyed. Perhaps the client/server
  model handles error handling/reporting much more nicely.


Great work!

  reply	other threads:[~2008-07-09 15:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-06 10:16 [ANNOUNCE] kvm-autotest Uri Lublin
2008-07-09 15:43 ` Marcelo Tosatti [this message]
2008-07-10 12:09   ` Uri Lublin
2008-07-12 15:31     ` Ryan Harper
2008-07-15  1:22       ` Uri Lublin
2008-07-15  7:39         ` Dor Laor
2008-07-15 12:32         ` Ryan Harper
2008-07-16 23:11           ` Uri Lublin
2008-07-17  0:08             ` Ryan Harper
2008-07-21 14:43               ` Uri Lublin
  -- strict thread matches above, loose matches on Subject: below --
2008-07-12 14:27 Marcelo Tosatti
2008-07-15  1:02 ` Uri Lublin

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=20080709154357.GA6217@dmt.cnet \
    --to=mtosatti@redhat.com \
    --cc=dror@qalogic.com \
    --cc=kvm@vger.kernel.org \
    --cc=uril@qumranet.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