qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Lucas Meneghel Rodrigues <lmr@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	Markus Armbruster <armbru@redhat.com>,
	Amit Shah <amit.shah@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] The state of testing
Date: Tue, 05 Mar 2013 13:09:47 -0300	[thread overview]
Message-ID: <513618CB.1020501@redhat.com> (raw)
In-Reply-To: <5134CA4A.7040700@redhat.com>

On 03/04/2013 01:22 PM, Gerd Hoffmann wrote:
>    Hi,
>
>> How are things looking with device emulation, migration, monitor, char, etc?
>
> At the moment autotest/virt-test is pretty much the only workable thing
> for non-trivial devices because libqtest lacks infrastructure for pci
> and anything building on top of pci.
>
> usb has no in-tree tests, but has autotest coverage.
>
> chardevs have some autotest coverage, /me wrote a test for
> chardev-{add,remove} qmp commands.  Still need to rebase + polish +
> submit that one though.
>
> Migration coverage is pretty bad overall I think.

On virt-tests there are at least 48 tests that are easy to run and 
involve migration. A subset of them is executed regularly in the daily jobs:

./run -t qemu -g Fedora.18.x86_64 --list-tests | grep migrat | grep -v 
multi_host

21 balloon_check.balloon-migrate
51 cpuflags.stress_guest.qemu_test_migration_with_additional_flags
65 migrate.default.tcp
66 migrate.default.unix
67 migrate.default.exec
68 migrate.default.fd
69 migrate.default.mig_cancel
70 migrate.with_speed_measurement.tcp
71 migrate.with_speed_measurement.unix
72 migrate.with_speed_measurement.exec
73 migrate.with_speed_measurement.fd
74 migrate.with_set_speed.tcp
75 migrate.with_set_speed.unix
76 migrate.with_set_speed.exec
77 migrate.with_set_speed.fd
78 migrate.with_reboot.tcp
79 migrate.with_reboot.unix
80 migrate.with_reboot.exec
81 migrate.with_reboot.fd
82 migrate.with_file_transfer.tcp
83 migrate.with_file_transfer.unix
84 migrate.with_file_transfer.exec
85 migrate.with_file_transfer.fd
86 migrate.with_autotest.dbench.tcp
87 migrate.with_autotest.dbench.unix
88 migrate.with_autotest.dbench.exec
89 migrate.with_autotest.dbench.fd
90 migrate.with_autotest.stress.tcp
91 migrate.with_autotest.stress.unix
92 migrate.with_autotest.stress.exec
93 migrate.with_autotest.stress.fd
94 migrate.with_autotest.monotonic_time.tcp
95 migrate.with_autotest.monotonic_time.unix
96 migrate.with_autotest.monotonic_time.exec
97 migrate.with_autotest.monotonic_time.fd
2146 nic_hotplug.migration.nic_8139 (requires root)
2147 nic_hotplug.migration.nic_virtio (requires root)
2148 nic_hotplug.migration.nic_e1000 (requires root)
2483 
virtio_console.spread_linear.specifiable.virtserialport.with_vm.migration.offline
2484 
virtio_console.spread_linear.specifiable.virtserialport.with_vm.migration.online
2515 
virtio_console.spread_linear.specifiable.virtconsole.with_vm.migration.offline
2516 
virtio_console.spread_linear.specifiable.virtconsole.with_vm.migration.online
2561 
virtio_console.spread_2.specifiable.virtserialport.with_vm.migration.offline
2562 
virtio_console.spread_2.specifiable.virtserialport.with_vm.migration.online
2584 
virtio_console.spread_2.specifiable.virtconsole.with_vm.migration.offline
2585 
virtio_console.spread_2.specifiable.virtconsole.with_vm.migration.online
2672 timedrift.ntp.with_migration
2676 timedrift.date.with_migration

Those can be run with relative ease on every developer laptop, not 
counting the many multi host tests involving migration, that are still 
not being executed on a regular basis on our test farm. So I don't think 
migration coverage is that bad.

  parent reply	other threads:[~2013-03-05 16:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-04 15:53 [Qemu-devel] The state of testing Stefan Hajnoczi
2013-03-04 16:22 ` Gerd Hoffmann
2013-03-04 17:26   ` mdroth
2013-03-05  9:46   ` Kevin Wolf
2013-03-05 10:46   ` Stefan Hajnoczi
2013-03-05 11:17     ` Gerd Hoffmann
2013-03-05 15:59       ` Lucas Meneghel Rodrigues
2013-03-05 16:14         ` Gerd Hoffmann
2013-03-05 16:21           ` Lucas Meneghel Rodrigues
2013-03-06  9:53             ` Stefan Hajnoczi
2013-03-06 12:00               ` Markus Armbruster
2013-03-05 16:09   ` Lucas Meneghel Rodrigues [this message]
2013-03-05 16:23     ` Gerd Hoffmann
2013-03-05 16:41       ` Lucas Meneghel Rodrigues
2013-03-04 19:20 ` Anthony Liguori
2013-03-05 10:45   ` Stefan Hajnoczi
2013-03-05 10:11 ` Amit Shah
2013-03-05 15:54   ` Lucas Meneghel Rodrigues
2013-03-11  8:52     ` Amit Shah

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=513618CB.1020501@redhat.com \
    --to=lmr@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=amit.shah@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@gmail.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).